* Sebastian Reichel <sre@xxxxxxxxxx> [140519 22:13]: > On Mon, May 19, 2014 at 10:05:15PM +0300, Tomi Valkeinen wrote: > > On 19/05/14 19:04, Tony Lindgren wrote: > > > > > In many cases however we do have multiple compatible strings that > > > describe how the device is wired. See drivers/tty/serial/of_serial.c > > > for example. It has "ns16550" but then it also has additional > > > "nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial". > > > > All those sound like SoC components. In that case it sounds fine to have > > the device compatible contain the SoC name. We're talking here about > > external, detachable devices. Yes I agree it's also hackish. But playing with the compatible flags avoids adding other custom workarounds. > > >>> Not use what you're after with the SPI example though, but sounds > > >>> like that's something different. > > >> > > >> I think Sebastien's example is just like the issue here. > > > > > > Hmm is there some existing example in the kernel like that? > > > > No, Sebastien's example was just a hypothetical case. Here, using your > > way of having SoC specific data in the .dts, we would have > > "sharp,ls037v7dw01-omap-dss", and in Sebastien's example with a touch > > sensor we'd have, say, "synaptics,xyz123-omap-spi". > > Yes, that's what I wanted to say :) Hmm I think we need to add few things to the hypothetical SPI case to get it even close to the panel example. Like assume that no SPI bus exists, and that potentially multiple different Synaptics drivers are trying to share the same compatible flag for a non-existing generic binding.. I think then it's getting close to the panel example :) Regards, Tony -- 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
