[PATCH net-next v3 0/3] Initial support for PIC64-HPSC/HX Ethernet endpoint

[PATCH net-next v3 0/3] Initial support for PIC64-HPSC/HX Ethernet endpoint

[Charles Perry]

Hello,

This series add basic support for Microchip "PIC64-HPSC" and "PIC64HX"
Ethernet endpoint. Both SoCs contain 4 GEM IP with support for
MII/RGMII/SGMII/USXGMII at rates of 10M to 10G. Only RGMII and SGMII at a
rate of 1G is tested for now. Each GEM IP has 8 priority queues and the
revision register reads 0x220c010e.

One particularity of this instantiation of GEM is that the MDIO controller
within the GEM IP is disconnected from any physical pin and the SoC rely on
another standalone MDIO controller.

The maximum jumbo frame size also seems to be different on PIC64-HPSC/HX
(16383) than what most other platforms use (10240). I've found that I need
to tweak a bit the MTU calculation for this, otherwise the RXBS field of
the DMACFG register overflows. See patch 2 for more details.

PIC64-HPSC/HX also supports other features guarded behind CAPS bit like
MACB_CAPS_QBV but I've omitted those intentionally because I didn't test
these.

Thanks,
Charles

Changes in v3:
  - Fix one more "p64h" -> "pic64hpsc"
  - Remove .clk_init assignation since it's no longer required (patch 3)

Changes in v2:
  - Use separate compatibles for PIC64-HPSC and PIC64HX
  - "p64h" -> "pic64hpsc"
  - Merge patch 2 into patch 1

Charles Perry (3):
  dt-bindings: net: cdns,macb: add a compatible for Microchip pic64hpsc
  net: macb: add safeguards for jumbo frame larger than 10240
  net: macb: add support for Microchip pic64hpsc ethernet endpoint

 .../devicetree/bindings/net/cdns,macb.yaml    | 19 +++++++++++++++++++
 drivers/net/ethernet/cadence/macb_main.c      | 15 +++++++++++++--
 2 files changed, 32 insertions(+), 2 deletions(-)

-- 
2.47.3

[PATCH net-next v3 1/3] dt-bindings: net: cdns,macb: add a compatible for Microchip pic64hpsc

[Charles Perry]

Add "microchip,pic64hpsc-gem" for "PIC64-HPSC" and
"microchip,pic64hx-gem" for "PIC64HX", compatible with the former.

The generic compatible "cdns,gem" works but offers limited features.
Keep it as a fallback.

The GEM IPs within pic64hpsc have their MDIO controllers unconnected
from any physical pin. Add a check to prevent adding PHYs under the GEM
node.

Signed-off-by: Charles Perry <charles.perry@microchip.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
 .../devicetree/bindings/net/cdns,macb.yaml    | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml
index cb14c35ba996..feb168385837 100644
--- a/Documentation/devicetree/bindings/net/cdns,macb.yaml
+++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml
@@ -70,6 +70,14 @@ properties:
               - microchip,sama7d65-gem   # Microchip SAMA7D65 gigabit ethernet interface
           - const: microchip,sama7g5-gem # Microchip SAMA7G5 gigabit ethernet interface
 
+      - items:
+          - const: microchip,pic64hpsc-gem # Microchip PIC64-HPSC
+          - const: cdns,gem
+      - items:
+          - const: microchip,pic64hx-gem   # Microchip PIC64HX
+          - const: microchip,pic64hpsc-gem # Microchip PIC64-HPSC
+          - const: cdns,gem
+
   reg:
     minItems: 1
     items:
@@ -196,6 +204,17 @@ allOf:
       required:
         - phys
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: microchip,pic64hpsc-gem
+    then:
+      patternProperties:
+        "^ethernet-phy@[0-9a-f]$": false
+      properties:
+        mdio: false
+
 unevaluatedProperties: false
 
 examples:
-- 
2.47.3

Re: [PATCH net-next v3 1/3] dt-bindings: net: cdns,macb: add a compatible for Microchip pic64hpsc

[Théo Lebrun]

On Fri Mar 13, 2026 at 3:06 PM CET, Charles Perry wrote:
> Add "microchip,pic64hpsc-gem" for "PIC64-HPSC" and
> "microchip,pic64hx-gem" for "PIC64HX", compatible with the former.
>
> The generic compatible "cdns,gem" works but offers limited features.
> Keep it as a fallback.
>
> The GEM IPs within pic64hpsc have their MDIO controllers unconnected
> from any physical pin. Add a check to prevent adding PHYs under the GEM
> node.
>
> Signed-off-by: Charles Perry <charles.perry@microchip.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>  .../devicetree/bindings/net/cdns,macb.yaml    | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)

Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[PATCH net-next v3 2/3] net: macb: add safeguards for jumbo frame larger than 10240

[Charles Perry]

The RX buffers for GEM can have a maximum size of 16320 bytes
(0xff in the RXBS field of the DMACFG register means 255*64 =
16320 bytes).

The GEM IP has configurable maximum jumbo frame length that can go up to
16383. The actual value for this limit can be found in the
       "jumbo_max_length" field (bits 0..13) of the DCFG2 register.
Currently, the macb driver doesn't use the DCFG2 register when
determining the max MTU, instead an hardcoded value (jumbo_max_len in
struct macb_config) is used for each platform. Right now the maximum
value for jumbo_max_len is 10240 (0x2800).

GEM uses one buffer per packet which means that one buffer must allow
room for the max MTU plus L2 encapsulation and alignment. This is a
limitation of the driver.

This commit adds a limit to max_mtu and rx_buffer_size so that the RXBS
field can never overflow when a large MTU is used.

With this commit, it is now possible to add new platforms with a
jumbo_max_len of 16383 so that the hardware properties of each IP can be
properly captured in struct macb_config.

Signed-off-by: Charles Perry <charles.perry@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
---
 drivers/net/ethernet/cadence/macb_main.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 32f9463edff0..c653ea6cadef 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -52,6 +52,7 @@ struct sifive_fu540_macb_mgmt {
 
 #define MACB_RX_BUFFER_SIZE	128
 #define RX_BUFFER_MULTIPLE	64  /* bytes */
+#define RX_BUFFER_MAX		(0xFF * RX_BUFFER_MULTIPLE) /* 16320 bytes */
 
 #define DEFAULT_RX_RING_SIZE	512 /* must be power of 2 */
 #define MIN_RX_RING_SIZE	64
@@ -2603,7 +2604,7 @@ static void macb_init_rx_buffer_size(struct macb *bp, size_t size)
 	if (!macb_is_gem(bp)) {
 		bp->rx_buffer_size = MACB_RX_BUFFER_SIZE;
 	} else {
-		bp->rx_buffer_size = size;
+		bp->rx_buffer_size = MIN(size, RX_BUFFER_MAX);
 
 		if (bp->rx_buffer_size % RX_BUFFER_MULTIPLE) {
 			netdev_dbg(bp->dev,
@@ -5794,7 +5795,8 @@ static int macb_probe(struct platform_device *pdev)
 	/* MTU range: 68 - 1518 or 10240 */
 	dev->min_mtu = GEM_MTU_MIN_SIZE;
 	if ((bp->caps & MACB_CAPS_JUMBO) && bp->jumbo_max_len)
-		dev->max_mtu = bp->jumbo_max_len - ETH_HLEN - ETH_FCS_LEN;
+		dev->max_mtu = MIN(bp->jumbo_max_len, RX_BUFFER_MAX) -
+				ETH_HLEN - ETH_FCS_LEN;
 	else
 		dev->max_mtu = 1536 - ETH_HLEN - ETH_FCS_LEN;
 
-- 
2.47.3

Re: [PATCH net-next v3 2/3] net: macb: add safeguards for jumbo frame larger than 10240

[Théo Lebrun]

Hello Charles,

On Fri Mar 13, 2026 at 3:06 PM CET, Charles Perry wrote:
> The RX buffers for GEM can have a maximum size of 16320 bytes
> (0xff in the RXBS field of the DMACFG register means 255*64 =
> 16320 bytes).
>
> The GEM IP has configurable maximum jumbo frame length that can go up to
> 16383. The actual value for this limit can be found in the
>        "jumbo_max_length" field (bits 0..13) of the DCFG2 register.
> Currently, the macb driver doesn't use the DCFG2 register when
> determining the max MTU, instead an hardcoded value (jumbo_max_len in
> struct macb_config) is used for each platform. Right now the maximum
> value for jumbo_max_len is 10240 (0x2800).

If DCFG2 contains the value then we can runtime detect it. With that, we
could make the macb_config->jumbo_max_len attribute optional. Then
start dropping it from platforms where we know we can trust the DCFG2
value.

An alternative would be to validate macb_config->jumbo_max_len against
the DCFG2 value, but that is less useful.

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH net-next v3 2/3] net: macb: add safeguards for jumbo frame larger than 10240

[Charles Perry]

On Mon, Mar 16, 2026 at 06:21:38PM +0100, Théo Lebrun wrote:
> Hello Charles,
> 
> On Fri Mar 13, 2026 at 3:06 PM CET, Charles Perry wrote:
> > The RX buffers for GEM can have a maximum size of 16320 bytes
> > (0xff in the RXBS field of the DMACFG register means 255*64 =
> > 16320 bytes).
> >
> > The GEM IP has configurable maximum jumbo frame length that can go up to
> > 16383. The actual value for this limit can be found in the
> >        "jumbo_max_length" field (bits 0..13) of the DCFG2 register.
> > Currently, the macb driver doesn't use the DCFG2 register when
> > determining the max MTU, instead an hardcoded value (jumbo_max_len in
> > struct macb_config) is used for each platform. Right now the maximum
> > value for jumbo_max_len is 10240 (0x2800).
> 
> If DCFG2 contains the value then we can runtime detect it. With that, we
> could make the macb_config->jumbo_max_len attribute optional. Then
> start dropping it from platforms where we know we can trust the DCFG2
> value.
> 

Hello Théo,

That would be a good idea. We could use "jumbo_max_len == 0" as a way to
signal that the DCFG2 register should be used for determining the max MTU.

However, that's a new feature and it doesn't belong in this patch. All I
want to do in this patchset is put the real value of jumbo_max_length in
the PIC64-HPSC macb_config and make sure the driver doesn't overflow when
that's used.

Thanks,
Charles

> An alternative would be to validate macb_config->jumbo_max_len against
> the DCFG2 value, but that is less useful.
> 
> Thanks,
> 
> --
> Théo Lebrun, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 

Re: [PATCH net-next v3 2/3] net: macb: add safeguards for jumbo frame larger than 10240

[Paolo Abeni]

On 3/16/26 7:26 PM, Charles Perry wrote:
> On Mon, Mar 16, 2026 at 06:21:38PM +0100, Théo Lebrun wrote:
>> Hello Charles,
>>
>> On Fri Mar 13, 2026 at 3:06 PM CET, Charles Perry wrote:
>>> The RX buffers for GEM can have a maximum size of 16320 bytes
>>> (0xff in the RXBS field of the DMACFG register means 255*64 =
>>> 16320 bytes).
>>>
>>> The GEM IP has configurable maximum jumbo frame length that can go up to
>>> 16383. The actual value for this limit can be found in the
>>>        "jumbo_max_length" field (bits 0..13) of the DCFG2 register.
>>> Currently, the macb driver doesn't use the DCFG2 register when
>>> determining the max MTU, instead an hardcoded value (jumbo_max_len in
>>> struct macb_config) is used for each platform. Right now the maximum
>>> value for jumbo_max_len is 10240 (0x2800).
>>
>> If DCFG2 contains the value then we can runtime detect it. With that, we
>> could make the macb_config->jumbo_max_len attribute optional. Then
>> start dropping it from platforms where we know we can trust the DCFG2
>> value.
>>
> 
> Hello Théo,
> 
> That would be a good idea. We could use "jumbo_max_len == 0" as a way to
> signal that the DCFG2 register should be used for determining the max MTU.
> 
> However, that's a new feature and it doesn't belong in this patch. All I
> want to do in this patchset is put the real value of jumbo_max_length in
> the PIC64-HPSC macb_config and make sure the driver doesn't overflow when
> that's used.

FWIW, I agree that is better suited for a follow-up than for the initial
bring-up.

/P

Re: [PATCH net-next v3 2/3] net: macb: add safeguards for jumbo frame larger than 10240

[Théo Lebrun]

On Tue Mar 17, 2026 at 1:29 PM CET, Paolo Abeni wrote:
> On 3/16/26 7:26 PM, Charles Perry wrote:
>> On Mon, Mar 16, 2026 at 06:21:38PM +0100, Théo Lebrun wrote:
>>> Hello Charles,
>>>
>>> On Fri Mar 13, 2026 at 3:06 PM CET, Charles Perry wrote:
>>>> The RX buffers for GEM can have a maximum size of 16320 bytes
>>>> (0xff in the RXBS field of the DMACFG register means 255*64 =
>>>> 16320 bytes).
>>>>
>>>> The GEM IP has configurable maximum jumbo frame length that can go up to
>>>> 16383. The actual value for this limit can be found in the
>>>>        "jumbo_max_length" field (bits 0..13) of the DCFG2 register.
>>>> Currently, the macb driver doesn't use the DCFG2 register when
>>>> determining the max MTU, instead an hardcoded value (jumbo_max_len in
>>>> struct macb_config) is used for each platform. Right now the maximum
>>>> value for jumbo_max_len is 10240 (0x2800).
>>>
>>> If DCFG2 contains the value then we can runtime detect it. With that, we
>>> could make the macb_config->jumbo_max_len attribute optional. Then
>>> start dropping it from platforms where we know we can trust the DCFG2
>>> value.
>>>
>> 
>> Hello Théo,
>> 
>> That would be a good idea. We could use "jumbo_max_len == 0" as a way to
>> signal that the DCFG2 register should be used for determining the max MTU.
>> 
>> However, that's a new feature and it doesn't belong in this patch. All I
>> want to do in this patchset is put the real value of jumbo_max_length in
>> the PIC64-HPSC macb_config and make sure the driver doesn't overflow when
>> that's used.
>
> FWIW, I agree that is better suited for a follow-up than for the initial
> bring-up.

then:

Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[PATCH net-next v3 3/3] net: macb: add support for Microchip pic64hpsc ethernet endpoint

[Charles Perry]

pic64hpsc doesn't have the USRIO register so MACB_CAPS_USRIO_DISABLED is
used.

pic64hpsc does support PTP and has the timestamping unit so
MACB_CAPS_GEM_HAS_PTP is used.

jumbo_max_len is set to 16383 (0x3FFF) as reported by the DCFG2 register
bits 0..13. The JML register also has a default value of 0x3FFF.

dma_burst_length is set to 16 because that's what most other platforms
use and it worked for me so far. There is one other mode where bursts of
up to 256 are allowed but this might impact negatively other masters on
the NOC.  The register default value is 4 (bursts up to 4).

Signed-off-by: Charles Perry <charles.perry@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
---
 drivers/net/ethernet/cadence/macb_main.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index c653ea6cadef..66939c5cf926 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -5626,6 +5626,14 @@ static const struct macb_config raspberrypi_rp1_config = {
 	.jumbo_max_len = 10240,
 };
 
+static const struct macb_config pic64hpsc_config = {
+	.caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO |
+		MACB_CAPS_GEM_HAS_PTP | MACB_CAPS_USRIO_DISABLED,
+	.dma_burst_length = 16,
+	.init = init_reset_optional,
+	.jumbo_max_len = 16383,
+};
+
 static const struct of_device_id macb_dt_ids[] = {
 	{ .compatible = "cdns,at91sam9260-macb", .data = &at91sam9260_config },
 	{ .compatible = "cdns,macb" },
@@ -5644,6 +5652,7 @@ static const struct of_device_id macb_dt_ids[] = {
 	{ .compatible = "cdns,zynq-gem", .data = &zynq_config }, /* deprecated */
 	{ .compatible = "sifive,fu540-c000-gem", .data = &fu540_c000_config },
 	{ .compatible = "microchip,mpfs-macb", .data = &mpfs_config },
+	{ .compatible = "microchip,pic64hpsc-gem", .data = &pic64hpsc_config},
 	{ .compatible = "microchip,sama7g5-gem", .data = &sama7g5_gem_config },
 	{ .compatible = "microchip,sama7g5-emac", .data = &sama7g5_emac_config },
 	{ .compatible = "mobileye,eyeq5-gem", .data = &eyeq5_config },
-- 
2.47.3

Re: [PATCH net-next v3 3/3] net: macb: add support for Microchip pic64hpsc ethernet endpoint

[Théo Lebrun]

On Fri Mar 13, 2026 at 3:06 PM CET, Charles Perry wrote:
> pic64hpsc doesn't have the USRIO register so MACB_CAPS_USRIO_DISABLED is
> used.
>
> pic64hpsc does support PTP and has the timestamping unit so
> MACB_CAPS_GEM_HAS_PTP is used.
>
> jumbo_max_len is set to 16383 (0x3FFF) as reported by the DCFG2 register
> bits 0..13. The JML register also has a default value of 0x3FFF.
>
> dma_burst_length is set to 16 because that's what most other platforms
> use and it worked for me so far. There is one other mode where bursts of
> up to 256 are allowed but this might impact negatively other masters on
> the NOC.  The register default value is 4 (bursts up to 4).
>
> Signed-off-by: Charles Perry <charles.perry@microchip.com>
> Reviewed-by: Simon Horman <horms@kernel.org>
> ---
>  drivers/net/ethernet/cadence/macb_main.c | 9 +++++++++
>  1 file changed, 9 insertions(+)

Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH net-next v3 0/3] Initial support for PIC64-HPSC/HX Ethernet endpoint

[Théo Lebrun]

Hello Charles,

On Fri Mar 13, 2026 at 3:06 PM CET, Charles Perry wrote:
> Hello,
>
> This series add basic support for Microchip "PIC64-HPSC" and "PIC64HX"
> Ethernet endpoint. Both SoCs contain 4 GEM IP with support for
> MII/RGMII/SGMII/USXGMII at rates of 10M to 10G. Only RGMII and SGMII at a
> rate of 1G is tested for now. Each GEM IP has 8 priority queues and the
> revision register reads 0x220c010e.

Do you have plans to test higher rate? We might get our hands on GEMs
that support >1G and would like to know if CCing you would make sense.

> One particularity of this instantiation of GEM is that the MDIO controller
> within the GEM IP is disconnected from any physical pin and the SoC rely on
> another standalone MDIO controller.

Ah, that means you instantiate the MDIO bus for no good reason.
Code looks like:

static int macb_mii_init(struct macb *bp)
{
	struct device_node *mdio_np, *np = bp->pdev->dev.of_node;
	int err = -ENXIO;

	/* With fixed-link, we don't need to register the MDIO bus,
	 * except if we have a child named "mdio" in the device tree.
	 * In that case, some devices may be attached to the MACB's MDIO bus.
	 */
	mdio_np = of_get_child_by_name(np, "mdio");
	if (!mdio_np && of_phy_is_fixed_link(np))
		return macb_mii_probe(bp->dev);

	// ... probe MDIO bus ...
}

So to *not* get the bus we need to be in fixed link config. Do you care
about that? I think that the proper fix would be to lazy probe the MDIO
bus until a PHY (ours or some other MAC's) asks for it.

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH net-next v3 0/3] Initial support for PIC64-HPSC/HX Ethernet endpoint

[Charles Perry]

On Mon, Mar 16, 2026 at 06:28:39PM +0100, Théo Lebrun wrote:
> Hello Charles,
> 
> On Fri Mar 13, 2026 at 3:06 PM CET, Charles Perry wrote:
> > Hello,
> >
> > This series add basic support for Microchip "PIC64-HPSC" and "PIC64HX"
> > Ethernet endpoint. Both SoCs contain 4 GEM IP with support for
> > MII/RGMII/SGMII/USXGMII at rates of 10M to 10G. Only RGMII and SGMII at a
> > rate of 1G is tested for now. Each GEM IP has 8 priority queues and the
> > revision register reads 0x220c010e.
> 
> Do you have plans to test higher rate? We might get our hands on GEMs
> that support >1G and would like to know if CCing you would make sense.

Yes. I don't have a 10G setup right now but that's definitively in my TODO
list for this year.

> 
> > One particularity of this instantiation of GEM is that the MDIO controller
> > within the GEM IP is disconnected from any physical pin and the SoC rely on
> > another standalone MDIO controller.
> 
> Ah, that means you instantiate the MDIO bus for no good reason.
> Code looks like:
> 
> static int macb_mii_init(struct macb *bp)
> {
> 	struct device_node *mdio_np, *np = bp->pdev->dev.of_node;
> 	int err = -ENXIO;
> 
> 	/* With fixed-link, we don't need to register the MDIO bus,
> 	 * except if we have a child named "mdio" in the device tree.
> 	 * In that case, some devices may be attached to the MACB's MDIO bus.
> 	 */
> 	mdio_np = of_get_child_by_name(np, "mdio");
> 	if (!mdio_np && of_phy_is_fixed_link(np))
> 		return macb_mii_probe(bp->dev);
> 
> 	// ... probe MDIO bus ...
> }
> 
> So to *not* get the bus we need to be in fixed link config. Do you care
> about that? I think that the proper fix would be to lazy probe the MDIO
> bus until a PHY (ours or some other MAC's) asks for it.

Yes, I do have a bunch of unusable MDIO buses in sysfs. It would be great
if those just didn't exist but that would be yet more code and one more
MACB_CAPS for little benefit IMO.

As for the fixed link, I can't specify that just to not instantiate the
MDIO bus because that would cause other problems since my link has a PHY
with a negotiated rate/duplex/etc.

Thanks,
Charles

> 
> Thanks,
> 
> --
> Théo Lebrun, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 

Re: [PATCH net-next v3 0/3] Initial support for PIC64-HPSC/HX Ethernet endpoint

[Paolo Abeni]

On 3/16/26 6:28 PM, Théo Lebrun wrote:
> On Fri Mar 13, 2026 at 3:06 PM CET, Charles Perry wrote:
>> Hello,
>>
>> This series add basic support for Microchip "PIC64-HPSC" and "PIC64HX"
>> Ethernet endpoint. Both SoCs contain 4 GEM IP with support for
>> MII/RGMII/SGMII/USXGMII at rates of 10M to 10G. Only RGMII and SGMII at a
>> rate of 1G is tested for now. Each GEM IP has 8 priority queues and the
>> revision register reads 0x220c010e.
> 
> Do you have plans to test higher rate? We might get our hands on GEMs
> that support >1G and would like to know if CCing you would make sense.
> 
>> One particularity of this instantiation of GEM is that the MDIO controller
>> within the GEM IP is disconnected from any physical pin and the SoC rely on
>> another standalone MDIO controller.
> 
> Ah, that means you instantiate the MDIO bus for no good reason.
> Code looks like:
> 
> static int macb_mii_init(struct macb *bp)
> {
> 	struct device_node *mdio_np, *np = bp->pdev->dev.of_node;
> 	int err = -ENXIO;
> 
> 	/* With fixed-link, we don't need to register the MDIO bus,
> 	 * except if we have a child named "mdio" in the device tree.
> 	 * In that case, some devices may be attached to the MACB's MDIO bus.
> 	 */
> 	mdio_np = of_get_child_by_name(np, "mdio");
> 	if (!mdio_np && of_phy_is_fixed_link(np))
> 		return macb_mii_probe(bp->dev);
> 
> 	// ... probe MDIO bus ...
> }
> 
> So to *not* get the bus we need to be in fixed link config. Do you care
> about that? I think that the proper fix would be to lazy probe the MDIO
> bus until a PHY (ours or some other MAC's) asks for it.

I think that even this one could be a follow-up patch.

Thanks,

Paolo

Re: [PATCH net-next v3 0/3] Initial support for PIC64-HPSC/HX Ethernet endpoint

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Fri, 13 Mar 2026 07:06:07 -0700 you wrote:
> Hello,
> 
> This series add basic support for Microchip "PIC64-HPSC" and "PIC64HX"
> Ethernet endpoint. Both SoCs contain 4 GEM IP with support for
> MII/RGMII/SGMII/USXGMII at rates of 10M to 10G. Only RGMII and SGMII at a
> rate of 1G is tested for now. Each GEM IP has 8 priority queues and the
> revision register reads 0x220c010e.
> 
> [...]

Here is the summary with links:
  - [net-next,v3,1/3] dt-bindings: net: cdns,macb: add a compatible for Microchip pic64hpsc
    https://git.kernel.org/netdev/net-next/c/63e9d434ddc8
  - [net-next,v3,2/3] net: macb: add safeguards for jumbo frame larger than 10240
    https://git.kernel.org/netdev/net-next/c/363a99af19a7
  - [net-next,v3,3/3] net: macb: add support for Microchip pic64hpsc ethernet endpoint
    https://git.kernel.org/netdev/net-next/c/f45797fe02df

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html