10 Nov, 2011

1 commit


08 Nov, 2011

3 commits

  • Timers set by __set_chan_timer() should use miliseconds instead of
    jiffies. Commit 942ecc9c4643db5ce071562e0a23f99464d6b461 updated
    l2cap_set_timer() so it expects timeout to be specified in msecs
    instead of jiffies. This makes timeouts unreliable when CONFIG_HZ
    is not set to 1000.

    Signed-off-by: Andrzej Kaczmarek
    Signed-off-by: Gustavo F. Padovan

    Andrzej Kaczmarek
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (47 commits)
    forcedeth: fix a few sparse warnings (variable shadowing)
    forcedeth: Improve stats counters
    forcedeth: remove unneeded stats updates
    forcedeth: Acknowledge only interrupts that are being processed
    forcedeth: fix race when unloading module
    MAINTAINERS/rds: update maintainer
    wanrouter: Remove kernel_lock annotations
    usbnet: fix oops in usbnet_start_xmit
    ixgbe: Fix compile for kernel without CONFIG_PCI_IOV defined
    etherh: Add MAINTAINERS entry for etherh
    bonding: comparing a u8 with -1 is always false
    sky2: fix regression on Yukon Optima
    netlink: clarify attribute length check documentation
    netlink: validate NLA_MSECS length
    i825xx:xscale:8390:freescale: Fix Kconfig dependancies
    macvlan: receive multicast with local address
    tg3: Update version to 3.121
    tg3: Eliminate timer race with reset_task
    tg3: Schedule at most one tg3_reset_task run
    tg3: Obtain PCI function number from device
    ...

    Linus Torvalds
     
  • This reverts commit 330605423ca6eafafb8dcc27502bce1c585d1b06.
    The commit introduces regression when two 2.1 devices attempt
    establish rfcomm channel. Such connection is refused since there's
    a security block issue on l2cap. It means the link is unencrypted.

    2011-09-16 18:08:46.567616 < ACL data: handle 1 flags 0x00 dlen 24
    0000: 14 00 40 00 06 00 02 00 0f 35 03 19 12 00 ff ff
    ..@......5....˙˙
    0010: 35 05 0a 00 00 ff ff 00 5....˙˙.
    2011-09-16 18:08:46.572377 > HCI Event: Number of Completed Packets
    (0x13) plen 5
    handle 1 packets 1
    2011-09-16 18:08:46.577931 > ACL data: handle 1 flags 0x02 dlen 88
    L2CAP(d): cid 0x0040 len 84 [psm 0]
    0000: 07 00 02 00 4f 00 4c 35 4a 35 48 09 00 00 0a 00
    ....O.L5J5H.....
    0010: 01 00 00 09 00 01 35 03 19 12 00 09 00 05 35 03
    ......5.......5.
    0020: 19 10 02 09 00 09 35 08 35 06 19 12 00 09 01 02
    ......5.5.......
    0030: 09 02 00 09 01 02 09 02 01 09 00 0a 09 02 02 09
    ................
    0040: 00 00 09 02 03 09 00 00 09 02 04 28 01 09 02 05
    ...........(....
    0050: 09 00 02 00 ....
    2011-09-16 18:08:46.626057 < HCI Command: Authentication Requested
    (0x01|0x0011) plen 2
    handle 1
    2011-09-16 18:08:46.627614 > HCI Event: Command Status (0x0f) plen 4
    Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
    2011-09-16 18:08:46.627675 > HCI Event: Link Key Request (0x17) plen 6
    bdaddr 00:00:F2:6A:29:69
    2011-09-16 18:08:46.634999 < HCI Command: Link Key Request Reply
    (0x01|0x000b) plen 22
    bdaddr 00:00:F2:6A:29:69 key 58CD393179FC902E5E8F512A855EE532
    2011-09-16 18:08:46.683278 > HCI Event: Command Complete (0x0e) plen 10
    Link Key Request Reply (0x01|0x000b) ncmd 1
    status 0x00 bdaddr 00:00:F2:6A:29:69
    2011-09-16 18:08:46.764729 > HCI Event: Auth Complete (0x06) plen 3
    status 0x00 handle 1
    2011-09-16 18:08:46.764821 < ACL data: handle 1 flags 0x00 dlen 12
    0000: 08 00 01 00 02 05 04 00 03 00 41 00 ..........A.
    2011-09-16 18:08:46.764851 > HCI Event: Command Status (0x0f) plen 4
    Unknown (0x00|0x0000) status 0x00 ncmd 2
    2011-09-16 18:08:46.768117 > HCI Event: Number of Completed Packets
    (0x13) plen 5
    handle 1 packets 1
    2011-09-16 18:08:46.770894 > ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0041 result 3 status 0
    Connection refused - security block
    2011-09-16 18:08:49.000691 < ACL data: handle 1 flags 0x00 dlen 12
    0000: 08 00 01 00 06 06 04 00 40 00 40 00 ........@.@.
    2011-09-16 18:08:49.015675 > HCI Event: Number of Completed Packets
    (0x13) plen 5
    handle 1 packets 1
    2011-09-16 18:08:49.016927 > ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
    2011-09-16 18:08:51.009480 < HCI Command: Disconnect (0x01|0x0006) plen
    3
    handle 1 reason 0x13
    Reason: Remote User Terminated Connection
    2011-09-16 18:08:51.011525 > HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
    2011-09-16 18:08:51.123494 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 1 reason 0x16
    Reason: Connection Terminated by Local Host

    Signed-off-by: Arek Lichwa
    Signed-off-by: Gustavo F. Padovan

    Arek Lichwa
     

03 Nov, 2011

1 commit


01 Nov, 2011

4 commits

  • These files are non modular, but need to export symbols using
    the macros now living in export.h -- call out the include so
    that things won't break when we remove the implicit presence
    of module.h from everywhere.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     
  • With calls to modular infrastructure, these files really
    needs the full module.h header. Call it out so some of the
    cleanups of implicit and unrequired includes elsewhere can be
    cleaned up.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     
  • The HCI_MGMT flag should only be set when user space requests the full
    controller information. This way we avoid potential issues with setting
    change events ariving before the actual read_controller_info command
    finishes.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Gustavo F. Padovan

    Johan Hedberg
     
  • I've noticed that my CSR usb dongle was not working if it was plugged in when
    PC was booting. It looks like I get two HCI reset command complete events (see
    hcidump logs below).
    The root cause is reset called from off_timer. Timeout for this reset to
    complete is set to 250ms and my bt dongle requires more time for replying with
    command complete event. After that, chip seems to reply with reset command
    complete event for next non-reset command.

    Attached patch increase mentioned timeout to HCI_INIT_TIMEOUT, this value is
    already used for timeouting hci_reset_req in hci_dev_reset().

    This might also be related to BT not working after suspend that was reported
    here some time ago.

    Hcidump log:

    2011-09-12 23:13:27.379465 < HCI Command: Reset (0x03|0x0003) plen 0
    2011-09-12 23:13:27.380797 > HCI Event: Command Complete (0x0e) plen 4
    Reset (0x03|0x0003) ncmd 1
    status 0x00
    2011-09-12 23:13:27.380859 < HCI Command: Read Local Supported Features (0x04|0x000
    3) plen 0
    2011-09-12 23:13:27.760789 > HCI Event: Command Complete (0x0e) plen 4
    Reset (0x03|0x0003) ncmd 1
    status 0x00
    2011-09-12 23:13:27.760831 < HCI Command: Read Local Version Information (0x04|0x00
    01) plen 0
    2011-09-12 23:13:27.764780 > HCI Event: Command Complete (0x0e) plen 12
    Read Local Version Information (0x04|0x0001) ncmd 1
    status 0x00
    HCI Version: 1.1 (0x1) HCI Revision: 0x36f
    LMP Version: 1.1 (0x1) LMP Subversion: 0x36f
    Manufacturer: Cambridge Silicon Radio (10)

    Signed-off-by: Szymon Janc
    Signed-off-by: Gustavo F. Padovan

    Szymon Janc
     

25 Oct, 2011

1 commit


19 Oct, 2011

1 commit

  • The Bluetooth stack has internal connection handlers for all of the various
    Bluetooth protocols, and unfortunately, they are currently lacking the LSM
    hooks found in the core network stack's connection handlers. I say
    unfortunately, because this can cause problems for users who have have an
    LSM enabled and are using certain Bluetooth devices. See one problem
    report below:

    * http://bugzilla.redhat.com/show_bug.cgi?id=741703

    In order to keep things simple at this point in time, this patch fixes the
    problem by cloning the parent socket's LSM attributes to the newly created
    child socket. If we decide we need a more elaborate LSM marking mechanism
    for Bluetooth (I somewhat doubt this) we can always revisit this decision
    in the future.

    Reported-by: James M. Cape
    Signed-off-by: Paul Moore
    Acked-by: James Morris
    Signed-off-by: David S. Miller

    Paul Moore
     

15 Oct, 2011

1 commit

  • This was triggered by turning off encryption on ACL link when rfcomm
    was using high security. rfcomm_security_cfm (which is called from rx
    task) was closing DLC and this involves sending disconnect message
    (and locking socket).

    Move closing DLC to rfcomm_process_dlcs and only flag DLC for closure
    in rfcomm_security_cfm.

    BUG: sleeping function called from invalid context at net/core/sock.c:2032
    in_atomic(): 1, irqs_disabled(): 0, pid: 1788, name: kworker/0:3
    [] (unwind_backtrace+0x0/0x108) from [] (dump_stack+0x20/0x24)
    [] (dump_stack+0x20/0x24) from [] (__might_sleep+0x110/0x12c)
    [] (__might_sleep+0x110/0x12c) from [] (lock_sock_nested+0x2c/0x64)
    [] (lock_sock_nested+0x2c/0x64) from [] (l2cap_sock_sendmsg+0x58/0xcc)
    [] (l2cap_sock_sendmsg+0x58/0xcc) from [] (sock_sendmsg+0xb0/0xd0)
    [] (sock_sendmsg+0xb0/0xd0) from [] (kernel_sendmsg+0x3c/0x44)
    [] (kernel_sendmsg+0x3c/0x44) from [] (rfcomm_send_frame+0x50/0x58)
    [] (rfcomm_send_frame+0x50/0x58) from [] (rfcomm_send_disc+0x78/0x80)
    [] (rfcomm_send_disc+0x78/0x80) from [] (__rfcomm_dlc_close+0x2d0/0x2fc)
    [] (__rfcomm_dlc_close+0x2d0/0x2fc) from [] (rfcomm_security_cfm+0x140/0x1e0)
    [] (rfcomm_security_cfm+0x140/0x1e0) from [] (hci_event_packet+0x1ce8/0x4d84)
    [] (hci_event_packet+0x1ce8/0x4d84) from [] (hci_rx_task+0x1d0/0x2d0)
    [] (hci_rx_task+0x1d0/0x2d0) from [] (tasklet_action+0x138/0x1e4)
    [] (tasklet_action+0x138/0x1e4) from [] (__do_softirq+0xcc/0x274)
    [] (__do_softirq+0xcc/0x274) from [] (do_softirq+0x60/0x6c)
    [] (do_softirq+0x60/0x6c) from [] (local_bh_enable_ip+0xc8/0xd4)
    [] (local_bh_enable_ip+0xc8/0xd4) from [] (_raw_spin_unlock_bh+0x48/0x4c)
    [] (_raw_spin_unlock_bh+0x48/0x4c) from [] (data_from_chip+0xf4/0xaec)
    [] (data_from_chip+0xf4/0xaec) from [] (send_skb_to_core+0x40/0x178)
    [] (send_skb_to_core+0x40/0x178) from [] (cg2900_hu_receive+0x15c/0x2d0)
    [] (cg2900_hu_receive+0x15c/0x2d0) from [] (hci_uart_tty_receive+0x74/0xa0)
    [] (hci_uart_tty_receive+0x74/0xa0) from [] (flush_to_ldisc+0x188/0x198)
    [] (flush_to_ldisc+0x188/0x198) from [] (process_one_work+0x144/0x4b8)
    [] (process_one_work+0x144/0x4b8) from [] (worker_thread+0x198/0x468)
    [] (worker_thread+0x198/0x468) from [] (kthread+0x98/0xa0)
    [] (kthread+0x98/0xa0) from [] (kernel_thread_exit+0x0/0x8)

    Signed-off-by: Szymon Janc
    Signed-off-by: Gustavo F. Padovan

    Szymon Janc
     

12 Oct, 2011

1 commit


01 Oct, 2011

1 commit


30 Sep, 2011

2 commits


28 Sep, 2011

5 commits

  • Signed-off-by: Szymon Janc
    Signed-off-by: Gustavo F. Padovan

    Szymon Janc
     
  • The new connection parameters now match the recommended values for
    Proximity and Health Thermometer profiles. The previous values were
    ramdomly chosen, and are either too low or too high for most cases.

    New values:

    Scan Interval: 60 ms
    Scan Window: 30 ms
    Minimum Connection Interval: 50 ms
    Maximum Connection Interval: 70 ms
    Supervision Timeout: 420 ms

    See "Table 5.2: Recommended Scan Interval and Scan Window Values" and
    "Table 5.3: Recommended Connection Interval Values" for both profiles
    for details. Note that the "fast connection" parameters were chosen,
    because we do not support yet dynamically changing these parameters from
    initiator side.

    Additionally, the Proximity profile recommends (section "4.4 Alert on
    Link Loss"):

    "It is recommended that the Link Supervision Timeout (LSTO) is set to 6x
    the connection interval."

    Minimum_CE_Length and Maximum_CE_Length were also changed from 0x0001 to
    0x0000 because they are informational and optional, and old value was
    not reflecting reality.

    Signed-off-by: Anderson Lizardo
    Signed-off-by: Gustavo F. Padovan

    Anderson Lizardo
     
  • Use sk_buff fragment capabilities to link together incoming skbs
    instead of allocating a new skb for reassembly and copying.

    The new reassembly code works equally well for ERTM and streaming
    mode, so there is now one reassembly function instead of two.

    Signed-off-by: Mat Martineau
    Signed-off-by: Gustavo F. Padovan

    Mat Martineau
     
  • ERTM reassembly will be more efficient when skbs are linked together
    rather than copying every incoming data byte. The existing stream recv
    function assumes skbs are linear, so it needs to know how to handle
    fragments before reassembly is changed.

    bt_sock_recvmsg() already handles fragmented skbs.

    Signed-off-by: Mat Martineau
    Signed-off-by: Gustavo F. Padovan

    Mat Martineau
     
  • Fragmented skbs are only encountered when receiving ERTM or streaming
    mode L2CAP data. BNEP, CMTP, HIDP, and RFCOMM generally use basic
    mode, but they need to handle fragments without crashing.

    Signed-off-by: Mat Martineau
    Signed-off-by: Gustavo F. Padovan

    Mat Martineau
     

22 Sep, 2011

1 commit

  • Conflicts:
    MAINTAINERS
    drivers/net/Kconfig
    drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
    drivers/net/ethernet/broadcom/tg3.c
    drivers/net/wireless/iwlwifi/iwl-pci.c
    drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c
    drivers/net/wireless/rt2x00/rt2800usb.c
    drivers/net/wireless/wl12xx/main.c

    David S. Miller
     

21 Sep, 2011

18 commits