summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/utilities/utcopy.c
diff options
context:
space:
mode:
authorTrent Piepho <xyzzy@speakeasy.org>2007-07-17 18:29:42 -0300
committerMauro Carvalho Chehab <mchehab@infradead.org>2007-07-30 16:26:23 -0300
commitc812b67ca4ed13fa5ec60f06c4ed8f648722a186 (patch)
treef01921a78e2f0a46d2a154430b8e7afc42ef277b /drivers/acpi/utilities/utcopy.c
parent9c837fb692b005203765d8a569a2fe43fdff9df1 (diff)
downloadkernel-crypto-c812b67ca4ed13fa5ec60f06c4ed8f648722a186.tar.gz
kernel-crypto-c812b67ca4ed13fa5ec60f06c4ed8f648722a186.tar.xz
kernel-crypto-c812b67ca4ed13fa5ec60f06c4ed8f648722a186.zip
V4L/DVB (5886): zr36067: Fix problem setting norms
The zr36067 driver doesn't make a distinction between the different sub-types of NTSC, PAL, or SECAM norms. For example, when the enum std ioctl returns the PAL standard it returns PAL_BG|PAL_DK|PAL_H|PAL_I. When setting the norm, it required the bitmask to match exactly the set of norms used during the enumeration. If just one norm was specified, for example PAL_BG or NTSC_M, it would fail. This violates the V4L2 spec, "VIDIOC_S_STD accepts *one* or more flags..." The key thing to realize is that V4L2_STD_PAL is not one bit, it is multiple bits. It's ok to call S_STD with any *one* of those bits, but the driver was requiring *all* of them. This fixes the S_STD function so that it will accept any set of one or more PAL norms as PAL, and the same for NTSC and SECAM. Signed-off-by: Trent Piepho <xyzzy@speakeasy.org> Acked-by: Ronald S. Bultje <rbultje@ronald.bitfreak.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Diffstat (limited to 'drivers/acpi/utilities/utcopy.c')
0 files changed, 0 insertions, 0 deletions