09 Sep, 2008

1 commit

  • The ACL config stage keeps holding a reference count on incoming
    connections when requesting the extended features. This results in
    keeping an ACL link up without any users. The problem here is that
    the Bluetooth specification doesn't define an ownership of the ACL
    link and thus it can happen that the implementation on the initiator
    side doesn't care about disconnecting unused links. In this case the
    acceptor needs to take care of this.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     

15 Jul, 2008

12 commits

  • When attaching Bluetooth low-level connections to the bus, the bus name
    is constructed from the remote address since at that time the connection
    handle is not assigned yet. This has worked so far, but also caused a
    lot of troubles. It is better to postpone the creation of the sysfs
    entry to the time when the connection actually has been established
    and then use its connection handle as unique identifier.

    This also fixes the case where two different adapters try to connect
    to the same remote device.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • With Bluetooth 2.1 and Simple Pairing the requirement is that any new
    connection needs to be authenticated and that encryption has been
    switched on before allowing L2CAP to use it. So make sure that all
    the requirements are fulfilled and otherwise drop the connection with
    a minimal disconnect timeout of 10 milliseconds.

    This change only affects Bluetooth 2.1 devices and Simple Pairing
    needs to be enabled locally and in the remote host stack. The previous
    changes made sure that these information are discovered before any
    kind of authentication and encryption is triggered.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The Bluetooth technology introduces new features on a regular basis
    and for some of them it is important that the hardware on both sides
    support them. For features like Simple Pairing it is important that
    the host stacks on both sides have switched this feature on. To make
    valid decisions, a config stage during ACL link establishment has been
    introduced that retrieves remote features and if needed also the remote
    extended features (known as remote host features) before signalling
    this link as connected.

    This change introduces full reference counting of incoming and outgoing
    ACL links and the Bluetooth core will disconnect both if no owner of it
    is present. To better handle interoperability during the pairing phase
    the disconnect timeout for incoming connections has been increased to
    10 seconds. This is five times more than for outgoing connections.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The Simple Pairing process can only be used if both sides have the
    support enabled in the host stack. The current Bluetooth specification
    has three ways to detect this support.

    If an Extended Inquiry Result has been sent during inquiry then it
    is safe to assume that Simple Pairing is enabled. It is not allowed
    to enable Extended Inquiry without Simple Pairing. During the remote
    name request phase a notification with the remote host supported
    features will be sent to indicate Simple Pairing support. Also the
    second page of the remote extended features can indicate support for
    Simple Pairing.

    For all three cases the value of remote Simple Pairing mode is stored
    in the inquiry cache for later use.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The Simple Pairing feature is optional and needs to be enabled by the
    host stack first. The Linux kernel relies on the Bluetooth daemon to
    either enable or disable it, but at any time it needs to know the
    current state of the Simple Pairing mode. So track any changes made
    by external entities and store the current mode in the HCI device
    structure.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • During the Simple Pairing process the HCI disconnect timer must be
    disabled. The way to do this is by holding a reference count of the
    HCI connection. The Simple Pairing process on both sides starts with
    an IO Capabilities Request and ends with Simple Pairing Complete.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The class of device value can only be retrieved via inquiry or during
    an incoming connection request. Outgoing connections can't ask for the
    class of device. To compensate for this the value is stored and copied
    via the inquiry cache, but currently only updated via inquiry. This
    update should also happen during an incoming connection request.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • Some minor cosmetic cleanups to the HCI event handling to make the
    code easier to read and understand.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The Bluetooth specification supports the default link policy settings
    on a per host controller basis. For every new connection the link
    manager would then use these settings. It is better to use this instead
    of bothering the controller on every connection setup to overwrite the
    default settings.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The connection packet type can be changed after the connection has been
    established and thus needs to be properly tracked to ensure that the
    host stack has always correct and valid information about it.

    On incoming connections the Bluetooth core switches the supported packet
    types to the configured list for this controller. However the usefulness
    of this feature has been questioned a lot. The general consent is that
    every Bluetooth host stack should enable as many packet types as the
    hardware actually supports and leave the decision to the link manager
    software running on the Bluetooth chip.

    When running on Bluetooth 2.0 or later hardware, don't change the packet
    type for incoming connections anymore. This hardware likely supports
    Enhanced Data Rate and thus leave it completely up to the link manager
    to pick the best packet type.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • When trying to establish an eSCO link between two devices then it can
    happen that the remote device falls back to a SCO link. Currently this
    case is not handled correctly and the message dispatching will break
    since it is looking for eSCO packets. So in case the configured link
    falls back to SCO overwrite the link type with the correct value.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The authentication status is not communicated to both parties. This is
    actually a flaw in the Bluetooth specification. Only the requesting side
    really knows if the authentication was successful or not. This piece of
    information is however needed on the other side to know if it has to
    trigger the authentication procedure or not. Worst case is that both
    sides will request authentication at different times, but this should
    be avoided since it costs extra time when setting up a new connection.

    For Bluetooth encryption it is required to authenticate the link first
    and the encryption status is communicated to both sides. So when a link
    is switched to encryption it is possible to update the authentication
    status since it implies an authenticated link.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     

03 May, 2008

1 commit


22 Oct, 2007

2 commits

  • With the Bluetooth 1.2 specification the Extended SCO feature for
    better audio connections was introduced. So far the Bluetooth core
    wasn't able to handle any eSCO connections correctly. This patch
    adds simple eSCO support while keeping backward compatibility with
    older devices.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     
  • The Bluetooth HCI commands are divided into logical OGF groups for
    easier identification of their purposes. While this still makes sense
    for the written specification, its makes the code only more complex
    and harder to read. So instead of using separate OGF and OCF values
    to identify the commands, use a common 16-bit opcode that combines
    both values. As a side effect this also reduces the complexity of
    OGF and OCF calculations during command header parsing.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     

11 Jul, 2007

1 commit


26 Apr, 2007

1 commit


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


22 Nov, 2006

1 commit


16 Oct, 2006

1 commit

  • Most Bluetooth chips don't support concurrent connect requests, because
    this would involve a multiple baseband page with only one radio. In the
    case an upper layer like L2CAP requests a concurrent connect these chips
    return the error "Command Disallowed" for the second request. If this
    happens it the responsibility of the Bluetooth core to queue the request
    and try again after the previous connect attempt has been completed.

    Signed-off-by: Marcel Holtmann

    Marcel Holtmann
     

29 Sep, 2006

4 commits


04 Jul, 2006

2 commits


01 Jul, 2006

1 commit


09 Nov, 2005

1 commit


13 Sep, 2005

1 commit


30 Aug, 2005

4 commits


06 Aug, 2005

2 commits


26 Apr, 2005

1 commit

  • A lot of places in there are including major.h for no reason whatsoever.
    Removed. And yes, it still builds.

    The history of that stuff is often amusing. E.g. for net/core/sock.c
    the story looks so, as far as I've been able to reconstruct it: we used
    to need major.h in net/socket.c circa 1.1.early. In 1.1.13 that need
    had disappeared, along with register_chrdev(SOCKET_MAJOR, "socket",
    &net_fops) in sock_init(). Include had not. When 1.2 -> 1.3 reorg of
    net/* had moved a lot of stuff from net/socket.c to net/core/sock.c,
    this crap had followed...

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds