[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+ASDXMSyVbPrTz4Vag-4_yi7080bBtkwBgOLFYOTmwb=NDvNQ@mail.gmail.com>
Date: Fri, 21 Jun 2024 12:16:50 -0700
From: Brian Norris <briannorris@...omium.org>
To: Sascha Hauer <s.hauer@...gutronix.de>
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
Francesco Dolcini <francesco@...cini.it>, Kalle Valo <kvalo@...nel.org>, David Lin <yu-hao.lin@....com>
Subject: Re: [PATCH] wifi: mwifiex: increase max_num_akm_suites
On Fri, Jun 21, 2024 at 1:48 AM Sascha Hauer <s.hauer@...gutronix.de> wrote:
> On Thu, Jun 20, 2024 at 11:05:24AM -0700, Brian Norris wrote:
> > Possibly dumb question: what's unique about mwifiex here? Everything you
> > describe above sounds applicable to all drivers, IIUC, and I don't see
> > any other driver that touches max_num_akm_suites.
>
> I asked myself the same question and I don't have an answer to it. To me
> it looks like the number of akm suites is limited by the akm_suites array
> size which is CFG80211_MAX_NUM_AKM_SUITES which is 10 and that could be
> used for all drivers.
Yeah, I can't figure out a great answer either. Although I did find that
(1) it's theoretically possible some driver could be confused by
larger indices (which should be easy enough to audit...) and
(2) there's at least 1 borderline example, in wilc1000 --
wilc_join_bss_param is only prepared to handle up to 3 akm_suites. But
it also has a (magic number) bound of 3, so it will silently drop the
4th, 5th, ... suite.
So maybe it's a reasonable start to have drivers modify this as
needed. If we later figure out all drivers should be OK with an
increased limit, we can unify that later.
> max_num_akm_suites is introduced to be driver specific and so I changed
> it only for the driver I am currently interested in.
Sure. Seems fine to me.
Acked-by: Brian Norris <briannorris@...omium.org>
Powered by blists - more mailing lists