Silicon Labs acquired Redpine Signals recently. It needs to continue
giving support to the existing REDPINE WIRELESS DRIVER. This patch adds
new Maintainers for it.
Signed-off-by: Ganapathi Kondraju <[email protected]>
---
V2:
- Add proper prefix for patch subject.
- Reorder the maintainers list alphabetically.
- Add a new member to the list.
---
V3:
- Fix sentence formation in the patch subject and description.
---
MAINTAINERS | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea941dc..04a08c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17709,8 +17709,14 @@ S: Maintained
F: drivers/net/wireless/realtek/rtw89/
REDPINE WIRELESS DRIVER
+M: Amol Hanwate <[email protected]>
+M: Ganapathi Kondraju <[email protected]>
+M: Jérôme Pouiller <[email protected]>
+M: Narasimha Anumolu <[email protected]>
+M: Shivanadam Gude <[email protected]>
+M: Srinivas Chappidi <[email protected]>
L: [email protected]
-S: Orphan
+S: Maintained
F: drivers/net/wireless/rsi/
REGISTER MAP ABSTRACTION
--
2.5.5
Ganapathi Kondraju <[email protected]> writes:
> Silicon Labs acquired Redpine Signals recently. It needs to continue
> giving support to the existing REDPINE WIRELESS DRIVER. This patch adds
> new Maintainers for it.
>
> Signed-off-by: Ganapathi Kondraju <[email protected]>
> ---
> V2:
> - Add proper prefix for patch subject.
> - Reorder the maintainers list alphabetically.
> - Add a new member to the list.
> ---
> V3:
> - Fix sentence formation in the patch subject and description.
> ---
>
> MAINTAINERS | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea941dc..04a08c7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17709,8 +17709,14 @@ S: Maintained
> F: drivers/net/wireless/realtek/rtw89/
>
> REDPINE WIRELESS DRIVER
> +M: Amol Hanwate <[email protected]>
> +M: Ganapathi Kondraju <[email protected]>
> +M: Jérôme Pouiller <[email protected]>
> +M: Narasimha Anumolu <[email protected]>
> +M: Shivanadam Gude <[email protected]>
> +M: Srinivas Chappidi <[email protected]>
> L: [email protected]
> -S: Orphan
> +S: Maintained
> F: drivers/net/wireless/rsi/
For me six maintainers is way too much. Just last November I marked this
driver as orphan, I really do not want to add all these people to
MAINTAINERS and never hear from them again.
Ideally I would prefer to have one or two maintainers who would be
actively working with the drivers. And also I would like to see some
proof (read: reviewing patches and providing feedback) that the
maintainers are really parciticiping in upstream before changing the
status.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On 2/27/23 11:28, Kalle Valo wrote:
> Ganapathi Kondraju <[email protected]> writes:
>
>> Silicon Labs acquired Redpine Signals recently. It needs to continue
>> giving support to the existing REDPINE WIRELESS DRIVER. This patch adds
>> new Maintainers for it.
>>
>> Signed-off-by: Ganapathi Kondraju <[email protected]>
>> ---
>> V2:
>> - Add proper prefix for patch subject.
>> - Reorder the maintainers list alphabetically.
>> - Add a new member to the list.
>> ---
>> V3:
>> - Fix sentence formation in the patch subject and description.
>> ---
>>
>> MAINTAINERS | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index ea941dc..04a08c7 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -17709,8 +17709,14 @@ S: Maintained
>> F: drivers/net/wireless/realtek/rtw89/
>>
>> REDPINE WIRELESS DRIVER
>> +M: Amol Hanwate <[email protected]>
>> +M: Ganapathi Kondraju <[email protected]>
>> +M: Jérôme Pouiller <[email protected]>
>> +M: Narasimha Anumolu <[email protected]>
>> +M: Shivanadam Gude <[email protected]>
>> +M: Srinivas Chappidi <[email protected]>
>> L: [email protected]
>> -S: Orphan
>> +S: Maintained
>> F: drivers/net/wireless/rsi/
>
> For me six maintainers is way too much. Just last November I marked this
> driver as orphan, I really do not want to add all these people to
> MAINTAINERS and never hear from them again.
>
> Ideally I would prefer to have one or two maintainers who would be
> actively working with the drivers. And also I would like to see some
> proof (read: reviewing patches and providing feedback) that the
> maintainers are really parciticiping in upstream before changing the
> status.
Has there been any progress on improving this driver maintainership
since this patch ?
On Saturday 27 May 2023 23:12:16 CEST Marek Vasut wrote:
> On 2/27/23 11:28, Kalle Valo wrote:
> > Ganapathi Kondraju <[email protected]> writes:
> >
> >> Silicon Labs acquired Redpine Signals recently. It needs to continue
> >> giving support to the existing REDPINE WIRELESS DRIVER. This patch adds
> >> new Maintainers for it.
> >>
> >> Signed-off-by: Ganapathi Kondraju <[email protected]>
> >> ---
> >> V2:
> >> - Add proper prefix for patch subject.
> >> - Reorder the maintainers list alphabetically.
> >> - Add a new member to the list.
> >> ---
> >> V3:
> >> - Fix sentence formation in the patch subject and description.
> >> ---
> >>
> >> MAINTAINERS | 8 +++++++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index ea941dc..04a08c7 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -17709,8 +17709,14 @@ S: Maintained
> >> F: drivers/net/wireless/realtek/rtw89/
> >>
> >> REDPINE WIRELESS DRIVER
> >> +M: Amol Hanwate <[email protected]>
> >> +M: Ganapathi Kondraju <[email protected]>
> >> +M: J?r?me Pouiller <[email protected]>
> >> +M: Narasimha Anumolu <[email protected]>
> >> +M: Shivanadam Gude <[email protected]>
> >> +M: Srinivas Chappidi <[email protected]>
> >> L: [email protected]
> >> -S: Orphan
> >> +S: Maintained
> >> F: drivers/net/wireless/rsi/
> >
> > For me six maintainers is way too much. Just last November I marked this
> > driver as orphan, I really do not want to add all these people to
> > MAINTAINERS and never hear from them again.
> >
> > Ideally I would prefer to have one or two maintainers who would be
> > actively working with the drivers. And also I would like to see some
> > proof (read: reviewing patches and providing feedback) that the
> > maintainers are really parciticiping in upstream before changing the
> > status.
>
> Has there been any progress on improving this driver maintainership
> since this patch ?
Hello Marek,
The situation is still blurry. There is a willing to maintain this driver
(and several people would like I take care of that). However, the effort
to properly support this driver is still unknown (in fact, I have not yet
started to really look at the situation).
Is this driver blocking some architectural changes? Kalle is talking about
patches to review. Can you point me on them?
Anyway, I would like to come back with a plan by the end of the summer.
--
J?r?me Pouiller
On 6/1/23 12:47, Jérôme Pouiller wrote:
> On Saturday 27 May 2023 23:12:16 CEST Marek Vasut wrote:
>> On 2/27/23 11:28, Kalle Valo wrote:
>>> Ganapathi Kondraju <[email protected]> writes:
>>>
>>>> Silicon Labs acquired Redpine Signals recently. It needs to continue
>>>> giving support to the existing REDPINE WIRELESS DRIVER. This patch adds
>>>> new Maintainers for it.
>>>>
>>>> Signed-off-by: Ganapathi Kondraju <[email protected]>
>>>> ---
>>>> V2:
>>>> - Add proper prefix for patch subject.
>>>> - Reorder the maintainers list alphabetically.
>>>> - Add a new member to the list.
>>>> ---
>>>> V3:
>>>> - Fix sentence formation in the patch subject and description.
>>>> ---
>>>>
>>>> MAINTAINERS | 8 +++++++-
>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index ea941dc..04a08c7 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -17709,8 +17709,14 @@ S: Maintained
>>>> F: drivers/net/wireless/realtek/rtw89/
>>>>
>>>> REDPINE WIRELESS DRIVER
>>>> +M: Amol Hanwate <[email protected]>
>>>> +M: Ganapathi Kondraju <[email protected]>
>>>> +M: Jérôme Pouiller <[email protected]>
>>>> +M: Narasimha Anumolu <[email protected]>
>>>> +M: Shivanadam Gude <[email protected]>
>>>> +M: Srinivas Chappidi <[email protected]>
>>>> L: [email protected]
>>>> -S: Orphan
>>>> +S: Maintained
>>>> F: drivers/net/wireless/rsi/
>>>
>>> For me six maintainers is way too much. Just last November I marked this
>>> driver as orphan, I really do not want to add all these people to
>>> MAINTAINERS and never hear from them again.
>>>
>>> Ideally I would prefer to have one or two maintainers who would be
>>> actively working with the drivers. And also I would like to see some
>>> proof (read: reviewing patches and providing feedback) that the
>>> maintainers are really parciticiping in upstream before changing the
>>> status.
>>
>> Has there been any progress on improving this driver maintainership
>> since this patch ?
>
> Hello Marek,
>
> The situation is still blurry. There is a willing to maintain this driver
> (and several people would like I take care of that). However, the effort
> to properly support this driver is still unknown (in fact, I have not yet
> started to really look at the situation).
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 ?
> Is this driver blocking some architectural changes? Kalle is talking about
> patches to review. Can you point me on them?
You can look up patches at patchwork.kernel.org or lore.kernel.org and
search for "rsi:" or "wifi: rsi:" tags.
This driver is basically unusable and I am tempted to send a patch to
move it to staging and possibly remove it altogether.
WiFi/BT coex is broken, WiFi stability is flaky at best, BT often
crashes the firmware. There are very iffy design decisions in the driver
and other weird defects I keep finding.
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.
> Anyway, I would like to come back with a plan by the end of the summer.
Sure.
In the meantime, since RSI neglected this driver for years, what would
be the suggestion for people who are stuck with the RSI WiFi hardware?
On Mon, 5 Jun 2023 at 11:59, Marek Vasut <[email protected]> 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
Hi Marek,
On Monday 5 June 2023 11:59:41 CEST Marek Vasut wrote:
> On 6/1/23 12:47, J?r?me Pouiller wrote:
> > On Saturday 27 May 2023 23:12:16 CEST Marek Vasut wrote:
> >> On 2/27/23 11:28, Kalle Valo wrote:
> >>> Ganapathi Kondraju <[email protected]> writes:
[...]
> >> Has there been any progress on improving this driver maintainership
> >> since this patch ?
> >
> > Hello Marek,
> >
> > The situation is still blurry. There is a willing to maintain this driver
> > (and several people would like I take care of that). However, the effort
> > to properly support this driver is still unknown (in fact, I have not yet
> > started to really look at the situation).
>
> 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 ?
I think Ganapathi just wanted to give a list of people to keep in Cc in
case there were some discussions about this driver. The status change was
probably not what he wanted to do.
> > Is this driver blocking some architectural changes? Kalle is talking about
> > patches to review. Can you point me on them?
>
> You can look up patches at patchwork.kernel.org or lore.kernel.org and
> search for "rsi:" or "wifi: rsi:" tags.
>
> This driver is basically unusable and I am tempted to send a patch to
> move it to staging and possibly remove it altogether.
>
> WiFi/BT coex is broken, WiFi stability is flaky at best, BT often
> crashes the firmware. There are very iffy design decisions in the driver
> and other weird defects I keep finding.
>
> 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.
You are talking about this driver[1] I assume?
[1]: https://github.com/SiliconLabs/RS911X-nLink-OSD
[...]
> In the meantime, since RSI neglected this driver for years, what would
> be the suggestion for people who are stuck with the RSI WiFi hardware?
Unfortunately, my only suggestion is to use the downstream driver we
mentioned above.
--
J?r?me Pouiller
Hi Jérôme,
On 2023-06-09 08:10, Jérôme Pouiller wrote:
>
> You are talking about this driver[1] I assume?
>
> [1]: https://github.com/SiliconLabs/RS911X-nLink-OSD
>
> [...]
>> In the meantime, since RSI neglected this driver for years, what would
>> be the suggestion for people who are stuck with the RSI WiFi hardware?
>
> Unfortunately, my only suggestion is to use the downstream driver we
> mentioned above.
That driver isn't really a solution as it rarely applies cleanly to
recent kernels.
The lack of proper commit messages also makes the changes opaque.
Cheers
Angus
On 6/9/23 17:46, Angus Ainslie wrote:
> Hi Jérôme,
>
> On 2023-06-09 08:10, Jérôme Pouiller wrote:
>>
>> You are talking about this driver[1] I assume?
>>
>> [1]: https://github.com/SiliconLabs/RS911X-nLink-OSD
>>
>> [...]
>>> In the meantime, since RSI neglected this driver for years, what would
>>> be the suggestion for people who are stuck with the RSI WiFi hardware?
>>
>> Unfortunately, my only suggestion is to use the downstream driver we
>> mentioned above.
>
> That driver isn't really a solution as it rarely applies cleanly to
> recent kernels.
>
> The lack of proper commit messages also makes the changes opaque.
Worse, that repo is just massive dump of unreviewed, unreviewable,
obfuscated goo. That is something I would never dare to put into any
serious deployment.
To make it clear, the aforementioned suggestion is NOT an option.
On 6/9/23 17:10, Jérôme Pouiller wrote:
> Hi Marek,
Hi,
> On Monday 5 June 2023 11:59:41 CEST Marek Vasut wrote:
>> On 6/1/23 12:47, Jérôme Pouiller wrote:
>>> On Saturday 27 May 2023 23:12:16 CEST Marek Vasut wrote:
>>>> On 2/27/23 11:28, Kalle Valo wrote:
>>>>> Ganapathi Kondraju <[email protected]> writes:
> [...]
>>>> Has there been any progress on improving this driver maintainership
>>>> since this patch ?
>>>
>>> Hello Marek,
>>>
>>> The situation is still blurry. There is a willing to maintain this driver
>>> (and several people would like I take care of that). However, the effort
>>> to properly support this driver is still unknown (in fact, I have not yet
>>> started to really look at the situation).
>>
>> 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 ?
>
>
> I think Ganapathi just wanted to give a list of people to keep in Cc in
> case there were some discussions about this driver. The status change was
> probably not what he wanted to do.
Do I understand this correctly that there is no intention to actually
improve the upstream support from RSI side ?
[...]