linux-kernel - Re: [PATCH 00/21] On-demand device registration

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, 11 Jun 2015 12:17:19 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Grant Likely <grant.likely@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
	open@...dq.ahsoftware,
	"list@...dq.ahsoftware:DRM PANEL DRIVERS" 
	<dri-devel@...ts.freedesktop.org>, dmaengine@...r.kernel.org,
	Dan Williams <dan.j.williams@...el.com>,
	"linux-usb@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH 00/21] On-demand device registration

Am 11.06.2015 um 10:12 schrieb Linus Walleij:
> On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler <holler@...oftware.de> wrote:
>> Am 10.06.2015 um 09:30 schrieb Linus Walleij:
>
>>> i2c host comes out, probes the regulator driver, regulator driver
>>> probes and then the regulator_get() call returns.
>>>
>>> This requires instrumentation on anything providing a resource
>>> to another driver like those I mentioned and a lot of overhead
>>> infrastructure, but I think it's the right approach. However I don't
>>> know if I would ever be able to pull that off myself, I know talk
>>> is cheap and I should show the code instead.
>>
>> You would end up with the same problem of deadlocks as currently, and you
>> would still need something ugly like the defered probe brutforce to avoid
>> them.
>
> Sorry I don't get that. Care to elaborate on why?

Because loading/initializing on demand doesn't give you any solved order 
of drivers to initialize. And it can't because it has no idea about the 
requirements of other drivers. The reason why it might work better in 
the case of the tegra is that it might give you another initialization 
order than the one which is currently choosen, which, by luck, might be 
a better one.

But maybe I missed something, I haven't looked at the patches at all. 
But just loading on demand, can't magically give you a working order of 
drivers to initialize. E.g. how do you choose the first driver to 
initialize?

Regards,

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