All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roland Vossen" <rvossen@broadcom.com>
To: "Michael Büsch" <m@bues.ch>, "gregkh@suse.de" <gregkh@suse.de>
Cc: "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:45:46 +0200	[thread overview]
Message-ID: <4DAD920A.9080500@broadcom.com> (raw)
In-Reply-To: <1303215002.27432.5.camel@maggie>

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>

Thanks, Roland.


  reply	other threads:[~2011-04-19 13:46 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 [this message]
2011-04-19 13:49       ` Michael Büsch
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=4DAD920A.9080500@broadcom.com \
    --to=rvossen@broadcom.com \
    --cc=devel@linuxdriverproject.org \
    --cc=gregkh@suse.de \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=m@bues.ch \
    /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.