[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whDLKZZEuxU_jEhZRdeWjXAkL8=J_JRk2Ar6wp9UK3h2w@mail.gmail.com>
Date: Tue, 19 Dec 2023 17:44:18 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Hector Martin <marcan@...can.st>
Cc: Kalle Valo <kvalo@...nel.org>, Daniel Berlin <dberlin@...rlin.org>,
Arend van Spriel <arend.vanspriel@...adcom.com>, Arend van Spriel <aspriel@...il.com>,
Franky Lin <franky.lin@...adcom.com>, Hante Meuleman <hante.meuleman@...adcom.com>,
SHA-cyfmac-dev-list@...ineon.com, asahi@...ts.linux.dev,
brcm80211-dev-list.pdl@...adcom.com, linux-kernel@...r.kernel.org,
linux-wireless@...r.kernel.org, David Airlie <airlied@...hat.com>,
Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password
On Tue, 19 Dec 2023 at 16:06, Hector Martin <marcan@...can.st> wrote:
>
> On 2023/12/19 23:42, Kalle Valo wrote:
> >
> > Why is it that every patch Hector submits seems to end up with flame
> > wars?
Well, I do think some of it is Hector's personality and forceful
approaches, but I do think part of it is also the area in question.
Because I do agree with Hector that..
> Just recently a patch was posted to remove the Infineon list from
> MAINTAINERS because that company cares so little they have literally
> stopped accepting emails from us. Meanwhile they are telling their
> customers that they do not recommend upstream brcmfmac and they should
> use their downstream driver [1].
Unquestionably broadcom is not helping maintain things, and I think it
should matter.
As Hector says, they point to their random driver dumps on their site
that you can't even download unless you are a "Broadcom community
member" or whatever, and hey - any company that works that way should
be seen as pretty much hostile to any actual maintenance and proper
development.
If Daniel and Hector are responsive to actual problem reports for the
changes they cause, I do think that should count a lot.
I don't think Cypress support should necessarily be removed (or marked
broken), but if the sae_password code already doesn't work, _that_
part certainly shouldn't hold things up?
Put another way: if we effectively don't have a driver maintainer that
can test things, and somebody is willing to step up, shouldn't we take
that person up on it?
Linus
Powered by blists - more mailing lists