Skip to content
  1. Aug 10, 2010
  3. Aug 09, 2010
    • Tejun Heo's avatar
      drm: fix fallouts from slow-work -> wq conversion · 9a919c46
      Tejun Heo authored 
      

Commit 991ea75c (drm: use workqueue instead of slow-work), which made
drm to use wq instead of slow-work, didn't account for the return
value difference between delayed_slow_work_enqueue() and
queue_delayed_work().  The former returns 0 on success and -errno on
failures while the latter never fails and only uses the return value
to indicate whether the work was already pending or not.

This misconversion triggered spurious error messages.  Remove the now
unnecessary return value check and error message.

Markus: caught another incorrect conversion in drm_kms_helper_poll_enable()

Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Reported-by: default avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
Tested-by: default avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
      9a919c46
  5. Aug 06, 2010
    • Linus Torvalds's avatar
      pci: fix type warnings in intr_remapping.c · c513b67e
      Linus Torvalds authored 
      

Commit 69309a05 ("x86, asm: Clean up and simplify set_64bit()")
sanitized the x86-64 types to set_64bit(), and incidentally resulted in
warnings like

 drivers/pci/intr_remapping.c: In function 'modify_irte':
 drivers/pci/intr_remapping.c:314: warning: passing argument 1 of 'set_64bit' from incompatible pointer type
 arch/x86/include/asm/cmpxchg_64.h:6: note:expected 'volatile u64 *' but argument is of type 'long unsigned int *'

It turns out that the change to set_64bit() really does clean up things,
and the PCI intr_remapping.c file did a rather ugly cast in order to
avoid warnings with the previous set_64bit() type model.

Removing the ugly cast fixes the warning, and makes everybody happy and
expects a set_64bit() to take the logical "u64 *" argument.

Pointed-out-by: default avatarPeter Anvin <hpa@zytor.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c513b67e
    • Alan Stern's avatar
      SCSI: remove fake "address-of" expression · e6da54d8
      Alan Stern authored 
      

Fake "address-of" expressions that evaluate to NULL generally confuse
readers and can provoke compiler warnings.  This patch (as1411) removes
one such fake expression, using an "#ifdef" in its place.

Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e6da54d8
    • David Howells's avatar
      Fix init ordering of /dev/console vs callers of modprobe · 31d1d48e
      David Howells authored 
      

Make /dev/console get initialised before any initialisation routine that
invokes modprobe because if modprobe fails, it's going to want to open
/dev/console, presumably to write an error message to.

The problem with that is that if the /dev/console driver is not yet
initialised, the chardev handler will call request_module() to invoke
modprobe, which will fail, because we never compile /dev/console as a
module.

This will lead to a modprobe loop, showing the following in the kernel
log:

	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1

This can happen, for example, when the built in md5 module can't find
the built in cryptomgr module (because the latter fails to initialise).
The md5 module comes before the call to tty_init(), presumably because
'crypto' comes before 'drivers' alphabetically.

Fix this by calling tty_init() from chrdev_init().

Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      31d1d48e
  7. Aug 05, 2010