Re: Two rtlwifi drivers?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Larry Finger <Larry.Finger@xxxxxxxxxxxx> 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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux