On Mon, 5 Jun 2023 at 11:59, Marek Vasut <marex@xxxxxxx> wrote: > I have to admit, the aforementioned paragraph is quite disturbing, > considering that this patch adds 6 maintainers, is already in V3, and so > far it is not even clear to silabs how much effort it would be to > maintain driver for their own hardware, worse, silabs didn't even check. > What is the point of adding those maintainers then ? > Totally agree. IMHO (very humble, I'm not a maintainer, just a guy who has submitted and had merged a few patches to this driver) people shouldn't be added to MAINTAINERS *just* because they work for the company making the hardware and have been assigned to do driver work for it. Rather I think they should demonstrate, over a couple of development cycles, their ability and availability, preferably both submitting patches themselves and reviewing other patches. (This is not in any way a judgement of the proposed maintainers as I have seen nothing from them). And starting with one or two people doing that part time would be a way for Silabs to get a better idea of the effort needed. > This driver is basically unusable and I am tempted to send a patch to > move it to staging and possibly remove it altogether. > I do think this is a little harsh though. It certainly still has bugs but I think it is usable, at least for some use cases. > > Multiple people tried to fix at least a couple of basic problems, so the > driver can be used at all, but there is no documentation and getting > support regarding anything from RSI is a total waste of time. Sadly, the > only reference material I could find and work with is some downstream > goo, which is released in enormous single-commit code dumps with +/- > thousands of lines of changes and with zero explanation what each change > means. > Yes absolutely and this is a huge problem for this type of driver. For simpler hardware (like most I2C, SPI chips) anyone who has reasonable knowledge of the Linux kernel and the hardware datasheet can write a driver. Here the hardware datasheet isn't enough you really need the firmware interface documentation (which isn't available publicly) because the actual *hardware* isn't that important from a driver perspective. The driver is an interface between the Kernel 802.11 stack and the *firmware*. Actually I would rather have public interface documentation than official maintainers working for the vendor (though both would be great). Martin
