| Message ID | 20240827030302.1006179-1-lihongbo22@huawei.com (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | [-next,v2] wifi: mac80211: use max to simplify the code | expand |
On Tue, 2024-08-27 at 11:03 +0800, Hongbo Li wrote: > The following Coccinelle/coccicheck warning reported by > minmax.cocci: > WARNING opportunity for max() Yeah well, maybe sometimes we shouldn't blindly follow tools ... > Let's use max() to simplify the code and fix the warning. You should explain why. I think only one out of four changes in this patch is correct, semantically. johannes
On 2024/8/27 15:25, Johannes Berg wrote: > On Tue, 2024-08-27 at 11:03 +0800, Hongbo Li wrote: >> The following Coccinelle/coccicheck warning reported by >> minmax.cocci: >> WARNING opportunity for max() > > Yeah well, maybe sometimes we shouldn't blindly follow tools ... > >> Let's use max() to simplify the code and fix the warning. > > You should explain why. > > I think only one out of four changes in this patch is correct, > semantically. > You mean sometimes we should keep the variable type in comparison? Thanks, Hongbo > johannes >
On Tue, 2024-08-27 at 15:29 +0800, Hongbo Li wrote: > > On 2024/8/27 15:25, Johannes Berg wrote: > > On Tue, 2024-08-27 at 11:03 +0800, Hongbo Li wrote: > > > The following Coccinelle/coccicheck warning reported by > > > minmax.cocci: > > > WARNING opportunity for max() > > > > Yeah well, maybe sometimes we shouldn't blindly follow tools ... > > > > > Let's use max() to simplify the code and fix the warning. > > > > You should explain why. > > > > I think only one out of four changes in this patch is correct, > > semantically. > > > You mean sometimes we should keep the variable type in comparison? No, I just don't think these are semantically calculations of a maximum, even if they look that way. That's why I asked: Why are you making this change? It looks like you're making this change just because you want coccicheck to be silent here. But that's *really* not a good reason! Don't do that, ever, *think* about the changes you're making too. We should consider the primary consumer of the code to be *people*, not the compiler or tools like coccicheck. And for *people*, applying max() to a link ID makes no sense. It's a link ID, not any kind of value that applying max() to makes any sense. In contrast, for the timeout value there that you changed, that _does_ make sense: it clearly wants to take the longer of the two durations. So then why do we have patterns that look like max(0, link_id)? That's because we treat -1 as a special value indicating "no link, but for the whole sta/vif/...", "don't care about the link" or "MLD not used" (depending on the context). Internally in the code, however, we use 0 for non-MLD to simplify older drivers and internal logic. That's why we end up with "link_id >= 0 ? link_id : 0" in some places. But it's fundamentally not max() even though it looks like it. Replacing it with max() does this a disservice. Now arguably open-coding it often (though three perhaps isn't often, but I'm surprised it's only three times) maybe isn't a great idea either, but then that should be solved differently. So yeah, please think about changes, don't make them blindly. johannes
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h index d382d9729e85..6b75c7eeff25 100644 --- a/net/mac80211/driver-ops.h +++ b/net/mac80211/driver-ops.h @@ -971,7 +971,7 @@ drv_mgd_protect_tdls_discover(struct ieee80211_local *local, return; WARN_ON_ONCE(sdata->vif.type != NL80211_IFTYPE_STATION); - link_id = link_id > 0 ? link_id : 0; + link_id = max(link_id, 0); trace_drv_mgd_protect_tdls_discover(local, sdata); if (local->ops->mgd_protect_tdls_discover) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 4779a18ab75d..60a7631f0457 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -5375,7 +5375,7 @@ ieee80211_determine_our_sta_mode_auth(struct ieee80211_sub_if_data *sdata, struct ieee80211_conn_settings *conn) { ieee80211_determine_our_sta_mode(sdata, sband, NULL, wmm_used, - req->link_id > 0 ? req->link_id : 0, + max(req->link_id, 0), conn); } diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c index b5f2df61c7f6..e77c9f07b046 100644 --- a/net/mac80211/scan.c +++ b/net/mac80211/scan.c @@ -1013,10 +1013,8 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local, */ if ((chan->flags & (IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR)) || !scan_req->n_ssids) { - *next_delay = msecs_to_jiffies(scan_req->duration) > - IEEE80211_PASSIVE_CHANNEL_TIME ? - msecs_to_jiffies(scan_req->duration) : - IEEE80211_PASSIVE_CHANNEL_TIME; + *next_delay = max(msecs_to_jiffies(scan_req->duration), + IEEE80211_PASSIVE_CHANNEL_TIME); local->next_scan_state = SCAN_DECISION; if (scan_req->n_ssids) set_bit(SCAN_BEACON_WAIT, &local->scanning); diff --git a/net/mac80211/tdls.c b/net/mac80211/tdls.c index f07b40916485..719739def96c 100644 --- a/net/mac80211/tdls.c +++ b/net/mac80211/tdls.c @@ -919,7 +919,7 @@ ieee80211_tdls_build_mgmt_packet_data(struct ieee80211_sub_if_data *sdata, int ret; struct ieee80211_link_data *link; - link_id = link_id >= 0 ? link_id : 0; + link_id = max(link_id, 0); rcu_read_lock(); link = rcu_dereference(sdata->link[link_id]); if (WARN_ON(!link))
The following Coccinelle/coccicheck warning reported by minmax.cocci: WARNING opportunity for max() Let's use max() to simplify the code and fix the warning. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> --- v2: - change the commit title v1: https://patchwork.kernel.org/project/linux-wireless/patch/20240824074033.2134514-2-lihongbo22@huawei.com/ --- net/mac80211/driver-ops.h | 2 +- net/mac80211/mlme.c | 2 +- net/mac80211/scan.c | 6 ++---- net/mac80211/tdls.c | 2 +- 4 files changed, 5 insertions(+), 7 deletions(-)