Right, having a hook in pci_set_power_state() handles it all. Now,
there need to be some thinking about how to actually implement it
(when to call pcibios_set_power_state inside pci_set_power_state
and what result should it returns).
I see several options:
- Use it when the device has no PM capabilities
- Call it first, and depending on the result code, do the normal
PM or not, or eventually just fail.
- Call it last/first depending if entering a low power state or
exiting.
In my case, the device don't have PM caps, so I don't really care,
and it's the same for the other devices I have in mind that would
need it.
I still like the idea of implementing this as a function pointer
inside the pci_bus. In fact, the current implementation could be
done by filling this pointer with a default value, thus allowing
the arch to do any variation it may like by overriding this
pointer.
I keep having embedded in mind, where we have all sort of weird
designs (usually to save a few wires on a PLD) and flexibility is
fine when it doesn't add bloat. In this case, I beleive having
this notion of "pci_bus ops" for PM makes sense and is not bloat.
>Via is an exception
Yes, unless it's cascaded on a master interrupt controller. But
I agree the hard coding wasn't good, PPC is just so many different
boxes, they don't all have a nice device-tree or useable BIOS
residual datas :(
>Ok, agreed. There are always gonna be special case bridges, including
>(for my interest) multi-port NICs whose interfaces are presented as PCI
>devices downstream from a PCI-PCI bridge. Controlling power for these
>nics is sometimes done by messing around with the PM bits on the bridge,
>not on the downstream devices.
Ah, nice you see you agree ;)
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/