Re: [PATCH - 0/2] Identify native drivers and ACPI subsystem accessing the same resources

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Wednesday 18 July 2007 11:50:38 am Thomas Renninger wrote:
> On Fri, 2007-07-13 at 10:56 -0600, Bjorn Helgaas wrote:
> > The PNP core does not request resources for devices that are active
> > at boot.  Those resources currently don't get requested until a driver
> > claims the device.  I think this is a bug that we should fix.
> Yep, this is also a problem for the ACPI variables (in fact not really,
> as long as not overlapping like the rtc resource) and probably the
> reason why pnpacpi ignores addresses below 0x100?

By "ACPI variables," do you mean PM1a_EVT_BLK and the like?  Those
should be subsets of the _CRS resources for some device.

> IMO:
>   - Making sure ACPI claimed regions do not interfere with native
>     drivers is very important and will get much more important in near 
>     future

I agree with this.  I know some of these native drivers (lm-sensors, etc)
are pretty essential right now.  But they just aren't safe because they
use resources that ACPI thinks it owns.  I think the drivers should be
changed to explicitly override (with appropriate KERN_WARN messages)
any prior ACPI resource reservations.

> > >     The rtc driver seems to request the whole rtc space (0x70-0x77)
> > >     which fails because 0x72-0x73 has already been requested SHARED by
> > >     an ACPI SystemIO variable. At least parts of the rtc space got
> > >     requested (rtc0), I haven't checked whether the device was working
> > >     correctly...
> > 
> > I tripped over a couple of these when I changed the PNP core to request
> > resources for active devices.  The RTC is one; often BIOS says the RTC
> > is at 0x70-0x71 and 0x72-0x73, but the rtc drivers like to claim 0x8
> > (RTC_IO_EXTENT) ports.  However, I think the driver only *uses* two
> > ports, so we should change the driver to only request what it is
> > using.

> But there could be more?

I think the PNP core should request all the ports the device responds
to (as reported by the BIOS).  The driver should request only the ports
it uses.  If the rtc driver only uses two ports, there's no reason for
it to request all eight.

> Argggggh, normally it should be:
> 5000-50fe : ACPI PMIO
> ...
>   50c0-50df : pnp 00:07
>   50e0-50ff : pnp 00:07       # this one is missing because
>                               # it's bigger than the parent
>     50e0-50ef : amd756_smbus

IMO, this is backwards.  "pnp 00:07" should be the parent and should
be reserved by the PNP core.  A side-effect of this is that
drivers/pnp/system.c would not be needed at all.

> > > Summary:
> > > ...
> > >   - Not fixable (maybe someone has an idea): If ACPI IO region declares
> > >     a smaller IO part than the later native driver (e.g. example above
> > >     with rtc driver), the partially overlapping resource cannot be
> > >     registered and the native driver fails to load with strict and lax
> > >     option.
> > 
> > Assuming the BIOS describes the region correctly, I'd say a driver
> > that claims a larger region is buggy and should be fixed.
> 
> Yep, but a temporary solution where everything just works fine and a
> message: "This driver needs fixing" is needed IMO (if the code gets
> accepted... It's possible, but ...).

How about something like this:  We fix all the native drivers we know
about.  We make the PNP and ACPI cores request resources for all active
devices by default, but add a flag like "pnp=no_reservations" that turns
this off.  Then native drivers that request conflicting resources
will fail, but the user can limp along by using the boot-time option.

Bjorn


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/