From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: "Yinghai Lu" <yhlu.kernel@gmail.com>
Cc: "Gary Hade" <garyhade@us.ibm.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: boot parameter to avoid expansion ROM memory allocation
Date: Tue, 13 May 2008 15:28:17 -0700 [thread overview]
Message-ID: <200805131528.18252.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <86802c440805131411w1e0c661j93ba1a1854f314d6@mail.gmail.com>
> > There were some lkml/linux-pci visible discussions back in
> > November-December of last year where I floated the idea
> > of making PCI expansion ROM memory non-assignment the default:
> > http://marc.info/?l=linux-kernel&m=119742188215024&w=2
> > http://marc.info/?l=linux-kernel&m=119689499508369&w=2
> > I did not hear any objections so I went ahead and submitted
> > the change which entered mainline at 2.6.25-rc1 but it was
> > sternly evicted last week because of a reported regression
> > that it had caused:
> > http://marc.info/?l=linux-kernel&m=121029093331908&w=2
> > Attachments to http://bugs.freedesktop.org/show_bug.cgi?id=15523
> > indicate that a 2.6.25-rc2 x86_64 kernel was being used.
> >
> > > can we use pci rom in 64 bit kernel?
> >
> > Sorry, not sure if I understand this question. I hope the
> > above answers it.
>
> ok, i think the driver could reload fw in the option rom to reset the
> controlller in pci card.
> i don't think there is other usage for the option rom after OS loaded,
> except option rom contain other run-time code...
On graphics devices it's used for more than just POSTing (in fact POSTing is
the least of its uses these days). The ROM often contains tables describing
the specific hardware configuration of a given board, including output
information, extra supported modes, etc.
On other devices, it can be used to store default settings (this is common for
SCSI cards iirc, though I'm not sure how much Linux drivers use this info).
> so could disable them all, and use pci-quirks to enable that for the
> device/driver need it.
Since it's probably only big systems that really need the extra address space,
I'd rather to the opposite: allocate ROM space by default and let a boot
option avoid it.
Jesse
next prev parent reply other threads:[~2008-05-13 22:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-12 20:57 Gary Hade
2008-05-12 21:43 ` Yinghai Lu
2008-05-12 22:30 ` Gary Hade
2008-05-13 17:48 ` Yinghai Lu
2008-05-13 21:00 ` Gary Hade
2008-05-13 21:11 ` Yinghai Lu
2008-05-13 21:44 ` Yinghai Lu
2008-05-13 22:28 ` Jesse Barnes [this message]
2008-05-13 23:23 ` Yinghai Lu
2008-05-14 0:07 ` Gary Hade
2008-05-14 16:20 ` Gary Hade
2008-05-14 16:58 ` [RFC] which drivers need to map ROM BARs? Jesse Barnes
2008-05-20 17:57 ` [PATCH] PCI: boot parameter to avoid expansion ROM memory allocation Jesse Barnes
2008-05-20 20:00 ` Gary Hade
2008-05-20 20:16 ` Jesse Barnes
2008-05-21 17:29 ` Gary Hade
2008-05-21 17:40 ` Jesse Barnes
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=200805131528.18252.jbarnes@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=garyhade@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=yhlu.kernel@gmail.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
all inboxes | Powered by JetHome®