On Wed, Jun 1, 2011 at 7:02 AM, Artur Wojcik <artur.wojcik@xxxxxxxxx> wrote: > This patch enables the SMP READ/WRITE GPIO function interface in libsas SMP > host module. The interface is used to control the SGPIO initiator in the SAS > initiator. The implementation is SFF-8485 and SAS-2 compliant. > > There are two functions in transport class only responsible for reading and > writting GPIO registers. I decided to leave the decission about what type of > registers are supported to lldd. > > Now the user space application may issue SMP READ/WRITE GPIO frame to HBA in > order to read/write GPIO registers. > > Signed-off-by: Artur Wojcik <artur.wojcik@xxxxxxxxx> > --- > drivers/scsi/libsas/sas_host_smp.c | 48 +++++++++++++++++++++++++++++++++++- > include/scsi/libsas.h | 14 +++++++++++ > include/scsi/sas.h | 4 +++ > 3 files changed, 64 insertions(+), 2 deletions(-) > James, thoughts? The thing that struck me most about this patch was the following subtle deletion: > - /* FIXME: need GPIO support in the transport class */ Transport class support in my mind implies sysfs representation of the sgpio targets, this patch is just providing an interface for tickling sgpio-initiator registers in the hba. This is likely fine to get the conversation started, but it punts on the bigger question on whether/how to describe the sgpio initiator topology to userspace. This patch also enforces that the interface to the lldd is raw sgpio protocol, which seems like a passable idea to me. If a vendor does something non-standard they can internally translate sgpio to vendor-specific. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
