From: Lukas Wunner <lukas@wunner.de>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Mathias Duckeck <m.duckeck@kunbus.de>,
Phil Elwell <phil@raspberrypi.org>,
"Andrew F. Davis" <afd@ti.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 2/2] iio: dac: Add Texas Instruments 8/10/12-bit 2/4-channel DAC driver
Date: Sat, 7 Oct 2017 11:13:12 +0200 [thread overview]
Message-ID: <20171007091312.GA6890@wunner.de> (raw)
In-Reply-To: <20170910161108.2ecc34d3@archlinux>
On Sun, Sep 10, 2017 at 04:11:08PM +0100, Jonathan Cameron wrote:
> On Tue, 5 Sep 2017 11:27:00 +0200 Lukas Wunner <lukas@wunner.de> wrote:
> > The DACrrcS085 (rr = 08/10/12, c = 2/4) family of SPI DACs was
> > inherited by TI when they acquired National Semiconductor in 2011.
>
> Very nice. A few really minor comments inline.
D'accord on all your comments except this one:
> > + ret = sscanf(spi->modalias, "dac%2hhu%1d",
> > + &ti_dac->resolution, &indio_dev->num_channels);
> > + WARN_ON(ret != 2);
>
> Whilst this seems nice and clear now, it may not work if this driver
> had additional parts added in future.
>
> I would prefer an explicit table with this information in it and
> use an enum to reference into it.
>
> This is a bit 'too clever' :)
Hm, I looked at the other SPI DACs available from TI and their programming
interface is sufficiently different that they don't lend themselves all
too well for integration into this driver. There might be DACs from other
vendors with a similar programming interface.
What I *could* do is encode the resolution and number of channels in the
driver_data field of the spi MODULE_DEVICE_TABLE like this:
static const struct spi_device_id ti_dac_spi_id[] = {
{ "dac082s085", 8 << 8 + 2 },
{ "dac102s085", 10 << 8 + 2 },
...
Then instead of reading the information from the modalias I'd read them
from driver_data. However it looks a bit redundant and silly to me.
Can we add this extra complexity when the need for it actually arises?
Thanks,
Lukas
next prev parent reply other threads:[~2017-10-07 9:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 9:27 [PATCH 1/2] dt-bindings: iio: dac: ti-dac082s085: Document new driver Lukas Wunner
2017-09-05 9:27 ` [PATCH 2/2] iio: dac: Add Texas Instruments 8/10/12-bit 2/4-channel DAC driver Lukas Wunner
2017-09-10 15:11 ` Jonathan Cameron
2017-10-07 9:13 ` Lukas Wunner [this message]
2017-10-08 10:15 ` Jonathan Cameron
2017-09-10 15:12 ` [PATCH 1/2] dt-bindings: iio: dac: ti-dac082s085: Document new driver Jonathan Cameron
2017-09-12 21:51 ` Rob Herring
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=20171007091312.GA6890@wunner.de \
--to=lukas@wunner.de \
--cc=afd@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=m.duckeck@kunbus.de \
--cc=mark.rutland@arm.com \
--cc=phil@raspberrypi.org \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@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;
as well as URLs for NNTP newsgroup(s).