netdev - RE: [EXT] Re: [PATCH v2 net] qede: fix firmware halt over suspend and resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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