Michael Ellerman <m...@ellerman.id.au> writes: > Vipin K Parashar <vi...@linux.vnet.ibm.com> writes: > >> OPAL returns OPAL_WRONG_STATE for XSCOM operations >> >> done to read any core FIR which is sleeping, offline. > > OK. > > Do we know why Linux is causing that to happen? > > It's also returned from many of the XIVE routines if we're in the wrong > xive mode, all of which would indicate a fairly bad Linux bug. > > Also the skiboot patch which added WRONG_STATE for XSCOM ops did so > explicitly so we could differentiate from other errors: > > commit 9c2d82394fd2303847cac4a665dee62556ca528a > Author: Russell Currey <rus...@russell.cc> > AuthorDate: Mon Mar 21 12:00:00 2016 +1100 > > xscom: Return OPAL_WRONG_STATE on XSCOM ops if CPU is asleep > > xscom_read and xscom_write return OPAL_SUCCESS if they worked, and > OPAL_HARDWARE if they didn't. This doesn't provide information about why > the operation failed, such as if the CPU happens to be asleep. > > This is specifically useful in error scanning, so if every CPU is being > scanned for errors, sleeping CPUs likely aren't the cause of failures. > > So, return OPAL_WRONG_STATE in xscom_read and xscom_write if the CPU is > sleeping. > > Signed-off-by: Russell Currey <rus...@russell.cc> > Reviewed-by: Alistair Popple <alist...@popple.id.au> > Signed-off-by: Stewart Smith <stew...@linux.vnet.ibm.com> > > > > So I'm still not convinced that quietly swallowing this error and > mapping it to -EIO along with several of the other error codes is the > right thing to do.
FWIW I agree - pretty limited cases where it should just be converted into -EIO and passed on - probably *just* the debugfs interface to be honest. -- Stewart Smith OPAL Architect, IBM.