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
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
&
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
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
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
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
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 >=
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
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
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
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
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
.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
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
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
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
16 matches
Mail list logo
