Re: linux-next: manual merge of the slave-dma tree with Linus' tree

From: Vinod Koul
Date: Fri Mar 13 2020 - 08:42:50 EST


On 12-03-20, 09:16, Peter Ujfalusi wrote:
> Hi Stephen, Vinod,
>
> On 12/03/2020 7.26, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the slave-dma tree got a conflict in:
> >
> > drivers/dma/ti/k3-udma.c
> >
> > between commit:
> >
> > 16cd3c670183 ("dmaengine: ti: k3-udma: Workaround for RX teardown with stale data in peer")
> >
> > from Linus' tree
>
> In Linus' tree the drivers/dma/ti/k3-udma.c latest commit is:
> 8390318c04bb ("dmaengine: ti: k3-udma: Fix terminated transfer handling")
>
> git log --oneline drivers/dma/ti/k3-udma.c shows:
> 8390318c04bb dmaengine: ti: k3-udma: Fix terminated transfer handling
> c7450bb211f3 dmaengine: ti: k3-udma: Use the channel direction in pause/resume functions
> 6cf668a4ef82 dmaengine: ti: k3-udma: Use the TR counter helper for slave_sg and cyclic
> a97934071fc3 dmaengine: ti: k3-udma: Move the TR counter calculation to helper function
> 16cd3c670183 dmaengine: ti: k3-udma: Workaround for RX teardown with stale data in peer
> 1c83767c9d41 dmaengine: ti: k3-udma: Use ktime/usleep_range based TX completion check
> 6c0157be02f0 dmaengine: ti: k3-udma: fix spelling mistake "limted" -> "limited"
> d70241913413 dmaengine: ti: k3-udma: Add glue layer for non DMAengine users
> 25dcb5dd7b7c dmaengine: ti: New driver for K3 UDMA
>
> > and commit:
> >
> > db8d9b4c9b30 ("dmaengine: ti: k3-udma: Implement custom dbg_summary_show for debugfs")
>
> However slave-dma's next branch shows the following log for k3-udma.c:
> db8d9b4c9b30 dmaengine: ti: k3-udma: Implement custom dbg_summary_show for debugfs
> 0ebcf1a274c5 dmaengine: ti: k3-udma: Implement support for atype (for virtualization)
> 6c0157be02f0 dmaengine: ti: k3-udma: fix spelling mistake "limted" -> "limited"
> d70241913413 dmaengine: ti: k3-udma: Add glue layer for non DMAengine users
> 25dcb5dd7b7c dmaengine: ti: New driver for K3 UDMA
>
> The 5.6-rc5 patches (1c83767c9d41...8390318c04bb) is not present in slave-dma/next which
> causes the conflict.

Yeah I typically dont merge fixes to next, unless we have a dependency.

> > from the slave-dma tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
>
> I ended up with the exactly same resolution patch when merging dlave-dma/next
> to Linus' tree.

Thanks for confirming.. I will let Linus know about this, I dont think
we need to do much here :)

--
~Vinod