Re: [RFC PATCH net-next v2 0/2] net: pse-pd: Add LTC4266 PSE controller driver

[Kyle Swenson]

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