Linux wireless drivers development
 help / color / mirror / Atom feed
From: Alessio Ferri <alessio.ferri@mythread.it>
To: Rosen Penev <rosenp@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	"open list:B43 WIRELESS DRIVER" <linux-wireless@vger.kernel.org>,
	"John W. Linville" <linville@tuxdriver.com>,
	"open list:B43 WIRELESS DRIVER" <b43-dev@lists.infradead.org>
Subject: Re: [PATCH wireless] wifi: b43: back off the N-PHY TX power per rate
Date: Thu, 15 Oct 2026 22:11:10 +0200	[thread overview]
Message-ID: <20261015221110.000078b3@mythread.it> (raw)
In-Reply-To: <20261015175928.3558057-1-rosenp@gmail.com>

Il giorno Thu, 15 Oct 2026 10:59:28 -0700
Rosen Penev <rosenp@gmail.com> ha scritto:

> On N-PHY rev 3+ the hardware TX power control aims at the highest
> per-rate target, and an adjusted power table backs each rate group off
> from it. b43 fills that table from nphy->tx_power_offset[], but never
> sets the offsets, so they stay zero and every rate is sent at the
> power allowed for CCK.
> 
> The SPROM power offsets exist to avoid this: on boards with external
> PAs, OFDM and MCS rates have to be sent a few dB lower than CCK to
> keep the PA linear. Sent at full power, 16-QAM and 64-QAM frames are
> too distorted to decode. On an ASUS RT-N16 (BCM4718, N-PHY rev 5,
> radio 2056, ofdm2gpo 0x66666666) the router could only send at 6-18
> Mbit/s and MCS 0-2, even at -50 dBm, and 24 Mbit/s and up or MCS 3 and
> up delivered nothing.
> 
> Set the offsets from the per-rate targets b43 already computes from
> the SPROM, as brcmsmac does, before the table is built.
> 
> With this, the RT-N16 sends at 54 Mbit/s, and at MCS 7 with HT
> enabled, and TCP from the router to a client goes from 9 to 17-18
> Mbit/s.
> 
> Fixes: 8615eb2870f1 ("b43: N-PHY: support setting custom TX power")
> Assisted-by: LLM
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>  drivers/net/wireless/broadcom/b43/phy_n.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
> b/drivers/net/wireless/broadcom/b43/phy_n.c index
> 22359bd9db47..c9b2b7496983 100644 ---
> a/drivers/net/wireless/broadcom/b43/phy_n.c +++
> b/drivers/net/wireless/broadcom/b43/phy_n.c @@ -5834,6 +5834,7 @@
> static enum b43_txpwr_result b43_nphy_op_recalc_txpower(struct
> b43_wldev *dev, struct ieee80211_channel *channel =
> dev->wl->hw->conf.chandef.chan; struct b43_ppr *ppr =
> &nphy->tx_pwr_max_ppr; u8 max; /* qdBm */
> +	int i;
>  
>  	if (nphy->tx_pwr_last_recalc_freq == channel->center_freq &&
>  	    nphy->tx_pwr_last_recalc_limit == phy->desired_txpower)
> @@ -5868,6 +5869,16 @@ static enum b43_txpwr_result
> b43_nphy_op_recalc_txpower(struct b43_wldev *dev, /* Make sure we
> didn't go too low */ b43_ppr_apply_min(dev, ppr, INT_TO_Q52(8));
>  
> +	/*
> +	 * The hardware power control aims at the highest per-rate
> target.
> +	 * The adjusted power table backs other rates off from it,
> so that
> +	 * e.g. 64-QAM isn't sent at the power allowed for CCK.
> +	 */
> +	max = b43_ppr_get_max(dev, ppr);
> +	memset(nphy->tx_power_offset, 0,
> sizeof(nphy->tx_power_offset));
> +	for (i = 0; i < B43_PPR_RATES_NUM; i++)
> +		nphy->tx_power_offset[i] = max - ppr->__all_rates[i];
> +
>  	/* Apply */
>  	b43_mac_suspend(dev);
>  	b43_nphy_tx_power_ctl_setup(dev);

I'm not the maintainer, and i also have the same exact patch in my repo 
https://github.com/aleferri/b43-6362-wip/tree/main/patches/mainline, so 
i'm all for it, but isn't the ppr currently populated with 2Ghz sprom
params for all bands?

Alessio

  reply	other threads:[~2026-10-15 20:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 17:59 [PATCH wireless] wifi: b43: back off the N-PHY TX power per rate Rosen Penev
2026-10-15 20:11 ` Alessio Ferri [this message]
2026-10-15 21:50   ` Rosen Penev

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=20261015221110.000078b3@mythread.it \
    --to=alessio.ferri@mythread.it \
    --cc=b43-dev@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=rosenp@gmail.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