Received-SPF: pass (google.com: domain of linux-wireless+bounces-7969-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20231222032123.1036277-1-yu-hao.lin@nxp.com> <20231222032123.1036277-2-yu-hao.lin@nxp.com>
 <20240227175306.GB11034@francesco-nb> <PA4PR04MB96383C684AAA40C14DDB4B79D15F2@PA4PR04MB9638.eurprd04.prod.outlook.com>
 <PA4PR04MB9638983EBD1DB4D3E8FB5474D1222@PA4PR04MB9638.eurprd04.prod.outlook.com>
In-Reply-To: <PA4PR04MB9638983EBD1DB4D3E8FB5474D1222@PA4PR04MB9638.eurprd04.prod.outlook.com>
From: Brian Norris <briannorris@chromium.org>
Date: Wed, 22 May 2024 17:51:00 -0700
Message-ID: <CA+ASDXM1PEMRyxRpBryJ7G6e7yzG8Ku+g2_qpHN3g5djFpAWkw@mail.gmail.com>
Subject: Re: [EXT] Re: [PATCH v8 1/2] wifi: mwifiex: add host mlme for client mode
To: David Lin <yu-hao.lin@nxp.com>
Cc: Francesco Dolcini <francesco@dolcini.it>, 
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "kvalo@kernel.org" <kvalo@kernel.org>, 
	Pete Hsieh <tsung-hsien.hsieh@nxp.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Necromancing some v8 comments here, since I realized I had the same
question on my last pass at v10:

On Mon, Mar 4, 2024 at 11:26=E2=80=AFPM David Lin <yu-hao.lin@nxp.com> wrot=
e:
> > From: David Lin
> > Sent: Thursday, February 29, 2024 11:53 AM
> >
> > > From: Francesco Dolcini <francesco@dolcini.it>
> > > Sent: Wednesday, February 28, 2024 1:53 AM
> > >
> > > On Fri, Dec 22, 2023 at 11:21:22AM +0800, David Lin wrote:
> > > > +static int
> > > > +mwifiex_cfg80211_probe_client(struct wiphy *wiphy,
> > > > +                           struct net_device *dev, const u8 *peer,
> > > > +                           u64 *cookie) {
> > > > +     return -1;
> > >
> > > See my following comment on this

> > > > +             mwifiex_cfg80211_ops.probe_client =3D
> > > > +                     mwifiex_cfg80211_probe_client;
> > >
> > > Can you omit this one? You should get `-EOPNOTSUPP` for free with
> > > probe_client set to NULL. Am I wrong?
> > >
> >
> > Yes. You are right. Remove in patch v9.
>
> This function must be hooked, otherwise AP mode can't work. I will hook t=
his function as before but return -EOPNOTSUPP instead.

You mean, hostapd doesn't like it? That seems like hostapd's problem,
because the actual effect is the same -- the feature isn't supported,
and will always throw an error. The kernel is lying if it adds
NL80211_CMD_PROBE_CLIENT into the wiphy command feature list.

Can you point at what specifically goes wrong in hostapd, and see if
we can find a way to fix it in the right place -- in hostapd? I don't
really hack on hostapd much, but it looks like it comes down to the
drv->use_monitor flag? Notably, that has a comment:

# src/drivers/driver_nl80211_capa.c ~ line 1424
/*
 * If poll command and tx status are supported, mac80211 is new enough
  * to have everything we need to not need monitor interfaces.
 */

So, you're actively subverting something that hostapd is trying to
learn about mac80211. That sounds double wrong.

At the very least, if we're going to include hacks like this in the
kernel, we should probably have a comment in there, so that future
readers don't keep stubbing their toes on the same question. Or worse,
removing the seemingly useless function and breaking hostapd. But
ideally, we'd drop this hack and fix hostapd.

Brian