linux-kernel - Re: [PATCH] Make e100 suspend handler support PCI cards lacking PM capability

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]

Message-Id: <200906140028.16025.rjw@sisk.pl>
Date:	Sun, 14 Jun 2009 00:28:15 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	andi@...as.de
Cc:	akpm@...ux-foundation.org, e1000-devel@...ts.sourceforge.net,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Make e100 suspend handler support PCI cards lacking PM capability

On Saturday 13 June 2009, Andreas Mohr wrote:
> Hi all,
> 
> after having added non-MII PHY card support to e100, I noticed that
> the suspend handler rejects power-management non-capable PCI cards,

Well, that means we have a bug somewhere in the PCI PM core.

> causing a S2R request to immediately get back up to the desktop,
> losing network access in the process (rtnl mutex deadlock).

That's bad.

> 
> ChangeLog:
> Support PCI cards which are lacking power management capability
> in the e100 suspend handler.
> 
> 
> Frankly I was unsure how to best add this to the driver in a clean way.
> Usually drivers use pci_set_power_state(..., pci_choose_state(...))
> in order to avoid the rejection of an open-coded
> pci_set_power_state(..., PCI_D3hot) in case of a non-PM card,
> however pci_choose_state() depends on the _pm-internal_ pm_message_t type,
> which was doable in .suspend directly but not at the other e100
> driver locations where it was used.
> 
> Next attempt was to extend __e100_power_off() with a pci_power_t parameter,
> however since __e100_power_off() is called by two locations,
> that meant that I'd have to use pci_choose_state() at _both_ call sites.
> 
> Thus I simply resorted to do a brute-force yet most simple
> pci_find_capability() check in the __e100_power_off() function.
> 
> 
> Tested on 2.6.30-rc8 and suspending/resuming fine, checkpatch.pl:ed.
> Patch against 2.6.30-rc8 with my original non-MII support patch applied.
> (should apply fine in any case, I'd think).
> Intended for testing in -mmotm or so.
> 
> Thanks!
> 
> Signed-off-by: Andreas Mohr <andi@...as.de>
> 
> 
> --- linux-2.6.30-rc8.e100/drivers/net/e100.c.my_patch_orig	2009-06-13 18:47:53.000000000 +0200
> +++ linux-2.6.30-rc8.e100/drivers/net/e100.c	2009-06-13 20:27:46.000000000 +0200
> @@ -2897,6 +2897,13 @@ static void __e100_shutdown(struct pci_d
>  
>  static int __e100_power_off(struct pci_dev *pdev, bool wake)
>  {
> +	/* some older devices don't support PCI PM
> +	 * (e.g. mac_82557_D100_B combo card with 80c24 PHY)
> +	 * - skip those! (they most likely won't support WoL either)
> +	 */
> +	if (!pci_find_capability(pdev, PCI_CAP_ID_PM))
> +		return 0;

Devices without PCI_CAP_ID_PM may still be power-manageable by ACPI, so
returning 0 at this point is not a general solution.

> +
>  	if (wake) {
>  		return pci_prepare_to_sleep(pdev);

pci_prepare_to_sleep() is supposed to return 0 for your device.  I'll have a
look at it.

Best,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/