Message-ID: <e1f58a61065a0a455cf05458780f8164f6d6e1ad.camel@microchip.com>
Date: Thu, 23 Oct 2025 12:36:21 +0000
From: <Ariana.Lazar@...rochip.com>
To: <linux@...ck-us.net>, <jic23@...nel.org>
CC: <dlechner@...libre.com>, <linux-hwmon@...r.kernel.org>,
	<nuno.sa@...log.com>, <linux-iio@...r.kernel.org>,
	<devicetree@...r.kernel.org>, <robh@...nel.org>,
	<linux-kernel@...r.kernel.org>, <andy@...nel.org>, <krzk+dt@...nel.org>,
	<conor+dt@...nel.org>
Subject: Re: [PATCH 0/2] Adding support for Microchip PAC1711

Hi all,
  
Thank you for the feedback, I will make sure that for border devices I
will add HWMON list.
    
  I was thinking that the PAC1711 device is more suitable for the
IIO subsystem for the following reasons:
  - first but not the most important is to have the same API for the
whole family (with similar functionalities) of the devices from
Microchip;
  - second and the most important: We are looking at PAC1711 as a
"special" ADC, that has some special capabilities like hardware limits.
The PAC1711 could have a sample rate of up to 16384 samples/second if
we are sampling only the voltage or only the current.
      In case of sampling only the current we have some request to
be able to profile the current consumption of the device under test.

  I have started with a simple driver (this one that is more
appropriate to be a HWMON) and willing to add more functionality
later (like data buffering that is quite important for example if
someone wants to profile current consumption of the processor itself,
a peripheral device, a battery or an industrial low voltage
automation, this kind of functionality that was requested by our
customers).

Best regards,
Ariana Lazar



On Sun, 2025-10-19 at 08:02 -0700, Guenter Roeck wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> On 10/19/25 03:31, Jonathan Cameron wrote:
> > On Wed, 15 Oct 2025 13:12:14 +0300
> > Ariana Lazar <ariana.lazar@...rochip.com> wrote:
> > 
> > > The PAC1711 product is a single-channel power monitor with
> > > accumulator.
> > > The device uses 12-bit resolution for voltage and current
> > > measurements and
> > > 24 bits power calculations. The accumulator register (56-bit)
> > > could
> > > accumulate power (energy), current (Coulomb counter) or voltage.
> > > 
> > > PAC1711 measures up to 42V Full-Scale Range.
> > 
> > Hi Ariana,
> > 
> > For devices like this where the datasheet explicitly calls out
> > usecases in
> > power monitoring e.g. for "Portable and Embedded Computing"
> > (amongst other
> > things) there is always a question to answer wrt to whether the
> > correct
> > place to support them in Linux is in hwmon or IIO. Note that,
> > whilst this
> > has long been an informal policy I've become more strict on this
> > after some
> > concerns were raised in the last cycle - the presence of similar
> > devices
> > in IIO isn't necessarily a sign that was the right choice, but it
> > is worth
> > looking at the history of those divers as it may provide more
> > insight into
> > why they are in IIO.
> > 
> > To address that we ask that:
> > 1) Drivers for this sort of potentially borderline device are +CC
> > to hwmon
> >     list and maintainers
> > 2) A justification for IIO making more sense is included. That can
> > be
> >     based on what cannot be supported in hwmon (high speed capture
> > being
> >     a typical item - that doesn't seem to apply here as it's only
> > 200 sample/sec)
> > 
> > Anyhow, I've +CC relevant folk so if you can reply with that info
> > here then
> > that would be great.
> > 
> This should really be a hardware monitoring driver.
> 
> Guenter
> 

Powered by blists - more mailing lists