From: Simon Horman <horms@kernel.org>
To: Vimlesh Kumar <vimleshk@marvell.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
sedara@marvell.com, srasheed@marvell.com, hgani@marvell.com,
Veerasenareddy Burru <vburru@marvell.com>,
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>
Subject: Re: [PATCH net v1 2/3] octeon_ep: ensure dbell BADDR updation
Date: Fri, 12 Dec 2025 16:07:22 +0000 [thread overview]
Message-ID: <aTw9uutDeFnKDX1d@horms.kernel.org> (raw)
In-Reply-To: <20251212122304.2562229-3-vimleshk@marvell.com>
On Fri, Dec 12, 2025 at 12:23:01PM +0000, Vimlesh Kumar wrote:
> Make sure the OUT DBELL base address reflects the
> latest values written to it.
>
> Fix:
> Add a wait until the OUT DBELL base address register
> is updated with the DMA ring descriptor address,
> and modify the setup_oq function to properly
> handle failures.
>
> Fixes: 0807dc76f3bf5("octeon_ep: support Octeon CN10K devices")
Hi Vimlesh,
Thanks for your patch.
Some feedback from my side.
First, there is a space missing in the Fixes tag:
Fixes: 0807dc76f3bf ("octeon_ep: support Octeon CN10K devices")
> Signed-off-by: Sathesh Edara <sedara@marvell.com>
> Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
> Signed-off-by: Vimlesh Kumar <vimleshk@marvell.com>
...
> /* Setup registers for a PF mailbox */
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_cnxk_pf.c b/drivers/net/ethernet/marvell/octeon_ep/octep_cnxk_pf.c
...
> @@ -343,6 +344,23 @@ static void octep_setup_oq_regs_cnxk_pf(struct octep_device *oct, int oq_no)
> reg_val = octep_read_csr64(oct, CNXK_SDP_R_OUT_CONTROL(oq_no));
> } while (!(reg_val & CNXK_R_OUT_CTL_IDLE));
> }
> + octep_write_csr64(oct, CNXK_SDP_R_OUT_WMARK(oq_no), oq->max_count);
> + /* Wait for WMARK to get applied */
> + usleep_range(10, 15);
> +
> + octep_write_csr64(oct, CNXK_SDP_R_OUT_SLIST_BADDR(oq_no), oq->desc_ring_dma);
Please line-wrap Networking code to 80 columns wide or less where it can
be done without reducing readability (which is the case here).
checkpatch.pl --max-line-length=80 should flag this.
> + octep_write_csr64(oct, CNXK_SDP_R_OUT_SLIST_RSIZE(oq_no), oq->max_count);
> + reg_ba_val = octep_read_csr64(oct, CNXK_SDP_R_OUT_SLIST_BADDR(oq_no));
> + if (reg_ba_val != oq->desc_ring_dma) {
> + do {
> + if (reg_ba_val == UINT64_MAX)
I think that ULLONG_MAX here, rather than defining UINT64_MAX
elsewhere in this patch.
It might be better if the Kernel provided UINT64_MAX and friends.
But it doesn't. (And I'm sure there are many opinions on why.)
> + return -1;
This should be a standard error code.
Perhaps -EFAULT?
> + octep_write_csr64(oct, CNXK_SDP_R_OUT_SLIST_BADDR(oq_no),
> + oq->desc_ring_dma);
> + octep_write_csr64(oct, CNXK_SDP_R_OUT_SLIST_RSIZE(oq_no), oq->max_count);
> + reg_ba_val = octep_read_csr64(oct, CNXK_SDP_R_OUT_SLIST_BADDR(oq_no));
> + } while (reg_ba_val != oq->desc_ring_dma);
I am concerned that this loop is unbounded.
Could some limit be placed on it?
...
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_main.h b/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
> index 81ac4267811c..76622cdf577d 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
> @@ -55,6 +55,10 @@
> (iq_)->max_count - IQ_INSTR_PENDING(iq_); \
> })
>
> +#ifndef UINT64_MAX
> +#define UINT64_MAX ((u64)(~((u64)0))) /* 0xFFFFFFFFFFFFFFFF */
> +#endif
> +
> /* PCI address space mapping information.
> * Each of the 3 address spaces given by BAR0, BAR2 and BAR4 of
> * Octeon gets mapped to different physical address spaces in
...
--
pw-bot: cr
next prev parent reply other threads:[~2025-12-12 16:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 12:22 [PATCH net v1 0/3] disable interrupts and ensure dbell updation Vimlesh Kumar
2025-12-12 12:23 ` [PATCH net v1 1/3] octeon_ep: disable per ring interrupts Vimlesh Kumar
2025-12-12 16:13 ` Simon Horman
2025-12-12 12:23 ` [PATCH net v1 2/3] octeon_ep: ensure dbell BADDR updation Vimlesh Kumar
2025-12-12 16:07 ` Simon Horman [this message]
2025-12-12 12:23 ` [PATCH net v1 3/3] octeon_ep_vf: " Vimlesh Kumar
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=aTw9uutDeFnKDX1d@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hgani@marvell.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sedara@marvell.com \
--cc=srasheed@marvell.com \
--cc=vburru@marvell.com \
--cc=vimleshk@marvell.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 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).