April 2024 - Linux-stable-mirror

[PATCH v2] net: usb: ax88179_178a: avoid writing the mac address before first reading

by Jose Ignacio Tornos Martinez

After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets"), reset operation, in which the default mac address from the device is read, is not executed from bind operation and the random address, that is pregenerated just in case, is direclty written the first time in the device, so the default one from the device is not even read. This writing is not dangerous because is volatile and the default mac address is not missed. In order to avoid this and keep the simplification to have only one reset and reduce the delays, restore the reset from bind operation and remove the reset that is commanded from open operation. The behavior is the same but everything is ready for usbnet_probe. Tested with ASIX AX88179 USB Gigabit Ethernet devices. Restore the old behavior for the rest of possible devices because I don't have the hardware to test. cc: stable(a)vger.kernel.org # 6.6+ Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets") Reported-by: Jarkko Palviainen <jarkko.palviainen(a)gmail.com> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> --- v2: - Restore reset from bind operation to avoid problems with usbnet_probe. v1: https://lore.kernel.org/netdev/20240410095603.502566-1-jtornosm@redhat.com/ drivers/net/usb/ax88179_178a.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c index 69169842fa2f..a493fde1af3f 100644 --- a/drivers/net/usb/ax88179_178a.c +++ b/drivers/net/usb/ax88179_178a.c @@ -1316,6 +1316,8 @@ static int ax88179_bind(struct usbnet *dev, struct usb_interface *intf) netif_set_tso_max_size(dev->net, 16384); + ax88179_reset(dev); + return 0; } @@ -1694,7 +1696,6 @@ static const struct driver_info ax88179_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, @@ -1707,7 +1708,6 @@ static const struct driver_info ax88178a_info = { .unbind = ax88179_unbind, .status = ax88179_status, .link_reset = ax88179_link_reset, - .reset = ax88179_reset, .stop = ax88179_stop, .flags = FLAG_ETHER | FLAG_FRAMING_AX, .rx_fixup = ax88179_rx_fixup, -- 2.44.0

1 year, 8 months

2
1
0 0

[PATCH net] r8169: fix LED-related deadlock on module removal

by Heiner Kallweit

Binding devm_led_classdev_register() to the netdev is problematic because on module removal we get a RTNL-related deadlock. Fix this by avoiding the device-managed LED functions. Note: We can safely call led_classdev_unregister() for a LED even if registering it failed, because led_classdev_unregister() detects this and is a no-op in this case. Fixes: 18764b883e15 ("r8169: add support for LED's on RTL8168/RTL8101") Cc: <stable(a)vger.kernel.org> # 6.8.x Reported-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Heiner Kallweit <hkallweit1(a)gmail.com> --- The original change was introduced with 6.8, 6.9 added support for LEDs on RTL8125. Therefore the first version of the fix applied on 6.9-rc only. This is the modified version for 6.8. Upstream commit: 19fa4f2a85d7 --- drivers/net/ethernet/realtek/r8169.h | 4 +++- drivers/net/ethernet/realtek/r8169_leds.c | 23 +++++++++++++++++------ drivers/net/ethernet/realtek/r8169_main.c | 7 ++++++- 3 files changed, 26 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/realtek/r8169.h b/drivers/net/ethernet/realtek/r8169.h index 81567fcf3..1ef399287 100644 --- a/drivers/net/ethernet/realtek/r8169.h +++ b/drivers/net/ethernet/realtek/r8169.h @@ -72,6 +72,7 @@ enum mac_version { }; struct rtl8169_private; +struct r8169_led_classdev; void r8169_apply_firmware(struct rtl8169_private *tp); u16 rtl8168h_2_get_adc_bias_ioffset(struct rtl8169_private *tp); @@ -83,4 +84,5 @@ void r8169_get_led_name(struct rtl8169_private *tp, int idx, char *buf, int buf_len); int rtl8168_get_led_mode(struct rtl8169_private *tp); int rtl8168_led_mod_ctrl(struct rtl8169_private *tp, u16 mask, u16 val); -void rtl8168_init_leds(struct net_device *ndev); +struct r8169_led_classdev *rtl8168_init_leds(struct net_device *ndev); +void r8169_remove_leds(struct r8169_led_classdev *leds); diff --git a/drivers/net/ethernet/realtek/r8169_leds.c b/drivers/net/ethernet/realtek/r8169_leds.c index 007d077ed..1c97f3cca 100644 --- a/drivers/net/ethernet/realtek/r8169_leds.c +++ b/drivers/net/ethernet/realtek/r8169_leds.c @@ -138,20 +138,31 @@ static void rtl8168_setup_ldev(struct r8169_led_classdev *ldev, led_cdev->hw_control_get_device = r8169_led_hw_control_get_device; /* ignore errors */ - devm_led_classdev_register(&ndev->dev, led_cdev); + led_classdev_register(&ndev->dev, led_cdev); } -void rtl8168_init_leds(struct net_device *ndev) +struct r8169_led_classdev *rtl8168_init_leds(struct net_device *ndev) { - /* bind resource mgmt to netdev */ - struct device *dev = &ndev->dev; struct r8169_led_classdev *leds; int i; - leds = devm_kcalloc(dev, RTL8168_NUM_LEDS, sizeof(*leds), GFP_KERNEL); + leds = kcalloc(RTL8168_NUM_LEDS + 1, sizeof(*leds), GFP_KERNEL); if (!leds) - return; + return NULL; for (i = 0; i < RTL8168_NUM_LEDS; i++) rtl8168_setup_ldev(leds + i, ndev, i); + + return leds; +} + +void r8169_remove_leds(struct r8169_led_classdev *leds) +{ + if (!leds) + return; + + for (struct r8169_led_classdev *l = leds; l->ndev; l++) + led_classdev_unregister(&l->led); + + kfree(leds); } diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c index 4b6c28576..32b73f398 100644 --- a/drivers/net/ethernet/realtek/r8169_main.c +++ b/drivers/net/ethernet/realtek/r8169_main.c @@ -634,6 +634,8 @@ struct rtl8169_private { const char *fw_name; struct rtl_fw *rtl_fw; + struct r8169_led_classdev *leds; + u32 ocp_base; }; @@ -4930,6 +4932,9 @@ static void rtl_remove_one(struct pci_dev *pdev) cancel_work_sync(&tp->wk.work); + if (IS_ENABLED(CONFIG_R8169_LEDS)) + r8169_remove_leds(tp->leds); + unregister_netdev(tp->dev); if (tp->dash_type != RTL_DASH_NONE) @@ -5391,7 +5396,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) if (IS_ENABLED(CONFIG_R8169_LEDS) && tp->mac_version > RTL_GIGA_MAC_VER_06 && tp->mac_version < RTL_GIGA_MAC_VER_61) - rtl8168_init_leds(dev); + tp->leds = rtl8168_init_leds(dev); netdev_info(dev, "%s, %pM, XID %03x, IRQ %d\n", rtl_chip_infos[chipset].name, dev->dev_addr, xid, tp->irq); -- 2.44.0

1 year, 8 months

4
10
0 0

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

by ArcticLampyrid

spkid index is corrected in v3 Link to v3: https://lore.kernel.org/lkml/TYCP286MB25357A4599E935F26A8AAB24C40E2@TYCP286…

1 year, 8 months

1
0
0 0

Re: [PATCH] drm/ttm: Print the memory decryption status just once

by Zack Rusin

Sorry, apologies to everyone. By accident I replied off the list. Redoing it now on the list. More below. On Mon, Apr 8, 2024 at 12:10 PM Christian König <christian.koenig(a)amd.com> wrote: > > Am 08.04.24 um 18:04 schrieb Zack Rusin: > > On Mon, Apr 8, 2024 at 11:59 AM Christian König > > <christian.koenig(a)amd.com> wrote: > >> Am 08.04.24 um 17:56 schrieb Zack Rusin: > >>> Stop printing the TT memory decryption status info each time tt is created > >>> and instead print it just once. > >>> > >>> Reduces the spam in the system logs when running guests with SEV enabled. > >> Do we then really need this in the first place? > > Thomas asked for it just to have an indication when those paths are > > being used because they could potentially break things pretty bad. I > > think it is useful knowing that those paths are hit (but only once). > > It makes it pretty easy for me to tell whether bug reports with people > > who report black screen can be answered with "the kernel needs to be > > upgraded" ;) > > Sounds reasonable, but my expectation was rather that we would print > something on the device level. > > If that's not feasible for whatever reason than printing it once works > as well of course. TBH, I think it's pretty convenient to have the drm_info in the TT just to make sure that when drivers request use_dma_alloc on SEV systems TT turns decryption on correctly, i.e. it's a nice sanity check when reading the logs. But if you'd prefer it in the driver I can move this logic there as well. z

1 year, 8 months

2
2
0 0

[PATCH v2 2/2] 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 | 2 ++ sound/pci/hda/patch_realtek.c | 1 + 2 files changed, 3 insertions(+) diff --git a/sound/pci/hda/cs35l41_hda_property.c b/sound/pci/hda/cs35l41_hda_property.c index 8fb688e41414..60ad2344488b 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 }, @@ -500,6 +501,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", generic_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 cdcb28aa9d7b..ac729187f6a7 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

1 year, 8 months

2
1
0 0

[PATCH] binder: check offset alignment in binder_get_object()

by Carlos Llamas

Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying txn") introduced changes to how binder objects are copied. In doing so, it unintentionally removed an offset alignment check done through calls to binder_alloc_copy_from_buffer() -> check_buffer(). These calls were replaced in binder_get_object() with copy_from_user(), so now an explicit offset alignment check is needed here. This avoids later complications when unwinding the objects gets harder. It is worth noting this check existed prior to commit 7a67a39320df ("binder: add function to copy binder object from buffer"), likely removed due to redundancy at the time. Fixes: 6d98eb95b450 ("binder: avoid potential data leakage when copying txn") Cc: stable(a)vger.kernel.org Signed-off-by: Carlos Llamas <cmllamas(a)google.com> --- drivers/android/binder.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index bad28cf42010..dd6923d37931 100644 --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -1708,8 +1708,10 @@ static size_t binder_get_object(struct binder_proc *proc, size_t object_size = 0; read_size = min_t(size_t, sizeof(*object), buffer->data_size - offset); - if (offset > buffer->data_size || read_size < sizeof(*hdr)) + if (offset > buffer->data_size || read_size < sizeof(*hdr) || + !IS_ALIGNED(offset, sizeof(u32))) return 0; + if (u) { if (copy_from_user(object, u + offset, read_size)) return 0; -- 2.44.0.478.gd926399ef9-goog

1 year, 8 months

3
2
0 0

Re: Patch "mailbox: imx: fix suspend failue" has been added to the 5.10-stable tree

by Dominique Martinet

Hi Greg, gregkh(a)linuxfoundation.org wrote on Mon, Apr 15, 2024 at 01:18:20PM +0200: > mailbox: imx: fix suspend failue > > to the 5.10-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > mailbox-imx-fix-suspend-failue.patch > and it can be found in the queue-5.10 subdirectory. This only fixes typos in the commit message, but Mizobuchi sent a v2 here: https://lore.kernel.org/all/20240412055648.1807780-1-mizo@atmark-techno.com… (unfortunately you weren't in cc of the patch mail either, sorry... He can resend if that helps with the process) Peng Fan also gave his reviewed-by in the v2 thread, it's always appreciable to get an ack from someone closer to the authors. Since the code itself is identical, I'll leave the decision to update or not up to you; I just can't unsee the "failue" in the summary :) Thanks! -- Dominique

1 year, 8 months

2
1
0 0

FAILED: patch "[PATCH] io_uring: Fix io_cqring_wait() not restoring sigmask on" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 978e5c19dfefc271e5550efba92fcef0d3f62864 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024041502-handsaw-overpass-5b8a@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 978e5c19dfefc271e5550efba92fcef0d3f62864 Mon Sep 17 00:00:00 2001 From: Alexey Izbyshev <izbyshev(a)ispras.ru> Date: Fri, 5 Apr 2024 15:55:51 +0300 Subject: [PATCH] io_uring: Fix io_cqring_wait() not restoring sigmask on get_timespec64() failure This bug was introduced in commit 950e79dd7313 ("io_uring: minor io_cqring_wait() optimization"), which was made in preparation for adc8682ec690 ("io_uring: Add support for napi_busy_poll"). The latter got reverted in cb3182167325 ("Revert "io_uring: Add support for napi_busy_poll""), so simply undo the former as well. Cc: stable(a)vger.kernel.org Fixes: 950e79dd7313 ("io_uring: minor io_cqring_wait() optimization") Signed-off-by: Alexey Izbyshev <izbyshev(a)ispras.ru> Link: https://lore.kernel.org/r/20240405125551.237142-1-izbyshev@ispras.ru Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c index 4521c2b66b98..c170a2b8d2cf 100644 --- a/io_uring/io_uring.c +++ b/io_uring/io_uring.c @@ -2602,19 +2602,6 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, int min_events, if (__io_cqring_events_user(ctx) >= min_events) return 0; - if (sig) { -#ifdef CONFIG_COMPAT - if (in_compat_syscall()) - ret = set_compat_user_sigmask((const compat_sigset_t __user *)sig, - sigsz); - else -#endif - ret = set_user_sigmask(sig, sigsz); - - if (ret) - return ret; - } - init_waitqueue_func_entry(&iowq.wq, io_wake_function); iowq.wq.private = current; INIT_LIST_HEAD(&iowq.wq.entry); @@ -2633,6 +2620,19 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, int min_events, io_napi_adjust_timeout(ctx, &iowq, &ts); } + if (sig) { +#ifdef CONFIG_COMPAT + if (in_compat_syscall()) + ret = set_compat_user_sigmask((const compat_sigset_t __user *)sig, + sigsz); + else +#endif + ret = set_user_sigmask(sig, sigsz); + + if (ret) + return ret; + } + io_napi_busy_loop(ctx, &iowq); trace_io_uring_cqring_wait(ctx, min_events);

1 year, 8 months

3
2
0 0

v5.15+ backport request

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

1 year, 8 months

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

1 year, 8 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024