>>>>> On Tue, 17 Jan 2006 13:51:45 +0000, Ralf Baechle <firstname.lastname@example.org>
>> This include the iomap.c, which is not accepted by Ralf.
ralf> Yes - and the reasons are archived on this list. Reposting the
ralf> patch leaves me entirely unimpressed.
Ralf, is this the reason?
> Subject: Re: MIPS - 64bit woes
> From: Ralf Baechle <email@example.com>
> Date: Fri, 18 Nov 2005 17:29:48 +0000
> No. It's broken for machines with multiple PCI busses and I've explicitly
> rejected the patch which is in kernel.org before.
It seems a bit obscured for me --- and perhaps for some other people.
So I asked:
> Subject: mips iomap.c (Was: Re: MIPS - 64bit woes)
> From: Atsushi Nemoto <firstname.lastname@example.org>
> Date: Sun, 20 Nov 2005 02:36:41 +0900 (JST)
> Could you explain a bit _how_ broken current kernel.org's
> arch/mips/lib/iomap.c ? Is it a single mips_io_port_base issue?
> I suppose it works as well as traditional way (request_region +
> in[bwl] for IO resource, request_mem_region + iomap + read[bwl] for
> MEM resource).
> I think it is better than generic iomap.c (except that
> ioremap_cacheable_cow which is not available for R3000 is used).
But got no response at that time. So I ask again. Could you tell us
how the iomap patch broken verbosely, please?