From: Greg KH <gregkh@linux.com>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Kalle Valo <kvalo@codeaurora.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Birming Chiu <birming@realtek.com>, Pkshih <pkshih@realtek.com>
Subject: Re: New Realtek driver
Date: Sat, 22 Jul 2017 05:51:20 +0200 [thread overview]
Message-ID: <20170722035119.GA31377@kroah.com> (raw)
In-Reply-To: <2cf70a42-6665-1da9-7c38-32751f2dc981@lwfinger.net>
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
next prev parent reply other threads:[~2017-07-22 3:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 1:18 New Realtek driver Larry Finger
2017-07-21 10:13 ` Marcel Holtmann
2017-07-22 2:04 ` Larry Finger
2017-07-25 11:51 ` Kalle Valo
2017-07-21 15:08 ` Greg KH
2017-07-22 0:36 ` Larry Finger
2017-07-22 3:51 ` Greg KH [this message]
2017-07-22 12:51 ` Larry Finger
2017-07-22 13:09 ` Greg KH
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=20170722035119.GA31377@kroah.com \
--to=gregkh@linux.com \
--cc=Larry.Finger@lwfinger.net \
--cc=birming@realtek.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pkshih@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.