LKML Archive on
help / color / mirror / Atom feed
From: Jean Delvare <>
To: Andrew Morton <>
Cc:, linux-acpi <>,
	linux-kernel <>,
	Len Brown <>,
	"Mark M. Hoffman" <>
Subject: Re: [PATCH 2/5] Provide acpi_check_{mem_}region.
Date: Sun, 10 Feb 2008 13:25:36 +0100	[thread overview]
Message-ID: <20080210132536.7c4d1cb1@hyperion.delvare> (raw)
In-Reply-To: <>

Hi Andrew,

On Thu, 7 Feb 2008 23:40:02 -0800, Andrew Morton wrote:
> On Wed, 24 Oct 2007 16:32:59 +0200 Thomas Renninger <> wrote:
> > Provide acpi_check_{mem_}region.
> > 
> > Drivers can additionally check against possible ACPI interference by also
> > invoking this shortly before they call request_region.
> > If -EBUSY is returned, the driver must not load.
> > Use acpi_enforce_resources=strict/lax/no options to:
> >   - strict: let conflicting drivers fail to load with an error message
> >   - lax:    let conflicting driver work normal with a warning message
> >   - no:     no functional change at all
> > 
> > 
> OK, so Len has merged these into the acpi test tree.  My understanding is
> that once this work hits mainline, we can then merge
> check-for-acpi-resource-conflicts-in-hwmon-drivers.patch.

Correct. Same applies to a second patch:
Both patches should be merged upstream at the same time.

> My normal approach would be to send
> check-for-acpi-resource-conflicts-in-hwmon-drivers.patch to Mark for
> inclusion in git-hwmon one Len has merged the prerequisites into mainline. 
> Problem is, if Len merges late in the 2.6.26 merge window, Mark might not
> have time to gets these changes into mainline before 2.6.27.  Which is all
> getting a bit dumb considering I first merged everything in October. 
> Fortunately things aren't mormally _this_ inefficient when one follows the
> rules - this was an unusual patchset.
> But still, I think we could afford to speed things up a bit more than that.
>  We could ask Len to consider merging this work into 2.6.25 and then if
> Mark can ack check-for-acpi-resource-conflicts-in-hwmon-drivers.patch
> (below) for an akpm-merge, we're good to go.  But I do recall that people
> were a bit uncertain about it all back in October.
> Please share your thoughts with us.

Len already merged all the acpi bits for 2.6.25 as far as I can see, so
all that is missing now is these two patches:
Both have been in -mm for quite some time.

In the default mode (acpi_enforce_resources=lax) these patches simply
print warnings but still let the drivers load, so they are safe to
merge, and the sooner, the better. The idea is to get feedback on how
many systems out there have ACPI resource conflicts. Then we'll see how
we can address them (if at all.)

I don't remember anyone objecting to these patches, and anyway the
problem has been there for years and nobody took care, so if anyone
really isn't happy with the solution designed by Thomas, that person
will have to do the work and submit something better later. That
shouldn't delay the merge of what we have now.

Andrew, both patches are

Acked-by: Jean Delvare <>

and I am totally fine with you pushing them to Linus now. But of course
having Mark's ack would be good too.

Jean Delvare

  parent reply	other threads:[~2008-02-10 12:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-24 14:32 Thomas Renninger
2008-02-08  7:40 ` Andrew Morton
2008-02-08  9:11   ` Thomas Renninger
2008-02-10 12:25   ` Jean Delvare [this message]
2008-02-11 19:55     ` Andrew Morton
2008-02-11 21:18       ` Jean Delvare
2008-02-13 13:45         ` Mark M. Hoffman

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:

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

  git send-email \
    --in-reply-to=20080210132536.7c4d1cb1@hyperion.delvare \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 2/5] Provide acpi_check_{mem_}region.' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).