On 11/09/2018 23:43:02+0100, Lee Jones wrote:

quoted

I haven't read it, but I believe it's not unlike Renesas SCIF, which is
served by both drivers/tty/serial/sh-sci.c and drivers/spi/spi-sh-sci.c.
But the latter is not used from DT, so we haven't experienced (and solved)
the similar issue yet.

Would it work if the UART driver and SPI driver would match against the
same compatible value, but the UART driver would do in its probe()
function:

    device_property_read_u32(&pdev->dev, "atmel,usart-mode", &opmode);
    if (opmode != AT91_USART_MODE_SERIAL)
        return ENODEV;

while the SPI driver would do:

    device_property_read_u32(&pdev->dev, "atmel,usart-mode", &opmode);
    if (opmode != AT91_USART_MODE_SPI)
        return ENODEV;

? No MFD driver involved.

I haven't looked at the code in a while, but if memory serves I
believe platform code gives up once it has found its first match, so
by doing this, one of the drivers will never be matched/probed.

It's midnight here, so cracking out the datasheet isn't going to
happen just now, but it's my current belief that if the IP serves 2
very different modes of operation, even if the registers are in a
shared space, they could have their own compatible strings in DT.

That is what the MFD driver provides after all.  Why would it be okay
to allocate different compatible strings from the MFD, but not in the
Device Tree?

It would be the easiest solution.

Has Rob commented on this yet?

V4 of the bindings were acked by Rob and you:
https://patchwork.kernel.org/patch/10428087/


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com