Dan Williams <dan.j.williams@xxxxxxxxx> writes: > Aneesh Kumar K.V wrote: > [..] >> >> Also wondering should the stream id be unique at the rootport level? ie >> for a config like below >> >> # pwd >> /sys/devices/platform/40000000.pci/pci0000:00 >> # ls >> 0000:00:01.0 available_secure_streams power >> 0000:00:02.0 pci_bus uevent >> # lspci >> 00:01.0 PCI bridge: ARM Device 0def >> 00:02.0 PCI bridge: ARM Device 0def >> 01:00.0 Unassigned class [ff00]: ARM Device ff80 >> 02:00.0 SATA controller: Device 0abc:aced (rev 01) >> # >> # lspci -t >> -[0000:00]-+-01.0-[01]----00.0 >> \-02.0-[02]----00.0 >> # >> >> >> I should be able to use the same stream id to program both the rootports? > > For all the IDE capable platforms I know of the stream id allocation > pool is segmented per host-bridge. Do you have a use case where root > ports that share a host-bridge each have access to a distinct pool of > IDE stream ids? I am using FVP simulator for my development. Hence no real device. The spec states: " All IDE TLPs must be associated with an IDE Stream, identified via an IDE Stream ID. ◦ Software must assign IDE Stream IDs such that two Partner Ports use the same value for a given IDE Stream. ◦ Software must assign IDE Stream IDs such that every enabled IDE Stream associated with a given terminal Port is assigned a unique Stream ID value at that Port ◦ It is permitted for a platform to further restrict the assignment of Stream IDs. " If I understand correctly, the stream ID allocation pool per host bridge qualifies as an additional platform restriction? If so, why is Linux enforcing it? Wouldn’t it be more appropriate for the platform code to handle this instead? -aneesh