Re: [PATCH net-next 10/13] net: macb: Add "mobileye,eyeq5-gem" compatible

From: Théo Lebrun
Date: Tue Mar 25 2025 - 13:26:03 EST

On Mon Mar 24, 2025 at 9:18 AM CET, Claudiu Beznea wrote:
> On 21.03.2025 21:09, Théo Lebrun wrote:
>> Add support for the two GEM instances inside Mobileye EyeQ5 SoCs, using
>> compatible "mobileye,eyeq5-gem". With it, add a custom init sequence
>> that accesses two system-controller registers.
>>
>> Noteworthy: NET_IP_ALIGN=2 on MIPS but the hardware does not align and
>> low bits aren't configurable, so we cannot respect the requested IP
>> header alignment.
>>
>> Signed-off-by: Théo Lebrun <theo.lebrun@xxxxxxxxxxx>
>> ---
>> drivers/net/ethernet/cadence/macb_main.c | 95 ++++++++++++++++++++++++++++++++
>> 1 file changed, 95 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
>> index 79161d559166478f85a6f8294d488ed961d9be7f..9f2a5bf9a5ebca5941229bd96091a0fb96f0607d 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c

[...]

>> +static int eyeq5_init(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct net_device *netdev = platform_get_drvdata(pdev);
>> + struct macb *bp = netdev_priv(netdev);
>> + struct device_node *np = dev->of_node;
>> + unsigned int gp, sgmii;
>> + struct regmap *regmap;
>> + unsigned int args[2];
>> + unsigned int reg;
>> + int ret;
>> +
>> + regmap = syscon_regmap_lookup_by_phandle_args(np, "mobileye,olb", 2, args);
>> + if (IS_ERR(regmap))
>> + return PTR_ERR(regmap);
>> +
>> + gp = args[0];
>> + sgmii = args[1];
>> +
>> + /* Forced reset */
>> + regmap_write(regmap, gp, 0);
>> + regmap_write(regmap, sgmii, 0);
>> + usleep_range(5, 20);
>> +
>> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
>> + regmap_write(regmap, gp, EYEQ5_OLB_GP_SGMII_MODE);
>> +
>> + reg = EYEQ5_OLB_SGMII_PWR_EN | EYEQ5_OLB_SGMII_RST_DIS |
>> + EYEQ5_OLB_SGMII_PLL_EN;
>> + regmap_write(regmap, sgmii, reg);
>> +
>> + ret = regmap_read_poll_timeout(regmap, sgmii, reg,
>> + reg & EYEQ5_OLB_SGMII_PLL_ACK,
>> + 1, 100);
>> + if (ret)
>> + return dev_err_probe(dev, ret, "PLL timeout");
>> +
>> + regmap_read(regmap, sgmii, &reg);
>> + reg |= EYEQ5_OLB_SGMII_PWR_STATE | EYEQ5_OLB_SGMII_SIG_DET_SW;
>> + regmap_write(regmap, sgmii, reg);
>
> You can use regmap_update_bits() here.
>
>> + }
>> +
>> + regmap_read(regmap, gp, &reg);
>> + reg &= ~EYEQ5_OLB_GP_RGMII_DRV;
>> + if (phy_interface_mode_is_rgmii(bp->phy_interface))
>> + reg |= FIELD_PREP(EYEQ5_OLB_GP_RGMII_DRV, 0x9);
>> + reg |= EYEQ5_OLB_GP_TX_SWRST_DIS | EYEQ5_OLB_GP_TX_M_CLKE;
>> + reg |= EYEQ5_OLB_GP_SYS_SWRST_DIS | EYEQ5_OLB_GP_SYS_M_CLKE;
>> + regmap_write(regmap, gp, reg);
>
> To me it looks like this code could be abstracted as a phy driver. E.g.,
> check the init_reset_optional() and its usage on "cdns,zynqmp-gem" (phy
> driver here: drivers/phy/xilinx/phy-zynqmp.c).

I thought about that question. Options to implement that sequence are:

- (1) Implement a separate PHY driver, what you are proposing. I just
made a prototype branch to see what it'd look like. Nothing too
surprising; mostly the above sequence is copy-pasted inside
phy_init|power_on(). I see two issues:

- First, a practical one. This adds a lot of boilerplate for no
obvious benefit compared to a raw registers read/write sequence
inside macb_config->init().

The main reason for that boilerplate is to allow reuse of a PHY
across MACs; here we already know that cannot be useful because
the EyeQ5 has two GEMs and nothing else. Those registers are
EyeQ5-specific.

- Second, a semantic one. The registers we are touching are *not*
the PHY's registers. They are configuring the PHY's integration:
its input PLL, resets, etc.

- (2) Second, taking into account that what we are configuring isn't
the PHY itself but its resources, we could try modeling each
individual register+field as a reset / clock / pin control (there is
some drive strength in here, *I think*). Issue: this would get
messy, fast.
- A single register would expose many resources.
- The sequence in macb_config->init() would need to be the exact
same order. IE we can't abstract much.

Something like this pseudocode (which is a bad idea, we'd all agree
here):

reset_deassert(bp->eq5_sgmii_reset);
reset_deassert(bp->eq5_sgmii_reset_pwr);
reset_deassert(bp->eq5_phy_reset_tx);
reset_deassert(bp->eq5_phy_reset_sys);

if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
pinctrl_select_state(bp->eq5_phy_input_pinctrl, bp->eq5_pins_sgmii);

reset_deassert(bp->eq5_sgmii_reset);
clk_prepare_enable(bp->eq5_sgmii_phy_input_pll);

reset_deassert(bp->eq5_sgmii_reset_pwr);
} else {
pinctrl_select_state(bp->eq5_pinctrl, bp->eq5_pins_rgmii);
}

reset_deassert(bp->eq5_phy_reset_tx);
reset_deassert(bp->eq5_phy_reset_sys);
clk_prepare_enable(bp->eq5_phy_mclk_tx);
clk_prepare_enable(bp->eq5_phy_mclk_sys);

- (3) Keep the sequence in macb_config->init(). Plain and simple.
- Issue: it is somewhat unrelated platform-specific code that's
present inside macb_main.c.

The two serious options are (1) and (3).
(1) is what you proposed and (3) is what's in the series.

>> static const struct of_device_id macb_dt_ids[] = {
>> { .compatible = "cdns,at91sam9260-macb", .data = &at91sam9260_config },
>> { .compatible = "cdns,macb" },
>> @@ -5152,6 +5246,7 @@ static const struct of_device_id macb_dt_ids[] = {
>> { .compatible = "cdns,zynqmp-gem", .data = &zynqmp_config}, /* deprecated */
>> { .compatible = "cdns,zynq-gem", .data = &zynq_config }, /* deprecated */
>> { .compatible = "sifive,fu540-c000-gem", .data = &fu540_c000_config },
>> + { .compatible = "mobileye,eyeq5-gem", .data = &eyeq5_config },
>
> Maybe move it after microchip to have it a bit sorted.

Argh those semi sorted lists. I saw "cdns" then "atmel" then "cdns" so I
ignored sorting.

Thanks for the review!

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