On Tue, 25 Jan 2005 22:40:51 +0100 Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Evgeniy & all, > > > > 1* This was 5 months ago. I'd expect Evgeniy's code to have > > > significantly evolved since, so an additional review now would > > > certainly be welcome. > > > > superio core was not changed much, all related changes were posted > > into lm_sensors mail list and discussed. > > Well, according to the mailing-list archives, which have a better memory > than I do, I skipped at least one: > > http://archives.andrew.net.au/lm-sensors/msg18655.html > > So I suspect that this update at least was never reviewed by anyone (on > the sensors list at least). I have one rule - if noone answers that it means noone objects, or it is not interesting for anyone, and thus noone objects. > And while we are at it, this post by Andrew is certainly of interest > too: > > http://archives.andrew.net.au/lm-sensors/msg18749.html I believe he commented connector patch mostly - we had some very little private discussion that time about it. I've posted connector patch several times to lkml - no answers except Alan Cox, thus noone objects but patch is very usefull. > > > 3* Some of my objections have been ignored by Evgeniy. Among others, > > > the choice of "sc" as a prefix for the superio stuff is definitely > > > poor and has to be changed. > > > > > > http://archives.andrew.net.au/lm-sensors/msg27847.html > > > > Yep %) > > SuperIO Control - is a good name, sio_ I've seen somewhere... > > Sure, sio would be better, or even superio in whole. Anything that > reminds "Super-I/O" is fine with me. sc doesn't. > > > GPIO and AccessBus are very simple devices, and I added them just > > because 1. people often asked exactly about GPIO > > 2. I had only GPIO and ACB to test. Actually I had a RTC and WDT too, > > but noone never asked in any mail list about them, but I think it > > worth to implement. > > > > Addind SuperIO itself does not have much sence that it can not be > > tested without at least one logical device, thus I added two. > > > > Porting existing SuperIO devices to the new schema is a very good > > task, but I had only SC1100 processor and PC87366 chip, so I created > > and tested superio chip drivers for them. > > The PC87366 has integrated sensors, some of which have to be connected > whatever your configuration: voltage inputs 7 to 10 and third > temperature channel. We have a driver for it in the kernel: > drivers/i2c/chips/pc87360. So if you have such a chip, this is actually > someone you can use as a test for your superio subsystem. Btw, they appeared almost the same time :) Difference was about several days... I have pc8736x logical devices in my TODO list, but they are currently preempted by acrypto, but I definitely will get it very soon. > If you can provide a patch which adds your superio core driver and one > which modifies the pc87360 driver to take make use of it, and only that, > this would certainly be easier for everyone (and especially me) to > review your superio code. Once this is in, incremental patches for the > additional features should be easier for you to generate and for the > rest of us to review. pc87360.c can not be used with superio as is, it requires big rewrite, since you implemented it as part of i2c core, that is why I created parts that was not touched by your driver. Since GPIO can be used with w1 it had greater priority. Your driver is part of i2c core, it just not supposed to be used in superio, although many hardware routings could be used. I will use it as a base for other superio logical devices. > Thanks, > -- > Jean Delvare > http://khali.linux-fr.org/ Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
