public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Thomas Renninger <trenn@suse.de>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
	Zhao Yakui <yakui.zhao@intel.com>, Len Brown <lenb@kernel.org>,
	Peter Mahlknecht <mali100@gmx.net>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: ACPI reads wrong temperature
Date: Thu, 13 Nov 2008 11:24:11 +0100	[thread overview]
Message-ID: <20081113112411.009fc89c@hyperion.delvare> (raw)
In-Reply-To: <200811121620.44520.trenn@suse.de>

Hi Thomas,

On Wed, 12 Nov 2008 16:20:43 -0600, Thomas Renninger wrote:
> On Thursday 06 November 2008 03:11:26 am Matthew Garrett wrote:
> > On Thu, Nov 06, 2008 at 02:12:52PM +0800, Zhao Yakui wrote:
> > > On your box after the i2c-i801 driver is loaded, the smbus controller
> > > will be used by the AML code and i2c-i801 driver. Unfortunately there is
> > > no synchronization between them. IMO this is the BIOS fault. The SMbus
> > > will be accessed by the two different modules. But it is exported by
> > > BIOS.
> >
> > No, loading i2c-i801 is harmless. The breakage occurs when you attempt
> > to drive the smbus.
> >
> > >     So the better solution is that:
> > >     a. SMBus is hidden in BIOS. In such case the Linux OS can't detect
> > > the SMbus controller . Of course it won't try to load the device driver
> > > for it.
> > >     b. Linux OS won't load the device driver for it.
> >
> > The solution is for users not to load smbus drivers unless they know for
> > certain that it's safe to do so, or alternatively for us to refuse to

Except that all these drivers auto-load, so the user doesn't actually
get to verify anything beforehand. Nor do I believe they should have
to. If there's a way for the user to verify that loading the driver is
safe then the same check can be added to the driver itself. Which, as
Thomas explained, is partly implemented, just not yet enforced.

> > load i2c drivers if they overlap with ACPI resource allocations.
> 
> We already have that:
> >  or alternatively for us to refuse to load i2c drivers
> in drivers/acpi/osl.c:
> 
> #define ENFORCE_RESOURCES_STRICT 2
> #define ENFORCE_RESOURCES_LAX    1
> #define ENFORCE_RESOURCES_NO     0
> 
> static unsigned int acpi_enforce_resources = ENFORCE_RESOURCES_LAX;
> 
> lax means print out warning which i2c driver conflicts with which ACPI 
> Operation Region.
> Did you get such a message:
> printk("%sACPI: %s resource %s [0x%llx-0x%llx]"
>                                " conflicts with ACPI region %s"
>                                " [0x%llx-0x%llx]\n",
>                                acpi_enforce_resources == ENFORCE_RESOURCES_LAX
>                                ? KERN_WARNING : KERN_ERR,
>                                ioport ? "I/O" : "Memory", res->name,
>                                (long long) res->start, (long long) res->end,
>                                res_list_elem->name,
>                                (long long) res_list_elem->start,
>                                (long long) res_list_elem->end);
> 
> If not, probably this specific i2c driver has to be added to check it's 
> resources against ACPI used Operation Regions.
> 
> Jean: Could you add that if necessary, pls.
> This is the whole thread:
> http://marc.info/?t=122546192400002&r=1&w=2

The i2c-i801 driver already has this check.

The exact same issue (reported by the same person) was already
discussed on the lm-sensors list:
http://lists.lm-sensors.org/pipermail/lm-sensors/2008-October/024608.html
http://lists.lm-sensors.org/pipermail/lm-sensors/2008-November/024610.html

With the same conclusion, i.e. i2c-i801 should be blacklisted on that
specific model, or acpi_enforce_resources=strict should be used. Or the
BIOS should hide the SMBus, that would be even better.

-- 
Jean Delvare

      parent reply	other threads:[~2008-11-13 10:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-31 14:02 ACPI reads wrong temperature Peter Mahlknecht
2008-10-31 14:30 ` Matthew Garrett
2008-10-31 21:09   ` Peter Mahlknecht
2008-11-02  9:25     ` Matthew Garrett
2008-11-02 11:31       ` Peter Mahlknecht
2008-11-03  2:05         ` Zhao Yakui
2008-11-03  9:01           ` Peter Mahlknecht
2008-11-03 14:50             ` Zhao, Yakui
2008-11-03 14:57               ` Matthew Garrett
2008-11-03 17:47                 ` Len Brown
2008-11-03 17:48                   ` Matthew Garrett
2008-11-06  6:12                     ` Zhao Yakui
2008-11-06  9:11                       ` Matthew Garrett
2008-11-12 22:20                         ` Thomas Renninger
2008-11-12 22:27                           ` Matthew Garrett
2008-11-13 10:24                           ` Jean Delvare [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=20081113112411.009fc89c@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mali100@gmx.net \
    --cc=mjg59@srcf.ucam.org \
    --cc=trenn@suse.de \
    --cc=yakui.zhao@intel.com \
    /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