All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Bianconi <lorenzo@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Netdev <netdev@vger.kernel.org>, Felix Fietkau <nbd@nbd.name>,
	lorenzo.bianconi83@gmail.com,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Conor Dooley <conor@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Rob Herring <robh+dt@kernel.org>,
	krzysztof.kozlowski+dt@linaro.org,
	Conor Dooley <conor+dt@kernel.org>,
	devicetree@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	upstream@airoha.com,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	benjamin.larsson@genexis.eu, linux-clk@vger.kernel.org,
	Ratheesh Kannoth <rkannoth@marvell.com>,
	Sunil Goutham <sgoutham@marvell.com>,
	Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH v2 net-next 2/2] net: airoha: Introduce ethernet support for EN7581 SoC
Date: Fri, 28 Jun 2024 19:27:45 +0200	[thread overview]
Message-ID: <Zn7ykZeBWXN3cObh@lore-desk> (raw)
In-Reply-To: <2d74f9c1-2b46-4544-a9c2-aa470ce36f80@app.fastmail.com>

[-- Attachment #1: Type: text/plain, Size: 6974 bytes --]

> On Tue, Jun 18, 2024, at 09:49, Lorenzo Bianconi wrote:
> > Add airoha_eth driver in order to introduce ethernet support for
> > Airoha EN7581 SoC available on EN7581 development board (en7581-evb).
> > en7581-evb networking architecture is composed by airoha_eth as mac
> > controller (cpu port) and a mt7530 dsa based switch.
> > EN7581 mac controller is mainly composed by Frame Engine (FE) and
> > QoS-DMA (QDMA) modules. FE is used for traffic offloading (just basic
> > functionalities are supported now) while QDMA is used for DMA operation
> > and QOS functionalities between mac layer and the dsa switch (hw QoS is
> > not available yet and it will be added in the future).
> > Currently only hw lan features are available, hw wan will be added with
> > subsequent patches.
> >
> > Tested-by: Benjamin Larsson <benjamin.larsson@genexis.eu>
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> 
> I noticed a few small things that you may want to improve:

Hi Arnd,

thx for the review.

> 
> > +static void airoha_qdma_set_irqmask(struct airoha_eth *eth, int index,
> > +				    u32 clear, u32 set)
> > +{
> > +	unsigned long flags;
> > +
> > +	if (WARN_ON_ONCE(index >= ARRAY_SIZE(eth->irqmask)))
> > +		return;
> > +
> > +	spin_lock_irqsave(&eth->irq_lock, flags);
> > +
> > +	eth->irqmask[index] &= ~clear;
> > +	eth->irqmask[index] |= set;
> > +	airoha_qdma_wr(eth, REG_INT_ENABLE(index), eth->irqmask[index]);
> > +
> > +	spin_unlock_irqrestore(&eth->irq_lock, flags);
> > +}
> 
> spin_lock_irqsave() is fairly expensive here, and it doesn't
> actually protect the register write since that is posted
> and can leak out of the spinlock.
> 
> You can probably just remove the lock and instead do the mask
> with atomic_cmpxchg() here.

I did not get what you mean here. I guess the spin_lock is used to avoid
concurrent irq registers updates from user/bh context or irq handler.
Am I missing something?

> 
> > +
> > +		dma_sync_single_for_device(dev, e->dma_addr, e->dma_len, dir);
> > +
> > +		val = FIELD_PREP(QDMA_DESC_LEN_MASK, e->dma_len);
> > +		WRITE_ONCE(desc->ctrl, cpu_to_le32(val));
> > +		WRITE_ONCE(desc->addr, cpu_to_le32(e->dma_addr));
> > +		val = FIELD_PREP(QDMA_DESC_NEXT_ID_MASK, q->head);
> > +		WRITE_ONCE(desc->data, cpu_to_le32(val));
> > +		WRITE_ONCE(desc->msg0, 0);
> > +		WRITE_ONCE(desc->msg1, 0);
> > +		WRITE_ONCE(desc->msg2, 0);
> > +		WRITE_ONCE(desc->msg3, 0);
> > +
> > +		wmb();
> > +		airoha_qdma_rmw(eth, REG_RX_CPU_IDX(qid), RX_RING_CPU_IDX_MASK,
> > +				FIELD_PREP(RX_RING_CPU_IDX_MASK, q->head));
> 
> The wmb() between the descriptor write and the MMIO does nothing
> and can probably just be removed here, a writel() already contains
> all the barriers you need to make DMA memory visible before the
> MMIO write.
> 
> If there is a chance that the device might read the descriptor
> while it is being updated by you have not written to the
> register, there should be a barrier before the last store to
> the descriptor that sets a 'valid' bit. That one can be a
> cheaper dma_wmb() then.

ack, I will fix it in v4.

> 
> > +static irqreturn_t airoha_irq_handler(int irq, void *dev_instance)
> > +{
> > +	struct airoha_eth *eth = dev_instance;
> > +	u32 intr[ARRAY_SIZE(eth->irqmask)];
> > +	int i;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(eth->irqmask); i++) {
> > +		intr[i] = airoha_qdma_rr(eth, REG_INT_STATUS(i));
> > +		intr[i] &= eth->irqmask[i];
> > +		airoha_qdma_wr(eth, REG_INT_STATUS(i), intr[i]);
> > +	}
> 
> This looks like you send an interrupt Ack to each
> interrupt in order to re-arm it, but then you disable
> it again. Would it be possible to leave the interrupt enabled
> but defer the Ack until the napi poll function is completed?

I guess doing so we are not using NAPIs as expected since they are
supposed to run with interrupt disabled. Agree?

> 
> > +	if (!test_bit(DEV_STATE_INITIALIZED, &eth->state))
> > +		return IRQ_NONE;
> > +
> > +	if (intr[1] & RX_DONE_INT_MASK) {
> > +		airoha_qdma_irq_disable(eth, QDMA_INT_REG_IDX1,
> > +					RX_DONE_INT_MASK);
> > +		airoha_qdma_for_each_q_rx(eth, i) {
> > +			if (intr[1] & BIT(i))
> > +				napi_schedule(&eth->q_rx[i].napi);
> > +		}
> > +	}
> 
> Something seems wrong here, but that's probably just me
> misunderstanding the design: if all queues are signaled
> through the same interrupt handler, and you then do
> napi_schedule() for each queue, I would expect them to
> just all get run on the same CPU.
> 
> If you have separate queues, doesn't that mean you also need
> separate irq numbers here so they can be distributed to the
> available CPUs?

Actually I missed to mark the NAPI as threaded. Doing so, even if we have a
single irq line shared by all Rx queues, the scheduler can run the NAPIs in
parallel on different CPUs. I will fix it in v4.

> 
> > +		val = FIELD_PREP(QDMA_DESC_LEN_MASK, len);
> > +		if (i < nr_frags - 1)
> > +			val |= FIELD_PREP(QDMA_DESC_MORE_MASK, 1);
> > +		WRITE_ONCE(desc->ctrl, cpu_to_le32(val));
> > +		WRITE_ONCE(desc->addr, cpu_to_le32(addr));
> > +		val = FIELD_PREP(QDMA_DESC_NEXT_ID_MASK, index);
> > +		WRITE_ONCE(desc->data, cpu_to_le32(val));
> > +		WRITE_ONCE(desc->msg0, cpu_to_le32(msg0));
> > +		WRITE_ONCE(desc->msg1, cpu_to_le32(msg1));
> > +		WRITE_ONCE(desc->msg2, cpu_to_le32(0xffff));
> > +
> > +		e->skb = i ? NULL : skb;
> > +		e->dma_addr = addr;
> > +		e->dma_len = len;
> > +
> > +		wmb();
> > +		airoha_qdma_rmw(eth, REG_TX_CPU_IDX(qid), TX_RING_CPU_IDX_MASK,
> > +				FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
> 
> Same as above with the wmb().

ack, I will fix it in v4.

> 
> > +static int airoha_rx_queues_show(struct seq_file *s, void *data)
> > +{
> > +	struct airoha_eth *eth = s->private;
> > +	int i;
> > +
> ...
> > +static int airoha_xmit_queues_show(struct seq_file *s, void *data)
> > +{
> > +	struct airoha_eth *eth = s->private;
> > +	int i;
> > +
> 
> Isn't this information available through ethtool already?

I guess we can get rid of this debugfs since it was just for debugging.

> 
> > b/drivers/net/ethernet/mediatek/airoha_eth.h
> > new file mode 100644
> > index 000000000000..fcd684e1418a
> > --- /dev/null
> > +++ b/drivers/net/ethernet/mediatek/airoha_eth.h
> > @@ -0,0 +1,793 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2024 Lorenzo Bianconi <lorenzo@kernel.org>
> > + */
> > +
> > +#define AIROHA_MAX_NUM_RSTS		3
> > +#define AIROHA_MAX_NUM_XSI_RSTS		4
> 
> If your driver only has a single .c file, I would suggest moving all the
> contents of the .h file into that as well for better readability.

I do not have a strong opinion about it but since we will extend the driver
in the future, keeping .c and .h in different files, seems a bit more tidy.
What do you think?

Regards,
Lorenzo

> 
>       Arnd 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2024-06-28 17:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18  7:49 [PATCH v2 net-next 0/2] Introduce EN7581 ethernet support Lorenzo Bianconi
2024-06-18  7:49 ` [PATCH v2 net-next 1/2] dt-bindings: net: airoha: Add EN7581 ethernet controller Lorenzo Bianconi
2024-06-18 11:32   ` Rob Herring (Arm)
2024-06-18 17:46   ` Conor Dooley
2024-06-19  6:42     ` Lorenzo Bianconi
2024-06-18 17:47   ` Conor Dooley
2024-06-19  6:58     ` Lorenzo Bianconi
2024-06-18  7:49 ` [PATCH v2 net-next 2/2] net: airoha: Introduce ethernet support for EN7581 SoC Lorenzo Bianconi
2024-06-18 13:46   ` Andrew Lunn
2024-06-19  7:19     ` Lorenzo Bianconi
2024-06-24 15:58   ` kernel test robot
2024-06-24 20:05   ` Arnd Bergmann
2024-06-28 17:27     ` Lorenzo Bianconi [this message]
2024-06-28 19:34       ` Arnd Bergmann
2024-06-28 19:57         ` Felix Fietkau

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=Zn7ykZeBWXN3cObh@lore-desk \
    --to=lorenzo@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=arnd@arndb.de \
    --cc=benjamin.larsson@genexis.eu \
    --cc=catalin.marinas@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=conor@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=lorenzo.bianconi83@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rkannoth@marvell.com \
    --cc=robh+dt@kernel.org \
    --cc=sgoutham@marvell.com \
    --cc=upstream@airoha.com \
    --cc=will@kernel.org \
    /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.