- 12 Apr, 2017 40 commits
-
-
Harry Morris authored
Add driver source and config for softMAC implementation of Cascoda's CA8210 IEEE 802.15.4 transceiver device. The driver mimics a common PHY-only implementation despite the CA8210 being a hardMAC device which exposes a SAP interface to the fully integrated MAC. The chip is a modem-only device with an integrated processor which runs the 802.15.4 MAC. The chip communicates via full-duplex SPI with additional pins for NIRQ and NRESET. The chip can also output its 16MHz clock to a GPIO with a configurable divider. The driver can be configured to implement a debugfs node that provides access to the SAP-based API to drive mechanisms not currently supported by the standard kernel interface. Signed-off-by:
Harry Morris <h.morris@cascoda.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Andy Shevchenko authored
Until now the driver supports only ACPI enumeration. Nevertheless Intel Edison SoM has Broadcom Wi-Fi + BT chip and neither ACPI nor DT enumeration mechanism. Enable pure platform driver in order to support Intel Edison SoM. Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Jeffy Chen authored
Currrently we are disabling this wake irq after receiving it. If this happens before we finish suspend and the pm event check is disabled, the system will continue suspending, and this irq would not work again. We may need to abort system suspend to avoid that. Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by:
-
Jeffy Chen authored
Currrently we are disabling this wake irq after receiving it. If this happens before we finish suspend and the pm event check is disabled, the system will continue suspending, and this irq would not work again. We may need to abort system suspend to avoid that. Signed-off-by:
-
Larry Finger authored
The message concerning missing config files for 8723b, 8821a, and 8761a should have been issued with BT_INFO() rather than BT_ERR() as this condition is not fatal. After looking at that code, I have reworked the logic to log such messages only if the device needs such a config file. At the moment, only the 8822b fits that description. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
陆朱伟 <alex_lu@realsil.com.cn> Signed-off-by:
-
Gabriel authored
Signed-off-by: -
Jonas Holmberg authored
Use the initial connection interval recommended in Bluetooth Specification v4.2 (30ms - 50ms). Signed-off-by:
Jonas Holmberg <jonashg@axis.com> Signed-off-by:
-
Colin Ian King authored
Variable err is being initialized to zero and then later being set to the error return from the call to hci_req_run_skb; hence we can remove the redundant initialization to zero. Also on two occassions err is not being set from the error return from the call to hci_req_run_skb, so add these missing assignments. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Tedd Ho-Jeong An authored
This patch adds support for Intel Bluetooth device 9160/9260 also known as ThunderPeak(ThP) for UART. Signed-off-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
-
Tedd Ho-Jeong An authored
The format of Intel Bluetooth firmware for bootloader product is ibt-<hw_variant>-<device_revision_id>.sfi and .ddc. This patch uses a hw_variant value read from the device during runtime to form the firmware filenames instead of using a constant value, so it can support multiple prouducts. Signed-off-by:
-
Marcel Holtmann authored
The new Bluetooth devices 9160/9260 (also known as ThunderPeak) devices from Intel use the same firmware loading mechanism as previous generation. So include the new USB product identifier and whitelist the hardware variant. T: Bus=02 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 8 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0025 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Bluetooth: hci0: Bootloader revision 0.1 build 42 week 52 2015 Bluetooth: hci0: Device revision is 2 Bluetooth: hci0: Secure boot is enabled Bluetooth: hci0: OTP lock is disabled Bluetooth: hci0: API lock is disabled Bluetooth: hci0: Debug lock is disabled Bluetooth: hci0: Minimum firmware build 1 week 10 2014 < HCI Command: Read Local Version Information (0x04|0x0001) plen 0 > HCI Event: Command Complete (0x0e) plen 12 Read Local Version Information (0x04|0x0001) ncmd 1 Status: Success (0x00) HCI version: Bluetooth 5.0 (0x09) - Revision 256 (0x0100) LMP version: Bluetooth 5.0 (0x09) - Subversion 256 (0x0100) Manufacturer: Intel Corp. (2) Based on original patch from Jaya Praveen G <jaya.p.g@linux.intel.com> Signed-off-by: -
Tedd Ho-Jeong An authored
Multiple new hardware variants are planned and the simple if statement would get really complicated and unreadable. So instead replace it with a simple switch statement. The change is applied to both USB and UART. Based-on-patch-by:
-
Marcin Kraglak authored
Fix issue found during L2CAP qualification test TP/LE/CFC/BV-20-C. Signed-off-by:
Marcin Kraglak <marcin.kraglak@tieto.com> Signed-off-by:
-
Dean Jenkins authored
There is a race condition between a thread calling bt_accept_dequeue() and a different thread calling bt_accept_unlink(). Protection against concurrency is implemented using sk locking. However, sk locking causes serialisation of the bt_accept_dequeue() and bt_accept_unlink() threads. This serialisation can cause bt_accept_dequeue() to obtain the sk from the parent list but becomes blocked waiting for the sk lock held by the bt_accept_unlink() thread. bt_accept_unlink() unlinks sk and this thread releases the sk lock unblocking bt_accept_dequeue() which potentially runs bt_accept_unlink() again on the same sk causing a crash. The attempt to double unlink the same sk from the parent list can cause a NULL pointer dereference crash due to bt_sk(sk)->parent becoming NULL on the first unlink, followed by the second unlink trying to execute bt_sk(sk)->parent->sk_ack_backlog-- in bt_accept_unlink() which crashes. When sk is in the parent list, bt_sk(sk)->parent will be not be NULL. When sk is removed from the parent list, bt_sk(sk)->parent is set to NULL. Therefore, add a defensive check for bt_sk(sk)->parent not being NULL to ensure that sk is still in the parent list after the sk lock has been taken in bt_accept_dequeue(). If bt_sk(sk)->parent is detected as being NULL then restart the loop so that the loop variables are refreshed to use the latest values. This is necessary as list_for_each_entry_safe() is not thread safe so causing a risk of an infinite loop occurring as sk could point to itself. In addition, in bt_accept_dequeue() increase the sk reference count to protect against early freeing of sk. Early freeing can be possible if the bt_accept_unlink() thread calls l2cap_sock_kill() or rfcomm_sock_kill() functions before bt_accept_dequeue() gets the sk lock. For test purposes, the probability of failure can be increased by putting a msleep of 1 second in bt_accept_dequeue() between getting the sk and waiting for the sk lock. This exposes the fact that the loop list_for_each_entry_safe(p, n, &bt_sk(parent)->accept_q) is not safe from threads that unlink sk from the list in parallel with the loop which can cause sk to become stale within the loop. Signed-off-by:
Dean Jenkins <Dean_Jenkins@mentor.com> Signed-off-by:
-
Dean Jenkins authored
There is a small risk that bt_accept_unlink() runs concurrently with bt_accept_enqueue() on the same socket. This scenario could potentially lead to a NULL pointer dereference of the socket's parent member because the socket can be on the list but the socket's parent member is not yet updated by bt_accept_enqueue(). Therefore, add socket locking inside bt_accept_enqueue() so that the socket is added to the list AND the parent's socket address is set in the socket's parent member. The socket locking ensures that the socket is on the list with a valid non-NULL parent member. Signed-off-by:
-
Geliang Tang authored
Use setup_timer() instead of init_timer() to simplify the code. Signed-off-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
According to RFC 7668 U/L bit shall not be used: https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]: In the figure, letter 'b' represents a bit from the Bluetooth device address, copied as is without any changes on any bit. This means that no bit in the IID indicates whether the underlying Bluetooth device address is public or random. |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb| +----------------+----------------+----------------+----------------+ Because of this the code cannot figure out the address type from the IP address anymore thus it makes no sense to use peer_lookup_ba as it needs the peer address type. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Reviewed-by:
Stefan Schmidt <stefan@osg.samsung.com> Acked-by:
Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
This allow technologies such as Bluetooth to use its native lladdr which is eui48 instead of eui64 which was expected by functions like lowpan_header_decompress and lowpan_header_compress. Signed-off-by:
-
Alexander Aring authored
This patch adds support for 48 bit 6LoWPAN address length autoconfiguration which is the case for BTLE 6LoWPAN. Signed-off-by:
Alexander Aring <aar@pengutronix.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alexander Aring authored
The skb->pkt_type need to be set by L2, but on 6LoWPAN there exists L2 e.g. BTLE which doesn't has multicast addressing. If it's a multicast or not is detected by IPHC headers multicast bit. The IPv6 layer will evaluate this pkt_type, so we force set this type while uncompressing. Should be okay for 802.15.4 as well. Signed-off-by:
-
Patrik Flykt authored
Set MAC address length according to the 6LoWPAN link layer in use. Bluetooth Low Energy uses 48 bit addressing while IEEE802.15.4 uses 64 bits. Signed-off-by:
Patrik Flykt <patrik.flykt@linux.intel.com> Reviewed-by:
-
Patrik Flykt authored
Set BTLE MAC addresses that are 6 bytes long and not 8 bytes that are used in other places with 6lowpan. Signed-off-by:
-
John Keeping authored
The hci_bcm driver currently does not prepare/unprepare the clock and goes directly to enable, but as the documentation for clk_enable says, clk_prepare must be called before clk_enable. Signed-off-by:
John Keeping <john@metanate.com> Signed-off-by:
-
Elena Reshetova authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
Elena Reshetova <elena.reshetova@intel.com> Signed-off-by:
Hans Liljestrand <ishkamiel@gmail.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
David Windsor <dwindsor@gmail.com> Signed-off-by:
-
Colin Ian King authored
trivial fix to spelling mistake in debug message Signed-off-by:
-
Alexey Dobriyan authored
This field is never big enough to warrant 16-bitness. 8-bit accesses enjoy shorted encoding on i386/x86_64 than 16-bit accesses: add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-10 (-10) function old new delta loopback_setup 169 164 -5 ether_setup 148 143 -5 Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
Using 16-bit ->hh_len doesn't save any memory, save some .text instead: add/remove: 0/0 grow/shrink: 1/6 up/down: 2/-19 (-17) function old new delta neigh_update 2312 2314 +2 fwnet_header_cache 199 197 -2 eth_header_cache 101 99 -2 ip6_finish_output2 2371 2368 -3 vrf_finish_output6 1522 1518 -4 vrf_finish_output 1413 1409 -4 ip_finish_output2 1627 1623 -4 Signed-off-by:
-
Ilan Tayari authored
A driver may use build_skb() for received packets. These SKBs then have a head_frag. Since commit d7e8883c ("net: make GRO aware of skb->head_frag"), GRO may build frag_list SKBs out of head_frag received SKBs. In such a case, the chained SKBs end up with a head_frag. Commit 07b26c94 ("gso: Support partial splitting at the frag_list pointer") adds partial segmentation of frag_list SKB chains into individual SKBs. However, this is not done if the chained SKBs have any linear part, because the device may not be able to DMA the private linear buffer. A chained frag_list SKB with head_frag is wrongfully detected in this case as having a private linear part and thus falls back to software GSO, while in fact the linear part is backed by a DMA page just like any other frag. This causes low performance when forwarding those packets that were built with build_skb() Allow partial segmentation at the frag_list pointer for chained SKBs with head_frag. Note that such SKBs can only be created by GRO, when applied to received packets with head_frag. Also note that this change only affects the data path that performs the partial segmentation at frag_list pointer, and not any of the other more common data paths. Signed-off-by:
Ilan Tayari <ilant@mellanox.com> Signed-off-by:
-
David S. Miller authored
Guillaume Nault says: ==================== l2tp: constify l2tp_session_get*() and l2tp_tunnel_find*() Declare parameters of these functions as "const" where possible. ==================== Signed-off-by: -
Guillaume Nault authored
l2tp_tunnel_find() and l2tp_tunnel_find_nth() don't modify "net". Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
Guillaume Nault authored
Make l2tp_pernet()'s parameter constant, so that l2tp_session_get*() can declare their "net" variable as "const". Also constify "ifname" in l2tp_session_get_by_ifname(). Signed-off-by:
-
David S. Miller authored
Benjamin Herrenschmidt says: ==================== ftgmac100: Rework batch 4 - Misc This is v2 of the fourth batch of updates to the ftgmac100 driver. This is a bunch of misc cleanups and fixes, such as properly disabling HW checksum generation on AST2400 where it's known to be broken and some chip init updates. This also adds the ability to turn HW checksum on/off and configure the ring sizes via ethtool. v2 Fixes patch 1/10 (NETIF_F_HW_CSUM conversion) The next (and last) batch will add a few more "features" such as netpoll, multicast/promist, vlan offload... ==================== Signed-off-by: -
Benjamin Herrenschmidt authored
I haven't seen any improvement above that size on the machines I've tested with. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
We set an arbitrary max at 1024 since we pre-allocate the actual descriptor arrays and skb arrays to the full size to keep the code a bit simpler and avoid allocation failures in the reset task. Signed-off-by:
-
Benjamin Herrenschmidt authored
Clear stale interrupts on entry, configure FIFO sizes, set FIFO thresholds, configure interrupt mitigation. Signed-off-by:
-
Benjamin Herrenschmidt authored
The helpers just take space but don't provide much value. Simple one line comments are more explanatory. Signed-off-by:
-
Benjamin Herrenschmidt authored
To remove more confusion. This function is about obtaining the initial MAC address at driver probe time. Signed-off-by:
-
Benjamin Herrenschmidt authored
To avoid confusion with the ndo callback and generally be clearer about the purpose of that function Signed-off-by:
-
Benjamin Herrenschmidt authored
So features can be turned on/off via ethtool Signed-off-by:
-
Benjamin Herrenschmidt authored
We found out that HW checksum generation only works from AST2500 onward. This disables it on AST2400 and removes the "no-hw-checksum" properties in the device-trees. The problem we had wasn't related to NC-SI. Also rework the logic testing for that property so it can be used to disable HW checksum generation and checking regardless of whether NC-SI is used or not in case other variants out there need this. Signed-off-by:
-
