Alexey Kardashevskiy wrote: [..] > >> access to set T-bit). The device got just one (which is no use here as I > >> understand). > > > > I also have no idea from SPEC how to use the IDE register blocks on EP, > > except stream ENABLE bit. > > Well, there is another problem. > > My other test device has 1 link stream and 1 selective stream, both have > streamid=0 and enable=0 after reset. I only configure 1 selective stream > (write streamid + enable) and do not touch the link stream. > > But the device assumes 2 streams have the same streamid=0 and when it > receives KEY_PROG, it semi-randomly assigns the key to the link stream > in my case so things do not work. The argument for it is: every stream > needs to have an unique id, regardless its enabled state as "enable" can > come before or after key programming (and I wonder if somebody else > interprets it the same way). > > This patch assumes that the selective streamid is the same as its index > in the IDE cap's list of selective streams. Oh, true that should be separated, and perhaps that is the concern that Aneesh has been raising as well? > And it just leaves link streams unconfigured. So I have to work around > my device by writing unique numbers to all streams (link + selective) > I am not using. Meh. This sounds like a device-quirk where it is not waiting for an enable event to associate the key with a given stream index. One could imagine this is either a pervasive problem and TSMs will start considering Stream ID 0 as burned for compatibilitiy reasons. Or, this device is just exhibiting a pre-production quirk that Linux does not need to react, yet. Can you say whether this problem is going to escape your test bench into something mainline Linux needs to worry about? > And then what are we doing to do when we start adding link streams? I > suggest decoupling pci_ide::stream_id from stream_id in sel_ide_offset() > (which is more like selective_stream_index) from the start. Setting aside that I agree with you that Stream index be separated from from Stream ID, what would motivate Linux to consider setting up Link Stream IDE? One of the operational criticisms of Link IDE is that it requires adding more points of failure into the TCB where a compromised switch can snoop traffic. It also adds more Keys and their associated maintainenace overhead. So, before we start planning ahead for Link IDE and Selective Stream IDE to co-exist in the implementation, I think we need a clear use case that demonstrates Link IDE is going to graduate from the specification into practical deployments. We can always cross that sophistication bridge later.
