[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200712060434.lB64YUtc023934@po-mbox305.hop.2iij.net>
Date: Thu, 6 Dec 2007 13:34:32 +0900
From: Yoichi Yuasa <yoichi_yuasa@...peaks.co.jp>
To: benh@...nel.crashing.org
Cc: yoichi_yuasa@...peaks.co.jp,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...e.de>, Ralf Baechle <ralf@...ux-mips.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Please revert: PCI: fix IDE legacy mode resources
On Thu, 06 Dec 2007 11:10:18 +1100
Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> The commit below that was merged in october looks bogus to me.
>
> At this stage in the PCI probe, the pci_dev->resource's contain RAW bar
> values, that is bus values..
>
> A PCI legacy IDE controller that hard decodes 0x1f0 etc... does such as
> bus values as well. That is, the resources should contain 0x1f0...0x1f7
> etc... -not- some kind of transformed values, because that's exactly
> what a BAR would contain if it had been read from the device by
> pci_read_bases() and we haven't performed any fixup yet.
>
> If the platform offsets resources, like powerpc does, it should do so
> later on in a fixup pass (on ppc, we use either a header quirk or
> fixup_bus depending on the phase of the moon) and that should work
> fine.
>
> I don't understand how his fix can work on MIPS nor why the previous
> code didn't, but I don't know how MIPS does its remapping tricks,
> however it will definitely -not- work on powerpc (and will break a
> couple of machines out there).
MIPS pcibios_fixup_bus() converts RAW BAR values(including offset) to resource values.
How does it fix up on powerpc?
Yoichi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists