Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ee24c4eda8d389ac7197b6296944e168ccc6b602.camel@sipsolutions.net>
Subject: Re: brcmfmac: Unexpected cfg80211_set_channel: set chanspec ...
 fail, reason -52
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Arend van Spriel <arend.vanspriel@broadcom.com>,
        Stefan Wahren <stefan.wahren@i2se.com>,
        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
Date:   Tue, 03 Jan 2023 08:07:41 +0100
In-Reply-To: <1f428e2b-f73f-64ff-02d3-eefbcd11db89@broadcom.com>
References: <2635fd4f-dfa0-1d87-058b-e455cee96750@i2se.com>
         <1f428e2b-f73f-64ff-02d3-eefbcd11db89@broadcom.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) 
MIME-Version: 1.0
Precedence: bulk

Hi,


> > [=C2=A0 104.897615] brcmfmac: cfg80211_set_channel: set chanspec 0x100e=
 fail,=20
> > reason -52

[...]

>=20
> > All of these 10 errors are repeated every 60 sec.
>=20
> Catching up after the holidays ;-) Above chanspec values are invalid.=20
> 0x100e =3D channel 14/bw 20MHz. The 'iw list' output shows all these=20
> channels are disabled. So who/what is trying to set these channels.=20
> Scanning sets the channel in firmware. Is this initiated from hostapd?=
=20

Yeah, what userspace is running here? Looks like cfg80211_set_channel()
is only used for survey?

Couple of observations on the side:
 * might be nice to have some "brcm" indication in that name :P
 * dump_survey should just dump data, not actually implement the data
   collection, I think?


> Maybe trying ACS?=C2=A0
>=20

Seems it must be something like that.

> As these are marked as disabled user-space should not=20
> use them. What I don't understand is why these pass the cfg80211 layer=
=20
> so adding Johannes here.
>=20

Well that goes back to my earlier observation above: dump_survey()
should just dump all *available* data, not actually try to *collect*
data. So if userspace requests data for a channel that's disabled,
that's actually OK, but you shouldn't _have_ any data for that channel
since it's disabled. Also nl80211 won't send the data out if it exists,
but there's no check to see if asking the driver makes sense since if
it's a channel that exists, it should be valid to ask the driver if it
has data - it just shouldn't have any.

The way it works in mac80211 is that survey data is collected during
scan, I think?

johannes