At Mon, 1 Mar 2010 15:18:48 +0100, Daniel Mack wrote:
On Mon, Mar 01, 2010 at 03:06:57PM +0100, Takashi Iwai wrote:
At Mon, 1 Mar 2010 15:01:29 +0100, Daniel Mack wrote:
Ok, will do. However, I wonder which way is best to do that. Given that you posted patches on top of mine, can I take this as a general agreement to my changeset? If so, I will just provide a patch on top to do the ua101 -> misc rename, because otherwise, I would have to rebase all three patches for that.
Well, honestly, I prefer seeing the fixes by Clemens based on the current code, and merge Daniel's refactoring patches after 2.6.34 merge window.
Clemens fixes only make sense for v2 of the USB audio spec, which isn't fully supported yet. IOW, the code as it will go into 2.6.34 is not able to support that, with or without my refactoring. So rebasing them doesn't make sense IMO.
OK, then we can merge them together later.
Refactoring is a good thing but it can easily introduce any careless bugs (like copy&paste error), and this split action makes really hard to track the changes. Thus I'd like to keep this well ripened before reaching to the Linus tree, not only for a few days.
Yes, certainly. I didn't expect that to be taken for .34.
Good that we agree :)
I would be fine with having it in a branch on your side, and getting it merged to your for-next after any .34 issues are sorted out.
There will be quite some more patches to fully support the most common features, but they won't be as intrusive and big of course.
Fair enough.
thanks,
Takashi