linux-kernel - Re: [PATCH 00/13] Discover and probe dependencies

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]

Date:	Thu, 18 Jun 2015 15:49:34 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Andrzej Hajda <a.hajda@...sung.com>
Cc:	Mark Brown <broonie@...nel.org>,
	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>,
	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 Thu, Jun 18, 2015 at 03:14:31PM +0200, Andrzej Hajda wrote:
> 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.

That already happens today, if you structure the driver appropriately.
I really don't buy into the crap argument that "all struct device must
be created by DT" - it is perfectly acceptable for a device driver to
declare and register its own sub-devices where it's appropraite for it
to do so.

Since audio _requires_ video on HDMI to work (audio fundamentally
depends on a working video setup), it is perfectly acceptable for a
HDMI video driver to register a struct device for its audio driver,
and to pass details that the audio driver may need.

What is not acceptable is to duplicate the HDMI drivers device_node
into the child devices: this creates a situation where the generic
device model can match the HDMI driver with its child device.  So
this is a big no no.

The model I refer to above is something which I have, and others have
implemented for HDMI devices, and it's a completely reasonable model.

Remember, DT is about describing the hardware.  If you have a HDMI
encoder, that's one hardware block, and there should be one entry
describing it in DT.  Just because in Linux we may decide to separate
them into two separate drivers, and therefore two separate struct
device's is an implementation detail, and is not a reason to medle
with the hardware model in DT.

I think you may need to pick a better example to illustrate your point. :)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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/