[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1206502750.10573.12.camel@pasglop>
Date: Wed, 26 Mar 2008 14:39:10 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Thomas Meyer <thomas@...3r.de>, Ingo Molnar <mingo@...e.hu>,
Stefan Richter <stefanr@...6.in-berlin.de>,
Thomas Gleixner <tglx@...utronix.de>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
"Rafael J. Wysocki" <rjw@...k.pl>,
LKML <linux-kernel@...r.kernel.org>,
Adrian Bunk <bunk@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Natalie Protasevich <protasnb@...il.com>
Subject: Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported
regressions from 2.6.24)
On Mon, 2008-03-24 at 13:47 -0700, Linus Torvalds wrote:
>
> On Mon, 24 Mar 2008, Thomas Meyer wrote:
> > Ingo Molnar schrieb:
> > >
> > > the bootlog should have such entries:
> > >
> > > ioremap: 0x12340000(0x00001000) => 0x12340000
> > >
> > > near the ohci1394 initialization messages.
> >
> > Second try. See attached file.
>
> Hmm. This isn't with my suggested patch, is it?
>
> You are still losing the high 32 bits, and we see:
>
> [ 162.485695] ioremap: 00000000(00000800) => f8978000
> <3>ohci1394: fw-host0: Get PHY Reg timeout [0x00008400/0x00000000/100]
>
> because it's trying to ioremap the resource that is at 0x100000000, and it
> gets truncated to 0x00000000.
>
> I already committed my patch as "obviously correct", so if you're a git
> user, you can just update to current git, but here it is again if you
> missed it and aren't a git person.
Misses your patch (email problems yesterday).
I suggest you merge the one bulk-fixing iomap and then apply your x86
ioremap fixup on top of it, if not too late..
Cheers,
Ben.
> Linus
>
> ---
> commit b9e76a00749521f2b080fa8a4fb15f66538ab756
> Author: Linus Torvalds <torvalds@...ux-foundation.org>
> Date: Mon Mar 24 11:22:39 2008 -0700
>
> x86-32: Pass the full resource data to ioremap()
>
> It appears that 64-bit PCI resources cannot possibly ever have worked on
> x86-32 even when the RESOURCES_64BIT config option was set, because any
> driver that tried to [pci_]ioremap() the resource would have been unable
> to do so because the high 32 bits would have been silently dropped on
> the floor by the ioremap() routines that only used "unsigned long".
>
> Change them to use "resource_size_t" instead, which properly encodes the
> whole 64-bit resource data if RESOURCES_64BIT is enabled.
>
> Acked-by: H. Peter Anvin <hpa@...nel.org>
> Acked-by: Stefan Richter <stefanr@...6.in-berlin.de>
> Cc: Ivan Kokshaysky <ink@...assic.park.msu.ru>
> Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
> ---
> arch/x86/mm/ioremap.c | 6 +++---
> include/asm-x86/io_32.h | 6 +++---
> include/asm-x86/io_64.h | 6 +++---
> lib/iomap.c | 2 +-
> 4 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 8fe576b..4afaba0 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -106,7 +106,7 @@ static int ioremap_change_attr(unsigned long vaddr, unsigned long size,
> * have to convert them into an offset in a page-aligned mapping, but the
> * caller shouldn't need to know that small detail.
> */
> -static void __iomem *__ioremap(unsigned long phys_addr, unsigned long size,
> +static void __iomem *__ioremap(resource_size_t phys_addr, unsigned long size,
> enum ioremap_mode mode)
> {
> unsigned long pfn, offset, last_addr, vaddr;
> @@ -193,13 +193,13 @@ static void __iomem *__ioremap(unsigned long phys_addr, unsigned long size,
> *
> * Must be freed with iounmap.
> */
> -void __iomem *ioremap_nocache(unsigned long phys_addr, unsigned long size)
> +void __iomem *ioremap_nocache(resource_size_t phys_addr, unsigned long size)
> {
> return __ioremap(phys_addr, size, IOR_MODE_UNCACHED);
> }
> EXPORT_SYMBOL(ioremap_nocache);
>
> -void __iomem *ioremap_cache(unsigned long phys_addr, unsigned long size)
> +void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
> {
> return __ioremap(phys_addr, size, IOR_MODE_CACHED);
> }
> diff --git a/include/asm-x86/io_32.h b/include/asm-x86/io_32.h
> index 58d2c45..d4d8fbd 100644
> --- a/include/asm-x86/io_32.h
> +++ b/include/asm-x86/io_32.h
> @@ -114,13 +114,13 @@ static inline void * phys_to_virt(unsigned long address)
> * If the area you are trying to map is a PCI BAR you should have a
> * look at pci_iomap().
> */
> -extern void __iomem *ioremap_nocache(unsigned long offset, unsigned long size);
> -extern void __iomem *ioremap_cache(unsigned long offset, unsigned long size);
> +extern void __iomem *ioremap_nocache(resource_size_t offset, unsigned long size);
> +extern void __iomem *ioremap_cache(resource_size_t offset, unsigned long size);
>
> /*
> * The default ioremap() behavior is non-cached:
> */
> -static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
> +static inline void __iomem *ioremap(resource_size_t offset, unsigned long size)
> {
> return ioremap_nocache(offset, size);
> }
> diff --git a/include/asm-x86/io_64.h b/include/asm-x86/io_64.h
> index f64a59c..db0be20 100644
> --- a/include/asm-x86/io_64.h
> +++ b/include/asm-x86/io_64.h
> @@ -158,13 +158,13 @@ extern void early_iounmap(void *addr, unsigned long size);
> * it's useful if some control registers are in such an area and write combining
> * or read caching is not desirable:
> */
> -extern void __iomem *ioremap_nocache(unsigned long offset, unsigned long size);
> -extern void __iomem *ioremap_cache(unsigned long offset, unsigned long size);
> +extern void __iomem *ioremap_nocache(resource_size_t offset, unsigned long size);
> +extern void __iomem *ioremap_cache(resource_size_t offset, unsigned long size);
>
> /*
> * The default ioremap() behavior is non-cached:
> */
> -static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
> +static inline void __iomem *ioremap(resource_size_t offset, unsigned long size)
> {
> return ioremap_nocache(offset, size);
> }
> diff --git a/lib/iomap.c b/lib/iomap.c
> index db004a9..dd6ca48 100644
> --- a/lib/iomap.c
> +++ b/lib/iomap.c
> @@ -256,7 +256,7 @@ EXPORT_SYMBOL(ioport_unmap);
> * */
> void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
> {
> - unsigned long start = pci_resource_start(dev, bar);
> + resource_size_t start = pci_resource_start(dev, bar);
> unsigned long len = pci_resource_len(dev, bar);
> unsigned long flags = pci_resource_flags(dev, bar);
>
> --
> 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/
--
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