i2c/sensors patch for 2.4.21 uploaded to my server....

i2c/sensors patch for 2.4.21 uploaded to my server....

[Steven J. Hill]

Greetings.

I just uploaded a clean patch against 2.4.21 that I have working
on my dual AMD boxen. I just took your last 2.4.20 stuff and
applied and fix a couple reject files. You can get it from here:

    ftp://ftp.realitydiluted.com/linux/i2c

Thanks for all your great work.

-Steve

i2c/sensors patch for 2.4.21 uploaded to my server....

[Jean Delvare]

> I just uploaded a clean patch against 2.4.21 that I have working
> on my dual AMD boxen. I just took your last 2.4.20 stuff and
> applied and fix a couple reject files. You can get it from here:
> 
>     ftp://ftp.realitydiluted.com/linux/i2c

We will generate new patches in a few weeks based on i2c and lm_sensors
2.8.0, actually right after 2.8.0 is released. There has been so much
change commited to CVS since 2.7.0 that this will be a hard work.

What would be of interest for us is to know if you encountered
difficulties while doing your patch. If yes, we are likely to encounter
the same difficulties too.

In the meantime, we could consider putting a link on our news page,
pointing to your patch, for interested users, unless someone has an
objection against this. My only objection would be on the patch name.
I'd better name it "sensors" than "i2c".

> Thanks for all your great work.

You're welcome.

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

i2c/sensors patch for 2.4.21 uploaded to my server....

[Steven J. Hill]

Jean Delvare wrote:
> 
> We will generate new patches in a few weeks based on i2c and lm_sensors
> 2.8.0, actually right after 2.8.0 is released. There has been so much
> change commited to CVS since 2.7.0 that this will be a hard work.
> 
> What would be of interest for us is to know if you encountered
> difficulties while doing your patch. If yes, we are likely to encounter
> the same difficulties too.
>
Yes, the following patches failed with the specific files:

     2.4.20-i2c-1-patch
       * drivers/i2c/Config.in
     2.4.20-i2c-2-patch
       * include/linux/i2c-id.h
       * include/linux/i2c.h

> In the meantime, we could consider putting a link on our news page,
> pointing to your patch, for interested users, unless someone has an
> objection against this. My only objection would be on the patch name.
> I'd better name it "sensors" than "i2c".
> 
I changed the name, but I also uploaded the corrected patches with the
2.4.21 prefix. All of the other 2.4.20 patches could be renamed with
the 2.4.21 prefix and new regeneration of the patches are unnecessary.

I also downloaded the 2.8.0 stuff and tested it out on my dual Athlon
machine. I have uploaded the 2.8.0 patches for 2.4.21 to my ftp site
as well. There were two modules, scx200_acb.c and scx200_i2c.c that did
not compile. These patches have also been uploaded. The link again is:

     ftp://ftp.realitydiluted.com/linux/i2c

-Steve

i2c/sensors patch for 2.4.21 uploaded to my server....

[Jean Delvare]

> I changed the name, but I also uploaded the corrected patches with the
> 2.4.21 prefix. All of the other 2.4.20 patches could be renamed with
> the 2.4.21 prefix and new regeneration of the patches are unnecessary.

It looks like the 2.4.21-i2c-sensors-patch.gz is older than the other
patches. You forgot to upload the new one, didn't you?

> I also downloaded the 2.8.0 stuff and tested it out on my dual Athlon
> machine. I have uploaded the 2.8.0 patches for 2.4.21 to my ftp site
> as well. There were two modules, scx200_acb.c and scx200_i2c.c that
> did not compile. These patches have also been uploaded. The link again
> is:
> 
>      ftp://ftp.realitydiluted.com/linux/i2c

I've added this link to our download page. Some things would need to be
clarified however:

1* I saw you added calls to MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT in
at least the SCx200 driver.Why that? The compatibility issue raised by
this release was caused by the use of these. Mark D. Studebaker told me
to get rid of them in all kernel drivers, what I did. So, what are we
really supposed to do? Mark, I'd like to hear you on this.

2* It isn't clear what each of your patch does. I'd appreciate a list
that says which patch changes which files, and in which way.

We now have our own patch set for i2c-2.8.0 (we don't have any for
lm_sensors-2.8.0 yet though.) I'd like you to take a look at my page
that explains in detail what the patches do and why they are necessary.
In a way, I guess we made some common work, and trying to compare what
you and I did should be interesting:

    http://www.ensicaen.ismra.fr/~delvare/devel/i2c/

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

i2c/sensors patch for 2.4.21 uploaded to my server....

[Jean Delvare]

> The rule is, "modules aren't supposed to change their own usage count"
> so you shouldn't use MOD_xxx_USE_COUNT.
> All the usage counts are changed in i2c-core now.
> That's what caused all the struct changes.

Why are these macros still defined if nobody should use them anymore?

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

i2c/sensors patch for 2.4.21 uploaded to my server....

[Mark D. Studebaker]

The rule is, "modules aren't supposed to change their own usage count"
so you shouldn't use MOD_xxx_USE_COUNT.
All the usage counts are changed in i2c-core now.
That's what caused all the struct changes.

Jean Delvare wrote:
>>I changed the name, but I also uploaded the corrected patches with the
>>2.4.21 prefix. All of the other 2.4.20 patches could be renamed with
>>the 2.4.21 prefix and new regeneration of the patches are unnecessary.
> 
> 
> It looks like the 2.4.21-i2c-sensors-patch.gz is older than the other
> patches. You forgot to upload the new one, didn't you?
> 
> 
>>I also downloaded the 2.8.0 stuff and tested it out on my dual Athlon
>>machine. I have uploaded the 2.8.0 patches for 2.4.21 to my ftp site
>>as well. There were two modules, scx200_acb.c and scx200_i2c.c that
>>did not compile. These patches have also been uploaded. The link again
>>is:
>>
>>     ftp://ftp.realitydiluted.com/linux/i2c
> 
> 
> I've added this link to our download page. Some things would need to be
> clarified however:
> 
> 1* I saw you added calls to MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT in
> at least the SCx200 driver.Why that? The compatibility issue raised by
> this release was caused by the use of these. Mark D. Studebaker told me
> to get rid of them in all kernel drivers, what I did. So, what are we
> really supposed to do? Mark, I'd like to hear you on this.
>

i2c/sensors patch for 2.4.21 uploaded to my server....

[Jean Delvare]

> Okay, so I uploaded a new patch against 2.4.21 to remove the
> macros and the inc_use/dec_use from the scx200 modules. I
> also downloaded 2.4.22-pre8 and noticed that these function
> pointers still have not been fixed been removed from the main
> i2c headers.

And they won't until we submit a patch for integration of i2c-2.8.0 into
Linux 2.4. We plan to submit a patch right after 2.4.22 is released.

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

i2c/sensors patch for 2.4.21 uploaded to my server....

[Steven J. Hill]

Mark D. Studebaker wrote:
> The rule is, "modules aren't supposed to change their own usage count"
> so you shouldn't use MOD_xxx_USE_COUNT.
> All the usage counts are changed in i2c-core now.
> That's what caused all the struct changes.
> 
Okay, so I uploaded a new patch against 2.4.21 to remove the
macros and the inc_use/dec_use from the scx200 modules. I
also downloaded 2.4.22-pre8 and noticed that these function
pointers still have not been fixed been removed from the main
i2c headers. Anyway, the patches for 2.8.0 against 2.4.21 are
up there and I will be quiet now :).

    ftp://ftp.realitydiluted.com/linux/i2c

-Steve