I'll reject the patch. Thanks for getting back to me. Ira
> -----Original Message----- > From: [email protected] [mailto:linux-rdma- > [email protected]] On Behalf Of Pramod Gunjikar > Sent: Thursday, April 18, 2013 3:29 AM > To: Boris Chiu > Cc: Or Gerlitz; Hal Rosenstock; Ira Weiny; [email protected] > Subject: Re: [PATCH] libibmad: To fix big endian problem for both 32-bit & 64- > bit SPARC > > Hello Hal / Or, > > Sorry for the delay in getting back on this. > > Solaris specific endian fixes were applied to OFED 1.3 in order to fix > infiniband-diag failures observed > on SPARC. Changes to OFED 1.5.3 now make these fixes redundant > consequently the patch request > is withdrawn. > > Let us know if you have any queries. > > Thanks > Pramod > > > Hi Hal and Or, > > > > We are checking on this and will get back. > > > > Thanks, > > Boris > > > > On 03/13/13 05:58, Or Gerlitz wrote: > >> On 13/03/2013 14:48, Hal Rosenstock wrote: > >>> On 3/12/2013 3:36 PM, Boris Chiu wrote: > >>>> >--- a/src/dump.c > >>>> >+++ b/src/dump.c > >>>> >@@ -46,12 +46,24 @@ > >>>> > > >>>> >void mad_dump_int(char *buf, int bufsz, void *val, int valsz) { > >>>> >+ /* > >>>> >+ * the val pointer passed to the dump routines are always 32 bit > >>>> >+ * integers for valsz <= 4 and 64 bit integer for the rest. > >>>> It is > >>>> >never > >>>> >+ * uint8_t or uint16_t. This is because mad_decode_field > >>>> >+ always > >>>> >returns > >>>> >+ * the values as 32 bit integer even if they are 8 bit or 16 > >>>> >+ bit > >>>> >fields. > >>>> >+ */ > >>>> > switch (valsz) { > >>>> > case 1: > >>>> >- snprintf(buf, bufsz, "%d", *(uint32_t *) val & 0xff); > >>>> >+#if defined(_BIG_ENDIAN) > >>>> >+ val = ((uint8_t *)val) + 3; #endif /* _BIG_ENDIAN */ > >>> I don't understand what's different about SPARC and PPC in terms of > >>> this. These routines all work without this on PPC64 and PPC32. > >> > >> Yep, agree, assuming the code works on other BE archs, we 1st and > >> most need to understand the problem before going to solutions. > >> > >> Or. > >> > >> > >> > >>> > >>> At a minimum, should this be ifdef'd on something like both __sun > >>> and > >>> __SVR4 rather than _BIG_ENDIAN ? > >> > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-rdma" > > in the body of a message to [email protected] More > majordomo > > info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the > body of a message to [email protected] More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
