1. 15 7月, 2008 9 次提交
    • M
      [Bluetooth] Track status of remote Simple Pairing mode · 41a96212
      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: NMarcel Holtmann <marcel@holtmann.org>
      41a96212
    • M
      [Bluetooth] Track status of Simple Pairing mode · 333140b5
      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: NMarcel Holtmann <marcel@holtmann.org>
      333140b5
    • M
      [Bluetooth] Disable disconnect timer during Simple Pairing · 0493684e
      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: NMarcel Holtmann <marcel@holtmann.org>
      0493684e
    • M
      [Bluetooth] Update class of device value whenever possible · c7bdd502
      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: NMarcel Holtmann <marcel@holtmann.org>
      c7bdd502
    • M
      [Bluetooth] Some cleanups for HCI event handling · f383f275
      Marcel Holtmann 提交于
      Some minor cosmetic cleanups to the HCI event handling to make the
      code easier to read and understand.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f383f275
    • M
      [Bluetooth] Make use of the default link policy settings · e4e8e37c
      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: NMarcel Holtmann <marcel@holtmann.org>
      e4e8e37c
    • M
      [Bluetooth] Track connection packet type changes · a8746417
      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: NMarcel Holtmann <marcel@holtmann.org>
      a8746417
    • M
      [Bluetooth] Support the case when headset falls back to SCO link · 9dc0a3af
      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: NMarcel Holtmann <marcel@holtmann.org>
      9dc0a3af
    • M
      [Bluetooth] Update authentication status after successful encryption · ae293196
      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: NMarcel Holtmann <marcel@holtmann.org>
      ae293196
  2. 03 5月, 2008 1 次提交
  3. 22 10月, 2007 2 次提交
    • M
      [Bluetooth] Add support for handling simple eSCO links · b6a0dc82
      Marcel Holtmann 提交于
      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: NMarcel Holtmann <marcel@holtmann.org>
      b6a0dc82
    • M
      [Bluetooth] Switch from OGF+OCF to using only opcodes · a9de9248
      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: NMarcel Holtmann <marcel@holtmann.org>
      a9de9248
  4. 11 7月, 2007 1 次提交
  5. 26 4月, 2007 1 次提交
  6. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      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: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  7. 11 2月, 2007 1 次提交
  8. 22 11月, 2006 1 次提交
  9. 16 10月, 2006 1 次提交
    • M
      [Bluetooth] Support concurrent connect requests · 4c67bc74
      Marcel Holtmann 提交于
      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: NMarcel Holtmann <marcel@holtmann.org>
      4c67bc74
  10. 29 9月, 2006 4 次提交
  11. 04 7月, 2006 2 次提交
  12. 01 7月, 2006 1 次提交
  13. 09 11月, 2005 1 次提交
  14. 13 9月, 2005 1 次提交
  15. 30 8月, 2005 4 次提交
  16. 06 8月, 2005 2 次提交
  17. 26 4月, 2005 2 次提交
    • A
      [NET]: kill gratitious includes of major.h · 5523662c
      Al Viro 提交于
      	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: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5523662c
    • A
      [PATCH] kill gratitious includes of major.h under net/* · b453257f
      Al Viro 提交于
      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: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b453257f
  18. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4