linux-kernel - Re: [PATCH] dt-bindings: iio: adc: Add TI TWL603X GPADC

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]

Date:   Sun, 20 Aug 2023 08:29:08 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Andreas Kemnade <andreas@...nade.info>
Cc:     jic23@...nel.org, lars@...afoo.de, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: iio: adc: Add TI TWL603X GPADC

On 19/08/2023 22:19, Andreas Kemnade wrote:
>>> +---
>>> +$id: http://devicetree.org/schemas/iio/adc/ti,twl6030-gpadc.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: GPADC subsystem in the TWL6030 power module
>>> +
>>> +maintainers:
>>> +  - Jonathan Cameron <jic23@...nel.org>  
>>
>> This should be rather someone knowing or having or caring about this
>> particular hardware, not subsystem maintainer.
>>
> Hmm, I have the twl6032, but not the twl6030. So probably
> Tony (OMAP-Maintainer) or me?

Yes. If you have a device, it's even better, but "caring about" or
having datasheet is enough.

> 
>>> +
>>> +description:
>>> +  The GPADC subsystem in the TWL6030 consists of a 10-bit ADC
>>> +  combined with a 15-input analog multiplexer.
>>> +
>>> +properties:
>>> +  compatible:
>>> +    const: ti,twl6030-gpadc  
>>
>> Devices look fairly similar. Same properties. Why aren't they in one
>> binding (enum here instead)?
>>
> I hope it can be done. See commit message. Maybe my reasoning is wrong.

The parent device binding can expect the compatible for the child and it
will have the same effect in total as $ref to this binding. The only
difference would be that running dtbs_check on parent binding would not
spot all the issues in the child node. One need to run dtbs_check with
both bindings.

For an example:
Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml


Best regards,
Krzysztof