lkml.org 
[lkml]   [2019]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] soc: qcom: update config dependencies for QCOM_RPMPD
From
Date
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

\
 
 \ /
  Last update: 2019-01-22 10:54    [W:0.063 / U:10.528 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site