On Mon, 2015-06-01 at 15:56 +0200, Philippe Bergheaud wrote: > Michael Neuling wrote: > > Please use negative error codes here. -EIO? > > And check it here. > > Mikey, > > I am reluctant to fail the entire CAPI init after a PSL timebase sync failure. > If we ignore the error, the CAPI device stays available (without timebase > sync). > If we honour the error, the CAPI device fails entirely. > > I know three reasons why PSL timebase sync can fail: > 1. h/w failure
This would be a good reason to fail it. Bad hardware, we should fail. > 2. OPAL did not initialize the CAPP timebase (wrong OPAL version) This would not as we are going to have to deal with older opal for a while. Is there a way for us to tell if OPAL has this capability? I guess we could add something to the device tree of the PHB node if we know the timebase has been synced. > 3. the PCIe bus was not powered off/on between shutdown and reboot We should fix that. What's the problem? > I think that it is premature to choose to fail the entire CAPI init in all > cases. > In particular, point 3. introduces a regression, as PCIe off/on was never a > requirement for booting CAPI on P8. We should fix it. Is a PERST enough? > I have tried one workaround do far: forcing the 0 to 1 transition of the tb > bit of the PSL register TB_CTLSTAT. > In vain. > > What do you think? The OPAL one (2) is the most concerning but let's work out if we can determine if the syncing has happened in the CAPP unit or not. If we know it's synced but it fails your test, then I think we should fail the whole probe. I the other reasons (1 and 3) shouldn't be ignored. Mikey _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
