lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130530083332.245e3c62@vostro>
Date:	Thu, 30 May 2013 08:33:32 +0300
From:	Timo Teras <timo.teras@....fi>
To:	Jon Arne Jørgensen <jonarne@...arne.no>
Cc:	Andy Walls <awalls@...metrocast.net>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	hans.verkuil@...co.com, prabhakar.csengg@...il.com,
	g.liakhovetski@....de, ezequiel.garcia@...e-electrons.com
Subject: Re: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

On Thu, 30 May 2013 07:21:36 +0200
Jon Arne Jørgensen <jonarne@...arne.no> wrote:

> On Wed, May 29, 2013 at 10:19:49PM -0400, Andy Walls wrote:
> > Mauro Carvalho Chehab <mchehab@...hat.com> wrote:
> > 
> > >Em Wed, 29 May 2013 22:41:16 +0200
> > >Jon Arne Jørgensen <jonarne@...arne.no> escreveu:
> > >
> > >> Change all default values in the initial setup table to match the
> > >table
> > >> in the datasheet.
> > >
> > >This is not a good idea, as it can produce undesired side effects
> > >on the existing drivers that depend on it, and can't be easily
> > >tested.
> > >
> > >Please, don't change the current "default". It is, of course, OK
> > >to change them if needed via the information provided inside the
> > >platform data.
> >
> > I was going to make a comment along the same line as Mauro.  
> > Please leave the driver defaults alone.  It is almost impossible to
> > regression test all the different devices with a SAA7113 chip, to
> > ensure the change doesn't cause someone's device to not work
> > properly.
> >
> 
> You guys are totally right.
> 
> What if I clone the original saa7113_init table into a new one, and
> make the driver use the new one if the calling driver sets
> platform_data.
> 
> Something like this?
> 
>         switch (state->ident) {
>         case V4L2_IDENT_SAA7111:
>         case V4L2_IDENT_SAA7111A:
>                 saa711x_writeregs(sd, saa7111_init);
>                 break;
>         case V4L2_IDENT_GM7113C:
>         case V4L2_IDENT_SAA7113:
> -		saa711x_writeregs(sd, saa7113_init);
> +		if (client->dev.platform_data)
> +			saa711x_writeregs(sd, saa7113_new_init);
> +		else
> +			saa711x_writeregs(sd, saa7113_init);

I would rather have the platform_data provide the new table. Or if you
think bulk of the table will be the same for most users, then perhaps
add there an enum saying which table to use - and name the tables
according to the chip variant it applies to.

- Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ