linux-kernel - Re: [GIT PULL] On-demand device probing

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: <1445258870.53393.173.camel@infradead.org>
Date:	Mon, 19 Oct 2015 13:47:50 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Rob Herring <robh+dt@...nel.org>
Cc:	Mark Brown <broonie@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Russell King <linux@....linux.org.uk>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Vinod Koul <vinod.koul@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Thierry Reding <thierry.reding@...il.com>,
	David Airlie <airlied@...ux.ie>,
	Terje Bergström <tbergstrom@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Wolfram Sang <wsa@...-dreams.de>,
	Frank Rowand <frowand.list@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Kishon Vijay Abraham I <kishon@...com>,
	Sebastian Reichel <sre@...nel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Felipe Balbi <balbi@...com>, Jingoo Han <jingoohan1@...il.com>,
	Lee Jones <lee.jones@...aro.org>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-clk@...r.kernel.org, dmaengine@...r.kernel.org,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux PWM List <linux-pwm@...r.kernel.org>,
	Linux USB List <linux-usb@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>
Subject: Re: [GIT PULL] On-demand device probing

On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
> 
> > Certainly, if it literally is adding of_* calls then that would seem to
> > be gratuitously firmware-specific. Nothing should be using those these
> > days; any new code should be using the generic device property APIs
> > (except in special cases).
> 
> See version 2 of the series[1] which did that. It became obvious that
> was pointless because the call paths ended up looking like this:
> 
> Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
> of_probe_device

You link to a thread which says that "AT LEAST CURRENTLY, the calling
locations [the 'DT look-up code' you mention above] are DT specific
functions anyway.

But the point I'm making is that we are working towards *fixing* that,
and *not* using DT-specific code in places where we should be using the
generic APIs.

Sure, Russell is probably right that there are some places where the
generic APIs need fixing because they don't quite cover all use cases
yet.

And Mark is (unfortunately) right that some people are inventing new
bindings *purely* for ACPI which are different to the DT bindings for
the same device. But still, in those cases you'll theoretically be able
to see the *same* device represented under ACPI with *either* its new
ACPI HID and the ACPI-specific bindings, *or* as a PRP0001 with the DT
bindings. And this was always possible even with just DT — you could
have two incompatible bindings for the *same* hardware, with different
drivers. It was just a bad thing. And still is when one is ACPI and one
is DT, in my opinion.

None of that really negates that fact that we are *working* on cleaning
these code paths up to be firmware-agnostic, and the fact that we
haven't got to this one *yet* isn't necessarily a good reason to make
it *worse* by adding new firmware-specificity to it.

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5691 bytes)