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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 3 Jan 2018 15:29:40 -0600
From:   Rob Herring <robh@...nel.org>
To:     Rafał Miłecki <zajec5@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devicetree@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Brian Norris <computersforpeace@...il.com>
Subject: Re: 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