On 22/08/25 11:07 am, Yibo Dong wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Fri, Aug 22, 2025 at 04:49:44AM +0000, Parthiban.Veerasooran@xxxxxxxxxxxxx wrote:
>> On 22/08/25 8:04 am, Dong Yibo wrote:
>>> +/**
>>> + * mucse_mbx_get_capability - Get hw abilities from fw
>>> + * @hw: pointer to the HW structure
>>> + *
>>> + * mucse_mbx_get_capability tries to get capabities from
>>> + * hw. Many retrys will do if it is failed.
>>> + *
>>> + * @return: 0 on success, negative on failure
>>> + **/
>>> +int mucse_mbx_get_capability(struct mucse_hw *hw)
>>> +{
>>> + struct hw_abilities ability = {};
>>> + int try_cnt = 3;
>>> + int err = -EIO;
>> Here too you no need to assign -EIO as it is updated in the while.
>>
>> Best regards,
>> Parthiban V
>>> +
>>> + while (try_cnt--) {
>>> + err = mucse_fw_get_capability(hw, &ability);
>>> + if (err)
>>> + continue;
>>> + hw->pfvfnum = le16_to_cpu(ability.pfnum) & GENMASK_U16(7, 0);
>>> + return 0;
>>> + }
>>> + return err;
>>> +}
>>> +
>
> err is updated because 'try_cnt = 3'. But to the code logic itself, it should
> not leave err uninitialized since no guarantee that codes 'whthin while'
> run at least once. Right?
Yes, but 'try_cnt' is hard coded as 3, so the 'while loop' will always
execute and err will definitely be updated.
So in this case, the check isn’t needed unless try_cnt is being modified
externally with unknown values, which doesn’t seem to be happening here.
Best regards,
Parthiban V
>
> Thanks for your feedback.
>
>
