netdev - [RFC PATCH net-next 0/2] Add support for the LTC4266 PSE Controller

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-next>] [day] [month] [year] [list]

Message-ID: <20250603230422.2553046-1-kyle.swenson@est.tech>
Date: Tue, 3 Jun 2025 23:04:34 +0000
From: Kyle Swenson <kyle.swenson@....tech>
To: "o.rempel@...gutronix.de" <o.rempel@...gutronix.de>,
	"kory.maincent@...tlin.com" <kory.maincent@...tlin.com>,
	"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>, "davem@...emloft.net"
	<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>
CC: Kyle Swenson <kyle.swenson@....tech>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>
Subject: [RFC PATCH net-next 0/2] Add support for the LTC4266 PSE Controller

Hello,

This RFC series is intended as a starting point for adding support for the
LTC4266, an older PSE (IEEE 802.3at+) chipset from Linear Technology.

This chip has four individually controllable ports, each with its own
detection, classification and current-limiting abilities.  Currently, this
series integrates with the PSE controller core and supports enable/disable,
current and voltage reporting, classification results and will power up a valid
IEEE 802.3at or IEEE802.3af powered device.

It also (poorly) supports the power-limiting functionality in the PSE core.
The complexity here is that the LTC4266 only supports limiting the current, and
so deriving a "current limit" from this power limit while staying compliant
with the IEEE 802.3at/af specifications is tricky.  I'm curious if folks have a
better idea than the linear approximation I've used here.

It is RFC because I want to clarify some confusion I have around the
system-level flow for a port's power allocation.  It's very likely I've missed
something, but it appears as though the port needs to be delivering power in
order to set the power limit on the port.

Thanks for your time,
Kyle

Kyle Swenson (2):
  dt-bindings: net: pse-pd: Describe the LTC4266 PSE chipset
  net: pse-pd: Add LTC4266 PSE controller driver

 .../bindings/net/pse-pd/lltc,ltc4266.yaml     | 146 +++
 drivers/net/pse-pd/Kconfig                    |  10 +
 drivers/net/pse-pd/Makefile                   |   1 +
 drivers/net/pse-pd/ltc4266.c                  | 919 ++++++++++++++++++
 4 files changed, 1076 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/pse-pd/lltc,ltc4266.yaml
 create mode 100644 drivers/net/pse-pd/ltc4266.c

-- 
2.47.0