From: Matt Fleming <matt@codeblueprint.co.uk>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Peter Jones <pjones@redhat.com>,
linux-efi@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
Matt Fleming <matt.fleming@intel.com>,
Pete Hawkins <pete.hawkins@znyx.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Chad Page <chad.page@znyx.com>
Subject: Re: [PATCH] efifb: Add support for 64-bit frame buffer addresses
Date: Tue, 01 Sep 2015 08:54:26 +0000 [thread overview]
Message-ID: <20150901085426.GC2823@codeblueprint.co.uk> (raw)
In-Reply-To: <CAMuHMdU146p_vs9bfgV9n_tTkH_545hRb1qsEza=dLO=C-y69A@mail.gmail.com>
On Mon, 31 Aug, at 10:24:31PM, Geert Uytterhoeven wrote:
> On Fri, Aug 28, 2015 at 2:12 PM, Matt Fleming <matt@codeblueprint.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
prev parent reply other threads:[~2015-09-01 8:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-28 12:12 [PATCH] efifb: Add support for 64-bit frame buffer addresses Matt Fleming
[not found] ` <1440763939-17027-1-git-send-email-matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-08-31 15:23 ` Peter Jones
2015-08-31 20:24 ` Geert Uytterhoeven
2015-09-01 8:54 ` Matt Fleming [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150901085426.GC2823@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=chad.page@znyx.com \
--cc=geert@linux-m68k.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=mjg59@srcf.ucam.org \
--cc=pete.hawkins@znyx.com \
--cc=pjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).