On 24 September 2014 21:52, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Wed, Sep 24, 2014 at 03:47:17PM -0400, Alan Stern wrote: >> On Wed, 24 Sep 2014, Pavel Machek wrote: >> >> > On Wed 2014-09-24 15:50:08, Krzysztof Kozlowski wrote: >> > > Add a simple getter pm_runtime_is_irq_safe() for quering whether runtime >> > > PM IRQ safe was set or not. >> > > >> > > Various bus drivers implementing runtime PM may use choose to suspend >> > > differently based on IRQ safeness status of child driver (e.g. do not >> > > unprepare the clock if IRQ safe is not set). >> > > >> > > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@xxxxxxxxxxx> >> > > Reviewed-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> >> > >> > Are you sure this is good interface? >> > >> > "Tell me if another function works this or that way". >> > >> > That's certainly not traditional interface, and it seems dangerous to >> > me. Callbacks now have different semantic requirements based on value >> > of some flag... >> > >> > Would it be possible to have two sets of callbacks, one irq safe and >> > one not? >> >> Or maybe add a flag to the bus-specific device structures, indicating >> specifically whether or not the clock should be unprepared during a >> runtime suspend. Then individual drivers could set this flag or not, >> independent of the irq-safe setting. > > What you're proposing is _less_ safe, because with your proposal, you > now have the possibility that drivers will tell runtime PM that it has > IRQ safe callbacks, but the bus code tries to prepare/unprepare the > clock, which causes a might-sleep-if warning. > > This is fragile. I agree. I would also like to feed another argument into this discussion on why I like the new API. Currently the generic power domain accesses "dev->power.irq_safe" directly. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
