On Thu, Feb 13, 2014 at 01:01:42PM -0600, Rob Herring wrote: > On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao <haokexin@xxxxxxxxx> wrote: > > When the device node do have a compatible property, we definitely > > prefer the compatible match besides the type and name. Only if > > there is no such a match, we then consider the candidate which > > doesn't have compatible entry but do match the type or name with > > the device node. > > > > This is based on a patch from Sebastian Hesselbarth. > > http://patchwork.ozlabs.org/patch/319434/ > > > > I did some code refactoring and also fixed a bug in the original patch. > > I'm inclined to just revert this once again and avoid possibly > breaking yet another platform. > > However, I think I would like to see this structured differently. We > basically have 2 ways of matching: the existing pre-3.14 way and the > desired match on best compatible only. All new bindings should match > with the new way and the old way needs to be kept for compatibility. > So lets structure the code that way. Search the match table first for > best compatible with name and type NULL, then search the table the old > way. I realize it appears you are doing this, but it is not clear this > is the intent of the code. I would like to see this written as a patch > with commit 105353145eafb3ea919 reverted first and you add a new match > function to call first and then fallback to the existing function. OK, I will git it a try. Thanks, Kevin
Attachment:
pgplwFR3YxGg_.pgp
Description: PGP signature
