Hi, I'm sorry to keep you waiting. <snip> > > If you need the modes to be discovered in some specific order, then we > > need the framework to allow you to do that. So perhaps the tcpci > > drivers should be able to supply the preferred order to the tcpm? > > > > But as such, unless I'm mistaken, this patch will change the logic so > > that only the partner alt modes that the port supports get registered, > > and that way are exposed to the user. You can't do that - right now > > it's the only way we can inform the user about them. All partner > > alternate modes (at least the SVIDs) must be exposed to the user one > > way or the other, regardless does the port support them or not. > > The test this patch tries to fix could just be written without consideration > of this. My guess is that the test was designed such that the SVIDs before > the DisplayPort SVID are unknown to the port under test so the mentality > could have been "why should a port care about SVIDs it doesn't know > about?" > > A defense I could make for it is that the USB PD CTS doesn't test > to see if a port under test sends Discover Modes for every SVID returned > in a Discover SVIDs ACK, so the interpretation isn't invalid. I've seen other > tcpm implementations handle Discover Modes this way as well. > > Regardless, you're definitely right that the user should know about all > Alt Modes/SVIDs - the port would lose SVID information without > registering a partner altmode for it. Currently I think the approaches to pass > this test look like: > 1. Your suggestion - let the tcpci decide if there should be a > discovery order. > Alternatively, let the tcpci decide if it wants to opt into this > patch's behavior of > only discovering modes for known SVIDs - a strict discovery flag. > 2. Send a Discover Mode message to known SVIDs first in the order > they come in, and then to unknown SVIDs. The test passes and no information > is lost, but it's unnecessary refactoring just to pass one test for > one Alt Mode. > 3. Don't send a Discover Mode message to unknown SVIDs, but do register > an Alt Mode with blank info for that SVID. It passes the test without having to > do any reordering compared to the first option and it preserves supported > SVIDs. But, the port would lose information such as each SVID's Alt Modes > VDO plus each SVID can support more than one Alt Mode. > > Let me know if any of these approaches sound worth pursuing; I do think > Option 1 does make more sense than the others. I would like to hear what Guenter thinks. Guenter, do you have time to take a look at this? thanks, -- heikki
