[+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@xxxxxxxxxxxxxx>
> ---
> 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
>
