On Mon, Jan 27, 2014 at 06:58:35AM -0800, Guenter Roeck wrote: > On 01/26/2014 04:32 PM, Mark Brown wrote: > >control at all. This means that if for some reason the regulator API is > >enabled on such a system it should assume that any supplies that devices > >need are provided by the system at all relevant times without any software > >intervention. > Couple of scenarios where I don't entirely see how this is expected to work. Please do note the above section of the commit log and in general try to understand what happens on systems which have full constraints. As you have been told you appear to have some substantial confusion in this area which is not helping. > - A system which uses CPU cards which sit on a carrier card. The CPU is shared > across multiple carrier cards, and built by an OEM. It supports and uses ACPI, > but ACPI only knows about the CPU card and not the carrier cards, and thus does > not know anything about the carrier card power or regulator requirements. Unless the support for the card says otherwise the system will assume that all power supplies are taken care of transparently in exactly the same way as it will for components on the motherboard. > - A system which supports a large number of complex OIR capable cards. > The card connector includes GPIO pins, I2C busses, PCIe busses, and various other > functionality such as SERDES lines. The card functionality is determined by the > card ID and not known by the time the system ships. Unless the support for the card says otherwise the system will assume that all power supplies are taken care of transparently in exactly the same way as it will for components on the motherboard. > - A USB-I2C or USB-SPI adapter connected to a standard PC. Any I2C or SPI device > can be connected to the I2C or SPI ports. Unless the support for the adaptor says otherwise the system will assume that all power supplies are taken care of transparently in exactly the same way as it will for components on the motherboard. > How is the firmware expected to know about the various devices ? Is the answer > "sorry, this scenario is not supported by the kernel" ? The firmware for the motherboard is not expected to know anything about the supplies for the various devices either on or off the motherboard, you will note that this change does not add any code to parse any data from the firmware (since that data does not exist).
Attachment:
signature.asc
Description: Digital signature
