From: David Lechner <dlechner@baylibre.com>
To: "Paller, Kim Seer" <KimSeer.Paller@analog.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
"Dimitri Fedrau" <dima.fedrau@gmail.com>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Hennerich, Michael" <Michael.Hennerich@analog.com>,
"Nuno Sá" <noname.nuno@gmail.com>,
"kernel test robot" <lkp@intel.com>
Subject: Re: [PATCH v3 5/5] iio: dac: ltc2664: Add driver for LTC2664 and LTC2672
Date: Fri, 7 Jun 2024 14:13:36 -0500 [thread overview]
Message-ID: <afd89c16-d9d7-43e3-b40a-a88588fd7346@baylibre.com> (raw)
In-Reply-To: <PH0PR03MB7141405D9A40A18E1C90FF79F9FA2@PH0PR03MB7141.namprd03.prod.outlook.com>
On 6/6/24 10:49 AM, Paller, Kim Seer wrote:
>>> +#define LTC2664_CHANNEL(_chan) { \
>>> + .indexed = 1, \
>>> + .output = 1, \
>>> + .channel = (_chan), \
>>> + .info_mask_separate = BIT(IIO_CHAN_INFO_SCALE) | \
>>> + BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_RAW),
>> \
>>> + .info_mask_separate_available = BIT(IIO_CHAN_INFO_RAW),
>> \
>>> + .ext_info = ltc2664_ext_info, \
>>> +}
>>> +
>>> +static const struct iio_chan_spec ltc2664_channels[] = {
>>> + LTC2664_CHANNEL(0),
>>> + LTC2664_CHANNEL(1),
>>> + LTC2664_CHANNEL(2),
>>> + LTC2664_CHANNEL(3),
>>> +};
>>> +
>>> +static const struct iio_chan_spec ltc2672_channels[] = {
>>> + LTC2664_CHANNEL(0),
>>> + LTC2664_CHANNEL(1),
>>> + LTC2664_CHANNEL(2),
>>> + LTC2664_CHANNEL(3),
>>> + LTC2664_CHANNEL(4),
>>> +};
>>
>> Do we really need these since they are only used as a template anyway?
>> We could just have a single template for one channel and copy it as
>> manay times as needed.
>
> Yes, from what I can see we need separate channel specs for both devices
> since they have a differing number of channels. As for your suggestion about
> having a single template for one channel and copying it as many times as
> needed, I'm not entirely sure how to implement it in this context. Could you
> provide something like a code snippet to illustrate this?
>
Instead of the #define and arrays above, just have a single static struct:
static const struct iio_chan_spec ltc2664_channel_template = {
.indexed = 1,
.output = 1,
.info_mask_separate = BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_OFFSET) |
BIT(IIO_CHAN_INFO_RAW),
.info_mask_separate_available = BIT(IIO_CHAN_INFO_RAW),
.ext_info = ltc2664_ext_info,
};
>>> +static int ltc2664_setup(struct ltc2664_state *st, struct regulator *vref)
>>> +{
>>> + const struct ltc2664_chip_info *chip_info = st->chip_info;
>>> + struct gpio_desc *gpio;
>>> + int ret;
>>> +
>>> + /* If we have a clr/reset pin, use that to reset the chip. */
>>> + gpio = devm_gpiod_get_optional(&st->spi->dev, "reset", GPIOD_OUT_HIGH);
>>> + if (IS_ERR(gpio))
>>> + return dev_err_probe(&st->spi->dev, PTR_ERR(gpio),
>>> + "Failed to get reset gpio");
>>> + if (gpio) {
>>> + usleep_range(1000, 1200);
>>> + gpiod_set_value_cansleep(gpio, 0);
>>> + }
>>> +
>>> + /*
>>> + * Duplicate the default channel configuration as it can change during
>>> + * @ltc2664_channel_config()
>>> + */
>>> + st->iio_channels = devm_kmemdup(&st->spi->dev, chip_info->iio_chan,
>>> + (chip_info->num_channels + 1) *
>>> + sizeof(*chip_info->iio_chan),
>>> + GFP_KERNEL);
Then here, instead of devm_kmemdup():
st->iio_channels = devm_kcalloc(&st->spi->dev,
chip_info->num_channels,
sizeof(struct iio_chan_spec),
GFP_KERNEL);
if (!st->iio_channels)
return -ENOMEM;
for (i = 0; i < chip_info->num_channels; i++) {
st->iio_channels[i] = ltc2664_channel_template;
st->iio_channels[i].type = chip_info->measurement_type;
st->iio_channels[i].channel = i;
}
Note: the original code was missing the error check and I think
num_channels + 1 was 1 too many, so I fixed both of those in the
example as well.
This also replaces:
st->iio_channels[chan].type = chip_info->measurement_type;
from ltc2664_set_span() as it seems a bit out of place there.
>>> +
>>> + ret = ltc2664_channel_config(st);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (!vref)
>>> + return 0;
>>> +
>>> + return regmap_set_bits(st->regmap, LTC2664_CMD_CONFIG, LTC2664_REF_DISABLE);
>>> +}
next prev parent reply other threads:[~2024-06-07 19:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 1:21 [PATCH v3 0/5] Add driver for LTC2664 and LTC2672 Kim Seer Paller
2024-06-03 1:21 ` [PATCH v3 1/5] iio: ABI: Generalize ABI documentation for DAC Kim Seer Paller
2024-06-08 14:40 ` Jonathan Cameron
2024-06-12 10:57 ` Paller, Kim Seer
2024-06-13 17:00 ` Jonathan Cameron
2024-06-03 1:21 ` [PATCH v3 2/5] iio: ABI: add DAC 42kohm_to_gnd powerdown mode Kim Seer Paller
2024-06-03 1:21 ` [PATCH v3 3/5] dt-bindings: iio: dac: Add adi,ltc2664.yaml Kim Seer Paller
2024-06-03 7:02 ` Krzysztof Kozlowski
2024-06-03 1:21 ` [PATCH v3 4/5] dt-bindings: iio: dac: Add adi,ltc2672.yaml Kim Seer Paller
2024-06-03 7:05 ` Krzysztof Kozlowski
2024-06-03 19:59 ` David Lechner
2024-06-03 20:17 ` David Lechner
2024-06-04 6:47 ` Krzysztof Kozlowski
2024-06-04 13:53 ` David Lechner
2024-06-08 14:32 ` Jonathan Cameron
2024-06-03 1:22 ` [PATCH v3 5/5] iio: dac: ltc2664: Add driver for LTC2664 and LTC2672 Kim Seer Paller
2024-06-03 13:12 ` Nuno Sá
2024-06-03 20:43 ` David Lechner
2024-06-06 15:49 ` Paller, Kim Seer
2024-06-07 19:13 ` David Lechner [this message]
2024-06-18 10:32 ` Paller, Kim Seer
2024-06-18 13:42 ` David Lechner
2024-06-08 14:57 ` Jonathan Cameron
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=afd89c16-d9d7-43e3-b40a-a88588fd7346@baylibre.com \
--to=dlechner@baylibre.com \
--cc=KimSeer.Paller@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dima.fedrau@gmail.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=noname.nuno@gmail.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