2.4.22 kernel patches available

2.4.22 kernel patches available

[Jean Delvare]

Hi all,

I just finished updating my installation guide to support the new 2.4.22
kernel.

I noticed that new I2C drivers exist there: i2c-sibyte (plus
i2c-algo-sibyte) and i2c-max1617. Why they end up there without us even
hearing about it is a complete mystery to me. The max1617 driver is
crappy (polling + working only with the sibyte bus) and completely
useless since we already support that chip for years. The bus driver
probably should have been built into a single module. And none of these
modules will even compile since they use I2C IDs that are not defined.

My 2.4.22 patch simply wipe them out. I can't understand how they were
accepted into the main kernel tree. I couldn't find anything related to
them in the kernel changelog nor in LKML archives. I feel like we should
complain about that, but unfortunately I don't have time for that right
now. Greg, you have more contact with the kernel people than any of us
here, do you have any information we don't have?

I am taking a new (well...) job tomorrow. At last :) I'm more than
pleased, but you have to understand that this also means the end of my
active participation to the LM Sensors project. Don't worry, I won't
leave the project completely and within a few months I hope I'll have
some time left again to contribute. But I won't spend 6 hours a day on
it as it has been the case for the last few months. BTW, I'd like to
thank you all very much for that. I've learned much here, and it also
prevented me from falling into the laziness :)

See you later.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

2.4.22 kernel patches available

[Mark D. Studebaker]

On sybyte and max1617 we should try and find the authors and bring them into the fold.

On you moving on, hopefully you can find 1-2 hours a week for us which would
still qualify you as "active"! We've appreciated your energy and enthusiasm
(and new ideas) over the recent months, especially as it came when
I was running out of all of those...

Any proposal for how to proceed with the 2.4 patch?
Without you to generate a 2.8.1->2.4.23 patch, what should we do?


And if you don't mind, what are you going to be doing for a living?

thanks again
mds

Jean Delvare wrote:
> Hi all,
> 
> I just finished updating my installation guide to support the new 2.4.22
> kernel.
> 
> I noticed that new I2C drivers exist there: i2c-sibyte (plus
> i2c-algo-sibyte) and i2c-max1617. Why they end up there without us even
> hearing about it is a complete mystery to me. The max1617 driver is
> crappy (polling + working only with the sibyte bus) and completely
> useless since we already support that chip for years. The bus driver
> probably should have been built into a single module. And none of these
> modules will even compile since they use I2C IDs that are not defined.
> 
> My 2.4.22 patch simply wipe them out. I can't understand how they were
> accepted into the main kernel tree. I couldn't find anything related to
> them in the kernel changelog nor in LKML archives. I feel like we should
> complain about that, but unfortunately I don't have time for that right
> now. Greg, you have more contact with the kernel people than any of us
> here, do you have any information we don't have?
> 
> I am taking a new (well...) job tomorrow. At last :) I'm more than
> pleased, but you have to understand that this also means the end of my
> active participation to the LM Sensors project. Don't worry, I won't
> leave the project completely and within a few months I hope I'll have
> some time left again to contribute. But I won't spend 6 hours a day on
> it as it has been the case for the last few months. BTW, I'd like to
> thank you all very much for that. I've learned much here, and it also
> prevented me from falling into the laziness :)
> 
> See you later.
> 

2.4.22 kernel patches available

[Greg KH]

On Sun, Aug 31, 2003 at 05:27:30PM +0200, Jean Delvare wrote:
> 
> I noticed that new I2C drivers exist there: i2c-sibyte (plus
> i2c-algo-sibyte) and i2c-max1617. Why they end up there without us even
> hearing about it is a complete mystery to me. The max1617 driver is
> crappy (polling + working only with the sibyte bus) and completely
> useless since we already support that chip for years. The bus driver
> probably should have been built into a single module. And none of these
> modules will even compile since they use I2C IDs that are not defined.
> 
> My 2.4.22 patch simply wipe them out. I can't understand how they were
> accepted into the main kernel tree. I couldn't find anything related to
> them in the kernel changelog nor in LKML archives.

These all came in from the merge with the MIPS maintainer.  Bitkeeper is
nice :)

> I feel like we should complain about that, but unfortunately I don't
> have time for that right now. Greg, you have more contact with the
> kernel people than any of us here, do you have any information we
> don't have?

Why complain?  What is it hurting?  The cvs code sure isn't in the
kernel tree so what do we have to base our complaint on?  :)

So I'm guessing that some people with MIPS platforms actually use this
driver.  Good for them.  I would not recommend that your patches "wipe
them out" for that reason.

thanks,

greg k-h

2.4.22 kernel patches available

[Jean Delvare]

> On sybyte and max1617 we should try and find the authors and bring
> them into the fold.

The author is Kip Walker from Broadcom Corp., it seems. Googl'ing the
name should provide an e-mail address, but I admit I'm too busy to
contact him right now, and I hope that one of you will do so.

> On you moving on, hopefully you can find 1-2 hours a week for us which
> would still qualify you as "active"! We've appreciated your energy and
> enthusiasm(and new ideas) over the recent months, especially as it
> came when I was running out of all of those...

Finding a few hours a week won't be difficult, especially since I
*really like* contributing to the project. The real difficulty for now
is that I hardly have a place I can call home (although I *do* have a
flat now). Hopefully, I'll have brand new bed and fridge there within a
few days, a phone line and, even more important, power supply :) Once
all these are OK, I'll move there for good and you'll see more often
again.

> Any proposal for how to proceed with the 2.4 patch?

Release 2.8.1 (hi, Phil ;)), generate patches, post patches on LKML.
Wait and see.

Phil, I remind you that you don't have to bump the library's version, as
I already did.

> Without you to generate a 2.8.1->2.4.23 patch, what should we do?

There's no such thing as "without me". I won't let you down :) The patch
is almost already generated. The patches I made available for Linux
2.4.22 users will be OK for inclusion into Linux 2.4.23, with the
exception of the main patch that will have to be regenerated once i2c
2.8.1 is released. But that one is automatically generated, so that's
not a big problem.

The main concern IMHO are the new sibyte and max1617 drivers, that
really entered the tree at the worst possible time. I don't know exactly
what to do with them. Wiping them out is bad. But integrating them
correctly could take some more time. Suggestions welcome.

> And if you don't mind, what are you going to be doing for a living?

I've been hired as a development engineer (and that's great, because
that's what I just am). I'll be working in Paris (well, so near that
it's the same) and living there too (likewise, so near that's it's the
same, although that's not the same "so near", unfortunately). My first
task will be about web application development, using PHP 4 and a some
HTML/CSS design too.

> thanks again

You're more than welcome. Not sure who should thank the other here :)

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

2.4.22 kernel patches available

[Jean Delvare]

> > I noticed that new I2C drivers exist there: i2c-sibyte (plus
> > i2c-algo-sibyte) and i2c-max1617. Why they end up there without us
> > even hearing about it is a complete mystery to me. The max1617
> > driver is crappy (polling + working only with the sibyte bus) and
> > completely useless since we already support that chip for years. The
> > bus driver probably should have been built into a single module. And
> > none of these modules will even compile since they use I2C IDs that
> > are not defined.
> > 
> > My 2.4.22 patch simply wipe them out. I can't understand how they
> > were accepted into the main kernel tree. I couldn't find anything
> > related to them in the kernel changelog nor in LKML archives.
> 
> These all came in from the merge with the MIPS maintainer.  Bitkeeper
> is nice :)

Oh, OK. Not used to bitkeeper yet (and no time for this now).

> > I feel like we should complain about that, but unfortunately I don't
> > have time for that right now. Greg, you have more contact with the
> > kernel people than any of us here, do you have any information we
> > don't have?
> 
> Why complain?  What is it hurting?  The cvs code sure isn't in the
> kernel tree so what do we have to base our complaint on?  :)

The I2C architecture as we know it has been defined some years ago,
IIRC. And the i2c subsystem is regularly updated from our CVS repository
AFAIK (although it has been some time since it was last done). People
needing I2C IDs should know they have to ask. People wanting to write
I2C drivers should read our docs and follow the guidelines. Or why are
we writing docs?

> So I'm guessing that some people with MIPS platforms actually use this
> driver.  Good for them.  I would not recommend that your patches "wipe
> them out" for that reason.

I wiped them out because they would not *compile* and I don't want
people to think that our patch is faulty, while it isn't. I think that
we should preserve the sibyte driver (and algo). But I want the
i2c-max1617 driver out, because we *do* have a driver for that chip for
a very long time, which respects the overall architecture, with procfs
and libsensors support. So we just don't need another, poor max1617
driver.

We'll have to define the required IDs for the sibyte driver and algo
(BTW, shouldn't the algo be included into the driver? Is it likely to be
reused?), since that's them missing that prevent the modules from
compiling.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

2.4.22 kernel patches available

[Greg KH]

On Sun, Sep 07, 2003 at 06:21:30PM +0200, Jean Delvare wrote:
> > > I feel like we should complain about that, but unfortunately I don't
> > > have time for that right now. Greg, you have more contact with the
> > > kernel people than any of us here, do you have any information we
> > > don't have?
> > 
> > Why complain?  What is it hurting?  The cvs code sure isn't in the
> > kernel tree so what do we have to base our complaint on?  :)
> 
> The I2C architecture as we know it has been defined some years ago,
> IIRC.  And the i2c subsystem is regularly updated from our CVS repository
> AFAIK (although it has been some time since it was last done).

It has been quite a while for a 2.4 sync up, right?

> People needing I2C IDs should know they have to ask. People wanting to
> write I2C drivers should read our docs and follow the guidelines. Or
> why are we writing docs?

These docs are not in the kernel tree.  People are free to do what they
want with the kernel source.  Hence changes happen, deal with it, this
is normal :)

And as there hasn't been an active i2c kernel maintainer for a long
time, it's normal that others start to make changes to the code.

> > So I'm guessing that some people with MIPS platforms actually use this
> > driver.  Good for them.  I would not recommend that your patches "wipe
> > them out" for that reason.
> 
> I wiped them out because they would not *compile* and I don't want
> people to think that our patch is faulty, while it isn't.

How did you build these drivers?  They need a mips configuration and
probably cross compiler.  Did you do that or something else?

> I think that we should preserve the sibyte driver (and algo).

Agreed.

> But I want the i2c-max1617 driver out, because we *do* have a driver
> for that chip for a very long time, which respects the overall
> architecture, with procfs and libsensors support. So we just don't
> need another, poor max1617 driver.

As long as you don't break the in-kernel driver, that's fine with me.

But remember, the sysctl stuff is _not_ going into the main 2.4 kernel
tree (at least not through me...)  So I don't really know how a 2.4
merge will happen.

thanks,

greg k-h

2.4.22 kernel patches available

[Jean Delvare]

> > The I2C architecture as we know it has been defined some years ago,
> > IIRC.  And the i2c subsystem is regularly updated from our CVS
> > repository AFAIK (although it has been some time since it was last
> > done).
> 
> It has been quite a while for a 2.4 sync up, right?

Right. August 2001. Quite a while, as you say.

> > People needing I2C IDs should know they have to ask. People wanting
> > to write I2C drivers should read our docs and follow the guidelines.
> > Or why are we writing docs?
> 
> These docs are not in the kernel tree.  People are free to do what
> they want with the kernel source.  Hence changes happen, deal with it,
> this is normal :)

OK, I guess I got angry a bit fast, and would like to appologize for
that.

The docs *are* in the kernel tree. Exerpt from
linux-2.4.22/Documentation/i2c/writing-clients:

"The id should be a unique ID. The range 0xf000 to 0xffff is reserved
for
local use, and you can use one of those until you start distributing the
driver. Before you do that, contact the i2c authors to get your own
ID(s)."

If you think things should be made clearer, please suggest some changes
and we'll apply them.

> And as there hasn't been an active i2c kernel maintainer for a long
> time, it's normal that others start to make changes to the code.

May I volunteer to be listed as the maintainer? IIRC, Frodo's name is
still listed, while he hasn't been seen around for several months (if
not a few years). If I don't know anything about I2C, it's probably
better to have a maintainer with my level of knowledge than nobody at
all.

> > I wiped them out because they would not *compile* and I don't want
> > people to think that our patch is faulty, while it isn't.
> 
> How did you build these drivers?  They need a mips configuration and
> probably cross compiler.  Did you do that or something else?

I took a look at the code, because I knew I'd have to patch the drivers
so that they follow the new module usage count policy. I saw the IDs,
grep'd the whole source tree and saw they weren't defined anywhere. So I
*know* they wouldn't compile, no need to try.

> > I think that we should preserve the sibyte driver (and algo).
> 
> Agreed.

At least something we agreed on ;)

> > But I want the i2c-max1617 driver out, because we *do* have a driver
> > for that chip for a very long time, which respects the overall
> > architecture, with procfs and libsensors support. So we just don't
> > need another, poor max1617 driver.
> 
> As long as you don't break the in-kernel driver, that's fine with me.

Which basically means you suggest I should keep the i2c-max1617 driver
alive, at least until our own driver is integrated into the official
kernel tree (which, for the 2.4 tree, means: forever, since I don't
think we plan to have lm_sensors drivers integrated there). After some
thinking about it, it's OK for me.

> But remember, the sysctl stuff is _not_ going into the main 2.4 kernel
> tree (at least not through me...)  So I don't really know how a 2.4
> merge will happen.

Well, it will not happen. If it was to happen, that would be after
everyone has moved to Linux 2.6, and would then be pointless IMHO.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

2.4.22 kernel patches available

[Greg KH]

On Sat, Sep 13, 2003 at 10:53:10PM +0200, Jean Delvare wrote:
> > > People needing I2C IDs should know they have to ask. People wanting
> > > to write I2C drivers should read our docs and follow the guidelines.
> > > Or why are we writing docs?
> > 
> > These docs are not in the kernel tree.  People are free to do what
> > they want with the kernel source.  Hence changes happen, deal with it,
> > this is normal :)
> 
> OK, I guess I got angry a bit fast, and would like to appologize for
> that.
> 
> The docs *are* in the kernel tree. Exerpt from
> linux-2.4.22/Documentation/i2c/writing-clients:
> 
> "The id should be a unique ID. The range 0xf000 to 0xffff is reserved
> for
> local use, and you can use one of those until you start distributing the
> driver. Before you do that, contact the i2c authors to get your own
> ID(s)."
> 
> If you think things should be made clearer, please suggest some changes
> and we'll apply them.

Ah, missed that, sorry.

Hm, now why do we need ids anyway?  I've looked at the adapter ids, and
removed almost all usages of then in the 2.6 kernel as no one except
some video drivers used them.  I'll hack on the video drivers in some
point in the future to get rid of that id all together.

Do we do anything with client ids?

> > And as there hasn't been an active i2c kernel maintainer for a long
> > time, it's normal that others start to make changes to the code.
> 
> May I volunteer to be listed as the maintainer? IIRC, Frodo's name is
> still listed, while he hasn't been seen around for several months (if
> not a few years). If I don't know anything about I2C, it's probably
> better to have a maintainer with my level of knowledge than nobody at
> all.

Sure, send a patch.

thanks,

greg k-h

2.4.22 kernel patches available

[Jean Delvare]

> > The docs *are* in the kernel tree. Exerpt from
> > linux-2.4.22/Documentation/i2c/writing-clients:
> > 
> > "The id should be a unique ID. The range 0xf000 to 0xffff is
> > reserved for local use, and you can use one of those until you
> > start distributing the driver. Before you do that, contact the
> > i2c authors to get your own ID(s)."
> > 
> > If you think things should be made clearer, please suggest some
> > changes and we'll apply them.
> 
> Ah, missed that, sorry.
> 
> Hm, now why do we need ids anyway?  I've looked at the adapter ids,
> and removed almost all usages of then in the 2.6 kernel as no one
> except some video drivers used them.  I'll hack on the video drivers
> in some point in the future to get rid of that id all together.
> 
> Do we do anything with client ids?

No idea. I never dived deep enough in the i2c core. I remember someone
already wondered if they were used (maybe it was you already?), and
seeing how many kernel or third-party drivers use bad IDs, I wouldn't be
surprised if they were not used at all. Or maybe for debugging purposes?

> > May I volunteer to be listed as the maintainer? IIRC, Frodo's name
> > is still listed, while he hasn't been seen around for several
> > months (if not a few years). If I don't know anything about I2C,
> > it's probably better to have a maintainer with my level of
> > knowledge than nobody at all.
> 
> Sure, send a patch.

Mmm, you mean a patch to MAINTAINERS?

Whatever, I should first contact Simon Vogl and Frodo Looijaard to ask
them what they do think about it.

Will do that now, (CC'd to the list, of course).

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/