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 08:57:26 +0000 [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
WARNING: multiple messages have this Message-ID (diff)
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: 42+ 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 10:08 ` Dan Carpenter
2017-08-24 12:14 ` Two rtlwifi drivers? Kalle Valo
2017-08-24 12:14 ` Kalle Valo
2017-08-24 14:41 ` Larry Finger
2017-08-24 14:41 ` Larry Finger
2017-10-11 9:06 ` Kalle Valo
2017-10-11 9:06 ` Kalle Valo
2017-10-11 13:13 ` Greg Kroah-Hartman
2017-10-11 13:13 ` Greg Kroah-Hartman
2017-10-11 13:54 ` Dan Carpenter
2017-10-11 13:54 ` Dan Carpenter
2017-10-11 14:19 ` Larry Finger
2017-10-11 14:19 ` Larry Finger
2017-10-12 8:57 ` Kalle Valo [this message]
2017-10-12 8:57 ` Kalle Valo
2017-10-12 8:38 ` Kalle Valo
2017-10-12 8:38 ` Kalle Valo
2017-10-12 10:34 ` Greg Kroah-Hartman
2017-10-12 10:34 ` Greg Kroah-Hartman
2017-10-16 2:41 ` Pkshih
2017-10-16 2:41 ` Pkshih
2017-10-16 6:46 ` Oleksij Rempel
2017-10-16 6:46 ` Oleksij Rempel
2017-10-16 13:07 ` Kalle Valo
2017-10-16 13:07 ` Kalle Valo
2017-10-16 13:11 ` Oleksij Rempel
2017-10-16 13:11 ` Oleksij Rempel
2017-10-16 7:45 ` Dan Carpenter
2017-10-16 7:45 ` Dan Carpenter
2017-10-16 13:03 ` Kalle Valo
2017-10-16 13:03 ` Kalle Valo
2017-10-16 7:50 ` Greg Kroah-Hartman
2017-10-16 7:50 ` Greg Kroah-Hartman
2017-10-17 1:24 ` Pkshih
2017-10-16 13:22 ` Kalle Valo
2017-10-16 13:22 ` Kalle Valo
2017-10-17 1:45 ` Pkshih
2017-10-18 5:33 ` Kalle Valo
2017-10-16 8:07 ` walter harms
2017-08-24 18:51 ` [PATCH] staging: rtlwifi: check for array overflow Larry Finger
2017-08-24 18:51 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.