> > > And, no, I'm not going to try omapzoom stuff, I want it working on > the > > > canonical linux-omap kernel, not some corporate version with god > knows > > > how many hacks. > > > > Your wish. > > I thought debugging and fixing the issue was more important than the > source of the fix !!! > > YES! > You have precisely exposed the problem with TI. > It could not have been formulated in a better way.
Where do you think the lineage of the hardware and software is? Do you believe it just jumped into being in open source? All hardware and software is full of deliberate design and hacks. Its true cooperate design constraints are driven by the bottom line and for some in open source it is not. If I look at this particular MUSB hardware/software stack I know it's a mix of purest work, semi-pure (sponsored by cooperate), and cooperate. A lot of parties have advanced the technology with different agendas. I've followed it from its start of life in hardware to its current state. One positive bit for this block is most of the parties today are publicly making their work and specifications available. Hopefully with this enablement code will be free to evolve. It would be nice if whatever code was on the main branch was not so frequently broken. Maybe those who are interested in it should work on a branch in the tree and periodically merge back at stable points. Maybe finally merged drivers at kernel.org will server that purpose and the local tree's can be all development. Where we need something working for a customer 'today' we export a tree to do this. ...many strong statements in open source might be grouped as religious, lobbyist, or novice. We all use some mix of these in work. What's your mix on this issue? Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
