linux-kernel - Re: Network drivers that don't suspend on interface down

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-next>] [day] [month] [year] [list]

Message-Id: <200612202125.10865.david-b@pacbell.net>
Date:	Wed, 20 Dec 2006 21:25:10 -0800
From:	David Brownell <david-b@...bell.net>
To:	Stephen Hemminger <shemminger@...l.org>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: Network drivers that don't suspend on interface down

Hmm, this reminds me of a thread from last summer, following up on
some PM discussions at OLS.  Thread "Runtime power management for
network interfaces", at the end of July.

> 2) Network device infrastructure should make it easier for devices:
>     bring interface down on suspend and bring it up after resume
>     (if it was running when suspended). This would allow many devices to
>     have no suspend/resume hook; except those that have some better power
>     control over hardware.

The _intent_ of the class suspend() and resume() methods is to let
infrastructure (the network stack was explicitly mentioned!) handle
pretty much everything except putting the hardware in low power
modes ... which last step might, for PCI devices at least, most
naturally be done in suspend_late().  That way it'd be decoupled
cleanly from anything else.

Now, I recently tried refreshing a patch that used those class
suspend() and resume() methods, and for some reason they're not
getting called.  I believe they used to get called, although it's
true their parameter wasn't very useful ... it was called with the
underlying device, not the class_device holding state that the
class driver manages.

I just wanted to point out that yes, this ground has been covered
before, with some agreement on that approach.  It'd be good to see
it pursued.  :)

- Dave

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