From: Kalle Valo <kvalo@codeaurora.org>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dan Carpenter <dan.carpenter@oracle.com>,
Ping-Ke Shih <pkshih@realtek.com>,
Yan-Hsuan Chuang <yhchuang@realtek.com>,
Johannes Berg <johannes.berg@intel.com>,
Souptick Joarder <jrdr.linux@gmail.com>,
devel@driverdev.osuosl.org, linux-wireless@vger.kernel.org,
kernel-janitors@vger.kernel.org
Subject: Re: Two rtlwifi drivers?
Date: Thu, 12 Oct 2017 11:57:26 +0300 [thread overview]
Message-ID: <87d15spwuh.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <18efa551-f8fe-6bd2-71b9-69c867467db3@lwfinger.net> (Larry Finger's message of "Wed, 11 Oct 2017 09:19:57 -0500")
Larry Finger <Larry.Finger@lwfinger.net> writes:
> On 10/11/2017 08:13 AM, Greg Kroah-Hartman wrote:
>
>> On Wed, Oct 11, 2017 at 12:06:00PM +0300, Kalle Valo wrote:
>> I think it's horrid too. But, if no one is able to do the real work
>> here, we hurt users who just need to use their hardware to get things
>> done.
>>
>> And it seems like the company isn't willing to do the real work, so
>> dumping this in staging is the best we can do at the moment.
>>
>> However, if this causes you problems, that's not good at all either.
>> Getting "real" support for this hardware is key, and hopefully can
>> happen somehow. But fixing up the staging driver is almost never the
>> way to do it, as you know :)
>>
>> So what to do? Any ideas? What makes your life easier? You can just
>> ignore the staging tree, as it should not affect your portion of the
>> kernel at all, right?
>
> Greg and Kalle,
>
> We can all agree that this situation is bad; however, several of the
> points made in your E-mails need to be addressed.
>
> First of all, I am not an employee of Realtek, and I have no knowledge
> of the internals of any of their chips. I have never signed a
> non-disclosure agreement, and the only thing that I have received from
> them are sample chips for testing. My main interest is in helping the
> user experience.
And you are doing a great job at that! My only gripe here is forking the
driver.
> As there are a number of users with the new RTL8822BE device, that
> meant getting an in-kernel driver to them as soon as possible. As
> stated earlier, adding this particular device to the rtlwifi family
> involved roughly 120K lines of new code. Given our recent experience
> in getting code accepted into the wireless tree meant that this
> additional code would not have been accepted for many months. For that
> reason, we chose the staging route. It is important that we get this
> right as Realtek tells me that there will be two additional new
> drivers in the coming 6 months.
If there are new drivers coming in 6 months they should submitting
patches already now, this is my main point. Don't work in a waterfall
model, release early and release often.
> As to the convergence of the rtlwifi code between staging and
> wireless, I applied the 40 or 50 patches in my queue to the wireless
> version to create the version that went into staging. If any of the
> current patches to wireless do not seem to be in the staging version,
> sometimes temporary changes are necessary so that the intermediate
> drivers will build and work. Yes, it is code churn, but necessary to
> keep patches small. In keeping with Kalle's requests, only a fraction
> of those patches have been submitted to him.
>
> My intent is to have the RTL8822BE driver moved from staging to
> mainline no later than 4.17. The affected drivers rtl_pci, rtlwifi and
> becoex will be moved in that order. Of course, the required changes
> will need to be in wireless before staging is changed, which will slow
> the process.
Great to hear that you will be working on that. But yeah, that's quite
an effort. IMHO a lot more work than if you would be working only with
drivers/net/wireless.
> As I see it, the switch can only occur with a new version.
Yeah, we need to be very careful with the switch so that we don't break
existing setups.
> My opinion is that the company has gone a long ways toward meeting the
> requirements of the Linux kernel. A lot of their code is written for
> Windows and Linux, with emphasis on Windows, which complicates matters
> as not all of the changes for Linux can be backported.
I think all vendors had these huge OS agnostic drivers before: TI,
Atheros/QCA etc. So it's not really a new thing and still most of the
companies have been able to adapt one way or another.
> Prior to the introduction of these drivers in 2.6.38, drivers were
> released periodically as tar files with no information regarding
> intermediate steps were recorded other than the SVN modification
> number. At least now, we get relatively small changes.
Yes, the changes might be small but to me it seems Realtek still dumps
them in one big release. That's the problem here.
> I have been pleased and surprised at the stability and performance of
> the driver in staging. Other than possible changes required by
> reviewers when it is moved, it is ready for the wireless tree.
>
> Finally, I have notified my Realtek contact that I do not plan to
> continue as the maintainer of these drivers very much longer due to my
> age. I still have the interest, but not always the energy. The people
> at Realtek have proposed a plan that seems workable. Of course, there
> will be hiccups, but the current process does not seem to be that
> smooth.
Sorry to hear that you are stepping down as the maintainer but it's
undertandable as you have had so much work to do. But I hope you still
stick around.
--
Kalle Valo
next prev parent reply other threads:[~2017-10-12 8:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-24 10:08 [PATCH] staging: rtlwifi: check for array overflow Dan Carpenter
2017-08-24 12:14 ` Two rtlwifi drivers? Kalle Valo
2017-08-24 14:41 ` Larry Finger
2017-10-11 9:06 ` Kalle Valo
2017-10-11 13:13 ` Greg Kroah-Hartman
2017-10-11 13:54 ` Dan Carpenter
2017-10-11 14:19 ` Larry Finger
2017-10-12 8:57 ` Kalle Valo [this message]
2017-10-12 8:38 ` Kalle Valo
2017-10-12 10:34 ` Greg Kroah-Hartman
2017-10-16 2:41 ` Pkshih
2017-10-16 6:46 ` Oleksij Rempel
2017-10-16 13:07 ` Kalle Valo
2017-10-16 13:11 ` Oleksij Rempel
2017-10-16 7:45 ` Dan Carpenter
2017-10-16 13:03 ` Kalle Valo
2017-10-16 7:50 ` Greg Kroah-Hartman
2017-10-17 1:24 ` Pkshih
2017-10-16 13:22 ` Kalle Valo
2017-10-17 1:45 ` Pkshih
2017-10-18 5:33 ` Kalle Valo
2017-08-24 18:51 ` [PATCH] staging: rtlwifi: check for array overflow Larry Finger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d15spwuh.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@codeaurora.org \
--cc=Larry.Finger@lwfinger.net \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=johannes.berg@intel.com \
--cc=jrdr.linux@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pkshih@realtek.com \
--cc=yhchuang@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).