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

Andrew Donnellan andrew.donnellan at au1.ibm.com
Wed Feb 28 23:43:07 AEDT 2018

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

More information about the Skiboot mailing list