From: Guenter Roeck <linux@roeck-us.net>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Samuel Ortiz <sameo@linux.intel.com>,
Lee Jones <lee.jones@linaro.org>,
Wim Van Sebroeck <wim@iguana.be>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v2 3/8] watchdog: at91rm9200: use the regmap from mfd
Date: Sat, 10 Jan 2015 17:14:00 -0800 [thread overview]
Message-ID: <54B1CE58.4040407@roeck-us.net> (raw)
In-Reply-To: <20150110184146.GH2447@piout.net>
On 01/10/2015 10:41 AM, Alexandre Belloni wrote:
> On 09/01/2015 at 16:39:21 -0800, Guenter Roeck wrote :
>> On 01/09/2015 01:51 AM, Alexandre Belloni wrote:
>>> /* ......................................................................... */
>>> @@ -204,6 +201,7 @@ static struct miscdevice at91wdt_miscdev = {
>>> static int at91wdt_probe(struct platform_device *pdev)
>>> {
>>> int res;
>>> + regmap_st = dev_get_drvdata(pdev->dev.parent);
>>>
>>
>> Is it guaranteed that parent is never NULL, and that the parent's
>> drvdata is always set ?
>>
>
> The only way to probe the driver left is to use platform_data. It is
> done from the MFD driver. If you prefer, I can test for NULL here and
> return.
>
I am fine if you are sure about that. The problem though is still the
check for double instantiation. Either the driver can not be instantiated
multiple times, and the check is no longer necessary, or it can, meaning
there must be some other means to instantiate it besides through the
mfd driver. And in that case you don't necessarily know if platform_data
is set.
>> Also, it seems that regmap_st will be overwritten if the device
>> is already open (see code below). That may not be a good idea.
>>
>
> I'm not sure what you meani, pdev->dev.parent and at91wdt_miscdev.parent
> are not the same thing. I didn't touch the code below but I believe
> there is no reason to pass in the probe twice and return -EBUSY.
>
Not sure I understand what my comment has to do with 'parent'.
The fact that the code checks if it has already been instantiated
suggests that the original author of the driver was concerned about
that case. Since you did not remove that check I have to assume that
this can still happen. If so, the second instantiation attempt will
overwrite regmap_st, since that variable is written prior to checking
for the dual instantiation.
Guenter
next prev parent reply other threads:[~2015-01-11 1:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 9:51 [PATCH v2 0/8] Atmel System Timer cleanups Alexandre Belloni
2015-01-09 9:51 ` [PATCH v2 1/8] ARM: at91/dt: declare atmel,at91rm9200-st as a syscon Alexandre Belloni
2015-01-09 9:51 ` [PATCH v2 2/8] mfd: Add atmel-st driver Alexandre Belloni
2015-01-09 9:51 ` [PATCH v2 3/8] watchdog: at91rm9200: use the regmap from mfd Alexandre Belloni
2015-01-10 0:39 ` Guenter Roeck
2015-01-10 18:41 ` Alexandre Belloni
2015-01-11 1:14 ` Guenter Roeck [this message]
2015-01-12 14:08 ` Alexandre Belloni
2015-01-09 9:51 ` [PATCH v2 4/8] ARM: at91: time: move the system timer driver to drivers/clocksource Alexandre Belloni
2015-01-09 9:51 ` [PATCH v2 5/8] ARM: at91: move the restart function to the system timer driver Alexandre Belloni
2015-01-09 9:51 ` [PATCH v2 6/8] clocksource: atmel-st: properly initialize driver Alexandre Belloni
2015-01-09 9:51 ` [PATCH v2 7/8] clocksource: atmel-st: use syscon/regmap Alexandre Belloni
2015-01-09 9:51 ` [PATCH v2 8/8] ARM: at91: remove useless include Alexandre Belloni
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=54B1CE58.4040407@roeck-us.net \
--to=linux@roeck-us.net \
--cc=alexandre.belloni@free-electrons.com \
--cc=boris.brezillon@free-electrons.com \
--cc=daniel.lezcano@linaro.org \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=nicolas.ferre@atmel.com \
--cc=plagnioj@jcrosoft.com \
--cc=sameo@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=wim@iguana.be \
/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