[lkml]   [2017]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [v11,1/4] drivers: jtag: Add JTAG core driver
On Tue, Nov 14, 2017 at 12:10:46PM +0100, wrote:
> On Tue, Nov 14, 2017 at 10:34:49AM +0000, Oleksandr Shamray wrote:
> > Greg, what you can suggest about it. May be better to add again single-open()-per-device lock with right locking way like:
> >
> > >if (mutex_lock_interruptible(&jtag->open_lock)) {
> You would stall an open? Why not just return saying you can't do that?

Greg, I think you need to look at the code again.

From the snippet in the email, this lock is not held while the device is
open, as you apparently think it is. It's a short-term lock that is
held to ensure atomic access to the jtag->opened member, so that two
concurrent opens are unable to operate lock-step, resulting in
jtag->opened becoming 2.

The open function snippet in the email drops the lock as soon as it has
incremented jtag->opened, or encounters an error.

It seems entirely sensible, rather than using an atomic_t counter, as
it means that other openers are held off until the current opener has
either succeeded in opening the device or failed to open it.

RMK's Patch system:
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to 8.21Mbps down 510kbps up

 \ /
  Last update: 2017-11-14 12:20    [W:0.047 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site