linux-kernel - Re: [RFD] Functional dependencies between devices

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: <5035713.rI4RnBEDVM@vostro.rjw.lan>
Date:	Sat, 31 Oct 2015 03:13:09 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Mark Brown <broonie@...nel.org>
Cc:	Linux PM list <linux-pm@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh@...nel.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Thierry Reding <treding@...dia.com>,
	Dmitry Torokhov <dtor@...gle.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Michael Turquette <mturquette@...libre.com>
Subject: Re: [RFD] Functional dependencies between devices

On Thursday, October 29, 2015 09:15:09 AM Mark Brown wrote:
> On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
> 
> > So, the question to everybody is whether or not this sounds reasonable or there
> > are concerns about it and if so what they are.  At this point I mostly need to
> > know if I'm not overlooking anything fundamental at the general level.
> 
> This seems like a good plan to me however I am concerned that only
> allowing links to be created at device registration time will prove
> restrictive - it means we're going to ignore anything we figure out
> later on in the boot sequence.

That's not the plan, though. :-)

I'm talking about device registration time or device probe time (for
dependencies that aren't known at the registration time).

> I would be very surprised if we didn't
> need that, either from things that get missed or from things that get
> allocated dynamically at runtime on systems with flexible hardware, and
> it'd also mean that systems can start to benefit from this for suspend
> and resume without needing the updates to the firmware parsing support.

The reason why I think it should be restricted to the probe/remove and
registration/unregistration times is because of PM.  More specifically,
adding a link to a "supplier" causes additional actions to be taken during
PM operations (eg. if the supplier device is suspended at the consumer device
resume time, it needs to be resumed in the runtime PM case or waited for in
the system resume case) which may be regarded as a change in a way PM is
handled.  Such changes are only expected to happen at the points I mentioned
and may lead to rather undesirable outcomes if made elsewhere.

Thanks,
Rafael

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)