From: Vivian Wang <wangruikang@iscas.ac.cn>
To: Troy Mitchell <troy.mitchell@linux.spacemit.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Jakub Kicinski <kuba@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Yixun Lan <dlan@gentoo.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>
Cc: Vivian Wang <uwu@dram.page>,
Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Junhui Liu <junhui.liu@pigmoral.tech>,
Simon Horman <horms@kernel.org>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-riscv@lists.infradead.org, spacemit@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v7 2/5] net: spacemit: Add K1 Ethernet MAC
Date: Thu, 28 Aug 2025 16:06:58 +0800 [thread overview]
Message-ID: <6c221dcf-4310-4e31-b3e8-a8a3b68c3734@iscas.ac.cn> (raw)
In-Reply-To: <193454B6B44560D1+aK-x9J2EIB5aA9yr@LT-Guozexi>
Hi Troy,
On 8/28/25 09:33, Troy Mitchell wrote:
> On Tue, Aug 26, 2025 at 02:23:47PM +0800, Vivian Wang wrote:
>> The Ethernet MACs found on SpacemiT K1 appears to be a custom design
>> that only superficially resembles some other embedded MACs. SpacemiT
>> refers to them as "EMAC", so let's just call the driver "k1_emac".
>>
>> Supports RGMII and RMII interfaces. Includes support for MAC hardware
>> statistics counters. PTP support is not implemented.
>>
>> Tested-by: Junhui Liu <junhui.liu@pigmoral.tech>
>> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
>> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
>> ---
> Hi Vivian,
> I have tested your patch on MUSE-PI.
> So here:
>
> Tested-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>
> But I still have a minor style comment on the code.
Thanks for your Tested-by and review.
>> drivers/net/ethernet/Kconfig | 1 +
>> drivers/net/ethernet/Makefile | 1 +
>> drivers/net/ethernet/spacemit/Kconfig | 29 +
>> drivers/net/ethernet/spacemit/Makefile | 6 +
>> drivers/net/ethernet/spacemit/k1_emac.c | 2193 +++++++++++++++++++++++++++++++
>> drivers/net/ethernet/spacemit/k1_emac.h | 426 ++++++
>> 6 files changed, 2656 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/spacemit/k1_emac.c b/drivers/net/ethernet/spacemit/k1_emac.c
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..9e558d5893cfbbda0baa7ad21a7209dadda9487e
>> --- /dev/null
>> +++ b/drivers/net/ethernet/spacemit/k1_emac.c
>> @@ -0,0 +1,2193 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * SpacemiT K1 Ethernet driver
>> + *
>> + * Copyright (C) 2023-2025 SpacemiT (Hangzhou) Technology Co. Ltd
>> + * Copyright (C) 2025 Vivian Wang <wangruikang@iscas.ac.cn>
>> + */
>> +
> [...]
>> +
>> +static void emac_wr(struct emac_priv *priv, u32 reg, u32 val)
>> +{
>> + writel(val, priv->iobase + reg);
>> +}
> basically short and obvious code like this:
>
> writel(val, priv->iobase + reg)
>
> you replace:
>
> emac_wr(priv, reg, val)
>
> It's not helpful..You could just use writel/readl directly
>> +
>> +static int emac_rd(struct emac_priv *priv, u32 reg)
>> +{
>> + return readl(priv->iobase + reg);
>> +}
> ditto.
I have decided against inlining these wrappers.
Firstly, the wrappers being mostly trivial is not it being "not
helpful". In long blocks of register access code, especially, having
just emac_rd(priv,...) or emac_wr(priv,...) repeated is easier to
recognize and harder to mess up (e.g. precedence of "priv->iomem + ...").
Secondly, they serve as documentation that a normal register access for
this driver is a 32-bit read or write. This is despite the fact that the
registers all "look like" they each only have the low 16 bits.
>> +
>> +static int emac_phy_interface_config(struct emac_priv *priv)
>> +{
>> + u32 val = 0, mask = PHY_INTF_RGMII;
>> +
>> + switch (priv->phy_interface) {
>> + case PHY_INTERFACE_MODE_RMII:
>> + mask |= REF_CLK_SEL;
>> + break;
>> + case PHY_INTERFACE_MODE_RGMII:
>> + case PHY_INTERFACE_MODE_RGMII_ID:
>> + case PHY_INTERFACE_MODE_RGMII_RXID:
>> + case PHY_INTERFACE_MODE_RGMII_TXID:
>> + val |= PHY_INTF_RGMII;
>> +
>> + mask |= RGMII_TX_CLK_SEL;
>> + break;
>> + default:
>> + netdev_err(priv->ndev, "Unsupported PHY interface %d",
>> + priv->phy_interface);
>> + return -EINVAL;
>> + }
>> +
>> + regmap_update_bits(priv->regmap_apmu,
>> + priv->regmap_apmu_offset + APMU_EMAC_CTRL_REG,
>> + mask, val);
>> +
>> + return 0;
>> +}
>> +
> [...]
>> +static bool emac_tx_should_interrupt(struct emac_priv *priv, u32 pkt_num)
>> +{
>> + bool should_interrupt;
>> +
>> + /* Manage TX mitigation */
>> + priv->tx_count_frames += pkt_num;
>> + if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
>> + emac_tx_coal_timer_resched(priv);
>> + should_interrupt = false;
>> + } else {
>> + priv->tx_count_frames = 0;
>> + should_interrupt = true;
>> + }
>> +
>> + return should_interrupt;
> If we really need this variable?
>
> How about this:
> if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
> emac_tx_coal_timer_resched(priv);
> return false;
> }
>
> priv->tx_count_frames = 0;
> return true;
I will simplify this in the next version.
>> +}
>> +
>> +static void emac_free_tx_buf(struct emac_priv *priv, int i)
>> +{
>> + struct emac_tx_desc_buffer *tx_buf;
>> + struct emac_desc_ring *tx_ring;
>> + struct desc_buf *buf;
>> + int j;
>> +
>> + tx_ring = &priv->tx_ring;
>> + tx_buf = &tx_ring->tx_desc_buf[i];
>> +
>> + for (j = 0; j < 2; j++) {
>> + buf = &tx_buf->buf[j];
>> + if (buf->dma_addr) {
>> + if (buf->map_as_page)
>> + dma_unmap_page(&priv->pdev->dev, buf->dma_addr,
>> + buf->dma_len, DMA_TO_DEVICE);
>> + else
>> + dma_unmap_single(&priv->pdev->dev,
>> + buf->dma_addr, buf->dma_len,
>> + DMA_TO_DEVICE);
>> +
>> + buf->dma_addr = 0;
>> + buf->map_as_page = false;
>> + buf->buff_addr = NULL;
>> + }
> if (!buf->dma_addr)
> continue;
>
> Best regards,
> Troy
You tricked me! There's one more review comment below :P
>> + }
>> +
>> + if (tx_buf->skb) {
>> + dev_kfree_skb_any(tx_buf->skb);
>> + tx_buf->skb = NULL;
>> + }
>> +}
>> +
>> +static void emac_clean_tx_desc_ring(struct emac_priv *priv)
>> +{
>> + struct emac_desc_ring *tx_ring = &priv->tx_ring;
>> + u32 i;
>> +
>> + /* Free all the TX ring skbs */
>> + for (i = 0; i < tx_ring->total_cnt; i++)
>> + emac_free_tx_buf(priv, i);
>> +
>> + tx_ring->head = 0;
>> + tx_ring->tail = 0;
>> +}
>> +
>> +static void emac_clean_rx_desc_ring(struct emac_priv *priv)
>> +{
>> + struct emac_rx_desc_buffer *rx_buf;
>> + struct emac_desc_ring *rx_ring;
>> + u32 i;
>> +
>> + rx_ring = &priv->rx_ring;
>> +
>> + /* Free all the RX ring skbs */
>> + for (i = 0; i < rx_ring->total_cnt; i++) {
>> + rx_buf = &rx_ring->rx_desc_buf[i];
>> + if (rx_buf->skb) {
>> + dma_unmap_single(&priv->pdev->dev, rx_buf->dma_addr,
>> + rx_buf->dma_len, DMA_FROM_DEVICE);
>> +
>> + dev_kfree_skb(rx_buf->skb);
>> + rx_buf->skb = NULL;
>> + }
> if (!rx_buf->skb)
> continue;
I will change both of these to "if (...) continue;" in the next version.
Thanks,
Vivian "dramforever" Wang
next prev parent reply other threads:[~2025-08-28 8:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 6:23 [PATCH net-next v7 0/5] Add Ethernet MAC support for SpacemiT K1 Vivian Wang
2025-08-26 6:23 ` [PATCH net-next v7 1/5] dt-bindings: net: Add " Vivian Wang
2025-08-26 6:23 ` [PATCH net-next v7 2/5] net: spacemit: Add K1 Ethernet MAC Vivian Wang
2025-08-26 8:54 ` Philipp Zabel
2025-08-27 13:17 ` Vivian Wang
2025-08-28 1:33 ` Troy Mitchell
2025-08-28 8:06 ` Vivian Wang [this message]
2025-08-28 8:31 ` Troy Mitchell
2025-08-28 12:29 ` Andrew Lunn
2025-08-26 6:23 ` [PATCH net-next v7 3/5] riscv: dts: spacemit: Add Ethernet support for K1 Vivian Wang
2025-08-26 6:23 ` [PATCH net-next v7 4/5] riscv: dts: spacemit: Add Ethernet support for BPI-F3 Vivian Wang
2025-08-26 6:23 ` [PATCH net-next v7 5/5] riscv: dts: spacemit: Add Ethernet support for Jupiter Vivian 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=6c221dcf-4310-4e31-b3e8-a8a3b68c3734@iscas.ac.cn \
--to=wangruikang@iscas.ac.cn \
--cc=alex@ghiti.fr \
--cc=andrew+netdev@lunn.ch \
--cc=aou@eecs.berkeley.edu \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dlan@gentoo.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=junhui.liu@pigmoral.tech \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh@kernel.org \
--cc=spacemit@lists.linux.dev \
--cc=troy.mitchell@linux.spacemit.com \
--cc=uwu@dram.page \
--cc=vadim.fedorenko@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).