public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Olivier Berger <oberger@ouvaton.org>
To: Thomas Renninger <trenn@suse.de>
Cc: linux-acpi@vger.kernel.org
Subject: Re: Incorrect ACPI blacklisting of ASUS P4B266 ?
Date: Tue, 28 Apr 2009 19:15:47 +0200	[thread overview]
Message-ID: <877i14aed8.fsf@olivierberger.com> (raw)
In-Reply-To: <200904281339.15689.trenn@suse.de> (Thomas Renninger's message of "Tue\, 28 Apr 2009 13\:39\:14 +0200")

Thomas Renninger <trenn@suse.de> writes:

>> 
>> That would be sad if the current blacklisting wasn't able to do such
>> checks on versions :(
> You could either:
>   1) add a whitelist into the blacklist
>   2) better limit the blacklist
> The first won't break machines, but is ugly.

I suppose some new algorithm would need to be written for that, and no easy
"struct definition" (like what is currently there) will be enough ?

> For the second you must know which BIOS(es) fix the acpi parts to not cause
> regressions and then list all broken BIOS revisions, e.g.:
> 	{
> 	 .callback = force_acpi_ht,
> 	 .ident = "ASUS P4B266",
> 	 .matches = {
> 		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
> 		     DMI_MATCH(DMI_BOARD_NAME, "P4B266"),
> 		     DMI_MATCH(DMI_BOARD_VERSION, "ASUS P4B266 ACPI BIOS Revision 1007"),
> 		     },
> 	 },
> 	{
> 	 .callback = force_acpi_ht,
> 	 .ident = "ASUS P4B266",
> 	 .matches = {
> 		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
> 		     DMI_MATCH(DMI_BOARD_NAME, "P4B266"),
> 		     DMI_MATCH(DMI_BOARD_VERSION, "ASUS P4B266 ACPI BIOS Revision 1008"),
> 		     },
> 	 },
>
> BTW, the same seem to have happened for the ASUS A7V:
> 	/*
> 	 * Boxes that need ACPI PCI IRQ routing disabled
> 	 */
> 	{
> 	 .callback = disable_acpi_irq,
> 	 .ident = "ASUS A7V",
> 	 .matches = {
> 		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC"),
> 		     DMI_MATCH(DMI_BOARD_NAME, "<A7V>"),
> 		     /* newer BIOS, Revision 1011, does work */
> 		     DMI_MATCH(DMI_BIOS_VERSION,
> 			       "ASUS A7V ACPI BIOS Revision 1007"),
> 		     },
> 	 },
>

Well, that lacks some version comparison operator to look clean to
me... which looks far from trivial considering the version formats
probably quite creative ;)

> One could argue that people have to upgrade to the latest BIOS
> and your patch is ok. This is IMO a valid argument, but it could be
> that people with a P4B266-SE board cannot upgrade to version 1010.
> I'd say, better leave the fingers off...

Yup.

>
>> Anyway, I suppose I will follow your advice and try and report people of
>> the acpi=force as I already started to do in
>> http://www.olivierberger.com/weblog/index.php?post/2009/03/28/Proper-power-management-on-Asus-P4B266-mainboard
> Everyone with such problems should easily be able to google the acpi=force
> param for this board then.
>

I'm thinking about some kind of warning message that might be provided
by the kernel.

Currently, the blacklisting issues something like : 
 xxx detected : force use of acpi=ht 

Maybe in some greylisted cases (like such ASUS P4B266), an additional
message may be issued, something like :
 xxx detected : may work with acpi=force (test at own risk)
or something like that ?


Btw, while we're at it, the first message is not so clear to me "force
use of acpi=ht" : I think it could be interpreted as "you may force ACPI
to work by passing acpi=ht" or something like that, as it tends to
indicate that it refers to an 'acpi=' parameter.

Maybe something like "forced 'ht' mode for acpi" or a similar variant
would be less ambiguous (pardon me, I'm not so sure what 'ht' means
here, btw).

Hope this helps,
-- 
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/

  reply	other threads:[~2009-04-28 17:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-28 15:32 Incorrect ACPI blacklisting of ASUS P4B266 ? Olivier Berger
     [not found] ` <200904021502.31021.trenn@suse.de>
2009-04-25 19:35   ` Olivier Berger
2009-04-27 10:18     ` Thomas Renninger
2009-04-28  6:09       ` Olivier Berger
2009-04-28 11:39         ` Thomas Renninger
2009-04-28 17:15           ` Olivier Berger [this message]
2009-04-28 17:56             ` Thomas Renninger
2009-04-30  4:22               ` Olivier Berger
2009-05-06  6:11                 ` Olivier Berger
2009-05-14 17:14               ` Len Brown
2009-05-17  7:38                 ` Olivier Berger
2009-05-22  5:52                   ` Olivier Berger
2009-05-14 17:18     ` Len Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877i14aed8.fsf@olivierberger.com \
    --to=oberger@ouvaton.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=trenn@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox