From: Johannes Berg <johannes@sipsolutions.net>
To: netdev@vger.kernel.org
Cc: Greg Ungerer <gerg@uclinux.org>,
Lucas Stach <l.stach@pengutronix.de>,
Fugang Duan <B38611@freescale.com>, Arnd Bergmann <arnd@arndb.de>,
Shawn Guo <shawnguo@kernel.org>,
Kevin Hilman <khilman@linaro.org>
Subject: Re: net: fec: make driver endian-safe
Date: Sun, 24 Jan 2016 08:26:13 +0100 [thread overview]
Message-ID: <1453620373.2453.6.camel@sipsolutions.net> (raw)
In-Reply-To: <1453586940-21181-1-git-send-email-johannes@sipsolutions.net>
On Sat, 2016-01-23 at 23:09 +0100, Johannes Berg wrote:
>
> +/* buffer endianness appears to be a mess ... ARM is usually LE but
> can be BE */
> +#if defined(CONFIG_ARM) && defined(CONFIG_CPU_BIG_ENDIAN)
Just realized that this is, of course, completely wrong. If the ARM CPU
is little endian, the device is of course *still* little endian, it
doesn't magically change itself with the CONFIG_CPU_BIG_ENDIAN
setting... :)
Ergo, the #if part should be taken, rather than the #else part, to
still define the descriptors as __le and just have no byteswapping
done.
Also, as Arnd had pointed out last night but I wasn't coherent enough
to fully understand, it's exceedingly likely that
> #if defined(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)
this needs to be changed and that the device is simply "generated" as
little-endian for ARM SoCs. He also pointed out that there could be
multiple CONFIG_SOC or CONFIG_ARCH definitions (if I understood
correctly), so this would be wrong anyway.
It's tempting to combine both ifdefs and change them to just CONFIG_ARM
but I have no way of verifying that on anything other than i.MX6 (on
the hummingboard), nor do I even know which SoCs ship with this block.
johannes
prev parent reply other threads:[~2016-01-24 7:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-23 22:09 [PATCH] net: fec: make driver endian-safe Johannes Berg
2016-01-24 7:26 ` Johannes Berg [this message]
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=1453620373.2453.6.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=B38611@freescale.com \
--cc=arnd@arndb.de \
--cc=gerg@uclinux.org \
--cc=khilman@linaro.org \
--cc=l.stach@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=shawnguo@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 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.