On Sat, 2006-03-04 at 11:17 -0700, Moore, Eric wrote: > I'm not clear what your intent is here. All the info is there, so I'm not sure > why this change is needed. The sas_transport implementation Christoph > has layed out is a flat model. In /sys/class/sas_phy, you will see all the > phys for both hba and expander all togeather in the tree.The rphy is at the > end of a phy link, where it the target protocol could be SMP, STP, SATA, > or SAS; e.g. you can see that in rphy->identify.target_port_protocols. > You can figure out whether its an end device by the attribute by > rphy->indentify.device_type, which could be SAS_END_DEVICE, > SAS_EDGE_EXPANDER, SAS_FANOUT_EXPANDER, or > SAS_PHY_UNUSED. Well, it's not ... the nexus loss timeout parameters weren't available. The intent is to embed the rphys into more representative structures that can have different parameters (an expander has parameters than an end device doesn't and vice versa). Eventually, when the whole lot is converted, the ability to alloc a plain rphy will be revoked and everything will be done via the real device type. The aic94xx needs a full tree representation for this, so I'm planning to add this to the sas transport class. We really need to work out a way for mptsas to display the tree too. Having different topology views for the same physical SAS topology show up when you change HBA is a bit undesirable. > > Temporarily, because mptsas doesn't do this, I've put a flag in to > > indicate whether the rphy is enveloped or not, however, if we enforce > > this for everything, then eventually that would go away. > > > > Ok, I'm not sure what this comment means, in respect to mptsas. > The mptsas driver is reporting all device types to the transport class, > as defined in the SAS spec. It means I couldn't be bothered to add the end device allocations to mptsas, so the code currently understands that there's a separate flag that says whether it can be cast out to the end device or not. > > If everyone's OK with this, I'll do expanders next. > > Ok, the mptsas driver is already reporing expanders to transport class. > This is handled from mptsas.c, in mptsas_probe_one_phy(), when > we call sas_phy_add(). When there is any attached devices at > the end of a phy, we call sas_rphy_add(). Both these functions > exported from sas_transport, work well for both hba, and expanders. > > The patch I sent yesterday is adding support when someone needs to > add a expander after the start of day, or reomove one. Its responding > to the firmware DISCOVERY event. Yes, I know. However, I need expander devices that contain the necessary information to be able to perform discovery in the sas transport class, so they'll appear eventually in the same way that this patch adds end devices ... as objects with embedded rphys. James - : 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
