Devicetree
 help / color / mirror / Atom feed
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
> 


  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