On Thu, Oct 4, 2012 at 9:56 AM, Gwendal Grignou <gwendal@xxxxxxxxxx> wrote: >> What's the benefit of this? > + To unify ata transport sysfs topology with other scsi transport. My concern is the thrash and breakage to switch the ordering around given the (minor) growing pains injecting an ata_port into the device path caused. Although, it seems like Aaron has caught where this reversal broke things at the cost of some additional special-casing (4 files changed, 25 insertions(+), 13 deletions(-)). Patch 1 also creates a problem for bisections as the code that assumes <dev>/port/host will break. I don't know... I'm all for consistency, but if the only justification is to make the transports look the "same" we'll still have a glaring transport difference between ata and sas. In the sas case one hba/host spanning all possible sas domains vs the ata case of a guaranteed ata_port per "ata domain" relationship with at least one host per port. The "port" does live higher in the topology in the ata case. > + To easily map a ata_port with its associated scsi_host structure. Not sure this is getting any easier. There would now be three options based on kernel version: look for the ata_port as a host attribute, look at the host's parent, or look for the host's child. -- Dan -- 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