Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <1675433281-6132-1-git-send-email-ganapathi.kondraju@silabs.com>
 <87lekj1jx2.fsf@kernel.org> <8eb3f1fc-0dee-3e5d-b309-e62349820be8@denx.de>
 <112376890.nniJfEyVGO@pc-42> <dd9a86af-e41a-3450-5e52-6473561a3e18@denx.de>
In-Reply-To: <dd9a86af-e41a-3450-5e52-6473561a3e18@denx.de>
Reply-To: martin.fuzzey@flowbird.group
From:   "Fuzzey, Martin" <martin.fuzzey@flowbird.group>
Date:   Mon, 5 Jun 2023 14:00:00 +0200
Message-ID: <CANh8Qzzzg775T87UvoTywj-ByuP4=_9KpHkCgP4TqZW5CBY=pg@mail.gmail.com>
Subject: Re: [PATCH v3] MAINTAINERS: Add new maintainers to Redpine driver
To:     Marek Vasut <marex@denx.de>
Cc:     =?UTF-8?B?SsOpcsO0bWUgUG91aWxsZXI=?= <jerome.pouiller@silabs.com>,
        Kalle Valo <kvalo@kernel.org>,
        Ganapathi Kondraju <ganapathi.kondraju@silabs.com>,
        linux-wireless@vger.kernel.org,
        Amitkumar Karwar <amitkarwar@gmail.com>,
        Amol Hanwate <amol.hanwate@silabs.com>,
        Angus Ainslie <angus@akkea.ca>,
        Jakub Kicinski <kuba@kernel.org>,
        Johannes Berg <johannes@sipsolutions.net>,
        Martin Kepplinger <martink@posteo.de>,
        Narasimha Anumolu <narasimha.anumolu@silabs.com>,
        Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>,
        Shivanadam Gude <shivanadam.gude@silabs.com>,
        Siva Rebbagondla <siva8118@gmail.com>,
        Srinivas Chappidi <srinivas.chappidi@silabs.com>,
        netdev@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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