On Tue, 2018-04-17 at 12:03 +0100, Mark Brown wrote: > On Fri, Apr 13, 2018 at 08:12:51PM +0200, Alexandre Belloni wrote: > > On 13/04/2018 19:12:54+0200, Nicolas Ferre wrote: > > > This layout of the hardware is completely different from the > > > USART one and > > > it seems to makes sense to address it with a different hardware > > > description > > > and so a different compatible string. > > But then, you can end up with two drivers trying to use the same IP > > because nothing prevents you from writing a DT with both a usart > > and an > > spi node enabled for the same IP. request_mem_region() will not > > help > > here because then the working driver will depend on the probing > > order. > > We don't really have too much in the way of better ideas for how to > handle this though. Take a look at how the PXA SSP stuff handles > this, > though that's not really doing too much different it at least layers > a > mechanism on top to avoid collisions. Hi Mark, Thank you for suggestions. I followed your advice and looked at PXA SSP driver. In my opinion it is a layer that avoids collsions and unfortunately complicates things a bit. My ideea is to keep the things as simple as possible. For example, I can enhance usart-serial and usart-spi drivers to print detailed messages if probe fails because one driver tries to request a memory region already used by another driver. What do you think? Is this approach a good way to move forward? -- 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
