New Realtek driver

New Realtek driver

[Larry Finger]

Kalle and Greg,

Once again I find myself in the awkward position of needing to submit code to 
two different trees, i.e. wireless and staging.

The code in question concerns a new Realtek device, the RTL8822BE. The device is 
already shipping, and Realtek would like it to be available in kernel 3.14. As 
it consists of ~120,000 new lines of code, I have assured Realtek that 3.14 
would not be possible, at least in the wireless tree. What I plan to do is 
submit the changes in the existing drivers through wireless, and the three 
totally new drivers through staging. My expectation is that this code would live 
for a relatively short time there, but going that route would give time for the 
code to be reviewed properly, but still be available in a kernel driver. All of 
the new code will be available in a GitHub repo maintained by Realtek for those 
users whose distros do not configure anything in staging.

For my part, I will push the wireless tree material as fast as I can and hope 
there is time available near the end of the 4.13-rcX sequence for the material 
to reach 4.14-rc1.

Thanks for your understanding and help.

Larry

Re: New Realtek driver

[Marcel Holtmann]

Hi Larry,

> Once again I find myself in the awkward position of needing to submit code to two different trees, i.e. wireless and staging.
> 
> The code in question concerns a new Realtek device, the RTL8822BE. The device is already shipping, and Realtek would like it to be available in kernel 3.14. As it consists of ~120,000 new lines of code, I have assured Realtek that 3.14 would not be possible, at least in the wireless tree. What I plan to do is submit the changes in the existing drivers through wireless, and the three totally new drivers through staging. My expectation is that this code would live for a relatively short time there, but going that route would give time for the code to be reviewed properly, but still be available in a kernel driver. All of the new code will be available in a GitHub repo maintained by Realtek for those users whose distros do not configure anything in staging.
> 
> For my part, I will push the wireless tree material as fast as I can and hope there is time available near the end of the 4.13-rcX sequence for the material to reach 4.14-rc1.

I really do not understand the need for staging if there is already active cleanup and submission to wireless-drivers happening. I find it also unfair to others who submit code to linux-wireless and have it reviewed there before it gets merged.

Also the faster it gets into wireless-drivers the faster it can be available via linux-backports. Seems many companies have used linux-backports successfully to deal with older kernel versions.

Regards

Marcel

Re: New Realtek driver

[Greg KH]

On Thu, Jul 20, 2017 at 08:18:13PM -0500, Larry Finger wrote:
> Kalle and Greg,
> 
> Once again I find myself in the awkward position of needing to submit code
> to two different trees, i.e. wireless and staging.
> 
> The code in question concerns a new Realtek device, the RTL8822BE. The
> device is already shipping, and Realtek would like it to be available in
> kernel 3.14. As it consists of ~120,000 new lines of code, I have assured
> Realtek that 3.14 would not be possible, at least in the wireless tree. What
> I plan to do is submit the changes in the existing drivers through wireless,
> and the three totally new drivers through staging. My expectation is that
> this code would live for a relatively short time there, but going that route
> would give time for the code to be reviewed properly, but still be available
> in a kernel driver. All of the new code will be available in a GitHub repo
> maintained by Realtek for those users whose distros do not configure
> anything in staging.
> 
> For my part, I will push the wireless tree material as fast as I can and
> hope there is time available near the end of the 4.13-rcX sequence for the
> material to reach 4.14-rc1.

Why do you need a staging driver to have changes in the wireless tree?
Staging drivers should be self-contained and not rely on anything
outside of it in order to work properly (i.e. don't add code to the real
kernel only for a staging driver.)

thanks,

greg k-h

Re: New Realtek driver

[Larry Finger]

On 07/21/2017 10:08 AM, Greg KH wrote:
> On Thu, Jul 20, 2017 at 08:18:13PM -0500, Larry Finger wrote:
>> Kalle and Greg,
>>
>> Once again I find myself in the awkward position of needing to submit code
>> to two different trees, i.e. wireless and staging.
>>
>> The code in question concerns a new Realtek device, the RTL8822BE. The
>> device is already shipping, and Realtek would like it to be available in
>> kernel 3.14. As it consists of ~120,000 new lines of code, I have assured
>> Realtek that 3.14 would not be possible, at least in the wireless tree. What
>> I plan to do is submit the changes in the existing drivers through wireless,
>> and the three totally new drivers through staging. My expectation is that
>> this code would live for a relatively short time there, but going that route
>> would give time for the code to be reviewed properly, but still be available
>> in a kernel driver. All of the new code will be available in a GitHub repo
>> maintained by Realtek for those users whose distros do not configure
>> anything in staging.
>>
>> For my part, I will push the wireless tree material as fast as I can and
>> hope there is time available near the end of the 4.13-rcX sequence for the
>> material to reach 4.14-rc1.
> 
> Why do you need a staging driver to have changes in the wireless tree?
> Staging drivers should be self-contained and not rely on anything
> outside of it in order to work properly (i.e. don't add code to the real
> kernel only for a staging driver.)

Greg,

To add the new driver to staging without any other changes, I will need to 
duplicate a lot of code. That is no problem, other than the duplicate entry 
points that will show up in a makeallyes configuration. If that is what you 
want, then that is what I will do.

Larry

Re: New Realtek driver

[Larry Finger]

On 07/21/2017 05:13 AM, Marcel Holtmann wrote:
> Hi Larry,
> 
>> Once again I find myself in the awkward position of needing to submit code to two different trees, i.e. wireless and staging.
>>
>> The code in question concerns a new Realtek device, the RTL8822BE. The device is already shipping, and Realtek would like it to be available in kernel 3.14. As it consists of ~120,000 new lines of code, I have assured Realtek that 3.14 would not be possible, at least in the wireless tree. What I plan to do is submit the changes in the existing drivers through wireless, and the three totally new drivers through staging. My expectation is that this code would live for a relatively short time there, but going that route would give time for the code to be reviewed properly, but still be available in a kernel driver. All of the new code will be available in a GitHub repo maintained by Realtek for those users whose distros do not configure anything in staging.
>>
>> For my part, I will push the wireless tree material as fast as I can and hope there is time available near the end of the 4.13-rcX sequence for the material to reach 4.14-rc1.
> 
> I really do not understand the need for staging if there is already active cleanup and submission to wireless-drivers happening. I find it also unfair to others who submit code to linux-wireless and have it reviewed there before it gets merged.
> 
> Also the faster it gets into wireless-drivers the faster it can be available via linux-backports. Seems many companies have used linux-backports successfully to deal with older kernel versions.

The part that is being submitted to wireless drivers is only a small part of the 
entire effort.

Beyond that is the new driver with roughly 120,000 lines of code that have not 
yet been seen by any reviewers. My experience says that there is no way that 
this much new code will be reviewed and approved in a month. Including 
everything in wireless would likely take until 4.15 or 4.16.

Larry

Re: New Realtek driver

[Greg KH]

On Fri, Jul 21, 2017 at 07:36:41PM -0500, Larry Finger wrote:
> On 07/21/2017 10:08 AM, Greg KH wrote:
> > On Thu, Jul 20, 2017 at 08:18:13PM -0500, Larry Finger wrote:
> > > Kalle and Greg,
> > > 
> > > Once again I find myself in the awkward position of needing to submit code
> > > to two different trees, i.e. wireless and staging.
> > > 
> > > The code in question concerns a new Realtek device, the RTL8822BE. The
> > > device is already shipping, and Realtek would like it to be available in
> > > kernel 3.14. As it consists of ~120,000 new lines of code, I have assured
> > > Realtek that 3.14 would not be possible, at least in the wireless tree. What
> > > I plan to do is submit the changes in the existing drivers through wireless,
> > > and the three totally new drivers through staging. My expectation is that
> > > this code would live for a relatively short time there, but going that route
> > > would give time for the code to be reviewed properly, but still be available
> > > in a kernel driver. All of the new code will be available in a GitHub repo
> > > maintained by Realtek for those users whose distros do not configure
> > > anything in staging.
> > > 
> > > For my part, I will push the wireless tree material as fast as I can and
> > > hope there is time available near the end of the 4.13-rcX sequence for the
> > > material to reach 4.14-rc1.
> > 
> > Why do you need a staging driver to have changes in the wireless tree?
> > Staging drivers should be self-contained and not rely on anything
> > outside of it in order to work properly (i.e. don't add code to the real
> > kernel only for a staging driver.)
> 
> Greg,
> 
> To add the new driver to staging without any other changes, I will need to
> duplicate a lot of code. That is no problem, other than the duplicate entry
> points that will show up in a makeallyes configuration. If that is what you
> want, then that is what I will do.

What do you mean by "duplicate entry points"?  Duplicate global symbols?
Something else?

confused,

greg k-h

Re: New Realtek driver

[Larry Finger]

On 07/21/2017 10:51 PM, Greg KH wrote:
> On Fri, Jul 21, 2017 at 07:36:41PM -0500, Larry Finger wrote:
>> On 07/21/2017 10:08 AM, Greg KH wrote:
>>> On Thu, Jul 20, 2017 at 08:18:13PM -0500, Larry Finger wrote:
>>>> Kalle and Greg,
>>>>
>>>> Once again I find myself in the awkward position of needing to submit code
>>>> to two different trees, i.e. wireless and staging.
>>>>
>>>> The code in question concerns a new Realtek device, the RTL8822BE. The
>>>> device is already shipping, and Realtek would like it to be available in
>>>> kernel 3.14. As it consists of ~120,000 new lines of code, I have assured
>>>> Realtek that 3.14 would not be possible, at least in the wireless tree. What
>>>> I plan to do is submit the changes in the existing drivers through wireless,
>>>> and the three totally new drivers through staging. My expectation is that
>>>> this code would live for a relatively short time there, but going that route
>>>> would give time for the code to be reviewed properly, but still be available
>>>> in a kernel driver. All of the new code will be available in a GitHub repo
>>>> maintained by Realtek for those users whose distros do not configure
>>>> anything in staging.
>>>>
>>>> For my part, I will push the wireless tree material as fast as I can and
>>>> hope there is time available near the end of the 4.13-rcX sequence for the
>>>> material to reach 4.14-rc1.
>>>
>>> Why do you need a staging driver to have changes in the wireless tree?
>>> Staging drivers should be self-contained and not rely on anything
>>> outside of it in order to work properly (i.e. don't add code to the real
>>> kernel only for a staging driver.)
>>
>> Greg,
>>
>> To add the new driver to staging without any other changes, I will need to
>> duplicate a lot of code. That is no problem, other than the duplicate entry
>> points that will show up in a makeallyes configuration. If that is what you
>> want, then that is what I will do.
> 
> What do you mean by "duplicate entry points"?  Duplicate global symbols?
> Something else?

Of course, I meant duplicate global symbols.

Larry

Re: New Realtek driver

[Greg KH]

On Sat, Jul 22, 2017 at 07:51:20AM -0500, Larry Finger wrote:
> On 07/21/2017 10:51 PM, Greg KH wrote:
> > On Fri, Jul 21, 2017 at 07:36:41PM -0500, Larry Finger wrote:
> > > On 07/21/2017 10:08 AM, Greg KH wrote:
> > > > On Thu, Jul 20, 2017 at 08:18:13PM -0500, Larry Finger wrote:
> > > > > Kalle and Greg,
> > > > > 
> > > > > Once again I find myself in the awkward position of needing to submit code
> > > > > to two different trees, i.e. wireless and staging.
> > > > > 
> > > > > The code in question concerns a new Realtek device, the RTL8822BE. The
> > > > > device is already shipping, and Realtek would like it to be available in
> > > > > kernel 3.14. As it consists of ~120,000 new lines of code, I have assured
> > > > > Realtek that 3.14 would not be possible, at least in the wireless tree. What
> > > > > I plan to do is submit the changes in the existing drivers through wireless,
> > > > > and the three totally new drivers through staging. My expectation is that
> > > > > this code would live for a relatively short time there, but going that route
> > > > > would give time for the code to be reviewed properly, but still be available
> > > > > in a kernel driver. All of the new code will be available in a GitHub repo
> > > > > maintained by Realtek for those users whose distros do not configure
> > > > > anything in staging.
> > > > > 
> > > > > For my part, I will push the wireless tree material as fast as I can and
> > > > > hope there is time available near the end of the 4.13-rcX sequence for the
> > > > > material to reach 4.14-rc1.
> > > > 
> > > > Why do you need a staging driver to have changes in the wireless tree?
> > > > Staging drivers should be self-contained and not rely on anything
> > > > outside of it in order to work properly (i.e. don't add code to the real
> > > > kernel only for a staging driver.)
> > > 
> > > Greg,
> > > 
> > > To add the new driver to staging without any other changes, I will need to
> > > duplicate a lot of code. That is no problem, other than the duplicate entry
> > > points that will show up in a makeallyes configuration. If that is what you
> > > want, then that is what I will do.
> > 
> > What do you mean by "duplicate entry points"?  Duplicate global symbols?
> > Something else?
> 
> Of course, I meant duplicate global symbols.

Just make the staging driver only be built as a module then there should
not be the chance for any global symbols to occur.  We've done that many
times in the past, probably for these same drivers...

thanks,

greg k-h

Re: New Realtek driver

[Kalle Valo]

Larry Finger <Larry.Finger@lwfinger.net> writes:

> On 07/21/2017 05:13 AM, Marcel Holtmann wrote:
>> Hi Larry,
>>
>>> Once again I find myself in the awkward position of needing to
>>> submit code to two different trees, i.e. wireless and staging.
>>>
>>> The code in question concerns a new Realtek device, the RTL8822BE.
>>> The device is already shipping, and Realtek would like it to be
>>> available in kernel 3.14. As it consists of ~120,000 new lines of
>>> code, I have assured Realtek that 3.14 would not be possible, at
>>> least in the wireless tree. What I plan to do is submit the changes
>>> in the existing drivers through wireless, and the three totally new
>>> drivers through staging. My expectation is that this code would
>>> live for a relatively short time there, but going that route would
>>> give time for the code to be reviewed properly, but still be
>>> available in a kernel driver. All of the new code will be available
>>> in a GitHub repo maintained by Realtek for those users whose
>>> distros do not configure anything in staging.
>>>
>>> For my part, I will push the wireless tree material as fast as I
>>> can and hope there is time available near the end of the 4.13-rcX
>>> sequence for the material to reach 4.14-rc1.
>>
>> I really do not understand the need for staging if there is already
>> active cleanup and submission to wireless-drivers happening. I find
>> it also unfair to others who submit code to linux-wireless and have
>> it reviewed there before it gets merged.
>>
>> Also the faster it gets into wireless-drivers the faster it can be
>> available via linux-backports. Seems many companies have used
>> linux-backports successfully to deal with older kernel versions.
>
> The part that is being submitted to wireless drivers is only a small
> part of the entire effort.
>
> Beyond that is the new driver with roughly 120,000 lines of code that
> have not yet been seen by any reviewers.

120 kLOC is a lot, why is the driver so big? I would like to take a
quick look, is the code available somewhere?

-- 
Kalle Valo