Re: [BUG BISECT] Ethernet fail on VF50 (OF: Don't set default coherent DMA mask)

From: Robin Murphy
Date: Wed Aug 01 2018 - 12:33:36 EST


On 31/07/18 18:38, Guenter Roeck wrote:
On Tue, Jul 31, 2018 at 04:58:41PM +0100, Robin Murphy wrote:
On 31/07/18 16:43, Guenter Roeck wrote:
On Tue, Jul 31, 2018 at 03:09:34PM +0100, Robin Murphy wrote:
Please note that sparc images still generate the warning (next-20180731).

Ugh, OK, any ideas what sparc does to create these platform devices that
isn't of_platform_device_create_pdata() and has somehow grown an implicit
dependency on of_dma_configure() since 4.12? I'm looking, but nothing jumps
out...


I suspect it might be of_device_register(), called from
arch/sparc/kernel/of_device_64.c:scan_one_device()
arch/sparc/kernel/of_device_32.c:scan_one_device()

Right, that's as far as I got as well, so I'm struggling to see how these
things ever got DMA masks set before the of_dma_configure() call moved out
of of_platform_device_create_pdata(), or why it wasn't a problem prior to
the generic dma_ops rework if they didn't :/

Ah, ok. No idea, sorry. All I know is that the messages were first seen
with next-20180727.

OK, I spent this afternoon wrangling toolchains and QEMU to boot an instrumented 4.11 kernel, and the answer is that the warnings are arguably correct. These masks have indeed never been set where they should have been, but then the sbus_dma_ops don't reference them anyway.

The coherent mask WARN_ON *should* have started appearing in 4.16 with 205e1b7f51e4("dma-mapping: warn when there is no coherent_dma_mask"), but happened to be hidden by the inadvertent side-effect of the prior dma_configure() change. Since there's seemingly no actual regression of functionality, I'm inclined to leave this in the hands of whoever cares about sparc32.

Robin.