Re: [PATCH v2 03/20] ARM: LPAE: use u32 instead of unsigned longfor 32-bit ptes

[Russell King - ARM Linux]

On Sun, Nov 14, 2010 at 02:13:23PM +0000, Catalin Marinas wrote:
> On Sunday, November 14, 2010, Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
> > On Sunday, November 14, 2010, Russell King - ARM Linux
> > <linux@xxxxxxxxxxxxxxxx> wrote:
> >> On Fri, Nov 12, 2010 at 06:00:23PM +0000, Catalin Marinas wrote:
> >>> From: Will Deacon <will.deacon@xxxxxxx>
> >>>
> >>> When using 2-level paging, pte_t and pmd_t are typedefs for
> >>> unsigned long but phys_addr_t is a typedef for u32.
> >>>
> >>> This patch uses u32 for the page table entry types when
> >>> phys_addr_t is not 64-bit, allowing the same conversion
> >>> specifier to be used for physical addresses and page table
> >>> entries regardless of LPAE.
> >>
> >> However, code which prints the value of page table entries assumes that
> >> they are unsigned long, and places where we store the raw pte value also
> >> uses 'unsigned long'.
> >>
> >> If we're going to make this change, we need to change more places than
> >> this patch covers.  grep for pte_val to help find those places.
> >
> > Patch 19/20 introduces a common macro for formatting but we should
> > probably order the patches a bit to avoid problems if anyone is
> > bisecting  in the middle of the series.
> 
> Actually not a problem since LPAE is only enabled by the last patch.
> There may be some compiler warnings without 19/20, I need to check.

There will be compiler warnings because u32 is unsigned int, and we
print it as %08lx.  Generic code cases pte values to (long long) and
prints them using %08llx.  We should do the same.

In any case, this patch on its own introduces new compiler warnings.
These need to be fixed in this patch, rather than relying on one later
in the series.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/