| Message ID | 20230321193208.366561-1-u.kleine-koenig@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | PCI: Convert to platform remove callback returning void | expand |
Hello Bjorn, On Tue, Mar 21, 2023 at 08:31:53PM +0100, Uwe Kleine-König wrote: > this series adapts the platform drivers below drivers/pci to use the > .remove_new() callback. Compared to the traditional .remove() callback > .remove_new() returns no value. This is a good thing because the driver core > doesn't (and cannot) cope for errors during remove. The only effect of a > non-zero return value in .remove() is that the driver core emits a warning. The > device is removed anyhow and an early return from .remove() usually yields a > resource leak. > > By changing the remove callback to return void driver authors cannot > reasonably assume any more that there is some kind of cleanup later. > > All drivers were easy to convert as they all returned zero in their > remove callback. Only for iproc the conversion wasn't trivial, the other > were converted using coccinelle. > > There are no interdependencies between these patches. So even if there > are some concerns for individual patches, I ask you to apply the > remaining set. Then I only have to care for the review feedback of the > refused patches. (Having said that I don't expect any serious objection, > just things like squashing or separating patches, or maybe I picked a > wrong subject prefix.) These patches wait for application for quite some time now. They apply just fine to v6.4-rc1 and next/master. Would be great to get them in during the next merge window and ideally give them some time in next before. Best regards Uwe
On Tue, May 30, 2023 at 04:07:42PM +0200, Uwe Kleine-König wrote: > Hello Bjorn, > > On Tue, Mar 21, 2023 at 08:31:53PM +0100, Uwe Kleine-König wrote: > > this series adapts the platform drivers below drivers/pci to use the > > .remove_new() callback. Compared to the traditional .remove() callback > > .remove_new() returns no value. This is a good thing because the driver core > > doesn't (and cannot) cope for errors during remove. The only effect of a > > non-zero return value in .remove() is that the driver core emits a warning. The > > device is removed anyhow and an early return from .remove() usually yields a > > resource leak. > > > > By changing the remove callback to return void driver authors cannot > > reasonably assume any more that there is some kind of cleanup later. > > > > All drivers were easy to convert as they all returned zero in their > > remove callback. Only for iproc the conversion wasn't trivial, the other > > were converted using coccinelle. > > > > There are no interdependencies between these patches. So even if there > > are some concerns for individual patches, I ask you to apply the > > remaining set. Then I only have to care for the review feedback of the > > refused patches. (Having said that I don't expect any serious objection, > > just things like squashing or separating patches, or maybe I picked a > > wrong subject prefix.) > > These patches wait for application for quite some time now. They apply > just fine to v6.4-rc1 and next/master. Would be great to get them in > during the next merge window and ideally give them some time in next > before. Thanks, these seem fine to me, and Lorenzo normally takes care of drivers/pci/controller/. Lorenzo, if it's easier to have me apply them, that's fine, too, just let me know. The only tweaks I would make would be: PCI: j721e: Convert to platform remove callback returning void PCI: dwc: Convert to platform remove callback returning void to match the git history.
Hello, [dropped Tom Joseph and Joyce Ooi from Cc:, my last mail in this thread resulted in a bounce for their addresses.] On Fri, Jun 02, 2023 at 04:37:34PM -0500, Bjorn Helgaas wrote: > On Tue, May 30, 2023 at 04:07:42PM +0200, Uwe Kleine-König wrote: > > Hello Bjorn, > > > > On Tue, Mar 21, 2023 at 08:31:53PM +0100, Uwe Kleine-König wrote: > > > this series adapts the platform drivers below drivers/pci to use the > > > .remove_new() callback. Compared to the traditional .remove() callback > > > .remove_new() returns no value. This is a good thing because the driver core > > > doesn't (and cannot) cope for errors during remove. The only effect of a > > > non-zero return value in .remove() is that the driver core emits a warning. The > > > device is removed anyhow and an early return from .remove() usually yields a > > > resource leak. > > > > > > By changing the remove callback to return void driver authors cannot > > > reasonably assume any more that there is some kind of cleanup later. > > > > > > All drivers were easy to convert as they all returned zero in their > > > remove callback. Only for iproc the conversion wasn't trivial, the other > > > were converted using coccinelle. > > > > > > There are no interdependencies between these patches. So even if there > > > are some concerns for individual patches, I ask you to apply the > > > remaining set. Then I only have to care for the review feedback of the > > > refused patches. (Having said that I don't expect any serious objection, > > > just things like squashing or separating patches, or maybe I picked a > > > wrong subject prefix.) > > > > These patches wait for application for quite some time now. They apply > > just fine to v6.4-rc1 and next/master. Would be great to get them in > > during the next merge window and ideally give them some time in next > > before. > > Thanks, these seem fine to me, and Lorenzo normally takes care of > drivers/pci/controller/. Lorenzo, if it's easier to have me apply > them, that's fine, too, just let me know. > > The only tweaks I would make would be: > > PCI: j721e: Convert to platform remove callback returning void > PCI: dwc: Convert to platform remove callback returning void If it's easier for you (or Lorenzo) I can resend with these tweaks. Otherwise if these are adapted when applying them, that's fine for me, too. Just tell me if I should do anything here. Best regards Uwe
On Friday 02 June 2023 16:37:34 Bjorn Helgaas wrote: > On Tue, May 30, 2023 at 04:07:42PM +0200, Uwe Kleine-König wrote: > > Hello Bjorn, > > > > On Tue, Mar 21, 2023 at 08:31:53PM +0100, Uwe Kleine-König wrote: > > > this series adapts the platform drivers below drivers/pci to use the > > > .remove_new() callback. Compared to the traditional .remove() callback > > > .remove_new() returns no value. This is a good thing because the driver core > > > doesn't (and cannot) cope for errors during remove. The only effect of a > > > non-zero return value in .remove() is that the driver core emits a warning. The > > > device is removed anyhow and an early return from .remove() usually yields a > > > resource leak. > > > > > > By changing the remove callback to return void driver authors cannot > > > reasonably assume any more that there is some kind of cleanup later. > > > > > > All drivers were easy to convert as they all returned zero in their > > > remove callback. Only for iproc the conversion wasn't trivial, the other > > > were converted using coccinelle. > > > > > > There are no interdependencies between these patches. So even if there > > > are some concerns for individual patches, I ask you to apply the > > > remaining set. Then I only have to care for the review feedback of the > > > refused patches. (Having said that I don't expect any serious objection, > > > just things like squashing or separating patches, or maybe I picked a > > > wrong subject prefix.) > > > > These patches wait for application for quite some time now. They apply > > just fine to v6.4-rc1 and next/master. Would be great to get them in > > during the next merge window and ideally give them some time in next > > before. > > Thanks, these seem fine to me, and Lorenzo normally takes care of > drivers/pci/controller/. Lorenzo, if it's easier to have me apply > them, that's fine, too, just let me know. > > The only tweaks I would make would be: > > PCI: j721e: Convert to platform remove callback returning void > PCI: dwc: Convert to platform remove callback returning void > > to match the git history. Hello Bjorn, it should be expected that other changes for PCIe drivers sent by other people which were sent to the list before this patch series and are still waiting for the review (because are without comments), would be processed before and patches sent later. Also I would like to point out that in past I have sent fixes for PCIe mvebu driver, which is currently in the broken state. And this is also on waiting on the list.
On Sun, Jun 11, 2023 at 03:24:23PM +0200, Pali Rohár wrote: > On Friday 02 June 2023 16:37:34 Bjorn Helgaas wrote: > > On Tue, May 30, 2023 at 04:07:42PM +0200, Uwe Kleine-König wrote: > > > On Tue, Mar 21, 2023 at 08:31:53PM +0100, Uwe Kleine-König wrote: > > > > this series adapts the platform drivers below drivers/pci to > > > > use the .remove_new() callback. Compared to the traditional > > > > .remove() callback .remove_new() returns no value. This is a > > > > good thing because the driver core doesn't (and cannot) cope > > > > for errors during remove. The only effect of a non-zero return > > > > value in .remove() is that the driver core emits a warning. > > > > The device is removed anyhow and an early return from > > > > .remove() usually yields a resource leak. > ... > Hello Bjorn, it should be expected that other changes for PCIe drivers > sent by other people which were sent to the list before this patch > series and are still waiting for the review (because are without > comments), would be processed before and patches sent later. I don't think it's necessary to delay simple, easily-reviewed changes behind more complicated ones. > Also I would like to point out that in past I have sent fixes for PCIe > mvebu driver, which is currently in the broken state. And this is also > on waiting on the list. Thanks for this reminder. Would you mind reposting them? I poked around in patchwork and I must be doing something wrong because I can't find *any* patches from you, though obviously there are many. If you repost them at least we'll know unambiguously what is on the table. Bjorn
On Monday 12 June 2023 11:19:27 Bjorn Helgaas wrote: > On Sun, Jun 11, 2023 at 03:24:23PM +0200, Pali Rohár wrote: > > On Friday 02 June 2023 16:37:34 Bjorn Helgaas wrote: > > > On Tue, May 30, 2023 at 04:07:42PM +0200, Uwe Kleine-König wrote: > > > > On Tue, Mar 21, 2023 at 08:31:53PM +0100, Uwe Kleine-König wrote: > > > > > this series adapts the platform drivers below drivers/pci to > > > > > use the .remove_new() callback. Compared to the traditional > > > > > .remove() callback .remove_new() returns no value. This is a > > > > > good thing because the driver core doesn't (and cannot) cope > > > > > for errors during remove. The only effect of a non-zero return > > > > > value in .remove() is that the driver core emits a warning. > > > > > The device is removed anyhow and an early return from > > > > > .remove() usually yields a resource leak. > > ... > > > Hello Bjorn, it should be expected that other changes for PCIe drivers > > sent by other people which were sent to the list before this patch > > series and are still waiting for the review (because are without > > comments), would be processed before and patches sent later. > > I don't think it's necessary to delay simple, easily-reviewed changes > behind more complicated ones. > > > Also I would like to point out that in past I have sent fixes for PCIe > > mvebu driver, which is currently in the broken state. And this is also > > on waiting on the list. > > Thanks for this reminder. Would you mind reposting them? I poked > around in patchwork and I must be doing something wrong because I > can't find *any* patches from you, though obviously there are many. > > If you repost them at least we'll know unambiguously what is on the > table. > > Bjorn Well, my patches I reposted more times. And some were also reposted by other people. I do not know if they are in patchwork, but they are in email archive. For example last repost of aardvark patches are here: https://lore.kernel.org/linux-pci/20220927141926.8895-1-kabel@kernel.org/ And some other aardvark are also here: https://lore.kernel.org/linux-pci/20220711120626.11492-1-pali@kernel.org/
Hello, > this series adapts the platform drivers below drivers/pci to use the > .remove_new() callback. Compared to the traditional .remove() callback > .remove_new() returns no value. This is a good thing because the driver core > doesn't (and cannot) cope for errors during remove. The only effect of a > non-zero return value in .remove() is that the driver core emits a warning. The > device is removed anyhow and an early return from .remove() usually yields a > resource leak. > > By changing the remove callback to return void driver authors cannot > reasonably assume any more that there is some kind of cleanup later. > > All drivers were easy to convert as they all returned zero in their > remove callback. Only for iproc the conversion wasn't trivial, the other > were converted using coccinelle. > > There are no interdependencies between these patches. So even if there > are some concerns for individual patches, I ask you to apply the > remaining set. Then I only have to care for the review feedback of the > refused patches. (Having said that I don't expect any serious objection, > just things like squashing or separating patches, or maybe I picked a > wrong subject prefix.) Applied to controller/remove-void-callbacks, thank you! [01/15] PCI: aardvark: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/b11c76db97e7 [02/15] PCI: altera: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/3a610560aa4f [03/15] PCI: altera-msi: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/60d03f70455c [04/15] PCI: brcmstb: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/b169c576ad0c [05/15] PCI: j721e: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/c86f4bd6008e [06/15] PCI: dwc: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/221879c98698 [07/15] PCI: hisi-error: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/9a285fbbb591 [08/15] PCI: iproc: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/6f1c0a046048 [09/15] PCI: mediatek: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/5e0005409427 [10/15] PCI: mediatek-gen3: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/22626c46bb32 [11/15] PCI: mt7621: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/8c47ac2a66c4 [12/15] PCI: mvebu: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/4c3bc1b41b8f [13/15] PCI: rockchip-host: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/2998efcd8e73 [14/15] PCI: tegra: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/c7fd95cda648 [15/15] PCI: xgene-msi: Convert to platform remove callback returning void https://git.kernel.org/pci/pci/c/afbb9130d2bf Krzysztof
Hello, [...] > > > These patches wait for application for quite some time now. They apply > > > just fine to v6.4-rc1 and next/master. Would be great to get them in > > > during the next merge window and ideally give them some time in next > > > before. > > > > Thanks, these seem fine to me, and Lorenzo normally takes care of > > drivers/pci/controller/. Lorenzo, if it's easier to have me apply > > them, that's fine, too, just let me know. > > > > The only tweaks I would make would be: > > > > PCI: j721e: Convert to platform remove callback returning void > > PCI: dwc: Convert to platform remove callback returning void > > If it's easier for you (or Lorenzo) I can resend with these tweaks. > Otherwise if these are adapted when applying them, that's fine for me, > too. Just tell me if I should do anything here. I took the entire series and tweaked the subject lines as Bjorn requested. Thank you! Krzysztof