[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240904145720.GA2552590-robh@kernel.org>
Date: Wed, 4 Sep 2024 09:57:20 -0500
From: Rob Herring <robh@...nel.org>
To: Wei Fang <wei.fang@....com>
Cc: davem@...emloft.net, pabeni@...hat.com, krzk+dt@...nel.org,
conor+dt@...nel.org, andrew@...n.ch, f.fainelli@...il.com,
hkallweit1@...il.com, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
imx@...ts.linux.dev
Subject: Re: [PATCH net] dt-bindings: net: tja11xx: fix the broken binding
On Mon, Sep 02, 2024 at 02:33:52PM +0800, Wei Fang wrote:
> As Rob pointed in another mail thread [1], the binding of tja11xx PHY
> is completely broken, the schema cannot catch the error in the DTS. A
> compatiable string must be needed if we want to add a custom propety.
> So extract known PHY IDs from the tja11xx PHY drivers and convert them
> into supported compatible string list to fix the broken binding issue.
>
> [1]: https://lore.kernel.org/netdev/31058f49-bac5-49a9-a422-c43b121bf049@kernel.org/T/
>
> Fixes: 52b2fe4535ad ("dt-bindings: net: tja11xx: add nxp,refclk_in property")
> Signed-off-by: Wei Fang <wei.fang@....com>
> ---
> .../devicetree/bindings/net/nxp,tja11xx.yaml | 50 +++++++++++++------
> 1 file changed, 34 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
> index 85bfa45f5122..c2a1835863e1 100644
> --- a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
> +++ b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
> @@ -14,8 +14,41 @@ maintainers:
> description:
> Bindings for NXP TJA11xx automotive PHYs
>
> +properties:
> + compatible:
> + enum:
> + - ethernet-phy-id0180.dc40
> + - ethernet-phy-id0180.dd00
> + - ethernet-phy-id0180.dc80
> + - ethernet-phy-id001b.b010
> + - ethernet-phy-id001b.b031
> +
> allOf:
> - $ref: ethernet-phy.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ethernet-phy-id0180.dc40
> + - ethernet-phy-id0180.dd00
> + then:
> + properties:
> + nxp,rmii-refclk-in:
> + type: boolean
> + description: |
> + The REF_CLK is provided for both transmitted and received data
> + in RMII mode. This clock signal is provided by the PHY and is
> + typically derived from an external 25MHz crystal. Alternatively,
> + a 50MHz clock signal generated by an external oscillator can be
> + connected to pin REF_CLK. A third option is to connect a 25MHz
> + clock to pin CLK_IN_OUT. So, the REF_CLK should be configured
> + as input or output according to the actual circuit connection.
> + If present, indicates that the REF_CLK will be configured as
> + interface reference clock input when RMII mode enabled.
> + If not present, the REF_CLK will be configured as interface
> + reference clock output when RMII mode enabled.
> + Only supported on TJA1100 and TJA1101.
>
> patternProperties:
> "^ethernet-phy@[0-9a-f]+$":
> @@ -32,22 +65,6 @@ patternProperties:
> description:
> The ID number for the child PHY. Should be +1 of parent PHY.
>
> - nxp,rmii-refclk-in:
> - type: boolean
> - description: |
> - The REF_CLK is provided for both transmitted and received data
> - in RMII mode. This clock signal is provided by the PHY and is
> - typically derived from an external 25MHz crystal. Alternatively,
> - a 50MHz clock signal generated by an external oscillator can be
> - connected to pin REF_CLK. A third option is to connect a 25MHz
> - clock to pin CLK_IN_OUT. So, the REF_CLK should be configured
> - as input or output according to the actual circuit connection.
> - If present, indicates that the REF_CLK will be configured as
> - interface reference clock input when RMII mode enabled.
> - If not present, the REF_CLK will be configured as interface
> - reference clock output when RMII mode enabled.
> - Only supported on TJA1100 and TJA1101.
> -
> required:
> - reg
>
> @@ -60,6 +77,7 @@ examples:
> #size-cells = <0>;
>
> tja1101_phy0: ethernet-phy@4 {
> + compatible = "ethernet-phy-id0180.dc40";
> reg = <0x4>;
> nxp,rmii-refclk-in;
Are child phy devices optional? Either way, would be good to show a
child device. IOW, make examples as complete as possible showing
optional properties/nodes.
Rob
Powered by blists - more mailing lists