linux-kernel - Re: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

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: <20130531100827.10710841@redhat.com>
Date:	Fri, 31 May 2013 10:08:27 -0300
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Jon Arne Jørgensen <jonarne@...arne.no>
Cc:	Timo Teras <timo.teras@....fi>,
	Andy Walls <awalls@...metrocast.net>,
	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

Em Thu, 30 May 2013 21:00:01 +0200
Jon Arne Jørgensen <jonarne@...arne.no> escreveu:

> On Thu, May 30, 2013 at 08:33:32AM +0300, Timo Teras wrote:
> > 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.
> > 
> 
> I think the bulk of the table will be the same for all drivers.
> It's one bit here and one bit there that needs changing.
> As the driver didn't support platform data.
> Changing to a new init table for the drivers that implement
> platform_data shouldn't cause any regressions.

There are several things that are very bad on passing a table via
platform data:

	1) you're adding saa711x-specific data at the bridge driver,
	   so, the saa711x code is spread on several places at the
	   long term;

	2) some part of the saa711x code may override the data there, 
	   as it is not aware about what bits should be preserved from
	   the new device;

	3) due (2), latter changes on the code are more likely to
	   cause regressions;

	4) also due to (2), some hacks can be needed, in order to warn
	   saa711x to handle some things differently.

That's why it is a way better to add meaningful parameters telling what
bits are needed for the driver to work with the bridge. That's also
why we do this with all other drivers.

Regards,
Mauro
--
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/