Re: [EXTERNAL] Re: [PATCH net v3 3/3] octeon_ep_vf: ensure dbell BADDR updation

[Simon Horman]

On Thu, Jan 15, 2026 at 09:34:23AM +0000, Vimlesh Kumar wrote:
> 
> 
> > -----Original Message-----
> > From: Simon Horman <horms@xxxxxxxxxx>
> > Sent: Monday, January 12, 2026 8:10 PM
> > To: Vimlesh Kumar <vimleshk@xxxxxxxxxxx>
> > Cc: netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Sathesh B Edara
> > <sedara@xxxxxxxxxxx>; Shinas Rasheed <srasheed@xxxxxxxxxxx>; Haseeb
> > Gani <hgani@xxxxxxxxxxx>; Veerasenareddy Burru <vburru@xxxxxxxxxxx>;
> > Satananda Burla <sburla@xxxxxxxxxxx>; Andrew Lunn
> > <andrew+netdev@xxxxxxx>; David S. Miller <davem@xxxxxxxxxxxxx>; Eric
> > Dumazet <edumazet@xxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Paolo
> > Abeni <pabeni@xxxxxxxxxx>
> > Subject: [EXTERNAL] Re: [PATCH net v3 3/3] octeon_ep_vf: ensure dbell
> > BADDR updation
> > 
> > On Wed, Jan 07, 2026 at 01: 18: 56PM +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
> > On Wed, Jan 07, 2026 at 01:18:56PM +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: 2c0c32c72be29 ("octeon_ep_vf: add hardware configuration APIs")
> > > Signed-off-by: Sathesh Edara <sedara@xxxxxxxxxxx>
> > > Signed-off-by: Shinas Rasheed <srasheed@xxxxxxxxxxx>
> > > Signed-off-by: Vimlesh Kumar <vimleshk@xxxxxxxxxxx>
> > > ---
> > > V3:
> > > - Use reverse christmas tree order variable declaration.
> > > - Return error if timeout happens during setup oq.
> > 
> > ...
> > 
> > > diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> > > b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> > > index d70c8be3cfc4..6446f6bf0b90 100644
> > > --- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> > > +++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> > > @@ -171,7 +171,9 @@ static int octep_vf_setup_oq(struct octep_vf_device
> > *oct, int q_no)
> > >  		goto oq_fill_buff_err;
> > >
> > >  	octep_vf_oq_reset_indices(oq);
> > > -	oct->hw_ops.setup_oq_regs(oct, q_no);
> > > +	if (oct->hw_ops.setup_oq_regs(oct, q_no))
> > > +		goto oq_fill_buff_err;
> > > +
> > 
> > Hi Vimlesh, all,
> > 
> > I think that a new label needs to be added to the unwind ladder such that
> > octep_vf_oq_free_ring_buffers() is called if the error condition above is met.
> > 
> > Likewise in patch 2/3.
> 
> Hi Simon, 
> 
> octep_vf_oq_free_ring_buffers() is being called from the caller function octep_vf_setup_oqs() in the error case and hence not required over here.

Ok. I'm not a big fan of asymmetric clean-up paths.
But I agree that would prevent leaks.

...