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