Re: [PATCH] libata: add enclosure management support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux