On Wed, Aug 01, 2018 at 05:33:30PM +0100, Robin Murphy wrote:
> 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.
>
You mean there is now a warning stating that coherent_dma_mask is not set,
but coherent_dma_mask isn't used by sparc32 in the first place ?
Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
