linux-kernel - Re: [PATCH] regulator: core: add of_match_full

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] [day] [month] [year] [list]

Message-ID: <20200820171104.GF5854@sirena.org.uk>
Date:   Thu, 20 Aug 2020 18:11:04 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Cristian Marussi <cristian.marussi@....com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: core: add of_match_full_name boolean flag

On Thu, Aug 20, 2020 at 05:38:44PM +0100, Cristian Marussi wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> On Wed, Aug 19, 2020 at 07:22:45PM +0100, Mark Brown wrote:
> > On Wed, Aug 19, 2020 at 03:04:48PM +0100, Cristian Marussi wrote:

> > > In this case the above matching mechanism based on the simple (common) name
> > > will fail and the only viable alternative would be to properly define the
> > > deprecrated 'regulator-compatible' property equal to the full name
> > > <common-name>@<unit>.

> > This seems like a massive jump.  You appear to be saying that the reg
> > property is unusable which doesn't seem right to me?

> The 'issue' I observed while working on another series was that with the
> following example DT:

...

> the regulator framework standard initialization routines were able to match univocally the
> first two regulators above (and parse autonomously the constraints without me explicitly
> calling of_get_regulator_init_data() as in a previous version of the series), but got fooled

My point is that your jump to "this is the only possible approach" seems
to suggest we can't involve the reg property in the matching which like
I say doesn't seem right.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)