On Wed, 12 Sep 2018, Alexandre Belloni wrote: > On 11/09/2018 23:43:02+0100, Lee Jones wrote: > > > 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/ We didn't Ack the bindings. We Acked the location change. I mean, has Rob specifically spoken out about using a compatible string for each function. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
