[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150901085426.GC2823@codeblueprint.co.uk>
Date: Tue, 1 Sep 2015 09:54:26 +0100
From: Matt Fleming <matt@...eblueprint.co.uk>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Peter Jones <pjones@...hat.com>, linux-efi@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
Matt Fleming <matt.fleming@...el.com>,
Pete Hawkins <pete.hawkins@...x.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
Chad Page <chad.page@...x.com>
Subject: Re: [PATCH] efifb: Add support for 64-bit frame buffer addresses
On Mon, 31 Aug, at 10:24:31PM, Geert Uytterhoeven wrote:
> On Fri, Aug 28, 2015 at 2:12 PM, Matt Fleming <matt@...eblueprint.co.uk> wrote:
> > --- a/arch/x86/boot/compressed/eboot.c
> > +++ b/arch/x86/boot/compressed/eboot.c
> > @@ -624,7 +624,7 @@ setup_pixel_info(struct screen_info *si, u32 pixels_per_scan_line,
> > static efi_status_t
> > __gop_query32(struct efi_graphics_output_protocol_32 *gop32,
> > struct efi_graphics_output_mode_info **info,
> > - unsigned long *size, u32 *fb_base)
> > + unsigned long *size, u64 *fb_base)
>
> phys_addr_t instead of u64?
I can see why you might think that, but no, phys_addr_t isn't the
correct data type because your kernel config dictates whether that's
u32 or u64.
We're interacting with the firmware here and the frame buffer address
is always u64, for both 32-bit and 64-bit firmware. It's defined that
way in the UEFI spec.
It's better to be explicit about these kinds of things, and use u64.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists