Re: [PATCH net-next v21 1/3] dt-bindings: net: Document Motorcomm YT8824 PHY package
From: Kyle Switch
Date: Sun Sep 27 2026 - 23:45:03 EST
On 9/28/26 09:45, Kyle Switch wrote:
On 9/25/26 03:16, Andrew Lunn wrote:
phy-mode is definitely wrong, it has a different meaning, and reusing+$ref: ethernet-phy-package.yaml#This should be after ref, but also have a vendor prefix.
+
+properties:
+ compatible:
+ enum:
+ - motorcomm,yt8824-package
+ phy-mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ internal, 10g-qxgmii ]
Additionally, the qcom ethernet-phy-package user also has a mode
property. Net folks, should this be made common?
it is just going to cause confusion.
qcom,package-mode does have the same meaning as what is trying to be
expressed here. So yes, a common, vendor independent property would
make sense. It maybe should be in ethernet-phy-package.
Ans: okay, In the next version, I will revert the previous
implementation and follow the qcom,package-related approach.
Ans: Another question I'd like to get your opinions on. The usage modes of
the phy8824 are not as numerous as those covered by the qcom package.
What we're trying to express here is simply whether it's a phy8824 built into the switch or
a standalone phy8824. In both scenarios, there is one 10G serdes outputting four UTPs,
and the only difference is that some operations are slightly different, such as soft reset,
power down, and power up. How should these two types be defined and identified?
In a previous patch version, the "internal" and "10g-qxgmii" modes were used to
represent them. Andrew pointed out that "internal" is already a mode included in phy-mode,
which could cause confusion, so in subsequent versions phy-mode was used directly.
Now phy-mode needs to be replaced with a vendor-defined mode, but since the meaning
is different from what qcom expresses, it's not good to make it a common definition,
so we'd like to ask for your suggestions on how to identify internal vs. external phy8824 more appropriately.
Andrew