[RFC] acpi _CRS analyzation for PCMCIA resource management

[Dominik Brodowski]

On Sun, Mar 28, 2004 at 03:11:18PM +0100, Russell King wrote:
> On Sun, Mar 28, 2004 at 03:49:54PM +0200, Dominik Brodowski wrote:
> > One of the biggest challanges of 16-bit PCMCIA is to determine which 
> > resources (IO-ports and IO-memory) are available for PCMCIA cards. And as
> > Russell and others explained to me lately, even on so-called 
> > "legacy-free PCs", not all such resources are detectable, so whatever 
> > mentioned in /proc/ioports and /proc/iomem is only a guess...
> 
> I think this is something which should not be PCMCIA-centric.  Whenever
> we want to allocate a resource, whether it be PCMCIA or some other
> subsystem, we need this information available to us.

This is correct. However, on most systems I'm aware of [and that might be
quite x86-centric, I know...] PCMCIA is the only troublesome subsystem which
doesn't know nothing about resources.

> I therefore think it should be manipulating the kernels central resource
> manager rather than trying to produce some new separate database.

Also, manipulating the kernel's central resource manager is impossible for
the ACPI case: even though there's an ACPI name for each, let's say, PCI
object or serial port, in most cases there's no direct "pointer" from the
ACPI object to the linux kernel device object. And all device drivers would
need to become aware of ACPI then, and this is something we should try very
hard to avoid:

let's assume a resource are is marked as "consumed" by an ACPI _CRS object,
but it is not yet marked as "used" by the kernel's resource manager. If ACPI
then registers this resource as "pending/reserved", a subsequently loaded 
device driver which wants to register this resource, needs either to tell
ACPI to let it go [racy!], or register it as a subsequent resource -- which
means it needs to know much about ACPI. 

Not marking the resource as "used" is a no-go too: then PCMCIA would freely
access this space... So, I _currently_ see no other choice as to have 
the ACPI _CRS parser tell the PCMCIA subsystem of what resources to use
or not. This might change if the platform_data pointer in the driver model
is finally filled with life, as Patrick Mochel once intended to do...

	Dominik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20040328/8498caa5/attachment.bin