From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rajendra Nayak Subject: Re: [PATCH] soc: qcom: update config dependencies for QCOM_RPMPD Date: Tue, 22 Jan 2019 15:24:04 +0530 Message-ID: <864348fb-3d06-7b4b-cc82-17c96b7ce219@codeaurora.org> References: <20190118044801.7312-1-rnayak@codeaurora.org> <154783318835.169631.6614930101893188915@swboyd.mtv.corp.google.com> <25f46403-e78e-271b-c4d0-13b4623846b3@roeck-us.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <25f46403-e78e-271b-c4d0-13b4623846b3@roeck-us.net> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Guenter Roeck , Stephen Boyd , andy.gross@linaro.org, david.brown@linaro.org Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Viresh Kumar , Ulf Hansson List-Id: linux-arm-msm@vger.kernel.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