linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Michal Januszewski <spock@gentoo.org>,
	linux-fbdev@vger.kernel.org, x86@kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Wang YanQing <udknight@gmail.com>
Subject: Re: [PATCH] x86: export 'pcibios_enabled'
Date: Wed, 14 Mar 2012 11:21:37 +0000	[thread overview]
Message-ID: <20120314112137.68fa4f70@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <4F607A18.8080004@gmx.de>

> > uvesafb could look for any PCI vga class device - which I suspect is
> > what it *should* be doing ?
> 
> Would this really change depending on whether the page is NX-protected
> or not?
> Your suggestion sounds like it is about detecting whether there is any
> graphic chip present or not while the patch is about fixing an oops
> caused by NX-protection of the BIOS.

Right yes.. I misunderstood what you are trying to do. I'd assumed you
wanted to find the ROM and thus set it to the right mapping mode.

You can use set_memory_x() to mark memory executable (and _nx to set it back).

If you really need to know if NX is being used then the check

	if (__supported_pte_mask & PTE_NX)

will do the trick and the variable is exported.

I'd suggest however you wrap that in a cpu_has_nx() type macro somewhere
in the arch headers.

If you go poking around pcibios values you are going to get burned if
someone is ever bored enough to make NX and PCIBIOS work together
differently.

Alan

  reply	other threads:[~2012-03-14 11:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-13  9:41 linux-next: Tree for Mar 13 Stephen Rothwell
2012-03-13 17:10 ` linux-next: Tree for Mar 13 (dlm / gfs2) Randy Dunlap
2012-03-13 20:30 ` [PATCH] x86: export 'pcibios_enabled' Randy Dunlap
2012-03-14  0:43   ` H. Peter Anvin
2012-03-14  9:29     ` Alan Cox
2012-03-14 10:59       ` Florian Tobias Schandinat
2012-03-14 11:21         ` Alan Cox [this message]
2012-03-22  0:41           ` Wang YanQing
2012-03-26  0:27             ` Wang YanQing
2012-03-16  0:41     ` Wang YanQing
2012-03-19  0:30   ` Wang YanQing
2012-03-19  1:03     ` [PATCH v2] x86: export 'pcibios_enabled' as GPL Randy Dunlap
2012-03-21  4:37       ` Wang YanQing
2012-03-21  9:29         ` Alan Cox
2012-03-13 21:06 ` linux-next: Tree for Mar 13 (ata) Randy Dunlap
2012-03-13 21:22   ` Jeff Garzik
2012-03-14  0:36     ` Dan Williams

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=20120314112137.68fa4f70@pyramind.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=FlorianSchandinat@gmx.de \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=sfr@canb.auug.org.au \
    --cc=spock@gentoo.org \
    --cc=udknight@gmail.com \
    --cc=x86@kernel.org \
    /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).