All of lore.kernel.org
 help / color / mirror / Atom feed
From: Piet Delaney <piet.delaney@tensilica.com>
To: Chris Zankel <chris@zankel.net>
Cc: Harvey Harrison <harvey.harrison@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Marc Gauthier <marc@tensilica.com>,
	Joe Taylor <joetayloremail@gmail.com>,
	linux-xtensa@linux-xtensa.org,
	Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH 10/10] xtensa: use the new byteorder headers - Merged with your previous xtensa-next and will remerge shortly.
Date: Fri, 07 Nov 2008 19:00:16 -0800	[thread overview]
Message-ID: <491500C0.90407@tensilica.com> (raw)
In-Reply-To: <49133094.6070407@zankel.net>

Hi Chris:

   I've merged your recent xtensa-next with our 2.6.24-smp repo.
It seems to work fine and I'm in the process of cleaning it
up a bit and adding preliminary XTENSA kgdb support.

   Looks like you have moved xtensa include files to arch/xtensa.
I'm pulling your repo and re-merge with your latest bits. I'm
limiting the changes outside of arch/xtensa to just the few
required (like the open core Ethernet driver) and a very small
change I made to mm/slab.c to allow the kernel to be compiled -O0.

   One regression that came up after the merge with your previous
bits (2.6.27-rc3 last changed 2008-07-30) was that the NFS RPC
code wouldn't compile -O0 due to a problem with byte order macros
to convert IP addresses from local to net form. In this case it
appears to be the RPC code with it's initialization of a structure
with a htonl(INADDR_LOOPBACK) which isn't being optimized away.

		"net/sunrpc/rpcb_clnt.c
		-----------------------
static const struct sockaddr_in rpcb_inaddr_loopback = {
         .sin_family             = AF_INET,
         .sin_addr.s_addr        = htonl(INADDR_LOOPBACK),
         .sin_port               = htons(RPCBIND_PORT),
};

Looks like this convention was started by Chuck Lever on 7/14/2008 (Id:44).


   Still tweaking and testing a major change to entry.S that Marc wrote
to allow gdb to backtrace across an exception. It's been extremely
valuable while working on problems like bringing up the kgdb stub.

-piet

> Hi Harvey,
> 
> I have added your patch to the xtensa-next tree on kernel.org and will 
> push to Linus soon.
> 
> Thanks,
> -Chris
> 
> Harvey Harrison wrote:
>> Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
>> ---
>>  include/asm-xtensa/byteorder.h |   32 +++++++++++++++-----------------
>>  1 files changed, 15 insertions(+), 17 deletions(-)
>>
>> diff --git a/include/asm-xtensa/byteorder.h 
>> b/include/asm-xtensa/byteorder.h
>> index 765edf1..07d10ad 100644
>> --- a/include/asm-xtensa/byteorder.h
>> +++ b/include/asm-xtensa/byteorder.h
>> @@ -14,7 +14,17 @@
>>  #include <asm/types.h>
>>  #include <linux/compiler.h>
>>  
>> -static __inline__ __attribute_const__ __u32 ___arch__swab32(__u32 x)
>> +#ifdef __XTENSA_EL__
>> +# define __LITTLE_ENDIAN
>> +#elif defined(__XTENSA_EB__)
>> +# define __BIG_ENDIAN
>> +#else
>> +# error processor byte order undefined!
>> +#endif
>> +
>> +#define __SWAB_64_THRU_32__
>> +
>> +static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
>>  {
>>      __u32 res;
>>      /* instruction sequence from Xtensa ISA release 2/2000 */
>> @@ -28,8 +38,9 @@ static __inline__ __attribute_const__ __u32 
>> ___arch__swab32(__u32 x)
>>          );
>>      return res;
>>  }
>> +#define __arch_swab32 __arch_swab32
>>  
>> -static __inline__ __attribute_const__ __u16 ___arch__swab16(__u16 x)
>> +static inline __attribute_const__ __u16 __arch_swab16(__u16 x)
>>  {
>>      /* Given that 'short' values are signed (i.e., can be negative),
>>       * we cannot assume that the upper 16-bits of the register are
>> @@ -62,21 +73,8 @@ static __inline__ __attribute_const__ __u16 
>> ___arch__swab16(__u16 x)
>>  
>>      return res;
>>  }
>> +#define __arch_swab16 __arch_swab16
>>  
>> -#define __arch__swab32(x) ___arch__swab32(x)
>> -#define __arch__swab16(x) ___arch__swab16(x)
>> -
>> -#if !defined(__STRICT_ANSI__) || defined(__KERNEL__)
>> -#  define __BYTEORDER_HAS_U64__
>> -#  define __SWAB_64_THRU_32__
>> -#endif
>> -
>> -#ifdef __XTENSA_EL__
>> -# include <linux/byteorder/little_endian.h>
>> -#elif defined(__XTENSA_EB__)
>> -# include <linux/byteorder/big_endian.h>
>> -#else
>> -# error processor byte order undefined!
>> -#endif
>> +#include <linux/byteorder.h>
>>  
>>  #endif /* _XTENSA_BYTEORDER_H */
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

  reply	other threads:[~2008-11-08  3:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-05 18:35 [PATCH 10/10] xtensa: use the new byteorder headers Harvey Harrison
2008-11-06 17:59 ` Chris Zankel
2008-11-08  3:00   ` Piet Delaney [this message]
2008-11-08  3:38     ` [PATCH 10/10] xtensa: use the new byteorder headers - Merged with your previous xtensa-next and will remerge shortly Harvey Harrison
2008-11-09  3:55       ` Piet Delaney
2008-11-14  8:13         ` Piet Delaney
2008-11-14 16:33           ` Harvey Harrison

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=491500C0.90407@tensilica.com \
    --to=piet.delaney@tensilica.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris@zankel.net \
    --cc=chuck.lever@oracle.com \
    --cc=harvey.harrison@gmail.com \
    --cc=joetayloremail@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=marc@tensilica.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.