From: "Michael Büsch" <m@bues.ch>
To: Roland Vossen <rvossen@broadcom.com>
Cc: "gregkh@suse.de" <gregkh@suse.de>,
"devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"linville@tuxdriver.com" <linville@tuxdriver.com>
Subject: Re: [PATCH 1/2] staging: brcm80211: removed #ifdef __mips__
Date: Tue, 19 Apr 2011 15:49:20 +0200 [thread overview]
Message-ID: <1303220960.27432.11.camel@maggie> (raw)
In-Reply-To: <4DAD920A.9080500@broadcom.com>
On Tue, 2011-04-19 at 15:45 +0200, Roland Vossen wrote:
> Hello guys,
>
> Greg, please drop this patch set. Rest of this email is FYI only.
>
> Michael:
>
> > Are you sure? __mips__ is automagically defined by GCC, if compiling
> > for MIPS. Maybe it should be converted to some CONFIG_... symbol.
> > But removal seems wrong.
>
> You are right. The majority of the removed #ifdef __mips__ code has to
> do with write flushing. To accomplish this, it performs a R_REG after a
> W_REG. I assumed that writeb() and friends guarantee ordering and write
> flushing, but after some reading I learned that this is not the case.
>
> I will rework the code and submit a new patch set.
>
> For some background info: this patch was a reaction on an email from
> John Linville to us. John wrote:
>
> <quote>
> I took a quick run through a pull of staging from today. I made a few
> notes, but a lot of them would seem to relate to the utils stuff you
> mention above. One general comment would be that there still seems
> to be a lot of MIPS-specific stuff buried in the code, in particular
> a lot of "#ifdef __mips__" stuff that if necessary should at least
> be hidden inside the W_REG macro.
> </quote>
You should probably create a new macro W_REG_FLUSH or something like
that, which enforces ordering by reading back the register, if required.
That avoids ugly #ifdefs in the code.
--
Greetings Michael.
next prev parent reply other threads:[~2011-04-19 13:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 7:13 [PATCH 0/2] staging: brcm80211: removal of obsolete mips code Roland Vossen
2011-04-19 7:13 ` [PATCH 1/2] staging: brcm80211: removed #ifdef __mips__ Roland Vossen
2011-04-19 12:10 ` Michael Büsch
2011-04-19 13:45 ` Roland Vossen
2011-04-19 13:49 ` Michael Büsch [this message]
2011-04-19 13:57 ` Johannes Berg
2011-04-20 7:40 ` Roland Vossen
2011-04-19 7:13 ` [PATCH 2/2] staging: brcm80211: removed BCMFASTPATH macro Roland Vossen
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=1303220960.27432.11.camel@maggie \
--to=m@bues.ch \
--cc=devel@linuxdriverproject.org \
--cc=gregkh@suse.de \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=rvossen@broadcom.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.