David Howells [Wed, 10 Apr 2013 14:52:18 +0000 (15:52 +0100)]
hp_sdc_rtc: Don't use create_proc_read_entry()
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Brian S. Julin <bri@calyx.com>
cc: Helge Deller <deller@gmx.de>
cc: linux-m68k@lists.linux-m68k.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
David Howells [Wed, 10 Apr 2013 12:23:50 +0000 (13:23 +0100)]
fsl_udc: Don't use create_proc_read_entry()
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Li Yang <leoli@freescale.com>
cc: Felipe Balbi <balbi@ti.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: linux-usb@vger.kernel.org
cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
David Howells [Mon, 8 Apr 2013 14:48:07 +0000 (15:48 +0100)]
rtl8187se: Don't use create_proc_read_entry()
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead. Whilst we're at it, reduce the
number of show functions where we can share them.
Question: Do any of the registers read by proc_get_registers() have side
effects upon reading? If so, locking will be required.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Maxim Mikityanskiy <maxtram95@gmail.com>
cc: YAMANE Toshiaki <yamanetoshi@gmail.com>
cc: Bill Pemberton <wfp5p@virginia.edu>
cc: Andrea Merello <andreamrl@tiscali.it>
cc: linux-wireless@vger.kernel.org
cc: devel@driverdev.osuosl.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
David Howells [Mon, 8 Apr 2013 14:17:33 +0000 (15:17 +0100)]
rtl8192u: Don't use create_proc_read_entry()
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead. Whilst we're at it, reduce the
number of show functions where we can share them.
Note: proc_get_stats_ap() should probably use seq_file iteration rather than
list_for_each_entry().
Further note: There appears to be a lot of locking missing in this file to
defend against concurrent access by the driver doing normal operations.
Notably, ieee->network_list traversal and RWCAM/RCAMO command/response access.
Further, do any of the registers read have side effects upon reading?
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jerry Chuang <jerry-chuang@realtek.com>
cc: Mauro Carvalho Chehab <mchehab@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: linux-wireless@vger.kernel.org
cc: devel@driverdev.osuosl.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
do add_timer() *before* unlocking dev->lock, or unpleasant things can
happen if misdn_del_timer() on another CPU finds the sucker, calls
del_timer_sync() (which does nothing, since we hadn't started the
timer yet) and frees it, just as we get around to add_timer()...
Al Viro [Mon, 15 Apr 2013 20:31:13 +0000 (16:31 -0400)]
mISDN: fix the races with timers going off just as they are deleted
timer callback in timerdev.c both accesses struct mISDNtimer it's
called for *and* moves it to dev->expired. We need del_timer_sync(),
or we risk kfree() freeing it right under dev_expire_timer() *and*
dev->expired getting corrupted.
Al Viro [Mon, 15 Apr 2013 02:39:37 +0000 (22:39 -0400)]
lpfc: fix races for miscdevice open vs. rmmod
mind you, I'm not sure WTF would anybody _need_ that miscdevice
at all - no IO is possible for it, opening it only pins the module
down and is seriously racy, at that.
Al Viro [Sun, 14 Apr 2013 00:31:37 +0000 (20:31 -0400)]
new helper: read_code()
switch binfmts that use ->read() to that (and to kernel_read()
in several cases in binfmt_flat - sure, it's nommu, but still,
doing ->read() into kmalloc'ed buffer...)
David Howells [Thu, 4 Apr 2013 15:32:28 +0000 (16:32 +0100)]
procfs: Clean up huge if-statement in __proc_file_read()
Switch huge if-statement in __proc_file_read() around. This then puts the
single line loop break immediately after the if-statement and allows us to
de-indent the huge comment and make it take fewer lines. The code following
the if-statement then follows naturally from the call to dp->read_proc().
Signed-off-by: David Howells <dhowells@redhat.com>
Al Viro [Sat, 6 Apr 2013 00:39:36 +0000 (20:39 -0400)]
pxa3xx-gcu: quite playing silly buggers with ->f_op
misc device gets ->private_data pointing to struct miscdevice
on open(), so we can use that to get to per-device structure
instead of relying on file_operations being copied into it.
David Howells [Thu, 4 Apr 2013 15:49:26 +0000 (16:49 +0100)]
wlags49_h2: Don't use create_proc_entry()
create_proc_entry() shouldn't be used. Rather proc_create_data() should be
used. The proc_write() function is only used by #if'd out code, so delete it
for now.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Thu, 4 Apr 2013 15:44:51 +0000 (16:44 +0100)]
nubus: Don't use create_proc_entry()
Don't use create_proc_entry() in nubus_proc_subdir(). The files created aren't
given any way to use them, so for the moment use create_proc_read_entry() with
a NULL accessor and generate a compile-time warning.
Signed-off-by: David Howells <dhowells@redhat.com>
Al Viro [Sun, 31 Mar 2013 22:16:14 +0000 (18:16 -0400)]
procfs: new helper - PDE_DATA(inode)
The only part of proc_dir_entry the code outside of fs/proc
really cares about is PDE(inode)->data. Provide a helper
for that; static inline for now, eventually will be moved
to fs/proc, along with the knowledge of struct proc_dir_entry
layout.
Al Viro [Sun, 31 Mar 2013 17:50:52 +0000 (13:50 -0400)]
scsi_proc: make proc_scsi_host_open() preallocate a bigger buffer
Some of the ->show_info() instances really spew a lot; it's not a problem
wrt correctness (seq_read() will grow buffer and call the sucker again),
but in this case it makes sense to start with a somewhat bigger one -
they often do exceed one page worth of output.
Al Viro [Sun, 31 Mar 2013 17:43:23 +0000 (13:43 -0400)]
new helper: single_open_size()
Same as single_open(), but preallocates the buffer of given size.
Doesn't make any sense for sizes up to PAGE_SIZE and doesn't make
sense if output of show() exceeds PAGE_SIZE only rarely - seq_read()
will take care of growing the buffer and redoing show(). If you
_know_ that it will be large, it might make more sense to look into
saner iterator, rather than go with single-shot one. If that's
impossible, single_open_size() might be for you.
Again, don't use that without a good reason; occasionally that's really
the best way to go, but very often there are better solutions.
projects / mirror_ubuntu-disco-kernel.git / log