[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <864348fb-3d06-7b4b-cc82-17c96b7ce219@codeaurora.org>
Date: Tue, 22 Jan 2019 15:24:04 +0530
From: Rajendra Nayak <rnayak@...eaurora.org>
To: Guenter Roeck <linux@...ck-us.net>,
Stephen Boyd <swboyd@...omium.org>, andy.gross@...aro.org,
david.brown@...aro.org
Cc: linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
Viresh Kumar <viresh.kumar@...aro.org>,
Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH] soc: qcom: update config dependencies for QCOM_RPMPD
Adding Viresh and Ulf to this thread,
On 1/22/2019 10:38 AM, Guenter Roeck wrote:
> On 1/21/19 6:30 PM, Rajendra Nayak wrote:
>>
>>
>> On 1/18/2019 11:09 PM, Stephen Boyd wrote:
>>> Quoting Rajendra Nayak (2019-01-17 20:48:01)
>>>> drivers/soc/qcom/Kconfig | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>>>> index a5d5167c3f16..1ee298f6bf17 100644
>>>> --- a/drivers/soc/qcom/Kconfig
>>>> +++ b/drivers/soc/qcom/Kconfig
>>>> @@ -109,7 +109,7 @@ config QCOM_RPMHPD
>>>> config QCOM_RPMPD
>>>> bool "Qualcomm RPM Power domain driver"
>>>
>>> Just curious, does it need to be bool for some reason?
>>
>> Here's the link to the discussion around it on the v3 patchset of this series
>> https://lkml.org/lkml/2018/6/12/111
>>
>
> I think you were missing the implication of "if possible", the implication
> being that the driver can now not be used in a multi-platform image, and that
> having a bool driver depend on tristate drivers doesn't make much if any sense.
Fair enough, I hadn't thought about the implications with multi platform builds,
I guess it makes sense to have these drivers as tristate then.
I was doing some quick testing by adding the calls to of_genpd_remove_last() as
suggested by Ulf for cleaning up the genpd registrations, and I run into this
backtrace when the driver re-probes followed by a remove
[ 59.204525] kobject ((____ptrval____)): tried to init an initialized object, something is seriously wr.
[ 59.214262] CPU: 3 PID: 1600 Comm: sh Not tainted 5.0.0-rc1-00012-g0513915837c5-dirty #32
[ 59.222500] Hardware name: Qualcomm Technologies, Inc. SDM845 MTP (DT)
[ 59.229081] Call trace:
[ 59.231574] dump_backtrace+0x0/0x148
[ 59.235276] show_stack+0x14/0x20
[ 59.238631] dump_stack+0x8c/0xac
[ 59.241980] kobject_init+0x8c/0xa0
[ 59.245506] device_initialize+0x34/0xc8
[ 59.249474] pm_genpd_init+0x170/0x260
[ 59.253261] rpmhpd_probe+0x194/0x2b0
[ 59.256966] platform_drv_probe+0x4c/0xa8
[ 59.261011] really_probe+0x1e4/0x2c8
[ 59.264711] driver_probe_device+0x58/0x10
[ 59.268927] bind_store+0xdc/0x178
[ 59.272356] drv_attr_store+0x20/0x30
[ 59.276061] sysfs_kf_write+0x48/0x58
[ 59.279760] kernfs_fop_write+0xcc/0x1c8
[ 59.283728] __vfs_write+0x34/0x170
[ 59.287245] vfs_write+0xa8/0x1b8
[ 59.290592] ksys_write+0x5c/0xc8
[ 59.293941] __arm64_sys_write+0x14/0x20
[ 59.297897] el0_svc_common+0xb4/0x118
[ 59.301676] el0_svc_handler+0x2c/0x80
[ 59.305455] el0_svc+0x8/0xc
Viresh/Ulf, looks like we need some cleanup of whats done by device_initialize()
in pm_genpd_init() to happen as part of the pm_genpd_remove()?
>
> The argument in the exchange is odd - one can not remove any driver as long
> there are client drivers / devices attached to it. This is true for all
> drivers, not just for this one, and handled quite nicely by the driver core.
> Just run "lsmod" and try to remove a driver with any attached users.
>
> Guenter
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Powered by blists - more mailing lists