linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: matthieu castet <castet.matthieu@free.fr>
Cc: linux-wireless@vger.kernel.org
Subject: Re: b43 : unaligned access on mips
Date: Tue, 2 Jun 2009 20:27:35 +0200	[thread overview]
Message-ID: <200906022027.35609.mb@bu3sch.de> (raw)
In-Reply-To: <4A256CCC.5040908@free.fr>

On Tuesday 02 June 2009 20:17:48 matthieu castet wrote:
> Hi Michael,
> 
> Michael Buesch wrote:
> > On Tuesday 02 June 2009 00:00:12 matthieu castet wrote:
> >> matthieu castet wrote:
> >>> Hi,
> >>>
> >>> b43_generate_plcp_hdr generate unaligned access on mips with gcc [1] 
> >>> from openwrt.
> >>>
> >>> A small testcase [2] show that &plcp->data is access as a 32 bit aligned 
> >>> variable (see the "lw      $2,0($4)" and "sw      $2,0($4)").
> >>> I don't know enough mips to know if it is a gcc bug (ignoring the packed 
> >>> attribute) or something missing in b43 code.
> >> For example using "plcp->data" instead "*data" produce the correct code.
> > 
> > Uhm, I'm not sure. This code has been in the driver as-is forever and I don't
> > see any unaligned access issues on mips (I checked a month or so ago).
> Where does this pointer come from ? May be other code change change this 
> pointer alignement?
> Which toolchain did you use ?
> Could you try to build the testcase I posted and see which code it 
> generate ?

OpenWRT trunk.

> > The plcp data structure is also __attribute__((packed)), so there can't be any
> > unaligned accesses, as gcc is required to _expect_ unaligned accesses on structures
> > with packed attribute. So it is required to do byte accesses on architectures where
> > alignment matters.
> > So I don't think there's an issue in the code.
> > 
> But the code doesn't use the structure to access the data.
> It use by an extra pointer "data", and I believe gcc loose the packed 
> info (use byte accesses) when we do the "u32 *data = &plcp->data".

Ok, yeah. Maybe they changed semantics then.

Can you send a patch please?
I do actually prefer patches anyway instead of verbose explanations. I'd have
immediately understood what you were talking about, if you'd just sent a patch. ;)

-- 
Greetings, Michael.

  reply	other threads:[~2009-06-02 18:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-01 21:54 b43 : unaligned access on mips matthieu castet
2009-06-01 22:00 ` matthieu castet
2009-06-02  7:46   ` Johannes Berg
2009-06-02 15:20   ` Michael Buesch
2009-06-02 18:17     ` matthieu castet
2009-06-02 18:27       ` Michael Buesch [this message]
2009-06-04 19:51         ` matthieu castet

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=200906022027.35609.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=castet.matthieu@free.fr \
    --cc=linux-wireless@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).