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
