On Wed, Aug 11, 2021 at 10:27:26PM +0200, Heiner Kallweit wrote:

On 11.08.2021 17:43, Andy Shevchenko wrote:

quoted

On Fri, Aug 06, 2021 at 11:13:29PM +0200, Heiner Kallweit wrote:

quoted

p2sb_spinlock is used in i801_add_tco_spt() only, and in process context
only. Therefore a mutex is sufficient, and we can make the definition
local to i801_add_tco_spt().

The problem with either AFAICT is that it should actually hold PCI rescan lock.
See the discussion with Message-ID
20210308122020.57071-1-andriy.shevchenko@linux.intel.com for the details.

Thanks for the link. I see that you use pci_lock_rescan_remove() but at a first
glance didn't see this being discussed. Maybe because it's obvious ..

i801 was discussed here:
https://lore.kernel.org/linux-i2c/20210310155145.513a7165@endymion/ (local)
However discussion seems to have ended w/o result. What's the status of your
p2sb series? Backgroud of the question is: Does it make sense to wait for
your series to be applied, to make use of your new ps2b library functions?
Or change the mutex to the rescan mutex for the time being?

The problem with P2SB PCI device is that it's used as a holder for the firmware
programmed value of the BAR which mustn't be relocated. If PCI runs rescan
concurrently with this piece of code (still a probability higher than 0) then
we will be in bad situation.

So, yes, rescan lock is a minimum what has to be done.

In regard to the series the idea is to unhide the P2SB in early PCI quirk and
mark its resources unrelocatable. But I haven't time to research that. It's
postponed currently due to lack of time on my side because higher priority
tasks ongoing.

-- 
With Best Regards,
Andy Shevchenko