All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Dybcio <konradybcio@gmail.com>
To: Stephen Boyd <sboyd@kernel.org>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Marijn Suijten <marijn.suijten@somainline.org>,
	linux-kernel@vger.kernel.org,
	Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>,
	Abel Vesa <abel.vesa@linaro.org>,
	Johan Hovold <johan+linaro@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Subject: Re: [PATCH v2] spmi: Fix controller->node != parent->node breakage
Date: Tue, 14 Jan 2025 21:37:20 +0100	[thread overview]
Message-ID: <91e2bd5b-71fa-402a-82cb-e68d3295804a@gmail.com> (raw)
In-Reply-To: <305d7cf5f0a66efc01181f24d3a288d3.sboyd@kernel.org>



On 1/14/25 19:30, Stephen Boyd wrote:
> Quoting Konrad Dybcio (2025-01-13 14:12:28)
>>
>> On 1/13/25 22:52, Stephen Boyd wrote:
>>> Quoting Konrad Dybcio (2025-01-13 05:02:58)
>>>>
>>>> Make controller->node specifiable to both benefit from Joe's refcount
>>>> improvements and un-break the aforementioned platforms.
>>>
>>> How is it broken? I see spmi_pmic_arb_bus_init() calls
>>> devm_spmi_controller_alloc() which sets the of_node to the parent device
>>> and then spmi_pmic_arb_bus_init() overwrites that with
>>> 'ctrl->dev.of_node = node' later on in the same function. That will
>>> cause one more of_node_put() than is expected. I don't see that removed
>>> in this patch though, so the leak is still there?
>>>
>>>>
>>>> Fixes: 821b07853e32 ("spmi: hisi-spmi-controller: manage the OF node reference in device initialization and cleanup")
>>>
>>> I've dropped this patch from my queue. I don't know if we're really
>>> doing anything better by managing the of_node lifetime in that function
>>> vs. letting the callers assign the node they want and manage the
>>> lifetime themselves. Maybe we don't need to do anything? Presumably the
>>> parent device driver will unregister the controller anyway, so the
>>> lifetime of the of_node will be ensured regardless. For subnodes like
>>> qcom SPMI, the subnodes are child nodes of the parent device so they
>>> won't be removed. If they are dynamic nodes, then the caller can manage
>>> the lifetime.
>>
>> Stephen, the wrong node gets assigned in the qcom driver with
>> multi-master controllers, resulting in probe failures.
>>
>> Since the introduction of the commit referenced in fixes,
>> of_spmi_register_devices() sees the controller's subnodes
>> (which describe each of the two masters) as slave devices
>> - meaning no "real" devices ever get to probe
>>
> 
> Ok, I see that I was reading the already reverted state of the tree
> where the 'ctrl->dev.of_node = node' assignment came back. So there's
> nothing to do besides drop the patch in fixes, which I already did. We
> can then apply this patch to drop the duplicate assignment as a cleanup
> and to avoid a refcount bump on the of_node that isn't needed.
> 
> ----8<---
> diff --git a/drivers/spmi/hisi-spmi-controller.c b/drivers/spmi/hisi-spmi-controller.c
> index 3cafdf22c909..122140b97579 100644
> --- a/drivers/spmi/hisi-spmi-controller.c
> +++ b/drivers/spmi/hisi-spmi-controller.c
> @@ -300,9 +300,6 @@ static int spmi_controller_probe(struct platform_device *pdev)
>   
>   	spin_lock_init(&spmi_controller->lock);
>   
> -	ctrl->dev.parent = pdev->dev.parent;
> -	ctrl->dev.of_node = of_node_get(pdev->dev.of_node);
> -
>   	/* Callbacks */
>   	ctrl->read_cmd = spmi_read_cmd;
>   	ctrl->write_cmd = spmi_write_cmd;

That works for me, thank you

Konrad



  reply	other threads:[~2025-01-14 20:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-13 13:02 [PATCH v2] spmi: Fix controller->node != parent->node breakage Konrad Dybcio
2025-01-13 13:52 ` AngeloGioacchino Del Regno
2025-01-13 21:52 ` Stephen Boyd
2025-01-13 22:12   ` Konrad Dybcio
2025-01-14 18:30     ` Stephen Boyd
2025-01-14 20:37       ` Konrad Dybcio [this message]
2025-01-15 23:16         ` Stephen Boyd
2025-01-16  4:54           ` Joe Hattori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=91e2bd5b-71fa-402a-82cb-e68d3295804a@gmail.com \
    --to=konradybcio@gmail.com \
    --cc=abel.vesa@linaro.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bjorn.andersson@oss.qualcomm.com \
    --cc=joe@pf.is.s.u-tokyo.ac.jp \
    --cc=johan+linaro@kernel.org \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=marijn.suijten@somainline.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab+huawei@kernel.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.