>>>>> On Tue, 17 Jan 2006 13:51:45 +0000, Ralf Baechle <ralf@xxxxxxxxxxxxxx> said: >> 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 <ralf@xxxxxxxxxxxxxx> > 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 <anemo@xxxxxxxxxxxxx> > 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? --- Atsushi Nemoto
