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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D8PITUNTWTXA.366TNSXDUL48G@bootlin.com>
Date: Tue, 25 Mar 2025 18:25:35 +0100
From: Théo Lebrun <theo.lebrun@...tlin.com>
To: "Claudiu Beznea" <claudiu.beznea@...on.dev>, "Andrew Lunn"
 <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, "Eric
 Dumazet" <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>, "Paolo
 Abeni" <pabeni@...hat.com>, "Rob Herring" <robh@...nel.org>, "Krzysztof
 Kozlowski" <krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>,
 "Nicolas Ferre" <nicolas.ferre@...rochip.com>, "Paul Walmsley"
 <paul.walmsley@...ive.com>, "Palmer Dabbelt" <palmer@...belt.com>, "Albert
 Ou" <aou@...s.berkeley.edu>, "Alexandre Ghiti" <alex@...ti.fr>, "Samuel
 Holland" <samuel.holland@...ive.com>, "Richard Cochran"
 <richardcochran@...il.com>, "Russell King" <linux@...linux.org.uk>, "Thomas
 Bogendoerfer" <tsbogend@...ha.franken.de>, "Vladimir Kondratiev"
 <vladimir.kondratiev@...ileye.com>, "Gregory CLEMENT"
 <gregory.clement@...tlin.com>
Cc: <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <linux-riscv@...ts.infradead.org>,
 <linux-mips@...r.kernel.org>, "Thomas Petazzoni"
 <thomas.petazzoni@...tlin.com>, "Tawfik Bayouk"
 <tawfik.bayouk@...ileye.com>
Subject: Re: [PATCH net-next 10/13] net: macb: Add "mobileye,eyeq5-gem"
 compatible

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@...tlin.com>
>> ---
>>  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