netdev - Re: [PATCH 1/1] wifi: nl80211: Add support for plumbing SAE groups to driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0da40ae1-c033-4089-a64e-27d16bce7ab6@quicinc.com>
Date: Wed, 14 Feb 2024 08:57:39 -0800
From: Jeff Johnson <quic_jjohnson@...cinc.com>
To: Johannes Berg <johannes@...solutions.net>,
        Jakub Kicinski
	<kuba@...nel.org>
CC: Kalle Valo <kvalo@...nel.org>,
        Vinayak Yadawad
	<vinayak.yadawad@...adcom.com>,
        <linux-wireless@...r.kernel.org>, <jithu.jance@...adcom.com>,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/1] wifi: nl80211: Add support for plumbing SAE groups to
 driver

On 2/14/2024 2:27 AM, Johannes Berg wrote:
> At which point, yeah, I'm putting my foot down and saying this has to
> stop. I really don't (**) care about Broadcom doing their own vendor-
> specific APIs if there's zero chance the things they're needed for will
> ever land upstream anyway.
> 
> (**) No longer. I used to think that being more open about this would
> encourage folks to start a journey of contributing more upstream, but
> clearly that hasn't worked out.
> 
> Now this is why I used to be more open: I will also most definitely not
> accept all the vendor APIs upstream if someone later decides they do
> want an upstream driver, and then push all the vendor stuff on grounds
> that "it's used now and we have to support it" ... We don't, at least
> not upstream, what you sell to your customers really isn't our problem.
> 
> (And to be honest, if customers cared, we'd not be in this position)

I feel a need to respond since, as part of the thread, Qualcomm was also
mentioned, and rightfully so. In addition to our in-tree ath drivers we
have multiple out-of-tree wifi drivers, some for mobile-based products
and some for infrastructure-based products. And we have also contributed
patches in the past that were only in support of our out-of-tree drivers.

There are good reasons these out-of-tree drivers exist, but there is
also a movement, at least for the Qualcomm infrastructure products, to
transition to an upstream driver, in part due to customer requests. So
it is disconcerting that you are talking about inserting barriers to
converting to an upstream driver. Converting from an out-of-tree driver
to an upstream driver involves significance NRE cost with little to no
revenue gain, but that is something Qualcomm is willing to do for the
driver. But we need our userspace interfaces to survive since both
Qualcomm and our customers have years of work invested in the existing
userspace interfaces and applications. The customers who want an
upstream driver do not want to be forced to rewrite their applications
to support it.

In the kernel we have a clear mantra to not break userspace. That should
hopefully hold true when converting from an out-of-tree driver to an
upstream one.

/jeff