public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jon Smirl <jonsmirl@gmail.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Greg KH <greg@kroah.com>,
	helgehaf@aitel.hist.no
Subject: Re: Ignore disabled ROM resources at setup
Date: Tue, 30 Aug 2005 00:47:21 -0400	[thread overview]
Message-ID: <9e4733910508292147556a4413@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0508291956210.3243@g5.osdl.org>

On 8/29/05, Linus Torvalds <torvalds@osdl.org> wrote:
> 
> 
> On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote:
> >
> > 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.
> 
> Ehh.. It didn't do anything with the old code either for that case, so
> there's apparently something else also going on.
> 
> It would write the base address, but since it wouldn't _enable_ the ROM
> mapping (only the "non-enabled" case changed by this commit), the end
> result from a hw standpoint should be exactly the same: the ROM isn't
> actually mapped.
> 
> So after pci_assign_resource(), the resource has literally been assigned,
> but that patch should not have mattered in any way whether it was actually
> _enabled_ or not.
> 
> Now, there's clearly a difference. What has always worked is then to do
> 
>         pci_write_config_dword(dev,
>                 PCI_ROM_ADDRESS,
>                 PCI_ROM_ADDRESS_ENABLE | res->start)
> 
> (well, these days you're supposed to use "pcibios_resource_to_bus()" to
> get the start value to write out).
> 
> Much preferable is probably to just enable the resource manually _before_
> calling pci_assign_resource, ie do something like.
> 
>         dev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_ENABLE;
>         pci_assign_resource(dev, PCI_ROM_RESOURCE);
> 
> But yes, if something used to just blindly set PCI_ROM_ADDRESS_ENABLE,
> then that got broken. I grepped for that and didn't see anything like it,
> but I guess people are doing it with the magic constant "1"..

Nothing in the driver tree should be using PCI_ROM_ADDRESS_ENABLE
except drivers/pci/*. Drivers that are still manipulating ROMs
directly should be converted to use the PCI ROM API.

I started to fix these but some of the use is non-obvious. It is best
if the maintainers do it. These files are still directly manipulating
ROMs:

ide/pci/aec62xx.c
ide/pci/cmd64x.c
ide/pci/hpt34x.c
ide/pci/hpt366.c
ide/pci/pdc202xx_new.
ide/pci/pdc202xx_old.c
mtd/maps/pci.c
net/sungem.c
net/sunhme.c
scsi/qla2xxx/qla_init.c
video/console/sticore.c
video/matrox/matroxfb_misc.c
video/sis/sis_main.c

-- 
Jon Smirl
jonsmirl@gmail.com

  reply	other threads:[~2005-08-30  4:47 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 ` Ignore disabled ROM resources at setup Benjamin Herrenschmidt
2005-08-30  3:15   ` Linus Torvalds
2005-08-30  4:47     ` Jon Smirl [this message]
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=9e4733910508292147556a4413@mail.gmail.com \
    --to=jonsmirl@gmail.com \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox