linux-kernel - Re: [PATCH v3 0/2] hwmon: (tps23861) add class restrictions and semi-auto mode support

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: <20250908185728.132e9665@kmaincent-XPS-13-7390>
Date: Mon, 8 Sep 2025 18:57:28 +0200
From: Kory Maincent <kory.maincent@...tlin.com>
To: Gregory Fuchedgi <gfuchedgi@...il.com>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>, Guenter Roeck
 <linux@...ck-us.net>, Robert Marko <robert.marko@...tura.hr>, Luka Perkov
 <luka.perkov@...tura.hr>, Jean Delvare <jdelvare@...e.com>, Jonathan Corbet
 <corbet@....net>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 linux-hwmon@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, Network
 Development <netdev@...r.kernel.org>
Subject: Re: [PATCH v3 0/2] hwmon: (tps23861) add class restrictions and
 semi-auto mode support

On Mon, 8 Sep 2025 09:39:58 -0700
Gregory Fuchedgi <gfuchedgi@...il.com> wrote:

> On Sun, Sep 7, 2025 at 9:51 PM Oleksij Rempel <o.rempel@...gutronix.de> wrote:
> >
> > On Sun, Sep 07, 2025 at 09:06:25AM -0700, Guenter Roeck wrote:  
> > > +Cc: pse-pd maintainers and netdev mailing list
> > >
> > > On 9/4/25 10:33, Gregory Fuchedgi via B4 Relay wrote:  
>  [...]  
> > >
> > > This entire series makes me more and more unhappy. It is not the
> > > responsibility of the hardware monitoring subsystem to control power. The
> > > hardware monitoring subsystem is for monitoring, not for control.
> > >
> > > Please consider adding a driver for this chip to the pse-pd subsystem
> > > (drivers/net/pse-pd). As it turns out, that subsystem already supports
> > > tps23881. This is a similar chip which even has a similar register set.
> > >
> > > This driver could then be modified to be an auxiliary driver of that
> > > driver. Alternatively, we could drop this driver entirely since the
> > > pse-pd subsystem registers the chips it supports as regulator which has
> > > its own means to handle telemetry.  
> > Yes, Guenter is right. This driver belongs to the pse-pd framework.  
> No disagreement here in principle. However, the current hwmon driver
> already implements power control and exposes it via in*_enable sysfs
> files. I found this a bit odd, but I don't write drivers often.
> My understanding of Guenter's suggestion is that it would require breaking
> this userspace API?
>
> From a quick look at the tps23881 datasheet I can see that it is
> similar, however, it is quite different in the context of this patch.
> tps23881 (unlike tps23861) has Port Power Allocation register that can
> limit poe power class. This register can be set prior to
> detection/classification. So the extra complexity of an interrupt
> handler that decides whether to enable the power may not be required.
> 
> Perhaps it still makes sense to merge these drivers, but I don't have
> time or hardware to do it at the moment.

In either way the tps23861 is a PoE controller therefore the driver should land
into the pse-pd framework. Then tweaking tps23881 driver to support tps2361 or
using a standalone driver is another question.
From a quick look the register map is really similar so indeed using tps23881
driver seems relevant.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com