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
