Sounds good to me. Phil On Mon, Sep 09, 2002 at 08:42:20PM -0400, Mark D. Studebaker wrote: > Here's my proposal. > > I would like to do the 2.6.5 release as-is this week and then submit it > to Alan, > for two reasons: > - what we have in CVS is much safer for Thinkpad and 24RF08 users than > what > is in 2.6.4; we should make it available even if it is an incremental > improvement and not a perfect fix; > - it's much easier for tracking if we submit releases rather than CVS > stuff to Alan. > > We are all agreed that what we have is not bulletproof and that we > shouldn't > claim it is. > > Let's plan on addressing whatever concerns Alan may have, together > with incorporating any further info we get from IBM, in 2.6.6. > Also in that release incorporating locking or i2c-core tweaks if > that makes sense. > > As long as we are working with Alan and trying to get into 2.5 we should > try and have a release interval of about 4 weeks or less so we can be > responsive. > > thoughts? > > phil at netroedge.com wrote: > > > > On Mon, Sep 09, 2002 at 11:18:44AM +0300, Ky?sti M?lkki wrote: > > >[...] > > > > > > However I do not consider current situation very satisfactory: > > > > > > 1. Blacklisting by DMI data does not catch new models beforehand. > > > > Pam claims all current and future models will not use this chip (at > > least on Thinkpads). > > > > > 2. IBM systems with other than PIIX4 are compromised if admin does not > > > run and/or believe sensors-detect warnings and is unaware of the issue. > > > > Yes, there are still configurations which exist which make it possible > > for this problem to crop up again. I worry particularly about other > > chips which may react negatively to probing. > > > > > 3. If #1 or #2 happens, every existing client driver probing around > > > 0x54-0x57 needs a workaround. Including video4linux(2) drivers from > > > several sources, and any app using the char device. > > > > > > I think patching i2c-core to add extra Write Quick within the critical > > > section is safe and easy way to handle those issues. This leaves only > > > multi-master topologies vulnerable. What do the SMBus specs say, can a > > > laptop share SMBus with a docking station, charger etc ? > > > > I'm wary of changing the code at quite that low of a level. I think > > it's good we tweaked sensors-detect to do what it can to work around > > the issue. It's also nice to have the blacklist in effect as a > > temporary measure until testing is completed. > > > > Past that, I think we should stay out of most kernel code (with > > exception to the blacklisting code). What we most definitely do not > > want to do is change the operation of the code to make it work in an > > unexpected way for developers (e.g. having quick writes get duplicated > > for certain addresses and such). > > > > It's a balance between practicality and technical 'correctness'. I'd > > like to keep things as technically correct as possible. If a chip or > > mobo has a broken design, then it's the problem of the manufacturer. > > In practicality, it is nessesary for us to do what we can to make it > > safe for users, but I don't want to move away from having the code > > work as expected simply to work around someone else's broken hardware > > design. > > > > Phil > > > > -- > > Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR > > phil at netroedge.com -- http://www.netroedge.com/~phil > > PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A -- Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR phil at netroedge.com -- http://www.netroedge.com/~phil PGP F16: 01 D2 FD 01 B5 46 F4 F0 3A 8B 9D 7E 14 7F FB 7A
