linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: jeff@garzik.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH] libata: add enclosure management support
Date: Thu, 17 Jan 2008 16:50:42 -0600	[thread overview]
Message-ID: <1200610243.3255.47.camel@localhost.localdomain> (raw)
In-Reply-To: <20080115164417.4a5e2789@appleyard>

On Tue, 2008-01-15 at 16:44 -0800, Kristen Carlson Accardi wrote:
> Add Enclosure Management support to libata and ahci.
> 
> This patch adds support for the LED protocol, as defined in the AHCI spec.
> It adds a generic em_message and em_type sysfs entry per host.  It also adds
> a sw_activity field per existing drive.
> 
> The em_message field can be used by the driver to take enclosure management
> commands from userspace.  In the case of the LED protocol, writes and reads
> from em_message correspond to the LED message format as defined in the 
> AHCI spec.
> 
> em_message type is a read only file that displays the current enclosure
> management protocol that is used by the driver.
> 
> sw_activity is used by drivers which support software controlled activity LEDs.
> It has the following valid values:
> 
> 0	OFF - the LED is not activated on activity
> 1	BLINK_ON - the LED blinks on every 10ms when activity is detected.
> 2	BLINK_OFF - the LED is on when idle, and blinks off every 10ms when
> 		    activity is detected.
> 
> It's important to note that the user must turn sw_activity OFF it they wish
> to control the activity LED via the em_message file.

One of the things we really need to do is to get some type of generic
enclosure support.  I note that ahci support three standard eclosure
management protocols (SAF-TE, SES-2, SFF-8485 SGPIO) as well as the one
proprietary one you've chosen to implement.  Is that because no-one in
the field has actually connected AHCI up to anything supporting one of
the standard protocols?

I'm looking at this from slightly the other way around:  the SAS
protocol is virtually mandating SFF-8485 as the enclosure protocol to
the point that it's actually built into the sas management protocol ...
I was starting to wonder how we should be taking advantage of this.

The implementation probably should be generic (above SCSI or IDE or ATA)
but it would obviously need to tap into the subsytem/transport/device
specific pieces, so possibly block looks to be the right place to start?

James



  reply	other threads:[~2008-01-17 22:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-16  0:44 [PATCH] libata: add enclosure management support Kristen Carlson Accardi
2008-01-17 22:50 ` James Bottomley [this message]
2008-01-17 23:36   ` Kristen Carlson Accardi
2008-01-18  1:55   ` Jeff Garzik
2008-01-18 16:52   ` Kristen Carlson Accardi
2008-01-18 17:11     ` James Bottomley
2008-01-18 17:41       ` Kristen Carlson Accardi
2008-01-19  0:16         ` James Bottomley
2008-01-19  0:35           ` Kristen Carlson Accardi
2008-01-19  0:47             ` James Bottomley
2008-01-19  0:55               ` Kristen Carlson Accardi
2008-01-19  2:33                 ` James Bottomley
2008-01-19  0:52           ` Kristen Carlson Accardi
2008-01-21 18:12             ` James Bottomley

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=1200610243.3255.47.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=jeff@garzik.org \
    --cc=kristen.c.accardi@intel.com \
    --cc=linux-ide@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).