linux-kernel - Re: [PATCH v2 5/9] dt-bindings: iio: dac: add ad3552r axi-dac compatible

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: <058937fa93d484f3e81807d08a39bd8dfd3358e8.camel@gmail.com>
Date: Fri, 06 Sep 2024 13:53:22 +0200
From: Nuno Sá <noname.nuno@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Angelo Dureghello
	 <adureghello@...libre.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich
 <Michael.Hennerich@...log.com>, Nuno Sá
 <nuno.sa@...log.com>,  Jonathan Cameron <jic23@...nel.org>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Olivier Moysan <olivier.moysan@...s.st.com>,
 linux-iio@...r.kernel.org,  devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, David Lechner <dlechner@...libre.com>
Subject: Re: [PATCH v2 5/9] dt-bindings: iio: dac: add ad3552r axi-dac
 compatible

On Fri, 2024-09-06 at 11:37 +0200, Krzysztof Kozlowski wrote:
> On 06/09/2024 11:11, Angelo Dureghello wrote:
> > Hi Krzysztof,
> > 
> > On 06/09/24 9:22 AM, Krzysztof Kozlowski wrote:
> > > On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
> > > > From: Angelo Dureghello <adureghello@...libre.com>
> > > > 
> > > > Add a new compatible for the ad3552r variant of the generic DAC IP.
> > > > 
> > > > The ad3552r DAC IP variant is very similar to the generic DAC IP,
> > > > register map is the same, but some register fields are specific to
> > > > this IP, and also, a DDR QSPI bus has been included in the IP.
> > > > 
> > > > Signed-off-by: Angelo Dureghello <adureghello@...libre.com>
> > > > ---
> > > >   Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
> > > >   1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > index a55e9bfc66d7..c0cccb7a99a4 100644
> > > > --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > @@ -24,6 +24,7 @@ properties:
> > > >     compatible:
> > > >       enum:
> > > >         - adi,axi-dac-9.1.b
> > > > +      - adi,axi-dac-ad3552r
> > > I am sorry, but what is the product here? It looks like either wrong
> > > order or even completely redundant. What is ad3552r?
> > > 
> > > And why versions are mixed with real products but without any
> > > compatibility. What does the version express in such case?
> > 
> > dac-ad3552r IP (fpga) is a variant of the dac IP, very similar,
> > about the version, it still reads as 9.1.b
> > 
> > so i can eventually change it to:
> > 
> > adi,axi-dac-ad3552-9.1.b
> > 
> > Should be more correct.
> 
> No. First ad3552r is the product, so axi-dac is redundant. Second why
> adding versions if you have product names? Versioning was allowed
> because apparently that's how these are called, but now it turns out it
> is not version but names.
> 

Let me try to explain on how this whole thing works...

We have a generic FPGA IP called axi-dac (same story is true for the other axi-adc
IP) which adds some basic and generic capabilities like DDS (Direct digital
synthesis) and the generic one is the compatible existing now. This IP is a so called
IIO backend because it then connects to a real converter (in this case DACs)
extending it's capabilities and also serving as an interface between another block
(typical DMA as this is used for really high speed stuff) and the device. Now,
depending on the actual device, we may need to add/modify some features of the IP and
this is what's happening for the ad3552r DAC (it's still build on top of the base
generic axi-adc). And in this design the IP is also acting as a qspi controller for
actually controlling the configuration of the device while, typically, IIO backends
are meant to only care about the dataplane. With all of this, there are discussions
still happening on the RFC (Angelo was too fast with this version) between using
different properties or new compatibles for changes so significant like this on the
generic IP. See the thread where Conor is also involved.

> Third, versions are useless if you do not use them as fallbacks.
> 

In this particular case we can't use the generic IP as a fallback since without the
bus controller feature the device can't really work. But it can happen we increase
the version on the generic core and use the existing version as fallback 

> Something this is really broken and I don't know if the binding or this
> patch.

Having said the above, I'm really not sure if what we have is the best approach but
these are also early days (upstream) for this so we should still be able to change
things if we need too. I'm fairly sure there's still no one relying on this so we
should be able to change things in a breaking way (if we need to be that extreme).

Thanks!
- Nuno Sá