All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Randy Wright <rwright@hp.com>
Cc: Matthew Garrett <mjg@redhat.com>,
	linux-kernel@vger.kernel.org, tmac@hp.com
Subject: Re: [PATCH] Fix devmem_is_allowed for below 1MB accesses for an efi machine
Date: Thu, 04 Oct 2012 14:06:09 -0700	[thread overview]
Message-ID: <506DFA41.3080803@zytor.com> (raw)
In-Reply-To: <506DEC95.8050806@hp.com>

On 10/04/2012 01:07 PM, Randy Wright wrote:
> 
> I wanted to mention in this context a patch RFC I posted yesterday as a
> distinct thread which is visible as https://lkml.org/lkml/2012/10/3/589
> with the subject: [PATCH RFC] function probe_roms accessing improper
> addresses on UEFI systems.
> 

And it's equally as wrong.  It has nothing to do with UEFI vs BIOS at
all; this is rather a change in the classic behavior on x86 to return -1
on an impossible read rather than #MC.

Normally I would say probe_roms() doesn't really make any sense in the
EFI context anyway, but I believe there are systems which actually need
to probe at least for the video ROM even when running under EFI (and I
think there are storage devices which have parameter blocks in their
ROMs with similar issues).

Excluding reserved regions in general is a non-option, because on a lot
of systems the ROMs that *do* need to be probed for are marked just
RESERVED.

One option would be to quirk it; obviously there is some piece of
hardware which does cause this #MC and hopefully we could use that to
detect that specific regions should be excluded; another option would be
to trap the #MC during ROM probing.

	-hpa

  reply	other threads:[~2012-10-04 21:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <jQim6-6MC-7@gated-at.bofh.it>
     [not found] ` <jQiFt-6UB-13@gated-at.bofh.it>
     [not found]   ` <jQoUx-33k-3@gated-at.bofh.it>
     [not found]     ` <jQp4d-37r-3@gated-at.bofh.it>
     [not found]       ` <jQpxf-3Cv-1@gated-at.bofh.it>
2012-10-04 20:07         ` [PATCH] Fix devmem_is_allowed for below 1MB accesses for an efi machine Randy Wright
2012-10-04 21:06           ` H. Peter Anvin [this message]
2012-10-02 21:32 T Makphaibulchoke
2012-10-02 21:32 ` T Makphaibulchoke
2012-10-02 21:50 ` H. Peter Anvin
2012-10-02 21:50   ` H. Peter Anvin
2012-10-03  4:31   ` Matthew Garrett
2012-10-03  4:31     ` Matthew Garrett
2012-10-03  4:44     ` H. Peter Anvin
2012-10-03  4:44       ` H. Peter Anvin
2012-10-03  5:15       ` Matthew Garrett
2012-10-03  5:15         ` Matthew Garrett
2012-10-03  5:13         ` Thavatchai Makphaibulchoke
2012-10-03  5:13           ` Thavatchai Makphaibulchoke
2012-10-03  5:28           ` Matthew Garrett
2012-10-03  5:28             ` Matthew Garrett
2012-10-03  5:35             ` H. Peter Anvin
2012-10-03  5:35               ` H. Peter Anvin
2012-10-03  5:27         ` H. Peter Anvin
2012-10-03  5:27           ` H. Peter Anvin

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=506DFA41.3080803@zytor.com \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg@redhat.com \
    --cc=rwright@hp.com \
    --cc=tmac@hp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.