linux-kernel - Re: [RFC PATCH v1 0/4] Add support for Allwinner GPADC on D1/T113s/R329 SoCs

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]

Message-ID: <20230528162507.144cfdf2@jic23-huawei>
Date:   Sun, 28 May 2023 16:25:07 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Maxim Kiselev <bigunclemax@...il.com>
Cc:     Andre Przywara <andre.przywara@....com>, linux-iio@...r.kernel.org,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Samuel Holland <samuel@...lland.org>,
        Conor Dooley <conor@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Heiko Stuebner <heiko.stuebner@...ll.eu>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Cosmin Tanislav <demonsingur@...il.com>,
        Mike Looijmans <mike.looijmans@...ic.nl>,
        Haibo Chen <haibo.chen@....com>,
        ChiYuan Huang <cy_huang@...htek.com>,
        Ramona Bolboaca <ramona.bolboaca@...log.com>,
        Ibrahim Tilki <Ibrahim.Tilki@...log.com>,
        Caleb Connolly <caleb.connolly@...aro.org>,
        William Breathitt Gray <william.gray@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        Leonard Göhrs <l.goehrs@...gutronix.de>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Hugo Villeneuve <hvilleneuve@...onoff.com>,
        ChiaEn Wu <chiaen_wu@...htek.com>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [RFC PATCH v1 0/4] Add support for Allwinner GPADC on
 D1/T113s/R329 SoCs

On Sun, 28 May 2023 16:22:57 +0100
Jonathan Cameron <jic23@...nel.org> wrote:

> On Wed, 24 May 2023 14:36:28 +0300
> Maxim Kiselev <bigunclemax@...il.com> wrote:
> 
> > Hi Andre,
> > 
> > thanks for you comments
> >   
> > > This may sound kind of obvious, but wouldn't it be easier to model this
> > > with one compatible string, and have the number of channels as a DT
> > > property?    
> > 
> > Yes, I completely agree that using separate config for each SoCs is looks
> > overcomplicated because the only difference is the number of channels.
> > I thought about a DT property with channels number but I didn't find
> > another ADC driver with the same approach (except i2c ADC's with child nodes).  
> If you are 100% sure that that devices are either
> 1) Detectable at runtime
> 2) Identical in functionality.
> 
> So that in neither case will any changes on driver support expose differences
> in the future then a single compatible is fine.
> 
> The back up is that you use fallback compatibles - list more than one.
> Whilst it doesn't matter (as no differences found) the driver can use
> the first one.  If differences become apparent later, others may be used.
> 
> I'm not however keen on a simple channel count parameter.  If you want
> to go that way, it's better to provide the fine control of individual channel
> child nodes (see Documentation/devicetree/bindings/iio/adc/adc.yaml)
> 
> That way the control is on which channels are wired to something useful, rather
> than whether the device can read them or not (which is pointless if no one
> wired them up.

Another thing to note is that with generic compatibles you loose the ability
to have the dt-schmema validate that sets of parameters make sense. If it's
just the channels available that may not matter however.


> 
> 
> >   
> > > Or, alternatively, using iio/multiplexer/io-channel-mux.yaml, since it's
> > > only one ADC anyway?    
> > I'm sorry, I didn't quite understand what you're suggesting.  
> 
> That's normally only used for a separate MUX where we need a separate driver
> to handle it.  If used on a device like this it would expose additional complexity
> to userspace with no benefits in generality etc.
> 
> >   
> > > And btw: it seems that the T507 (the H616 die with a different pinout) has
> > > the same IP, with four channels:
> > > http://dl.linux-sunxi.org/T507/    
> > 
> > Oh, thanks for pointing that. I'll add it to the list in the next version.  
>