Devicetree
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: "Nuno Sá" <noname.nuno@gmail.com>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Angelo Dureghello" <adureghello@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Olivier Moysan" <olivier.moysan@foss.st.com>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, "Mark Brown" <broonie@kernel.org>
Subject: Re: [PATCH v6 7/8] iio: dac: ad3552r: add high-speed platform driver
Date: Sat, 19 Oct 2024 16:18:55 +0100	[thread overview]
Message-ID: <20241019161855.32078709@jic23-huawei> (raw)
In-Reply-To: <61cf3072af74a8b2951c948ddc2383ba1e55954d.camel@gmail.com>


> > >   
> > > > 
> > > > Re: the other recent discussions about getting too many
> > > > callbacks. Instead of a dedicated function like this, we
> > > > could make a set of generic functions:
> > > > 
> > > > iio_backend_{g,s}et_property_{s,u}(8, 16, 32, 64}()
> > > >   
> > > 
> > > Hmm interesting approach. I don't dislike it. Kind of a generic getter/setter
> > > thingy.
> > > We could then still have optional inline helpers that would call the generic
> > > functions with the proper enum value.
> > >   
> > > > that take an enum parameter for the property. This way,
> > > > for each new property, we just have to add an enum member
> > > > instead of creating a get/set callback pair.
> > > > 
> > > > Unrelated to this particular case, but taking the idea even
> > > > farther, we could also do the same with enable/disable
> > > > functions. We talked before about cutting the number of
> > > > callbacks in half by using a bool parameter instead of
> > > > separate enable/disable callbacks. But we could cut it down
> > > > even more by having an enum parameter for the thing we are
> > > > enabling/disabling.  
> > > 
> > > If we don't get too strict about types it could even fall into the above u8
> > > category.
> > > 
> > > Instead of lot of new simple ops we just grow an enum.  
> > 
> > Sure. For that matter, maybe try to just stick with 32-bit
> > for everything to keep it simple. Probably will eventually
> > need 64-bit for some things, but might be able to get away
> > with avoiding 8 and 16-bit.
> >   
> 
> Agreed. Anyways, nothing that I will take care in the near future (I would first like
> for things to stabilize a bit). That said, if you want (or anybody else), feel free
> to send the patches :)

Definitely don't do the many size versions.  Large signed integers
are nice and flexible. Maybe just go s64 from the start.

Jonathan

> 
> - Nuno Sá
> 


  reply	other threads:[~2024-10-19 15:19 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-14 10:08 [PATCH v6 0/8] iio: add support for the ad3552r AXI DAC IP Angelo Dureghello
2024-10-14 10:08 ` [PATCH v6 1/8] dt-bindings: iio: dac: ad3552r: add iio backend support Angelo Dureghello
2024-10-14 10:08 ` [PATCH v6 2/8] dt-bindings: iio: dac: adi-axi-dac: add ad3552r axi variant Angelo Dureghello
2024-10-14 11:21   ` Rob Herring (Arm)
2024-10-14 13:38     ` Rob Herring
2024-10-14 14:04       ` Angelo Dureghello
2024-10-14 19:20         ` Jonathan Cameron
2024-10-14 19:24           ` Angelo Dureghello
2024-10-14 21:13   ` David Lechner
2024-10-15  7:44     ` Angelo Dureghello
2024-10-15 14:40       ` David Lechner
2024-10-15 14:51         ` Nuno Sá
2024-10-15 18:19           ` Angelo Dureghello
2024-10-14 10:08 ` [PATCH v6 3/8] iio: backend: extend features Angelo Dureghello
2024-10-14 10:08 ` [PATCH v6 4/8] iio: dac: adi-axi-dac: " Angelo Dureghello
2024-10-14 21:14   ` David Lechner
2024-10-15  6:30     ` Nuno Sá
2024-10-15  8:57     ` Angelo Dureghello
2024-10-15 11:10       ` Nuno Sá
2024-10-19 15:08         ` Jonathan Cameron
2024-10-14 10:08 ` [PATCH v6 5/8] iio: dac: ad3552r: changes to use FIELD_PREP Angelo Dureghello
2024-10-14 21:14   ` David Lechner
2024-10-15  6:17     ` Nuno Sá
2024-10-15 10:19     ` Angelo Dureghello
2024-10-14 10:08 ` [PATCH v6 6/8] iio: dac: ad3552r: extract common code (no changes in behavior intended) Angelo Dureghello
2024-10-19 15:15   ` Jonathan Cameron
2024-10-14 10:08 ` [PATCH v6 7/8] iio: dac: ad3552r: add high-speed platform driver Angelo Dureghello
2024-10-14 21:15   ` David Lechner
2024-10-15  6:37     ` Nuno Sá
2024-10-15 14:38       ` David Lechner
2024-10-15 15:00         ` Nuno Sá
2024-10-15 15:23           ` David Lechner
2024-10-16  7:50             ` Nuno Sá
2024-10-19 15:18               ` Jonathan Cameron [this message]
2024-10-16  8:35           ` Angelo Dureghello
2024-10-15  7:15   ` Nuno Sá
2024-10-15 14:48     ` David Lechner
2024-10-16 11:54       ` Nuno Sá
2024-10-17  7:27     ` Angelo Dureghello
2024-10-19 15:24   ` Jonathan Cameron
2024-10-14 10:08 ` [PATCH v6 8/8] iio: dac: adi-axi-dac: add registering of child fdt node Angelo Dureghello
2024-10-14 21:16   ` David Lechner
2024-10-15  6:11     ` Nuno Sá
2024-10-17  8:32       ` Angelo Dureghello
2024-10-17 15:13         ` Nuno Sá

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241019161855.32078709@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=adureghello@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=noname.nuno@gmail.com \
    --cc=nuno.sa@analog.com \
    --cc=olivier.moysan@foss.st.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox