On Mon, 14 Dec 2009 11:11:27 +0100 Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> wrote: > If these functions are obsolete and going to be removed, I don't think it > could be of any importance whether they are modified before removal or not. > Otherwise, a solution seems simple to me: you submit a patch that addresses > all concearns, yours, Tony's (BTW, have you already reviewed the drivers as > Tony suggested?), maybe others. Then, after your patch is accepted for > inclusion and it appears in conflict with this series still not applied for > any reason (possibly waiting for your changes if that decided), Jarkko, or > Tony, or anyone else pointed out by Tony, decides which one goes first and > which is going to be refreshed on top of the other. Does it sound like a good > plan for you? > I would favor the Janusz's set going in first since it will solve and help the in-tree problems without making out-of-tree use any worse than currently. - Fixes register access in polled I/O functions (out-of-tree use) - Fixes McBSP register corruption noted on Amstrad Delta - McBSP register caching could help the PM development Fixing any other issues in polled I/O API belongs to another context than this patch set and IMO is easier to handle after this set since the patch 1/5 already fixes the register access width. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
