From: Jeff Garzik <jeff@garzik.org>
To: Mark Lord <liml@rtr.ca>,
Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-scsi <linux-scsi@vger.kernel.org>
Subject: Port control interface (was Re: [PATCH] ata: ahci: power off unused ports)
Date: Fri, 09 May 2008 11:28:35 -0400 [thread overview]
Message-ID: <48246DA3.9080307@garzik.org> (raw)
In-Reply-To: <48246872.8000502@rtr.ca>
Mark Lord wrote:
> And a more general note: I still believe we should have a follow-up
> feature to this one, to enable polling for newly inserted drives.
>
> That would allow powering down idle ports to save money/planet/whatever,
> but still with hotplug capability. The polling interval should be
> tunable in /sys, with a default of, say, once every couple of seconds.
>
> Thanks for working on this stuff.
In the grand open source tradition of "pass the buck", I've long been
hoping that someone would take a few days, sit down, and hammer out the
policy side of this.
We -don't- want to do hotplug-active all the time -- the current default
in all drivers that support device hotplug -- because it needlessly
keeps parts active that are unused 99.9% of the time [when they are empty].
Admins need a generic way to control SATA ports and links from
userspace. Within that, admins need to be able to set a link's hotplug
state among three choices: hotplug-active [when supported],
hotplug-poll, and hotplug-never. And of course, hotplug-poll's interval
should be tunable.
And of course this control interface needs to be usable on SAS/SATA
cards that will be common in the future (broadsas, mvsas are early
examples).
This is why I look askance at an AHCI BIOS flag. That's merely a hint,
and potentially unreliable one at that. It could just be describing
what the BIOS writer felt were the ports that _should_ be hotpluggable
-- i.e. not even describing what is _possible_ but someone's definition
of "reasonable." The BIOS flag might even be filled with fuzz (AHCI's
BIOS-written registers have occasionally been shipped into the field
uninitialized).
A better solution involves taking the BIOS flag and using that to set a
default policy that an admin can easily override using the
above-mentioned control interface.
Because in some cases, that BIOS flag might do the wrong thing, and we
need to give the admin an ability to undo the damage.
Jeff
next prev parent reply other threads:[~2008-05-09 15:28 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-08 23:10 [PATCH] ata: ahci: power off unused ports Kristen Carlson Accardi
2008-05-08 23:37 ` Matthew Garrett
2008-05-08 23:35 ` Kristen Carlson Accardi
2008-05-09 0:14 ` Matthew Garrett
2008-05-09 0:28 ` Kristen Carlson Accardi
2008-05-09 15:58 ` Lennart Sorensen
2008-05-09 16:06 ` Matthew Garrett
2008-05-09 16:14 ` Lennart Sorensen
2008-05-09 17:14 ` Kristen Carlson Accardi
2008-05-09 15:06 ` Mark Lord
2008-05-09 15:28 ` Jeff Garzik [this message]
2008-05-27 3:08 ` Theodore Tso
2008-05-27 21:32 ` Kristen Carlson Accardi
2008-05-27 22:59 ` Theodore Tso
2008-05-27 23:32 ` Kristen Carlson Accardi
2008-05-31 8:00 ` Pavel Machek
2008-06-01 19:16 ` Jeff Garzik
2008-06-02 7:04 ` Alan Cox
2008-06-02 7:43 ` Jeff Garzik
2008-06-02 8:22 ` Alan Cox
2008-06-02 9:48 ` Jeff Garzik
2008-06-02 13:54 ` Alan Cox
2008-06-02 16:55 ` Kristen Carlson Accardi
2008-06-02 13:03 ` Mark Lord
2008-06-02 16:07 ` Jeff Garzik
2008-06-02 17:00 ` Kristen Carlson Accardi
2008-06-02 17:45 ` Jeff Garzik
2008-06-02 17:47 ` Kristen Carlson Accardi
2008-06-02 18:15 ` Jeff Garzik
2008-06-02 18:16 ` Kristen Carlson Accardi
2008-06-02 18:30 ` Ric Wheeler
2008-06-02 18:40 ` Jeff Garzik
2008-06-02 18:49 ` Ric Wheeler
2008-06-02 18:52 ` Jeff Garzik
2008-06-02 20:00 ` Matthew Garrett
2008-06-02 18:38 ` Jeff Garzik
2008-06-03 16:49 ` Kristen Carlson Accardi
2008-06-02 17:07 ` Greg Freemyer
2008-06-02 16:57 ` Kristen Carlson Accardi
2008-06-02 17:44 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48246DA3.9080307@garzik.org \
--to=jeff@garzik.org \
--cc=kristen.c.accardi@intel.com \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).