On Tue, 12 May 2009, Mauro Carvalho Chehab wrote: > Em Tue, 12 May 2009 17:18:20 -0400 > Devin Heitmueller <[email protected]> escreveu: > > > On Tue, May 12, 2009 at 4:39 PM, <[email protected]> wrote: > > > From: Roel Kluin <[email protected]> > > > > > > Fix &&/|| typo. `default_norm' can be 0 (PAL), 1 (NTSC) or 2 (SECAM), > > > the condition tested was impossible. > > > > > > Signed-off-by: Roel Kluin <[email protected]> > > > Cc: Mauro Carvalho Chehab <[email protected]> > > > Cc: Hans Verkuil <[email protected]> > > > Signed-off-by: Andrew Morton <[email protected]> > > > --- > > > > Hello, > > > > Was the patch actually tested against the hardware in question? While > > I agree that it looks ok, it can result in the default logic being > > inverted in some cases, which could expose other bugs and result in a > > regression. > > > > I just want to be confident that this patch was tested by somebody > > with the hardware and it isn't going into the codebase because "it > > obviously cannot be right". > > Hans and Jean worked on it. Both are at PAL area, so they won't notice such > error without a standards generator, since the default is to assume that the > signal is PAL. > > With this patch, PAL should keep working, but I can't see how NTSC or SECAM > would work without it.
NTSC works fine without it. The code with the bug was supposed to check for an out of range module parameter and fix it, but it was broken and did nothing. There is no problem if default_norm was set to an ok value, but if someone specified default_norm=42 then the driver wouldn't fix it and something bad might happen. Maybe it would read off the end of the norms array and crash? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
