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: Wed, 29 Jan 2020 01:51:08 -0800 From: Guenter Roeck <linux@...ck-us.net> To: Logan Shaw <Logan.Shaw@...iedtelesis.co.nz>, "robh@...nel.org" <robh@...nel.org> Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Joshua Scott <Joshua.Scott@...iedtelesis.co.nz>, Chris Packham <Chris.Packham@...iedtelesis.co.nz>, "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>, "jdelvare@...e.com" <jdelvare@...e.com>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org> Subject: Re: [PATCH v6 2/2] dt-bindings: hwmon: (adt7475) Added missing adt7475 documentation On 1/28/20 8:30 PM, Logan Shaw wrote: > On Mon, 2020-01-27 at 09:48 -0600, Rob Herring wrote: >> On Mon, Jan 27, 2020 at 11:10:14AM +1300, Logan Shaw wrote: >>> Added a new file documenting the adt7475 devicetree and added the >>> four >>> new properties to it. >>> >>> Signed-off-by: Logan Shaw <logan.shaw@...iedtelesis.co.nz> >>> --- >>> --- >>> .../devicetree/bindings/hwmon/adt7475.yaml | 95 >>> +++++++++++++++++++ >>> 1 file changed, 95 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/hwmon/adt7475.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/hwmon/adt7475.yaml >>> b/Documentation/devicetree/bindings/hwmon/adt7475.yaml >>> new file mode 100644 >>> index 000000000000..450da5e66e07 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/hwmon/adt7475.yaml >>> @@ -0,0 +1,95 @@ >>> +# SPDX-License-Identifier: GPL-2.0 >> >> Dual license new bindings please: >> >> (GPL-2.0-only OR BSD-2-Clause) >> >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/adt7475.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: ADT7475 hwmon sensor >>> + >>> +maintainers: >>> + - Jean Delvare <jdelvare@...e.com> >>> + >>> +description: | >>> + The ADT7473, ADT7475, ADT7476, and ADT7490 are thermal monitors >>> and multiple >>> + PWN fan controllers. >>> + >>> + They support monitoring and controlling up to four fans (the >>> ADT7490 can only >>> + control up to three). They support reading a single on chip >>> temperature >>> + sensor and two off chip temperature sensors (the ADT7490 >>> additionally >>> + supports measuring up to three current external temperature >>> sensors with >>> + series resistance cancellation (SRC)). >>> + >>> + Datasheets: >>> + https://www.onsemi.com/pub/Collateral/ADT7473-D.PDF >>> + https://www.onsemi.com/pub/Collateral/ADT7475-D.PDF >>> + https://www.onsemi.com/pub/Collateral/ADT7476-D.PDF >>> + https://www.onsemi.com/pub/Collateral/ADT7490-D.PDF >>> + >>> + Description taken from omsemiconductors specification sheets, >>> with minor >> >> omsemi? >> ^ >> >>> + rephrasing. >>> + >>> +properties: >>> + compatible: >>> + enum: >>> + - adi,adt7473 >>> + - adi,adt7475 >>> + - adi,adt7476 >>> + - adi,adt7490 >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + bypass-attenuator-in0: >> >> Needs a vendor prefix and a type ref. > > Adi (Analog Devices) sold the ADT product line (amongst other things) > to On Semiconductor. As changing the vendor of these chips (in code) > would break backwards compatibility should we keep the vendor as adi? > > To confirm, would this make the property "adi,adt7476,bypass- > attenuator-in0"? > > So used in conjunction with patternProperties you would end up with > something like: > > "adi,(adt7473|adt7475|adt7476|adt7490),bypass-attenuator-in[0134]" > That seems highly unusual and would be quite messy to implement. I don't see the point of having the chip name in individual properties. Guenter >> >>> + description: | >>> + Configures bypassing the individual voltage input >>> + attenuator, on in0. This is supported on the ADT7476 and >>> ADT7490. >>> + If set to a non-zero integer the attenuator is bypassed, if >>> set to >>> + zero the attenuator is not bypassed. If the property is >>> absent then >>> + the config register is not modified. >> >> Sounds like this could be boolean? If not, define a schema for what >> are >> valid values. >> >>> + maxItems: 1 >>> + >>> + bypass-attenuator-in1: >>> + description: | >>> + Configures bypassing the individual voltage input >>> + attenuator, on in1. This is supported on the ADT7473, >>> ADT7475, >>> + ADT7476 and ADT7490. If set to a non-zero integer the >>> attenuator >>> + is bypassed, if set to zero the attenuator is not bypassed. >>> If the >>> + property is absent then the config register is not modified. >>> + maxItems: 1 >>> + >>> + bypass-attenuator-in3: >>> + description: | >>> + Configures bypassing the individual voltage input >>> + attenuator, on in3. This is supported on the ADT7476 and >>> ADT7490. >>> + If set to a non-zero integer the attenuator is bypassed, if >>> set to >>> + zero the attenuator is not bypassed. If the property is >>> absent then >>> + the config register is not modified. >>> + maxItems: 1 >>> + >>> + bypass-attenuator-in4: >> >> These 4 could be a single entry under patternProperties. >> >> >>> + description: | >>> + Configures bypassing the individual voltage input >>> + attenuator, on in4. This is supported on the ADT7476 and >>> ADT7490. >>> + If set to a non-zero integer the attenuator is bypassed, if >>> set to >>> + zero the attenuator is not bypassed. If the property is >>> absent then >>> + the config register is not modified. >>> + maxItems: 1 >>> + >>> +required: >>> + - compatible >>> + - reg >>> + >>> +examples: >>> + - | >>> + i2c { >>> + #address-cells = <1>; >>> + #size-cells = <0>; >>> + >>> + hwmon@2e { >>> + compatible = "adi,adt7476"; >>> + reg = <0x2e>; >>> + bypass-attenuator-in0 = <1>; >>> + bypass-attenuator-in1 = <0>; >>> + }; >>> + }; >>> +... >>> -- >>> 2.25.0 >>>
Powered by blists - more mailing lists