Re: Order in "compatibility" DT property ignored by a platform bus

[Rob Herring]

On Tue, Jan 02, 2018 at 10:19:42AM +0100, RafaÅ MiÅecki wrote:
> I was wondering how platform bus handles order of strings in the
> "compatibility" property. After reading the code & testing it I
> realized it doesn't.
> 
> The property should store strings ordered from the most specific to
> the most generic. You could expect a more specific string to have a
> priority while matching.
> 
> In platform_match there isn't any magic code for handling that. It
> simply checks if a driver that was passed can support a given device.
> I also did 2 quick tests with:
> 1) compatible = "foo", "bar";
> 2) compatible = "bar", "foo";

Strictly speaking one of these has to be invalid, but I get your point.

> and it each case a foo platform driver was used. It just happened to
> be before bar platform driver on kernel's internal list (both drivers
> were built-in).
> 
> If you compare this with ARM's setup_machine_fdt you will notice that
> one actually looks for the best matching machine code (it's handled
> with the __of_match_node).
> 
> Am I correct understanding this isn't a proper behavior? 

Yes. The current state is that multiple drivers matching is not 
supported (or undefined behavior).

> Are there any
> plans fixing this?

Not that I'm aware of. I think it should really only be a problem when 
you have a generic driver and then a device specific driver. It seems to 
be a rare enough problem that no one has bothered to fix it for years.

It gets more complicated because what happens in the 2nd case if driver 
foo is built-in and driver bar is loaded later?

Rob