Messages in this thread | | | Subject | Re: [PATCH 3/4] Fix remaining big endian issue of hfcmulti | From | Benjamin Herrenschmidt <> | Date | Wed, 06 Aug 2008 09:04:18 +1000 |
| |
> But do we really need a generic driver that can do either? Maybe for the > current mISDN driver, but when you get to other chip ports, say the > xhfc, you have to select the low level interface at compile time. Or I > should say you currently have to select at config time.
Which is pretty wrong thing to do. It might work fine for a specific case of an embedded vendor building one ad-hoc kernel for the device, but look at this from the point of view of a linux distribution shipping a generic kernel image & built modules to support any HW out there...
> I'm not arguing that we *have* to do it this way. I just don't think we > should throw out the simplest method without some thought. There is > some precedence for a config time option, for example the 8139too > ethernet driver.
Well, yeah, we made mistakes in the past :-)
If the size of the binary (or performances) involved in doing the two type of IOs in a single driver is such that having the ability to only use one is worth it (for embedded for example), then you can provide a config option that allows to select which method to build in the driver, but it's a good idea to allow building both with runtime detection.
Ben.
| |