On Tue, Mar 17, 2020 at 12:48:47PM -0700, Florian Fainelli wrote: > > > On 3/17/2020 4:56 AM, Oleksij Rempel wrote: > > On Fri, Mar 13, 2020 at 07:53:27PM +0100, Oleksij Rempel wrote: > >> On Fri, Mar 13, 2020 at 11:20:35AM -0700, Florian Fainelli wrote: > >>> > >>> > >>> On 3/13/2020 11:16 AM, Oleksij Rempel wrote: > >>>> On Fri, Mar 13, 2020 at 07:10:56PM +0100, Andrew Lunn wrote: > >>>>>>> diff --git a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml > >>>>>>> new file mode 100644 > >>>>>>> index 000000000000..42be0255512b > >>>>>>> --- /dev/null > >>>>>>> +++ b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml > >>>>>>> @@ -0,0 +1,61 @@ > >>>>>>> +# SPDX-License-Identifier: GPL-2.0+ > >>>>>>> +%YAML 1.2 > >>>>>>> +--- > >>>>>>> +$id: http://devicetree.org/schemas/net/nxp,tja11xx.yaml# > >>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>>>> + > >>>>>>> +title: NXP TJA11xx PHY > >>>>>>> + > >>>>>>> +maintainers: > >>>>>>> + - Andrew Lunn <andrew@xxxxxxx> > >>>>>>> + - Florian Fainelli <f.fainelli@xxxxxxxxx> > >>>>>>> + - Heiner Kallweit <hkallweit1@xxxxxxxxx> > >>>>>>> + > >>>>>>> +description: > >>>>>>> + Bindings for NXP TJA11xx automotive PHYs > >>>>>>> + > >>>>>>> +allOf: > >>>>>>> + - $ref: ethernet-phy.yaml# > >>>>>>> + > >>>>>>> +patternProperties: > >>>>>>> + "^ethernet-phy@[0-9a-f]+$": > >>>>>>> + type: object > >>>>>>> + description: | > >>>>>>> + Some packages have multiple PHYs. Secondary PHY should be defines as > >>>>>>> + subnode of the first (parent) PHY. > >>>>>> > >>>>>> > >>>>>> There are QSGMII PHYs which have 4 PHYs embedded and AFAICT they are > >>>>>> defined as 4 separate Ethernet PHY nodes and this would not be quite a > >>>>>> big stretch to represent them that way compared to how they are. > >>>>>> > >>>>>> I would recommend doing the same thing and not bend the MDIO framework > >>>>>> to support the registration of "nested" Ethernet PHY nodes. > >>>>> > >>>>> Hi Florian > >>>>> > >>>>> The issue here is the missing PHY ID in the secondary PHY. Because of > >>>>> that, the secondary does not probe in the normal way. We need the > >>>>> primary to be involved to some degree. It needs to register it. What > >>>>> i'm not so clear on is if it just needs to register it, or if these > >>>>> sub nodes are actually needed, given the current code. > >>>> > >>>> There are a bit more dependencies: > >>>> - PHY0 is responsible for health monitoring. If some thing wrong, it may > >>>> shut down complete chip. > >>>> - We have shared reset. It make no sense to probe PHY1 before PHY0 with > >>>> more controlling options will be probed > >>>> - It is possible bat dangerous to use PHY1 without PHY0. > >>> > >>> probing is a software problem though. If we want to describe the PHY > >>> package more correctly, we should be using a container node, something > >>> like this maybe: > >>> > >>> phy-package { > >>> compatible = "nxp,tja1102"; > >>> > >>> ethernet-phy@4 { > >>> reg = <4>; > >>> }; > >>> > >>> ethernet-phy@5 { > >>> reg = <5>; > >>> }; > >>> }; > >> > >> Yes, this is almost the same as it is currently done: > >> > >> phy-package { > >> reg = <4>; > >> > >> ethernet-phy@5 { > >> reg = <5>; > >> }; > >> }; > >> > >> Because the primary PHY0 can be autodetected by the bus scan. > >> But I have nothing against your suggestions. Please, some one should say the > >> last word here, how exactly it should be implemented? > > It's not for me to decide, I was hoping the Device Tree maintainers > could chime in, your current approach would certainly work although it > feels visually awkward. Something like this is what I'd do: ethernet-phy@4 { compatible = "nxp,tja1102"; reg = <4 5>; }; Rob