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

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

[Jean Delvare]

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
+Check:	i2c_attach_client i2c_detach_client
 Why:	Deprecated by the new (standard) device driver binding model. Use
 	i2c_driver->probe() and ->remove() instead.
 Who:	Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>


-- 
Jean Delvare

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

[Mauro Carvalho Chehab]

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.

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

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.

> +Check:	i2c_attach_client i2c_detach_client

OK.

Cheers,
Mauro

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

[Jean Delvare]

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

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

[Mauro Carvalho Chehab]

On Thu, 12 Mar 2009 18:51:10 +0100
Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:

> 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.)

:)

I agree on trying to do this for 2.6.30, but it will depend on when Linus will
release 2.6.29.
> 
> > 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.

True. Thanks to Hans, most of drivers were converted.

> 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.

The issue is not related to drop support for < 2.6.22, but to finish porting
the I2C adapters that use those I2C drivers, and test they with the several
different supported i2c combinations.

On a first glance, it seems that we still need to port bttv, cafe-ccic, cx23885,
em28xx, cx88 and pvrusb2.

Those drivers responds for the majority number of different TV capture boards
in the market.

I know that Hans is working with bttv driver, and asked other developers to
help on this task.

It is still a huge job, due to the number of different I2C variants that each
card have, the need for tests with several different I2C configurations and the
lack of information we have about a large number of the supported cards.

Doing this conversion without care and enough testing will for sure generate
regressions.

Cheers,
Mauro

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

[Jean Delvare]

Hi Mauro,

On Thu, 12 Mar 2009 23:41:33 -0300, Mauro Carvalho Chehab wrote:
> On Thu, 12 Mar 2009 18:51:10 +0100
> Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:
> > 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.
> 
> True. Thanks to Hans, most of drivers were converted.
> 
> > 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.
> 
> The issue is not related to drop support for < 2.6.22, but to finish porting
> the I2C adapters that use those I2C drivers, and test they with the several
> different supported i2c combinations.

It is related, indirectly, because it is the same developers who can
work on finishing driver conversions and who take care of the v4l-dvb
repository. The time spent on compatibility issues (which happen to be
difficult to deal with for kernels < 2.6.22) is not spent on fixing and
testing upstream drivers. Not to mention that the code for pre-2.6.22
kernels would be so different that it would need to be tested
separately, in effect doubling the amount of testing required.

Hans made a poll some weeks ago with regards to the interest developers
and users have in supporting pre-2.6.22 kernels and the results were
pretty clear: this is something almost nobody is interested in. So I am
curious, what are we waiting for before we drop support these old
kernels?

> On a first glance, it seems that we still need to port bttv, cafe-ccic, cx23885,
> em28xx, cx88 and pvrusb2.
> 
> Those drivers responds for the majority number of different TV capture boards
> in the market.
> 
> I know that Hans is working with bttv driver, and asked other developers to
> help on this task.
> 
> It is still a huge job, due to the number of different I2C variants that each
> card have, the need for tests with several different I2C configurations and the
> lack of information we have about a large number of the supported cards.
> 
> Doing this conversion without care and enough testing will for sure generate
> regressions.

Yes, I agree. I can help test bttv (2 adapters) and cx88 (one adapter).

-- 
Jean Delvare

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

[Mauro Carvalho Chehab]

On Sun, 15 Mar 2009 09:25:29 +0100
Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:

> Hi Mauro,
> 
> On Thu, 12 Mar 2009 23:41:33 -0300, Mauro Carvalho Chehab wrote:
> > On Thu, 12 Mar 2009 18:51:10 +0100
> > Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:
> > > 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.
> > 
> > True. Thanks to Hans, most of drivers were converted.
> > 
> > > 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.
> > 
> > The issue is not related to drop support for < 2.6.22, but to finish porting
> > the I2C adapters that use those I2C drivers, and test they with the several
> > different supported i2c combinations.
> 
> It is related, indirectly, because it is the same developers who can
> work on finishing driver conversions and who take care of the v4l-dvb
> repository. The time spent on compatibility issues (which happen to be
> difficult to deal with for kernels < 2.6.22) is not spent on fixing and
> testing upstream drivers. Not to mention that the code for pre-2.6.22
> kernels would be so different that it would need to be tested
> separately, in effect doubling the amount of testing required.
> 
> Hans made a poll some weeks ago with regards to the interest developers
> and users have in supporting pre-2.6.22 kernels and the results were
> pretty clear: this is something almost nobody is interested in. So I am
> curious, what are we waiting for before we drop support these old
> kernels?

>From the comments posted at lwn.net, it seems that there are more people
interested on keeping backport support. Also, from my side, not supporting
2.6.18 will break my production environment, and for sure this is something I
don't want.

Anyway, I've already provided an skeleton of a backport solution for pre-2.6.22, on an
experimental tree, based on a driver that Hans provided me, with what he thinks
it will be the way the new drivers will look alike and what's needed to keep it
working with 2.6.22 or lower.

Since people are still busy with the i2c conversion I didn't have any feedback
yet about the backport tree, nor I think people will have enough time to test
this before 2.6.30 rc cycle, I suspect that the tree changes (and probably
including moving it to a full git-based deployment model) will likely be
postponed, since we'll need to adjust the entire development environment, and
this takes time that I won't have during this merging cycle.

> > On a first glance, it seems that we still need to port bttv, cafe-ccic, cx23885,
> > em28xx, cx88 and pvrusb2.
> > 
> > Those drivers responds for the majority number of different TV capture boards
> > in the market.
> > 
> > I know that Hans is working with bttv driver, and asked other developers to
> > help on this task.
> > 
> > It is still a huge job, due to the number of different I2C variants that each
> > card have, the need for tests with several different I2C configurations and the
> > lack of information we have about a large number of the supported cards.
> > 
> > Doing this conversion without care and enough testing will for sure generate
> > regressions.
> 
> Yes, I agree. I can help test bttv (2 adapters) and cx88 (one adapter).

Good!

Cheers,
Mauro

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

[Jean Delvare]

Hi Mauro,

On Mon, 16 Mar 2009 07:25:59 -0300, Mauro Carvalho Chehab wrote:
> On Sun, 15 Mar 2009 09:25:29 +0100
> Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:
> > Hans made a poll some weeks ago with regards to the interest developers
> > and users have in supporting pre-2.6.22 kernels and the results were
> > pretty clear: this is something almost nobody is interested in. So I am
> > curious, what are we waiting for before we drop support these old
> > kernels?
> 
> From the comments posted at lwn.net, it seems that there are more people
> interested on keeping backport support.

Pointer?

The key question IMHO is: are these people willing to contribute their
time to make it work? If not then their opinion is only mildly
interesting.

> Also, from my side, not supporting
> 2.6.18 will break my production environment, and for sure this is something I
> don't want.

I can understand that you want a rock-solid environment for your daily
work. However I fail to see why that environment also needs to be the
target for your development. I have a separate system for this.

> Anyway, I've already provided an skeleton of a backport solution for pre-2.6.22, on an
> experimental tree, based on a driver that Hans provided me, with what he thinks
> it will be the way the new drivers will look alike and what's needed to keep it
> working with 2.6.22 or lower.
> 
> Since people are still busy with the i2c conversion I didn't have any feedback
> yet about the backport tree, nor I think people will have enough time to test
> this before 2.6.30 rc cycle, I suspect that the tree changes (and probably
> including moving it to a full git-based deployment model) will likely be
> postponed, since we'll need to adjust the entire development environment, and
> this takes time that I won't have during this merging cycle.

Agreed.

-- 
Jean Delvare