On Tuesday, August 29, 2006 9:35 AM, James Bottomley wrote: > I think the object should be to have all the SAS cards > display the same > thing, so support for internal SMP passthrough looks to be the way to > implement this. Also, if the SAS transport class does this, > then we can > hook that up to BSG instead of having to have the drivers do it > individually. Ok, I will look into passing internal smp request so link_errors and link/phy reset can work for expander phys. It maybe a couple weeks as sles10 activities have been keeping rather busy of late. > > I understood there was some architectural objection to doing SMP > passthrough from the LSI architects ... does that still exist? > I think their main complaint was they didn't want transport layer doing discovery. Something that would be redundant as fusion fw already handles that, and that would introduce a performance hit with all the primitives bouncing around. What we currently do is reading config pages to determine what was setup by firmware, which is fine with them. I believe you already assured me that the transport layer wouldn't take over discovery if we exported a portal. My idea of the portal was for Doug Gilberts smputils to use generic interface, instead of the current mptctl interface. To what extent would transport layer use the portal besides exporting it to userspace? Eric - 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
