Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765489AbYHEVXi (ORCPT ); Tue, 5 Aug 2008 17:23:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1763625AbYHEVX1 (ORCPT ); Tue, 5 Aug 2008 17:23:27 -0400 Received: from toronto-hs-216-138-233-67.s-ip.magma.ca ([216.138.233.67]:33981 "HELO yow.seanm.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1765401AbYHEVX0 (ORCPT ); Tue, 5 Aug 2008 17:23:26 -0400 Date: Tue, 5 Aug 2008 17:23:24 -0400 From: Sean MacLennan To: "Karsten Keil" Cc: "Linus Torvalds" , "Benjamin Herrenschmidt" , "Andreas.Eversberg" , , Subject: Re: [PATCH 3/4] Fix remaining big endian issue of hfcmulti Message-ID: <20080805172324.45853d98@lappy.seanm.ca> In-Reply-To: <20080805210239.GB6052@pingi.kke.suse.de> 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> <20080805210239.GB6052@pingi.kke.suse.de> Organization: PIKA X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.9; i686-pc-linux-gnu) X-Message-Flag: Warning: This message may contain actual content. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1723 Lines: 51 On Tue, 5 Aug 2008 23:02:39 +0200 "Karsten Keil" wrote: > On Tue, Aug 05, 2008 at 11:42:56AM -0700, Linus Torvalds wrote: > > > > > > 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. > > > > One question here, what is the better approach to do such a different > implementation, use one local function like > > static void > my_out32(struct card *c, u_int offset, u-int data) > { > if (c->mode == MMIO) { > ... > } else { > ... > } > } > > or use 2 function, one for the MMIO and one for the PIO model and > then use indirect calls (like c->my_out32(...)) ? Why not select PIO or MMIO at config time? Cheers, Sean -- 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/