April 2024 - Linux-stable-mirror

by dcrady＠os.amperecomputing.com

Please backport the following v6.7 commit: commit be097997a273 ("KVM: arm64: Always invalidate TLB for stage-2 permission faults") to stable kernels v5.15 and newer to fix: It is possible for multiple vCPUs to fault on the same IPA and attempt to resolve the fault. One of the page table walks will actually update the PTE and the rest will return -EAGAIN per our race detection scheme. KVM elides the TLB invalidation on the racing threads as the return value is nonzero. Before commit a12ab1378a88 ("KVM: arm64: Use local TLBI on permission relaxation") KVM always used broadcast TLB invalidations when handling permission faults, which had the convenient property of making the stage-2 updates visible to all CPUs in the system. However now we do a local invalidation, and TLBI elision leads to the vCPU thread faulting again on the stale entry. Remember that the architecture permits the TLB to cache translations that precipitate a permission fault. Invalidate the TLB entry responsible for the permission fault if the stage-2 descriptor has been relaxed, regardless of which thread actually did the job. Thank you! doug rady

8 months, 3 weeks

2
2
0 0

Re: [PATCH] arm64: dts: mediatek: mt8395-genio-1200-evk: add u3port1 for xhci1

by Macpaul Lin

On 2/16/24 17:57, Macpaul Lin wrote: > This patch fixes an issue where xhci1 was not functioning properly because > the state and PHY settings were incorrect. > > The introduction of the 'force-mode' property in the phy-mtk-tphy driver > allows for the correct initialization of xhci1 by updating the Device Tree > settings accordingly. > > The necessary fixup which added support for the 'force-mode' switch in the > phy-mtk-tphy driver. > commit 9b27303003f5 ("phy: mediatek: tphy: add support force phy mode switch") > Link: https://lore.kernel.org/r/20231211025624.28991-2-chunfeng.yun@mediatek.com Dear AngeloGioacchino, Just a soft reminding about the patch has been sent a while back for the shared U3PHY and PCIe PHY setup for genio-1200 boards. I'm not sure if you've missed this patch in mail box. :) The patch is pretty important as it lets the device tree (dts) decide whether to enable U3PHY or PCIe PHY. Because this is a shared hardware phy and could only be configured in dts to decide which function to be initialized, so it's something that should be included in the board-specific dts files. Do you think it needs to be resubmitted, or is it still in the queue for review? It's meant to be ready for action from kernel version 6.8 onwards. Looking forward to your thoughts on this. Let me know if there's anything else you need from my side. > Prior to this fix, the system would exhibit the following probe failure messages > for xhci1: > xhci-mtk 11290000.usb: supply vbus not found, using dummy regulator > xhci-mtk 11290000.usb: uwk - reg:0x400, version:104 > xhci-mtk 11290000.usb: xHCI Host Controller > xhci-mtk 11290000.usb: new USB bus registered, assigned bus number 5 > xhci-mtk 11290000.usb: clocks are not stable (0x1003d0f) > xhci-mtk 11290000.usb: can't setup: -110 > xhci-mtk 11290000.usb: USB bus 5 deregistered > xhci-mtk: probe of 11290000.usb failed with error -110 > > With the application of this dts fixup, the aforementioned initialization errors > are resolved and xhci1 is working. > > Signed-off-by: Macpaul Lin <macpaul.lin(a)mediatek.com> > --- > arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts > index 7fc515a07c65..e0b9f2615c11 100644 > --- a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts > +++ b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts > @@ -854,6 +854,10 @@ > > &u3phy1 { > status = "okay"; > + > + u3port1: usb-phy@700 { > + mediatek,force-mode; > + }; > }; > > &u3phy2 { > @@ -885,6 +889,8 @@ > }; > > &xhci1 { > + phys = <&u2port1 PHY_TYPE_USB2>, > + <&u3port1 PHY_TYPE_USB3>; > vusb33-supply = <&mt6359_vusb_ldo_reg>; > status = "okay"; > }; Thanks Macpaul Lin

8 months, 3 weeks

2
1
0 0

[PATCH 1/2 v3] USB: serial: option: add Lonsung U8300/U9300 product

by Coia Prant

Update the USB serial option driver to support Longsung U8300/U9300. For U8300 Interface 4 is used by for QMI interface in stock firmware of U8300, the router which uses U8300 modem. Free the interface up, to rebind it to qmi_wwan driver. Interface 5 is used by for ADB interface in stock firmware of U8300, the router which uses U8300 modem. Free the interface up. The proper configuration is: Interface mapping is: 0: unknown (Debug), 1: AT (Modem), 2: AT, 3: PPP (NDIS / Pipe), 4: QMI, 5: ADB T: Bus=05 Lev=01 Prnt=03 Port=02 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1c9e ProdID=9b05 Rev=03.18 S: Manufacturer=Android S: Product=Android C: #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms For U9300 Interface 1 is used by for ADB interface in stock firmware of U9300, the router which uses U9300 modem. Free the interface up. Interface 4 is used by for QMI interface in stock firmware of U9300, the router which uses U9300 modem. Free the interface up, to rebind it to qmi_wwan driver. The proper configuration is: Interface mapping is: 0: ADB, 1: AT (Modem), 2: AT, 3: PPP (NDIS / Pipe), 4: QMI Note: Interface 3 of some models of the U9300 series can send AT commands. T: Bus=05 Lev=01 Prnt=05 Port=04 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1c9e ProdID=9b3c Rev=03.18 S: Manufacturer=Android S: Product=Android C: #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms Tested successfully using Modem Manager on U9300. Tested successfully AT commands using If=1, If=2 and If=3 on U9300. Signed-off-by: Coia Prant <coiaprant(a)gmail.com> Reviewed-by: Lars Melin <larsm17(a)gmail.com> Cc: stable(a)vger.kernel.org Cc: netdev(a)vger.kernel.org --- drivers/usb/serial/option.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index 55a65d941ccb..27a116901459 100644 --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -412,6 +412,10 @@ static void option_instat_callback(struct urb *urb); */ #define LONGCHEER_VENDOR_ID 0x1c9e +/* Longsung products */ +#define LONGSUNG_U8300_PRODUCT_ID 0x9b05 +#define LONGSUNG_U9300_PRODUCT_ID 0x9b3c + /* 4G Systems products */ /* This one was sold as the VW and Skoda "Carstick LTE" */ #define FOUR_G_SYSTEMS_PRODUCT_CARSTICK_LTE 0x7605 @@ -2054,6 +2058,10 @@ static const struct usb_device_id option_ids[] = { .driver_info = RSVD(4) }, { USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) }, { USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) }, + { USB_DEVICE(LONGCHEER_VENDOR_ID, LONGSUNG_U8300_PRODUCT_ID), + .driver_info = RSVD(4) | RSVD(5) }, + { USB_DEVICE(LONGCHEER_VENDOR_ID, LONGSUNG_U9300_PRODUCT_ID), + .driver_info = RSVD(0) | RSVD(4) }, { USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) }, { USB_DEVICE_AND_INTERFACE_INFO(HAIER_VENDOR_ID, HAIER_PRODUCT_CE81B, 0xff, 0xff, 0xff) }, /* Pirelli */ -- 2.39.2

8 months, 3 weeks

3
2
0 0

[PATCH v2 2/2] wifi: rtl8xxxu: enable MFP support with security flag of RX descriptor

by Martin Kaistra

In order to connect to networks which require 802.11w, add the MFP_CAPABLE flag and let mac80211 do the actual crypto in software. When a robust management frame is received, rx_dec->swdec is not set, even though the HW did not decrypt it. Extend the check and don't set RX_FLAG_DECRYPTED for these frames in order to use SW decryption. Use the security flag in the RX descriptor for this purpose, like it is done in the rtw88 driver. Cc: stable(a)vger.kernel.org Signed-off-by: Martin Kaistra <martin.kaistra(a)linutronix.de> --- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 9 +++++++++ drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 7 +++++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h index fd92d23c43d91..16d884a3d87df 100644 --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h @@ -122,6 +122,15 @@ enum rtl8xxxu_rx_type { RX_TYPE_ERROR = -1 }; +enum rtl8xxxu_rx_desc_enc { + RX_DESC_ENC_NONE = 0, + RX_DESC_ENC_WEP40 = 1, + RX_DESC_ENC_TKIP_WO_MIC = 2, + RX_DESC_ENC_TKIP_MIC = 3, + RX_DESC_ENC_AES = 4, + RX_DESC_ENC_WEP104 = 5, +}; + struct rtl8xxxu_rxdesc16 { #ifdef __LITTLE_ENDIAN u32 pktlen:14; diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c index 4a49f8f9d80f2..b15a30a54259e 100644 --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c @@ -6473,7 +6473,8 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb) rx_status->mactime = rx_desc->tsfl; rx_status->flag |= RX_FLAG_MACTIME_START; - if (!rx_desc->swdec) + if (!rx_desc->swdec && + rx_desc->security != RX_DESC_ENC_NONE) rx_status->flag |= RX_FLAG_DECRYPTED; if (rx_desc->crc32) rx_status->flag |= RX_FLAG_FAILED_FCS_CRC; @@ -6578,7 +6579,8 @@ int rtl8xxxu_parse_rxdesc24(struct rtl8xxxu_priv *priv, struct sk_buff *skb) rx_status->mactime = rx_desc->tsfl; rx_status->flag |= RX_FLAG_MACTIME_START; - if (!rx_desc->swdec) + if (!rx_desc->swdec && + rx_desc->security != RX_DESC_ENC_NONE) rx_status->flag |= RX_FLAG_DECRYPTED; if (rx_desc->crc32) rx_status->flag |= RX_FLAG_FAILED_FCS_CRC; @@ -7998,6 +8000,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface, ieee80211_hw_set(hw, HAS_RATE_CONTROL); ieee80211_hw_set(hw, SUPPORT_FAST_XMIT); ieee80211_hw_set(hw, AMPDU_AGGREGATION); + ieee80211_hw_set(hw, MFP_CAPABLE); wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST); -- 2.39.2

8 months, 3 weeks

1
0
0 0

[PATCH 2/2] wifi: rtl8xxxu: enable MFP support

by Martin Kaistra

In order to connect to networks which require 802.11w, add the MFP_CAPABLE flag and let mac80211 do the actual crypto in software. When a robust management frame is received, rx_dec->swdec is not set, even though the HW did not decrypt it. Extend the check and don't set RX_FLAG_DECRYPTED for these frames in order to use SW decryption. Use the security flag in the RX descriptor for this purpose, like it is done in the rtw88 driver. Cc: stable(a)vger.kernel.org Signed-off-by: Martin Kaistra <martin.kaistra(a)linutronix.de> --- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 9 +++++++++ drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 7 +++++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h index fd92d23c43d91..4f2615dbfd0f0 100644 --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h @@ -122,6 +122,15 @@ enum rtl8xxxu_rx_type { RX_TYPE_ERROR = -1 }; +enum rtw_rx_desc_enc { + RX_DESC_ENC_NONE = 0, + RX_DESC_ENC_WEP40 = 1, + RX_DESC_ENC_TKIP_WO_MIC = 2, + RX_DESC_ENC_TKIP_MIC = 3, + RX_DESC_ENC_AES = 4, + RX_DESC_ENC_WEP104 = 5, +}; + struct rtl8xxxu_rxdesc16 { #ifdef __LITTLE_ENDIAN u32 pktlen:14; diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c index 4a49f8f9d80f2..b15a30a54259e 100644 --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c @@ -6473,7 +6473,8 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb) rx_status->mactime = rx_desc->tsfl; rx_status->flag |= RX_FLAG_MACTIME_START; - if (!rx_desc->swdec) + if (!rx_desc->swdec && + rx_desc->security != RX_DESC_ENC_NONE) rx_status->flag |= RX_FLAG_DECRYPTED; if (rx_desc->crc32) rx_status->flag |= RX_FLAG_FAILED_FCS_CRC; @@ -6578,7 +6579,8 @@ int rtl8xxxu_parse_rxdesc24(struct rtl8xxxu_priv *priv, struct sk_buff *skb) rx_status->mactime = rx_desc->tsfl; rx_status->flag |= RX_FLAG_MACTIME_START; - if (!rx_desc->swdec) + if (!rx_desc->swdec && + rx_desc->security != RX_DESC_ENC_NONE) rx_status->flag |= RX_FLAG_DECRYPTED; if (rx_desc->crc32) rx_status->flag |= RX_FLAG_FAILED_FCS_CRC; @@ -7998,6 +8000,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface, ieee80211_hw_set(hw, HAS_RATE_CONTROL); ieee80211_hw_set(hw, SUPPORT_FAST_XMIT); ieee80211_hw_set(hw, AMPDU_AGGREGATION); + ieee80211_hw_set(hw, MFP_CAPABLE); wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST); -- 2.39.2

8 months, 3 weeks

2
3
0 0

[PATCH] ALSA: hda/realtek: Fix internal speakers for Legion Y9000X 2022 IAH7

by ArcticLampyrid

This fixes the sound not working from internal speakers on Lenovo Legion Y9000X 2022 IAH7 models. Signed-off-by: ArcticLampyrid <ArcticLampyrid(a)outlook.com> Cc: <stable(a)vger.kernel.org> --- sound/pci/hda/cs35l41_hda_property.c | 17 +++++++++++++++++ sound/pci/hda/patch_realtek.c | 1 + 2 files changed, 18 insertions(+) diff --git a/sound/pci/hda/cs35l41_hda_property.c b/sound/pci/hda/cs35l41_hda_property.c index 8fb688e41..244e41d51 100644 --- a/sound/pci/hda/cs35l41_hda_property.c +++ b/sound/pci/hda/cs35l41_hda_property.c @@ -109,6 +109,7 @@ static const struct cs35l41_config cs35l41_config_table[] = { { "10431F1F", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 1, -1, 0, 0, 0, 0 }, { "10431F62", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 1, 2, 0, 0, 0, 0 }, { "10433A60", 2, INTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 1, 2, 0, 1000, 4500, 24 }, + { "17AA386E", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, 1, -1, 0, 0, 0 }, { "17AA386F", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, -1, -1, 0, 0, 0 }, { "17AA3877", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, 1, -1, 0, 0, 0 }, { "17AA3878", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, 1, -1, 0, 0, 0 }, @@ -414,6 +415,21 @@ static int lenovo_legion_no_acpi(struct cs35l41_hda *cs35l41, struct device *phy return 0; } +/* + * Some devices just have a single interrupt line for multiple amps, for which we + * should just register the interrupt for the first amp. Otherwise, we would meet EBUSY + * when registering the interrupt for the second amp. + */ +static int single_interrupt_dsd_config(struct cs35l41_hda *cs35l41, struct device *physdev, int id, + const char *hid) +{ + generic_dsd_config(cs35l41, physdev, id, hid); + if (id != 0x40) { + cs35l41->hw_cfg.gpio2.func = CS35L41_NOT_USED; + } + return 0; +} + struct cs35l41_prop_model { const char *hid; const char *ssid; @@ -500,6 +516,7 @@ static const struct cs35l41_prop_model cs35l41_prop_model_table[] = { { "CSC3551", "10431F1F", generic_dsd_config }, { "CSC3551", "10431F62", generic_dsd_config }, { "CSC3551", "10433A60", generic_dsd_config }, + { "CSC3551", "17AA386E", single_interrupt_dsd_config }, { "CSC3551", "17AA386F", generic_dsd_config }, { "CSC3551", "17AA3877", generic_dsd_config }, { "CSC3551", "17AA3878", generic_dsd_config }, diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index cdcb28aa9..ac729187f 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10382,6 +10382,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x3853, "Lenovo Yoga 7 15ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x3855, "Legion 7 16ITHG6", ALC287_FIXUP_LEGION_16ITHG6), SND_PCI_QUIRK(0x17aa, 0x3869, "Lenovo Yoga7 14IAL7", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), + SND_PCI_QUIRK(0x17aa, 0x386e, "Legion Y9000X 2022 IAH7", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x17aa, 0x386f, "Legion 7i 16IAX7", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x17aa, 0x3870, "Lenovo Yoga 7 14ARB7", ALC287_FIXUP_YOGA7_14ARB7_I2C), SND_PCI_QUIRK(0x17aa, 0x3877, "Lenovo Legion 7 Slim 16ARHA7", ALC287_FIXUP_CS35L41_I2C_2), -- 2.44.0

8 months, 3 weeks

2
5
0 0

[PATCH v2 0/2] usb: dwc3: Disable susphy during initialization

by Thinh Nguyen

We notice some platforms set "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Just make sure that the GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY are clear during initialization. The host initialization involved xhci. So the dwc3 needs to implement the xhci_plat_priv->plat_start() for xhci to re-enable the suspend bits. Since there's a prerequisite patch to drivers/usb/host/xhci-plat.h that's not a fix patch, this series should go on Greg's usb-testing branch instead of usb-linus. Changes in v2: - Fix xhci-rzv2m build issue Thinh Nguyen (2): usb: xhci-plat: Don't include xhci.h usb: dwc3: core: Prevent phy suspend during init drivers/usb/dwc3/core.c | 90 +++++++++++++++-------------------- drivers/usb/dwc3/core.h | 1 + drivers/usb/dwc3/gadget.c | 2 + drivers/usb/dwc3/host.c | 27 +++++++++++ drivers/usb/host/xhci-plat.h | 4 +- drivers/usb/host/xhci-rzv2m.c | 1 + 6 files changed, 72 insertions(+), 53 deletions(-) base-commit: 3d122e6d27e417a9fa91181922743df26b2cd679 -- 2.28.0

8 months, 3 weeks

1
2
0 0

+ mm-hugetlb-fix-missing-hugetlb_lock-for-resv-uncharge.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/hugetlb: fix missing hugetlb_lock for resv uncharge has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-hugetlb-fix-missing-hugetlb_lock-for-resv-uncharge.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Peter Xu <peterx(a)redhat.com> Subject: mm/hugetlb: fix missing hugetlb_lock for resv uncharge Date: Wed, 17 Apr 2024 17:18:35 -0400 There is a recent report on UFFDIO_COPY over hugetlb: https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/ 350: lockdep_assert_held(&hugetlb_lock); Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd() will update the cgroup pointer, so it requires to be called with the lock held. Link: https://lkml.kernel.org/r/20240417211836.2742593-3-peterx@redhat.com Fixes: 79aa925bf239 ("hugetlb_cgroup: fix reservation accounting") Signed-off-by: Peter Xu <peterx(a)redhat.com> Reported-by: syzbot+4b8077a5fccc61c385a1(a)syzkaller.appspotmail.com Cc: Mina Almasry <almasrymina(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/mm/hugetlb.c~mm-hugetlb-fix-missing-hugetlb_lock-for-resv-uncharge +++ a/mm/hugetlb.c @@ -3268,9 +3268,12 @@ struct folio *alloc_hugetlb_folio(struct rsv_adjust = hugepage_subpool_put_pages(spool, 1); hugetlb_acct_memory(h, -rsv_adjust); - if (deferred_reserve) + if (deferred_reserve) { + spin_lock_irq(&hugetlb_lock); hugetlb_cgroup_uncharge_folio_rsvd(hstate_index(h), pages_per_huge_page(h), folio); + spin_unlock_irq(&hugetlb_lock); + } } if (!memcg_charge_ret) _ Patches currently in -mm which might be from peterx(a)redhat.com are mm-hugetlb-fix-missing-hugetlb_lock-for-resv-uncharge.patch mm-hmm-process-pud-swap-entry-without-pud_huge.patch mm-gup-cache-p4d-in-follow_p4d_mask.patch mm-gup-check-p4d-presence-before-going-on.patch mm-x86-change-pxd_huge-behavior-to-exclude-swap-entries.patch mm-sparc-change-pxd_huge-behavior-to-exclude-swap-entries.patch mm-arm-use-macros-to-define-pmd-pud-helpers.patch mm-arm-redefine-pmd_huge-with-pmd_leaf.patch mm-arm64-merge-pxd_huge-and-pxd_leaf-definitions.patch mm-powerpc-redefine-pxd_huge-with-pxd_leaf.patch mm-gup-merge-pxd-huge-mapping-checks.patch mm-treewide-replace-pxd_huge-with-pxd_leaf.patch mm-treewide-remove-pxd_huge.patch mm-arm-remove-pmd_thp_or_huge.patch mm-document-pxd_leaf-api.patch mm-always-initialise-folio-_deferred_list-fix.patch selftests-mm-run_vmtestssh-fix-hugetlb-mem-size-calculation.patch selftests-mm-run_vmtestssh-fix-hugetlb-mem-size-calculation-fix.patch mm-kconfig-config_pgtable_has_huge_leaves.patch mm-hugetlb-declare-hugetlbfs_pagecache_present-non-static.patch mm-make-hpage_pxd_-macros-even-if-thp.patch mm-introduce-vma_pgtable_walk_beginend.patch mm-arch-provide-pud_pfn-fallback.patch mm-arch-provide-pud_pfn-fallback-fix.patch mm-gup-drop-folio_fast_pin_allowed-in-hugepd-processing.patch mm-gup-refactor-record_subpages-to-find-1st-small-page.patch mm-gup-handle-hugetlb-for-no_page_table.patch mm-gup-cache-pudp-in-follow_pud_mask.patch mm-gup-handle-huge-pud-for-follow_pud_mask.patch mm-gup-handle-huge-pmd-for-follow_pmd_mask.patch mm-gup-handle-huge-pmd-for-follow_pmd_mask-fix.patch mm-gup-handle-hugepd-for-follow_page.patch mm-gup-handle-hugetlb-in-the-generic-follow_page_mask-code.patch mm-allow-anon-exclusive-check-over-hugetlb-tail-pages.patch

8 months, 3 weeks

1
0
0 0

[PATCH] drm/xe/vm: prevent UAF in rebind_work_func()

by Matthew Auld

We flush the rebind worker during the vm close phase, however in places like preempt_fence_work_func() we seem to queue the rebind worker without first checking if the vm has already been closed. The concern here is the vm being closed with the worker flushed, but then being rearmed later, which looks like potential uaf, since there is no actual refcounting to track the queued worker. To ensure this can't happen prevent queueing the rebind worker once the vm has been closed. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1591 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1304 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1249 Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ --- drivers/gpu/drm/xe/xe_pt.c | 2 +- drivers/gpu/drm/xe/xe_vm.h | 17 ++++++++++++++--- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c index 5b7930f46cf3..e21461be904f 100644 --- a/drivers/gpu/drm/xe/xe_pt.c +++ b/drivers/gpu/drm/xe/xe_pt.c @@ -1327,7 +1327,7 @@ __xe_pt_bind_vma(struct xe_tile *tile, struct xe_vma *vma, struct xe_exec_queue } if (!rebind && last_munmap_rebind && xe_vm_in_preempt_fence_mode(vm)) - xe_vm_queue_rebind_worker(vm); + xe_vm_queue_rebind_worker_locked(vm); } else { kfree(rfence); kfree(ifence); diff --git a/drivers/gpu/drm/xe/xe_vm.h b/drivers/gpu/drm/xe/xe_vm.h index 306cd0934a19..8420fbf19f6d 100644 --- a/drivers/gpu/drm/xe/xe_vm.h +++ b/drivers/gpu/drm/xe/xe_vm.h @@ -211,10 +211,20 @@ int xe_vm_rebind(struct xe_vm *vm, bool rebind_worker); int xe_vm_invalidate_vma(struct xe_vma *vma); -static inline void xe_vm_queue_rebind_worker(struct xe_vm *vm) +static inline void xe_vm_queue_rebind_worker_locked(struct xe_vm *vm) { xe_assert(vm->xe, xe_vm_in_preempt_fence_mode(vm)); - queue_work(vm->xe->ordered_wq, &vm->preempt.rebind_work); + lockdep_assert_held(&vm->lock); + + if (!xe_vm_is_closed(vm)) + queue_work(vm->xe->ordered_wq, &vm->preempt.rebind_work); +} + +static inline void xe_vm_queue_rebind_worker(struct xe_vm *vm) +{ + down_read(&vm->lock); + xe_vm_queue_rebind_worker_locked(vm); + up_read(&vm->lock); } /** @@ -225,12 +235,13 @@ static inline void xe_vm_queue_rebind_worker(struct xe_vm *vm) * If the rebind functionality on a compute vm was disabled due * to nothing to execute. Reactivate it and run the rebind worker. * This function should be called after submitting a batch to a compute vm. + * */ static inline void xe_vm_reactivate_rebind(struct xe_vm *vm) { if (xe_vm_in_preempt_fence_mode(vm) && vm->preempt.rebind_deactivated) { vm->preempt.rebind_deactivated = false; - xe_vm_queue_rebind_worker(vm); + xe_vm_queue_rebind_worker_locked(vm); } } -- 2.44.0

8 months, 3 weeks

2
2
0 0

[PATCH v2] PCI: dw-rockchip: Fix GPIO initialization flag

by Niklas Cassel

PERST is active low according to the PCIe specification. However, the existing pcie-dw-rockchip.c driver does: gpiod_set_value(..., 0); msleep(100); gpiod_set_value(..., 1); When asserting + deasserting PERST. This is of course wrong, but because all the device trees for this compatible string have also incorrectly marked this GPIO as ACTIVE_HIGH: $ git grep -B 10 reset-gpios arch/arm64/boot/dts/rockchip/rk3568* $ git grep -B 10 reset-gpios arch/arm64/boot/dts/rockchip/rk3588* The actual toggling of PERST is correct. (And we cannot change it anyway, since that would break device tree compatibility.) However, this driver does request the GPIO to be initialized as GPIOD_OUT_HIGH, which does cause a silly sequence where PERST gets toggled back and forth for no good reason. Fix this by requesting the GPIO to be initialized as GPIOD_OUT_LOW (which for this driver means PERST asserted). This will avoid an unnecessary signal change where PERST gets deasserted (by devm_gpiod_get_optional()) and then gets asserted (by rockchip_pcie_start_link()) just a few instructions later. Before patch, debug prints on EP side, when booting RC: [ 845.606810] pci: PERST asserted by host! [ 852.483985] pci: PERST de-asserted by host! [ 852.503041] pci: PERST asserted by host! [ 852.610318] pci: PERST de-asserted by host! After patch, debug prints on EP side, when booting RC: [ 125.107921] pci: PERST asserted by host! [ 132.111429] pci: PERST de-asserted by host! This extra, very short, PERST assertion + deassertion has been reported to cause issues with certain WLAN controllers, e.g. RTL8822CE. Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Tested-by: Jianfeng Liu <liujianfeng1994(a)gmail.com> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Cc: stable(a)vger.kernel.org # 5.15+ --- Changes since V1: -Picked up tags. -CC stable. -Clarified commit message. drivers/pci/controller/dwc/pcie-dw-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c index d6842141d384..a909e42b4273 100644 --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c @@ -240,7 +240,7 @@ static int rockchip_pcie_resource_get(struct platform_device *pdev, return PTR_ERR(rockchip->apb_base); rockchip->rst_gpio = devm_gpiod_get_optional(&pdev->dev, "reset", - GPIOD_OUT_HIGH); + GPIOD_OUT_LOW); if (IS_ERR(rockchip->rst_gpio)) return PTR_ERR(rockchip->rst_gpio); -- 2.44.0

8 months, 3 weeks

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024