On Wed, Sep 1, 2010 at 9:27 AM, David Miller <da...@davemloft.net> wrote: > From: Grant Likely <grant.lik...@secretlab.ca> > Date: Wed, 1 Sep 2010 08:42:49 -0600 > >> It seems to me that phylib is one of the cases where the users (the >> network drivers) don't actually care about the specific error code >> when calling phylib functions. The drivers only seem to care whether >> or not the function failed, and if it did then bail out. I've also >> noticed that using the "if (!ptr)" test on phylib return values is a >> common error for driver writers. >> >> In the interest of making driver code easier to write and review, >> would you be opposed to a set of patches to remove the ERR_PTR() >> pattern from phylib and its users? > > I'm opposed to it because it means that if code actually does > care about the error code it will no longer be able to obtain > it.
The error codes in phylib are almost arbitrary and don't really give enough information about where the a failure lies. dev_err() is more useful for debugging. My experience has been that the encoding of error numbers into a pointer return is a source of bugs for driver writers and should be strongly avoided unless the return codes are actually important (ie. userspace depends on them). Especially so when the use-case for keeping them is merely theoretical. I've looked through the phylib usage for ERR_PTR(), and it all is related to whether or not a phy_device pointer can be located. The error code is pretty much irrelevant if a phy cannot be obtained. How about this as a compromise: I'll investigate all the users of phylib and if I find even one situation where the specific return code is actually important to a driver, then I'll back off. phylib has been around for 5 years now which should be enough time for that use case to bubble to the surface. g. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
