[Skiboot] [PATCH v7 6/9] npu2-opencapi: Train OpenCAPI links and setup devices

[Frederic Barrat]

Le 28/02/2018 à 13:43, Andrew Donnellan a écrit :
> On 28/02/18 22:41, Frederic Barrat wrote:
>> We never really discussed it and I don't know how deep you looked at 
>> it, but for the "none" or "prbs31" case, we create a PHB but no 
>> associated slot. It has the side effects that various operations 
>> skiboot does when looking for PCI devices (reset, scan, ...) will fail 
>> with traces in the skiboot log. Similarly, linux will see the PHB, but 
>> is unable to do anything with it (it logs an error about an ioda table 
>> reset failing).
>> I believe this is what we want, i.e. don't really hide it, but don't 
>> let anybody mess with it as to leave the prbs31 pattern transmission 
>> alone. Or for the "none" case, don't interfere with whatever is done 
>> to the link through scom.
>>
>> When we add the capability to trigger link reset from the OS, I don't 
>> think it will matter either if we can't reset such a link without 
>> rebooting. In reality, for the "none" case, there's no opencapi 
>> device, it's just a loopback cable. So we don't have to sweat to be 
>> able to change that dynamically. Same is true for prbs31, it's used 
>> for signal integrity testing and I'm not even sure what's on the other 
>> side of the link. Definitely not a "normal" fpga image that our driver 
>> can handle. So in both scenarios, a change of the nvram setting + 
>> reboot doesn't seem like too much to ask since physical action is 
>> expected on the system anyway.
> Yeah, if you're using these options, you already expect everything 
> normal to be broken...
> 
> Though, hmm... We could just not register the PHB...

But then we get an error trace on the console to complain that the phb 
doesn't have an ID. Another option would be to not create the phb, but 
then it becomes hidden, which I don't think is desirable.

   Fred