On Thu, 2014-11-13 at 21:56 +1100, Benjamin Herrenschmidt wrote:
>
> No, there is no timeout, if that fails something went quite wrong, it
> could almost be a BUG_ON (basically we passed a wrong token or a NULL
> msg).
>
> > > + }
> > > +
> > > + rc = be64_to_cpu(msg.params[1]);
> > > + if (rc != OPAL_SUCCESS) {
> > > + rc = -EIO;
> > > + goto exit;
> > > + }
> > > +
Actually, to correct myself, there are a number of error conditions
including timeouts inside the FW layer, but they are returned here, not
from opal_async_wait_response(). So indeed, we could do some error code
conversion at that point.
Neelesh, can you do that on top of your patch that adds the detailed
error codes ? We can merge it fw side tomorrow if you have a new spin,
worst case if the FW is old and only returns OPAL_HARDWARE we return
-EIO and if the FW is newer we'll have more precise error codes in Linux
too.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
