linux-kernel - Re: [PATCH net-next v2 8/8] net: pse-pd: Add PD692x0 PSE controller driver

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: <20231221163610.47038996@kmaincent-XPS-13-7390>
Date: Thu, 21 Dec 2023 16:36:10 +0100
From: Köry Maincent <kory.maincent@...tlin.com>
To: Mark Brown <broonie@...nel.org>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
 <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Jonathan Corbet
 <corbet@....net>, Luis Chamberlain <mcgrof@...nel.org>, Russ Weight
 <russ.weight@...ux.dev>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley
 <conor+dt@...nel.org>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, devicetree@...r.kernel.org, Dent Project
 <dentproject@...uxfoundation.org>, Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH net-next v2 8/8] net: pse-pd: Add PD692x0 PSE controller
 driver

On Tue, 5 Dec 2023 15:57:28 +0000
Mark Brown <broonie@...nel.org> wrote:

> On Tue, Dec 05, 2023 at 03:02:03PM +0100, Oleksij Rempel wrote:
> > On Tue, Dec 05, 2023 at 12:55:18PM +0000, Mark Brown wrote:  
> > > On Tue, Dec 05, 2023 at 07:45:27AM +0100, Oleksij Rempel wrote:  
> 
> > > > CC regulator devs here too.  
> 
> > > Again, I'm not sure what if any question there is?  
> 
> > PSE is kind of PMIC for Ethernet ports. I assume, it is good to let you
> > know at least about existence drivers.  
> 
> OK...  I mean, if they're not using the regulator framework I'm not sure
> it has much impact - there are plenty of internal regulators in devices
> already so it wouldn't be *too* unusual other than the fact that AFAICT
> this is somewhat split between devices within the subsystem?  Neither of
> the messages was super clear.

PSE Power Interface (which is kind of the RJ45 in PSE world) have similar
functionalities as regulators. We wondered if registering a regulator for
each PSE PI (RJ45 ports) is a good idea. The point is that the PSE controller
driver will be its own regulator consumer.
I can't find any example in Linux with such a case of a driver being a provider
and a consumer of its own regulator. This idea of a regulator biting its own
tail seems weird to me. Maybe it is better to implement the PSE functionalities
even if they are like the regulator functionalities.

What do you think?

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