Received-SPF: pass (google.com: domain of linux-wireless+bounces-3523-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <99977c876429f33d8dbab18d7c3e71590585263b.camel@sipsolutions.net>
Subject: Re: brcmfmac: Unexpected brcmf_set_channel: set chanspec 0xd022
 fail, reason -52 - Part 2
From: Johannes Berg <johannes@sipsolutions.net>
To: Arend Van Spriel <arend.vanspriel@broadcom.com>, Stefan Wahren
	 <wahrenst@gmx.net>, Arend van Spriel <aspriel@gmail.com>, Franky Lin
	 <franky.lin@broadcom.com>, Hante Meuleman <hante.meuleman@broadcom.com>
Cc: linux-wireless@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com, 
 SHA-cyfmac-dev-list@infineon.com, Hector Martin <marcan@marcan.st>, Kalle
 Valo <kvalo@kernel.org>
Date: Tue, 13 Feb 2024 11:15:09 +0100
In-Reply-To: <18d1388fbe8.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
References: <d9c9336a-6314-4de9-aead-8b865bb30f05@gmx.net>
	 <18bbf6acf10.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
	 <cb07408d-af14-4b01-bd96-15c480989643@gmx.net>
	 <5c462fac-b27d-41c0-a62c-a8951bf445d2@gmx.net>
	 <d8f7dc94-40f5-4544-9693-01d7cbc6fefb@broadcom.com>
	 <ca0fd1c5-380d-4756-a33a-cb6c84014ce4@gmx.net>
	 <89d3f34a-3427-4871-971c-d960a16918ac@broadcom.com>
	 <004dabc3-c345-4d90-9348-5caa9b1f3849@gmx.net>
	 <c3996f70-bb2a-4d26-a7e9-a1b062fa0474@broadcom.com>
	 <0e5eba2f-e524-4f0d-8217-2770c57ad5ed@gmx.net>
	 <18c8d7da558.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
	 <f3af378f-fae4-4a98-a5b1-24173d17b64e@gmx.net>
	 <18c921b1690.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
	 <18c9224abb0.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
	 <d90cc093-e3fc-4af4-9a4a-5f4bd9a7cb1f@gmx.net>
	 <19541618e400c95a448f7e8c79590c01df214782.camel@sipsolutions.net>
	 <18d1388fbe8.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.3 (3.50.3-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Tue, 2024-01-16 at 19:29 +0100, Arend Van Spriel wrote:
> > >=20
> > > I modified brcmf_construct_chaninfo() to store the
> > > IEEE80211_CHAN_DISABLED flag within orig_flags in case the flags had =
it.
> > > This avoid the issue. Not sure this is the proper solution.
> >=20
> > orig_flags are from when the wiphy is registered - does the driver only
> > set up proper flags after that?
>=20
> Long time ago we discussed about this. So brcmfmac provides a superset of=
=20
> channels during wiphy_register() and none of them are disabled as they=
=20
> could never be enabled. After that the driver may disable a subset as it=
=20
> syncs with the device. I think we used strict custom reg flag, but that=
=20
> seems to have gone. Could that have the result Stefan is observing?
>=20

All this confuses me way more than it should, I guess.

We do still have REGULATORY_STRICT_REG, no? And that sets even
orig_flags:

        if (lr->initiator =3D=3D NL80211_REGDOM_SET_BY_DRIVER &&
            request_wiphy && request_wiphy =3D=3D wiphy &&
            request_wiphy->regulatory_flags & REGULATORY_STRICT_REG) {
                /*
                 * This guarantees the driver's requested regulatory domain
                 * will always be used as a base for further regulatory
                 * settings
                 */
                chan->flags =3D chan->orig_flags =3D
                        map_regdom_flags(reg_rule->flags) | bw_flags;


But brcmf_construct_chaninfo() looks a bit more like it really should be
setting a custom regulatory with all the channels listed, a bit like
what iwlwifi/mvm does, with REGULATORY_WIPHY_SELF_MANAGED?

Maybe we should start from the beginning: what does this actually
_want_?

johannes