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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABkfQAGR=sPwhwL0ifqXpqCWKHZ_8pPj6Da_ugOQzFbvYbKdDg@mail.gmail.com>
Date:   Sat, 12 Dec 2020 23:43:49 +0100
From:   Adrien Grassein <adrien.grassein@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     lgirdwood@...il.com, Rob Herring <robh+dt@...nel.org>,
        linux-kernel@...r.kernel.org, DTML <devicetree@...r.kernel.org>,
        troy.kisky@...ndarydevices.com,
        Gary Bisson <gary.bisson@...ndarydevices.com>
Subject: Re: [PATCH v2 1/2] dt-bindings: regulator: add pf8x00 PMIC

Hello,

Le ven. 11 déc. 2020 à 15:04, Mark Brown <broonie@...nel.org> a écrit :
>
> On Thu, Dec 10, 2020 at 11:16:28PM +0100, Adrien Grassein wrote:
> > Add a devicetree binding documentation for the pf8x00 regulator driver.
>
> Please don't send new patches in reply to old threads, it makes it hard
> to keep track of what is going on.

Sorry. Should I create a new mail each time I send a new version of the patch?

>
> > +          regulator-name:
> > +            pattern: "^ldo[1-4]$"
> > +            description:
> > +              should be ldo1", ..., "ldo4"
>
> This is part of the generic regulator binding and since it's for board
> specific usage it should not be constrained by the chip binding.

Ok.
>
> > +          nxp,vselect-en:
> > +            $ref: /schemas/types.yaml#definitions/flag
> > +            description:
> > +              Only available for ldo2. When specified, use the VSELECT
> > +              input pin of the chip to control the output voltage of the
> > +              ldo02 regulator. (3.3V if VSELECT is LOW, 1.8V if HIGH).
>
> How is VSELECT used without a binding specifying some mechanism for
> control?

I think that VSELECT input should be controlled by the sub system that
uses it (via maybe a GPIO).
On my board, it's directly controlled by another chip (so without a GPIO).

>
> > +          nxp,ilim-microamp:
> > +            $ref: /schemas/types.yaml#definitions/uint32
> > +            minimum: 2100
> > +            maximum: 4500
> > +            default: 2100
> > +            enum: [ 2100, 2600, 3000, 4500 ]
> > +            description:
> > +              Defines the maximum current delivered by the regulator in microamp.
>
> Instead of implementing a custom property this should use the already
> existing properties for current limits, this is a common thing for
> hardware to have so we shouldn't have custom bindings.  We'll need to
> relax the check the code currently has for a non-zero minimum limit but
> otherwise everything should already be there.

Ok I now use "regulator-max-microamp" property from the regulator that
acts like my property.
I was wrong with the default value. I re-read the documentation and
the default value is stored in OTP
memory. So if someone skipped this property, it's OK to not send any value.


Thanks again,
Regards,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ