After annotating the frame structs, this was left:
drivers/ieee1394/dv1394.c:2113:23: warning: invalid assignment: |=
drivers/ieee1394/dv1394.c:2113:23:    left side has type restricted __le32
drivers/ieee1394/dv1394.c:2113:23:    right side has type int
drivers/ieee1394/dv1394.c:2121:24: warning: invalid assignment: &=
drivers/ieee1394/dv1394.c:2121:24:    left side has type restricted __le32
drivers/ieee1394/dv1394.c:2121:24:    right side has type int
drivers/ieee1394/dv1394.c:2123:24: warning: invalid assignment: |=
drivers/ieee1394/dv1394.c:2123:24:    left side has type restricted __le32
drivers/ieee1394/dv1394.c:2123:24:    right side has type int

Which looks like a real bug on a big-endian arch as it would set/clear
the wrong bit.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>

Bill Fink writes:

I finally got a chance to test the patch on my kernel, and live DV
viewing using xine still worked fine.  Although I admit to being
mystified how it works both before and after the patch, since the
cpu_to_le32() calls that were added should result in byte swapping on
PPC that wasn't being done before.  I guess that either the code paths
involved aren't actually being triggered by my xine DV viewing, or
there's some fortuitous palindromic setting of bits.
Tested-by: Bill Fink <billfink@mindspring.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>