- 23 Apr, 2019 40 commits
-
-
Stephan Gerhold authored
Add the device ID for the BT/FM/GPS combo chip BCM2076 (rev B1) used in the AMPAK AP6476 WiFi/BT/FM/GPS module. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Dan Carpenter authored
NEXTHDR_MAX is 255. What happens here is that we take a u8 value "hdr->nexthdr" from the network and then look it up in lowpan_nexthdr_nhcs[]. The problem is that if hdr->nexthdr is 0xff then we read one element beyond the end of the array so the array needs to be one element larger. Fixes: 92aa7c65 ("6lowpan: add generic nhc layer interface") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Jukka Rissanen <jukka.rissanen@linux.intel.com> Acked-by:
Alexander Aring <aring@mojatatu.com> Signed-off-by:
-
Ferry Toth authored
The BCM43341B has the default MAC address 43:34:1B:00:1F:AC if none is given. This address was found when enabling Bluetooth on multiple Intel Edison modules. It also contains the sequence 43341B, the name the chip identifies itself as. Using the same BD_ADDR is problematic when having multiple Intel Edison modules in each others range. The default address also has the LAA (locally administered address) bit set which prevents a BNEP device from being created, needed for BT tethering. Add this to the list of black listed default MAC addresses and let the user configure a valid one using f.i. `btmgmt -i hci0 public-addr xx:xx:xx:xx:xx:xx` Suggested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Ferry Toth <ftoth@exalondelft.nl> Reviewed-by:
-
Young Xiao authored
Struct ca is copied from userspace. It is not checked whether the "name" field is NULL terminated, which allows local users to obtain potentially sensitive information from kernel stack memory, via a HIDPCONNADD command. This vulnerability is similar to CVE-2011-1079. Signed-off-by:
Young Xiao <YangX92@hotmail.com> Signed-off-by:
-
Tamás Szűcs authored
This patch adds support for Marvell 88W8987 chipset with SDIO interface. Register offsets and supported feature flags are updated. The corresponding firmware image file shall be "mrvl/sd8987_uapsta.bin". Signed-off-by:
Tamás Szűcs <tszucs@protonmail.ch> Signed-off-by:
-
Sean Wang authored
Add runtime PM support to btmtksdio. With this way, there will be the benefit of the device entering the more power saving state once it is been a while data traffic is idle. Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Sean Wang authored
Accumulate hdev->stat.byte_rx only for valid packets as btmtkuart doing. Signed-off-by:
-
Sean Wang authored
Add a register bit definition about CHLPCR bit 8 because the bit is quite different in the meaning between reading and writing that bit. The patch adds a definition particularly for the bit read to avoid the confusion about using write definition to read the bit. Signed-off-by:
-
Sean Wang authored
bt_dev logging macros already include a newline at each output so drop these unnecessary additional newlines in the driver. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a BT_DBG debug message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Sean Wang authored
Fixed warning: incorrect type in assignment reported by kbuild test robot. The detailed warning is shown as below. make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' All warnings (new ones prefixed by >>): btmtkuart.c:671:18: sparse: warning: incorrect type in assignment (different base types) btmtkuart.c:671:18: sparse: expected unsigned int [usertype] baudrate btmtkuart.c:671:18: sparse: got restricted __le32 [usertype] sparse warnings: (new ones prefixed by >>) btmtkuart.c:671:18: sparse: warning: incorrect type in assignment (different base types) btmtkuart.c:671:18: sparse: expected unsigned int [usertype] baudrate btmtkuart.c:671:18: sparse: got restricted __le32 [usertype] vim +671 drivers/bluetooth/btmtkuart.c 659 660 static int btmtkuart_change_baudrate(struct hci_dev *hdev) 661 { 662 struct btmtkuart_dev *bdev = hci_get_drvdata(hdev); 663 struct btmtk_hci_wmt_params wmt_params; 664 u32 baudrate; 665 u8 param; 666 int err; 667 668 /* Indicate the device to enter the probe state the host is 669 * ready to change a new baudrate. 670 */ > 671 baudrate = cpu_to_le32(bdev->desired_speed); 672 wmt_params.op = MTK_WMT_HIF; Fixes: 22eaf6c9 ("Bluetooth: mediatek: add support for MediaTek MT7663U and MT7668U UART devices") Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
-
Sean Wang authored
Fixed all the below warnings. They would probably cause the following error handling path would use the uninitialized value and then produce unexpected behavior. drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_len’ may be used uninitialized in this function [-Wmaybe-uninitialized] print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ old_data, old_len, true); ~~~~~~~~~~~~~~~~~~~~~~~~ drivers/bluetooth/btmtksdio.c:376:15: note: ‘old_len’ was declared here unsigned int old_len; ^~~~~~~ drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_data’ may be used uninitialized in this function [-Wmaybe-uninitialized] print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ old_data, old_len, true); ~~~~~~~~~~~~~~~~~~~~~~~~ drivers/bluetooth/btmtksdio.c:375:17: note: ‘old_data’ was declared here unsigned char *old_data; ^~~~~~~~ v2: Remove old_len and old_data because the error path for sdio_readsb also seems wrong. And change the prefix from "mediatek" to "btmtksdio". Fixes: d74eef2834b5 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Reported-by: -
Sean Wang authored
Macro module_sdio_driver is used for drivers whose init and exit paths only register and unregister to SDIO API. So remove boilerplate code to make code simpler by using module_sdio_driver. Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Sean Wang authored
Macro module_sdio_driver is used for drivers whose init and exit paths only register and unregister to SDIO API. So remove boilerplate code to make code simpler by using module_sdio_driver. Suggested-by:
-
Sean Wang authored
This patch introduces the module_sdio_driver macro which is a convenience macro for SDIO driver modules similar to module_usb_driver. It is intended to be used by drivers which init/exit section does nothing but register/ unregister the SDIO driver. By using this macro it is possible to eliminate a few lines of boilerplate code per SDIO driver. Suggested-by:
-
Fugang Duan authored
Add return check for security level set for socket interface since stack will check the return value. Signed-off-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
l2cap_le_flowctl_init was reseting the tx_credits which works only for outgoing connection since that set the tx_credits on the response, for incoming connections that was not the case which leaves the channel without any credits causing it to be suspended. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
Matthias Kaehlcke authored
Rename the misspelled struct 'qca_bardrate' to 'qca_baudrate' Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
-
Matthias Kaehlcke authored
Many functions obtain a 'struct qca_serdev' only to read the btsoc_type field. Add a helper function that encapsulates this. This also fixes crashes observed on platforms with ROME controllers that are instantiated through ldisc and not as serdev clients. The crashes are caused by NULL pointer dereferentiations, which stem from the driver's assumption that a QCA HCI device is always associated with a serdev device. Fixes: fa9ad876 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Reported-by:
Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by:
-
Sean Wang authored
This adds the support of enabling MT7663S and MT7668S SDIO-based Bluetooth function. There are quite many differences between MT766[3,8]S and standard Bluetooth SDIO devices such as Type-A and Type-B devices. For example, MT766[3,8]S have its own SDIO registers layout, definition, SDIO packet format, and the specific flow should be programmed on them to complete the device initialization and low power control and so on. Currently, there are many independent programming sequences from the transport which are exactly the same as the ones in btusb.c about MediaTek support [1] and btmtkuart.c. We can try to split the transport independent Bluetooth setups on the advance, place them into the common files and allow varous transport drivers to reuse them in the future. [1] http://lists.infradead.org/pipermail/linux-mediatek/2019-January/017074.htmlSigned-off-by:
-
Sean Wang authored
The SDIO identifier for MediaTek Bluetooth devices were defined in the MediaTek Bluetooth driver. Moving the definitions in MMC header file seems common sense. Signed-off-by:
-
Florian Fainelli authored
All we do is write the length/status and address bits to a DMA descriptor only to write its contents into on-chip registers right after, eliminate this unnecessary step. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
When a bridge port is being deleted, do not dereference it later in br_vlan_port_event() as it can result in a use-after-free [1] if the RCU callback was executed before invoking the function. [1] [ 129.638551] ================================================================== [ 129.646904] BUG: KASAN: use-after-free in br_vlan_port_event+0x53c/0x5fd [ 129.654406] Read of size 8 at addr ffff8881e4aa1ae8 by task ip/483 [ 129.663008] CPU: 0 PID: 483 Comm: ip Not tainted 5.1.0-rc5-custom-02265-ga946bd73daac #1383 [ 129.672359] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016 [ 129.682484] Call Trace: [ 129.685242] dump_stack+0xa9/0x10e [ 129.689068] print_address_description.cold.2+0x9/0x25e [ 129.694930] kasan_report.cold.3+0x78/0x9d [ 129.704420] br_vlan_port_event+0x53c/0x5fd [ 129.728300] br_device_event+0x2c7/0x7a0 [ 129.741505] notifier_call_chain+0xb5/0x1c0 [ 129.746202] rollback_registered_many+0x895/0xe90 [ 129.793119] unregister_netdevice_many+0x48/0x210 [ 129.803384] rtnl_delete_link+0xe1/0x140 [ 129.815906] rtnl_dellink+0x2a3/0x820 [ 129.844166] rtnetlink_rcv_msg+0x397/0x910 [ 129.868517] netlink_rcv_skb+0x137/0x3a0 [ 129.882013] netlink_unicast+0x49b/0x660 [ 129.900019] netlink_sendmsg+0x755/0xc90 [ 129.915758] ___sys_sendmsg+0x761/0x8e0 [ 129.966315] __sys_sendmsg+0xf0/0x1c0 [ 129.988918] do_syscall_64+0xa4/0x470 [ 129.993032] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 129.998696] RIP: 0033:0x7ff578104b58 ... [ 130.073811] Allocated by task 479: [ 130.077633] __kasan_kmalloc.constprop.5+0xc1/0xd0 [ 130.083008] kmem_cache_alloc_trace+0x152/0x320 [ 130.088090] br_add_if+0x39c/0x1580 [ 130.092005] do_set_master+0x1aa/0x210 [ 130.096211] do_setlink+0x985/0x3100 [ 130.100224] __rtnl_newlink+0xc52/0x1380 [ 130.104625] rtnl_newlink+0x6b/0xa0 [ 130.108541] rtnetlink_rcv_msg+0x397/0x910 [ 130.113136] netlink_rcv_skb+0x137/0x3a0 [ 130.117538] netlink_unicast+0x49b/0x660 [ 130.121939] netlink_sendmsg+0x755/0xc90 [ 130.126340] ___sys_sendmsg+0x761/0x8e0 [ 130.130645] __sys_sendmsg+0xf0/0x1c0 [ 130.134753] do_syscall_64+0xa4/0x470 [ 130.138864] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 130.146195] Freed by task 0: [ 130.149421] __kasan_slab_free+0x125/0x170 [ 130.154016] kfree+0xf3/0x310 [ 130.157349] kobject_put+0x1a8/0x4c0 [ 130.161363] rcu_core+0x859/0x19b0 [ 130.165175] __do_softirq+0x250/0xa26 [ 130.170956] The buggy address belongs to the object at ffff8881e4aa1ae8 which belongs to the cache kmalloc-1k of size 1024 [ 130.184972] The buggy address is located 0 bytes inside of 1024-byte region [ffff8881e4aa1ae8, ffff8881e4aa1ee8) Fixes: 9c0ec2e7 ("bridge: support binding vlan dev link state to vlan member bridge ports") Signed-off-by:Ido Schimmel <idosch@mellanox.com> Cc: Mike Manning <mmanning@vyatta.att-mail.com> Acked-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by:
Mike Manning <mmanning@vyatta.att-mail.com> Signed-off-by:
-
Crag.Wang authored
Without this patch the socket address family sporadically gets wrong value ends up the dev_set_mac_address() fails to set the desired MAC address. Fixes: 25766271 ("r8152: Refresh MAC address during USBDEVFS_RESET") Signed-off-by:
Crag.Wang <crag.wang@dell.com> Reviewed-by:
Mario Limonciello <mario.limonciello@dell.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Shared buffer improvements This patchset includes two improvements with regards to shared buffer configuration in mlxsw. The first part of this patchset forbids the user from performing illegal shared buffer configuration that can result in unnecessary packet loss. In order to better communicate these configuration failures to the user, extack is propagated from devlink towards drivers. This is done in patches #1-#8. The second part of the patchset deals with the shared buffer configuration of the CPU port. When a packet is trapped by the device, it is sent across the PCI bus to the attached host CPU. From the device's perspective, it is as if the packet is transmitted through the CPU port. While testing traffic directed at the CPU it became apparent that for certain packet sizes and certain burst sizes, the current shared buffer configuration of the CPU port is inadequate and results in packet drops. The configuration is adjusted by patches #9-#14 that create two new pools - ingress & egress - which are dedicated for CPU traffic. ==================== Acked-by:
-
Ido Schimmel authored
Switch the CPU port to use the new dedicated egress pool instead the previously used egress pool which was shared with normal front panel ports. Add per-port quotas for the amount of traffic that can be buffered for the CPU port and also adjust the per-{port, TC} quotas. Signed-off-by:Jiri Pirko <jiri@mellanox.com> Reviewed-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
The CPU port is used to transmit traffic that is trapped to the host CPU. It is therefore irrelevant to define ingress quota for it. Add a 'skip_ingress' argument to the function tasked with configuring per-port quotas, so that ingress quotas could be skipped in case the passed local port is the CPU port. Signed-off-by:
-
Ido Schimmel authored
The function is used to set the per-port shared buffer quotas. Currently, these quotas are only set for front panel ports, but a subsequent patch will configure these quotas for the CPU port as well. The configuration required for the CPU port is a bit different than that of the front panel ports, so split the business logic into a separate function which will be called with different parameters for the CPU port. No functional changes intended. Signed-off-by:
-
Ido Schimmel authored
Use the new ingress pool that was added in the previous patch for control packets (e.g., STP, LACP) that are trapped to the CPU. The previous management pool is no longer necessary and therefore its size is set to 0. The maximum quota for traffic towards the CPU is increased to 50% of the free space in the new ingress pool and therefore the reserved space is reduced by half, to 10KB - in both the shared and headroom buffer. This allows for more efficient utilization of the shared buffer as reserved space cannot be used for other purposes. Signed-off-by:
-
Ido Schimmel authored
Packets that are trapped to the CPU are transmitted through the CPU port to the attached host. The CPU port is therefore like any other port and needs to have shared buffer configuration. The maximum quotas configured for the CPU are provided using dynamic threshold and cannot be changed by the user. In order to make sure that these thresholds are always valid, the configuration of the threshold type of these pools is forbidden. Signed-off-by:
-
Ido Schimmel authored
The code currently assumes that ingress pools have lower indices than egress pools. This makes it impossible to add more ingress pools without breaking user configuration that relies on a certain pool index to correspond to an egress pool. Remove such assumptions from the code, so that more ingress pools could be added by subsequent patches. Signed-off-by:
-
Ido Schimmel authored
Commit e83c045e ("mlxsw: spectrum_buffers: Configure MC pool") configured the threshold of the multicast TCs as infinite so that the admission of multicast packets is only depended on per-switch priority threshold. Forbid the user from changing the thresholds of these multicast TCs and their binding to a different pool. Signed-off-by:
-
Ido Schimmel authored
Multicast packets have three egress quotas: * Per egress port * Per egress port and traffic class * Per switch priority The limits on the switch priority are not exposed to the user and specified as dynamic threshold on the first egress pool. Forbid changing the threshold type of the first egress pool so that these limits are always valid. Signed-off-by:
-
Ido Schimmel authored
Commit e83c045e ("mlxsw: spectrum_buffers: Configure MC pool") added a dedicated pool for multicast traffic. The pool is visible to the user so that it would be possible to monitor its occupancy, but its configuration should be forbidden in order to maintain its intended operation. Signed-off-by:
-
Ido Schimmel authored
Subsequent patches are going to need to veto changes in certain TCs' binding and threshold configurations. Add fields to the TC's struct that indicate if the TC can be bound to a different pool and whether its threshold can change and enforce that. Signed-off-by:
-
Ido Schimmel authored
Subsequent patches are going to need to veto changes in certain pools' size and / or threshold type (mode). Add two fields to the pool's struct that indicate if either of these attributes is allowed to change and enforce that. Signed-off-by:
-
Ido Schimmel authored
The pool indices are currently hard coded throughout the code, which makes the code hard to follow and extend. Overcome this by using defines for the pool indices. Signed-off-by:
-
Ido Schimmel authored
Add extack messages to better communicate invalid configuration to the user. Example: # devlink sb pool set pci/0000:01:00.0 pool 0 size 104857600 thtype dynamic Error: mlxsw_spectrum: Exceeded shared buffer size. devlink answers: Invalid argument Signed-off-by:
-
Ido Schimmel authored
Add extack to shared buffer set operations, so that meaningful error messages could be propagated to the user. Signed-off-by:
-
David S. Miller authored
Paul Gortmaker says: ==================== clean up needless use of module infrastructure People can embed modular includes and modular exit functions into code that never use any of it, and they won't get any errors or warnings. Using modular infrastructure in non-modules might seem harmless, but some of the downfalls this leads to are: (1) it is easy to accidentally write unused module_exit removal code (2) it can be misleading when reading the source, thinking a driver can be modular when the Makefile and/or Kconfig prohibit it (3) an unused include of the module.h header file will in turn include nearly everything else; adding a lot to CPP overhead. (4) it gets copied/replicated into other drivers and spreads quickly. As a data point for #3 above, an empty C file that just includes the module.h header generates over 750kB of CPP output. Repeating the same experiment with init.h and the result is less than 12kB; with export.h it is only about 1/2kB; with both it still is less than 12kB. One driver in this series gets the module.h ---> init.h+export.h conversion. Worse, are headers in include/linux that in turn include <linux/module.h> as they can impact a whole fleet of drivers, or a whole subsystem, so special care should be used in order to avoid that. Such headers should only include what they need to be stand-alone; they should not be trying to anticipate the various header needs of their possible end users. In this series, four include/linux headers have module.h removed from them because they don't strictly need it. Then three chunks of net related code have modular infrastructure that isn't used, removed. There are no runtime changes, so the biggest risk is a genuine consumer of module.h content relying on implicitly getting it from one of the include/linux instances removed here - thus resulting in a build fail. With that in mind, allmodconfig build testing was done on x86-64, arm64, x86-32, arm. powerpc, and mips on linux-next (and hence net-next). ==================== Signed-off-by:
-
