On Wed, Aug 11, 2021 at 10:27:26PM +0200, Heiner Kallweit wrote: > On 11.08.2021 17:43, Andy Shevchenko wrote: > > On Fri, Aug 06, 2021 at 11:13:29PM +0200, Heiner Kallweit wrote: > >> 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@xxxxxxxxxxxxxxx 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/ > 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
