All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, len.brown@intel.com,
	linux-acpi@vger.kernel.org
Subject: Re: [Ubuntu PATCH] acpi: Add IBM R60E laptop to proc-idle blacklist
Date: Tue, 20 Jun 2006 12:56:34 -0700	[thread overview]
Message-ID: <449852F2.7000704@oracle.com> (raw)
In-Reply-To: <20060620093016.GA27807@srcf.ucam.org>

Matthew Garrett wrote:
> On Mon, Jun 19, 2006 at 08:33:33PM -0700, Andrew Morton wrote:
>>> +	{ set_max_cstate, "IBM ThinkPad R40e", {
>>> +	  DMI_MATCH(DMI_BIOS_VENDOR, "IBM"),
>>> +	  DMI_MATCH(DMI_BIOS_VERSION, "1SET70WW") }, (void*)1},
> 
>> It seems that every R40e in the world is in that table.
>>
>> Can/should we wildcard it?  From my reading of dmi_check_system(), we can use
>> "" in place of the "1SET..." string and it'll dtrt?
> 
> Wouldn't that result in every machine with "IBM" as the BIOS vendor 
> having their maximum c-state limited?

Yes.  DMI_MATCH() specifies substring matching, so _if we knew_
that any BIOS version that began with "1SET4", "1SET5", "1SET6",
or "1SET7" needed C-state limiting, the table could be made a lot
smaller.  But then it may need some exceptions, so just sticking
with full version strings seems reasonable to me.

~Randy


      reply	other threads:[~2006-06-20 19:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-15 20:00 [Ubuntu PATCH] acpi: Add IBM R60E laptop to proc-idle blacklist Randy Dunlap
2006-06-20  3:33 ` Andrew Morton
2006-06-20  3:51   ` Ben Pfaff
2006-06-20  5:16     ` Randy.Dunlap
2006-06-20  9:30     ` Matthew Garrett
2006-06-20  9:30   ` Matthew Garrett
2006-06-20 19:56     ` Randy Dunlap [this message]

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=449852F2.7000704@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=akpm@osdl.org \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.