On Tue, Nov 21, 2023 at 03:45:42PM +0100, Andrew Lunn wrote:
> > > I do think we need somewhere to put package properties. But i don't
> > > think phy-mode is such a property. At the moment, i don't have a good
> > > example of a package property.
> >
> > What about power supplies and reset/enable lines?
>
> Yes, good point. I can imagine some packages sharing regulators. Reset
> might also be shared, but it makes things messy to handle.
>
Sooooo.... Sorry if I insist but I would really love to have something
""stable"" to move this further. (the changes are easy enough so it's
really a matter of finding a good DT structure)
Maybe a good idea would be summarize the concern and see what solution
was proposed:
Concern list:
1. ethernet-phy-package MUST be placed in mdio node (not in ethernet,
the example was wrong anyway) and MUST have an addr
Current example doesn't have an addr. I would prefer this way but
no problem in changing this.
Solution:
- Add reg to the ethernet-phy-package node with the base address of
the PHY package (base address = the first PHY address of the
package)
We will have a PHY node with the same address of the PHY package
node. Each PHY node in the PHY package node will have reg set to
the REAL address in the mdio bus.
2. global-phys are redundant and can be dropped.
They are used to facilitate and make it less obscure how the PHY
package is described. Can totally be handled internally by the PHY
driver. Still I would prefer to keep them as is.
Solution:
- Drop the thing and leave the PHY driver handle it with hardcoded
values.
Due to point 1, the shared struct will have the base address of
the PHY package and will be handle to reference the global PHY at
an offset from the base address.
3. phy-mode is problematic.
It's an optional value to enforce a specific mode for each PHY in the
package. For complex configuration the mode won't be defined.
Solution:
- Rename it to package-phy-mode to make it less confusing.
- Add an additional function that PHY package can use to make custom
validation on the mode for every PHY attached (in the PHY package).
Would make it less clear but more flexible for complex
configuration. Maybe both solution can be implemented and the
special function is used if the mode is not defined?
4. Not finding a correct place to put PHY package info.
I'm still convinced the mdio node is the correct place.
- PHY package are PHY in bundle so they are actual PHY
- We already have in the mdio node special handling (every DSA switch
use custom compatible and PHY ID is not used to probe them
normally)
- Node this way won't be treated as PHY as they won't match the PHY
node name pattern and also won't have the compatible pattern for
PHY.
Solution:
- ethernet-phy-package node is OK given a reg is defined.
These are the 4 concern we have currently, hoping I didn't miss any, I
hope we can sort those so I can send a v2 and make some progress on
this.
--
Ansuel
