On Sun, Aug 25, 2019 at 10:49 PM David Miller <da...@davemloft.net> wrote:
>
> From: Michael Chan <michael.c...@broadcom.com>
> Date: Sun, 25 Aug 2019 23:54:56 -0400
>
> > +static int bnxt_hwrm_error_recovery_qcfg(struct bnxt *bp)
> > +{
> > + struct hwrm_error_recovery_qcfg_output *resp = bp->hwrm_cmd_resp_addr;
> > + struct bnxt_fw_health *fw_health = bp->fw_health;
> > + struct hwrm_error_recovery_qcfg_input req = {0};
> > + int rc, i;
> > +
> > + if (!(bp->fw_cap & BNXT_FW_CAP_ERROR_RECOVERY))
> > + return 0;
> > +
> > + bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_ERROR_RECOVERY_QCFG, -1, -1);
> > + mutex_lock(&bp->hwrm_cmd_lock);
> > + rc = _hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
> > + if (rc) {
> > + rc = -EOPNOTSUPP;
> > + goto err_recovery_out;
> > + }
>
> How is this logically an unsupported operation if you're guarding it's use
> with an appropriate capability check?
The BNXT_FW_CAP_ERROR_RECOVERY flag says that error recovery should be
supported, but if the firmware call to get the recovery parameters
fails, we return -EOPNOTSUPP to let the caller know that error
recovery cannot be supported. Again, I will try to clean up the error
codes in v2.
