From: Johannes Berg <johannes@sipsolutions.net>
To: Evan Quan <evan.quan@amd.com>,
rafael@kernel.org, lenb@kernel.org, Alexander.Deucher@amd.com,
Christian.Koenig@amd.com, Xinhui.Pan@amd.com, airlied@gmail.com,
daniel@ffwll.ch, kvalo@kernel.org, nbd@nbd.name,
lorenzo@kernel.org, ryder.lee@mediatek.com,
shayne.chen@mediatek.com, sean.wang@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
Mario.Limonciello@amd.com, Lijo.Lazar@amd.com
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH V2 2/7] wifi: mac80211: Add support for ACPI WBRF
Date: Fri, 09 Jun 2023 10:21:12 +0200 [thread overview]
Message-ID: <ccbaf80adb305ea59eb1a457460b99dc920bb65d.camel@sipsolutions.net> (raw)
In-Reply-To: <20230609072846.1552238-3-evan.quan@amd.com>
On Fri, 2023-06-09 at 15:28 +0800, Evan Quan wrote:
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -5551,6 +5551,10 @@ struct wiphy {
>
> u16 hw_timestamp_max_peers;
>
> +#ifdef CONFIG_ACPI_WBRF
> + bool wbrf_supported;
> +#endif
This should be in some private struct in mac80211, ieee80211_local I
think.
> char priv[] __aligned(NETDEV_ALIGN);
> };
>
> @@ -9067,4 +9071,18 @@ static inline int cfg80211_color_change_notify(struct net_device *dev)
> bool cfg80211_valid_disable_subchannel_bitmap(u16 *bitmap,
> const struct cfg80211_chan_def *chandef);
>
> +#ifdef CONFIG_ACPI_WBRF
> +void ieee80211_check_wbrf_support(struct wiphy *wiphy);
> +int ieee80211_add_wbrf(struct wiphy *wiphy,
> + struct cfg80211_chan_def *chandef);
> +void ieee80211_remove_wbrf(struct wiphy *wiphy,
> + struct cfg80211_chan_def *chandef);
> +#else
> +static inline void ieee80211_check_wbrf_support(struct wiphy *wiphy) { }
> +static inline int ieee80211_add_wbrf(struct wiphy *wiphy,
> + struct cfg80211_chan_def *chandef) { return 0; }
> +static inline void ieee80211_remove_wbrf(struct wiphy *wiphy,
> + struct cfg80211_chan_def *chandef) { }
> +#endif /* CONFIG_ACPI_WBRF */
Same here, not the right place. This should even be in an internal
mac80211 header (such as net/mac80211/ieee80211_i.h or create a new
net/mac80211/wrbf.h or so if you prefer.)
> --- a/net/mac80211/chan.c
> +++ b/net/mac80211/chan.c
> @@ -668,6 +668,10 @@ static int ieee80211_add_chanctx(struct ieee80211_local *local,
> lockdep_assert_held(&local->mtx);
> lockdep_assert_held(&local->chanctx_mtx);
>
> + err = ieee80211_add_wbrf(local->hw.wiphy, &ctx->conf.def);
> + if (err)
> + return err;
> +
> if (!local->use_chanctx)
> local->hw.conf.radar_enabled = ctx->conf.radar_enabled;
>
> @@ -748,6 +752,8 @@ static void ieee80211_del_chanctx(struct ieee80211_local *local,
> }
>
> ieee80211_recalc_idle(local);
> +
> + ieee80211_remove_wbrf(local->hw.wiphy, &ctx->conf.def);
> }
>
> static void ieee80211_free_chanctx(struct ieee80211_local *local,
>
This is tricky, and quite likely incorrect.
First of all, chandefs can actually _change_, see
_ieee80211_change_chanctx(). You'd probably have to call this add/remove
(or have modify) whenever we call drv_change_chanctx() to change the
width (not if radar/rx chains change).
Secondly, you don't know if the driver will actually use ctx->conf.def,
or ctx->conf.mindef. For client mode that doesn't matter, but for AP
mode if the AP is configured to say 160 MHz, it might actually configure
down to 20 MHz when no stations are connected (or only 20 MHz stations
are). I don't know if you really care about taking that into account, I
also don't know how dynamic this really should be. Stations can connect
and disconnect quickly, so perhaps the WBRF should actually take the
full potential bandwidth into account all the time, in which case taking
ctx->conf.def would be correct.
I'll note that your previous in-driver approach had all the same
problems the way you had implemented it, though I don't know if that
driver ever can use mindef or not.
> +void ieee80211_check_wbrf_support(struct wiphy *wiphy)
> +{
> + struct device *dev = wiphy->dev.parent;
> + struct acpi_device *acpi_dev;
> +
> + acpi_dev = ACPI_COMPANION(dev);
Can this cope with 'dev' being NULL? Just not sure nothing like hwsim or
so always even has a parent. I guess it should, but ...
> +static int chan_width_to_mhz(enum nl80211_chan_width chan_width)
> +{
> + int mhz;
> +
> + switch (chan_width) {
> + case NL80211_CHAN_WIDTH_1:
> + mhz = 1;
> + break;
> + case NL80211_CHAN_WIDTH_2:
> + mhz = 2;
> + break;
> + case NL80211_CHAN_WIDTH_4:
> + mhz = 4;
> + break;
> + case NL80211_CHAN_WIDTH_8:
> + mhz = 8;
> + break;
> + case NL80211_CHAN_WIDTH_16:
> + mhz = 16;
> + break;
> + case NL80211_CHAN_WIDTH_5:
> + mhz = 5;
> + break;
> + case NL80211_CHAN_WIDTH_10:
> + mhz = 10;
> + break;
> + case NL80211_CHAN_WIDTH_20:
> + case NL80211_CHAN_WIDTH_20_NOHT:
> + mhz = 20;
> + break;
> + case NL80211_CHAN_WIDTH_40:
> + mhz = 40;
> + break;
> + case NL80211_CHAN_WIDTH_80P80:
> + case NL80211_CHAN_WIDTH_80:
> + mhz = 80;
> + break;
> + case NL80211_CHAN_WIDTH_160:
> + mhz = 160;
> + break;
> + case NL80211_CHAN_WIDTH_320:
> + mhz = 320;
> + break;
> + default:
> + WARN_ON_ONCE(1);
> + return -1;
> + }
> + return mhz;
This might be more generally useful as a function in cfg80211 that's
exported - hwsim has exactly the same function today, for example.
> +static void get_chan_freq_boundary(u32 center_freq,
> + u32 bandwidth,
> + u64 *start,
> + u64 *end)
> +{
> + bandwidth = MHZ_TO_KHZ(bandwidth);
> + center_freq = MHZ_TO_KHZ(center_freq);
> +
> + *start = center_freq - bandwidth / 2;
> + *end = center_freq + bandwidth / 2;
> +
> + /* Frequency in HZ is expected */
> + *start = KHZ_TO_HZ(*start);
> + *end = KHZ_TO_HZ(*end);
> +}
Similar patterns are probably elsewhere too for this, but I guess we can
always refactor later too.
johannes
next prev parent reply other threads:[~2023-06-09 8:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-09 7:28 [PATCH V2 0/7] Support Wifi RFI interference mitigation feature Evan Quan
2023-06-09 7:28 ` [PATCH V2 1/7] drivers/acpi: Add support for Wifi band RF mitigations Evan Quan
2023-06-09 7:28 ` [PATCH V2 2/7] wifi: mac80211: Add support for ACPI WBRF Evan Quan
2023-06-09 8:21 ` Johannes Berg [this message]
2023-06-12 7:39 ` Quan, Evan
2023-06-09 7:28 ` [PATCH V2 3/7] drm/amd/pm: update driver_if and ppsmc headers for coming wbrf feature Evan Quan
2023-06-09 7:28 ` [PATCH V2 4/7] drm/amd/pm: setup the framework to support Wifi RFI mitigation feature Evan Quan
2023-06-09 7:28 ` [PATCH V2 5/7] drm/amd/pm: add flood detection for wbrf events Evan Quan
2023-06-09 7:28 ` [PATCH V2 6/7] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0 Evan Quan
2023-06-09 7:28 ` [PATCH V2 7/7] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7 Evan Quan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ccbaf80adb305ea59eb1a457460b99dc920bb65d.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=Alexander.Deucher@amd.com \
--cc=Christian.Koenig@amd.com \
--cc=Lijo.Lazar@amd.com \
--cc=Mario.Limonciello@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=evan.quan@amd.com \
--cc=kvalo@kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=nbd@nbd.name \
--cc=rafael@kernel.org \
--cc=ryder.lee@mediatek.com \
--cc=sean.wang@mediatek.com \
--cc=shayne.chen@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®