All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Linz <linz@li-pro.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/4] microblaze: Fix byteorder for microblaze
Date: Fri, 12 Oct 2012 00:31:54 +0200	[thread overview]
Message-ID: <1349994714.2756.4.camel@keto> (raw)
In-Reply-To: <1349441933-22840-2-git-send-email-monstr@monstr.eu>

Am Freitag, den 05.10.2012, 14:58 +0200 schrieb Michal Simek: 
> Just remove ancient code.
> 
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> ---
>  arch/microblaze/include/asm/byteorder.h |   23 -----------------------
>  1 files changed, 0 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/microblaze/include/asm/byteorder.h b/arch/microblaze/include/asm/byteorder.h
> index b2757a4..f3a471d 100644
> --- a/arch/microblaze/include/asm/byteorder.h
> +++ b/arch/microblaze/include/asm/byteorder.h
> @@ -20,29 +20,6 @@
>  
>  #ifdef __GNUC__
>  
> -/* This is effectively a dupe of the arch-independent byteswap
> -   code in include/linux/byteorder/swab.h, however we force a cast
> -   of the result up to 32 bits.  This in turn forces the compiler
> -   to explicitly clear the high 16 bits, which it wasn't doing otherwise.
> -
> -   I think this is a symptom of a bug in mb-gcc.  JW 20040303
> -*/
> -
> -
> -static __inline__ __u16 ___arch__swab16 (__u16 half_word)
> -{
> -	/* 32 bit temp to cast result, forcing clearing of high word */
> -	__u32 temp;
> -
> -	temp = ((half_word & 0x00FFU) << 8) | ((half_word & 0xFF00U) >> 8);
> -
> -	return (__u16) temp;
> -}
> -
> -#define __arch__swab16(x) ___arch__swab16(x)
> -
> -/* Microblaze has no arch-specific endian conversion insns */
> -

Acked-by: Stephan Linz <linz@li-pro.net>

> 
>  #if !defined(__STRICT_ANSI__) || defined(__KERNEL__)
>  #  define __BYTEORDER_HAS_U64__
>  #  define __SWAB_64_THRU_32__

  parent reply	other threads:[~2012-10-11 22:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-05 12:58 [U-Boot] [PATCH 1/4] microblaze: Fix compilation warning in ext2_find_next_zero_bit Michal Simek
2012-10-05 12:58 ` [U-Boot] [PATCH 2/4] microblaze: Fix byteorder for microblaze Michal Simek
2012-10-05 16:48   ` Marek Vasut
2012-10-11 22:31   ` Stephan Linz [this message]
2012-10-05 12:58 ` [U-Boot] [PATCH 3/4] microblaze: Flush caches before enabling them Michal Simek
2012-10-05 16:50   ` Marek Vasut
2012-10-05 12:58 ` [U-Boot] [PATCH 4/4] microblaze: Fix compilation failure because of missing libdts Michal Simek
2012-10-05 16:51   ` Marek Vasut
2012-10-05 16:48 ` [U-Boot] [PATCH 1/4] microblaze: Fix compilation warning in ext2_find_next_zero_bit Marek Vasut
2012-11-07 16:08   ` Michal Simek
2012-11-08  1:30     ` Marek Vasut
2012-11-08  7:57       ` Michal Simek
2012-10-11 22:31 ` Stephan Linz

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=1349994714.2756.4.camel@keto \
    --to=linz@li-pro.net \
    --cc=u-boot@lists.denx.de \
    /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.