- 20 Jun, 2008 33 commits
-
-
Jonathan Corbet authored
Add explicit BKL to vcs_open(). Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Add the BKL to spidev_open(), even though the existing locking looks adequate. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
This documents the fact that somebody looked at the relevant open() functions and concluded that, due to their trivial nature, no locking was needed. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Parts of the serial code actually BUG() if we don't do this.
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
usb_open() is protected by a down_read(&minor_rwsem), but I'm not sure I trust it to protect everything including subsidiary open() functions. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
->release() already has explicit lock_kernel() calls... Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
phone_open() looks OK, but I don't trust the subsidiary drivers (and ixj in particular). Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
This driver would appear to have no internal locking at all. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
misc_open() looks fine, but who knows what all of the misc drivers are doing in their open() functions? Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
It's really hard to tell if this is necessary - lots of weird magic happens by way of map_devmem() Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
- 18 May, 2008 7 commits
-
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Push the cdev lock_kernel() call down into the x86 msr and cpuid drivers. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Push the cdev lock_kernel() call down into the sh gio driver. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Push the cdev lock_kernel() call into MIPS-specific drivers. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-
Jonathan Corbet authored
Push the cdev lock_kernel() call into cris drivers. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-