On Mon, Jan 17, 2011 at 12:05:04PM -0600, James Bottomley wrote: > On Mon, 2011-01-17 at 18:48 +0100, Herbert Poetzl wrote: > > On Mon, Jan 17, 2011 at 06:39:46PM +0100, Tejun Heo wrote: > > > On Mon, Jan 17, 2011 at 06:34:33PM +0100, Herbert Poetzl wrote: > > > > hmm, haven't had the time to dig through the specs yet, but > > > > at least addonics seems to disagree here: > > > > > > > > http://www.addonics.com/products/host_controller/tutorial_pm.asp > > > > > > > > but maybe that's just a marketing page with no relation > > > > to reality .... > > > > > > That's hardware RAID PMP. It would just show up as a single drive to > > > the host. They can do whatever they want to if they do that. > > > > okay, understood. > > > > > > > AFAIK, it just doesn't care. It could be ses-2 or whatever else. It > > > > > just transmits the binary blob it receives via sysfs and vice-versa. > > > > > > > > the interesting part here is, that the AHCI host controller > > > > my PMP is connected to recognizes the PMP perfectly fine > > > > (i.e. more than one drive works just as expected), but doesn't > > > > seem to allow for the em_message part (despite the fact that > > > > the attached PMP seems to be SEMB/SEP capable) ... > > > > > > > > maybe this is just a bug in the kernel code, maybe the AHCI > > > > implementation doesn't allow a PMP to receive enclosure > > > > management messages at all ... > > > > > > AFAIK, the ahci em message thing is not via PMP. > > > It's for cases where the ahci controller is directly connected > > > to an enclosure. Well, that's my understanding anyway. > > > > okay, so something similar would be useful for controlling > > enclosures attached to PMPs then? > > > > what would be the 'proper' place in the sysfs tree, espceically > > as the PMP doesn't show up there (yet)? > > > > how would I go about adding something like that to the kernel > > and where should it be placed (sysfs and code wise)? > > OK, just so we're not at cross purposes: > > 1. For an enclosure processor to show up and be attached to the > enclosure driver, it has to present as a SCSI target. This > often means handling nasty encapsulations somewhere (SES is > most often used on non-standard busses like i2c or GPIO). If > it's within a PMP and has a defined encapsulation which ATA > recognises, it sounds like libata is the best place for this. it seems that the SATA specification, specifically the PMP part 'defines' something called SEMB (Smart Enclosure Management Bridge) which is controlled via specific SATA PMP commands to send 'messages' over (typically) I2C to an SEP (Smart Enclosure Processor) which can act upon them and even generate data/replies to retrieve information like the temperature, fan status, etc > 2. The above has nothing to do with whether the PMP device shows > up in sysfs or has a bsg command port. That's a completely > separate discussion based on whether it makes sense (and > whether we can cope with the topological complexity). Just by > way of example, it's mostly not possible to use expanders with > enclosure devices via our expander bsg device, because there's > no SMP encapsulation of SES. What mostly happens is that the > expander has two or more target ports, one of which is SMP > and the other (completely separate one) is an addressable SES > target. as far as I understood, the SEMB is a separate and well defined entity controllable via special PMP commands ... not every PMP has to have one, but if they do, it should conform to the specification, even on the I2C layer HTC, Herbert > 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
