Dasgupta, Romit had written, on 01/15/2010 08:36 PM, the following:
Returning NULL pointer from the OPP APIs instead of ERR_PTR where
return struct omap_opp *. This is because there is no inherent value in
returning ERR_PTR from the opp layer. Returning NULL serves the purpose.
NAK.
Using ERR_PTR allows returning different types of error conditions,
and is common practice across the kernel.
Yes, it is true that it is a common practice but in case of the OPP layer I did not
see any purpose. The caller of the APIs returning struct omap_opp * can just
check for NULL value for failure.
My initial intention of introducing ERR_PTR had the objective of being
flexible:
I could not predict how each function would develop into - e.g. lists
etc. They may prefer to return error values which could be independently
handled. allow future flexibility. let me illustrate it - now that we
are aligned that we are moving to enums:
The caller does not have an idea if mpu_opps was initialized or not.
opp_find_freq_exact can return: (examples ofcourse)
-EDATA to say that the domain requested was not initialized
or
-EAGAIN once we introduce locks to say that it is locked
(non-blocking implementation)
or
-ERANGE to say that the caller is asking for a frequency beyond the
supported range.
Another example: opp_enable can now return -EEXIST to say that the the
opp was already enabled etc..
The benefit I definitely see is that with an previously placed single
pr_err of the return value by the caller, I can remotely debug an issue
in code instead of having the developer to add printks/use lauterbach to
debug.
ok, I might not have selected the best of return values, but I hope the
idea is clear. NAK from myside too.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
