Date:	Thu, 18 Jun 2015 15:14:31 +0200
From:	Andrzej Hajda <a.hajda@...sung.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	linux-arm-kernel@...ts.infradead.org,
	Alexander Holler <holler@...oftware.de>,
	Alexandre Courbot <gnurou@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Kumar Gala <galak@...eaurora.org>, Len Brown <lenb@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org, Lv Zheng <lv.zheng@...el.com>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Robert Moore <robert.moore@...el.com>,
	Rob Herring <robh+dt@...nel.org>,
	Russell King <linux@....linux.org.uk>,
	Stephen Warren <swarren@...dotorg.org>,
	Terje Bergström <tbergstrom@...dia.com>,
	Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH 00/13] Discover and probe dependencies

On 06/18/2015 12:36 PM, Mark Brown wrote:
> On Thu, Jun 18, 2015 at 11:42:01AM +0200, Andrzej Hajda wrote:
>
> There's something really messed up with how your mailer is word wrapping
> paragraphs, might want to check it out - it looks like it's making lines
> that are longer than 80 columns and then randomly breaking them 80
> columns in rather than reflowing things.
>
>> 3. Dependencies are mandatory, ie without it driver will not be able to
>> successfully finish
>> the probe.
>>     It should be not true. Sometimes device will require given resource
>> only in specific
>>     scenario, or it can still probe successfully and ask for the
>> resource later.
>>     I can also imagine that firmware can describe more information than
>> given driver require,
>>     some resources even if they are present in the dts, will be not
>> requested by the driver, it
>>     can be the case of drivers providing limited functionality, or just
>> obsolete bindings.
> Well, this isn't clear - the model here seems to be that the
> dependencies are those that are explicitly listed for a given platform.
> For those our current expectation is that we will try to control them
> and will defer probe until the resources that are mapped in on the
> platform are present so this doesn't seem like a change.
IMO current assumption is that we CAN TRY to control them
and we MAY defer probe until resource is present, nothing mandatory.

Lets look at more real example: we have HDMI encoder which can
use some video and audio resources provided by some video and audio
drivers. If we know that our machine will work without sound we can
disable audio drivers but we can expect video should still work, ie HDMI
driver should successfully probe even if audio resources are not available.

I had an impression that in this patchset the device wont be probed
until all dependencies are present, but after looking at the code it
does not seems to be true - in case dependency cannot be probed
warning will be printed but the probe will continue, so it should handle
scenario above properly. The only minor issue is that we will see
sometimes misleading message about missing dependencies.

Regards
Andrzej

--
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/

Powered by blists - more mailing lists