Messages in this thread | | | From | Veerasenareddy Burru <> | Subject | RE: [EXT] Re: [PATCH net-next 1/9] octeon_ep: wait for firmware ready | Date | Mon, 14 Nov 2022 20:47:42 +0000 |
| |
> -----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. Thanks
| |