Re: [RFD] Functional dependencies between devices

From: Mark Brown <broonie@kernel.org>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux PM list <linux-pm@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Thierry Reding <treding@nvidia.com>,
	Dmitry Torokhov <dtor@google.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michael Turquette <mturquette@baylibre.com>
Subject: Re: [RFD] Functional dependencies between devices
Date: Tue, 17 Nov 2015 13:55:49 +0000	[thread overview]
Message-ID: <20151117135549.GR31303@sirena.org.uk> (raw)
In-Reply-To: <564B224D.3050904@samsung.com>

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:

> this scenario:
> - many clock providers, irq domains are not provided by devices,

That seems like something we can and possibly should change if we want.

> - there are also dependencies between clock providers, ie. some clock provider
> requires clocks provided by another clock provider, so the entity is also not a
> device driver,

This is going to be really common but I'm not sure I see a problem with
it in terms of what Raphael is proposing - could you go into more detail
on the problem you see here?

> - another case are requests for some additional/optional resources after device
> driver probe, for example phone usually does not require HDMI related resources
> until user attach HDMI cable,

Normally the drivers we need would all be loaded based on the hardware
we have in the system, it would be very unusual to dynamically request
new resources at runtime to deal with a reconfiguration.  Doing so seems
likely to result in fragility.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]