[-Lin, +Lin] On Wed, Sep 12, 2012 at 1:02 PM, Gwendal Grignou <gwendal@xxxxxxxxxx> wrote: > Lin, > > Commit 9a6d6a2ddabbd32c07f6a38b659e5f3db319fa5a introduces a change > in sysfs directory for ata controller: > > Before: > /sys/devices/pci0000:00/0000:00:1f.2 (ahci controller) > |-- ata1 (ata port) > |-- host0 (scsi host) > |-- target0:0:0 (scsi target) > |-- 0:0:0:0 (disk) > > After: > /sys/devices/pci0000:00/0000:00:1f.2 (ahci controller) > |-- ata1 (ata port) > |-- host0 (scsi host) > |-- target0:0:0 (scsi target) > |-- 0:0:0:0 (disk) > > The problem is an ata controller, managed by libata, is still > considered by the kernel as a SCSI controller: diverging even more > from other SCSI controller sysfs layout is not a good idea. > When I wrote libata-transport.c, my plan was to be consistent with SAS > objects: for instance, for a SAS controller with a simple SAS topology > we have: > > > /sys/bus/pci/devices/0000\:0c\:00.0/ > |-- host7/ > |-- phy-7:0 > |-- phy-7:1 > .. > |-- phy-7:7 > |-- port-7:0 > |-- end_device-7\:0 > |-- target7:0:0/ > |-- 7:0:0:0 > |-- port-7:1 > .. > > Similarly, I wanted to represent an ata_port [equivalent to SAS phy] > and ata_link [equivalent to SAS port] under scsi_host hostX object, > but as far as i remember, when I wrote the code that was not possible, > I could not find a clean way to share object references between libata > and scsi layer. That's why ata_port object was sitting alongside to > the scsi_host object. I have to see if it is possible now. > > In the meantime, what would be the impact to revert that commit? > Do you think melting libata sysfs object into scsi sysfs objects would > work with your changes related to pm? > > Thanks, > > Gwendal. -- 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
