Re: [EXT] Re: [PATCH net-next 1/9] octeon_ep: wait for firmware ready

[Leon Romanovsky <leon@kernel.org>]

On Mon, Nov 14, 2022 at 08:47:42PM +0000, Veerasenareddy Burru wrote:
> 
> 
> > -----Original Message-----
> > From: Leon Romanovsky <leon@kernel.org>
> > Sent: Monday, November 7, 2022 12:19 AM
> > To: Veerasenareddy Burru <vburru@marvell.com>
> > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Liron Himi
> > <lironh@marvell.com>; Abhijit Ayarekar <aayarekar@marvell.com>; Sathesh
> > B Edara <sedara@marvell.com>; Satananda Burla <sburla@marvell.com>;
> > linux-doc@vger.kernel.org; David S. Miller <davem@davemloft.net>; Eric
> > Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>;
> > Paolo Abeni <pabeni@redhat.com>
> > Subject: [EXT] Re: [PATCH net-next 1/9] octeon_ep: wait for firmware ready
> > 
> > External Email
> > 
> > ----------------------------------------------------------------------
> > On Sun, Nov 06, 2022 at 11:25:15PM -0800, Veerasenareddy Burru wrote:
> > > Make driver initialize the device only after firmware is ready
> > >  - add async device setup routine.
> > >  - poll firmware status register.
> > >  - once firmware is ready, call async device setup routine.
> > 
> > Please don't do it. It is extremely hard to do it right. The proposed code that
> > has combination of atomics used as a locks together with absence of proper
> > locking from PCI and driver cores supports my claim.
> > 
> > Thanks
> Leon
>           What is the alternate approach you suggest here ?  Are you suggesting usage of deferred probe ? the driver initialization cannot proceed till firmware ready is set by firmware.

This is what I initially thought.

Thanks

> Thanks