2013/8/5 Benson Leung <bleung@xxxxxxxxxxxx>: > Hi Martin, > > Thank you for looking into this problem. Obviously, this is a problem > Olof and our team has been working on as well. Hi Benson, Thank you for spending time reviewing and testing my patch. I understand your team is busy and am honored you took the time to look at my code. > Your driver would result in three failed probes in 2 different drivers > on my board. Yes that is one down-side; sometimes the detect() function will be triggered even though the device is not supported (the return -ENODEV code paths in my driver). I thought that maybe a simpler driver could make up for unnecessary detect() calls. However ... > "Detect" is method #3, but it comes with a > stern warning : Once again, method 3 should be avoided wherever > possible. Explicit device instantiation (methods 1 and 2) is much > preferred for it is safer and faster. ... I must admit I did not see this. I realize that this makes my patch a dead end. I wish I would have seen that earlier, that would have saved time for everyone. My apologies. Regarding the interaction with non-i2c devices in chromeos_laptop, I was thinking that could perhaps have been solved by putting the i2c stuff in a separate driver, say chromeos_laptop_i2c, but that point is irrelevant now that you pointed out that the use of the detect()-method is discouraged by the documentation. Thank you again for reviewing the patch and for providing feedback. BR, Martin -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
