Hello,
On Tue, Sep 28, 2021 at 12:17:59PM -0500, Bjorn Helgaas wrote:
[+to Oliver, Russell for eeh_driver_name() question below]
On Mon, Sep 27, 2021 at 10:43:22PM +0200, Uwe Kleine-König wrote:
quoted
From: Uwe Kleine-König <redacted>
struct pci_dev::driver holds (apart from a constant offset) the same
data as struct pci_dev::dev->driver. With the goal to remove struct
pci_dev::driver to get rid of data duplication replace getting the
driver name by dev_driver_string() which implicitly makes use of struct
pci_dev::dev->driver.
When you repost to fix the build issue, can you capitalize the subject
line to match the other?
Yes, sure.
Also, would you mind using "pci_dev.driver" instead of
"pci_dev::driver"? AFAIK, the "::" operator is not actually part of
C, so I think it's more confusing than useful.
pci_dev.driver doesn't work either in C because pci_dev is a type and
not a variable. This is probably subjective, but for me pci_dev.driver
looks definitively stranger than pci_dev::driver. And :: is at least not
unseen in the kernel commit logs. (git log --grep=::)
But if you insist I can change to .
quoted
diff --git a/arch/powerpc/include/asm/ppc-pci.h b/arch/powerpc/include/asm/ppc-pci.h
index 2b9edbf6e929..e8f1795a2acf 100644
--- a/arch/powerpc/include/asm/ppc-pci.h
+++ b/arch/powerpc/include/asm/ppc-pci.h
@@ -57,7 +57,14 @@ void eeh_sysfs_remove_device(struct pci_dev *pdev);
static inline const char *eeh_driver_name(struct pci_dev *pdev)
{
- return (pdev && pdev->driver) ? pdev->driver->name : "<null>";
+ if (pdev) {
+ const char *drvstr = dev_driver_string(&pdev->dev);
+
+ if (strcmp(drvstr, ""))
+ return drvstr;
+ }
+
+ return "<null>";
Can we just do this?
if (pdev)
return dev_driver_string(&pdev->dev);
return "<null>";
Works for me, too. It behaves a bit differerently than my suggestion
(which nearly behaves identical to the status quo), but only in some
degenerated cases.
I think it's more complicated than it's worth to include a strcmp().
It's possible this will change those error messages about "Might be
infinite loop in %s driver", but that doesn't seem like a huge deal.
I moved Oliver to "to:" and added Russell in case they object.
quoted
}
#endif /* CONFIG_EEH */
diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
index 69c10a7b7c61..0973022d4b13 100644
--- a/drivers/bcma/host_pci.c
+++ b/drivers/bcma/host_pci.c
@@ -175,9 +175,10 @@ static int bcma_host_pci_probe(struct pci_dev *dev,
if (err)
goto err_kfree_bus;
- name = dev_name(&dev->dev);
- if (dev->driver && dev->driver->name)
- name = dev->driver->name;
+ name = dev_driver_string(&dev->dev);
+ if (!strcmp(name, ""))
+ name = dev_name(&dev->dev);
err = pci_request_regions(dev, name);
Again seems more complicated than it's worth to me. This is in the
driver's .probe() method, so really_probe() has already set
"dev->driver = drv", which means dev->driver is always set to
&bcma_pci_bridge_driver here, and bcma_pci_bridge_driver.name is
always "bcma-pci-bridge".
Almost all callers of pci_request_regions() just hardcode the driver
name or use a DRV_NAME #define
So I think we should just do:
err = pci_request_regions(dev, "bcma-pci-bridge");
Yes, looks right. I'd put this in a separate patch.
quoted
if (err)
goto err_pci_disable;
[...]
diff --git a/drivers/ssb/pcihost_wrapper.c b/drivers/ssb/pcihost_wrapper.c
index 410215c16920..4938ed5cfae5 100644
--- a/drivers/ssb/pcihost_wrapper.c
+++ b/drivers/ssb/pcihost_wrapper.c
@@ -78,9 +78,11 @@ static int ssb_pcihost_probe(struct pci_dev *dev,
err = pci_enable_device(dev);
if (err)
goto err_kfree_ssb;
- name = dev_name(&dev->dev);
- if (dev->driver && dev->driver->name)
- name = dev->driver->name;
+
+ name = dev_driver_string(&dev->dev);
+ if (*name == '\0')
+ name = dev_name(&dev->dev);
+
err = pci_request_regions(dev, name);
Also seems like more trouble than it's worth. This one is a little
strange but is always called for either b43_pci_bridge_driver or
b44_pci_driver, both of which have .name set, so I think we should
simply do:
err = pci_request_regions(dev, dev_driver_string(&dev->dev));
yes, agreed, too.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |