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

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

On Friday 13 July 2007 06:58:12 am Thomas Renninger wrote:
> This patch should:
> a) Identify machines where potentially ACPI interference can happen and
>    tell the user which legacy drivers are affected.
> b) Identify drivers/HW where we might need an ACPI driver in future
> c) If it works out (if not too much important drivers are affected)
>    enforce that native, non-ACPI drivers using the same IO/System
>    memory addresses as declared in ACPI namespace fail to load.

I like some of the ideas here, but as you say, there are some
issues to work out.

> There are two kind of IO/System memory declarations in ACPI ASL
> language: general variables and device specific resource
> declarations.
> The latter is already handled by pnpacpi and resources get requested 
> from pnpacpi already. These resources can (with this patch) partly
> already be requested by the general ACPI declarations and this patch
> should handle this gracefully.

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.

> ACPI drivers (e.g. pnpacpi and others) are allowed to request these
> resources (marked IORESOURCE_SHARED) through acpi_request_region().

I'm not a fan of IORESOURCE_SHARED.  I think that will make people
think it's acceptable to share a device between several drivers.  It
would be better to keep the ugliness of forcibly taking over a resource,
just as an incentive to clean up the drivers.

> Here two examples of not nice things that could happen with lax option:
> 
>  a) legacy drivers (in this case arch/x86_64/setup.c) request resources
>     before ACPI variables (shared resources) are requested:
> (/proc/ioports):
> 0080-008f : dma page reg
>   0080-0080 : ACPI DEB0*
>     In this case it's working as "dma page reg" includes the ACPI 
>     SystemIO variable's space. If the ACPI variable is bigger, I expect
>     the ACPI variable would not get inserted...

I think the best thing would be to reserve the PNP (including ACPI)
resources first, then the legacy things from setup.c.  I haven't looked
into that to see whether it's feasible.  Then you might have something
like this:

  0080-008f : 00:07 PNP0200
    0080-008f : dma page reg

>  b) A legacy driver requests resources bigger than the ACPI SystemIO 
>     variable, but the ACPI resource variable lies within the requested
>     space. Example:
> (/proc/ioports):
> 0070-0071 : rtc0
> 0072-0073 : ACPI KSB0*
> (syslog):
> IO region [rtc] conflicts with [ACPI KSB0].  Ignoring.., system might
> run unstable.
> rtc: I/O resource 70 is not free.
> 
>     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.

Another case is the "dma1" region from e820.c.  Currently this is
0x0-0x1f, but most PNP0c02 devices only respond from 0x10-0x1f.  So
I think we should start by splitting "dma1" into 0x0-0xf and 0x10-0x1f.

> Another issue that needs fix up is that the motherboad driver is not
> requesting it's resources anymore (which it still did with 2.6.18 - I
> didn't dig here anymore, maybe someone can comment why this has changed)

I don't know what's up here; I haven't looked at this recently.

> 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.

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/