Subject: Re: device tree traversal
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: Jachym Holecek <email@example.com>
Date: 07/04/2006 13:59:24
# Matthias Drochner 2006-07-03:
> firstname.lastname@example.org said:
> > This will be needed for proper powerhooks
> In the PCI case, I don't think traversing the (logical)
> device list is the right thing to to. What we need is
> to traverse the physical list. And this can only be done
> by the bus drivers theirselfes.
> Some reasons:
> -On a shared bus, all devices need to support a certain
> low-power state before the bus can be stopped, powered
> down or so. _All_ devices, not just these we have drivers
> attached for. The bus driver might also find out a
> common denominator at the beginning and handle individual
> devices later.
I suspect what we really want here is to have 'struct device'
for each _physical_ device -- some of them will ("optionally")
have a driver attached to them. This starts to make even more
sense when you consider loading drivers at runtime (lkm).
This idea is not mine and I believe it's on someone's TODO
list already ;-).
> -In PCI PM, most things can be done centrally. All the
> wakeup stuff and config register saving which is now
> in powerhooks shouldn't be there. So a call to the PCI
> device driver should be only done if the driver requests
> this. (There is a bit in the PCI PM capability which tells
> whether special driver assistance is needed. If this is
> set and the driver didn't register a hook, this would be
> an error.
I think that (assuming the above) this could be solved without
too much pain with device_iterator_*()-based powerhooks.
> -The namespace for PCI device power states is different
> from the PCI bus one, and that of ACPI. For sanity, I
> wouldn't try to hide this behind global names. The bus driver
> can well translate bus power states into device power
I was coming to the same conclusion. We can have two mandatory
power states ("fully on"/"fully off"), with bus/device/... specific
set of intermediate states. All we need then is the ability to
announce a list of supported states for given device to the user
(simple enough with proplib ;).
> (And as said, this is not just translation but rather
Yes -- the iterator API I'm proposing is supposed to be a tool for
PM hooks (and other purposes), rather then "the whole thing itself".