RE: [PATCH net-next RFC 3/9] net: dsa: mv88e6xxx: add support for GPIO configuration

From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Thursday, September 28, 2017 1:01 PM

quoted

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