On 11/13/2014 06:10 PM, Benjamin Herrenschmidt wrote:
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.
Yes, nice to have more precise error codes so I'm adding them in firmware
and rolling out new version of the FW. Please look at it.
Thanks,
Neelesh
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
