On Mon, Nov 25, 2013 at 3:14 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 11/25/2013 04:09 PM, Dan Williams wrote: >> On Mon, Nov 25, 2013 at 2:30 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: >>> On 11/25/2013 03:09 PM, Arnd Bergmann wrote: >>>> On Monday 25 November 2013 14:53:36 Stephen Warren wrote: >>>>> v2: Use of_dma_slave_xlate() rather than of_dma_simple_xlate(), as >>>>> suggested by Arnd Bergmann. >>>>> >>>>> This patch is part of a series with strong internal depdendencies. I'm >>>>> looking for an ack so that I can take the entire series through the Tegra >>>>> and arm-soc trees. The series will be part of a stable branch that can be >>>>> merged into other subsystems if needed to avoid/resolve dependencies. >>>> >>>> Did I suggest of_dma_slave_xlate()? I don't think I've actually heard >>>> of that function, and I can't find anything in the kernel source or >>>> using google. >>>> >>>> Why not just use an open-coded xlate function? >>> >>> Well, you suggested not using of_dma_simple_xlate() since it wasn't >>> appropriate. I then started to implement an open-coded xlate function, >>> but found that it was 99% identical to the same thing in the mmp driver, >>> and hence created a common of_dma_slave_xlate() so as not to just >>> cut/paste it everywhere. Unfortunately, I only sent that patch to >>> dmaengine@xxxxxxxxxxxxxxx and the DMA maintainers, and there's no >>> archive of that list:-( >> >> There is, however, an archive of the patches: >> >> dma: add common of_dma_slave_xlate() >> https://patchwork.kernel.org/patch/3234751/ >> >> dma: mmp_pdma: use of_dma_slave_xlate() >> https://patchwork.kernel.org/patch/3234761/ > > Ah, that's useful. > >> ..btw I think we should squash those two together. > > Isn't it more typical to do core work in one patch, then port each > driver individually? That keeps the patches small and logically > distinct, which could help bisect in some cases. But I guess I can go > either way. Including a user conversion in the same patch that introduces the api change makes it clear what is going on... for example a reviewer could see that the code comes from mmp_pdma unmolested. Inevitably the first question is always "show me the user". The bisect case is also a good example. Since the api change by itself dead code if we revert the only user we implicitly want to revert the core change. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
