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

Hi, Theo,

On 25.03.2025 19:25, Théo Lebrun wrote:

quoted

quoted

+	}
+
+	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