[PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-09 Thread Roy Zang
From: Lan Chunhe-B25806 When system uses 36bit physical address, res.start is 36bit physical address. But the function of in_be32 returns 32bit physical address. Then both of them compared each other is wrong. So by converting the address of res.start into the right format fixes this issue. Sign

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-09 Thread Geert Uytterhoeven
On Thu, Sep 9, 2010 at 12:20, Roy Zang wrote: > From: Lan Chunhe-B25806 > > When system uses 36bit physical address, res.start is 36bit > physical address. But the function of in_be32 returns 32bit > physical address. Then both of them compared each other is > wrong. So by converting the address

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-09 Thread Anton Vorontsov
On Thu, Sep 09, 2010 at 06:20:32PM +0800, Roy Zang wrote: [...] > /** > + * fsl_lbc_addr - convert the base address > + * @addr_base: base address of the memory bank > + * > + * This function converts a base address of lbc into the right format for > the BR > + * registers. If the SOC has e

RE: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Zang Roy-R61911
.com; Lan > Chunhe-B25806; linuxppc-...@ozlabs.org; a...@linux-foundation.org; > dw...@infradead.org; Gala Kumar-B11780 > Subject: Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with > 36bit mode > > On Thu, Sep 9, 2010 at 12:20, Roy Zang wrote: > > From: L

RE: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Zang Roy-R61911
B25806; Wood Scott-B07421; Gala Kumar- > B11780; linuxppc-...@ozlabs.org > Subject: Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with > 36bit mode > > On Thu, Sep 09, 2010 at 06:20:32PM +0800, Roy Zang wrote: > [...] > > /** > > + * fsl_lbc_addr - conve

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Timur Tabi
On Mon, Sep 13, 2010 at 2:30 AM, Zang Roy-R61911 wrote: > What is the different for unsigned int and u32? I think they are same. Roy, please don't ever write code that assumes that sizeof(int) == 4. There's a reason why we have unsized integer types (like int, long, and short) and sized integer

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Artem Bityutskiy
On Mon, 2010-09-13 at 09:10 -0500, Timur Tabi wrote: > On Mon, Sep 13, 2010 at 2:30 AM, Zang Roy-R61911 wrote: > > > What is the different for unsigned int and u32? I think they are same. > > Roy, please don't ever write code that assumes that sizeof(int) == 4. > There's a reason why we have uns

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Timur Tabi
On Mon, Sep 13, 2010 at 9:27 AM, Artem Bityutskiy wrote: > Yes, sizeof(int) == 4 assumption is not good. > > But sizeof(int) >= 4 is perfectly fine. I have to disagree. I don't see how you can say that == is not okay, but >= is okay. That just doesn't make any sense. Obviously, you have to m

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Scott Wood
PM > > To: Zang Roy-R61911 > > Cc: linux-...@lists.infradead.org; Wood Scott-B07421; dedeki...@gmail.com; > > Lan > > Chunhe-B25806; linuxppc-...@ozlabs.org; a...@linux-foundation.org; > > dw...@infradead.org; Gala Kumar-B11780 > > Subject: Re: [PATCH v2 3/3][MTD

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Artem Bityutskiy
On Mon, 2010-09-13 at 09:35 -0500, Timur Tabi wrote: > On Mon, Sep 13, 2010 at 9:27 AM, Artem Bityutskiy wrote: > > > Yes, sizeof(int) == 4 assumption is not good. > > > > But sizeof(int) >= 4 is perfectly fine. > > I have to disagree. I don't see how you can say that == is not okay, > but >=

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Timur Tabi
On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy wrote: > Unsigned int is reliably >= 4 in Linux. Not exactly. sizeof(unsigned int) is effectively never greater than 4 in Linux (I think it's still 32 bits even on a 64-bit kernel), so it makes no sense to say >=. So since you can't say that si

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Artem Bityutskiy
On Mon, 2010-09-13 at 13:36 -0500, Timur Tabi wrote: > On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy > wrote: > > Unsigned int is reliably >= 4 in Linux. > > Not exactly. sizeof(unsigned int) is effectively never greater than 4 > in Linux I know and said the same in the other paragraph wh

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Scott Wood
On Mon, 13 Sep 2010 13:36:45 -0500 Timur Tabi wrote: > On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy > wrote: > > Unsigned int is reliably >= 4 in Linux. > > Not exactly. sizeof(unsigned int) is effectively never greater than 4 > in Linux (I think it's still 32 bits even on a 64-bit kern

RE: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Zang Roy-R61911
t; foundation.org; dw...@infradead.org; Gala Kumar-B11780 > Subject: Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with > 36bit mode > > On Mon, 13 Sep 2010 00:22:10 -0700 > "Zang Roy-R61911" wrote: > > > > > > > &g

RE: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-13 Thread Zang Roy-R61911
ad.org; a...@linux- > foundation.org; dw...@infradead.org; Gala Kumar-B11780 > Subject: Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with > 36bit mode > > On Mon, 2010-09-13 at 09:10 -0500, Timur Tabi wrote: > > On Mon, Sep 13, 2010 at 2:30 AM, Zang Roy-R61911 &

Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode

2010-09-14 Thread Timur Tabi
On Mon, Sep 13, 2010 at 11:09 PM, Zang Roy-R61911 wrote: >> > > Shouldn't this be u32 or __be32, for consistency with the actual >> > > comparisons below? >> > __be32 is better. >> >> I disagree, the return from this function is native-endian.  It should >> be u32. > But the return of this value