On Sat, Feb 01, 2014 at 03:56:59PM +0100, Andrew Lunn wrote: > > IMHO, this new series look much better. However, I still think the above code > > is highly confusing (took me some time to see why you don't print the warning > > on PROBE_DEFER, but do the goto in all cases). > > > > Would it be too much to ask to add some comments to it? Your previous > > explanation about why we need to fail on EPROBE_DEFER, to allow the phy > > driver to load, was great. Adding some of that here would be nice. > > Anybody writing device drivers should know about EPROBE_DEFER. If > they don't they are writing broken drivers. So putting in a comment > here would be just pointing out the obvious. > Maybe you're right. It wasn't obvious to me, though. > What i can however do is add a comment that devm_phy_get_optional() > returns a valid phy if there is no error. Might that help with the > confusion? > Well, In don't think devm_phy_get_optional() brings any confusion. The name itself is pretty self-explanatory, and in that case you can always go look at the function implementation and documentation. So, I'd say no. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
