Messages in this thread | | | Date | Tue, 5 Aug 2008 23:02:39 +0200 | From | Karsten Keil <> | Subject | Re: [PATCH 3/4] Fix remaining big endian issue of hfcmulti |
| |
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(...)) ?
-- Karsten Keil SuSE Labs ISDN and VOIP development SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
| |