[PATCH 1/1] PCI : Refactoring error log prints for better readability
Siddharth Vadapalli
s-vadapalli at ti.com
Fri May 17 04:20:40 PDT 2024
On Fri, May 17, 2024 at 04:29:23PM +0530, Onkarnarth wrote:
> From: Onkarnath <onkarnath.1 at samsung.com>
I think that the $subject should be similar to:
https://patchwork.kernel.org/comment/25712288/
rather than the generic "refactoring error log".
>
> As %pe is already introduced, it's better to use it in place of (%ld) or (%d) for
> printing error in logs. It will enhance readability of logs.
>
> Error print style is more consistent now.
>
> Co-developed-by: Maninder Singh <maninder1.s at samsung.com>
> Signed-off-by: Maninder Singh <maninder1.s at samsung.com>
> Signed-off-by: Onkarnath <onkarnath.1 at samsung.com>
> ---
> Suggested by Bjorn Helgaas in below discussion
> https://patchwork.kernel.org/comment/25712288/
Since you have indicated that Bjorn has suggested it, shouldn't there
also be a "Suggested-by tag" in the commit message?
>
> drivers/pci/bus.c | 2 +-
> drivers/pci/controller/dwc/pci-dra7xx.c | 2 +-
> drivers/pci/controller/dwc/pci-meson.c | 16 +--
> drivers/pci/controller/dwc/pcie-armada8k.c | 4 +-
> drivers/pci/controller/dwc/pcie-histb.c | 6 +-
> drivers/pci/controller/dwc/pcie-intel-gw.c | 10 +-
> drivers/pci/controller/dwc/pcie-keembay.c | 2 +-
> drivers/pci/controller/dwc/pcie-kirin.c | 6 +-
> drivers/pci/controller/dwc/pcie-qcom-ep.c | 18 +--
> drivers/pci/controller/dwc/pcie-qcom.c | 18 +--
> drivers/pci/controller/dwc/pcie-tegra194.c | 132 +++++++++---------
> drivers/pci/controller/dwc/pcie-uniphier-ep.c | 2 +-
> drivers/pci/controller/pci-aardvark.c | 6 +-
> drivers/pci/controller/pci-ftpci100.c | 2 +-
> drivers/pci/controller/pci-tegra.c | 86 ++++++------
> drivers/pci/controller/pci-xgene.c | 4 +-
> drivers/pci/controller/pcie-microchip-host.c | 2 +-
> drivers/pci/controller/pcie-rcar-host.c | 14 +-
> drivers/pci/controller/pcie-rockchip.c | 34 ++---
> drivers/pci/controller/vmd.c | 2 +-
> drivers/pci/doe.c | 4 +-
> drivers/pci/endpoint/functions/pci-epf-mhi.c | 8 +-
> drivers/pci/endpoint/functions/pci-epf-ntb.c | 2 +-
> drivers/pci/endpoint/functions/pci-epf-test.c | 4 +-
> drivers/pci/endpoint/functions/pci-epf-vntb.c | 2 +-
> drivers/pci/endpoint/pci-ep-cfs.c | 12 +-
> drivers/pci/endpoint/pci-epf-core.c | 16 +--
> drivers/pci/hotplug/acpiphp_core.c | 2 +-
> drivers/pci/hotplug/pciehp_core.c | 8 +-
> drivers/pci/hotplug/shpchp_core.c | 4 +-
> drivers/pci/of.c | 6 +-
> drivers/pci/pci-driver.c | 4 +-
> drivers/pci/pcie/dpc.c | 4 +-
> drivers/pci/quirks.c | 2 +-
> drivers/pci/setup-bus.c | 2 +-
> drivers/pci/slot.c | 4 +-
> drivers/pci/vgaarb.c | 2 +-
> 37 files changed, 227 insertions(+), 227 deletions(-)
>
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index 826b5016a101..dbc16cf5a246 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -351,7 +351,7 @@ void pci_bus_add_device(struct pci_dev *dev)
> dev->match_driver = !dn || of_device_is_available(dn);
> retval = device_attach(&dev->dev);
> if (retval < 0 && retval != -EPROBE_DEFER)
> - pci_warn(dev, "device attach failed (%d)\n", retval);
> + pci_warn(dev, "device attach failed: %pe\n", ERR_PTR(retval));
Is there a reason behind dropping the parantheses?
>
> pci_dev_assign_added(dev, true);
> }
> diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c b/drivers/pci/controller/dwc/pci-dra7xx.c
> index d2d17d37d3e0..79b6cc7f0287 100644
> --- a/drivers/pci/controller/dwc/pci-dra7xx.c
> +++ b/drivers/pci/controller/dwc/pci-dra7xx.c
> @@ -801,7 +801,7 @@ static int dra7xx_pcie_probe(struct platform_device *pdev)
> reset = devm_gpiod_get_optional(dev, NULL, GPIOD_OUT_HIGH);
> if (IS_ERR(reset)) {
> ret = PTR_ERR(reset);
> - dev_err(&pdev->dev, "gpio request failed, ret %d\n", ret);
> + dev_err(&pdev->dev, "gpio request failed: %pe\n", ERR_PTR(ret));
Similar question as above regarding converting "failed, ret" to
"failed:". Is this a new convention that is expected to be followed,
where all errors are supposed to have "failed: %pe", rather than custom
statements? Please let me know if this has already been discussed
elsewhere.
[...]
Regards,
Siddharth.
More information about the linux-arm-kernel
mailing list