[cc'ing Linus: This is fix for a 2.6.39 regression, so just a heads up that I'll be sending you a pull req ASAP (later this morning)] On Wed, May 18, 2011 at 9:41 AM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > On Wed, May 18, 2011 at 9:27 AM, Milton Miller <miltonm@xxxxxxx> wrote: >> If two drivers are probing devices at the same time, both will write >> their match table result to the dev->of_match cache at the same time. >> >> Only write the result if the device matches. >> >> In a thread titled "SBus devices sometimes detected, sometimes not", >> Meelis reported his SBus hme was not detected about 50% of the time. >> From the debug suggested by Grant it was obvious another driver matched >> some devices between the call to match the hme and the hme discovery >> failling. >> >> Reported-by: Meelis Roos <mroos@xxxxxxxx> >> Signed-off-by: Milton Miller <miltonm@xxxxxxx> >> --- >> >> Grant, I really think this of_match cache in the device node is bad a >> bad tradeoff, and am willing to submit patches to remove it for 2.6.40. >> It is only used by about 26 drivers and all use it once during probe >> to fill out their driver data. It comes at the cost of a long for >> every struct device in every system. > > Ah, bugger. I had /thought/ that matching and probing were kept > together with a mutex. So, yes, this is bad and the of_match needs to > be removed. Thanks for volunteering to submit the patch. It should > be backported to 2.6.39 too. > >> I'll even offer to throw in a patch to cache the parsing of the >> compatible property to speed up of_device_is_compatible if needed. > > That would be useful. :-) > > I'll pick up your patch right now and fire it off to Linus. ... it's not perfect since it will break some theoretical drivers unbind/rebind use-cases, but I cannot think of any actual examples, and it is far safer than the current code. Regardless, the removal of of_match will definitely need to go into stable when it is ready. g. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
