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 <[email protected]>
> Reviewed-by: Nishanth Menon <[email protected]>
> ---
>
> Changes from v2:
> - Rebased on v6.6-rc1
>
> Changes from v1:
> - Flip logic as suggested in v1[0]
>
> [0] https://lore.kernel.org/lkml/[email protected]/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?
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?
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!
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);
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 <[email protected]>
>> Reviewed-by: Nishanth Menon <[email protected]>
>> ---
>>
>> Changes from v2:
>> - Rebased on v6.6-rc1
>>
>> Changes from v1:
>> - Flip logic as suggested in v1[0]
>>
>> [0] https://lore.kernel.org/lkml/[email protected]/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);
Hi!
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 <[email protected]>
>>> Reviewed-by: Nishanth Menon <[email protected]>
>>> ---
>>>
>>> Changes from v2:
>>> - Rebased on v6.6-rc1
>>>
>>> Changes from v1:
>>> - Flip logic as suggested in v1[0]
>>>
>>> [0] https://lore.kernel.org/lkml/[email protected]/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.
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?
mux_mmio_probe
->device_node_to_regmap
-> device_node_get_regmap
-> of_syscon_register
-> of_hwspin_lock_get_id
<- -EPROBE_DEFER
<- ERR_PTR(-EPROBE_DEFER)
<- ERR_PTR(-EPROBE_DEFER)
<- ERR_PTR(-EPROBE_DEFER)
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).
Cheers,
Peter
> 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);
On 10/20/23 4:22 PM, Peter Rosin wrote:
> Hi!
>
> 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 <[email protected]>
>>>> Reviewed-by: Nishanth Menon <[email protected]>
>>>> ---
>>>>
>>>> Changes from v2:
>>>> - Rebased on v6.6-rc1
>>>>
>>>> Changes from v1:
>>>> - Flip logic as suggested in v1[0]
>>>>
>>>> [0] https://lore.kernel.org/lkml/[email protected]/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.
>
> 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?
>
> mux_mmio_probe
> ->device_node_to_regmap
> -> device_node_get_regmap
> -> of_syscon_register
> -> of_hwspin_lock_get_id
> <- -EPROBE_DEFER
> <- ERR_PTR(-EPROBE_DEFER)
> <- ERR_PTR(-EPROBE_DEFER)
> <- ERR_PTR(-EPROBE_DEFER)
>
> 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.
>
This is why I liked the v1 version, dev_get_regmap() just returns a
simple NULL on error, no complex EPROBE_DEFER oddness :)
So is EPROBE_DEFER the only one we think should retry and not go
down the fallback path? I believe that is the normal assumption
for most drivers.
> 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).
>
I'm not normally so impatient but this went two whole kernel cycles without
any comment until rc6.. v4 on the way.
Andrew
> Cheers,
> Peter
>
>> 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);