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

[Andrew Donnellan]

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

-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan at au1.ibm.com  IBM Australia Limited