[lkml]   [2017]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH net-next RFC 3/9] net: dsa: mv88e6xxx: add support for GPIO configuration
> From: Andrew Lunn []
> 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

 \ /
  Last update: 2017-09-29 17:31    [W:0.143 / U:0.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site