Re: [PATCH] Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"

From: Will Deacon
Date: Mon Dec 05 2022 - 09:24:50 EST


On Fri, Dec 02, 2022 at 10:44:37PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Dec 02, 2022 at 05:32:51PM +0100, Greg KH wrote:
> > On Fri, Dec 02, 2022 at 05:27:24PM +0100, Thorsten Leemhuis wrote:
> > > On 02.12.22 17:10, Greg KH wrote:
> > > > On Fri, Dec 02, 2022 at 11:34:30AM +0100, Thorsten Leemhuis wrote:
> > > >> On 02.12.22 11:03, Will Deacon wrote:
> > > >>> On Fri, Dec 02, 2022 at 09:54:05AM +0100, Thorsten Leemhuis wrote:
> > > >>>> On 02.12.22 09:26, Amit Pundir wrote:
> > > >>>>> On Thu, 1 Dec 2022 at 23:15, Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
> > > >>>>>>
> > > >>>>>> On Thu, Dec 01, 2022 at 10:29:39AM +0100, Thorsten Leemhuis wrote:
> > > >>>>>>> Has any progress been made to fix this regression? It afaics is not a
> > > >>>>>>> release critical issue, but well, it still would be nice to get this
> > > >>>>>>> fixed before 6.1 is released.
> > > >>>>>>
> > > >>>>>> The only (nearly) risk-free "fix" for 6.1 would be to revert the commit
> > > >>>>>> that exposed the driver bug. It doesn't fix the actual bug, it only
> > > >>>>>> makes it less likely to happen.
> > > >>>>>>
> > > >>>>>> I like the original commit removing the cache invalidation as it shows
> > > >>>>>> drivers not behaving properly
> > > >>>>
> > > >>>> Yeah, I understand that, but I guess it's my job to ask at this point:
> > > >>>> "is continuing to live with the old behavior for one or two more cycles"
> > > >>>> that much of a problem"?
> > > >>>
> > > >>> That wouldn't be a problem. The problem is that I haven't see any efforts
> > > >>> from the Qualcomm side to actually fix the drivers [...]
> > > >>
> > > >> Thx for sharing the details. I can fully understand your pain. But well,
> > > >> in the end it looks to me like this commit it intentionally breaking
> > > >> something that used to work -- which to my understanding of the "no
> > > >> regression rule" is not okay, even if things only worked by chance and
> > > >> not flawless.
> > > >
> > > > "no regressions" for userspace code, this is broken, out-of-tree driver
> > > > code, right?
> > >
> > > If so: apologies. But that's not the impression I got, as Amit wrote "I
> > > can reproduce this crash on vanilla v6.1-rc1 as well with no out-of-tree
> > > drivers." here:
> > > https://lore.kernel.org/linux-arm-kernel/CAMi1Hd3H2k1J8hJ6e-Miy5+nVDNzv6qQ3nN-9929B0GbHJkXEg@xxxxxxxxxxxxxx/
> >
> > Ah, I missed that.
> >
> > Ok, what in-tree drivers are having problems being buggy? I can't seem
> > to figure that out from that report at all. Does anyone know?
> >
>
> It is the Qualcomm Q6V5_MSS remoteproc driver:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/qcom_q6v5_mss.c
>
> Qualcomm is working on the fix but the patches are not ready yet. So if we can
> get this patch reverted in the meantime, that would be helpful.

It's good to hear that you're working to fix this, even if it's happening
behind closed doors. Do you have a rough idea how soon you'll be able to
post the remoteproc driver fixes? That would help us to figure out when
to bring back the change if we were to revert it.

Cheers,

Will