From: Jonathan Cameron <jic23@kernel.org>
To: <Ariana.Lazar@microchip.com>
Cc: <dlechner@baylibre.com>, <linux@roeck-us.net>,
<linux-hwmon@vger.kernel.org>, <nuno.sa@analog.com>,
<linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
<robh@kernel.org>, <linux-kernel@vger.kernel.org>,
<andy@kernel.org>, <krzk+dt@kernel.org>, <conor+dt@kernel.org>,
<neil.armstrong@linaro.org>
Subject: Re: [PATCH v4 3/3] iio: adc: add support for PAC1711
Date: Wed, 21 Oct 2026 19:52:08 +0100 [thread overview]
Message-ID: <20261021195208.1693a46a@jic23-hlaptop> (raw)
In-Reply-To: <514e3ba1e9dd5f49afddf5c81ed6b9c38329102c.camel@microchip.com>
> > > + *val = (u32)info-
> > > >chip_reg_data.acc_val;
> >
> > Could use lower_32_bits / upper_32_bits.
> > Maybe we should just have a helper for this given it is
> > becoming rather more common.
> > iio_fill_val_int_64(info-
> > >chip_reg_data.acc_val, val, val2);
> >
> > I don't mind if you want to leave that a follow up for someone else
> > to do though.
>
>
> About this, would you prefer me to add iio_fill_val_int_64() as a
> precursor patch in this series, with PAC1711 as its first user? Or
> should I use lower_32_bits() and upper_32_bits() in the driver
> implementation and leave the generic helper for a separate follow-up
> series?
Prefer the helper - but not a strong preference.
>
> > >
> > >
> > > +
> > > +static int pac1711_parse_fw(struct i2c_client *client, struct
> > > pac1711_chip_info *info)
> > > +{
> > > + struct device *dev = &client->dev;
> > > + const char *acc_mode;
> > > + int ret;
> > > +
> > > + ret = device_property_read_u32(dev, "shunt-resistor-micro-
> > > ohms", &info->shunt);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Shunt resistor
> > > property error\n");
> > > +
> > > + if (!info->shunt)
> > > + return dev_err_probe(dev, -EINVAL, "Invalid value for
> > > shunt resistor\n");
> > > +
> > > + ret = pac1711_init_vbus_vsense_ranges(info, true);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = pac1711_init_vbus_vsense_ranges(info, false);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (device_property_present(dev, "microchip,accumulation-
> > > source")) {
> > > + ret = device_property_read_string(dev,
> > > "microchip,accumulation-source", &acc_mode);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Cannot read
> > > accumulation-source\n");
> > > +
> > > + if (!strcmp(acc_mode, PAC1711_ACC_ENERGY_STR))
> > > + info->accumulation_mode =
> > > PAC1711_ACCMODE_VPOWER;
> > > + else if (!strcmp(acc_mode, PAC1711_ACC_CHARGE_STR))
> > > + info->accumulation_mode =
> > > PAC1711_ACCMODE_VSENSE;
> >
> > Can we use fwnode_property_match_property_string() for this?
> > Could add a device variant for that to make it simpler still.
> >
> >
>
> Regarding this comment, I was wondering if
> device_property_match_property_string() is the function you want me to
> use in the driver implementation instead of strcmp():
>
> https://elixir.bootlin.com/linux/v7.3-rc7/C/ident/device_property_match_property_string
Huh. I wonder why my search didn't find that. Indeed!
Jonathan
>
>
>
>
> Best regards,
> Ariana
>
next prev parent reply other threads:[~2026-10-21 18:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 14:41 [PATCH v4 0/3] Add support for Microchip PAC1711 Power Monitor Ariana Lazar
2026-10-07 14:41 ` [PATCH v4 1/3] iio: core: add IIO_CHARGE channel type Ariana Lazar
2026-10-07 14:49 ` sashiko-bot
2026-10-07 14:41 ` [PATCH v4 2/3] dt-bindings: iio: adc: add support for PAC1711 Ariana Lazar
2026-10-07 14:50 ` sashiko-bot
2026-10-07 20:47 ` Rob Herring (Arm)
2026-10-07 14:41 ` [PATCH v4 3/3] " Ariana Lazar
2026-10-07 14:54 ` sashiko-bot
2026-10-08 16:46 ` kernel test robot
2026-10-18 19:27 ` Jonathan Cameron
2026-10-19 13:35 ` Ariana.Lazar
2026-10-21 18:52 ` Jonathan Cameron [this message]
2026-10-18 18:43 ` [PATCH v4 0/3] Add support for Microchip PAC1711 Power Monitor 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=20261021195208.1693a46a@jic23-hlaptop \
--to=jic23@kernel.org \
--cc=Ariana.Lazar@microchip.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=krzk+dt@kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=neil.armstrong@linaro.org \
--cc=nuno.sa@analog.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