On Mon, Nov 14, 2022 at 08:47:42PM +0000, Veerasenareddy Burru wrote: > > > > -----Original Message----- > > From: Leon Romanovsky <leon@xxxxxxxxxx> > > Sent: Monday, November 7, 2022 12:19 AM > > To: Veerasenareddy Burru <vburru@xxxxxxxxxxx> > > Cc: netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Liron Himi > > <lironh@xxxxxxxxxxx>; Abhijit Ayarekar <aayarekar@xxxxxxxxxxx>; Sathesh > > B Edara <sedara@xxxxxxxxxxx>; Satananda Burla <sburla@xxxxxxxxxxx>; > > linux-doc@xxxxxxxxxxxxxxx; David S. Miller <davem@xxxxxxxxxxxxx>; Eric > > Dumazet <edumazet@xxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; > > Paolo Abeni <pabeni@xxxxxxxxxx> > > 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
