1. 15 7月, 2008 1 次提交
    • 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
  2. 22 10月, 2007 1 次提交
    • 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
  3. 11 7月, 2007 1 次提交
  4. 26 4月, 2007 1 次提交
  5. 14 12月, 2006 1 次提交
  6. 29 9月, 2006 3 次提交
  7. 04 7月, 2006 2 次提交
  8. 09 11月, 2005 1 次提交
  9. 13 9月, 2005 1 次提交
  10. 30 8月, 2005 2 次提交
  11. 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