- 24 Apr, 2023 24 commits
-
-
Vasily Khoruzhick authored
The Realtek RTL8723CS is a SDIO WiFi chip. It also contains a Bluetooth module which is connected via UART to the host. It shares lmp subversion with 8703B, so Realtek's userspace initialization tool (rtk_hciattach) differentiates varieties of RTL8723CS (CG, VF, XX) with RTL8703B using vendor's command to read chip type. Also this chip declares support for some features it doesn't support so add a quirk to indicate that these features are broken. Signed-off-by:
Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by:
Bastian Germann <bage@debian.org> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Vasily Khoruzhick authored
Some adapters (e.g. RTL8723CS) advertise that they have more than 2 pages for local ext features, but they don't support any features declared in these pages. RTL8723CS reports max_page = 2 and declares support for sync train and secure connection, but it responds with either garbage or with error in status on corresponding commands. Signed-off-by:
-
Krzysztof Kozlowski authored
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/bluetooth/btmtkuart.c:971:36: error: ‘mt7668_data’ defined but not used [-Werror=unused-const-variable=] drivers/bluetooth/btmtkuart.c:966:36: error: ‘mt7663_data’ defined but not used [-Werror=unused-const-variable=] drivers/bluetooth/btmtkuart.c:962:36: error: ‘mt7622_data’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Krzysztof Kozlowski authored
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/bluetooth/hci_qca.c:1869:37: error: ‘qca_soc_data_wcn6750’ defined but not used [-Werror=unused-const-variable=] drivers/bluetooth/hci_qca.c:1853:37: error: ‘qca_soc_data_wcn3998’ defined but not used [-Werror=unused-const-variable=] drivers/bluetooth/hci_qca.c:1841:37: error: ‘qca_soc_data_wcn3991’ defined but not used [-Werror=unused-const-variable=] drivers/bluetooth/hci_qca.c:1830:37: error: ‘qca_soc_data_wcn3990’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
-
Krzysztof Kozlowski authored
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/bluetooth/btmrvl_sdio.c:43:34: error: ‘btmrvl_sdio_of_match_table’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
-
Krzysztof Kozlowski authored
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it might not be relevant here). drivers/bluetooth/hci_ll.c:769:34: error: ‘hci_ti_of_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
-
Luiz Augusto von Dentz authored
This delays the identity address updates to give time for userspace to process the new address otherwise there is a risk that userspace creates a duplicated device if the MGMT event is delayed for some reason. Signed-off-by: -
Inga Stotland authored
This removes the following duplicate statement in hci_le_ext_directed_advertising_sync(): cp.own_addr_type = own_addr_type; Signed-off-by:
Inga Stotland <inga.stotland@intel.com> Signed-off-by:
-
Brian Gix authored
The msft_set_filter_enable() command was using the deprecated hci_request mechanism rather than hci_sync. This caused the warning error: hci0: HCI_REQ-0xfcf0 Signed-off-by:
Brian Gix <brian.gix@intel.com> Signed-off-by:
-
Archie Pusaka authored
Currently, when we initiate disconnection, we will wait for the peer's reply unless when we are suspending, where we fire and forget the disconnect request. A similar case is when adapter is powering off. However, we still wait for the peer's reply in this case. Therefore, if the peer is unresponsive, the command will time out and the power off sequence will fail, causing "bluetooth powered on by itself" to users. This patch makes the host doesn't wait for the peer's reply when the disconnection reason is powering off. Signed-off-by:
Archie Pusaka <apusaka@chromium.org> Reviewed-by:
Abhishek Pandit-Subedi <abhishekpandit@google.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Meng Tang authored
Tested on Acer Nitro AN515-47 Notebook output from /sys/kernel/debug/usb/devices: T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e0e4 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by:
Meng Tang <tangmeng@uniontech.com> Signed-off-by:
-
Chris Morgan authored
Update the compatible for the Realtek RTL8821CS bluetooth node. Signed-off-by:
Chris Morgan <macromorgan@hotmail.com> Signed-off-by:
-
Chris Morgan authored
RTL8821CS is a WiFi + Bluetooth combo chip from Realtek that provides WiFi A/B/G/N/AC over an SDIO interface and Bluetooth 4.2 over a UART interface. Note that the firmware this was tested with was firmware version 0x75b8f098. Signed-off-by:
-
Chris Morgan authored
Add compatible string for RTL8821CS for existing Realtek Bluetooth driver. Signed-off-by:
Alistair Francis <alistair@alistair23.me> Signed-off-by:
-
Meng Tang authored
This bluetooth device is found in a combo WLAN/BT card for a MediaTek 7663. Tested on Acer Aspire A315-24P Notebook The device information: T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3801 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by:
-
Luiz Augusto von Dentz authored
This fixes the following new warning: net/bluetooth/hci_sync.c:2403 hci_pause_addr_resolution() warn: missing error code? 'err' Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/202302251952.xryXOegd-lkp@intel.com/Signed-off-by:
-
Luiz Augusto von Dentz authored
This makes hci_conn_hash_add append to the tail of the conn_hash so it matches the order they are created, this is required if the controller attempts to match the order of ACL with CIS which uses append logic when programming the CIS ids on the CIG. The result of this change affects Create CIS: Before: < HCI Command: LE Create Connected Isochronous Stream (0x08|0x0064) plen 9 Number of CIS: 2 CIS Handle: 2560 ACL Handle: 3586 CIS Handle: 2561 ACL Handle: 3585 After: < HCI Command: LE Create Connected Isochronous Stream (0x08|0x0064) plen 9 Number of CIS: 2 CIS Handle: 2560 ACL Handle: 3585 CIS Handle: 2561 ACL Handle: 3586 Signed-off-by: -
Victor Hassan authored
Add the support for RTL8852BS BT controller on UART interface. The necessary firmware file will be submitted to linux-firmware. Signed-off-by:
Victor Hassan <victor@allwinnertech.com> Signed-off-by:
-
Stefan Eichenberger authored
Add serdev support for the 88W8997 from NXP (previously Marvell). It includes support for changing the baud rate. The command to change the baud rate is taken from the user manual UM11483 Rev. 9 in section 7 (Bring-up of Bluetooth interfaces) from NXP. Signed-off-by:
Stefan Eichenberger <stefan.eichenberger@toradex.com> Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by:
-
Stefan Eichenberger authored
Use the maybe_unused macro for the device tree ids instead of #ifdef CONFIG_OF. This makes it easier to add support for new devices. Signed-off-by:
-
Stefan Eichenberger authored
The 88W8997 bluetooth module supports setting the max-speed property. Signed-off-by:
-
Stefan Eichenberger authored
Update the documentation with the device tree binding for the Marvell 88W8997 bluetooth device. Signed-off-by:
-
Tomasz Moń authored
Remove hardcoded interface number check because Bluetooth specification since version 4.0 only recommends and no longer requires specific interface numbers. While earlier Bluetooth versions, i.e. 2.1 + EDR and 3.0 + HS, contain required configuration table in Volume 4 - Host Controller Interface Part B - USB Transport Layer, Bluetooth Core Specification Addendum 2 changes the table from required to recommended configuration. Signed-off-by:
Tomasz Moń <tomasz.mon@nordicsemi.no> Signed-off-by:
-
Luiz Augusto von Dentz authored
This makes use of BIT macro when defining bitfields which makes it clearer what bit it is toggling. Signed-off-by:
-
- 23 Apr, 2023 16 commits
-
-
David S. Miller authored
Pedro Tammela says: ==================== net/sched: act_pedit: minor improvements This series aims to improve the code and usability of act_pedit for netlink users. Patches 1-2 improves error reporting for extended keys parsing with extack. Patch 3 checks the static offsets a priori on create/update. Currently, this is done at the datapath for both static and runtime offsets. Patch 4 removes a check from the datapath which is redundant since the netlink parsing validates the key types. Patch 5 changes the 'pr_info()' calls in the datapath to rate limited versions. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Pedro Tammela authored
Unbounded info messages in the pedit datapath can flood the printk ring buffer quite easily depending on the action created. As these messages are informational, usually printing some, not all, is enough to bring attention to the real issue. Reviewed-by:
Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by:
Pedro Tammela <pctammela@mojatatu.com> Signed-off-by:
-
Pedro Tammela authored
The netlink parsing already validates the key 'htype'. Remove the datapath check as it's redundant. Reviewed-by:
-
Pedro Tammela authored
Static key offsets should always be on 32 bit boundaries. Validate them on create/update time for static offsets and move the datapath validation for runtime offsets only. iproute2 already errors out if a given offset and data size cannot be packed to a 32 bit boundary. This change will make sure users which create/update pedit instances directly via netlink also error out, instead of finding out when packets are traversing. Reviewed-by:
-
Pedro Tammela authored
We have extack available when parsing 'ex' keys, so pass it to tcf_pedit_keys_ex_parse and add more detailed error messages. Reviewed-by:
-
Pedro Tammela authored
Transform two checks in the 'ex' key parsing into netlink policies removing extra if checks. Signed-off-by:
-
Yajun Deng authored
The kernel will print several warnings in a short period of time when it stalls. Like this: First warning: [ 7100.097547] ------------[ cut here ]------------ [ 7100.097550] NETDEV WATCHDOG: eno2 (xxx): transmit queue 8 timed out [ 7100.097571] WARNING: CPU: 8 PID: 0 at net/sched/sch_generic.c:467 dev_watchdog+0x260/0x270 ... Second warning: [ 7147.756952] rcu: INFO: rcu_preempt self-detected stall on CPU [ 7147.756958] rcu: 24-....: (59999 ticks this GP) idle=546/1/0x400000000000000 softirq=367 3137/3673146 fqs=13844 [ 7147.756960] (t=60001 jiffies g=4322709 q=133381) [ 7147.756962] NMI backtrace for cpu 24 ... We calculate that the transmit queue start stall should occur before 7095s according to watchdog_timeo, the rcu start stall at 7087s. These two times are close together, it is difficult to confirm which happened first. To let users know the exact time the stall started, print msecs when the transmit queue time out. Signed-off-by:Yajun Deng <yajun.deng@linux.dev> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Remove skb_mac_header() dependency in DSA xmit path Eric started working on removing skb_mac_header() assumptions from the networking xmit path, and I offered to help for DSA: https://lore.kernel.org/netdev/20230321164519.1286357-1-edumazet@google.com/ The majority of this patch set is a straightforward replacement of skb_mac_header() with skb->data (hidden either behind skb_eth_hdr(), or behind skb_vlan_eth_hdr()). The only patch which is more "interesting" is 9/9. Another potential caller of __skb_vlan_pop() on xmit (and therefore also of skb_mac_header()) is tcf_vlan_act(), but I haven't had the time to investigate that (enough to submit changes other than what's here). v1->v2: - 09/09: document the vlan_tci argument of vlan_remove_tag() in the kdoc v1 at: https://lore.kernel.org/netdev/20230322233823.1806736-1-vladimir.oltean@nxp.com/ Cc: Madalin Bucur <madalin.bucur@nxp.com> ==================== Signed-off-by:
-
Vladimir Oltean authored
ocelot_xmit_get_vlan_info() calls __skb_vlan_pop() as the most appropriate helper I could find which strips away a VLAN header. That's all I need it to do, but __skb_vlan_pop() has more logic, which will become incompatible with the future revert of commit 6d1ccff6 ("net: reset mac header in dev_start_xmit()"). Namely, it performs a sanity check on skb_mac_header(), which will stop being set after the above revert, so it will return an error instead of removing the VLAN tag. ocelot_xmit_get_vlan_info() gets called in 2 circumstances: (1) the port is under a VLAN-aware bridge and the bridge sends VLAN-tagged packets (2) the port is under a VLAN-aware bridge and somebody else (an 8021q upper) sends VLAN-tagged packets (using a VID that isn't in the bridge vlan tables) In case (1), there is actually no bug to defend against, because br_dev_xmit() calls skb_reset_mac_header() and things continue to work. However, in case (2), illustrated using the commands below, it can be seen that our intervention is needed, since __skb_vlan_pop() complains: $ ip link add br0 type bridge vlan_filtering 1 && ip link set br0 up $ ip link set $eth master br0 && ip link set $eth up $ ip link add link $eth name $eth.100 type vlan id 100 && ip link set $eth.100 up $ ip addr add 192.168.100.1/24 dev $eth.100 I could fend off the checks in __skb_vlan_pop() with some skb_mac_header_was_set() calls, but seeing how few callers of __skb_vlan_pop() there are from TX paths, that seems rather unproductive. As an alternative solution, extract the bare minimum logic to strip a VLAN header, and move it to a new helper named vlan_remove_tag(), close to the definition of vlan_insert_tag(). Document it appropriately and make ocelot_xmit_get_vlan_info() call this smaller helper instead. Seeing that it doesn't appear illegal to test skb->protocol in the TX path, I guess it would be a good for vlan_remove_tag() to also absorb the vlan_set_encap_proto() function call. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Vladimir Oltean authored
Once commit 6d1ccff6 ("net: reset mac header in dev_start_xmit()") will be reverted, it will no longer be true that skb->data points at skb_mac_header(skb) - since the skb->mac_header will not be set - so stop saying that, and just say that it points to the MAC header. I've reviewed vlan_insert_tag() and it does not *actually* depend on skb_mac_header(), so reword that to avoid the confusion. Signed-off-by:
-
Vladimir Oltean authored
This is a cosmetic patch which consolidates the code to use the helper function offered by if_vlan.h. Signed-off-by:
-
Vladimir Oltean authored
skb_mac_header() will no longer be available in the TX path when reverting commit 6d1ccff6 ("net: reset mac header in dev_start_xmit()"). As preparation for that, let's use skb_vlan_eth_hdr() to get to the VLAN header instead, which assumes it's located at skb->data (assumption which holds true here). Signed-off-by:
-
Vladimir Oltean authored
skb_mac_header() will no longer be available in the TX path when reverting commit 6d1ccff6 ("net: reset mac header in dev_start_xmit()"). As preparation for that, let's use skb_eth_hdr() to get to the Ethernet header's MAC DA instead, helper which assumes this header is located at skb->data (assumption which holds true here). Signed-off-by:
-
Vladimir Oltean authored
skb_mac_header() will no longer be available in the TX path when reverting commit 6d1ccff6 ("net: reset mac header in dev_start_xmit()"). As preparation for that, let's use skb_vlan_eth_hdr() to get to the VLAN header instead, which assumes it's located at skb->data (assumption which holds true here). Signed-off-by:
-
Vladimir Oltean authored
It appears that dpaa_enable_tx_csum() only calls skb_reset_mac_header() to get to the VLAN header using skb_mac_header(). We can use skb_vlan_eth_hdr() to get to the VLAN header based on skb->data directly. This avoids spending a few cycles to set skb->mac_header. Signed-off-by:
Madalin Bucur <madalin.bucur@oss.nxp.com> Signed-off-by:
-
Vladimir Oltean authored
Similar to skb_eth_hdr() introduced in commit 96cc4b69 ("macvlan: do not assume mac_header is set in macvlan_broadcast()"), let's introduce a skb_vlan_eth_hdr() helper which can be used in TX-only code paths to get to the VLAN header based on skb->data rather than based on the skb_mac_header(skb). We also consolidate the drivers that dereference skb->data to go through this helper. Signed-off-by:
-
