Re: New ACPI power resource code for testing

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

On Mon, Mar 01, 2010 at 10:54:29AM -0800, Paul Goyette wrote:
> It would be misleading for the acpi_power device to report messages 
> (even if they are only DPRINTFs) that purport to come from another 
> device.  I think it would be better to simply use %s/__func__

Agreed.

> >>dependency with acpitz.  Is it conceivable that an acpitz can be fully
> >>functional without needing the acpipower device?  (I'm thinking of
> >>passive-only situations.)  If so, then the dependency should be removed.
> >
> >Yes, it is possible, even likely. Perhaps some autoconfiguration glue would
> >help here?
> 
> Well, since there isn't any way for our configuration tree to indicate 
> "sibling dependency", I would suggest moving the power stuff back into 
> the generic acpi framework rather than making it a separate device?

After thinking this and reading the intriguing discussions around the new
modularized world order, why this is a problem? In another words, the
"sibling dependency" you mentioned could perhaps be understood so that a
consumer (acpitz, etc.) depends on a producer (power resources).

As for ACPI generally, one could even play with an idea of providing
"pseudo" or "fake" HIDs (PNPxxxxs) for every component and then running them
all through autoconfiguration or a related procedure. Note that acpitz(4) is
not a conventional ACPI device node either (i.e. it lacks a _HID).

And well, this discussion touches also acpismbus(4); in the future some ACPI
driver may want to access iic(4) through it?

- Jukka.