Re: [PATCH 0/3] Insert ATA transport objects in SCSI syfs topology.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 1, 2012 at 11:22 AM, Gwendal Grignou <gwendal@xxxxxxxxxx> wrote:
> This set of patches improve ATA transport classes integration with SCSI
> objects.
>
> Before [2.6.x]
>
> Ata and scsi transport class where separated:
> `--0000:09:00.0
> |  `--ata1
> |  |  `--port_port
> |  |  `--link1
> |  |  |  `--dev1.0
> |  |  |  `--dev1.1
> |  `--ata2
> |  ...
> |  `--host0
> |  |  `--scsi_host
> |  |  |  `--host0
> |  |  `--target0:0:0
> |  |  |  `--0:0:0:0
> |  |  |  |  `--block
> |  |  |  |  |  `--sda
> |  |  |  |  |  |  `--sda1
>
> In 3.2, Lin - in commit 9a6d6a2ddabbd32c07f6a38b659e5f3db319fa5a - addressed
> the issue of linking the ata port with the scsi host object by placing the
> scsi_host object under ata port objects.
>
> However to be more consistent with other transport, this patch does the opposite:
>
> For instance, with SAS transport, We have
> `--0000:0b:00.0
> |  `--host6
> |  |  `--phy-6:0
> |  |  `--phy-6:1
> ...
> |  |  `--port-6:0
> |  |  |  `--end_device-6:0
> |  |  |  |  `--sas_device
> |  |  |  |  |  `--end_device-6:0
> |  |  |  |  `--sas_end_device
> |  |  |  |  |  `--end_device-6:0
> |  |  |  |  `--target6:0:0
> |  |  |  |  |  `--6:0:0:0
> |  |  |  |  |  |  `--block
> |  |  |  |  |  |  |  `--sdb
> ...
> |  |  `--port-6:1
> |  |  |  `--end_device-6:1
> ...
> phy and port have to be separated, sas_port are created dynamically.
>
> For ata, all objects are created at initialization time, so the layout is:
> `--0000:09:00.0
> |  `--host0
> |  |  `--port1
> |  |  |  `--link1
> |  |  |  |  `--dev1.0
> |  |  |  |  |  `--target0:0:0
> |  |  |  |  |  |  `--0:0:0:0
> |  |  |  |  |  |  |  `--block
> |  |  |  |  |  |  |  |  `--sda
>
> If we have a port multiplier, more links are created.
> `--0000:09:00.0
> ...
> |  `--host4
> |  |  `--port5
> |  |  |  `--link5
> |  |  |  |  `--dev5.0
> [device for the port multiplier]
> |  |  |  `--link5.0
> |  |  |  |  `--dev5.0.0
> |  |  |  |  |  `--target4:0:0
> |  |  |  |  |  |  `--4:0:0:0
> |  |  |  |  |  |  |  `--block
> |  |  |  |  |  |  |  |  `--sdc
> [disk in port 0 of the port multiplier]
> ...
> |  |  |  `--link5.2
> |  |  |  |  `--dev5.2.0
> |  |  |  |  |  `--target4:2:0
> |  |  |  |  |  |  `--4:2:0:0
> |  |  |  |  |  |  |  `--block
> |  |  |  |  |  |  |  |  `--sde
> [disk in port 2 of the port multiplier]
>
> In consequence, the path of a scsi device becomes:
> .../0000:00:1f.2/host0/port1/link1/dev1.0/target0:0:0/0:0:0:0
> dev1.0 indicates the master device [0] in ata port 1.
> ata1 being under host0, we know the reliationships between the scsi_host id and
> ata port id.
>
> or when a port multiplier is present: for instance the device in port 4 of the
> port multiplier:
> .../0000:00:06.0/0000:09:00.0/host5/port6/link6.4/dev6.4.0/target5:4:0/5:4:0:0

What's the benefit of this?  From a PM perspective now it seems we'll
have the parent hardware port suspended before all the scsi_hosts on
that port, which defeats the original purpose of putting the ata_port
in the PM hierarchy.

--
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


[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux