[PATCH net-next v2 0/3] net: mscc-miim: add integrated PHY reset support

[PATCH net-next v2 0/3] net: mscc-miim: add integrated PHY reset support

[Michael Walle]

The MDIO driver has support to release the integrated PHYs from reset.
This was implemented for the SparX-5 for now. Now add support for the
LAN966x, too.

changes since v1:
 - fix typo in the subject in patch 3/3

Michael Walle (3):
  dt-bindings: net: mscc-miim: add lan966x compatible
  net: mdio: mscc-miim: replace magic numbers for the bus reset
  net: mdio: mscc-miim: add lan966x internal phy reset support

 .../devicetree/bindings/net/mscc-miim.txt     |  2 +-
 drivers/net/mdio/mdio-mscc-miim.c             | 59 +++++++++++++------
 2 files changed, 42 insertions(+), 19 deletions(-)

-- 
2.30.2

[PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible

[Michael Walle]

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.

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"
 - reg: The base address of the MDIO bus controller register bank. Optionally, a
   second register bank can be defined if there is an associated reset register
   for internal PHYs
-- 
2.30.2

[PATCH net-next v2 2/3] net: mdio: mscc-miim: replace magic numbers for the bus reset

[Michael Walle]

Replace the magic numbers by macros which are already defined. It seems
the original commit missed to use them.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 drivers/net/mdio/mdio-mscc-miim.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mdio/mdio-mscc-miim.c b/drivers/net/mdio/mdio-mscc-miim.c
index 64fb76c1e395..7773d5019e66 100644
--- a/drivers/net/mdio/mdio-mscc-miim.c
+++ b/drivers/net/mdio/mdio-mscc-miim.c
@@ -158,18 +158,18 @@ static int mscc_miim_reset(struct mii_bus *bus)
 {
 	struct mscc_miim_dev *miim = bus->priv;
 	int offset = miim->phy_reset_offset;
+	int mask = PHY_CFG_PHY_ENA | PHY_CFG_PHY_COMMON_RESET |
+		   PHY_CFG_PHY_RESET;
 	int ret;
 
 	if (miim->phy_regs) {
-		ret = regmap_write(miim->phy_regs,
-				   MSCC_PHY_REG_PHY_CFG + offset, 0);
+		ret = regmap_write(miim->phy_regs, offset, 0);
 		if (ret < 0) {
 			WARN_ONCE(1, "mscc reset set error %d\n", ret);
 			return ret;
 		}
 
-		ret = regmap_write(miim->phy_regs,
-				   MSCC_PHY_REG_PHY_CFG + offset, 0x1ff);
+		ret = regmap_write(miim->phy_regs, offset, mask);
 		if (ret < 0) {
 			WARN_ONCE(1, "mscc reset clear error %d\n", ret);
 			return ret;
@@ -272,7 +272,7 @@ static int mscc_miim_probe(struct platform_device *pdev)
 
 	miim = bus->priv;
 	miim->phy_regs = phy_regmap;
-	miim->phy_reset_offset = 0;
+	miim->phy_reset_offset = MSCC_PHY_REG_PHY_CFG;
 
 	ret = of_mdiobus_register(bus, pdev->dev.of_node);
 	if (ret < 0) {
-- 
2.30.2

[PATCH net-next v2 3/3] net: mdio: mscc-miim: add lan966x internal phy reset support

[Michael Walle]

The LAN966x has two internal PHYs which are in reset by default. The
driver already supported the internal PHYs of the SparX-5. Now add
support for the LAN966x, too. Add a new compatible to distinguish them.

The LAN966x has additional control bits in this register, thus convert
the regmap_write() to regmap_update_bits() to leave the remaining bits
untouched. This doesn't change anything for the SparX-5 SoC, because
there, the register consists only of reset bits.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 drivers/net/mdio/mdio-mscc-miim.c | 59 +++++++++++++++++++++----------
 1 file changed, 41 insertions(+), 18 deletions(-)

diff --git a/drivers/net/mdio/mdio-mscc-miim.c b/drivers/net/mdio/mdio-mscc-miim.c
index 7773d5019e66..d082a13d9af3 100644
--- a/drivers/net/mdio/mdio-mscc-miim.c
+++ b/drivers/net/mdio/mdio-mscc-miim.c
@@ -15,6 +15,7 @@
 #include <linux/of_mdio.h>
 #include <linux/phy.h>
 #include <linux/platform_device.h>
+#include <linux/property.h>
 #include <linux/regmap.h>
 
 #define MSCC_MIIM_REG_STATUS		0x0
@@ -36,11 +37,19 @@
 #define		PHY_CFG_PHY_RESET	(BIT(5) | BIT(6) | BIT(7) | BIT(8))
 #define MSCC_PHY_REG_PHY_STATUS	0x4
 
+#define LAN966X_CUPHY_COMMON_CFG	0x0
+#define		CUPHY_COMMON_CFG_RESET_N	BIT(0)
+
+struct mscc_miim_info {
+	unsigned int phy_reset_offset;
+	unsigned int phy_reset_mask;
+};
+
 struct mscc_miim_dev {
 	struct regmap *regs;
 	int mii_status_offset;
 	struct regmap *phy_regs;
-	int phy_reset_offset;
+	const struct mscc_miim_info *info;
 };
 
 /* When high resolution timers aren't built-in: we can't use usleep_range() as
@@ -157,27 +166,29 @@ static int mscc_miim_write(struct mii_bus *bus, int mii_id,
 static int mscc_miim_reset(struct mii_bus *bus)
 {
 	struct mscc_miim_dev *miim = bus->priv;
-	int offset = miim->phy_reset_offset;
-	int mask = PHY_CFG_PHY_ENA | PHY_CFG_PHY_COMMON_RESET |
-		   PHY_CFG_PHY_RESET;
+	unsigned int offset, mask;
 	int ret;
 
-	if (miim->phy_regs) {
-		ret = regmap_write(miim->phy_regs, offset, 0);
-		if (ret < 0) {
-			WARN_ONCE(1, "mscc reset set error %d\n", ret);
-			return ret;
-		}
+	if (!miim->phy_regs || !miim->info)
+		return 0;
 
-		ret = regmap_write(miim->phy_regs, offset, mask);
-		if (ret < 0) {
-			WARN_ONCE(1, "mscc reset clear error %d\n", ret);
-			return ret;
-		}
+	offset = miim->info->phy_reset_offset;
+	mask = miim->info->phy_reset_mask;
+
+	ret = regmap_update_bits(miim->phy_regs, offset, mask, 0);
+	if (ret < 0) {
+		WARN_ONCE(1, "mscc reset set error %d\n", ret);
+		return ret;
+	}
 
-		mdelay(500);
+	ret = regmap_update_bits(miim->phy_regs, offset, mask, mask);
+	if (ret < 0) {
+		WARN_ONCE(1, "mscc reset clear error %d\n", ret);
+		return ret;
 	}
 
+	mdelay(500);
+
 	return 0;
 }
 
@@ -272,7 +283,7 @@ static int mscc_miim_probe(struct platform_device *pdev)
 
 	miim = bus->priv;
 	miim->phy_regs = phy_regmap;
-	miim->phy_reset_offset = MSCC_PHY_REG_PHY_CFG;
+	miim->info = device_get_match_data(&pdev->dev);
 
 	ret = of_mdiobus_register(bus, pdev->dev.of_node);
 	if (ret < 0) {
@@ -294,8 +305,20 @@ static int mscc_miim_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct mscc_miim_info mscc_ocelot_miim_info = {
+	.phy_reset_offset = MSCC_PHY_REG_PHY_CFG,
+	.phy_reset_mask = PHY_CFG_PHY_ENA | PHY_CFG_PHY_COMMON_RESET |
+			  PHY_CFG_PHY_RESET,
+};
+
+static const struct mscc_miim_info mscc_lan966x_miim_info = {
+	.phy_reset_offset = LAN966X_CUPHY_COMMON_CFG,
+	.phy_reset_mask = CUPHY_COMMON_CFG_RESET_N,
+};
+
 static const struct of_device_id mscc_miim_match[] = {
-	{ .compatible = "mscc,ocelot-miim" },
+	{ .compatible = "mscc,ocelot-miim", .data = &mscc_ocelot_miim_info },
+	{ .compatible = "mscc,lan966x-miim", .data = &mscc_lan966x_miim_info },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, mscc_miim_match);
-- 
2.30.2

Re: [PATCH net-next v2 0/3] net: mscc-miim: add integrated PHY reset support

[Andrew Lunn]

On Sun, Mar 13, 2022 at 01:25:33AM +0100, Michael Walle wrote:
> The MDIO driver has support to release the integrated PHYs from reset.
> This was implemented for the SparX-5 for now. Now add support for the
> LAN966x, too.
> 
> changes since v1:
>  - fix typo in the subject in patch 3/3

Please don't repost so quickly. It would been better to just reply to
yourself saying you had spotted the typo, and will repost in a day or
two once people had had chance to review the code.

    Andrew

Re: [PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible

[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.
> 
> 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.

Best regards,
Krzysztof

Re: [PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible

[Michael Walle]

Hi Krzysztof,

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.
>> 
>> 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") ;)

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?

-michael

[1] 
https://lore.kernel.org/lkml/CAK8P3a2kRhCOoXnvcMyqS-zK2WDZjtUq4aqOzE5VV=VMg=pVOA@mail.gmail.com/

Re: [PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible

[Krzysztof Kozlowski]

On 13/03/2022 11:47, Michael Walle wrote:
> Hi Krzysztof,
> 
> 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".

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.

> 
> 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,').


Best regards,
Krzysztof

Re: [PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible

[Michael Walle]

[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.

> 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

Re: [PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible

[Krzysztof Kozlowski]

On 13/03/2022 17:30, Michael Walle wrote:
> [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.

Sure.

Best regards,
Krzysztof

Re: [PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible

[Horatiu Vultur]

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