linux-kernel - Re: [PATCH v4 4/5] dt-bindings: iio: dac: Add adi,ltc2672.yaml

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240624183753.0000218c@Huawei.com>
Date: Mon, 24 Jun 2024 18:37:53 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Conor Dooley <conor@...nel.org>
CC: "Paller, Kim Seer" <KimSeer.Paller@...log.com>, Jonathan Cameron
	<jic23@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-iio@...r.kernel.org"
	<linux-iio@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, David Lechner <dlechner@...libre.com>,
	Lars-Peter Clausen <lars@...afoo.de>, Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, Dimitri Fedrau <dima.fedrau@...il.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, "Hennerich, Michael"
	<Michael.Hennerich@...log.com>, Nuno Sá
	<noname.nuno@...il.com>
Subject: Re: [PATCH v4 4/5] dt-bindings: iio: dac: Add adi,ltc2672.yaml

On Mon, 24 Jun 2024 18:00:24 +0100
Conor Dooley <conor@...nel.org> wrote:

> On Mon, Jun 24, 2024 at 03:26:26PM +0000, Paller, Kim Seer wrote:
> > 
> >   
> > > -----Original Message-----
> > > From: Jonathan Cameron <jic23@...nel.org>
> > > Sent: Sunday, June 23, 2024 9:44 PM
> > > To: Conor Dooley <conor@...nel.org>
> > > Cc: Paller, Kim Seer <KimSeer.Paller@...log.com>; linux-
> > > kernel@...r.kernel.org; linux-iio@...r.kernel.org; devicetree@...r.kernel.org;
> > > David Lechner <dlechner@...libre.com>; Lars-Peter Clausen
> > > <lars@...afoo.de>; Liam Girdwood <lgirdwood@...il.com>; Mark Brown
> > > <broonie@...nel.org>; Dimitri Fedrau <dima.fedrau@...il.com>; Krzysztof
> > > Kozlowski <krzk+dt@...nel.org>; Rob Herring <robh@...nel.org>; Conor
> > > Dooley <conor+dt@...nel.org>; Hennerich, Michael
> > > <Michael.Hennerich@...log.com>; Nuno Sá <noname.nuno@...il.com>
> > > Subject: Re: [PATCH v4 4/5] dt-bindings: iio: dac: Add adi,ltc2672.yaml
> > > 
> > > [External]
> > > 
> > > On Wed, 19 Jun 2024 18:57:59 +0100
> > > Conor Dooley <conor@...nel.org> wrote:
> > >   
> > > > On Wed, Jun 19, 2024 at 02:49:03PM +0800, Kim Seer Paller wrote:  
> > > > > +patternProperties:
> > > > > +  "^channel@[0-4]$":
> > > > > +    type: object
> > > > > +    additionalProperties: false
> > > > > +
> > > > > +    properties:
> > > > > +      reg:
> > > > > +        description: The channel number representing the DAC output  
> > > channel.  
> > > > > +        maximum: 4
> > > > > +
> > > > > +      adi,toggle-mode:
> > > > > +        description:
> > > > > +          Set the channel as a toggle enabled channel. Toggle operation  
> > > enables  
> > > > > +          fast switching of a DAC output between two different DAC codes  
> > > without  
> > > > > +          any SPI transaction.
> > > > > +        type: boolean
> > > > > +
> > > > > +      adi,output-range-microamp:
> > > > > +        description: Specify the channel output full scale range.
> > > > > +        enum: [3125000, 6250000, 12500000, 25000000, 50000000,  
> > > 100000000,  
> > > > > +               200000000, 300000000]  
> > > >
> > > > IIO folks, is this sort of thing common/likely to exist on other DACs?  
> > > 
> > > Fair point. It is probably time to conclude this is at least moderately common
> > > and generalize it - which will need a dac.yaml similar to the one we have for
> > > ADCs in adc/adc.yaml.  That will need to make this a per channel node property
> > > (same as the adc ones).  
> > 
> > Should I proceed with generalizing common DAC properties in this series and does  
> 
> I think so, yes.

Yes, that would great.

> 
> > this mean somehow removing these common properties from existing DAC bindings?  
> 
> I think that that one is up to Jonathan.

We can deprecate them.  At somepoint we can remove them form the documented bindings
but we will need to keep them in drivers forever (which won't be costly in this case).

Jonathan

> 
> > > I'd also expect it to always take 2 values. In many cases the first will be 0 but
> > > that is fine.
> > > 
> > > Jonathan  
> >   
>