Date: Tue, 5 Aug 2008 11:42:56 -0700 (PDT)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Karsten Keil <kkeil@suse.de>
cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
       linux-kernel@vger.kernel.org, isdn4linux@listserv.isdn4linux.de,
       "Andreas.Eversberg" <Andreas.Eversberg@versatel.de>
Subject: Re: [PATCH 3/4] Fix remaining big endian issue of hfcmulti
In-Reply-To: <20080805172549.GA6052@pingi.kke.suse.de>
Message-ID: <alpine.LFD.1.10.0808051140250.3257@nehalem.linux-foundation.org>
References: <20080802151532.DE017A3C09@pingi.kke.suse.de> <1217910588.24157.151.camel@pasglop> <20080805113111.GA6827@pingi.kke.suse.de> <1217941466.24157.190.camel@pasglop> <20080805172549.GA6052@pingi.kke.suse.de>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1069
Lines: 26


On Tue, 5 Aug 2008, Karsten Keil wrote:
> 
> Maybe we can use the trick from lib/iomap.c to detect which
> kind of IO is needed, but unfortunately PIO_OFFSET, PIO_MASK and
> PIO_RESERVED are not exported so it would need to copy the defines, which
> isn't a really clean solution.

Even if they were exported, you couldn't.

lib/iomap.c is _not_ generic code. It's a library function for 
architectures that don't do it some other way. But various architectures 
can choose to not use lib/iomap.c at all - for example, they may have MMIO 
and PIO in the same address space, so they don't need the conditionals at 
all (because all the work was done at mapping time, not at runtime).

So if you actually have different models of operation for PIO and MMIO, 
then yes, you need to handle that in the driver itself.

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/