- 18 May, 2018 19 commits
-
-
Loic Poulain authored
This function allows to send a HCI command without expecting any controller event/response in return. This is allowed for vendor- specific commands only. Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Fabio Estevam authored
When both CONFIG_BT_HCIUART_INTEL and CONFIG_BT_HCIUART_BCM are not selected, sparse complains like this: drivers/bluetooth/hci_ldisc.c:437:9: warning: switch with no cases Fix the sparse warning by proving a default switch case. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
Vic Wei authored
Contains a QCA6174A chipset, with USB BT. Let's support loading firmware on it. From usb-devices: T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=301a 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 I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
Vic Wei <vwei@codeaurora.org> Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
-
John Keeping authored
I've seen timeout errors from HCI commands where it looks like schedule_timeout() has returned immediately; additional logging for the error case gives: req_status=1 req_result=0 remaining=10000 jiffies so the device is still in state HCI_REQ_PEND and the value returned by schedule_timeout() is the same as the original timeout (HCI_INIT_TIMEOUT on a system with HZ=1000). Use wait_event_interruptible_timeout() instead of open-coding similar behaviour which is subject to the spurious failure described above. Signed-off-by:
John Keeping <john@metanate.com> Signed-off-by:
-
Chriz Chow authored
There are some controllers sending out advertising data with illegal length value which is longer than HCI_MAX_AD_LENGTH, causing the buffer last_adv_data overflows. To avoid these controllers from overflowing the buffer, we do not process the advertisement data if its length is incorrect. Signed-off-by:
Chriz Chow <chriz.chow@aminocom.com> Signed-off-by:
-
Hans de Goede authored
Initialize hw_name to "BCM", this avoids the need for a number of NULL checks on hw_name later. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
btbcm_setup_patchram() starts with initializing the controller (and getting the firmware filename) and then after loading the firmware, does a re-init. This almost entirely duplicates the code in btbcm_initialize(), use that function instead. Signed-off-by:
-
Hans de Goede authored
btbcm_finalize() does a re-init of the controller, which is almost the same as the initial init. Modify btbcm_initialize() so that it can be used for this re-init and modify btbcm_finalize() to use it. As an added bonus this also makes the dev_info from btbcm_finalize() use the proper hw_name instead of always printing "BCM". Signed-off-by:
-
Hans de Goede authored
Make btbcm_initialize() also work for USB connected device, btbcm_initialize() and btbcm_setup_patchram() are quite similar, this is a preparation patch for making btbcm_setup_patchram() use btbcm_initialize() to remove the code duplication. Signed-off-by:
-
Hans de Goede authored
We are using the same loop in both the UART and USB bus cases, refactor things a bit to share the loop. This is mostly meant to improve readability. Signed-off-by:
-
Hans de Goede authored
btbcm_setup_patchram() was using the upper nibble of the revision code to determine if we are dealing with an uart or USB connected bcm-bt device, but just as btbcm_initialize() has started accepting 1 and 2 as uart connected devices, I've now encountered an USB connected device (0a5c:216c) which has 0 in the upper nibble. So it seems that the upper nibble is not really a reliable indicator of the bus type. Instead check hdev->bus which does give us a reliable indication. This fixes the patchram code trying to load the patchram by the fallback BCM.hcd filename, now it correctly requests BCM43142A0-0a5c-216c.hcd. Signed-off-by:
-
Thierry Escande authored
Add support for Qualcomm serial slave devices. Probe the serial device, retrieve its maximum speed and register a new hci uart device. Signed-off-by:
Thierry Escande <thierry.escande@linaro.org> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Thierry Escande authored
Add binding document for serial bluetooth chips using Qualcomm protocol. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Thierry Escande authored
Add a new serial node for the Qualcomm BT controller QCA6174. This allows automatic probing and hci registration through the serdev framework instead of relying on the userspace helpers. Signed-off-by:
-
Srinivas Kandagatla authored
This patch enables regulators and gpios for the Qualcomm QCA6174 BT/WLAN combo controller. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Amit Pundir authored
AOSP use userspace firmware loader to load firmwares, which will return -EAGAIN in case qca/rampatch_00440302.bin is not found. Since there is no rampatch for dragonboard820c QCA controller revision, just make it work as is. CC: Loic Poulain <loic.poulain@linaro.org> CC: Nicolas Dechesne <nicolas.dechesne@linaro.org> CC: Marcel Holtmann <marcel@holtmann.org> CC: Johan Hedberg <johan.hedberg@gmail.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
Loic Poulain authored
HCI RX/TX byte counters were only incremented when sending ACL packets. To reflect the real HCI traffic, we need to increment these counters on HCI events and HCI commands as well. Increment error counter on rpmsg errors. Signed-off-by:
-
Hans de Goede authored
Interrupts specified through an "Interrupt" ACPI resource (versus through a "GpioInt" resource) are now always assumed to be active low. When this change was originally made the Thinkpad 8 quirk was kept around because it was uncertain if the Thinkpad 8 uses an "Interrupt" or a "GpioInt" resource. Bug https://bugzilla.kernel.org/show_bug.cgi?id=196701 has a DSDT for the Thinkpad 8 attached and it uses an "Interrupt" resource, so the quirk is not necessary and the quirk, as well as the irq-active-low quirk handling code can be removed. Signed-off-by:
-
Hans de Goede authored
The Meegopad T08 hdmi-stick (think Intel computestick) has a brcm43430 wifi/bt combo chip. The BCM2E90 ACPI device describing the BT part does contain a valid ActiveLow GpioInt entry, but the GPIO it points to never goes low, so either the IRQ pin is not connected, or the ACPI resource- table points to the wrong GPIO. Eitherway things will not work if we try to use the specified IRQ, this commits adds a DMI based broken-irq blacklist and disables use of the IRQ and thus also runtime-pm for devices on this list. This blacklist starts with the the Meegopad T08, fixing bluetooth not working on this hdmi-stick. Since this is not a battery powered device the loss of runtime-pm is not really an issue. Signed-off-by:
-
- 17 May, 2018 21 commits
-
-
David S. Miller authored
Florian Fainelli says: ==================== net: Allow more drivers with COMPILE_TEST This patch series includes more drivers to be build tested with COMPILE_TEST enabled. This helps cover some of the issues I just ran into with missing a driver *sigh*. Chanves in v3: - drop the TI Keystone NETCP driver from the COMPILE_TEST additions Changes in v2: - allow FEC to build outside of CONFIG_ARM/ARM64 by defining a layout of registers, this is not meant to run, so this is not a real issue if we are not matching the correct register layout ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Those drivers build just fine with COMPILE_TEST, so make that possible. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
The Freescale FEC driver builds fine with COMPILE_TEST, so make that possible. Signed-off-by:
-
Florian Fainelli authored
Most of the TI drivers build just fine with COMPILE_TEST, cpmac (AR7) is the exception because it uses a header file from arch/mips/include/asm/mach-ar7/ar7.h and keystone netcp which requires help from drivers/soc/ti/ for queue management helpers. Signed-off-by:
-
David Ahern authored
Add informative messages for error paths related to adding a VLAN to a device. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Manish Chopra authored
This patch makes use of build_skb() throughout in driver's receieve data path [HW gro flow and non HW gro flow]. With this, driver can build skb directly from the page segments which are already mapped to the hardware instead of allocating new SKB via netdev_alloc_skb() and memcpy the data which is quite costly. This really improves performance (keeping same or slight gain in rx throughput) in terms of CPU utilization which is significantly reduced [almost half] in non HW gro flow where for every incoming MTU sized packet driver had to allocate skb, memcpy headers etc. Additionally in that flow, it also gets rid of bunch of additional overheads [eth_get_headlen() etc.] to split headers and data in the skb. Tested with: system: 2 sockets, 4 cores per socket, hyperthreading, 2x4x2=16 cores iperf [server]: iperf -s iperf [client]: iperf -c <server_ip> -t 500 -i 10 -P 32 HW GRO off – w/o build_skb(), throughput: 36.8 Gbits/sec Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle Average: all 0.59 0.00 32.93 0.00 0.00 43.07 0.00 0.00 23.42 HW GRO off - with build_skb(), throughput: 36.9 Gbits/sec Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle Average: all 0.70 0.00 31.70 0.00 0.00 25.68 0.00 0.00 41.92 HW GRO on - w/o build_skb(), throughput: 36.9 Gbits/sec Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle Average: all 0.86 0.00 24.14 0.00 0.00 6.59 0.00 0.00 68.41 HW GRO on - with build_skb(), throughput: 37.5 Gbits/sec Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle Average: all 0.87 0.00 23.75 0.00 0.00 6.19 0.00 0.00 69.19 Signed-off-by:
Ariel Elior <ariel.elior@cavium.com> Signed-off-by:
Manish Chopra <manish.chopra@cavium.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 10GbE Intel Wired LAN Driver Updates 2018-05-17 This series contains updates to ixgbe, ixgbevf and ice drivers. Cathy Zhou resolves sparse warnings by using the force attribute. Mauro S M Rodrigues fixes a bug where IRQs were not freed if a PCI error recovery system opts to remove the device which causes ixgbe_io_error_detected() to return PCI_ERS_RESULT_DISCONNECT before calling ixgbe_close_suspend() which results in IRQs not freed and crashing when the remove handler calls pci_disable_device(). Resolved this by calling ixgbe_close_suspend() before evaluating the PCI channel state. Pavel Tatashin releases the rtnl_lock during the call to ixgbe_close_suspend() to allow scaling if device_shutdown() is multi-threaded. Emil modifies ixgbe to not validate the MAC address during a reset, unless the MAC was set on the host so that the VF will get a new MAC address every time it reloads. Also updates ixgbevf to set hw->mac.perm_addr in order to retain the custom MAC on a reset. Anirudh updates the ice NVM read/erase/update AQ commands to align with the latest specification. ==================== Signed-off-by: -
Roman Mashak authored
Reported-by:
Vlad Buslov <vladbu@mellanox.com> Reported-by:
Davide Caratti <dcaratti@redhat.com> Signed-off-by:
Roman Mashak <mrv@mojatatu.com> Signed-off-by:
-
Dan Carpenter authored
We recently refactored this code and introduced a static checker warning. Smatch complains that if cmd->index is zero then we would underflow the arrays. That's obviously true. The question is whether we prevent cmd->index from being zero at a different level. I've looked at the code and I don't immediately see a check for that. Fixes: 062b3e1b ("net/ncsi: Refactor MAC, VLAN filters") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Eric Dumazet authored
syzkaller found that following program crashes the host : { int fd = socket(AF_SMC, SOCK_STREAM, 0); int val = 1; listen(fd, 0); shutdown(fd, SHUT_RDWR); setsockopt(fd, 6, TCP_NODELAY, &val, 4); } Simply initialize conn.tx_work & conn.send_lock at socket creation, rather than deeper in the stack. ODEBUG: assert_init not available (active state 0) object type: timer_list hint: (null) WARNING: CPU: 1 PID: 13988 at lib/debugobjects.c:329 debug_print_object+0x16a/0x210 lib/debugobjects.c:326 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 13988 Comm: syz-executor0 Not tainted 4.17.0-rc4+ #46 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 panic+0x22f/0x4de kernel/panic.c:184 __warn.cold.8+0x163/0x1b3 kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992 RIP: 0010:debug_print_object+0x16a/0x210 lib/debugobjects.c:326 RSP: 0018:ffff880197a37880 EFLAGS: 00010086 RAX: 0000000000000061 RBX: 0000000000000005 RCX: ffffc90001ed0000 RDX: 0000000000004aaf RSI: ffffffff8160f6f1 RDI: 0000000000000001 RBP: ffff880197a378c0 R08: ffff8801aa7a0080 R09: ffffed003b5e3eb2 R10: ffffed003b5e3eb2 R11: ffff8801daf1f597 R12: 0000000000000001 R13: ffffffff88d96980 R14: ffffffff87fa19a0 R15: ffffffff81666ec0 debug_object_assert_init+0x309/0x500 lib/debugobjects.c:692 debug_timer_assert_init kernel/time/timer.c:724 [inline] debug_assert_init kernel/time/timer.c:776 [inline] del_timer+0x74/0x140 kernel/time/timer.c:1198 try_to_grab_pending+0x439/0x9a0 kernel/workqueue.c:1223 mod_delayed_work_on+0x91/0x250 kernel/workqueue.c:1592 mod_delayed_work include/linux/workqueue.h:541 [inline] smc_setsockopt+0x387/0x6d0 net/smc/af_smc.c:1367 __sys_setsockopt+0x1bd/0x390 net/socket.c:1903 __do_sys_setsockopt net/socket.c:1914 [inline] __se_sys_setsockopt net/socket.c:1911 [inline] __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 01d2f7e2 ("net/smc: sockopts TCP_NODELAY and TCP_CORK") Signed-off-by:Eric Dumazet <edumazet@google.com> Cc: Ursula Braun <ubraun@linux.ibm.com> Cc: linux-s390@vger.kernel.org Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
Jiri Pirko authored
Don't store repr pointer to reprs array until the representor is successfully created. This avoids message about "representor destruction" even when it was never created. Also it cleans-up the flow. Also, check return value after port alloc. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
David S. Miller authored
Antoine Tenart says: ==================== net: mvpp2: small improvements Those 3 patches are small improvements to the Marvell PPv2 driver. The series does not conflict with the one sent about phylink and 1000/2500baseX support, so the two series can live in parallel. ==================== Signed-off-by: -
Yan Markman authored
Prevent flood of RX error prints during heavy traffic with weak signal in link by checking net_ratelimit() before using netdev_err(). Signed-off-by:
Yan Markman <ymarkman@marvell.com> [Antoine: small rework, commit message] Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
Yan Markman authored
Remove special stop/start handling from the set_mac_address callback. All this special care is not needed, and can be removed. It also simplifies the up/down status in the driver and helps avoiding possible link status mismatch issues. Signed-off-by:
-
Yan Markman authored
Avoid repeating the check for free aggregated descriptors when it already failed at the beginning of the function. Signed-off-by:
-
David S. Miller authored
Antoine Tenart says: ==================== net: mvpp2: phylink conversion This series convert the Marvell PPv2 driver to phylink (models the MAC to PHY link). One important point is the PPv2 driver supports two probe modes: device tree and ACPI. This series only brings phylink support for the device tree mode, as the ACPI one will need further work. Still, the driver should be working as before when using ACPI. This split should be temporary, and was discussed with Marcin (in Cc.) who added ACPI support to the driver. Also as the SFP cages on both DB boards can be considered as non-wired. We thus chose not to describe those SFP cages and we use fixed-link. The rest of the series uses phylink to add support for 1000BaseX and 2500BaseX modes in the PPv2 driver. To do this, two patches are needed in the common PHY framework (patches 3 and 4). The last 4 patches modify the device tree to use the new PPv2 functionalities. The series has been tested for the device tree mode on the 7040-db, 8040-db and 8040-mcbin boards, to ensure all the interface where working as expected. @Dave: patches 7 to 10 should go through the mvebu tree (Gregory in Cc.) to avoid any conflict with the other mvebu dt patches taken during this cycle. The series is based on today's net-next. Since v2: - Removed the SFP description from the DB boards, as their SFP cages are wired properly. We now use fixed-link. - Because of this rework, split the series in two, so that the SFP part is reviewed separately. - Small fixes in the phylink patch. - Rebased on the latest net-next branch. Since v1: - Chose a different approach to the SFP changes, as the previous ones weren't valid and reworked both BD boards device trees. - Misc fixes. - Added Kishon's acked-by on one patch. - Rebaed on latest net-next branch. ==================== Signed-off-by: -
Antoine Tenart authored
This patch adds the 2500Base-X PHY mode support in the Marvell PPv2 driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses nearly the same code path. Signed-off-by:
-
Antoine Tenart authored
This patch adds the 1000Base-X PHY mode support in the Marvell PPv2 driver. 1000Base-X is quite close the SGMII and uses nearly the same code path. Signed-off-by:
-
Antoine Tenart authored
This patch allow the CP110 comphy to configure some lanes in the 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the same code path. Signed-off-by:
-
Antoine Tenart authored
This patch adds one more generic PHY mode to the phy_mode enum, to allow configuring generic PHYs to the 2.5G SGMII mode by using the set_mode callback. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Antoine Tenart authored
Convert the PPv2 driver to implement phylink helpers, and use phylink in DT mode. The other mode supported is ACPI, which will need further work in order to be entirely compatible with phylink. The MAC and GoP configuration functions were completely moved to fit into the phylink helpers. When a PHY is always present between the MAC and the physical port, phylink only is used, but when this is not the case (the MAC directly is connected to the physical port) the link IRQ is used to detect changes in the link state and call phylink_mac_change. The ACPI mode do not uses phylink as of now, and the changes shouldn't impact its use. Signed-off-by:
-
