On 2017-07-09 01:12, Kuppuswamy, Sathyanarayanan wrote: > Hi Peter, > > > On 7/8/2017 2:00 PM, Peter Rosin wrote: >> On 2017-07-07 23:46, sathyanarayanan.kuppusw...@linux.intel.com wrote: >>> From: Kuppuswamy Sathyanarayanan >>> <sathyanarayanan.kuppusw...@linux.intel.com> >>> >>> If dev->of_node is NULL, then calling mux_control_get() >>> function can lead to NULL pointer exception. So adding >>> a NULL check for dev->of_node. >>> >>> Signed-off-by: Kuppuswamy Sathyanarayanan >>> <sathyanarayanan.kuppusw...@linux.intel.com> >> Do you have a driver that might call mux_control_get and not have any >> of_node? > For non-device tree drivers, this case is valid. I hit this issue when I > was working on Intel USB MUX driver. >> If not, I don't see the point of this check. > Since this is an API for other consumers, I think its better to have > some sanity checks. > > If a non device tree driver call this API , I think its better to fail > with some error no instead of creating null pointer exception.
Is it? When authoring a new driver, and you make some error like this, why is a "nice" error better than a big fat fail? If you get a null deref, you will presumably also get a call stack etc, which will help you find where you made the error, w/o adding a bunch of traces to find out exactly what you did wrong. So, I'm skeptic... Cheers, peda >> >> Cheers, >> peda >> >>> --- >>> drivers/mux/mux-core.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> Changes since v1: >>> * Removed dummy new line. >>> >>> diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c >>> index 90b8995..924c983 100644 >>> --- a/drivers/mux/mux-core.c >>> +++ b/drivers/mux/mux-core.c >>> @@ -438,6 +438,9 @@ struct mux_control *mux_control_get(struct device *dev, >>> const char *mux_name) >>> int index = 0; >>> int ret; >>> >>> + if (!np) >>> + return ERR_PTR(-ENODEV); >>> + >>> if (mux_name) { >>> index = of_property_match_string(np, "mux-control-names", >>> mux_name); >>> >