Re: [PATCH rtw-next v8 5/7] wifi: rtw88: 8723b: add the RTL8723B chip driver
From: Luka Gejak
Date: Wed Oct 14 2026 - 09:20:10 EST
October 14, 2026 at 3:04 PM, "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Oct 12, 2026 at 11:31:57AM +0000, Luka Gejak wrote:
>
> >
> > October 10, 2026 at 12:18 PM, "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> >
> >
> > On Wed, Oct 07, 2026 at 10:35:25AM +0000, Luka Gejak wrote:
> >
> > >
> > [...]
> > >
> > > Hi Greg,
> > >
> > > I have sent the patch, and I think you are going to like this
> > > number: 66186 deletions
> > >
> > Very happy :)
> >
> > >
> > > Not sure what people are going to use to learn though. It seems to
> > > me everyone is repeating the same patches.
> > >
> > Yeah, we need to dig up some more out-of-tree kernel code to add it for
> > them to churn on. But really, this is a good thing, it's nice to see
> > real support for this hardware finally.
> >
> > Hi Greg,
> >
> > As both of you and I know there are not many young people in the
> > kernel community and the steep learning curve is a big reason for that.
> >
> Really? We average about 200-250 new contributors every kernel release
> until recently when it's shot up to 600-700 if not more. So we don't
> seem to have a lack of new contributors for some reason...
You misunderstood me, I said young people. I asked multiple young
programmers who were interested in linux why aren't they contributing
to the linux kernel and they said that it was hard for them to learn
because many issues they find in staging(which I believe you recently
called learning ground) have already been submitted or nacked.
>
> >
> > I was not sure whether you were joking or not about the comment
> > above so I decided to find that appropriate replacement for staging
> > rtl8723bs. After searching I found this interesting xradio driver,
> > which is a mac80211 based driver for some orange pies and other devices.
> > It is around 18,000 lines of code and upon check it out I fixed bunch
> > of security issues per se and lockups that caused kernel to hang and it
> > is decently stable. I'm not gonna claim some extreme stability but it
> > is at least usable and it has many coding standard issues. It is a good
> > candidate because newcomers would be learning the modern architecture
> > and on top of it there is a lot of janitor work so people can learn
> > the workflow and etc. Link is [1] so you can see for yourself and tell
> > me what you think about it.
> >
> If you think it is worth adding, sure, but normally we need someone to
> actually care about it getting into the tree (i.e. real users
> somewhere).
As far as I know it is decently used piece of hardware so it should
have users.
>Also look at the bottom of the readme, shouldn't the
> existing in-kernel driver just be tweaked for this hardware instead?
>
Possibility, however it would require someone with sufficient knowledge
to tweek it, which who knows if it is as simple as readme says. And I
didn't mean it as a upstream ready driver, but rather a place where
new people can learn as I previously said.
Best regards,
Luka Gejak