Dear Jason Cooper, On Thu, 15 May 2014 11:31:50 -0400, Jason Cooper wrote: > > > iiuc, this patch depends on 1/3. So how would you like to handle it? > > > > Seems like my long cover letters are not always read in their > > entirety :-) > > It was, the 'u' comes from 'u'nderstanding the coverletter _and_ the > code. ;-) Hehe :-) > One a side note, I should mention I find your detailed coverletters > extremely helpful for getting up to speed quickly on what the intention > of a series is. Even better, the Link tag that's added to the commit > message allows future devs to be three clicks away from that > information. Thanks for setting that standard. Thanks, I appreciate. I intentionally do some efforts to write detailed cover letters, especially for the most complicated topics, I believe it's needed to "sell" the patches to the appropriate maintainers. > Which makes me think, in a lot of cases, it's better to start at the top > of the thread when researching a patch. The Message-Id of the > coverletter is always the first address in the References header. > Perhaps I should link to that instead, or add both. Maybe. In any case, the cover letter is never far away for the patch e-mails, so it isn't that complicated to get back to the cover letter. Sometimes, it's a bit difficult to decide how to balance the information between the cover letter and the commit logs. The explanation in the cover letter has the nice property that it covers the entire patch series, so it's very convenient to explain the overall goal of the patch series, the global architecture of the solution being proposed. But on the other hand, the contents of the cover letter do not become part of the Git history. On the other side, commit logs become part of the Git history (so people are more likely to see them in the future), but are more difficult to use to convey the overall design, since they are only per-patch. > > So the only course of action I see right now is to work with Russell to > > have him pull patches 1 and 2, and then provide a stable branch/tag > > that you can merge as a dependency in whatever branch you decide to > > merge patch 3/3. Would that work? > > Dunno. I have a 100% failure rate getting Russell to create a stable > topic branch to resolve dependencies like these. Unfortunately, I think > the answer is going to be resubmit 3/3 once 3.16-rc1 lands with 1/3 and > 2/3. Let's go for the solution you've chosen: merge PATCH 3/3 of the v4. This one does not have build dependency on PATCH 1/3, and already solves most of the problems: MT_UNCACHED mappings for PCI memory mappings, and avoidance of outer cache sync operations when hardware I/O coherency is used. The only thing that remains to solve is the PCI I/O mappings, but they are a lot less frequently used so it is not as important as the other aspects of the problem. And this aspect can indeed be solved as a followup patch. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
