linux-kernel - Re: [PATCH v2] mac80211: mesh: Add support for HW RC implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1466709992.11061.6.camel@sipsolutions.net>
Date:	Thu, 23 Jun 2016 21:26:32 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Maxim Altshul <maxim.altshul@...com>, linux-kernel@...r.kernel.org
Cc:	linux-wireless@...r.kernel.org
Subject: Re: [PATCH v2] mac80211: mesh: Add support for HW RC implementation


> +void sta_get_expected_throughput(struct sta_info *sta, u32 *thr)
> +{
> +	struct ieee80211_sub_if_data *sdata = sta->sdata;
> +	struct ieee80211_local *local = sdata->local;
> +	struct rate_control_ref *ref = NULL;
> +
> +	if (test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
> +		ref = local->rate_ctrl;
> +
> +	/* check if the driver has a SW RC implementation */
> +	if (ref && ref->ops->get_expected_throughput)
> +		*thr = ref->ops->get_expected_throughput(sta-
> >rate_ctrl_priv);
> +	else
> +		*thr = drv_get_expected_throughput(local, &sta-
> >sta);
> +}

I don't really see a reason for the function to take a u32 *thr, rather
than return u32? Would be clearer, IMHO, to just return the value.

Then in the user, it seems that you shouldn't use "rate" as the
variable that gets this result?

johannes