lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231027152951.52a4627f@jic23-huawei>
Date:   Fri, 27 Oct 2023 15:29:51 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Nuno Sá <noname.nuno@...il.com>
Cc:     Marius.Cristea@...rochip.com, lars@...afoo.de, robh+dt@...nel.org,
        conor+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        devicetree@...r.kernel.org, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] iio: adc: adding support for pac193x

On Fri, 27 Oct 2023 10:40:21 +0200
Nuno Sá <noname.nuno@...il.com> wrote:

> On Thu, 2023-10-26 at 15:03 +0000, Marius.Cristea@...rochip.com wrote:
> > Hi Nuno Sá,
> > 
> >   Thanks for looking over the patch.
> > 
> > On Wed, 2023-10-25 at 16:38 +0200, Nuno Sá wrote:  
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > > know the content is safe
> > > 
> > > On Wed, 2023-10-25 at 16:44 +0300,
> > > marius.cristea@...rochip.com wrote:  
> > > > From: Marius Cristea <marius.cristea@...rochip.com>
> > > > 
> > > > This is the iio driver for Microchip
> > > > PAC193X series of Power Monitor with Accumulator chip family.
> > > > 
> > > > Signed-off-by: Marius Cristea <marius.cristea@...rochip.com>
> > > > ---  
> > > 
> > > Hi Marius,
> > > 
> > > I'll be honest and I just looked at this for 5min. But I'm seeing
> > > things like
> > > shunt resistors, vsense, power, energy... This seems to me that it
> > > belong to
> > > drivers/hwmon. Any special reason for IIO?
> > >   
> > 
> >   Yes, this device is at the boundary between IIO and HWMON if you are
> > looking just at the "shunt resistors, vsense, power, energy". The
> > device also has ADC internaly that can measure voltages (up to 4
> > channels) and also currents (up to 4 channels). Current is measured as
> > voltage across the shunt_resistor.
> >   
> 
> I think this alone is not justification but...
> 
> >   As I said before: I was thinking to start with a simple driver (this
> > one that is more apropiate to be a HWMON) and add more functionality
> > later (like data buffering that is quite important for example if
> > someone wants to profile power consumtion of the procesor itself, or a
> > pheriperic, or a battery, this kind of functionality was requested by
> > our customers).
> >   
> 
> having buffering support already makes a case for IIO, yes.
> 
> Hmm, I'm also just realizing this is v2 and indeed you already justified the very
> same question in v1. Sorry for noise!

I'd suggest adding some text to the cover letter to explain this so you
can hopefully avoid being asked on v3 :)

Also for cases like this that sit at the boundary we tend to also
cc the hwmon maintainers so they are aware.  It can help us to make more
consistent decisions on where a future device belongs.

I'm not against having this in IIO, but nice to work by consensus and
avoid anyone getting a surprise.

Jonathan

> 
> - Nuno Sá
> >   
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ