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

Claudiu Beznea
2025-03-27T08:17:17Z

Hi, Theo,

On 25.03.2025 19:25, Théo Lebrun wrote:
>>> + }
>>> +
>>> + 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 macb is used by various platforms. If the settings proposed in this
patch (platform specific AFAICT) could be abstracted and used with generic
APIs I think would be better this way.

>
> The main reason for that boilerplate is to allow reuse of a PHY
> across MACs;

And/or avoid having platform specific code in the macb driver.

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

This looks complicated to me.

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

For maintainability I would prefer to avoid this.

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

I prefer (1) if it can be done.

Thank you,
Claudiu