On Fri, 04 Jul 2008 14:02:26 +0200, Hans de Goede wrote: > Jean Delvare wrote: > > Hi Hans, > > > > On Thu, 03 Jul 2008 22:18:51 +0200, Hans de Goede wrote: > >> Alistair John Strachan wrote: > >>> After updating my BIOS (from 16 to 17) the driver has stopped loading > >>> again. This is with 2.6.26-rc8. The reason is that the command byte has > >>> changed value to 0xFF (this is reproducible across cold and warm starts). > >>> > >>> The following diff fixes it, but the "probe" is now looking even more creaky.. > >>> > >> Ah what fun, well luckily I've added the DMI based check so the detection > >> routine is less important now. > >> > >> Mark, please apply. > > > > I have to object. 0xff is the value you would get without a chip at > > this address. So the change is roughly equivalent to not testing the > > port at all... Plus, if the possible values change with every BIOS > > update, we have to admit that the detection method isn't reliable. What > > about switching to a DMI-based check? Not only checking the board > > manufacturer but also the board product name. The abituguru3 driver > > requires board-specific data anyway, so that's not a big change. And > > there's always the "force" parameter to bypass the check for new boards. > > > > I understand where you're coming from, but I have to object to switching to DMI > based detection. I would be happy to make that switch if and when I've got DMI > strings for all currently supporting motherboards. I can start working on > collecting those, but without those, switching to DMI based detection would > cause regressions which IMHO is unacceptable. > > I agree that the 0xff check is not pretty, but please keep in mind that: > 1) This driver normally is never autoloaded, so it either has to be compiled in > or explicitly loaded by the user (this is something where dmi based > detection would be a win as dmi based autoloading is possible). > > 2) If someone has either compiled the driver in and/or loads it deliberately it > will still only load (without the force parameter) on Abit motherboards. > > 3) After this simple read check, the driver does some reads from the chip > (which involve isa writes) and if these fail the driver doesn't load. Note > that these reads will most likely fail if there is no uguru3, as the uguru3 > has a quite complex handshaking scheme. > > So move to DMI based detection in the future, sure. But for now I would like to > see this patch applied. Hmm, OK. I thought that you had these DMI strings handy already. If not, please start collecting them now, so that the driver can be switched to DMI-based detection in the future. -- Jean Delvare
