Re: [PATCH] soc: qcom: update config dependencies for QCOM_RPMPD

[Rajendra Nayak <rnayak@codeaurora.org>]

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