- 13 3月, 2014 1 次提交
-
-
由 Arnd Bergmann 提交于
Commit 97550887 "Bluetooth: make bluetooth 6lowpan as an option" ensures that 6LOWPAN_IPHC is turned on when we have BT_6LOWPAN enabled in Kconfig, but it allows building the IPHC code as a loadable module even if the entire Bluetooth stack is built-in, and that causes a link error. We can solve that by moving the 'select' statement into CONFIG_BT, which is a "tristate" option to enforce that 6LOWPAN_IPHC can only be a module if BT also is a module. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
- 11 3月, 2014 1 次提交
-
-
由 Alexander Aring 提交于
Currently you can have bluetooth 6lowpan without ipv6 enabled. This doesn't make any sense. With this patch you can disable/enable bluetooth 6lowpan support at compile time. The current bluetooth 6lowpan implementation doesn't check the return value of 6lowpan function. Nevertheless I added -EOPNOTSUPP as return value if 6lowpan bluetooth is disabled. Signed-off-by: NAlexander Aring <alex.aring@gmail.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
- 16 1月, 2014 1 次提交
-
-
由 Dmitry Eremin-Solenikov 提交于
IEEE 802.15.4 and Bluetooth networking stacks share 6lowpan compression code. Instead of introducing Makefile/Kconfig hacks, build this code as a separate module referenced from both ieee802154 and bluetooth modules. This fixes the following build error observed in some kernel configurations: net/built-in.o: In function `header_create': 6lowpan.c:(.text+0x166149): undefined reference to `lowpan_header_compress' net/built-in.o: In function `bt_6lowpan_recv': (.text+0x166b3c): undefined reference to `lowpan_process_data' Reported-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NDmitry Eremin-Solenikov <dmitry_eremin@mentor.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 10月, 2012 1 次提交
-
-
由 Syam Sidhardhan 提交于
Trivial fix. Signed-off-by: NSyam Sidhardhan <s.syam@samsung.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 28 9月, 2012 1 次提交
-
-
由 Andrei Emeltchenko 提交于
Function calculates AMP keys using hmac_sha256 helper. Calculated keys are Generic AMP Link Key (gamp) and Dedicated AMP Link Key with keyID "802b" for 802.11 PAL. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 01 3月, 2012 1 次提交
-
-
由 Andre Guedes 提交于
SMP is not a kernel module, it is part of Bluetooth Core (as already described in lines above). Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Acked-by: NGustavo F. Padovan <padovan@profusion.mobi> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
- 21 12月, 2011 1 次提交
-
-
由 Ulisses Furquim 提交于
The handling of SCO audio links and the L2CAP protocol are essential to any system with Bluetooth thus are always compiled in from now on. Signed-off-by: NUlisses Furquim <ulisses@profusion.mobi> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 28 6月, 2011 2 次提交
-
-
由 Randy Dunlap 提交于
Recent changes to hci_core.c use crypto interfaces, so select CRYPTO to make sure that those interfaces are present. Fixes these build errors when CRYPTO is not enabled: net/built-in.o: In function `hci_register_dev': (.text+0x4cf86): undefined reference to `crypto_alloc_base' net/built-in.o: In function `hci_unregister_dev': (.text+0x4f912): undefined reference to `crypto_destroy_tfm' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Randy Dunlap 提交于
Recent changes to hci_core.c use crypto interfaces, so select CRYPTO to make sure that those interfaces are present. Fixes these build errors when CRYPTO is not enabled: net/built-in.o: In function `hci_register_dev': (.text+0x4cf86): undefined reference to `crypto_alloc_base' net/built-in.o: In function `hci_unregister_dev': (.text+0x4f912): undefined reference to `crypto_destroy_tfm' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 14 6月, 2011 1 次提交
-
-
由 Vinicius Costa Gomes 提交于
This will allow using the crypto subsystem for encrypting data. As SMP (Security Manager Protocol) is implemented almost entirely on the host side and the crypto module already implements the needed methods (AES-128), it makes sense to use it. There's now a new module option to enable/disable SMP support. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NAnderson Briglia <anderson.briglia@openbossa.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 01 3月, 2011 1 次提交
-
-
由 Gustavo F. Padovan 提交于
If we want something "bool" built-in in something "tristate" it can't "depend on" the tristate config option. Report by DaveM: I give it 'y' just to make it happen, for both, and afterways no matter how many times I rerun "make oldconfig" I keep seeing things like this in my build: scripts/kconfig/conf --silentoldconfig Kconfig include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP Reported-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 2月, 2011 1 次提交
-
-
由 Gustavo F. Padovan 提交于
Actually doesn't make sense have these modules built separately. The L2CAP layer is needed by almost all Bluetooth protocols and profiles. There isn't any real use case without having L2CAP loaded. SCO is only essential for Audio transfers, but it is so small that we can have it loaded always in bluetooth.ko without problems. If you really doesn't want it you can disable SCO in the kernel config. Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 08 2月, 2011 1 次提交
-
-
由 Gustavo F. Padovan 提交于
Change hcid to bluetoothd. Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 22 7月, 2010 1 次提交
-
-
由 Gustavo F. Padovan 提交于
This reverts commit 84fb0a63 which adds the L2CAP Extended Features to the Kconfig, that is actually not needed. One can use other mechanisms to enable L2CAP Extended Features. Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
- 10 5月, 2010 1 次提交
-
-
由 Gustavo F. Padovan 提交于
The L2CAP Extended Features are still unstable and under development, so we are adding them under the EXPERIMENTAL flag to get more feedback on them. L2CAP Extended Features includes the Enhanced Retransmission and Streaming Modes, Frame Check Sequence (FCS), and Segmentation and Reassemby (SAR). Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi> Reviewed-by: NJoão Paulo Rechi Vita <jprvita@profusion.mobi> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
- 25 8月, 2009 1 次提交
-
-
由 Randy Dunlap 提交于
Fix net/bluetooth/l2cap.c build errors: l2cap.c:(.text+0x126035): undefined reference to `crc16' l2cap.c:(.text+0x126323): undefined reference to `crc16' l2cap.c:(.text+0x12668e): undefined reference to `crc16' l2cap.c:(.text+0x12683b): undefined reference to `crc16' l2cap.c:(.text+0x126956): undefined reference to `crc16' net/built-in.o:l2cap.c:(.text+0x129041): more undefined references to `crc16' follow Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
- 14 6月, 2009 1 次提交
-
-
由 Marcel Holtmann 提交于
Since the re-write of the RFKILL subsystem it is no longer good to just select RFKILL, but it is important to add a proper depends on rule. Based on a report by Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
- 10 5月, 2007 1 次提交
-
-
由 Martin Schwidefsky 提交于
Disable some more menus in the configuration files that are of no interest to a s390 machine. Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 17 4月, 2005 1 次提交
-
-
由 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!
-