- 19 Dec, 2018 3 commits
-
-
Jonathan Bakker authored
The Broadcom controller on aries S5PV210 boards sends out a couple of unknown packets after the firmware is loaded. This will cause logging of errors such as: Bluetooth: hci0: Frame reassembly failed (-84) This is probably also the case with other boards, as there are related Android userspace patches for custom ROMs such as https://review.lineageos.org/#/c/LineageOS/android_system_bt/+/142721/ Since this appears to be intended behaviour, treated them as diagnostic packets. Note that this is another variant of commit 01d5e44a ("Bluetooth: hci_bcm: Handle empty packet after firmware loading") Signed-off-by:
Jonathan Bakker <xc-racer2@live.ca> Signed-off-by:
Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Paweł Chmiel authored
This patch adds the device ID for the BCM 4329 combo module used in the Samsung Aries based phones (Galaxy S and it's variants). ``` [ 11.508980] Bluetooth: hci0: BCM: chip id 41 [ 11.518975] Bluetooth: hci0: BCM: features 0x04 [ 11.550132] Bluetooth: hci0: BCM4329B1 [ 11.557046] Bluetooth: hci0: BCM4329B1 (002.002.023) build 0000 [ 13.737071] Bluetooth: hci0: BCM4329B1 (002.002.023) build 0744 ``` Output from hciconfig ``` hci0: Type: Primary Bus: UART BD Address: 43:29:B1:55:00:00 ACL MTU: 1021:6 SCO MTU: 64:1 UP RUNNING RX bytes:1675 acl:0 sco:0 events:145 errors:0 TX bytes:20426 acl:0 sco:0 commands:146 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0x9b 0xff 0x79 0x83 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'aries' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 2.1 (0x4) Revision: 0x2e8 LMP Version: 2.1 (0x4) Subversion: 0x4217 Manufacturer: Broadcom Corporation (15) ``` Signed-off-by: -
Raghuram Hegde authored
Include the new USB product ID for Intel Bluetooth device 22260 family(CcPeak) The /sys/kernel/debug/usb/devices portion for this device is: T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0029 Rev= 0.01 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 Signed-off-by:
Raghuram Hegde <raghuram.hegde@intel.com> Signed-off-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by:
-
- 18 Dec, 2018 37 commits
-
-
Hans de Goede authored
On many devices the RTL8723BS device gets reset during suspend/resume, causing it to lose its firmware and all state. Testing has shown it drops back to communicating at 115200 bps and sends sync-request packages, indicating it has been fully reset. This commit fixes this by queueing a reprobe on resume. This mirrors how USB RTL BT devices, which have the same problem, are handled in the btusb driver, there we set the USB_QUIRK_RESET_RESUME for all RTL devices, which also causes a reprobe on resume. The only difference is that here we need to do the reprobe ourselves. Since we are doing a full reprobe on resume now, we can also turn off the device on suspend to save power while suspended. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
Add support for vendor specific suspend / resume callbacks. Signed-off-by:
-
Colin Ian King authored
Trivial fix to clean up an indentation issue, remove spaces Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
Trivial fix to clean up an indentation issue Signed-off-by:
-
Balakrishna Godavarthi authored
HCI_QUIRK_RESET_ON_CLOSE quirk is required for BT v1.0 based devices, to send a reset command to the chip during hci device close. Serdev architecture is used for the latest BT chips, which doesn't require to send the reset command during close. If still chips required reset command during close, it would be better enabling it in the vendor probes or in proto setup. Signed-off-by:
Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by:
-
Andrea Parri authored
The barriers are redundant because atomic_test_and_clear_bit() already provides the required full ordering for the cases in question (that is, when the bit is cleared). Signed-off-by:
Andrea Parri <andrea.parri@amarulasolutions.com> Signed-off-by:
-
Chen-Yu Tsai authored
The BCM43430A0 has the default MAC address 43:43:A0:12:1F:AC if none is given. This address was found when enabling Bluetooth on a bunch of boards with the AMPAK AP6210 module, all sharing the same address. It also contains the sequence 4343A0, which is suspicious as that is also the name the chip identifies itself as. Add this to the list of default MAC addresses and leave it to the user to configure a valid one. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Chen-Yu Tsai authored
The BCM4330 chip is a 802.11 a/b/g/n + Bluetooth 4.0 + HS controller. This patch adds a compatible string match to the serdev driver for the Bluetooth part of the chip. Signed-off-by:
-
Maxime Ripard authored
The BCM20702A1 chip is a single-chip Bluetooth 4.0 controller and transceiver. It is found in the AMPAK AP6210 WiFi+BT package. Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Tested-by:
Ondrej Jirman <megous@megous.com> Signed-off-by:
-
Chen-Yu Tsai authored
The datasheets for BCM20702 and BCM43438 both have power up time sequence graphs, however they are slightly different. Both chips also have an internal power-on-reset, which holds the chip in reset for a short time after the regulators are enabled. For the BCM20702, the time period from when the regulators are enabled, until the chip settles and comes out of sleep state, is 6564 ~ 8171 us. For the BCM43438, the graph only shows the time period from when the regulators are enabled until the chip responds by driving the host's CTS line low, assuming the host has already driven its RTS line low. This is shown to be 6.5 sleep cycles, with the sleep clock at 32.768 kHz. This is around 2 ms. Wait a full 10 ms after the regulators are enabled to account for signal rising times. Tested-by:
-
Chen-Yu Tsai authored
The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO. The former provides overall power for the chip, while the latter powers the I/O pins and buffers. Model these two as regulator supplies, and let the driver manage them in the same way as it does the clock supply. Tested-by:
-
Chen-Yu Tsai authored
The Broadcom Bluetooth controllers support a secondary LPO clock at 32.768 kHz. This external clock provides low power timing, and also a way to detect the frequency of the main reference clock. On many designs without NVRAM and a non-default reference clock, this must be used or the controller will not function correctly. Tested-by:
-
Chen-Yu Tsai authored
Originally the device tree binding only specified one clock reference, with the name "extclk". The driver simply retrieves the clock without bothering to specify a name. Since we added a second clock to the binding, we need to fetch the clocks by name now. First we try the new name "txco", then fall back to the old name "extclk", and finally try retrieving a clock without using any name, to cover any instances where a bad device tree or firmware worked by accident. In the last case, we should take care that we don't get the same clock twice when we add support for the "lpo" clock. Tested-by:
-
Chen-Yu Tsai authored
The driver currently checks the clk pointer for an error condition, as returned by clk_get, before every invocation of the clk consumer API. This is redundant if the goal is simply to ignore the errors, thereby making the clk optional. The clk consumer API already checks if the pointer is NULL or not. Simplify the code a bit by assigning NULL to the clk pointer if the error condition is one we want to ignore, which is every error except deferred probing. Tested-by:
-
Chen-Yu Tsai authored
On some systems that actually have the bluetooth controller wired up with an extra clock signal, it's possible the bluetooth controller probes before the clock provider. clk_get would return a defer probe error, which was not handled by this driver. Handle this properly, so that these systems can work reliably. Tested-by:
-
Chen-Yu Tsai authored
The BCM4330 is a 802.11 a/b/g/n WiFi + Bluetooth 4.0 chip from Broadcom. It is found in the Ampak AP6330 WiFi+BT module. The partiular one I have identifies as BCM4330B1 for Bluetooth and BCM4330/4 for WiFi. It is unclear if the AP6330 module uses this revision of the BCM4330, or if there are multiple revisions. The module does not have revision markings. This patch elects to use just BCM4330 for the compatible string. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Chen-Yu Tsai authored
The BCM20702A1 is a Bluetooth 4.0 chip from Broadcom. It is found in the Ampak AP6210 WiFi+BT module, identified from the read verbose config info command response. However the Bluetooth firmware provided by vendors uses the name BCM20710. This patch elects to use the chip ID returned by the chip for the compatible string. Reviewed-by:
-
Chen-Yu Tsai authored
The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO. The former provides overall power for the chip, while the latter powers the I/O pins and buffers. This patch adds properties for the two so we can describe the power supply relationships. Reviewed-by:
-
Chen-Yu Tsai authored
The Broadcom Bluetooth controllers can take up to two external clocks: an external frequency reference, substituting the main crystal, and a LPO clock at 32.768 kHz substituting the internal LPO clock. In particular, the external LPO clock must be used when the controller does not have NVRAM connected, and the main reference frequency is not the default 20 MHz. This is described in detail in the datasheet. The original "extclk" clock name is ambiguous as to which of these it refers to, and some designs might even require both. This patch deprecates the existing name, and adds "txco" and "lpo". Tested-by:
-
Yangtao Li authored
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by:
Yangtao Li <tiny.windzz@gmail.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Yangtao Li authored
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by:
-
John Hurley authored
Previously the identifier used for indirect block callback registry and for block rule cb registry (when done via indirect blocks) was the pointer to the netdev we were interested in receiving updates on. This worked fine if a single app existed that registered one callback per netdev of interest. However, if multiple cards are in place and, in turn, multiple apps, then each app may register the same callback with the same identifier to both the netdev's indirect block cb list and to a block's cb list. This can lead to EEXIST errors and/or incorrect cb deletions. Prevent this conflict by using the app pointer as the identifier for netdev indirect block cb registry, allowing each app to register a unique callback per netdev. For block cb registry, the same app may register multiple cbs to the same block if using TC shared blocks. Instead of the app, use the pointer to the allocated cb_priv data as the identifier here. This means that there can be a unique block callback for each app/netdev combo. Fixes: 3166dd07 ("nfp: flower: offload tunnel decap rules via indirect TC blocks") Reported-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
John Hurley <john.hurley@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shalom Toledo authored
This new firmware contains: * New packet traps for discarded packets * Secure firmware flash bug fix * Fence mechanism bug fix * TCAM RMA bug fix Signed-off-by:
Shalom Toledo <shalomt@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
David Ahern authored
mfc6_cache is not needed by ip6mr_forward2 so drop it from the input argument list. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
David Ahern authored
mfc_cache is not needed by ipmr_queue_xmit so drop it from the input argument list. Signed-off-by:
-
Peter Oskolkov authored
Commit d9fbc7f6 "net: tcp: prefer listeners bound to an address" removes port-only listener lookups. This caused segfaults in DCCP lookups because DCCP did not initialize the (addr,port) hashtable. This patch adds said initialization. The only non-trivial issue here is the size of the new hashtable. It seemed reasonable to make it match the size of the port-only hashtable (= INET_LHTABLE_SIZE) that was used previously. Other parameters to inet_hashinfo2_init() match those used in TCP. V2 changes: marked inet_hashinfo2_init as an exported symbol so that DCCP compiles when configured as a module. Tested: syzcaller issues fixed; the second patch in the patchset tests that DCCP lookups work correctly. Fixes: d9fbc7f6 "net: tcp: prefer listeners bound to an address" Reported-by:
syzcaller <syzkaller@googlegroups.com> Signed-off-by:
Peter Oskolkov <posk@google.com> Signed-off-by:
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Updates for net-next. Two main changes in this seris plus some miscellaneous changes. 1. Improvements and fixes for resource accounting which are required for enabling SR-IOV and RDMA on the new 57500 chips. Only SR-IOV for 57500 chips is enabled in this series. 2. New statistics counters and improvements to keep the basic counters and port counters during IFDOWN. 3. Msic. small changes for ETS, returning proper error codes when flashing NVRAM, and a link speed related fix for ethtool loopback selftest. ==================== Signed-off-by: -
Vasundhara Volam authored
With autoneg enabled, PHY loopback test fails. To disable autoneg, driver needs to send a valid forced speed to FW. FW is not sending async event for invalid speeds. To fix this, query forced speeds and send the correct speed when disabling autoneg mode. Signed-off-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Michael Chan authored
Port statistics which include RDMA counters are useful even when the netdevice is down. Do not free the port statistics DMA buffers when the netdevice is down. This is keep the snapshot of the port statistics and counters will just continue counting when the netdevice goes back up. Split the bnxt_free_stats() function into 2 functions. The port statistics buffers will only be freed when the netdevice is removed. Signed-off-by:
-
Michael Chan authored
With the current driver, the statistics reported by .ndo_get_stats64() are reset when the device goes down. Store a snapshot of the rtnl_link_stats64 before shutdown. This snapshot is added to the current counters in .ndo_get_stats64() so that the counters will not get reset when the device is down. Signed-off-by:
-
Vasundhara Volam authored
Currently firmware specific errors are returned directly in flash_device and reset ethtool hooks. Modify it to return linux standard errors to userspace when flashing operations fail. Signed-off-by:
-
Michael Chan authored
Currently, the code allows ETS bandwidth weight 0 to be set on unused TCs. We should not set any DCB parameters on unused TCs at all. Signed-off-by:
-
Michael Chan authored
Display the CoS counters as additional priority counters by looking up the priority to CoS queue mapping. If the TX extended port statistics block size returned by firmware is big enough to cover the CoS counters, then we will display the new priority counters. We call firmware to get the up-to-date pri2cos mapping to convert the CoS counters to priority counters. Signed-off-by:
-
Michael Chan authored
There are some minor differences when assigning VF resources on the new chips. The MSIX (NQ) resource has to be assigned and ring group is not needed on the new chips. Signed-off-by:
-
Michael Chan authored
When bringing up a device, the code checks to see if the number of MSIX has changed. pci_disable_msix() should be called first before changing the number of reserved NQs/CMPL rings. This ensures that the MSIX vectors associated with the NQs/CMPL rings are still properly mapped when pci_disable_msix() masks the vectors. This patch will prevent errors when RDMA support is added for the new 57500 chips. When the RDMA driver shuts down, the number of NQs is decreased and we must use the new sequence to prevent MSIX errors. Signed-off-by:
-
Vasundhara Volam authored
bnxt_en requires same number of stat_ctxs as CP rings but RDMA requires only 1 stat_ctx. Also add a new parameter resv_stat_ctxs to better keep track of stat_ctxs reserved including resources used by RDMA. Add a stat_ctxs parameter to all the relevant resource reservation functions so we can reserve the correct number of stat_ctxs. Prior to this patch, we were not reserving the extra stat_ctx for RDMA and RDMA would not work on the new 57500 chips. Signed-off-by:
-
Vasundhara Volam authored
Calling bnxt_set_max_func_stat_ctxs() to modify max stat_ctxs requested or freed by the RDMA driver is wrong. After introducing reservation of resources recently, the driver has to keep track of all stat_ctxs including the ones used by the RDMA driver. This will provide a better foundation for accurate accounting of the stat_ctxs. Signed-off-by:
-
