lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 20 Oct 2023 23:22:25 +0200
From:   Peter Rosin <>
To:     Andrew Davis <>,
        Greg Kroah-Hartman <>,
        Rob Herring <>,
        Krzysztof Kozlowski <>,
        Nishanth Menon <>,
        Vignesh Raghavendra <>
Subject: Re: [PATCH v3] mux: mmio: use reg property when parent device is not
 a syscon


2023-10-20 at 18:43, Andrew Davis wrote:
> 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 <>
>>> Reviewed-by: Nishanth Menon <>
>>> ---
>>> Changes from v2:
>>>   - Rebased on v6.6-rc1
>>> Changes from v1:
>>>   - Flip logic as suggested in v1[0]
>>> [0]
>>>   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.

The ideal working case is usually not much of a problem. When I look at what 
device_node_to_regmap does, I find, appart from -ENOMEM, possibilities of
-ENOENT (because no clock), and the clock may theoretically fail to prepare
for numerous reasons hidden in clock drivers, but the clock core can
trigger at least -EACCES and -EINPROGRESS via runtime PM.

And it definitely looks like the -EPROBE_DEFER case needs to be addressed.
I.e., why is this call chain not a problem?

  -> device_node_get_regmap
   -> of_syscon_register
    -> of_hwspin_lock_get_id

As far as I can tell, if device_node_to_regmap() fails with -EPROBE_DEFER
with your patch, then mux_mmio_probe() misbehaves. It should have aborted
and failed with -EPROBE_DEFER, but instead throws that error away and
goes on to try dev_get_regmap(). That, in turn, is probably futile and
will likely error out in some way, breaking a system that might have been
ok, if the probe had been retried some time later.

As long as the above is not sufficiently explained away, or fixed, I
consider the patch broken.

>> 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).

Hold your horses, I need the above explanation first (and perhaps an
updated 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);

Powered by blists - more mailing lists