On Thu, Mar 23, 2023 at 05:24:55PM +0000, Veerasenareddy Burru wrote: > > > > -----Original Message----- > > From: Leon Romanovsky <leon@xxxxxxxxxx> > > Sent: Thursday, March 23, 2023 3:39 AM > > To: Veerasenareddy Burru <vburru@xxxxxxxxxxx> > > Cc: netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; 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 v4 6/8] octeon_ep: support > > asynchronous notifications > > > > External Email > > > > ---------------------------------------------------------------------- > > On Wed, Mar 22, 2023 at 02:19:55AM -0700, Veerasenareddy Burru wrote: > > > Add asynchronous notification support to the control mailbox. > > > > > > Signed-off-by: Veerasenareddy Burru <vburru@xxxxxxxxxxx> > > > Signed-off-by: Abhijit Ayarekar <aayarekar@xxxxxxxxxxx> > > > --- > > > v3 -> v4: > > > * 0005-xxx.patch in v3 is 0006-xxx.patch in v4. > > > * addressed review comments > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__lore.kernel.org_all_Y-2B0J94sowllCe5Gs- > > 40boxer_&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=XkP_75lnbPIeeucsP > > X36ZgjiMqEKttwZfwNyWMCLjT0&m=5CnsD- > > SX6ZoW98szwM0k4IXgNC3wY0EwCQHxDKGyNIRUJxdaNe3zorLcOhc9iU6d&s > > =k73McQSsjbjj87VbCCB8EFFtGWtksMIGhn15RK12XF8&e= > > > - fixed rct violation. > > > - process_mbox_notify() now returns void. > > > > > > v2 -> v3: > > > * no change > > > > > > v1 -> v2: > > > * no change > > > > > > .../marvell/octeon_ep/octep_ctrl_net.c | 29 +++++++++++++++++++ > > > 1 file changed, 29 insertions(+) > > > > > > diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.c > > > b/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.c > > > index cef4bc3b1ec0..465eef2824e3 100644 > > > --- a/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.c > > > +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.c > > > @@ -271,6 +271,33 @@ static void process_mbox_resp(struct > > octep_device *oct, > > > } > > > } > > > > > > +static int process_mbox_notify(struct octep_device *oct, > > > + struct octep_ctrl_mbox_msg *msg) { > > > + struct net_device *netdev = oct->netdev; > > > + struct octep_ctrl_net_f2h_req *req; > > > + > > > + req = (struct octep_ctrl_net_f2h_req *)msg->sg_list[0].msg; > > > + switch (req->hdr.s.cmd) { > > > + case OCTEP_CTRL_NET_F2H_CMD_LINK_STATUS: > > > + if (netif_running(netdev)) { > > > + if (req->link.state) { > > > + dev_info(&oct->pdev->dev, > > "netif_carrier_on\n"); > > > + netif_carrier_on(netdev); > > > + } else { > > > + dev_info(&oct->pdev->dev, > > "netif_carrier_off\n"); > > > + netif_carrier_off(netdev); > > > + } > > > > Shouldn't netdev changes be protected by some lock? > > Is is safe to get event from FW and process it as is? > > > > Thanks > > Thanks for the kind feedback. > I do not see netif_carrier_on/off require any protection. I referred few other drivers and do not see such protection used for carrier on/off. > Please suggest if I am missing something here. I see that Dave already applied your v5. I think that you are missing context in which you are running FW commands. They run independently from netdev and makes netif_running() check to be racy. Thanks >
