All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>, Jia Wang <wangjia@ultrarisc.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next 3/3] net: stmmac: Add UltraRISC DP1000 GMAC support
Date: Thu, 3 Sep 2026 14:30:39 +0200	[thread overview]
Message-ID: <8611dff3-56ea-4798-8303-b0a8af84580e@bootlin.com> (raw)
In-Reply-To: <1622b0a7-5516-4e72-b5e1-60c12b65b52e@lunn.ch>



On 9/3/26 14:10, Andrew Lunn wrote:
>>> This looks to be 90% identical to dwmac-sophgo.c.
>>>
>>> Do you expect any further changes to this driver? Is everything
>>> supported? Are there more clocks? A GPIO for WoL?
>>>
>>> I'm just wondering if the common code should be pulled out, or even
>>> dwmac-sophgo.c made generic so it can handle all plain boring devices
>>> which have RGMII delays and not a lot else.
>>>
>>
>> The probe boilerplate is indeed largely similar because both drivers
>> use the common stmmac platform helpers. However, their platform-specific
>> requirements differ: Sophgo requires additional TX clock handling and
>> other configuration, while DP1000 requires fixed TX and RX delay
>> handling. ACPI support under development is also intended to use the
>> UltraRISC glue driver.
> 
> ACPI is going to be fun, since nobody does ACPI networking.
> 
> But how big is the change to the glue driver? I expect the change will
> be minor, a call to devm_stmmac_probe_config_acpi(), in addition to
> devm_stmmac_probe_config_dt(). Anything else?

I agree that if ACPI support is added, let's try to make it part of the
core.

> 
> One problem the stmmac driver has is cut/paste glue driver
> development. The same code is repeated again and again. Russell King
> spent a lot of time and effort trying to reduce the duplication. So we
> should not be adding more duplicated code unless it is actually
> required.

It seems to me that all the RGMII handling could be made much more generic,
as this is commong pattern in glue drivers :

dwmac-sophgo has the "has_internal_rx_delay" field, and dwmac-eic7700 has
both has_internal_[r|t]x_delay.

With this third one, it makes sense to start sharing that logic across
glues.

Maxime


  reply	other threads:[~2026-09-03 12:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01  1:27 [PATCH net-next 0/3] net: stmmac: Add UltraRISC DP1000 GMAC support Jia Wang
2026-09-01  1:27 ` [PATCH net-next 1/3] dt-bindings: net: snps,dwmac: Add UltraRISC DP1000 compatible Jia Wang
2026-09-01 17:46   ` Conor Dooley
2026-09-02  9:35     ` Jia Wang
2026-09-01  1:27 ` [PATCH net-next 2/3] dt-bindings: net: Add UltraRISC DP1000 GMAC Jia Wang
2026-09-01 17:47   ` Conor Dooley
2026-09-01  1:27 ` [PATCH net-next 3/3] net: stmmac: Add UltraRISC DP1000 GMAC support Jia Wang
2026-09-01  7:29   ` Maxime Chevallier
2026-09-01  8:32     ` Jia Wang
2026-09-01  9:05       ` Maxime Chevallier
2026-09-01 13:48   ` Andrew Lunn
2026-09-03  7:47     ` Jia Wang
2026-09-03 12:10       ` Andrew Lunn
2026-09-03 12:30         ` Maxime Chevallier [this message]
2026-09-04  6:01           ` Jia Wang
2026-09-07  5:48             ` Jia Wang
2026-09-07  7:28               ` Maxime Chevallier
2026-09-07  7:36                 ` Jia Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8611dff3-56ea-4798-8303-b0a8af84580e@bootlin.com \
    --to=maxime.chevallier@bootlin.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=joabreu@synopsys.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=peppe.cavallaro@st.com \
    --cc=robh@kernel.org \
    --cc=wangjia@ultrarisc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.