09 May, 2007

1 commit


08 May, 2007

1 commit


05 May, 2007

5 commits

  • The RFCOMM specification says that the device closing the last DLC on
    a particular session is responsible for closing the multiplexer by
    closing the corresponding L2CAP channel.

    Signed-off-by: Ville Tervo
    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • If RFCOMM_RELEASE_ONHUP flag is on and rfcomm_release_dev is called
    before connection is closed, rfcomm_dev is deleted twice from the
    rfcomm_dev_list and refcount is messed up. This patch adds a check
    before deleting device that the device actually is listed.

    Signed-off-by: Ville Tervo
    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The kernel provides a new convenient way to access the sockets API for
    in-kernel users. It is a good idea to actually use it.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The Bluetooth host adapters are attached to the Bluetooth class and the
    low-level connections are children of these class devices. Having class
    devices as parent of bus devices breaks a lot of reasonable assumptions
    about sysfs. The host adapters should be attached to the Bluetooth bus
    to simplify the dependency resolving. For compatibility an additional
    symlink from the Bluetooth class will be used.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The L2CAP and HCI setsockopt() implementations have a small information
    leak that makes it possible to leak kernel stack memory to userspace.

    If the optlen parameter is 0, no data will be copied by copy_from_user(),
    but the uninitialized stack buffer will be read and stored later. A call
    to getsockopt() can now retrieve the leaked information.

    To fix this problem the stack buffer given to copy_from_user() must be
    initialized with the current settings.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     

26 Apr, 2007

10 commits


29 Mar, 2007

1 commit

  • I have a bugreport that scrollwheel of bluetooth version of apple
    mightymouse doesn't work. The USB version of mightymouse works, as there
    is a quirk for handling scrollwheel in hid/usbhid for it.

    Now that bluetooth git tree is hooked to generic hid layer, it could easily
    use the quirks which are already present in generic hid parser, hid-input,
    etc.

    Below is a simple patch against bluetooth git tree, which adds quirk
    handling to current bluetooth hidp code, and sets quirk flags for device
    0x05ac/0x030c, which is the bluetooth version of the apple mightymouse.

    Signed-off-by: Jiri Kosina
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Kosina
     

23 Mar, 2007

1 commit

  • Turning up the warnings on gcc makes it emit warnings
    about the placement of 'inline' in function declarations.
    Here's everything that was under net/

    Signed-off-by: Dave Jones
    Signed-off-by: David S. Miller

    Dave Jones
     

08 Mar, 2007

1 commit

  • [Bluetooth] Fix socket locking in hci_sock_dev_event()

    hci_sock_dev_event() uses bh_lock_sock() to lock the socket lock.
    This is not deadlock-safe against locking of the same socket lock in
    l2cap_connect_cfm() from softirq context. In addition to that,
    hci_sock_dev_event() doesn't seem to be called from softirq context,
    so it is safe to use lock_sock()/release_sock() instead.

    The lockdep warning can be triggered on my T42p simply by switching
    the Bluetooth off by the keyboard button.

    =================================
    [ INFO: inconsistent lock state ]
    2.6.21-rc2 #4
    ---------------------------------
    inconsistent {in-softirq-W} -> {softirq-on-W} usage.
    khubd/156 [HC0[0]:SC0[0]:HE1:SE1] takes:
    (slock-AF_BLUETOOTH){-+..}, at: [] hci_sock_dev_event+0xa8/0xc5 [bluetooth]
    {in-softirq-W} state was registered at:
    [] mark_lock+0x59/0x414
    [] l2cap_connect_cfm+0x4e/0x11f [l2cap]
    [] __lock_acquire+0x3e5/0xb99
    [] l2cap_connect_cfm+0x4e/0x11f [l2cap]
    [] lock_acquire+0x67/0x81
    [] l2cap_connect_cfm+0x4e/0x11f [l2cap]
    [] _spin_lock+0x29/0x34
    [] l2cap_connect_cfm+0x4e/0x11f [l2cap]
    [] l2cap_connect_cfm+0x4e/0x11f [l2cap]
    [] hci_send_cmd+0x126/0x14f [bluetooth]
    [] hci_event_packet+0x729/0xebd [bluetooth]
    [] hci_rx_task+0x2a/0x20f [bluetooth]
    [] hci_rx_task+0x6c/0x20f [bluetooth]
    [] trace_hardirqs_on+0x10d/0x14e
    [] tasklet_action+0x3d/0x68
    [] __do_softirq+0x41/0x92
    [] do_softirq+0x27/0x3d
    [] do_IRQ+0x7b/0x8f
    [] common_interrupt+0x24/0x34
    [] common_interrupt+0x2e/0x34
    [] acpi_processor_idle+0x1b3/0x34a
    [] acpi_processor_idle+0x1b6/0x34a
    [] cpu_idle+0x39/0x4e
    [] start_kernel+0x372/0x37a
    [] unknown_bootoption+0x0/0x202
    [] 0xffffffff

    Signed-off-by: Jiri Kosina
    Acked-by: Marcel Holtmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Kosina
     

27 Feb, 2007

4 commits


15 Feb, 2007

1 commit

  • After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

11 Feb, 2007

1 commit


10 Feb, 2007

1 commit


23 Jan, 2007

2 commits


09 Jan, 2007

4 commits


14 Dec, 2006

1 commit


09 Dec, 2006

1 commit

  • This is the grungy swap all the occurrences in the right places patch that
    goes with the updates. At this point we have the same functionality as
    before (except that sgttyb() returns speeds not zero) and are ready to
    begin turning new stuff on providing nobody reports lots of bugs

    If you are a tty driver author converting an out of tree driver the only
    impact should be termios->ktermios name changes for the speed/property
    setting functions from your upper layers.

    If you are implementing your own TCGETS function before then your driver
    was broken already and its about to get a whole lot more painful for you so
    please fix it 8)

    Also fill in c_ispeed/ospeed on init for most devices, although the current
    code will do this for you anyway but I'd like eventually to lose that extra
    paranoia

    [akpm@osdl.org: bluetooth fix]
    [mp3@de.ibm.com: sclp fix]
    [mp3@de.ibm.com: warning fix for tty3270]
    [hugh@veritas.com: fix tty_ioctl powerpc build]
    [jdike@addtoit.com: uml: fix ->set_termios declaration]
    Signed-off-by: Alan Cox
    Signed-off-by: Martin Peschke
    Acked-by: Peter Oberparleiter
    Cc: Cornelia Huck
    Signed-off-by: Hugh Dickins
    Signed-off-by: Jeff Dike
    Cc: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alan Cox
     

05 Dec, 2006

1 commit


03 Dec, 2006

4 commits