On Mon, 2011-01-17 at 16:40 +0100, Tejun Heo wrote:

(cc'ing linux-scsi)
Hello,

On Fri, Jan 14, 2011 at 06:37:59PM +0100, Herbert Poetzl wrote:

quoted

Fair enough, let's start with a bunch of simple questions
I got from looking at the code (which I did just recently,
so don't expect deep understanding of the inner workings,
or even intelligent questions FWIW :)

- libata is used in the kernel for ata, sata and to some
  extend for scsi (via (s)ata), as a helper library.

The (s) there is Serial not SCSI, but yes some SAS drivers use libata
to drive SATA devices attached to SAS controllers.

quoted

  is there any counterpart in userspace to communicate
  with (s)ata host/devices or how are the interfaces to
  userspace designed to work?

SG_IO is the standard way to issue custom commands.  You need to wrap
ATA command inside a SCSI SCSI-ATA passthrough command.  Take a look
at hdparm, smartctl or any other tool which issues direct commands.

quoted

- the SiI3726 supports SAF-TE and SES protocols for the
  SEMB/SEP and the EMCs are sent through the SATA interface
  (according to the docu, SEP_ATTN in the command register
  and SEP command code in the features register)

  + how would I send such a command and retrieve the result
    (if there is one) from within the kernel (maybe with
    libata or from the ahci layer)?

If it's a proper command SAT passthrough via SG_IO should work but I'm
not sure whether it is.  Is it?

it sounds like it can be sent via ATA_12 or ATA_16 then depending on
what it does to the device state model.

quoted

- the SiI3726 supports GPIO pins, which can be reached via
  the General Status and Control Register [130] and accoring
  to the docu, the Read/Write Port Multiplier command can
  be used to read/write that register.
 
  + how would I go about issuing such a command and where
    should it be done? i.e. what about interference with
    other commands? what about retrieving return values?

The problem is that the PMP device itself is currently not allocated a
userland visible device, so it doesn't have any /dev/* node.  Hmmm...

So perhaps it should be.  If you look at the equivalent topology on SAS,
our expanders have a bsg device node precisely so that we can do this.

That said, SAS expanders have a defined protocol (SAS Management
Protocol) to talk to the outside world, so they are real visible objects
always in our topology ... I'm not sure PMP has this ... it seems that
all PMP visibility is an extension to the standard?

quoted

quoted

There also was something added to ahci which is exported through
sysfs.

I saw that the ahci driver uses *em_message* which I
think might be related to sending activity messages and
it also lists capabilities (which include 'ems') on
host adapters, but I'm not entirely sure this is SEMB
related (yet)

The message sent there can be of any format and that's why it was
added as a separate sysfs node.

ISTR there's a SCSI enclosure management driver.  Maybe SCSI people
have better clues about how enclosure management should be done?

Sure, as long as it speaks standard ses-2, there shouldn't be a protocol
problem.  The main problem is recognition: ses has to bind to an
enclosure device.  It can bind either to an explicit device (about all
the enclosures I've seen so far) where the ses device has a separate
address in the SCSI topology or an implicit device (where another SCSI
device indicates it has an enclosure port embedded in it).  As currently
coded, our ses driver only does the former probably the best way is to
expose the ses device via libata and we'll simply bind to it.

James


However,