Hi,

No, I do not think the existing feat_num-based check is sufficient here.

That check only verifies that num_cqs does not exceed the FCoE CQ
resources reported by the hardware:

    fcoe_pf_params->num_cqs <= p_hwfn->hw_info.feat_num[QED_FCOE_CQ]

But the ramrod field being filled afterwards is a fixed-size array:

    cq_cmdq_sb_num_arr[SCSI_MAX_NUM_OF_CMDQS]

and SCSI_MAX_NUM_OF_CMDQS is 64 in the current tree.

The in-tree qedf caller derives num_cqs from the device-reported CQ count
and the online CPU count:

    dev_info.num_cqs = FEAT_NUM(hwfn, QED_FCOE_CQ)
    num_queues = min(dev_info.num_cqs, num_online_cpus())
    fcoe_pf_params->num_cqs = num_queues

So the existing resource check and the ramrod array capacity are not the
same bound. If the hardware reports more than 64 FCoE CQs, current-tree
callers can still pass a num_cqs value that satisfies the feat_num check
but exceeds ARRAY_SIZE(cq_cmdq_sb_num_arr).

I can resend with this clarified in the commit message.

Best regards,
Pengpeng