Re: [PATCH 3/4] Fix remaining big endian issue of hfcmulti

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> 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.