linux-kernel - Re: [PATCH v8 3/5] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <1415088092.2389.12.camel@AMDC1943>
Date:	Tue, 04 Nov 2014 09:01:32 +0100
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Jonathan Corbet <corbet@....net>,
	Dan Williams <dan.j.williams@...el.com>,
	Vinod Koul <vinod.koul@...el.com>,
	Ulf Hansson <ulf.hansson@...aro.org>, linux-pm@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	dmaengine@...r.kernel.org, Lars-Peter Clausen <lars@...afoo.de>,
	Michal Simek <michal.simek@...inx.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH v8 3/5] amba: Don't unprepare the clocks if device driver
 wants IRQ safe runtime PM

On wto, 2014-11-04 at 02:57 +0100, Rafael J. Wysocki wrote:
> On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
> > On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
> > 
> > > That makes it pretty horrid from the point of view of having bus
> > > management code, because we now have the management of the bus clock
> > > split between the bus layer and the device driver.
> > > 
> > > This is /really/ a problem for runtime PM.  Runtime PM permits there
> > > to be a bus layer involved - and runtime PM can also be coupled up
> > > to PM domains as well.  For all this stuff, the context which the
> > > callbacks are called in depends on whether the driver itself has
> > > marked the device as having IRQ-safe callbacks.
> > > 
> > > That's fine, but the bus and PM domain level code then /really/ needs
> > > to know what context they're being called in, so they know whether
> > > they can sleep or not, or they must to be written to always use
> > > non-sleeping functions so they work in both contexts.  If we assume
> > > the former, then that implies that the irq-safe flag must never change
> > > state between a suspend and a resume.
> > 
> > If a bus subsystem or PM domain is going to allow its drivers to choose
> > between IRQ-safe and non-IRQ-safe runtime PM, then it is up to the
> > subsystem to come up with a way for drivers to indicate their choice.
> > 
> > I tend to agree with Rafael that testing dev->power.irq_safe should be 
> > good enough, with no real need for a wrapper.  But the subsystem can 
> > use a different mechanism if it wants.
> > 
> > Bear in mind, however, that once the irq_safe flag has been set, the 
> > runtime PM core offers no way to turn it off again.
> 
> There is a problem with it, though.  Say, a driver handles a device that
> may or may not be in a power domain.  Or in other words, the power domain
> the device is in may or may not be always on.  If the domain is always on,
> the runtime PM callbacks are IRQ-safe (they depend on the driver only).
> If it isn't, they may not be IRQ-safe.  How's the driver going to decide
> whether or not to set power.irq_safe?

The pl330 driver (being a part of amba bus) always wants IRQ safe
callbacks. However other amba drivers may not. So actually the driver
always sets one or another. The dualism is present only in the
amba/bus.c driver which encapsulates the child drivers.

Best regards,
Krzysztof


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/