* Sebastian Reichel [off-list ref] [140519 22:13]:
On Mon, May 19, 2014 at 10:05:15PM +0300, Tomi Valkeinen wrote:
quoted
On 19/05/14 19:04, Tony Lindgren wrote:
quoted
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.
quoted
quoted
quoted
quoted
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