linux-kernel - Re: [PATCH 10/21] regulator: core: Probe regulators on demand

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:	Tue, 26 May 2015 08:17:23 +0200
From:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Stéphane Marchesin <stephane.marchesin@...il.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Alexander Holler <holler@...oftware.de>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 10/21] regulator: core: Probe regulators on demand

On 25 May 2015 at 19:32, Mark Brown <broonie@...nel.org> wrote:
> On Mon, May 25, 2015 at 04:53:14PM +0200, Tomeu Vizoso wrote:
>
>> When looking up a regulator through its DT node, ensure that the
>> corresponding device has been registered.
>
> I'm sorry but I'm going to need a much better changelog to review this
> patch.  I can't entirely tell what the intended effect is supposed to
> be, the subject line says we're probing things and the body says we're
> registering things which aren't the same thing at all.

Agreed, it would be more appropriate to say that we are registering
devices, I will make it clearer in the next revision. It ends up
probing the device at that point because we have made sure with an
earlier patch that all built-in drivers have been registered already.

>>               if (node) {
>> +                     of_platform_device_ensure(node);
>
> This function doesn't appear in git so I'm guessing that some other
> patch in the series adds it.  See my reply to the first patch...

Sorry about that, the series touches so many subsystems that I would
have reached the maximum number of recipients on the mailing lists I'm
sending it to. I will send it next with you and Krzysztof on CC on the
whole series.

> The obvious questions here based on the name are why we're doing
> something specific to platform devices and why this isn't something
> we're abstracting in the driver core (or at least generic firmware code)
> - we're going to have the same thing with ACPI.

I don't know how useful this is going to be in systems with ACPI. My
experience is limited to 32bit ARM, where the kernel has to manage
every regulator, clock, gpio, etc so the dependency tree is so big. Is
deferred probing a problem with ACPI as well?

Thanks,

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