- 19 Dec, 2018 14 commits
-
-
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2018-12-19 Here's the main bluetooth-next pull request for 4.21: - Multiple fixes & improvements for Broadcom-based controllers - New USB ID for an Intel controller - Support for new Broadcom controller variants - Use DEFINE_SHOW_ATTRIBUTE to simplify debugfs code - Eliminate confusing "last event is not cmd complete" warning message - Added vendor suspend/resume support for H:5 (3-Wire UART) controllers - Various other smaller improvements & fixes Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2018-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== This time we have too many changes to list, highlights: * virt_wifi - wireless control simulation on top of another network interface * hwsim configurability to test capabilities similar to real hardware * various mesh improvements * various radiotap vendor data fixes in mac80211 * finally the nl_set_extack_cookie_u64() we talked about previously, used for * peer measurement APIs, right now only with FTM (flight time measurement) for location * made nl80211 radio/interface announcements more complete * various new HE (802.11ax) things: updates, TWT support, ... ==================== Signed-off-by:
-
Johan Hedberg authored
In case a command which completes in Command Status was sent using the hci_cmd_send-family of APIs there would be a misleading error in the hci_get_cmd_complete function, since the code would be trying to fetch the Command Complete parameters when there are none. Avoid the misleading error and silently bail out from the function in case the received event is a command status. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Acked-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
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:
-
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: -
Ilan Peer authored
The radiotap vendor data might be placed after some other radiotap elements, and thus when accessing it, need to access the correct offset in the skb data. Fix the code accordingly. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Fix two bugs in ieee80211_get_vht_max_nss(): * the spec says we should round down (reported by Nissim) * there's a double condition, the first one is wrong, supp_width == 0 / ext_nss_bw == 2 is valid in 80+80 (found by smatch) Fixes: b0aa75f0 ("ieee80211: add new VHT capability fields/parsing") Reported-by:
Nissim Bendanan <nissimx.bendanan@intel.com> Signed-off-by:
-
Johannes Berg authored
Due to the alignment handling, it actually matters where in the code we add the 4 bytes for the presence bitmap to the length; the first field is the timestamp with 8 byte alignment so we need to add the space for the extra vendor namespace presence bitmap *before* we do any alignment for the fields. Move the presence bitmap length accounting to the right place to fix the alignment for the data properly. 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:
-
Heiner Kallweit authored
After phy_start() phylib takes care of all needed actions, including aneg settings and checking link state. There's no need to set state PHY_CHANGELINK in drivers. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Alexandre Belloni authored
Microsemi has been bought by Microchip and Microchip is supporting those switches. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by:
Woojung Huh <Woojung.Huh@microchip.com> Signed-off-by:
-
Zhenbo Gao authored
NAME_DISTRIBUTOR messages are transmitted through unicast link on TIPC 2.0, by contrast, the messages are delivered through broadcast link on TIPC 1.7. But at present, NAME_DISTRIBUTOR messages received by broadcast link cannot be handled in tipc_rcv() until an unicast message arrives, which may lead to a significant delay to update name table. To avoid this delay, we will also deal with broadcast NAME_DISTRIBUTOR message on broadcast receive path. Signed-off-by:
Zhenbo Gao <zhenbo.gao@windriver.com> Reviewed-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
Heiner Kallweit authored
3c1bcc86 ("net: ethernet: Convert phydev advertize and supported from u32 to link mode") left some unused code in phy_probe(), remove it. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed: ==================== mlx5-uplink-rep-2018-12-15 Or Gerlitz says: This series is essentially a cleanup to align with the rest of the NIC switchdev drivers and make us more robust and clear/n: currently the PF netdev serves as the mlx5 e-switch uplink netdev representor when going into switchdev mode and back as plain NIC netdev when going out. This causes some irregularities and misc troubles. Move to use dedicated uplink rep, as we have for the VF vports. The uplink rep netdev does has sysfs link and supports the sriov vf mac ndo, these two are in use by libvirt and other orchestrators, It also has richer ethtool support to allow controlling the port link & mtu along with supporting dcb and plugging into the mlx5 lag logic. ==================== Signed-off-by:
-
- 18 Dec, 2018 26 commits
-
-
YueHaibing authored
function br_multicast_toggle now always return 0, so the variable 'err' is unneeded. Also cleanup dead branch in br_changelink. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1070:5: warning: variable 'op' set but not used [-Wunused-but-set-variable] drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1342:5: warning: variable 'cmd_op' set but not used [-Wunused-but-set-variable] 'op' never used since introduction in commit 7cb03b23 ("qlcnic: Support VF-PF communication channel commands.") 'cmd_op' not used since commit 6226204b ("qlcnic: Fix operation type and command type.") Signed-off-by:
-
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:
-
Arnd Bergmann authored
This is one of only two files that initialize a semaphore to a negative value. We don't really need the two semaphores here at all, but can do the same thing in more conventional and more effient way, by using a single waitqueue and an atomic thread counter. This gets us a little bit closer to eliminating classic semaphores from the kernel. It also fixes a corner case where we fail to continue after one of the threads fails to start up. An alternative would be to use a split kthread_create()+wake_up_process() and completely eliminate the separate synchronization. Acked-by:
Phil Sutter <phil@nwl.cc> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Heiner Kallweit authored
So far phy_error() silently stops the PHY state machine. If the network driver doesn't inform about a MDIO error then the user may wonder why his network is down. Let's print the stack trace to facilitate search for the root cause of the error. Signed-off-by:
-
Heiner Kallweit authored
Add helpers phy_is_started() and __phy_is_started() to avoid open-coded checks whether PHY has been started. To make the check easier move PHY_HALTED before PHY_UP in enum phy_state. Further improvements: phy_start_aneg(): Return -EBUSY and print warning if function is called from a non-started state (DOWN, READY, HALTED). Better check because function is exported and drivers may use it incorrectly. phy_interrupt(): Return IRQ_NONE also if state is DOWN or READY. We should never receive an interrupt in one of these states, but better play safe. phy_stop(): Just return and print a warning if PHY is in a non-started state. This warning should help to identify drivers with unbalanced calls to phy_start() / phy_stop(). phy_state_machine(): Schedule state machine run only if PHY is in a started state. E.g. if state is READY we don't need the state machine, it will be started by phy_start(). v2: - don't use __func__ within phy_warn_state v3: - use WARN() instead of printing error message to facilitate debugging Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
