From: Horatiu Vultur <horatiu.vultur@microchip.com>
To: Michael Walle <michael@walle.cc>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Rob Herring <robh+dt@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>, <netdev@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Kavyasree Kotagiri <kavyasree.kotagiri@microchip.com>
Subject: Re: [PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible
Date: Thu, 17 Mar 2022 20:14:06 +0100 [thread overview]
Message-ID: <20220317191406.5ivtfkdlwzngmobi@soft-dev3-1.localhost> (raw)
In-Reply-To: <145fc079ce8c266b8c2265aacfd3b077@walle.cc>
The 03/13/2022 17:30, Michael Walle wrote:
Hi Michael,
>
> [adding Horatiu and Kavyasree from Microchip]
>
> Am 2022-03-13 17:10, schrieb Krzysztof Kozlowski:
> > On 13/03/2022 11:47, Michael Walle wrote:
> > > Am 2022-03-13 10:47, schrieb Krzysztof Kozlowski:
> > > > On 13/03/2022 01:25, Michael Walle wrote:
> > > > > The MDIO controller has support to release the internal PHYs from
> > > > > reset
> > > > > by specifying a second memory resource. This is different between
> > > > > the
> > > > > currently supported SparX-5 and the LAN966x. Add a new compatible to
> > > > > distiguish between these two.
> >
> > Typo here, BTW.
> >
> > > > >
> > > > > Signed-off-by: Michael Walle <michael@walle.cc>
> > > > > ---
> > > > > Documentation/devicetree/bindings/net/mscc-miim.txt | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/net/mscc-miim.txt
> > > > > b/Documentation/devicetree/bindings/net/mscc-miim.txt
> > > > > index 7104679cf59d..a9efff252ca6 100644
> > > > > --- a/Documentation/devicetree/bindings/net/mscc-miim.txt
> > > > > +++ b/Documentation/devicetree/bindings/net/mscc-miim.txt
> > > > > @@ -2,7 +2,7 @@ Microsemi MII Management Controller (MIIM) / MDIO
> > > > > =================================================
> > > > >
> > > > > Properties:
> > > > > -- compatible: must be "mscc,ocelot-miim"
> > > > > +- compatible: must be "mscc,ocelot-miim" or "mscc,lan966x-miim"
> > > >
> > > > No wildcards, use one, specific compatible.
> > >
> > > I'm in a kind of dilemma here, have a look yourself:
> > > grep -r "lan966[28x]-" Documentation
> > >
> > > Should I deviate from the common "name" now? To make things
> > > worse, there was a similar request by Arnd [1]. But the
> > > solution feels like cheating ("lan966x" -> "lan966") ;)
> >
> > The previous 966x cases were added by one person from Microchip, so he
> > actually might know something. But do you know whether lan966x will
> > cover all current and future designs from Microchip? E.g. lan9669 (if
> > ever made) will be the same? Avoiding wildcard is the easiest, just
> > choose one implementation, e.g. "lan9662".
>
> So if Microchip would review/ack this it would be ok? I don't really
> have a strong opinion, I just want to avoid any inconsistencies. If no
> one from Microchip will answer, I'll use microchip,lan9668-miim.
I think it is OK to use microchip,lan966x.
I am not aware of any plans to create future lan966x designed(lan9664 or
lan9669). But we can also be on the safe side and use microchip,lan9668.
I don't have any strong opinion on this.
Acked-by: Horatiu Vultur <horatiu.vultur@microchip.com>
>
> > Different topic is that all current lan966[28] are from Microchip and
> > you still add Microsemi, even though it was acquired by Microchip.
> > That's an inconsistency which should be rather fixed.
>
> Agreed, that was an oversight by me.
>
> > > On a side note, I understand that there should be no wildcards,
> > > because the compatible should target one specific implementation,
> > > right? But then the codename "ocelot" represents a whole series of
> > > chips. Therefore, names for whole families shouldn't be used neither,
> > > right?
> >
> > You're not adding "ocelot" now, so it is separate topic. However a
> > compatible like "mscc,ocelot" feels wrong, unless it is used as a
> > fallback (see: git grep 'apple,').
>
> Sure, it was just a question for my understanding, not to make a
> point for a discussion.
>
> -michael
--
/Horatiu
next prev parent reply other threads:[~2022-03-17 19:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-13 0:25 [PATCH net-next v2 0/3] net: mscc-miim: add integrated PHY reset support Michael Walle
2022-03-13 0:25 ` [PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible Michael Walle
2022-03-13 9:47 ` Krzysztof Kozlowski
2022-03-13 10:47 ` Michael Walle
2022-03-13 16:10 ` Krzysztof Kozlowski
2022-03-13 16:30 ` Michael Walle
2022-03-13 17:56 ` Krzysztof Kozlowski
2022-03-17 19:14 ` Horatiu Vultur [this message]
2022-03-13 0:25 ` [PATCH net-next v2 2/3] net: mdio: mscc-miim: replace magic numbers for the bus reset Michael Walle
2022-03-13 0:25 ` [PATCH net-next v2 3/3] net: mdio: mscc-miim: add lan966x internal phy reset support Michael Walle
2022-03-13 0:54 ` [PATCH net-next v2 0/3] net: mscc-miim: add integrated PHY " Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220317191406.5ivtfkdlwzngmobi@soft-dev3-1.localhost \
--to=horatiu.vultur@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=hkallweit1@gmail.com \
--cc=kavyasree.kotagiri@microchip.com \
--cc=krzk@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=michael@walle.cc \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).