On 02-04-20, 16:28, Linus Torvalds wrote: > On Thu, Apr 2, 2020 at 4:25 AM Vinod Koul <vkoul@xxxxxxxxxx> wrote: > > > > Here are the changes for this cycle. SFR has told me that you might see > > a merge conflict, but I am sure you would be okay with it :) > > It looked trivial enough. That said, it's in the TI_K3_UDMA driver, > which I can't build. The driver is marked as COMPILE_TEST, but it also > has > > depends on TI_SCI_PROTOCOL > depends on TI_SCI_INTA_IRQCHIP > > which means that it depends on TI_MESSAGE_MANAGER, which in turn has a > > depends on ARCH_KEYSTONE || ARCH_K3 > > so it may be *marked* for build testing, but it doesn't actually get > any outside of those builds. > > So I did the resolution that looked trivial, but mistakes happen, and > I can't even build-test that driver.. > > Just a heads-up. It does look like it was _meant_ to be build-tested, > but that intent didn't work out. > > Adding a COMPILE_TEST option to TI_MESSAGE_MANAGER gets things a bit > further, but even then it doesn't actually build that driver because > that TI_SCI_INTA_IRQCHIP dependency needs to be enabled too. > > And that one doesn't even have a question, it's just a plain bool, and > expects to be selected. Which the arm64 platform does. > > Anyway, to make a long story short: "the COMPILE_TEST marker is a lie". Well I do agree to your analysis and would request Peter to fix this. > So somebody should actually test my merge. Said that, I have aarch64 tool chain and was able to conclude that merge looks just fine. I have compile tested the ti-udma driver as well whole of the subsystem Thanks -- ~Vinod
