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: <CAJiQ=7CorBMaO80xcEx4ygYFDJxxav_yyPs2jegKo3vrX1REHA@mail.gmail.com>
Date:	Wed, 16 Jul 2014 11:55:16 -0700
From:	Kevin Cernekee <cernekee@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Dmitry Torokhov <dtor@...gle.com>,
	Patrik Fimml <patrikf@...omium.org>, linux-pm@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Benson Leung <bleung@...gle.com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Power-managing devices that are not of interest at some point in time

On Wed, Jul 16, 2014 at 11:08 AM, Alan Stern <stern@...land.harvard.edu> wrote:
>> I am not so much concerned about userspace, but about reusing of as
>> much of existing PM framework in the drivers. Right now it is very
>> hard to correctly track dependencies between general open/close,
>> system suspend/resume, and various runtime-PM transitions. Adding yet
>> another PM mechanism into the mix will just add more complexity.
>
> Would it make sense to unbind the drivers for these devices when the
> lid is closed?  With the drivers gone, there would naturally be no I/O
> interactions with the hardware and the class devices would disappear.

FWIW, per your earlier recommendation[1], that is the approach that my
group has been using to disable various host controllers when Linux is
running (not suspended) but certain power-hungry peripherals are not
needed.  It has mostly worked out OK; each driver typically implements
its own special PHY init/shutdown procedure, and calls into the common
clk_* functions to enable/disable the appropriate clocks.

Obviously the application needs to be able to cope with disappearing
devices, and you wouldn't want to have any filesystems mounted on top
of them when the unbind event happens.

Our devices are on an SoC's internal bus, not PCI.

[1] http://lists.linuxfoundation.org/pipermail/linux-pm/2012-April/033976.html
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ