From: Larry Finger <Larry.Finger@lwfinger.net>
To: Kees Cook <keescook@chromium.org>
Cc: "John W. Linville" <linville@tuxdriver.com>,
Greg KH <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: repeated bugs in new rtl wifi drivers
Date: Thu, 11 Sep 2014 19:31:04 -0500 [thread overview]
Message-ID: <54123EC8.1040906@lwfinger.net> (raw)
In-Reply-To: <CAGXu5jJmyyWrsS2EFPT59RjK-np3sqmxe69meecmpicv6BNKrA@mail.gmail.com>
On 09/11/2014 06:50 PM, Kees Cook wrote:
> On Thu, Sep 11, 2014 at 4:38 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> On 09/11/2014 05:27 PM, Kees Cook wrote:
>>>
>>> Hi,
>>>
>>> I keep fixing this same bug that keeps showing up in the rtl wifi
>>> drivers. CL_PRINTF keeps getting redefined (incorrectly) instead of
>>> using a correctly fixed global. Is there a way to stop this from
>>> happening again?
>>>
>>> Here are the past three (identical) fixes I've landed:
>>> a3355a62673e2c4bd8617d2f07c8edee92a89b8d
>>> 037526f1ae7eeff5cf27ad790ebfe30303eeebe8
>>> 6437f51ec36af8ef1e3e2659439b35c37e5498e2
>>>
>>> And the buildbot report below seems to show there are more to be made. :)
>>
>>
>> Sorry that I missed your fix. I should have seen it come through Linville's
>> list. I will push your fix through again.
>
> Well, I should clarify: it's not getting unfixed/reverted, but rather,
> it hasn't been consolidated to avoid needing the code again in the
> future. All three of the fixes above are on almost identical header
> files. If we could consolidate them, that would be great, and it would
> keep things much nicer.
The two in staging are there because there was need to have those two driver
available as quickly as possible. Even though a lot of code is the same as the
regular tree, there were enough differences that it has taken a lot of work to
merge those two new drivers into the wireless tree. It is part of that effort
that ended up effectively reverting your fix for the wireless tree.
My plan is to ultimately eliminate all the CL_SNPRINTF and CL_PRINTF stuff. In
every case I have seen, the two are paired, thus they can be replaced with a
simple "pr_info". Now that we are unifying the Realtek and kernel codes, I need
to check with the Realtek guys.
Larry
next prev parent reply other threads:[~2014-09-12 0:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 22:27 repeated bugs in new rtl wifi drivers Kees Cook
2014-09-11 22:37 ` Greg KH
2014-09-11 23:38 ` Larry Finger
2014-09-11 23:50 ` Kees Cook
2014-09-12 0:31 ` Larry Finger [this message]
2014-09-12 10:49 ` Masanari Iida
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=54123EC8.1040906@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.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