May 2024 - Linux-stable-mirror

[PATCH 1/2] arm64: dts: qcom: sc7180: Disable SS instances in park mode

by Krishna Kurapati

On SC7180, in host mode, it is observed that stressing out controller in host mode results in HC died error and only restarting the host mode fixes it. Disable SS instances in park mode for these targets to avoid host controller being dead. Reported-by: Doug Anderson <dianders(a)google.com> Cc: <stable(a)vger.kernel.org> Fixes: 0b766e7fe5a2 ("arm64: dts: qcom: sc7180: Add USB related nodes") Signed-off-by: Krishna Kurapati <quic_kriskura(a)quicinc.com> --- arch/arm64/boot/dts/qcom/sc7180.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi index 2b481e20ae38..cc93b5675d5d 100644 --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi @@ -3063,6 +3063,7 @@ usb_1_dwc3: usb@a600000 { iommus = <&apps_smmu 0x540 0>; snps,dis_u2_susphy_quirk; snps,dis_enblslpm_quirk; + snps,parkmode-disable-ss-quirk; phys = <&usb_1_hsphy>, <&usb_1_qmpphy QMP_USB43DP_USB3_PHY>; phy-names = "usb2-phy", "usb3-phy"; maximum-speed = "super-speed"; -- 2.34.1

11 months

4
3
0 0

[PATCH v4 2/7] PCI: xilinx-nwl: Fix off-by-one in IRQ handler

by Sean Anderson

MSGF_LEG_MASK is laid out with INTA in bit 0, INTB in bit 1, INTC in bit 2, and INTD in bit 3. Hardware IRQ numbers start at 0, and we register PCI_NUM_INTX irqs. So to enable INTA (aka hwirq 0) we should set bit 0. Remove the subtraction of one. This bug would cause legacy interrupts not to be delivered, as enabling INTB would actually enable INTA, and enabling INTA wouldn't enable anything at all. It is likely that this got overlooked for so long since most PCIe hardware uses MSIs. This fixes the following UBSAN error: UBSAN: shift-out-of-bounds in ../drivers/pci/controller/pcie-xilinx-nwl.c:389:11 shift exponent 18446744073709551615 is too large for 32-bit type 'int' CPU: 1 PID: 61 Comm: kworker/u10:1 Not tainted 6.6.20+ #268 Hardware name: xlnx,zynqmp (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace (arch/arm64/kernel/stacktrace.c:235) show_stack (arch/arm64/kernel/stacktrace.c:242) dump_stack_lvl (lib/dump_stack.c:107) dump_stack (lib/dump_stack.c:114) __ubsan_handle_shift_out_of_bounds (lib/ubsan.c:218 lib/ubsan.c:387) nwl_unmask_leg_irq (drivers/pci/controller/pcie-xilinx-nwl.c:389 (discriminator 1)) irq_enable (kernel/irq/internals.h:234 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) __irq_startup (kernel/irq/internals.h:239 kernel/irq/chip.c:180 kernel/irq/chip.c:250) irq_startup (kernel/irq/chip.c:270) __setup_irq (kernel/irq/manage.c:1800) request_threaded_irq (kernel/irq/manage.c:2206) pcie_pme_probe (include/linux/interrupt.h:168 drivers/pci/pcie/pme.c:348) <snip> Fixes: 9a181e1093af ("PCI: xilinx-nwl: Modify IRQ chip for legacy interrupts") Cc: <stable(a)vger.kernel.org> Signed-off-by: Sean Anderson <sean.anderson(a)linux.dev> --- Changes in v4: - Explain likely effects of the off-by-one error - Trim down UBSAN backtrace Changes in v3: - Expand commit message drivers/pci/controller/pcie-xilinx-nwl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c b/drivers/pci/controller/pcie-xilinx-nwl.c index 0408f4d612b5..437927e3bcca 100644 --- a/drivers/pci/controller/pcie-xilinx-nwl.c +++ b/drivers/pci/controller/pcie-xilinx-nwl.c @@ -371,7 +371,7 @@ static void nwl_mask_intx_irq(struct irq_data *data) u32 mask; u32 val; - mask = 1 << (data->hwirq - 1); + mask = 1 << data->hwirq; raw_spin_lock_irqsave(&pcie->leg_mask_lock, flags); val = nwl_bridge_readl(pcie, MSGF_LEG_MASK); nwl_bridge_writel(pcie, (val & (~mask)), MSGF_LEG_MASK); @@ -385,7 +385,7 @@ static void nwl_unmask_intx_irq(struct irq_data *data) u32 mask; u32 val; - mask = 1 << (data->hwirq - 1); + mask = 1 << data->hwirq; raw_spin_lock_irqsave(&pcie->leg_mask_lock, flags); val = nwl_bridge_readl(pcie, MSGF_LEG_MASK); nwl_bridge_writel(pcie, (val | mask), MSGF_LEG_MASK); -- 2.35.1.1320.gc452695387.dirty

11 months

1
0
0 0

[PATCH v3] serial: port: Don't block system suspend even if bytes are left to xmit

by Douglas Anderson

Recently, suspend testing on sc7180-trogdor based devices has started to sometimes fail with messages like this: port a88000.serial:0.0: PM: calling pm_runtime_force_suspend+0x0/0xf8 @ 28934, parent: a88000.serial:0 port a88000.serial:0.0: PM: dpm_run_callback(): pm_runtime_force_suspend+0x0/0xf8 returns -16 port a88000.serial:0.0: PM: pm_runtime_force_suspend+0x0/0xf8 returned -16 after 33 usecs port a88000.serial:0.0: PM: failed to suspend: error -16 I could reproduce these problems by logging in via an agetty on the debug serial port (which was _not_ used for kernel console) and running: cat /var/log/messages ...and then (via an SSH session) forcing a few suspend/resume cycles. Tracing through the code and doing some printf()-based debugging shows that the -16 (-EBUSY) comes from the recently added serial_port_runtime_suspend(). The idea of the serial_port_runtime_suspend() function is to prevent the port from being _runtime_ suspended if it still has bytes left to transmit. Having bytes left to transmit isn't a reason to block _system_ suspend, though. If a serdev device in the kernel needs to block system suspend it should block its own suspend and it can use serdev_device_wait_until_sent() to ensure bytes are sent. The DEFINE_RUNTIME_DEV_PM_OPS() used by the serial_port code means that the system suspend function will be pm_runtime_force_suspend(). In pm_runtime_force_suspend() we can see that before calling the runtime suspend function we'll call pm_runtime_disable(). This should be a reliable way to detect that we're called from system suspend and that we shouldn't look for busyness. Fixes: 43066e32227e ("serial: port: Don't suspend if the port is still busy") Cc: stable(a)vger.kernel.org Reviewed-by: Tony Lindgren <tony.lindgren(a)linux.intel.com> Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- In v1 [1] this was part of a 2-patch series. I'm now just sending this patch on its own since the Qualcomm GENI serial driver has ended up having a whole pile of problems that are taking a while to unravel. It makes sense to disconnect the two efforts. The core problem fixed by this patch and the geni problems never had any dependencies anyway. [1] https://lore.kernel.org/r/20240523162207.1.I2395e66cf70c6e67d774c56943825c2… Changes in v3: - Adjust comment as per Tony Lindgren. - Add Cc: stable. Changes in v2: - Fix "regulator" => "regular" in comment. - Fix "PM Runtime" => "runtime PM" in comment. - Commit messages says how serdev devices should ensure bytes xfered. drivers/tty/serial/serial_port.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/tty/serial/serial_port.c b/drivers/tty/serial/serial_port.c index 91a338d3cb34..d35f1d24156c 100644 --- a/drivers/tty/serial/serial_port.c +++ b/drivers/tty/serial/serial_port.c @@ -64,6 +64,13 @@ static int serial_port_runtime_suspend(struct device *dev) if (port->flags & UPF_DEAD) return 0; + /* + * Nothing to do on pm_runtime_force_suspend(), see + * DEFINE_RUNTIME_DEV_PM_OPS. + */ + if (!pm_runtime_enabled(dev)) + return 0; + uart_port_lock_irqsave(port, &flags); if (!port_dev->tx_enabled) { uart_port_unlock_irqrestore(port, flags); -- 2.45.1.288.g0e0cd299f1-goog

11 months

2
1
0 0

[PATCH 1/1] leds: ss4200: Convert PCIBIOS_* return codes to errnos

by Ilpo Järvinen

ich7_lpc_probe() uses pci_read_config_dword() that returns PCIBIOS_* codes. The error handling code assumes incorrectly it's a normal errno and checks for < 0. The return code is returned from the probe function as is but probe functions should return normal errnos. Remove < 0 from the check and convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it. Fixes: a328e95b82c1 ("leds: LED driver for Intel NAS SS4200 series (v5)") Cc: stable(a)vger.kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> --- drivers/leds/leds-ss4200.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/leds/leds-ss4200.c b/drivers/leds/leds-ss4200.c index fcaa34706b6c..2ef9fc7371bd 100644 --- a/drivers/leds/leds-ss4200.c +++ b/drivers/leds/leds-ss4200.c @@ -356,8 +356,10 @@ static int ich7_lpc_probe(struct pci_dev *dev, nas_gpio_pci_dev = dev; status = pci_read_config_dword(dev, PMBASE, &g_pm_io_base); - if (status) + if (status) { + status = pcibios_err_to_errno(status); goto out; + } g_pm_io_base &= 0x00000ff80; status = pci_read_config_dword(dev, GPIO_CTRL, &gc); @@ -369,8 +371,9 @@ static int ich7_lpc_probe(struct pci_dev *dev, } status = pci_read_config_dword(dev, GPIO_BASE, &nas_gpio_io_base); - if (0 > status) { + if (status) { dev_info(&dev->dev, "Unable to read GPIOBASE.\n"); + status = pcibios_err_to_errno(status); goto out; } dev_dbg(&dev->dev, ": GPIOBASE = 0x%08x\n", nas_gpio_io_base); -- 2.39.2

11 months

2
1
0 0

[PATCH v2 5.10.y 0/2] bpf: fix warning in ftrace_verify_code()

by kovalev＠altlinux.org

This bug was found by syzkaller. The reproducer and the detailed warning log can be viewed here [1] [1] https://lore.kernel.org/bpf/20240129091746.260538-1-kovalev@altlinux.org/#t Capability cap_sys_admin is required for reproduce and on kernels with panic_on_warn enabled it will cause the system to crash. v2: Added an additional patch that fixes a build error by the clang compiler. To solve the problem, it is proposed to backport the following commits: [PATCH v2 5.10.y 1/2] bpf: Convert BPF_DISPATCHER to use static_call() (not [PATCH v2 5.10.y 2/2] bpf: Add explicit cast to 'void *' for

11 months

1
2
0 0

[PATCH v2 5.15.y 0/2] bpf: fix warning in ftrace_verify_code()

by kovalev＠altlinux.org

This bug was found by syzkaller. The reproducer and the detailed warning log can be viewed here [1] [1] https://lore.kernel.org/bpf/20240129091746.260538-1-kovalev@altlinux.org/#t Capability cap_sys_admin is required for reproduce and on kernels with panic_on_warn enabled it will cause the system to crash. v2: Added an additional patch that fixes a build error by the clang compiler. To solve the problem, it is proposed to backport the following commits: [PATCH v2 5.15.y 1/2] bpf: Convert BPF_DISPATCHER to use static_call() (not [PATCH v2 5.15.y 2/2] bpf: Add explicit cast to 'void *' for

11 months

1
2
0 0

[PATCH] ata: libata-core: Add ATA_HORKAGE_NOLPM for Apacer AS340

by Niklas Cassel

Commit 7627a0edef54 ("ata: ahci: Drop low power policy board type") dropped the board_ahci_low_power board type, and instead enables LPM if: -The AHCI controller reports that it supports LPM (Partial/Slumber), and -CONFIG_SATA_MOBILE_LPM_POLICY != 0, and -The port is not defined as external in the per port PxCMD register, and -The port is not defined as hotplug capable in the per port PxCMD register. Partial and Slumber LPM states can either be initiated by HIPM or DIPM. For HIPM (host initiated power management) to get enabled, both the AHCI controller and the drive have to report that they support HIPM. For DIPM (device initiated power management) to get enabled, only the drive has to report that it supports DIPM. However, the HBA will reject device requests to enter LPM states which the HBA does not support. The problem is that Apacer AS340 drives do not handle low power modes correctly. The problem was most likely not seen before because no one had used this drive with a AHCI controller with LPM enabled. Add a quirk so that we do not enable LPM for this drive, since we see command timeouts if we do (even though the drive claims to support DIPM). Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") Cc: stable(a)vger.kernel.org Reported-by: Tim Teichmann <teichmanntim(a)outlook.de> Closes: https://lore.kernel.org/linux-ide/87bk4pbve8.ffs@tglx/ Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- On the system reporting this issue, the HBA supports SALP (HIPM) and LPM states Partial and Slumber. This drive only supports DIPM but not HIPM, however, that should not matter, as a DIPM request from the device still has to be acked by the HBA, and according to AHCI 1.3.1, section 5.3.2.11 P:Idle, if the link layer has negotiated to low power state based on device power management request, the HBA will jump to state PM:LowPower. In PM:LowPower, the HBA will automatically request to wake the link (exit from Partial/Slumber) when a new command is queued (by writing to PxCI). Thus, there should be no need for host software to request an explicit wakeup (by writing PxCMD.ICC to 1). Therefore, even with only DIPM supported/enabled, we shouldn't see command timeouts with the current code. Also, only enabling only DIPM (by modifying the AHCI driver) with another drive (which support both DIPM and HIPM), shows no errors. Thus, it seems like the drive is the problem. drivers/ata/libata-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 4f35aab81a0a..25b400f1c3de 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4155,6 +4155,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { ATA_HORKAGE_ZERO_AFTER_TRIM | ATA_HORKAGE_NOLPM }, + /* Apacer models with LPM issues */ + { "Apacer AS340*", NULL, ATA_HORKAGE_NOLPM }, + /* These specific Samsung models/firmware-revs do not handle LPM well */ { "SAMSUNG MZMPC128HBFU-000MV", "CXM14M1Q", ATA_HORKAGE_NOLPM }, { "SAMSUNG SSD PM830 mSATA *", "CXM13D1Q", ATA_HORKAGE_NOLPM }, -- 2.45.1

11 months

3
5
0 0

[PATCH] ata: libata-core: Add ATA_HORKAGE_NOLPM for AMD Radeon S3 SSD

by Niklas Cassel

Commit 7627a0edef54 ("ata: ahci: Drop low power policy board type") dropped the board_ahci_low_power board type, and instead enables LPM if: -The AHCI controller reports that it supports LPM (Partial/Slumber), and -CONFIG_SATA_MOBILE_LPM_POLICY != 0, and -The port is not defined as external in the per port PxCMD register, and -The port is not defined as hotplug capable in the per port PxCMD register. Partial and Slumber LPM states can either be initiated by HIPM or DIPM. For HIPM (host initiated power management) to get enabled, both the AHCI controller and the drive have to report that they support HIPM. For DIPM (device initiated power management) to get enabled, only the drive has to report that it supports DIPM. However, the HBA will reject device requests to enter LPM states which the HBA does not support. The problem is that AMD Radeon S3 SSD drives do not handle low power modes correctly. The problem was most likely not seen before because no one had used this drive with a AHCI controller with LPM enabled. Add a quirk so that we do not enable LPM for this drive, since we see command timeouts if we do (even though the drive claims to support DIPM). Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") Cc: stable(a)vger.kernel.org Reported-by: Doru Iorgulescu <doru.iorgulescu1(a)gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218832 Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- drivers/ata/libata-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 4f35aab81a0a..6c4b69d34aa1 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4155,6 +4155,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { ATA_HORKAGE_ZERO_AFTER_TRIM | ATA_HORKAGE_NOLPM }, + /* AMD Radeon devices with broken LPM support */ + { "R3SL240G", NULL, ATA_HORKAGE_NOLPM }, + /* These specific Samsung models/firmware-revs do not handle LPM well */ { "SAMSUNG MZMPC128HBFU-000MV", "CXM14M1Q", ATA_HORKAGE_NOLPM }, { "SAMSUNG SSD PM830 mSATA *", "CXM13D1Q", ATA_HORKAGE_NOLPM }, -- 2.45.1

11 months

3
3
0 0

[PATCH] ata: libata-core: Add ATA_HORKAGE_NOLPM for Crucial CT240BX500SSD1

by Niklas Cassel

Commit 7627a0edef54 ("ata: ahci: Drop low power policy board type") dropped the board_ahci_low_power board type, and instead enables LPM if: -The AHCI controller reports that it supports LPM (Partial/Slumber), and -CONFIG_SATA_MOBILE_LPM_POLICY != 0, and -The port is not defined as external in the per port PxCMD register, and -The port is not defined as hotplug capable in the per port PxCMD register. Partial and Slumber LPM states can either be initiated by HIPM or DIPM. For HIPM (host initiated power management) to get enabled, both the AHCI controller and the drive have to report that they support HIPM. For DIPM (device initiated power management) to get enabled, only the drive has to report that it supports DIPM. However, the HBA will reject device requests to enter LPM states which the HBA does not support. The problem is that Crucial CT240BX500SSD1 drives do not handle low power modes correctly. The problem was most likely not seen before because no one had used this drive with a AHCI controller with LPM enabled. Add a quirk so that we do not enable LPM for this drive, since we see command timeouts if we do (even though the drive claims to support DIPM). Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") Cc: stable(a)vger.kernel.org Reported-by: Aarrayy <lp610mh(a)gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218832 Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- On the system reporting this issue, the HBA supports SALP (HIPM) and LPM states Partial and Slumber. This drive only supports DIPM but not HIPM, however, that should not matter, as a DIPM request from the device still has to be acked by the HBA, and according to AHCI 1.3.1, section 5.3.2.11 P:Idle, if the link layer has negotiated to low power state based on device power management request, the HBA will jump to state PM:LowPower. In PM:LowPower, the HBA will automatically request to wake the link (exit from Partial/Slumber) when a new command is queued (by writing to PxCI). Thus, there should be no need for host software to request an explicit wakeup (by writing PxCMD.ICC to 1). Therefore, even with only DIPM supported/enabled, we shouldn't see command timeouts with the current code. Also, only enabling only DIPM (by modifying the AHCI driver) with another drive (which support both DIPM and HIPM), shows no errors. Thus, it seems like the drive is the problem. drivers/ata/libata-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 4f35aab81a0a..b0ce621fe2a1 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4136,8 +4136,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { { "PIONEER BD-RW BDR-207M", NULL, ATA_HORKAGE_NOLPM }, { "PIONEER BD-RW BDR-205", NULL, ATA_HORKAGE_NOLPM }, - /* Crucial BX100 SSD 500GB has broken LPM support */ + /* Crucial devices with broken LPM support */ { "CT500BX100SSD1", NULL, ATA_HORKAGE_NOLPM }, + { "CT240BX500SSD1", NULL, ATA_HORKAGE_NOLPM }, /* 512GB MX100 with MU01 firmware has both queued TRIM and LPM issues */ { "Crucial_CT512MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM | -- 2.45.1

11 months

3
3
0 0

[PATCH 2/2] PCI: of_property: Fix NULL pointer defererence in of_pci_prop_intr_map()

by Nam Cao

The subordinate pointer can be null if we are out of bus number. The function of_pci_prop_intr_map() deferences this pointer without checking and may crashes the kernel. This crash can be reproduced by starting a QEMU instance: qemu-system-riscv64 -machine virt \ -kernel ../build-pci-riscv/arch/riscv/boot/Image \ -append "console=ttyS0 root=/dev/vda" \ -nographic \ -drive "file=root.img,format=raw,id=hd0" \ -device virtio-blk-device,drive=hd0 \ -device pcie-root-port,bus=pcie.0,slot=1,id=rp1,bus-reserve=0 \ -device pcie-pci-bridge,id=br1,bus=rp1 Then hot-add a bridge with device_add pci-bridge,id=br2,bus=br1,chassis_nr=1,addr=1 Then the kernel crashes: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 [snip] [<ffffffff804dac82>] of_pci_prop_intr_map+0x104/0x362 [<ffffffff804db262>] of_pci_add_properties+0x382/0x3ca [<ffffffff804c8228>] of_pci_make_dev_node+0xb6/0x116 [<ffffffff804a6b72>] pci_bus_add_device+0xa8/0xaa [<ffffffff804a6ba4>] pci_bus_add_devices+0x30/0x6a [<ffffffff804d3b5c>] shpchp_configure_device+0xa0/0x112 [<ffffffff804d2b3a>] board_added+0xce/0x354 [<ffffffff804d2e9a>] shpchp_enable_slot+0xda/0x30c [<ffffffff804d336c>] shpchp_pushbutton_thread+0x84/0xa0 NULL check this pointer first before proceeding. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Cc: stable(a)vger.kernel.org --- drivers/pci/of_property.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/of_property.c b/drivers/pci/of_property.c index 5fb516807ba2..c405978a0b7e 100644 --- a/drivers/pci/of_property.c +++ b/drivers/pci/of_property.c @@ -199,6 +199,9 @@ static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs, int ret; u8 pin; + if (!pdev->subordinate) + return 0; + pnode = pci_device_to_OF_node(pdev->bus->self); if (!pnode) pnode = pci_bus_to_OF_node(pdev->bus); -- 2.39.2

11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024