lkml.org 
[lkml]   [2022]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [EXT] Re: [PATCH net-next 1/9] octeon_ep: wait for firmware ready
Date


> -----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

\
 
 \ /
  Last update: 2022-11-14 21:48    [W:0.304 / U:0.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site