# Matthias Drochner 2006-07-03:
> freza@dspfpga.com 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
>  states.

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

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

	-- Jachym