All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Smirl <jonsmirl@gmail.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jesse Barnes <jbarnes@sgi.com>, Andrew Morton <akpm@osdl.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] quiet non-x86 option ROM warnings
Date: Thu, 17 Feb 2005 11:33:48 -0500	[thread overview]
Message-ID: <9e473391050217083312685e44@mail.gmail.com> (raw)
In-Reply-To: <1108601294.5426.1.camel@gaston>

On Thu, 17 Feb 2005 11:48:14 +1100, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2005-02-16 at 15:54 -0800, Jesse Barnes wrote:
> > On Tuesday, February 15, 2005 5:03 pm, Benjamin Herrenschmidt wrote:
> > > What about printing "No PCI ROM detected" ? I like having that info when
> > > getting user reports, but I agree that a less worrying message would
> > > be good.
> >
> > Ok, how about this then?  It changes the printks in both drivers to KERN_INFO
> > and describes the situation a bit more accurately.
> >
> > Signed-off-by: Jesse Barnes <jbarnes@sgi.com>
> >
> > Thanks,
> > Jesse
> >
> > P.S. Jon, I think the pci_map_rom code is buggy--if the option ROM signature
> > is missing or indicates that there's no ROM, the routine still returns a
> > valid pointer making the caller thing it succeeded.  If we fix that up we can
> > fix up the callers.
> 
> No, pci_map_rom shouldn't test the signature IMHO. While PCI ROMs should
> have the signature to be recognized as containing valid firmware images
> on x86 BIOSes an OF, it's just a convention on these platforms, and I
> would rather let people put whatever they want in those ROMs and still
> let them map it...
> 

pci_map_rom will return a pointer to any ROM it finds. It the
signature is invalid the size returned will be zero. Is this ok or do
we want it to do something different?

-- 
Jon Smirl
jonsmirl@gmail.com

  reply	other threads:[~2005-02-17 16:34 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-15 23:57 [PATCH] quiet non-x86 option ROM warnings Jesse Barnes
2005-02-16  0:36 ` Jon Smirl
2005-02-16  0:45   ` Jesse Barnes
2005-02-16  1:00     ` Benjamin Herrenschmidt
2005-02-16  1:00     ` Benjamin Herrenschmidt
2005-02-16  1:08       ` Jon Smirl
2005-02-16  1:57         ` Jesse Barnes
2005-02-16  4:00         ` Benjamin Herrenschmidt
2005-02-16  1:03 ` Benjamin Herrenschmidt
2005-02-16 23:54   ` Jesse Barnes
2005-02-17  0:48     ` Benjamin Herrenschmidt
2005-02-17 16:33       ` Jon Smirl [this message]
2005-02-17 17:29         ` Jesse Barnes
2005-02-17 17:32           ` Jon Smirl
2005-02-17 17:41             ` Jesse Barnes
2005-02-17 17:45             ` Jesse Barnes
2005-02-17 17:56               ` Jon Smirl
2005-02-17 22:48                 ` Benjamin Herrenschmidt
2005-02-17 22:47               ` Benjamin Herrenschmidt
2005-02-17 22:59                 ` Jon Smirl
2005-02-17 23:00                   ` Jesse Barnes
2005-02-17 23:04                   ` Benjamin Herrenschmidt
2005-02-17 23:20                   ` Andrew Vasquez
2005-02-17 22:45         ` Benjamin Herrenschmidt
2005-02-17 22:56           ` Jon Smirl
2005-02-18 12:09             ` Gabriel Paubert
2005-02-18 16:50               ` Jon Smirl
2005-09-04 13:27 ` Olaf Hering
2005-09-04 14:20   ` Andreas Schwab

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=9e473391050217083312685e44@mail.gmail.com \
    --to=jonsmirl@gmail.com \
    --cc=akpm@osdl.org \
    --cc=benh@kernel.crashing.org \
    --cc=jbarnes@sgi.com \
    --cc=linux-kernel@vger.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 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.