lkml.org 
[lkml]   [2018]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Order in "compatibility" DT property ignored by a platform bus
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

\
 
 \ /
  Last update: 2018-01-03 22:30    [W:0.035 / U:2.264 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site