[PATCH 09/10] wifi: mt76: mt7996: rework background radar check for mt7990

[Ben Greear]

On 4/1/25 18:30, Ping-Ke Shih wrote:
> Shayne Chen <shayne.chen at mediatek.com> wrote:
> 
>> On Mon, 2025-03-31 at 05:55 +0000, Ping-Ke Shih wrote:
>>>
>>>
>>> Shayne Chen <shayne.chen at mediatek.com> wrote:
>>>
>>> [...]
>>>
>>>> +
>>>> +bool mt7996_eeprom_has_background_radar(struct mt7996_dev *dev)
>>>> +{
>>>> +       switch (mt76_chip(&dev->mt76)) {
>>>> +       case MT7996_DEVICE_ID:
>>>> +               if (dev->var.type == MT7996_VAR_TYPE_233)
>>>> +                       return false;
>>>> +               break;
>>>> +       case MT7992_DEVICE_ID:
>>>> +               if (dev->var.type == MT7992_VAR_TYPE_23)
>>>> +                       return false;
>>>> +               break;
>>>> +       case MT7990_DEVICE_ID: {
>>>> +               u8 path, rx_path, nss, *eeprom = dev-
>>>>> mt76.eeprom.data;
>>>> +
>>>> +               mt7996_eeprom_parse_stream(eeprom, MT_BAND1, &path,
>>>> &rx_path, &nss);
>>>> +               /* Disable background radar capability in 3T3R */
>>>> +               if (path == 3 || rx_path == 3)
>>>> +                       return false;
>>>> +               break;
>>>> +       }
>>>
>>> The indentation of close brace looks weird.
>>
>> Will fix it, thanks.
>>>
>>> Since -Wdeclaration-after-statement is dropped, I think compilers
>>> will not
>>> warn without the braces. But note that it is still not recommended to
>>> put declarations in the middle.
>>>
>> Since those variables are currently only used by mt7990 case, I think
>> they can be putting there for the moment.
> 
> That looks not very natural though...
> 
> In fact, the declarations either in beginning of this function or at the
> mt7990 case, the frame size (stack) are the same.

The open parens make it the start of a new code block, so even strict
old c compilers should handle this just fine, and I personally like
variables kept to a tight local scope if possible.  Unless there is a
technical reason to change the code, then there are probably more important
things to worry about.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com