- 24 Apr, 2023 15 commits
-
-
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:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
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:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-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 25 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:
-
Vladimir Oltean authored
This is a preparatory change for the deletion of skb_reset_mac_header(skb) from __dev_queue_xmit(). After that deletion, skb_mac_header(skb) will no longer be set in TX paths, from which __vlan_insert_inner_tag() can still be called (perhaps indirectly). If we don't make this change, then an unset MAC header (equal to ~0U) will become set after the adjustment with VLAN_HLEN. Signed-off-by:
-
Ramón Nordin Rodriguez authored
This patch adds support for the Microchip LAN867x 10BASE-T1S family (LAN8670/1/2). The driver supports P2MP with PLCA. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Ramón Nordin Rodriguez <ramon.nordin.rodriguez@ferroamp.se> Signed-off-by:
-
Gustavo A. R. Silva authored
Zero-length arrays as fake flexible arrays are deprecated and we are moving towards adopting C99 flexible-array members instead. Transform zero-length array into flexible-array member in struct rxrpc_ackpacket. Address the following warnings found with GCC-13 and -fstrict-flex-arrays=3 enabled: net/rxrpc/call_event.c:149:38: warning: array subscript i is outside array bounds of ‘uint8_t[0]’ {aka ‘unsigned char[]’} [-Warray-bounds=] This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/21 Link: https://github.com/KSPP/linux/issues/263 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
David Howells <dhowells@redhat.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Jeffrey Altman <jaltman@auristor.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org cc: linux-hardening@vger.kernel.org Link: https://lore.kernel.org/r/ZAZT11n4q5bBttW0@work/Signed-off-by:
-
David S. Miller authored
Eric Dumazet says: ==================== net: give napi_threaded_poll() some love There is interest to revert commit 4cd13c21 ("softirq: Let ksoftirqd do its job") and use instead the napi_threaded_poll() mode. https://lore.kernel.org/netdev/140f61e2e1fcb8cf53619709046e312e343b53ca.camel@redhat.com/T/#m8a8f5b09844adba157ad0d22fc1233d97013de50 Before doing so, make sure napi_threaded_poll() benefits from recent core stack improvements, to further reduce softirq triggers. ==================== Signed-off-by:
-
Eric Dumazet authored
We use napi_threaded_poll() in order to reduce our softirq dependency. We can add a followup of 821eba96 ("net: optimize napi_schedule_rps()") to further remove the need of firing NET_RX_SOFTIRQ whenever RPS/RFS are used. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Eric Dumazet authored
If we call skb_defer_free_flush() from napi_threaded_poll(), we can avoid to raise IPI from skb_attempt_defer_free() when the list becomes too big. This allows napi_threaded_poll() to rely less on softirqs, and lowers latency caused by a too big list. Signed-off-by:
-
Eric Dumazet authored
We plan using skb_defer_free_flush() from napi_threaded_poll() in the following patch. Signed-off-by:
-
Eric Dumazet authored
kfree_skb() can be called from hard irq handlers, but skb_attempt_defer_free() is meant to be used from process or BH contexts, and skb_defer_free_flush() is meant to be called from BH contexts. Not having to mask hard irq can save some cycles. Signed-off-by:
-
Eric Dumazet authored
Make sure skbs that are stored in softnet_data.defer_list do not have a dst attached. Also make sure the the skb was orphaned. Link: https://lore.kernel.org/netdev/CANn89iJuEVe72bPmEftyEJHLzzN=QNR2yueFjTxYXCEpS5S8HQ@mail.gmail.com/T/Signed-off-by:
-
