mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Kuppuswamy, Sathyanarayanan" <sathyaosid@gmail.com>
To: Peter Rosin <peda@axentia.se>,
	sathyanarayanan.kuppuswamy@linux.intel.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] mux: mux-core: Add NULL check for dev->of_node
Date: Sun, 9 Jul 2017 00:35:45 -0700	[thread overview]
Message-ID: <27cdacb6-b775-f678-9ff0-6a3f2ad11e17@gmail.com> (raw)
In-Reply-To: <591290e2-5c63-52c2-b5a3-5417bc16dc27@axentia.se>

Hi,


On 7/9/2017 12:07 AM, Peter Rosin wrote:
> 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.kuppuswamy@linux.intel.com wrote:
>>>> From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@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.kuppuswamy@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.
In this case, I think the error can happen even if there is any 
configuration mismatch in device tree blob. So its not only
about API usage in driver. If you think that you need to fail the system 
if the API is used without proper dt node configuration,
  then we should use something like BUG or WARN_ON to explicitly mention 
this dependency.  But I think its better to
leave this decision to the MUX consumers because there use cases where 
MUX control can be optional
>
> 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);
>>>>

  reply	other threads:[~2017-07-09  7:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-07 21:46 sathyanarayanan.kuppuswamy
2017-07-08 21:00 ` Peter Rosin
2017-07-08 23:12   ` Kuppuswamy, Sathyanarayanan
2017-07-09  7:07     ` Peter Rosin
2017-07-09  7:35       ` Kuppuswamy, Sathyanarayanan [this message]
2017-07-10  7:40         ` Peter Rosin
2017-07-10 21:36           ` sathyanarayanan kuppuswamy
2017-07-12  9:14             ` Peter Rosin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27cdacb6-b775-f678-9ff0-6a3f2ad11e17@gmail.com \
    --to=sathyaosid@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peda@axentia.se \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®