On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt <[email protected]> wrote: > On Wed, 2013-02-06 at 10:14 +0000, Grant Likely wrote: >> >> Huh? That makes no sense. This device out in the wild with both big >> and little endian bus attachments. You can argue all day that one of >> them is wrong, but it doesn't matter. It exists, is used, and must be >> supported. > > No. That's where you are VERY wrong. We don't have to support crap and > arguably shouldn't if that can give an incentive to vendors to fix their > stuff. If you don't believe me, ask Linus :-)
As far as horrible hardware goes, this device comes no where close to some of the stuff I've worked on. The driver is self contained. It doesn't have any nasty hooks into the rest of the kernel and most importantly it currently *works* and is used. >> In fact, the driver already knows about this and figures >> out at runtime how the device is wired up to the bus. This is not the >> problem. > > Except that this is very gross, especially when you observe that in the > busted "big endian" case, it has to byteswap the bloody data port. > > So you end up having to do that gross hack with separate accessors for > registers vs. data and not able to use the _rep variants, which also > means that on platforms like ppc, you end up with a memory barrier on > every access (or more), which is going to slow things down enormously. I don't see why the _rep variants aren't usable here. The only reason I didn't use them when I wrote the driver in the first place was I was a n00b kernel hacker and I didn't know they were there. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
