On 4/1/25 18:30, Ping-Ke Shih wrote:
Shayne Chen <shayne.chen@xxxxxxxxxxxx> wrote:
On Mon, 2025-03-31 at 05:55 +0000, Ping-Ke Shih wrote:
Shayne Chen <shayne.chen@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
