linux-kernel - Re: [PATCH v3 1/3] dt-bindings: iio: adc: sophgo,cv18xx-saradc.yaml: Add Sophgo SARADC binding documentation

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: <4dc17f0c-557b-443b-a6cf-840b1b848b6f@kernel.org>
Date: Mon, 5 Aug 2024 16:46:21 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Thomas Bonnefille <thomas.bonnefille@...tlin.com>,
 Lars-Peter Clausen <lars@...afoo.de>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Chen Wang <unicorn_wang@...look.com>,
 Inochi Amaoto <inochiama@...look.com>,
 Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
 <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 Miquèl Raynal <miquel.raynal@...tlin.com>,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v3 1/3] dt-bindings: iio: adc: sophgo,cv18xx-saradc.yaml:
 Add Sophgo SARADC binding documentation

On 03/08/2024 12:39, Jonathan Cameron wrote:
>>
>>> +
>>> +unevaluatedProperties: false  
>>
>> I don't see any other $ref. Don't you miss adc.yaml? Or channels? Or
>> some more properties? This looks incomplete for ADC.
> 
> It's acceptable on ADCs in particular (but more generally)
> to just assume all channels are exposed.  They may all be wired
> to internal power lines anyway, in which case what is there is
> a chip feature.  This only works if their isn't any channel specific
> configuration, then not providing the channels child nodes is fine.
> 
> However, that requires us to be fairly sure there won't ever be
> a per channel thing that needs configuring from DT.
> That's generally only the case in simple devices.
> 
> So might be better to put the channels nodes in there and deal with
> dynamic channel configuration (so don't present any without
> a channel node) from the start as it's more future proof.

OK. Then anyway this should be additionalProperties: false (unless I
missed somewhere $ref?).

Best regards,
Krzysztof