Re: [PATCH] i2c: Let checkpatch shout on users of the legacy model

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

Hi Mauro,

On Thu, 12 Mar 2009 12:32:04 -0300, Mauro Carvalho Chehab wrote:
> Hi Jean,
> 
> On Thu, 12 Mar 2009 16:15:51 +0100
> Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:
> 
> > As suggested by Mauro Carvalho Chehab.
> > 
> > Signed-off-by: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
> > Cc: Mauro Carvalho Chehab <mchehab-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> > ---
> >  Documentation/feature-removal-schedule.txt |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > --- linux-2.6.29-rc7.orig/Documentation/feature-removal-schedule.txt	2009-03-12 08:48:06.000000000 +0100
> > +++ linux-2.6.29-rc7/Documentation/feature-removal-schedule.txt	2009-03-12 16:07:35.000000000 +0100
> > @@ -311,7 +311,8 @@ Who:  Krzysztof Piotr Oledzki <ole@ans.p
> >  ---------------------------
> >  
> >  What:	i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client()
> > -When:	2.6.29 (ideally) or 2.6.30 (more likely)
> > +When:	2.6.30
> 
> There are still some legacy v4l drivers that uses those functions. I'm not sure
> if there are enough time to convert all of them in time for 2.6.30 merge
> window.

Well, the legacy API will go away in 2.6.30. Drivers using it will
break, I'm sure this will motivate users to complain, and in turn
developers to fix their drivers ;)

(I'm only half-kidding.)

> Those directly references i2c_attach_client:
> 	ir-kbd-i2c.c, ov7670.c, v4l2-common.c
> 
> And those are using the legacy I2C header, created by Hans:
> 	cs53l32a.c, cx25840-core.c, msp3400-driver.c, saa6588.c, saa7115.c, tda7432.c
> 	tda9875.c, tuner-core.c, tvaudio.c, tvp5150.c, wm8775.c

As I understand it, Hans is already working on converting these drivers
to no longer use the legacy model. So there really only are 3 drivers
which need more work. I am working on ir-kbd-i2c myself (well, I am
supposed to... didn't progress too much lately).

> This plus the I2C buses that requires those drivers.
> 
> Depending on the time Linus releases 2.6.29, it would probably be more
> realistic to schedule it to 2.6.31.

There's no point in rescheduling. If we patiently wait for an API to
become unused before we remove it, there's no point to announce a
version when the API will be removed in the first palce, and there's a
risk that the removal will never happen. The whole point of announcing
a version is that developers can prepare for it and we stick to what we
announced (as much as possible).

Really, I don't think 2.6.30 is unrealistic. Hans has done a huge work
already for the v4l side. I have done my part on hwmon, and Alessandro
Zummo on rtc. Getting the remainder done within a few weeks sounds
totally possible _if_ we can drop support kernels < 2.6.22 from the
v4l-dvb repository. This has already been discussed... There are i2c
subsystem fixes and improvements which many people have asked for which
depend on this.

-- 
Jean Delvare