On Fri, 8 Dec 2023, Bjorn Helgaas wrote: > On Fri, Dec 08, 2023 at 09:00:56AM +0100, Johan Hovold wrote: > > On Thu, Dec 07, 2023 at 02:47:16PM -0600, Bjorn Helgaas wrote: > > > On Tue, Nov 28, 2023 at 09:15:07AM +0100, Johan Hovold wrote: > > > > Add a helper for enabling link states that can be used in contexts where > > > > a pci_bus_sem read lock is already held (e.g. from pci_walk_bus()). > > > > > > > > This helper will be used to fix a couple of potential deadlocks where > > > > the current helper is called with the lock already held, hence the CC > > > > stable tag. > > > > > As far as I can see, we end up with pci_enable_link_state() defined > > > but never called and pci_enable_link_state_locked() being called only > > > by pcie-qcom.c and vmd.c. > > > > Correct, I mentioned this in the cover letter. > > Ah, right. I really don't like these exported locked/unlocked > interfaces because pci_bus_sem is internal to the PCI core, and the > caller shouldn't need to know or be able to specify whether it is held > or not. They exist for now, but I think we should try to get rid of > them. > > > > Can we just rename pci_enable_link_state() to > > > pci_enable_link_state_locked() and assert that pci_bus_sem is held, so > > > we don't end up with a function that's never used? > > > > That would work too. I went with adding a new helper to facilitate > > stable backports and to mirror pci_disable_link_state(). The variants > > are simple wrappers around the implementation so there's no real cost to > > having the unused one. > > Makes good sense. There's no real machine cost to the unused one; I'm > more concerned about the human cost here. I know these were already applied but I want to correct one small misconcept that seems to be floating around thanks the misleading name... pci_enable_link_state() is not really a pair/mirror of pci_disable_link_state() despite its name. It would be better called pci_set_default_link_state() to better match what it does. -- i.
