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:	Mon, 29 Sep 2008 17:55:47 -0700
From:	"Jeffrey W. Baker" <jwbaker@...il.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Put unused PCI devices in D3

On Tue, 2008-09-30 at 01:09 +0100, Matthew Garrett wrote: 
> On Mon, Sep 29, 2008 at 01:11:03PM -0700, Jeffrey W. Baker wrote:
> 
> > Currently it looks to me from browsing the code that D3 is only used in
> > Linux when the whole machine is headed for S3, and the drivers are asked
> > to suspend.  I think the drivers should be able to enter D3 in other
> > circumstances:
> > 
> > * During pci_unregister_driver ... i.e. on module unload
> 
> The fact that Linux isn't using a device doesn't inherently mean that 
> the system isn't using it. For example, the smbus controller will 
> probably still be used by ACPI even if there's no Linux driver loaded.

True.  On my hardware, the smbus controller doesn't advertise power
management capabilities, so this would not be a problem. 

> > * When a network interface is downed
> 
> Yes. Drivers are moving towards this model.

Very cool.  netbsd-current apparently  has this already (and a
kernel-wide topological representation of PCI power management
generally).

> > * If the device is a bridge or hub with no downstream device
> 
> Potential problems with hotplugging? But sure, this kind of thing is 
> being implemented in USB and SCSI.
> 
> > * Whenever userspace requests D3 via sysfs
> 
> This functionality was explicitly removed a few years back.

I sure would like to have it back, if only just for experimentation.
Right now, I don't even know what kind of power savings could be
achieved from D3, I'm just speculating.  As you rightfully point out,
it's possible that the driver could put the device into an ultra-low
power saving state while still operating in D0, and that D3 savings
would be negligible.

> > So, what fundamental problem prevents me from, for example, calling
> > pci_set_power_state() from ohci1394's __exit?
> 
> Nothing I'm aware of. It sounds pretty safe in that case. But that would 
> require you to load and unload the driver - better to have the driver 
> loaded the entire time and make sure it does as much runtime power 
> management as possible. I don't know enough about the firewire OHCI 
> hardware, but can you power down most of the chip and still get hotplug 
> events?

No, you couldn't, but that isn't really the point.  If I have my laptop
on a transoceanic flight it may be useful for me to be able to set a
power policy turning off all the extraneous junk on my machine, because
I know /a priori/ that no hotplug events will happen.  There's no way
the kernel could know that, but userspace can tell the kernel to turn
off an unneeded device.

Think of it this way.  Putting the machine into S3 prevents it from
checking my email, but the capability exists.  All I want to do is
extend that concept to the PCI device level.

Anyway, ohci1394 is pretty easy to understand, and it's not likely to
hose up the system too badly, so I'm going to perform surgery there.

-jwb

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

Powered by blists - more mailing lists