Re: [PATCH v4 3/5] phy: core: Add phy bulk data helper functions

[Vladimir Oltean <olteanv@gmail.com>]

On Mon, Oct 05, 2026 at 12:12:51PM +0200, Vinod Koul wrote:
> On 29-09-26, 16:52, Inochi Amaoto wrote:
> > Add several helper functions that allow drivers to get several phy
> > consumers in one operation. If any of the phy cannot be acquired then
> > any phys that were got will be put before returning to the caller.
> 
> Do we have many such examples? Phy is not a many resource like
> clock/regulators... Do we really need this. How many in kernel users
> will benefit from this API?

I have another case for more than 1 PHY. On some NXP boards, retimers
like phy-ds125df111.c are used for networking, but not in the way you'd
expect, i.e. not like this:

 SerDes      SerDes
 Lane A      Lane B
 RX   TX     RX   TX
  ^   |       ^   |
  |   |       |   |
  |   v       |   v
Retimer C   Retimer D
ch0  ch1    ch0  ch1
  ^   |       ^   |
  |   |       |   |
  |   |       |   |
  |   |       |   |
  |   v       |   v

but like this:

SerDes  SerDes       SerDes  SerDes
Lane A  Lane B       Lane A  Lane B
RX      RX           TX      TX
 ^      ^             |      |
 |      |             |      |
 |      |             v      v
Retimer C            Retimer D
ch0  ch1             ch0  ch1
 ^      ^             |      |
 |      |             |      |
 |      |             |      |
 |      |             |      |
 |      |             v      v

Since the retimer channels are bidirectional and not hardcoded for RX/TX
function (unlike the SerDes differential pairs), this is not a problem.

Since one SerDes lane is one struct phy, its RX side and its TX side
need to configure the channels of physically different retimer devices.

The retimer driver was modeled to permit this configuration, and it
exposes each channel as a separate struct phy. The implication is that
any consumer of this retimer needs two 'phys' phandles to have both RX
and TX retimed.


Actually I'm interested in this series too, specifically due to retimers/
repeaters. I believe they should gain core PHY support, because the
current support is very sporadic and not homogenous.

Today all SerDes PHYs capable of supporting repeaters/retimers need to
manually acquire their phy->repeater using phy_get(), and forward all
ops from their consumer to the repeater as well. But this creates the
odd situation where maybe the SerDes PHY doesn't need to do anything on,
say, phy_init(), yet it needs to implement it anyway, just to call
phy_init(phy->repeater). The existence of downstream repeaters can be
made very transparent to the top-level struct phy (the one that the
consumer interacts with).

And because in general, there could be >1 repeater in the signal path,
I was thinking the bulk API could be a good candidate for managing the
list of repeaters of a PHY.