* [PATCH] PCI: mediatek: fix optional reset handling
@ 2021-03-05 9:17 Philipp Zabel
2021-03-05 15:36 ` Bjorn Helgaas
0 siblings, 1 reply; 3+ messages in thread
From: Philipp Zabel @ 2021-03-05 9:17 UTC (permalink / raw)
To: linux-pci; +Cc: Bjorn Helgaas, Matthias Brugger
As of commit bb475230b8e5 ("reset: make optional functions really
optional"), the reset framework API calls use NULL pointers to describe
optional, non-present reset controls.
This allows to unconditionally return errors from
devm_reset_control_get_optional_exclusive.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
drivers/pci/controller/pcie-mediatek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 23548b517e4b..35c66fa770a6 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -954,7 +954,7 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
snprintf(name, sizeof(name), "pcie-rst%d", slot);
port->reset = devm_reset_control_get_optional_exclusive(dev, name);
- if (PTR_ERR(port->reset) == -EPROBE_DEFER)
+ if (IS_ERR(port->reset))
return PTR_ERR(port->reset);
/* some platforms may use default PHY setting */
--
2.29.2
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] PCI: mediatek: fix optional reset handling
2021-03-05 9:17 [PATCH] PCI: mediatek: fix optional reset handling Philipp Zabel
@ 2021-03-05 15:36 ` Bjorn Helgaas
0 siblings, 0 replies; 3+ messages in thread
From: Bjorn Helgaas @ 2021-03-05 15:36 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-pci, Bjorn Helgaas, Matthias Brugger, Ryder Lee,
Lorenzo Pieralisi, Rob Herring, linux-mediatek
[+cc Ryder, Lorenzo, Rob, linux-mediatek (mediatek maintainers)]
Capitalize first word of subject per convention:
PCI: mediatek: Fix optional reset handling
But "Fix" is pretty non-specific; it doesn't give any information
about what the change does.
On Fri, Mar 05, 2021 at 10:17:15AM +0100, Philipp Zabel wrote:
> As of commit bb475230b8e5 ("reset: make optional functions really
> optional"), the reset framework API calls use NULL pointers to describe
> optional, non-present reset controls.
>
> This allows to unconditionally return errors from
> devm_reset_control_get_optional_exclusive.
"devm_reset_control_get_optional_exclusive()"
This basically restates the code change, but doesn't say *why* we want
this change.
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> drivers/pci/controller/pcie-mediatek.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> index 23548b517e4b..35c66fa770a6 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -954,7 +954,7 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
>
> snprintf(name, sizeof(name), "pcie-rst%d", slot);
> port->reset = devm_reset_control_get_optional_exclusive(dev, name);
> - if (PTR_ERR(port->reset) == -EPROBE_DEFER)
> + if (IS_ERR(port->reset))
> return PTR_ERR(port->reset);
Before this patch,
-EPROBE_DEFER: abort probe, return -EPROBE_DEFER
other errors: port->reset = -EINVAL, etc, continue probe
future WARN_ON() from reset_control_assert()
NULL (no reset control): port->reset = NULL, continue probe
valid reset control: port->reset = rstc, continue probe
After this patch,
all errors: abort probe, return err
NULL (no reset control): port->reset = NULL, continue probe
valid reset control: port->reset = rstc, continue probe
So IIUC, if devm_reset_control_get_optional_exclusive() returns an
error other than -EPROBE_DEFER, e.g., -EINVAL, we used to continue.
We would then get warnings from reset_control_assert() and
reset_control_deassert() because "IS_ERR(port->reset)" was true.
Since the reset control seems to be optional, I assume the port *may*
still be usable even though we get warnings.
But after this patch, if devm_reset_control_get_optional_exclusive()
returns -EINVAL, we will fail the probe, rendering the port useless.
If my understanding is correct, this seems like a difference we should
mention in the commit log because it took me a while to untangle this
and the subject line doesn't hint at it at all.
> /* some platforms may use default PHY setting */
> --
> 2.29.2
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] PCI: mediatek: fix optional reset handling
@ 2021-03-05 15:36 ` Bjorn Helgaas
0 siblings, 0 replies; 3+ messages in thread
From: Bjorn Helgaas @ 2021-03-05 15:36 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-pci, Bjorn Helgaas, Matthias Brugger, Ryder Lee,
Lorenzo Pieralisi, Rob Herring, linux-mediatek
[+cc Ryder, Lorenzo, Rob, linux-mediatek (mediatek maintainers)]
Capitalize first word of subject per convention:
PCI: mediatek: Fix optional reset handling
But "Fix" is pretty non-specific; it doesn't give any information
about what the change does.
On Fri, Mar 05, 2021 at 10:17:15AM +0100, Philipp Zabel wrote:
> As of commit bb475230b8e5 ("reset: make optional functions really
> optional"), the reset framework API calls use NULL pointers to describe
> optional, non-present reset controls.
>
> This allows to unconditionally return errors from
> devm_reset_control_get_optional_exclusive.
"devm_reset_control_get_optional_exclusive()"
This basically restates the code change, but doesn't say *why* we want
this change.
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> drivers/pci/controller/pcie-mediatek.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> index 23548b517e4b..35c66fa770a6 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -954,7 +954,7 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
>
> snprintf(name, sizeof(name), "pcie-rst%d", slot);
> port->reset = devm_reset_control_get_optional_exclusive(dev, name);
> - if (PTR_ERR(port->reset) == -EPROBE_DEFER)
> + if (IS_ERR(port->reset))
> return PTR_ERR(port->reset);
Before this patch,
-EPROBE_DEFER: abort probe, return -EPROBE_DEFER
other errors: port->reset = -EINVAL, etc, continue probe
future WARN_ON() from reset_control_assert()
NULL (no reset control): port->reset = NULL, continue probe
valid reset control: port->reset = rstc, continue probe
After this patch,
all errors: abort probe, return err
NULL (no reset control): port->reset = NULL, continue probe
valid reset control: port->reset = rstc, continue probe
So IIUC, if devm_reset_control_get_optional_exclusive() returns an
error other than -EPROBE_DEFER, e.g., -EINVAL, we used to continue.
We would then get warnings from reset_control_assert() and
reset_control_deassert() because "IS_ERR(port->reset)" was true.
Since the reset control seems to be optional, I assume the port *may*
still be usable even though we get warnings.
But after this patch, if devm_reset_control_get_optional_exclusive()
returns -EINVAL, we will fail the probe, rendering the port useless.
If my understanding is correct, this seems like a difference we should
mention in the commit log because it took me a while to untangle this
and the subject line doesn't hint at it at all.
> /* some platforms may use default PHY setting */
> --
> 2.29.2
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-03-05 15:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-05 9:17 [PATCH] PCI: mediatek: fix optional reset handling Philipp Zabel
2021-03-05 15:36 ` Bjorn Helgaas
2021-03-05 15:36 ` Bjorn Helgaas
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.