07:53 <arnd> tmlind: I was trying to look at the dma bug, it's musb_cppi41.c I think, not cppi_dma.c

07:53 <arnd> anyway, I came across this gem:

07:53 <arnd> dma_addr_t *buf = (void *)urb->iso_frame_desc[qh->iso_idx].offset + (u32)urb->transfer_dma;

07:54 <arnd> where 'transfer_dma' is a dma_addr_t, and 'buf' gets passed into another function that takes a dma_addr_t

07:59 <arnd> it's not the bug we are looking for, but it's amazing that this made it through code review multiple times

08:00 <ardb> wow

08:00 <ardb> so buf is a pointer to dma_addr_t??

08:01 <arnd> right, but then it's cast back to a plain 'u32', which is compatible with dma_addr_t

08:02 <arnd> removing all the casts and the extra '*' would make it perfectly readable and not change behavior

08:04 <ardb> :maybe they 'fixed' the code for LPAE?

08:04 <arnd> I think it was just the author being new to C and pointers

08:05 <ardb> perhaps

08:05 <arnd> without the casts it would actually work with LPAE, and build on 64-bit

08:07 <ardb> arnd: so AIUI, we've identified MUSB DMA as the culprit for the latest vmap stack related issue, right?

08:08 <arnd> ardb: I still think it's more likely to be the FT-X serial port driver

08:09 <arnd> the URB buffers get allocated by the USB device driver, mapped by the USB core code, and passed down to musb as dma_addr_t, and from there to the dmaengine

08:09 <ardb> but for a peripheral that is only widely used on ARM but not arm64 or x86?

08:11 <arnd> that's what I was thinking, but then again the musb driver is clearly suspicious, see exhibit #1

08:12 <arnd> if there are no other devices connected to MUSB, they could try printing the DMA address just before it gets passed to the hardware

08:22 <tmlind> arnd: ok musb_cppi41.c sounds right for am335x

08:23 <tmlind> hmm so how come pinephone musb is working

08:23 <tmlind> bbl

08:24 <arnd> tmlind: he did say that it happened only with CAN on FT-X but not another FTDI chip on a different machine. It could be a combination of two bugs

08:24 <arnd> it's just odd that DMA debugging showed no output

08:26 <arnd> eek: buf = phys_to_virt((u32)chdat->dma_addr) + chdat->transfer_len;

08:26 <arnd> that's from tusb6010_omap, so I guess not on this chip, and it's also not this bug, but this is also really bad

08:29 <arnd> if there was a virt_to_phys() in place of dma_map_single(), that would explain how dma-debug missed the problem

08:30 <ardb> indeed

08:30 <ardb> phys_to_virt() OTOH is not likely to be noticed in the absence of highmem or SMMU

08:38 <arnd> FWIW, I created a series to remove virt_to_bus()/bus_to_virt() the other day, these were created originally to allow machines with phys!=bus before we had the dma-mapping interfaces

08:40 <arnd> lots of fun history in there, including a completely obsolete Documentation/core-api/bus-virt-phys-mapping.rst that describes part of the linux-2.0 driver interface and a comment in drivers/scsi/BusLogic.c that complains about being unable to use dma-mapping.h because it lacks a bus_to_virt() replacement

11:25 <mwalle> is anyone aware of recent cma (or maybe dma changes). I'm getting the following splat on the latest next: https://pastebin.com/raw/JY2nFJjT

11:26 <mwalle> I guess the real problem here is the "cma_alloc: reserved: alloc failed". The i2c splat is just a consequence of that

17:27 <HdkR> https://www.phoronix.com/scan.php?page=news_item&px=AmpereOne

17:28 <HdkR> Anyone have any Ampere Computing contacts that I can talk with for getting hardware sampling of AmpereOne? :)

17:30 <HdkR> (Not sarcasm, quite serious. Contact page on their website is just a web form)