[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54AD5F13.1020107@pengutronix.de>
Date: Wed, 07 Jan 2015 17:30:11 +0100
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Sören Brinkmann <soren.brinkmann@...inx.com>
CC: Kedareswara rao Appana <appana.durga.rao@...inx.com>,
wg@...ndegger.com, michal.simek@...inx.com,
grant.likely@...aro.org, linux-can@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Kedareswara rao Appana <appanad@...inx.com>
Subject: Re: [PATCH v4] can: Convert to runtime_pm
On 01/07/2015 04:58 PM, Sören Brinkmann wrote:
>> I think you have to convert the _remove() function, too. Have a look at
>> the gpio-zynq.c driver:
>>
>>> static int zynq_gpio_remove(struct platform_device *pdev)
>>> {
>>> struct zynq_gpio *gpio = platform_get_drvdata(pdev);
>>>
>>> pm_runtime_get_sync(&pdev->dev);
>>
>> However I don't understand why the get_sync() is here. Maybe Sören can help?
>
> IIRC, the concern was that the remove function may be called while the device is
> runtime suspended. Hence the remove function needs to resume the device since the
> remove function may access the HW.
What about the corresponding runtime_put()? Would some counter be
unbalanced upon device removal?
Without having tested it, unloading and loading, i.e. reloading a CAN
driver is easier than reloading the gpio driver on an average embedded
system. Kedareswara please test your driver with something like:
modprobe; ifconfig up; cansend; ifconfig down; rmmod in a loop.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists