Hi Johannes, Kalle, >I'm sure it's for an out-of-tree driver. Yes, it's for an out of tree driver. > I've said this before: I can't maintain something well that I cannot see (and possibly change) the user(s) of. >I recall the rule was that nl80211 API changes should also have at least one driver implementing it. Got your point. The recent efforts for patch submission was to align more with the nl80211/cfg80211 interface and remove vendor patches/interfaces. I wasn’t aware of this upstream requirement, but I do get your point that the requirement is to have at least one driver that exercises these interfaces for code maintainability/understanding the why interface changes are needed. >A practical tip I can give to Broadcom is to remind that you have a great engineer with upstream knowledge: Arend >And thenever you add a new feature to the stack, add support to brcm80211 driver at the same time. This help Broadcom to get the feature you need to upstream and the upstream community would have a better Broadcom driver. Thanks for the inputs. Let me sync up internally and get back. Thanks, On Tue, Feb 13, 2024 at 6:20 PM Kalle Valo <kvalo@xxxxxxxxxx> wrote: > > Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > > > On Tue, 2024-02-13 at 13:19 +0100, Arend van Spriel wrote: > > > >> On 2/13/2024 12:45 PM, Johannes Berg wrote: > >> > On Tue, 2024-02-13 at 12:13 +0100, Arend van Spriel wrote: > >> > > > >> > > I recall the rule was that nl80211 API changes > >> > > should also have at least one driver implementing it. Guess we let that > >> > > slip a couple of times. I fully agree enforcing this. > >> > > >> > Well, enforcing it strictly never really worked all that well in > >> > practice, since you don't necessarily want to have a complex driver > >> > implementation while hashing out the API, and the API fundamentally has > >> > to come first. > >> > > >> > So in a sense it comes down to trust, and that people will actually > >> > follow up with implementations. And yeah, plans can change and you end > >> > up not really supporting everything that was defined ... that's life, I > >> > guess. > >> > > >> > But the mode here seems to be that there's not even any _intent_ to do > >> > that? > >> > > >> > I guess we could hash out the API, review the patches, and then _not_ > >> > apply them until a driver is ready? So the first round of reviews would > >> > still come with API only, but once that settles we don't actually merge > >> > it immediately, unlike normally where we merge a patch we've reviewed? > >> > And then if whoever did it lost interest, we already have a reviewed > >> > version for anyone else who might need it? > >> > >> Sounds like a plan. Maybe they can get a separate state in patchwork and > >> let them sit there for grabs. > > > > I guess I can leave them open as 'under review' or something? Not sure > > we can add other states. > > I belong to the church of 'Clean Inbox' so I use 'Deferred' state for > stuff I can't work on right now. Though I know a lot of people don't > like it because deferred patches are not shown in the default patchwok > view. > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
