Dino Klein | 1 Feb 2004 01:28
Picon
Favicon

ACPI and the PNP Layer

Hello everyone,
I am curious to know whether there is supposed to be a relationship between 
ACPI and the PNP layer in Linux, i.e. should the devices found through ACPI 
be registered with the PNP layer, or will the PNP layer itself be supplanted 
on ACPI based machines?

The reason I'm asking is because I'm toying with the idea of writing a 
protocol driver that will "export" devices from ACPI to the PNP layer. Would 
this be a more "proper" scheme of dealing with devices, instead of having 
each driver modified to register with the ACPI bus (serial driver style)? 
Wouldn't placing devices in the PNP layer make it more transparent for 
drivers to bind to devices, whether the machine supports ACPI, or only 
PNPBIOS?

Thanks.

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
Matthew Wilcox | 1 Feb 2004 02:43
Picon
Favicon

Re: ACPI and the PNP Layer

On Sun, Feb 01, 2004 at 12:28:27AM +0000, Dino Klein wrote:
> I am curious to know whether there is supposed to be a relationship between 
> ACPI and the PNP layer in Linux, i.e. should the devices found through ACPI 
> be registered with the PNP layer, or will the PNP layer itself be 
> supplanted on ACPI based machines?

PNP is unnecessary on machines with ACPI.

> The reason I'm asking is because I'm toying with the idea of writing a 
> protocol driver that will "export" devices from ACPI to the PNP layer. 
> Would this be a more "proper" scheme of dealing with devices, instead of 
> having each driver modified to register with the ACPI bus (serial driver 
> style)? Wouldn't placing devices in the PNP layer make it more transparent 
> for drivers to bind to devices, whether the machine supports ACPI, or only 
> PNPBIOS?

I think there's a fundamental mistake here, which is that drivers need
to be modified to deal with ACPI.  The serial driver (I'm the original
author of the 8250_acpi code) needed to be modified to discover serial
devices in the ACPI namespace.  This is because HP's ia64 machines are
legacy-free, so do not have serial ports at 0x3f8 and 0x2f8 (or wherever
...) like PCs.  Some of HP's machines have PCI serial ports which need
no additional code, but others have what are called 'PDH UARTs' which
can only be discovered by looking in the ACPI namespace.

Obviously no ia64 machine will support ISAPNP or PNPBIOS, so your proposal
wouldn't work very well.  It's also not a lot of code -- 4934 bytes for
8250_acpi.c versus 12488 bytes for 8250_pnp.c.  I can't think of any other
"legacy devices in non-legacy positions" situations like this.  Can you?

(Continue reading)


Gmane