May 2024 - Linux-stable-mirror

Re: [PATCH v3] af_packet: Handle outgoing VLAN packets without hardware offloading

by Willem de Bruijn

On Mon, May 27, 2024 at 11:40 PM Chengen Du <chengen.du(a)canonical.com> wrote: > > Hi Willem, > > Thank you for your suggestions on the patch. > However, there are some parts I am not familiar with, and I would appreciate more detailed information from your side. Please respond with plain-text email. This message did not make it to the list. Also no top posting. https://docs.kernel.org/process/submitting-patches.html https://subspace.kernel.org/etiquette.html > > > @@ -2457,7 +2465,8 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev, > > > sll->sll_halen = dev_parse_header(skb, sll->sll_addr); > > > sll->sll_family = AF_PACKET; > > > sll->sll_hatype = dev->type; > > > - sll->sll_protocol = skb->protocol; > > > + sll->sll_protocol = (skb->protocol == htons(ETH_P_8021Q)) ? > > > + vlan_eth_hdr(skb)->h_vlan_encapsulated_proto : skb->protocol; > > > > In SOCK_RAW mode, the VLAN tag will be present, so should be returned. > > Based on libpcap's handling, the SLL may not be used in SOCK_RAW mode. The kernel fills in the sockaddr_ll fields in tpacket_rcv for both SOCK_RAW and SOCK_DGRAM. Libpcap already can use both SOCK_RAW and SOCK_DGRAM. And constructs the sll2_header pseudo header that tcpdump sees itself, in pcap_handle_packet_mmap. > Do you recommend evaluating the mode and maintaining the original logic in SOCK_RAW mode, > or should we use the same logic for both SOCK_DGRAM and SOCK_RAW modes? I suggest keeping as is for SOCK_RAW, as returning data that starts at a VLAN header together with skb->protocol of ETH_P_IPV6 would be just as confusing as the inverse that we do today on SOCK_DGRAM. > > > > I'm concerned about returning a different value between SOCK_RAW and > > SOCK_DGRAM. But don't immediately see a better option. And for > > SOCK_DGRAM this approach is indistinguishable from the result on a > > device with hardware offload, so is acceptable. > > > > This test for ETH_P_8021Q ignores the QinQ stacked VLAN case. When > > fixing VLAN encap, both variants should be addressed at the same time. > > Note that ETH_P_8021AD is included in the eth_type_vlan test you call > > above. > > In patch 1, the eth_type_vlan() function is used to determine if we need to set the sll_protocol to the VLAN-encapsulated protocol, which includes both ETH_P_8021Q and ETH_P_8021AD. > You mentioned previously that we might want the true network protocol instead of the inner VLAN tag in the QinQ case (which means 802.1ad?). > I believe I may have misunderstood your point. I mean that if SOCK_DGRAM strips all VLAN headers to return the data from the start of the true network header, then skb->protocol should return that network protocol. With vlan stacking, your patch currently returns ETH_P_8021Q. See the packet formats in https://en.wikipedia.org/wiki/IEEE_802.1ad#Frame_format if you're confused about how stacking works. > Could you please confirm if both ETH_P_8021Q and ETH_P_8021AD should use the VLAN-encapsulated protocol when VLAN hardware offloading is unavailable? > Or are there other aspects that this judgment does not handle correctly?

1 year, 6 months

1
0
0 0

[PATCH] Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x13d3:0x3591

by WangYuli

Add the support ID(0x13d3, 0x3591) to usb_device_id table for Realtek RTL8852BE. The device table is as follows: T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3591 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA 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=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 Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Guan <guanwentao(a)uniontech.com> Signed-off-by: WangYuli <wangyuli(a)uniontech.com> --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 79aefdb3324d..7b9421423ebc 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -555,6 +555,8 @@ static const struct usb_device_id quirks_table[] = { BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x13d3, 0x3572), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x13d3, 0x3591), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, /* Realtek 8852BT/8852BE-VT Bluetooth devices */ { USB_DEVICE(0x0bda, 0x8520), .driver_info = BTUSB_REALTEK | -- 2.45.1

1 year, 6 months

1
0
0 0

[PATCH 1/1] j1939: recover socket queue on CAN bus error during BAM transmission

by Oleksij Rempel

Addresses an issue where a CAN bus error during a BAM transmission could stall the socket queue, preventing further transmissions even after the bus error is resolved. The fix activates the next queued session after the error recovery, allowing communication to continue. Fixes: 9d71dd0c70099 ("can: add support of SAE J1939 protocol") Cc: stable(a)vger.kernel.org Reported-by: Alexander Hölzl <alexander.hoelzl(a)gmx.net> Tested-by: Alexander Hölzl <alexander.hoelzl(a)gmx.net> Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> --- net/can/j1939/transport.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c index fe3df23a25957..9805124d16763 100644 --- a/net/can/j1939/transport.c +++ b/net/can/j1939/transport.c @@ -1681,6 +1681,8 @@ static int j1939_xtp_rx_rts_session_active(struct j1939_session *session, j1939_session_timers_cancel(session); j1939_session_cancel(session, J1939_XTP_ABORT_BUSY); + if (session->transmission) + j1939_session_deactivate_activate_next(session); return -EBUSY; } -- 2.39.2

1 year, 6 months

2
1
0 0

Quick note, current 6.1 q successful test

by Eddie Chapman

Just a quick note to say I've just booted 6.1.92, plus the 274 patches in the current stable queue applied, on an x86-64 workstation and no problems or issues to report, no unexpected errors in dmesg. (AMD Ryzen, 3 x AMD gpu, sata, nvme, lots of USB, Gentoo, SELinux, KDE) Eddie

1 year, 6 months

1
0
0 0

[PATCH V3 1/8] clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL

by Ajit Pandey

In LUCID EVO PLL CAL_L_VAL and L_VAL bitfields are part of single PLL_L_VAL register. Update for L_VAL bitfield values in PLL_L_VAL register using regmap_write() API in __alpha_pll_trion_set_rate callback will override LUCID EVO PLL initial configuration related to PLL_CAL_L_VAL bit fields in PLL_L_VAL register. Observed random PLL lock failures during PLL enable due to such override in PLL calibration value. Use regmap_update_bits() with L_VAL bitfield mask instead of regmap_write() API to update only PLL_L_VAL bitfields in __alpha_pll_trion_set_rate callback. Fixes: 260e36606a03 ("clk: qcom: clk-alpha-pll: add Lucid EVO PLL configuration interfaces") Cc: stable(a)vger.kernel.org Signed-off-by: Ajit Pandey <quic_ajipan(a)quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- drivers/clk/qcom/clk-alpha-pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c index d4227909d1fe..62138ed3df88 100644 --- a/drivers/clk/qcom/clk-alpha-pll.c +++ b/drivers/clk/qcom/clk-alpha-pll.c @@ -1665,7 +1665,7 @@ static int __alpha_pll_trion_set_rate(struct clk_hw *hw, unsigned long rate, if (ret < 0) return ret; - regmap_write(pll->clkr.regmap, PLL_L_VAL(pll), l); + regmap_update_bits(pll->clkr.regmap, PLL_L_VAL(pll), LUCID_EVO_PLL_L_VAL_MASK, l); regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), a); /* Latch the PLL input */ -- 2.25.1

1 year, 6 months

1
0
0 0

[PATCH v2 2/2] xhci: Apply broken streams quirk to Etron EJ188 xHCI host

by Kuangyi Chiang

As described in commit 8f873c1ff4ca ("xhci: Blacklist using streams on the Etron EJ168 controller"), EJ188 have the same issue as EJ168, where Streams do not work reliable on EJ188. So apply XHCI_BROKEN_STREAMS quirk to EJ188 as well. Cc: <stable(a)vger.kernel.org> Signed-off-by: Kuangyi Chiang <ki.chiang65(a)gmail.com> --- Changes in v2: - Porting to latest release drivers/usb/host/xhci-pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index b47d57d80b96..effeec5cf1fa 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -399,6 +399,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) if (pdev->vendor == PCI_VENDOR_ID_ETRON && pdev->device == PCI_DEVICE_ID_EJ188) { xhci->quirks |= XHCI_RESET_ON_RESUME; + xhci->quirks |= XHCI_BROKEN_STREAMS; } if (pdev->vendor == PCI_VENDOR_ID_RENESAS && pdev->device == 0x0014) { -- 2.25.1

1 year, 6 months

3
3
0 0

[PATCH 0/2] cpufreq: qcom-nvmem: fix memory leaks and add auto device node cleanup

by Javier Carrasco

There are a number of error paths in the probe function that do not call of_node_put() to decrement the np device node refcount, leading to memory leaks if those errors occur. In order to ease backporting, the fix has been divided into two patches: the first one simply adds the missing calls to of_node_put(), and the second one adds the __free() macro to the existing device nodes to remove the need for of_node_put(), ensuring that the same bug will not arise in the future. The issue was found by chance while analyzing the code, and I do not have the hardware to test it beyond compiling and static analysis tools. Although the issue is clear and the fix too, if someone wants to volunteer to test the series with real hardware, it would be great. Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- Javier Carrasco (2): cpufreq: qcom-nvmem: fix memory leaks in probe error paths cpufreq: qcom-nvmem: eliminate uses of of_node_put() drivers/cpufreq/qcom-cpufreq-nvmem.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) --- base-commit: 3689b0ef08b70e4e03b82ebd37730a03a672853a change-id: 20240523-qcom-cpufreq-nvmem_memleak-6b6821db52b1 Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

1 year, 6 months

2
2
0 0

[PATCH v2 2/2] xhci: Apply broken streams quirk to Etron EJ188 xHCI host

by Kuangyi Chiang

As described in commit 8f873c1ff4ca ("xhci: Blacklist using streams on the Etron EJ168 controller"), EJ188 have the same issue as EJ168, where Streams do not work reliable on EJ188. So apply XHCI_BROKEN_STREAMS quirk to EJ188 as well. Cc: <stable(a)vger.kernel.org> Signed-off-by: Kuangyi Chiang <ki.chiang65(a)gmail.com> --- Changes in v2: - Porting to latest release drivers/usb/host/xhci-pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index b47d57d80b96..effeec5cf1fa 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -399,6 +399,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) if (pdev->vendor == PCI_VENDOR_ID_ETRON && pdev->device == PCI_DEVICE_ID_EJ188) { xhci->quirks |= XHCI_RESET_ON_RESUME; + xhci->quirks |= XHCI_BROKEN_STREAMS; } if (pdev->vendor == PCI_VENDOR_ID_RENESAS && pdev->device == 0x0014) { -- 2.25.1

1 year, 6 months

1
1
0 0

[PATCH AUTOSEL 4.19] power: supply: cros_usbpd: provide ID table for avoiding fallback match

by Sasha Levin

From: Tzung-Bi Shih <tzungbi(a)kernel.org> [ Upstream commit 0f8678c34cbfdc63569a9b0ede1fe235ec6ec693 ] Instead of using fallback driver name match, provide ID table[1] for the primary match. [1]: https://elixir.bootlin.com/linux/v6.8/source/drivers/base/platform.c#L1353 Reviewed-by: Benson Leung <bleung(a)chromium.org> Reviewed-by: Prashant Malani <pmalani(a)chromium.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Signed-off-by: Tzung-Bi Shih <tzungbi(a)kernel.org> Link: https://lore.kernel.org/r/20240401030052.2887845-4-tzungbi@kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/power/supply/cros_usbpd-charger.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/power/supply/cros_usbpd-charger.c b/drivers/power/supply/cros_usbpd-charger.c index 74b5914abbf7e..123a5572fe5b1 100644 --- a/drivers/power/supply/cros_usbpd-charger.c +++ b/drivers/power/supply/cros_usbpd-charger.c @@ -5,6 +5,7 @@ * Copyright (c) 2014 - 2018 Google, Inc */ +#include <linux/mod_devicetable.h> #include <linux/module.h> #include <linux/mfd/cros_ec.h> #include <linux/mfd/cros_ec_commands.h> @@ -530,16 +531,22 @@ static int cros_usbpd_charger_resume(struct device *dev) static SIMPLE_DEV_PM_OPS(cros_usbpd_charger_pm_ops, NULL, cros_usbpd_charger_resume); +static const struct platform_device_id cros_usbpd_charger_id[] = { + { DRV_NAME, 0 }, + {} +}; +MODULE_DEVICE_TABLE(platform, cros_usbpd_charger_id); + static struct platform_driver cros_usbpd_charger_driver = { .driver = { .name = DRV_NAME, .pm = &cros_usbpd_charger_pm_ops, }, - .probe = cros_usbpd_charger_probe + .probe = cros_usbpd_charger_probe, + .id_table = cros_usbpd_charger_id, }; module_platform_driver(cros_usbpd_charger_driver); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("ChromeOS EC USBPD charger"); -MODULE_ALIAS("platform:" DRV_NAME); -- 2.43.0

1 year, 6 months

1
0
0 0

[PATCH AUTOSEL 5.10 1/2] power: supply: cros_usbpd: provide ID table for avoiding fallback match

by Sasha Levin

From: Tzung-Bi Shih <tzungbi(a)kernel.org> [ Upstream commit 0f8678c34cbfdc63569a9b0ede1fe235ec6ec693 ] Instead of using fallback driver name match, provide ID table[1] for the primary match. [1]: https://elixir.bootlin.com/linux/v6.8/source/drivers/base/platform.c#L1353 Reviewed-by: Benson Leung <bleung(a)chromium.org> Reviewed-by: Prashant Malani <pmalani(a)chromium.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Signed-off-by: Tzung-Bi Shih <tzungbi(a)kernel.org> Link: https://lore.kernel.org/r/20240401030052.2887845-4-tzungbi@kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/power/supply/cros_usbpd-charger.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/power/supply/cros_usbpd-charger.c b/drivers/power/supply/cros_usbpd-charger.c index 0a4f02e4ae7ba..d7ee1eb9ca880 100644 --- a/drivers/power/supply/cros_usbpd-charger.c +++ b/drivers/power/supply/cros_usbpd-charger.c @@ -5,6 +5,7 @@ * Copyright (c) 2014 - 2018 Google, Inc */ +#include <linux/mod_devicetable.h> #include <linux/module.h> #include <linux/platform_data/cros_ec_commands.h> #include <linux/platform_data/cros_ec_proto.h> @@ -711,16 +712,22 @@ static int cros_usbpd_charger_resume(struct device *dev) static SIMPLE_DEV_PM_OPS(cros_usbpd_charger_pm_ops, NULL, cros_usbpd_charger_resume); +static const struct platform_device_id cros_usbpd_charger_id[] = { + { DRV_NAME, 0 }, + {} +}; +MODULE_DEVICE_TABLE(platform, cros_usbpd_charger_id); + static struct platform_driver cros_usbpd_charger_driver = { .driver = { .name = DRV_NAME, .pm = &cros_usbpd_charger_pm_ops, }, - .probe = cros_usbpd_charger_probe + .probe = cros_usbpd_charger_probe, + .id_table = cros_usbpd_charger_id, }; module_platform_driver(cros_usbpd_charger_driver); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("ChromeOS EC USBPD charger"); -MODULE_ALIAS("platform:" DRV_NAME); -- 2.43.0

1 year, 6 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024