linux-kernel - Re: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in supplies

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: <20221031193810.vdsdndr4ltvhrfel@notapiano>
Date:   Mon, 31 Oct 2022 15:38:10 -0400
From:   Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>, kernel@...labora.com,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Liam Girdwood <lgirdwood@...il.com>,
        Oder Chiou <oder_chiou@...ltek.com>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in supplies

On Mon, Oct 31, 2022 at 02:09:38PM -0500, Rob Herring wrote:
> On Mon, Oct 31, 2022 at 12:31:40PM -0400, Nícolas F. R. A. Prado wrote:
> > On Mon, Oct 31, 2022 at 01:09:28PM +0000, Mark Brown wrote:
> > > On Fri, Oct 28, 2022 at 04:55:38PM -0400, Nícolas F. R. A. Prado wrote:
> > > 
> > > > @@ -35,6 +35,8 @@ const char *rt5682_supply_names[RT5682_NUM_SUPPLIES] = {
> > > >  	"AVDD",
> > > >  	"MICVDD",
> > > >  	"VBAT",
> > > > +	"dbvdd",
> > > > +	"ldo1-in",
> > > 
> > > Why are we making these inconsistent in style with the other supplies?
> > 
> > In short because the other supplies already have users while these are new ones.
> > My understanding was that new supplies should have lowercase names, following DT
> > convention. But I do see the argument on having them all be consistent for a
> > single driver/binding. If there are no remarks from Rob or Krzysztof I can
> > change it in the next version.
> 
> We want lowercase and consistency... Between the 2, I pick consistency.

We could have both if we converted the existing ones to lowercase first, but as
I mentioned in [1] this requires using devm_regulator_get_optional() before
falling back, which seemed like an abuse of that API and to unnecessarily
complicate the code.

So leaving the existing ones as they are and just keeping the consistency for
the new ones seems like the way forward.

[1] https://lore.kernel.org/all/20221028211224.iiphmwrpqqs27jr4@notapiano/

Thanks,
Nícolas