* Jarkko Nikula <jhnikula@xxxxxxxxx> [091214 03:12]: > 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. Sounds good to me. Tony -- 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
