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