[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170710142455.Horde.1omqcjm0Viv_2slRPRXktZa@gator4166.hostgator.com>
Date: Mon, 10 Jul 2017 14:24:55 -0500
From: "Gustavo A. R. Silva" <garsilva@...eddedor.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Thierry Reding <thierry.reding@...il.com>,
Jon Hunter <jonathanh@...dia.com>,
Rakesh Iyer <riyer@...dia.com>,
Laxman Dewangan <ldewangan@...dia.com>,
linux-input@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] input: tegra-kbc: add NULL check on of_match_device()
return value
Hi all,
Quoting Dmitry Torokhov <dmitry.torokhov@...il.com>:
> On Fri, Jul 07, 2017 at 11:30:41AM +0200, Thierry Reding wrote:
>> On Fri, Jul 07, 2017 at 08:42:32AM +0100, Jon Hunter wrote:
>> >
>> > On 07/07/17 07:27, Gustavo A. R. Silva wrote:
>> > > Check return value from call to of_match_device()
>> > > in order to prevent a NULL pointer dereference.
>> > >
>> > > In case of NULL print error message and return -ENODEV
>> > >
>> > > Signed-off-by: Gustavo A. R. Silva <garsilva@...eddedor.com>
>> > > ---
>> > > drivers/input/keyboard/tegra-kbc.c | 4 ++++
>> > > 1 file changed, 4 insertions(+)
>> > >
>> > > diff --git a/drivers/input/keyboard/tegra-kbc.c
>> b/drivers/input/keyboard/tegra-kbc.c
>> > > index 0c07e10..742c5ac 100644
>> > > --- a/drivers/input/keyboard/tegra-kbc.c
>> > > +++ b/drivers/input/keyboard/tegra-kbc.c
>> > > @@ -617,6 +617,10 @@ static int tegra_kbc_probe(struct
>> platform_device *pdev)
>> > > const struct of_device_id *match;
>> > >
>> > > match = of_match_device(tegra_kbc_of_match, &pdev->dev);
>> > > + if (!match) {
>> > > + dev_err(&pdev->dev, "failed to match device\n");
>> > > + return -ENODEV;
>> > > + }
>> >
>> > Given that Tegra always uses device-tree, I believe that this cannot
>> > happen and so this additional check is not needed.
>>
>> I think you can make it happen if you manually create the platform
>> device with a name matching that of the driver. But you really shouldn't
>> be doing that, so might as well let it crash and burn so that people
>> realize their mistake early.
>>
>> Errors are easily overlooked, crashes are not.
>
> Agree.
>
I get it.
Thanks for clarifying.
--
Gustavo A. R. Silva
Powered by blists - more mailing lists