This RFC series intends to continue discussion around the support for
the LTC4266, an older PSE controller that supports powering Type 1 and
Type 2 PDs.

This chip has four individually controllable ports, each with its own
detection, classification and current-limiting abilities.  The driver
declares the static power budgeting strategy.

The LTC4266 only enforces a current limit (I_CUT and I_LIM), not a power
limit, so an admin power limit has to be turned into a current limit.
There are two problems that fall out of this I don't feel like I've got
a great solution to either and would welcome feedback, hence the 2nd RFC
version.

The first problem is programming the current limit from the
admin-specified power limit for power limits other than a specific PD
class.  For this, I replaced the linear regression in the first RFC with
the minimum port voltage for a Type 2 PSE (50V, from Table 33-11 in the
IEEE 802.3 spec) to convert power to current.

The second problem is that when the admin does something like

    ethtool --set-pse eth1 c33-pse-avail-pw-limit 10000

the command fails with:

    netlink error: Can't calculate the current, PSE voltage read is 0
    netlink error: Result not representable

unless the PSE port has been enabled first, and the PSE has detected and
classified a PD on that port.  I'm hopeful I'm just missing something I
can do differently in this driver, but if not I'm open to adjusting
things at other layers to support this.

---
RFC v1 -> RFC v2:
  - Rebase on net-next/main
  - Integrate and test with the PSE core's PSE_BUDGET_EVAL_STATIC.
  - ltc4266: Convert register access to the regmap API (replaces the
    open-coded read-modify-write helper and its explicit mutex).  Note
    the explicit mutex is gone because it only protected reading both the
    high and low bytes of a port's voltage/current.  This isn't actually
    needed because reading the LSB will latch the MSB until the MSB is
    read, so I2C transactions between the two reads are benign (Oleksij)
  - ltc4266: Rename LTC4266_ICUT_RSENSE to LTC4266_ICUT_RSENSE_025_OHM
    (Oleksij)
  - ltc4266: Rename the ILIM AF/AT constants to TYPE1/TYPE2 (IEEE 802.3
    terminology) (Oleksij)
  - ltc4266: Add kernel-doc to ltc4266_port_set_ilim() citing IEEE Std
    802.3-2022 Table 33-11 / Eq. (33-6) and the datasheet Table 5
    sense-resistor dependence (Oleksij)
  - ltc4266: Use the standard "2-event classification" term (IEEE
    802.3-2022, Clause 33) instead of the datasheet's "Ping-Pong" name
    (Oleksij)
  - ltc4266: Document the ltc4266_port_mode enum
    (SHUTDOWN/MANUAL/SEMI/AUTO).  The suggestion to treat any OPMD other
    than SHUTDOWN as ADMIN_STATE_ENABLED didn't really apply since the
    PSE core added the PSE_BUDGET_EVAL_STRAT_STATIC (Oleksij)
  - ltc4266: Return 0 from ltc4266_read_iv() rather than -EINVAL when the
    port is not delivering power, so an "ethtool --show-pse" query is not
    aborted, and clarify the "delivering power" wording (Oleksij)
  - ltc4266: Replace the I_CUT (18750, 0x3F, 850) and current/voltage
    (122070, 61035, 5835) magic numbers with named defines (Oleksij)
  - dt-bindings: Drop the blank line after "channels:" (Krzysztof)
  - dt-bindings: Move the channels "description" after
    "additionalProperties" so the structural keywords stay together
    (Krzysztof)
  - dt-bindings: Drop the blank line before "type: object" (Krzysztof)
  - dt-bindings: Collapse the double blank line before
    "patternProperties" to one (Krzysztof)
  - dt-bindings: Use single quotes consistently for
    '#address-cells'/'#size-cells' (Krzysztof)
  - dt-bindings: Move "unevaluatedProperties: false" after the top-level
    "required" block (Krzysztof)
  - dt-bindings: Drop 'status = "okay";' from the example and tidy the
    surrounding blank lines, including separating the channels and
    pse-pis nodes (Krzysztof)
  - dt-bindings: Reword the channels description based on the review in
    [1] (Kory)

[1] https://lore.kernel.org/netdev/20250517003525.2f6a5005@kmaincent-XPS-13-7390/
RFC v1: https://lore.kernel.org/netdev/20250603230422.2553046-1-kyle.swenson@est.tech/

Kyle Swenson (2):
  dt-bindings: net: pse-pd: Add bindings for LTC4266 PSE Controller
  net: pse-pd: Add LTC4266 PSE controller driver

 .../bindings/net/pse-pd/lltc,ltc4266.yaml     |  180 +++
 drivers/net/pse-pd/Kconfig                    |   11 +
 drivers/net/pse-pd/Makefile                   |    1 +
 drivers/net/pse-pd/ltc4266.c                  | 1305 +++++++++++++++++
 4 files changed, 1497 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/pse-pd/lltc,ltc4266.yaml
 create mode 100644 drivers/net/pse-pd/ltc4266.c

-- 
2.55.0

Hello Kyle,

Sadly, we won't present together at the next ELCE, but well, we still 
can drink a beer together. Are you going anyway?

On 8/20/26 16:25, Kyle Swenson wrote:
> This RFC series intends to continue discussion around the support for
> the LTC4266, an older PSE controller that supports powering Type 1 and
> Type 2 PDs.
> 
> This chip has four individually controllable ports, each with its own
> detection, classification and current-limiting abilities.  The driver
> declares the static power budgeting strategy.
> 
> The LTC4266 only enforces a current limit (I_CUT and I_LIM), not a power
> limit, so an admin power limit has to be turned into a current limit.
> There are two problems that fall out of this I don't feel like I've got
> a great solution to either and would welcome feedback, hence the 2nd RFC
> version.

Of course every controller is doing it on its own way ...
I have taken a look at your driver, it would be more precise to use the 
voltage used on each ports instead of the constant LTC4266_VPORT_MIN_MV.
I don't have the datasheet of the registers but does a read voltage 
return a value even with no PD plugged?
BTW I don't understand why in ltc4266_pi_set_pw_limit you are using the 
detected class for power comparison. If the user wants to set a power 
above the current detected class, well lets allow him to do so. Also 
this will prevent any power limit set if no PD is plugged which is not good.

> The first problem is programming the current limit from the
> admin-specified power limit for power limits other than a specific PD
> class.  For this, I replaced the linear regression in the first RFC with
> the minimum port voltage for a Type 2 PSE (50V, from Table 33-11 in the
> IEEE 802.3 spec) to convert power to current.

See above, please use a measured voltage for more precision.
  > The second problem is that when the admin does something like
> 
>      ethtool --set-pse eth1 c33-pse-avail-pw-limit 10000
> 
> the command fails with:
> 
>      netlink error: Can't calculate the current, PSE voltage read is 0
>      netlink error: Result not representable
> 
> unless the PSE port has been enabled first, and the PSE has detected and
> classified a PD on that port.  I'm hopeful I'm just missing something I
> can do differently in this driver, but if not I'm open to adjusting
> things at other layers to support this.

To have this working the pi_get_voltage should return some value even 
with no PD plugged.

I am replying only here for now. I will take a look more deeply on your 
code when this is solved. Is it ok for you?

Also I think your code is rather ready, so you could remove the RFC 
prefix. With it, the nedev check are not triggered.

Also in the 2nd patch you should add yourself in the MAINTAINERS file 
for this new driver.

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

On Mon, Aug 24, 2026 at 02:43:44PM +0200, Kory Maincent wrote:
> Hello Kyle,
> 
> Sadly, we won't present together at the next ELCE, but well, we still can
> drink a beer together. Are you going anyway?
Yep, I'll be there and look forward to it!

> 
> On 8/20/26 16:25, Kyle Swenson wrote:
> > This RFC series intends to continue discussion around the support for
> > the LTC4266, an older PSE controller that supports powering Type 1 and
> > Type 2 PDs.
> > 
> > This chip has four individually controllable ports, each with its own
> > detection, classification and current-limiting abilities.  The driver
> > declares the static power budgeting strategy.
> > 
> > The LTC4266 only enforces a current limit (I_CUT and I_LIM), not a power
> > limit, so an admin power limit has to be turned into a current limit.
> > There are two problems that fall out of this I don't feel like I've got
> > a great solution to either and would welcome feedback, hence the 2nd RFC
> > version.
> 
> Of course every controller is doing it on its own way ...
> I have taken a look at your driver, it would be more precise to use the
> voltage used on each ports instead of the constant LTC4266_VPORT_MIN_MV.
> I don't have the datasheet of the registers but does a read voltage return a
> value even with no PD plugged?

That, I think, is the crux of the issue- the LTC4266's port voltage is
only valid when it's powering a PD.  Otherwise, the values I've seen
measured while not powering a PD are anywhere from 0 10V and they vary
randomly. The values read aren't the typical or expected port voltages
that like the TPS2388x will show, unless the PD is powered.

> BTW I don't understand why in ltc4266_pi_set_pw_limit you are using the
> detected class for power comparison. If the user wants to set a power above
> the current detected class, well lets allow him to do so. Also this will
> prevent any power limit set if no PD is plugged which is not good.

Well, my intent was that if a user configures a power limit on a port,
the limit we program should be within the IEEE802.3 limits for the
class- so I capped the admin set power limit to the maximum value of the
class.  However, I don't have any problem with allowing the admin to set
an arbitrary power limit on a particular port and then using that
regardless of the detect class.  That simplifies the whole "no port
voltage unless a PD is powered problem"

> 
> > The first problem is programming the current limit from the
> > admin-specified power limit for power limits other than a specific PD
> > class.  For this, I replaced the linear regression in the first RFC with
> > the minimum port voltage for a Type 2 PSE (50V, from Table 33-11 in the
> > IEEE 802.3 spec) to convert power to current.
> 
> See above, please use a measured voltage for more precision.

If we let the admin power limit be whatever the admin has programmed, we
don't need a port voltage until we need to write a current limit for the
power, so we could do something like use a class-default power limit for
a device and let it power up, and then adjust the current limit using the
port voltage that's now valid (because the PD is powered).

I'll think through this some more.

>  > The second problem is that when the admin does something like
> > 
> >      ethtool --set-pse eth1 c33-pse-avail-pw-limit 10000
> > 
> > the command fails with:
> > 
> >      netlink error: Can't calculate the current, PSE voltage read is 0
> >      netlink error: Result not representable
> > 
> > unless the PSE port has been enabled first, and the PSE has detected and
> > classified a PD on that port.  I'm hopeful I'm just missing something I
> > can do differently in this driver, but if not I'm open to adjusting
> > things at other layers to support this.
> 
> To have this working the pi_get_voltage should return some value even with
> no PD plugged.

Yeah, I guess my question is _what_ to return, since 0 causes the
netlink error, and returning some constant if there's no PD attached
feels like a lie.

But it sounds like the intent with pi_get_voltage is that it should
_always_ return a non-zero voltage for the port, and that voltage should
be in the 44-57V range (depending on the supply voltage for the PSE
voltage domain (which I also can't read via the LTC4266)).

> 
> I am replying only here for now. I will take a look more deeply on your code
> when this is solved. Is it ok for you?
Yes, of course!  Thanks for your feedback already.

> 
> Also I think your code is rather ready, so you could remove the RFC prefix.
> With it, the nedev check are not triggered.

Will do, I'll repost as non-RFC when the net-next merge window opens
back up.

> Also in the 2nd patch you should add yourself in the MAINTAINERS file for
> this new driver.

Ack.

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

Thanks so much!
Kyle