linux-kernel - Re: [PATCH v2 1/2] dt-bindings: iio: adc: Require generic adc-chan name for channel nodes

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: <20230123103607.00001fcd@Huawei.com>
Date:   Mon, 23 Jan 2023 10:36:07 +0000
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Marijn Suijten <marijn.suijten@...ainline.org>
CC:     Jonathan Cameron <jic23@...nel.org>, <phone-devel@...r.kernel.org>,
        <~postmarketos/upstreaming@...ts.sr.ht>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Martin Botka <martin.botka@...ainline.org>,
        Jami Kettunen <jami.kettunen@...ainline.org>,
        <iio@...r.kernel.org>, Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        "Manivannan Sadhasivam" <mani@...nel.org>,
        <linux-iio@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: iio: adc: Require generic adc-chan
 name for channel nodes

On Mon, 23 Jan 2023 00:37:41 +0100
Marijn Suijten <marijn.suijten@...ainline.org> wrote:

> On 2023-01-21 17:08:25, Jonathan Cameron wrote:
> > On Thu, 19 Jan 2023 22:26:31 +0100
> > Marijn Suijten <marijn.suijten@...ainline.org> wrote:
> >   
> > > As discussed in [1] it is more convenient to use a generic adc-chan node
> > > name for ADC channels while storing a friendly - board-specific instead
> > > of PMIC-specific - name in the label, if/when desired to overwrite the
> > > channel description already contained (but previously unused) in the
> > > driver [2].
> > > 
> > > Replace the .* name pattern with the adc-chan literal, but leave the
> > > label property optional for bindings to choose to fall back a channel
> > > label hardcoded in the driver [2] instead.
> > > 
> > > [1]: https://lore.kernel.org/linux-arm-msm/20221106193018.270106-1-marijn.suijten@somainline.org/T/#u
> > > [2]: https://lore.kernel.org/linux-arm-msm/20230116220909.196926-4-marijn.suijten@somainline.org/
> > > 
> > > Signed-off-by: Marijn Suijten <marijn.suijten@...ainline.org>  
> > Other than the use in the tm5 thermal example that Rob's bot found, this looks
> > good to me.  
> 
> Yep, shouldn't have ran dt_binding_check and dtbs_check with
> DT_SCHEMA_FILES=just/the/one/edited/here.
> 
> > I think ideal would be to fix that in a precursor patch then
> > do this one.  
> 
> Can't that be part of the current one?  At least the change requested by
> dt-bindings here is backwards-compatible; the adc-chan@xx format with
> optional label property was already allowed.

Sure you can merge it in, or do it as a precursor. I'd split it though
purely as it can be picked up by a different maintainer if that makes
sense (at cost of some errors as things filter through the various
trees).

> 
> > Note that the existing two patches should be in the other order
> > 1. Update the dtsi
> > 2. Tighten the bounds to check they are right.  
> 
> Hmm, I'm never sure what goes first: drivers, bindings, or DT
> (considering there's an ABI it shouldn't matter whether drivers or DT
> go first, leaving just dt-bindings which could be used to TDD the DT...
> or check adjustment after the fact).  Is this relationship - and the
> order following from it - documented somewhere?

In this particular case we in theory want bisectability.  As you note
the updated tighter naming is already allowed, so we can make that change
first.

Normally we are adding new bindings and it doesn't matter on order as
we just have an undocumented binding if the driver goes first.

As noted it all become irrelevant when things go through different
trees anyway!

J
> 
> > Doesn't matter much though as the two patches will probably go through
> > different trees.  
> 
> Should be right, indeed.
> 
> - Marijn