netdev - Re: [PATCH v3] MAINTAINERS: Add new maintainers to Redpine 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]

Date: Mon, 5 Jun 2023 14:00:00 +0200
From: "Fuzzey, Martin" <martin.fuzzey@...wbird.group>
To: Marek Vasut <marex@...x.de>
Cc: Jérôme Pouiller <jerome.pouiller@...abs.com>, 
	Kalle Valo <kvalo@...nel.org>, Ganapathi Kondraju <ganapathi.kondraju@...abs.com>, 
	linux-wireless@...r.kernel.org, Amitkumar Karwar <amitkarwar@...il.com>, 
	Amol Hanwate <amol.hanwate@...abs.com>, Angus Ainslie <angus@...ea.ca>, 
	Jakub Kicinski <kuba@...nel.org>, Johannes Berg <johannes@...solutions.net>, 
	Martin Kepplinger <martink@...teo.de>, Narasimha Anumolu <narasimha.anumolu@...abs.com>, 
	Sebastian Krzyszkowiak <sebastian.krzyszkowiak@...i.sm>, 
	Shivanadam Gude <shivanadam.gude@...abs.com>, Siva Rebbagondla <siva8118@...il.com>, 
	Srinivas Chappidi <srinivas.chappidi@...abs.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v3] MAINTAINERS: Add new maintainers to Redpine driver

On Mon, 5 Jun 2023 at 11:59, Marek Vasut <marex@...x.de> 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