| Message ID | 1444280468-17159-5-git-send-email-rnayak@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 10/08, Rajendra Nayak wrote: > @@ -3520,11 +3522,26 @@ static int gcc_msm8960_probe(struct platform_device *pdev) > if (IS_ERR(clk)) > return PTR_ERR(clk); > > - return qcom_cc_probe(pdev, match->data); > + ret = qcom_cc_probe(pdev, match->data); > + if (ret) > + return ret; > + > + tsens = platform_device_register_data(&pdev->dev, "qcom-tsens", -1, > + NULL, 0); > + if (IS_ERR(tsens)) { > + qcom_cc_remove(pdev); > + return PTR_ERR(tsens); > + } > + platform_set_drvdata(pdev, tsens); We just blew away the pointer that qcom_cc_probe() stores. > + > + return 0; > } > > static int gcc_msm8960_remove(struct platform_device *pdev) > { > + struct platform_device *tsens = platform_get_drvdata(pdev); > + > + platform_device_unregister(tsens); > qcom_cc_remove(pdev); So now we've leaked the reset controller. I suppose the simplest solution is to get the drvdata pointer after qcom_cc_probe(), allocate a container structure to hold that as a void * plus the tsens device, i.e. struct container { void *data; struct platform_device *tsens; }; and then set the drvdata to that. And finally undo all that and restore the drvdata pointer on remove. I've also been considering putting some devm stuff inside qcom_cc_probe() itself so that in the normal case you don't even need to call qcom_cc_remove(), it just gets done automatically. That would open up the possibility for drivers to use the drvdata member as they wish.
On 10/08/2015 11:35 AM, Stephen Boyd wrote: > On 10/08, Rajendra Nayak wrote: >> @@ -3520,11 +3522,26 @@ static int gcc_msm8960_probe(struct platform_device *pdev) >> if (IS_ERR(clk)) >> return PTR_ERR(clk); >> >> - return qcom_cc_probe(pdev, match->data); >> + ret = qcom_cc_probe(pdev, match->data); >> + if (ret) >> + return ret; >> + >> + tsens = platform_device_register_data(&pdev->dev, "qcom-tsens", -1, >> + NULL, 0); >> + if (IS_ERR(tsens)) { >> + qcom_cc_remove(pdev); >> + return PTR_ERR(tsens); >> + } >> + platform_set_drvdata(pdev, tsens); > > We just blew away the pointer that qcom_cc_probe() stores. Oops, I seem to have completely overlooked that. > >> + >> + return 0; >> } >> >> static int gcc_msm8960_remove(struct platform_device *pdev) >> { >> + struct platform_device *tsens = platform_get_drvdata(pdev); >> + >> + platform_device_unregister(tsens); >> qcom_cc_remove(pdev); > > So now we've leaked the reset controller. > > I suppose the simplest solution is to get the drvdata pointer > after qcom_cc_probe(), allocate a container structure to hold > that as a void * plus the tsens device, i.e. > > struct container { > void *data; > struct platform_device *tsens; > }; > > and then set the drvdata to that. And finally undo all that and > restore the drvdata pointer on remove. > > I've also been considering putting some devm stuff inside > qcom_cc_probe() itself so that in the normal case you don't even > need to call qcom_cc_remove(), it just gets done automatically. > That would open up the possibility for drivers to use the drvdata > member as they wish. I'll test with the patch you just sent. >
diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c index aa294b1..86d85e5 100644 --- a/drivers/clk/qcom/gcc-msm8960.c +++ b/drivers/clk/qcom/gcc-msm8960.c @@ -3506,6 +3506,8 @@ static int gcc_msm8960_probe(struct platform_device *pdev) struct clk *clk; struct device *dev = &pdev->dev; const struct of_device_id *match; + struct platform_device *tsens; + int ret; match = of_match_device(gcc_msm8960_match_table, &pdev->dev); if (!match) @@ -3520,11 +3522,26 @@ static int gcc_msm8960_probe(struct platform_device *pdev) if (IS_ERR(clk)) return PTR_ERR(clk); - return qcom_cc_probe(pdev, match->data); + ret = qcom_cc_probe(pdev, match->data); + if (ret) + return ret; + + tsens = platform_device_register_data(&pdev->dev, "qcom-tsens", -1, + NULL, 0); + if (IS_ERR(tsens)) { + qcom_cc_remove(pdev); + return PTR_ERR(tsens); + } + platform_set_drvdata(pdev, tsens); + + return 0; } static int gcc_msm8960_remove(struct platform_device *pdev) { + struct platform_device *tsens = platform_get_drvdata(pdev); + + platform_device_unregister(tsens); qcom_cc_remove(pdev); return 0; }
8960 family of devices have TSENS as part of GCC in hardware. Hence DT would represent a GCC node with GCC properties as well as TSENS. Create a virtual platform child device here for TSENS so the driver can probe it and use the parent (GCC) to extract DT properties. Suggested-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> --- drivers/clk/qcom/gcc-msm8960.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)