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/ -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
