> From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Thursday, September 28, 2017 1:01 PM > > > With the write and read acquiring and then releasing the lock > > immediately, is no there room for this sequence to be interrupted in the > > middle and end-up returning inconsistent reads? > > The general pattern in this code is that the lock chip->reg_lock is > taken at a higher level. That protects against other threads. The > driver tends to do that at the highest levels, at the entry points > into the driver. I've not yet checked this code follows the pattern > yet. However, we have a check in the low level to ensure the lock has > been taken. So it seems likely the lock is held.
Yes, the expectation here is that an upper layer takes the reg_lock. All the functions in ptp.c that call this function do that. If they did not, then assert_reg_lock() gets very angry. :) Perhaps using __must_hold() and similar annotations would also help document the requirements, but we don't seem to use those in this driver today. -- brandon
