From: Andrew Davis <afd@ti.com>
To: Peter Rosin <peda@axentia.se>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>
Cc: <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] mux: mmio: use reg property when parent device is not a syscon
Date: Fri, 20 Oct 2023 11:43:04 -0500 [thread overview]
Message-ID: <ab1c4929-0d7d-45eb-ab70-7680dbebcdbb@ti.com> (raw)
In-Reply-To: <0cb645c7-f3c5-e4bb-7686-2a83d32274bb@axentia.se>
On 10/20/23 9:28 AM, Peter Rosin wrote:
> Hi!
>
> 2023-09-11 at 17:10, Andrew Davis wrote:
>> The DT binding for the reg-mux compatible states it can be used when the
>> "parent device of mux controller is not syscon device". It also allows
>> for a reg property. When the reg property is provided, use that to
>> identify the address space for this mux. If not provided fallback to
>> using the parent device as a regmap provider.
>>
>> Signed-off-by: Andrew Davis <afd@ti.com>
>> Reviewed-by: Nishanth Menon <nm@ti.com>
>> ---
>>
>> Changes from v2:
>> - Rebased on v6.6-rc1
>>
>> Changes from v1:
>> - Flip logic as suggested in v1[0]
>>
>> [0] https://lore.kernel.org/lkml/1c27d9d4-b1cc-c158-90f7-f7e47e02c424@ti.com/T/
>>
>> drivers/mux/mmio.c | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mux/mmio.c b/drivers/mux/mmio.c
>> index fd1d121a584ba..b6095b7853ed2 100644
>> --- a/drivers/mux/mmio.c
>> +++ b/drivers/mux/mmio.c
>> @@ -44,10 +44,13 @@ static int mux_mmio_probe(struct platform_device *pdev)
>> int ret;
>> int i;
>>
>> - if (of_device_is_compatible(np, "mmio-mux"))
>> + if (of_device_is_compatible(np, "mmio-mux")) {
>> regmap = syscon_node_to_regmap(np->parent);
>> - else
>> - regmap = dev_get_regmap(dev->parent, NULL) ?: ERR_PTR(-ENODEV);
>> + } else {
>> + regmap = device_node_to_regmap(np);
>
> I started digging in device_node_to_regmap() to try to find an error that
> could be used to trigger if the failover to dev_get_regmap() should be
> tried, instead of always doing the failover on error. I got lost fairly
> quickly, but it seems device_node_to_regmap() can return -EDEFER_PROBE.
> While I'm not certain that it is applicable, that case should probably
> not fall back to dev_get_regmap()...
>
> Are there other error cases that should prevent the failover? I would
> guess that it's perhaps just a single error that should trigger trying
> the failover path? But I don't know, and which error if that's the case?
>
Ideally the only error that will be returned is ENOMEM, which happens when
this node does not have a 'reg' property, and this is also the one case we
want to do the failover. So all should be well.
> How much badness can be caused if syscon_node_to_regmap() fails for some
> random obscure reason and the failover path is taken inadvertently? It
> certainly smells bad for -EDEFER_PROBE, but do you have any insight in
> other cases?
>
If we take the failover inadvertently then we will check if the parent
node is a syscon, if it is then our offset will most likely be wrong
(parent will not match child 'reg').
> And after getting to approx that point a while back, I had other things
> to take care of, and this fell off the table. Sorry!
>
No problem as long as we can find a way to get this in quickly (lot of
DT warning need cleaned up based on this patch).
Thanks
Andrew
> Cheers,
> Peter
>
>> + if (IS_ERR(regmap))
>> + regmap = dev_get_regmap(dev->parent, NULL) ?: ERR_PTR(-ENODEV);
>> + }
>> if (IS_ERR(regmap)) {
>> ret = PTR_ERR(regmap);
>> dev_err(dev, "failed to get regmap: %d\n", ret);
next prev parent reply other threads:[~2023-10-20 16:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 15:10 Andrew Davis
2023-10-20 14:28 ` Peter Rosin
2023-10-20 16:43 ` Andrew Davis [this message]
2023-10-20 21:22 ` Peter Rosin
2023-10-23 16:26 ` Andrew Davis
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=ab1c4929-0d7d-45eb-ab70-7680dbebcdbb@ti.com \
--to=afd@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=peda@axentia.se \
--cc=robh+dt@kernel.org \
--cc=vigneshr@ti.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®