* [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.