Thread (18 messages) 18 messages, 4 authors, 2021-02-19

Re: [PATCH v3 3/4] i2c: designware: Use the correct name of device-managed function

From: Dejin Zheng <hidden>
Date: 2021-02-17 11:46:32
Also in: linux-i2c, linux-pci, lkml

On Tue, Feb 16, 2021 at 06:46:01PM +0100, Krzysztof Wilczyński wrote:
Hi Krzysztof,
Hi Dejin,

Thank you for all the changes, looks good!

You could improve the subject line, as it is very vague - what is the
new function name more correct?  Was the other and/or the previous one
not correct?  Seems like you are correcting a typo of sorts, rather than
introducing a new function in this file.
If you have read the following commit comments, As you know, the
pci_alloc_irq_vectors() is not a real device-managed function. But
in some specific cases, it will act as an device-managed function.
Such naming will cause controversy, So In the case of need device-managed,
should be used pcim_alloc_irq_vectors(), an explicit device-managed
function. So the subject name is "Use the correct name of device-managed function".
quoted
Use the new function pcim_alloc_irq_vectors() to allocate IRQ vectors,
the pcim_alloc_irq_vectors() function, an explicit device-managed
version of pci_alloc_irq_vectors(). If pcim_enable_device() has been
called before, then pci_alloc_irq_vectors() is actually
a device-managed function. It is used here as a device-managed
function, So replace it with pcim_alloc_irq_vectors().
The commit is good, but it could use some polish, so to speak.

A few suggestions to think about:

  - What are we adding and/or changing, and why
  - Why is using pcim_alloc_irq_vectors(), which is part
    of the managed devices framework, a better alternative
    to the pci_alloc_irq_vectors()
  - And finally why this change allowed us to remove the
    pci_free_irq_vectors()
These are all explained by the device-managed function mechanism.
quoted
At the same time, simplify the error handling path.
The change simplifies the error handling path, how?  A line of two which
explains how it has been achieved might help should someone reads the
commit message in the future.
To put it simply, if the driver probe fail, the device-managed function
mechanism will automatically call pcim_release(), then the pci_free_irq_vectors()
will be executed. For details, please see the relevant code.
[...]
quoted
 	if (controller->setup) {
 		r = controller->setup(pdev, controller);
-		if (r) {
-			pci_free_irq_vectors(pdev);
+		if (r)
 			return r;
-		}
 	}
 
 	i2c_dw_adjust_bus_speed(dev);
@@ -246,10 +244,8 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
 		i2c_dw_acpi_configure(&pdev->dev);
 
 	r = i2c_dw_validate_speed(dev);
-	if (r) {
-		pci_free_irq_vectors(pdev);
+	if (r)
 		return r;
-	}
 
 	i2c_dw_configure(dev);
 
@@ -269,10 +265,8 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
 	adap->nr = controller->bus_num;
 
 	r = i2c_dw_probe(dev);
-	if (r) {
-		pci_free_irq_vectors(pdev);
+	if (r)
 		return r;
-	}
 
 	pm_runtime_set_autosuspend_delay(&pdev->dev, 1000);
 	pm_runtime_use_autosuspend(&pdev->dev);
@@ -292,7 +286,6 @@ static void i2c_dw_pci_remove(struct pci_dev *pdev)
 
 	i2c_del_adapter(&dev->adapter);
 	devm_free_irq(&pdev->dev, dev->irq, dev);
-	pci_free_irq_vectors(pdev);
If pcim_release() is called should the pci_driver's probe callback fail,
Yes, you guessed right.
and I assume that this is precisely the case, then all of the above make
sense in the view of using pcim_alloc_irq_vectors().

Reviewed-by: Krzysztof Wilczyński <redacted>

Krzysztof
BR,
Dejin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help