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

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

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

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
>