> Doesn't it require a struct device* to be used? Yes but the sdhci port can be a device even if its wired via a controller which is its parent. The device layer is designed that way > > I cannot use the host controller struct because that may be using > dev_pm_ops for some other scheme. Such as ? > Then you must mean that it should be implemented in each and every > driver instead, like it is today. We had a long discussion about > that already. Why - it simply means you need the core to contain a library routine which is the default behaviour. This is how scsi works, how ATA works, etc for just about everything it does. Standardising something in the core code shouldn't mean hardwiring it to work that way or having a million copies of it. > Right now the way I see it the host driver can support > dev_pm_ops and simply call runtime_pm_put() when it recieves an > ios with clock frequency 0, so it's not like it contradicts > runtime PM. This makes sense - for one it means that devices with more complex rules - eg not being able to do card insertion detects with power off can handle it themselves. > > The plumbing used in runtime PM is however very applicable to the > task, so if it could be made to work in a subsystem without any > struct device* anchor, it would be very reusable. Is this > feasible? I think its the wrong question. The right question is why can't the device be used, and if not why can't it have subdevices as the device tree is meant to work (and runtime pm understands) -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
