All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Greg KH <greg@kroah.com>,
	helgehaf@aitel.hist.no, Linus Torvalds <torvalds@osdl.org>
Subject: Re: Ignore disabled ROM resources at setup
Date: Tue, 30 Aug 2005 12:38:04 +1000	[thread overview]
Message-ID: <1125369485.11949.27.camel@gaston> (raw)
In-Reply-To: <200508261859.j7QIxT0I016917@hera.kernel.org>

On Fri, 2005-08-26 at 11:59 -0700, Linux Kernel Mailing List wrote:
> tree d8b7aaaec93de93841b46e8e05a3b454d05bd357
> parent 26aad69e3dd854abe9028ca873fb40b410a39dd7
> author Linus Torvalds <torvalds@g5.osdl.org> Sat, 27 Aug 2005 00:49:22 -0700
> committer Linus Torvalds <torvalds@g5.osdl.org> Sat, 27 Aug 2005 00:49:22 -0700
> 
> Ignore disabled ROM resources at setup
> 
> Writing even a disabled value seems to mess up some matrox graphics
> cards.  It may be a card-related issue, but we may also be writing
> reserved low bits in the result.
> 
> This was a fall-out of switching x86 over to the generic PCI resource
> allocation code, and needs more debugging.  In particular, the old x86
> code defaulted to not doing any resource allocations at all for ROM
> resources.
> 
> In the meantime, this has been reported to make X happier by Helge
> Hafting <helgehaf@aitel.hist.no>.

This "fix" also seems to break all powermac laptops around :( In fact,
it might break any user of pci_map_rom() as it exposes a bug in that
function.

The problem is that their firmware doesn't assign a ROM resource as they
have no ROM on the video chip (like most laptops). radeonfb and aty128fb
among others will call pci_map_rom() to try to find an x86 BIOS ROM with
some config tables in it.

pci_map_rom "sees" that the resource is unassigned by testing the parent
pointer, and calls pci_assign_resource() which, with this new patch,
will do nothing.

Unfortunately, pci_map_rom will not notice this failure, and will
happily ioremap & access the bogus resource, thus causing the crash.
I'll come up with a fix for pci_map_rom later today.

While looking there, I also noticed pci_map_rom_copy() stuff and I'm
surprised it was ever accepted in the tree. While I can understand that
we might need to keep a cached copy of the ROM content (due to cards
like matrox who can't enable both the ROM and the BARs among other
issues), the whole idea of whacking a kernel virtual pointer in the
struct resource->start of the ROM bar is just too disgusting for words
and will probably cause "intersting" side effects in /proc, sysfs and
others... Shouldn't we just have a pointer in pci_dev for the optional
"ROM cache" instead ?

Ben.



       reply	other threads:[~2005-08-30  2:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200508261859.j7QIxT0I016917@hera.kernel.org>
2005-08-30  2:38 ` Benjamin Herrenschmidt [this message]
2005-08-30  3:15   ` Ignore disabled ROM resources at setup Linus Torvalds
2005-08-30  4:47     ` Jon Smirl
2005-08-30  3:19   ` Benjamin Herrenschmidt
2005-08-30  3:52     ` Linus Torvalds
2005-08-30  4:09       ` Linus Torvalds
2005-08-30  4:20         ` David S. Miller
2005-08-30  4:37           ` Benjamin Herrenschmidt
2005-08-30  4:40           ` Linus Torvalds
2005-08-30  4:49             ` Benjamin Herrenschmidt
2005-08-30  5:29               ` Linus Torvalds
2005-08-30  6:46                 ` Benjamin Herrenschmidt
2005-08-31  4:16                 ` Benjamin Herrenschmidt
2005-08-30  4:51             ` Jon Smirl
2005-08-30  4:54               ` Benjamin Herrenschmidt
2005-08-30  5:15               ` Linus Torvalds
2005-08-30 14:39                 ` Alan Cox
2005-08-30 15:29                 ` Petr Vandrovec
2005-08-30  4:33       ` Benjamin Herrenschmidt
2005-08-30  5:03         ` Linus Torvalds
2005-08-30  6:40           ` Benjamin Herrenschmidt
2005-08-30  4:35   ` Jon Smirl
2005-08-30  5:32     ` David S. Miller
2005-08-30  6:43       ` Benjamin Herrenschmidt

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=1125369485.11949.27.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=greg@kroah.com \
    --cc=helgehaf@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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 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.