On Thursday 15 January 2009 15:22:45 Jean Delvare wrote:
> > (One remaining question would be whether patch 1 should be CCed to
> > -stable, since there has been a regression introduced into 2.6.27 and
> > present in 2.6.28 for some BIOS revisions of the IP35 Pro.)
>
> Is there really a regression? If the DMI matching doesn't work, we fall
> back to the old detection method, so I can't see how there would be a
> regression. Care to explain?
Having looked at this properly I agree. It's clear that in this bug report
what actually happened was the DMI match failed, AND the probe routine failed.
This definitely puts the final nail in the coffin of manual probing,
especially on the IP35 Pro (which was where all these changes originated
from).
Sorry for the confusion, you are correct, and there is no way this could be
considered a regression. I had just extrapolated that from the original
poster, but it must be the case that it has never worked, or worked
unreliably.
> Speaking of DMI matching... If DMI is disabled, we do:
>
> static inline int abituguru3_dmi_detect(void)
> {
> return -ENODEV;
> }
>
> And this error value causes abituguru3_init() to bail out. Unless I'm
> missing something, the abituguru3 driver is simply useless without DMI
> support at the moment. We should either make that official and make the
> driver depend on DMI at Kconfig level, or change
> abituguru3_dmi_detect() to return 1, so that we fallback to the old
> detection method. Opinions?
It should return 1. This is simply a blunder. Fortunately CONFIG_DMI is quite
difficult to turn off, and no distribution would. I'll follow up to this email
with a proper patch.
Apologies for the mistakes..
--
Cheers,
Alistair.
