[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<BY3PR18MB4612F2621E50B2F12F2BC342AB10A@BY3PR18MB4612.namprd18.prod.outlook.com>
Date: Fri, 11 Aug 2023 09:31:15 +0000
From: Manish Chopra <manishc@...vell.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Ariel Elior
<aelior@...vell.com>, Alok Prasad <palok@...vell.com>,
Nilesh Javali
<njavali@...vell.com>,
Saurav Kashyap <skashyap@...vell.com>,
"jmeneghi@...hat.com" <jmeneghi@...hat.com>,
"yuval.mintz@...gic.com"
<yuval.mintz@...gic.com>,
Sudarsana Reddy Kalluru <skalluru@...vell.com>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"edumazet@...gle.com"
<edumazet@...gle.com>,
"horms@...nel.org" <horms@...nel.org>,
David Miller
<davem@...emloft.net>
Subject: RE: [EXT] Re: [PATCH v2 net] qede: fix firmware halt over suspend and
resume
> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, August 11, 2023 6:17 AM
> To: Manish Chopra <manishc@...vell.com>
> Cc: netdev@...r.kernel.org; Ariel Elior <aelior@...vell.com>; Alok Prasad
> <palok@...vell.com>; Nilesh Javali <njavali@...vell.com>; Saurav Kashyap
> <skashyap@...vell.com>; jmeneghi@...hat.com; yuval.mintz@...gic.com;
> Sudarsana Reddy Kalluru <skalluru@...vell.com>; pabeni@...hat.com;
> edumazet@...gle.com; horms@...nel.org; David Miller
> <davem@...emloft.net>
> Subject: [EXT] Re: [PATCH v2 net] qede: fix firmware halt over suspend and
> resume
>
> External Email
>
> ----------------------------------------------------------------------
> On Wed, 9 Aug 2023 19:13:39 +0530 Manish Chopra wrote:
> > While performing certain power-off sequences, PCI drivers are called
> > to suspend and resume their underlying devices through PCI PM (power
> > management) interface. However this NIC hardware does not support PCI
> > PM suspend/resume operations so system wide suspend/resume leads to
> > bad MFW (management firmware) state which causes various follow-up
> > errors in driver when communicating with the device/firmware
> > afterwards.
>
> Does the FW end up recovering? That could still be preferable to rejecting
> suspend altogether. Reject is a big hammer, I'm a bit worried it will cause a
> regression in stable.
Yes, By adding the driver's suspend handler with explicit error returned
to PCI subsystem prevents the system wide suspend and does not impact the
device/FW at all. It keeps them operational as they were before.
>
> > To fix this driver implements PCI PM suspend handler to indicate
> > unsupported operation to the PCI subsystem explicitly, thus avoiding
> > system to go into suspended/standby mode.
> >
> > Fixes: 2950219d87b0 ("qede: Add basic network device support")
> > Cc: David Miller <davem@...emloft.net>
> > Signed-off-by: Manish Chopra <manishc@...vell.com>
> > Signed-off-by: Alok Prasad <palok@...vell.com>
> > ---
> > V1->V2:
> > * Replace SIMPLE_DEV_PM_OPS with DEFINE_SIMPLE_DEV_PM_OPS
> > ---
> > drivers/net/ethernet/qlogic/qede/qede_main.c | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c
> > b/drivers/net/ethernet/qlogic/qede/qede_main.c
> > index d57e52a97f85..18ae7af1764c 100644
> > --- a/drivers/net/ethernet/qlogic/qede/qede_main.c
> > +++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
> > @@ -177,6 +177,18 @@ static int qede_sriov_configure(struct pci_dev
> > *pdev, int num_vfs_param) } #endif
> >
> > +static int __maybe_unused qede_suspend(struct device *dev) {
> > + if (!dev)
> > + return -ENODEV;
>
> Can dev really be NULL here? That wouldn't make sense, what's the driver
> supposed to do in such case?
It's not supposed to be NULL here assuming caller must be validating it way
before. I just put it for sanity. I will remove it.
> --
> pw-bot: cr
Powered by blists - more mailing lists