Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Message-ID: <ac1f3d9b81dbca244bdc8262e9d2ee44220f78c1.camel@sipsolutions.net>
Subject: Re: removing OCB/WAVE/802.11p
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Jeff Johnson <quic_jjohnson@quicinc.com>,
        linux-wireless@vger.kernel.org
Cc:     Rostislav Lisovy <lisovy@gmail.com>, chrisshen@skku.edu,
        bienaime@skku.edu, pauljeong@skku.edu,
        carloaugusto.grazia@unimore.it
Date:   Tue, 10 Oct 2023 16:47:28 +0200
In-Reply-To: <90fcfe15-de1b-4371-a316-574ac7a03eda@quicinc.com>
References: <ec69aa2722b07bffd6184d687861cc7e5ae9c1ef.camel@sipsolutions.net>
         <90fcfe15-de1b-4371-a316-574ac7a03eda@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Fri, 2023-10-06 at 16:15 -0700, Jeff Johnson wrote:
> On 9/28/2023 8:38 AM, Johannes Berg wrote:
> > Hi,
> >=20
> > CC'ing lots of people who touched or used this in the past in hopes of
> > triggering some reaction somewhere ...
> >=20
> > I'm trying to do some cleanup in IBSS and following that some other
> > cleanups wrt. station allocation etc., but OCB pretty much copied the
> > IBSS code in this area, and I don't know how to use it, how to test it,
> > who's using it, if anyone is actually maintaining it, etc.
> >=20
> > Also, it only ever got implemented for ath9k, so I'm guessing it's not
> > getting any traction in new products/devices.
> >=20
> > So I'm probably going to remove it.
> >=20
> > Any takers to help maintain it instead?
>=20
> Do you have an estimate on the footprint of this logic? Do you have a=20
> proposed patch?

Neither. It's actually not really big, and I was just putting out
feelers.

The particular reason was that we had a patch a long time back:
https://patchwork.kernel.org/project/linux-wireless/patch/20180216161301.29=
339-3-luca@coelho.fi/

which was rightfully rejected. But I was looking at it recently again,
thinking I should revive it (and I may still), and then I thought if I
do that, I can remove the gfp_t argument to sta_info_alloc(), but OCB
identically copied this code ...

Now, I suppose OCB doesn't have much in the way of station
discovery/connection process (like auth) since that's kind of the
_point_, but maybe doing something else would work here?

> In addition to ath9k I know there is out-of-tree usage of this=20
> functionality, and I'm trying to see if I can find someone to maintain=
=20
> this. But how would that actually work?

Well for starters it'd be nice to actually have some tests with hwsim, I
guess, and someone who knows how to use it, how to test things if there
are relevant changes, etc.

johannes