- Linux-stable-mirror - lists.linaro.org

Re: [PATCH v2] net: usb: sr9700: fix incorrect command used to write single register

by Andrew Lunn

On Sun, Dec 21, 2025 at 03:42:58PM -0800, Ethan Nelson-Moore wrote: > Hi, Andrew, > > The other two are correct because they intend to write multiple registers - > they are used with a length parameter. Please don't top post. How finished do you think this driver is? Are there likely to be more instances of SR_WR_REG/SR_WR_REGS added in the future? If so, it might make sense to change the code to make this sort of error less likely. SR_WR_MULTIPLE_REG and SR_WR_ONE_REG? Andrew

13 hours, 55 minutes

1
0
0 0

[PATCH v2 6/6] Revert "PCI: dwc: Don't wait for link up if driver can detect Link Up event"

by Niklas Cassel

This reverts commit 8d3bf19f1b585a3cc0027f508b64c33484db8d0d. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number after initial scan during boot. The long term plan is to migrate this driver to the pwrctrl framework, once it adds proper support for powering up and enumerating PCIe switches. Cc: stable(a)vger.kernel.org Suggested-by: Manivannan Sadhasivam <mani(a)kernel.org> Acked-by: Shawn Lin <shawn.lin(a)rock-chips.com> Tested-by: Shawn Lin <shawn.lin(a)rock-chips.com> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- drivers/pci/controller/dwc/pcie-designware-host.c | 10 ++-------- drivers/pci/controller/dwc/pcie-designware.h | 1 - 2 files changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c index 8c41b90a1db1..06c02fcc76c8 100644 --- a/drivers/pci/controller/dwc/pcie-designware-host.c +++ b/drivers/pci/controller/dwc/pcie-designware-host.c @@ -665,14 +665,8 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp) goto err_remove_edma; } - /* - * Note: Skip the link up delay only when a Link Up IRQ is present. - * If there is no Link Up IRQ, we should not bypass the delay - * because that would require users to manually rescan for devices. - */ - if (!pp->use_linkup_irq) - /* Ignore errors, the link may come up later */ - dw_pcie_wait_for_link(pci); + /* Ignore errors, the link may come up later */ + dw_pcie_wait_for_link(pci); ret = pci_host_probe(bridge); if (ret) diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h index fc9cf8ce8629..a3a3f6e89a81 100644 --- a/drivers/pci/controller/dwc/pcie-designware.h +++ b/drivers/pci/controller/dwc/pcie-designware.h @@ -438,7 +438,6 @@ struct dw_pcie_rp { bool use_atu_msg; int msg_atu_index; struct resource *msg_res; - bool use_linkup_irq; struct pci_eq_presets presets; struct pci_config_window *cfg; bool ecam_enabled; -- 2.52.0

16 hours, 20 minutes

1
0
0 0

[PATCH v2 3/6] Revert "PCI: qcom: Don't wait for link if we can detect Link Up"

by Niklas Cassel

This reverts commit 36971d6c5a9a134c15760ae9fd13c6d5f9a36abb. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number after initial scan during boot. The long term plan is to migrate this driver to the pwrctrl framework, once it adds proper support for powering up and enumerating PCIe switches. Cc: stable(a)vger.kernel.org Suggested-by: Manivannan Sadhasivam <mani(a)kernel.org> Acked-by: Shawn Lin <shawn.lin(a)rock-chips.com> Tested-by: Shawn Lin <shawn.lin(a)rock-chips.com> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- drivers/pci/controller/dwc/pcie-qcom.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index 60373fe1362f..e87ec6779d44 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -1958,10 +1958,6 @@ static int qcom_pcie_probe(struct platform_device *pdev) platform_set_drvdata(pdev, pcie); - irq = platform_get_irq_byname_optional(pdev, "global"); - if (irq > 0) - pp->use_linkup_irq = true; - ret = dw_pcie_host_init(pp); if (ret) { dev_err(dev, "cannot initialize host\n"); @@ -1975,6 +1971,7 @@ static int qcom_pcie_probe(struct platform_device *pdev) goto err_host_deinit; } + irq = platform_get_irq_byname_optional(pdev, "global"); if (irq > 0) { ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, qcom_pcie_global_irq_thread, -- 2.52.0

16 hours, 20 minutes

1
0
0 0

[PATCH v2 2/6] Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ"

by Niklas Cassel

This reverts commit 0e0b45ab5d770a748487ba0ae8f77d1fb0f0de3e. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number after initial scan during boot. The long term plan is to migrate this driver to the pwrctrl framework, once it adds proper support for powering up and enumerating PCIe switches. Cc: stable(a)vger.kernel.org Suggested-by: Manivannan Sadhasivam <mani(a)kernel.org> Acked-by: Shawn Lin <shawn.lin(a)rock-chips.com> Tested-by: Shawn Lin <shawn.lin(a)rock-chips.com> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- drivers/pci/controller/dwc/pcie-dw-rockchip.c | 59 +------------------ 1 file changed, 3 insertions(+), 56 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c index ca808d8f7975..352f513ebf03 100644 --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c @@ -508,34 +508,6 @@ static const struct dw_pcie_ops dw_pcie_ops = { .get_ltssm = rockchip_pcie_get_ltssm, }; -static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg) -{ - struct rockchip_pcie *rockchip = arg; - struct dw_pcie *pci = &rockchip->pci; - struct dw_pcie_rp *pp = &pci->pp; - struct device *dev = pci->dev; - u32 reg; - - reg = rockchip_pcie_readl_apb(rockchip, PCIE_CLIENT_INTR_STATUS_MISC); - rockchip_pcie_writel_apb(rockchip, reg, PCIE_CLIENT_INTR_STATUS_MISC); - - dev_dbg(dev, "PCIE_CLIENT_INTR_STATUS_MISC: %#x\n", reg); - dev_dbg(dev, "LTSSM_STATUS: %#x\n", rockchip_pcie_get_ltssm_reg(rockchip)); - - if (reg & PCIE_RDLH_LINK_UP_CHGED) { - if (rockchip_pcie_link_up(pci)) { - msleep(PCIE_RESET_CONFIG_WAIT_MS); - dev_dbg(dev, "Received Link up event. Starting enumeration!\n"); - /* Rescan the bus to enumerate endpoint devices */ - pci_lock_rescan_remove(); - pci_rescan_bus(pp->bridge->bus); - pci_unlock_rescan_remove(); - } - } - - return IRQ_HANDLED; -} - static irqreturn_t rockchip_pcie_ep_sys_irq_thread(int irq, void *arg) { struct rockchip_pcie *rockchip = arg; @@ -568,29 +540,14 @@ static irqreturn_t rockchip_pcie_ep_sys_irq_thread(int irq, void *arg) return IRQ_HANDLED; } -static int rockchip_pcie_configure_rc(struct platform_device *pdev, - struct rockchip_pcie *rockchip) +static int rockchip_pcie_configure_rc(struct rockchip_pcie *rockchip) { - struct device *dev = &pdev->dev; struct dw_pcie_rp *pp; - int irq, ret; u32 val; if (!IS_ENABLED(CONFIG_PCIE_ROCKCHIP_DW_HOST)) return -ENODEV; - irq = platform_get_irq_byname(pdev, "sys"); - if (irq < 0) - return irq; - - ret = devm_request_threaded_irq(dev, irq, NULL, - rockchip_pcie_rc_sys_irq_thread, - IRQF_ONESHOT, "pcie-sys-rc", rockchip); - if (ret) { - dev_err(dev, "failed to request PCIe sys IRQ\n"); - return ret; - } - /* LTSSM enable control mode */ val = FIELD_PREP_WM16(PCIE_LTSSM_ENABLE_ENHANCE, 1); rockchip_pcie_writel_apb(rockchip, val, PCIE_CLIENT_HOT_RESET_CTRL); @@ -602,17 +559,7 @@ static int rockchip_pcie_configure_rc(struct platform_device *pdev, pp = &rockchip->pci.pp; pp->ops = &rockchip_pcie_host_ops; - ret = dw_pcie_host_init(pp); - if (ret) { - dev_err(dev, "failed to initialize host\n"); - return ret; - } - - /* unmask DLL up/down indicator */ - val = FIELD_PREP_WM16(PCIE_RDLH_LINK_UP_CHGED, 0); - rockchip_pcie_writel_apb(rockchip, val, PCIE_CLIENT_INTR_MASK_MISC); - - return ret; + return dw_pcie_host_init(pp); } static int rockchip_pcie_configure_ep(struct platform_device *pdev, @@ -731,7 +678,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev) switch (data->mode) { case DW_PCIE_RC_TYPE: - ret = rockchip_pcie_configure_rc(pdev, rockchip); + ret = rockchip_pcie_configure_rc(rockchip); if (ret) goto deinit_clk; break; -- 2.52.0

16 hours, 20 minutes

1
0
0 0

[PATCH v2 1/6] Revert "PCI: dw-rockchip: Don't wait for link since we can detect Link Up"

by Niklas Cassel

This reverts commit ec9fd499b9c60a187ac8d6414c3c343c77d32e42. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number after initial scan during boot. The long term plan is to migrate this driver to the pwrctrl framework, once it adds proper support for powering up and enumerating PCIe switches. Cc: stable(a)vger.kernel.org Suggested-by: Manivannan Sadhasivam <mani(a)kernel.org> Acked-by: Shawn Lin <shawn.lin(a)rock-chips.com> Tested-by: Shawn Lin <shawn.lin(a)rock-chips.com> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- drivers/pci/controller/dwc/pcie-dw-rockchip.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c index 8c1c92208802..ca808d8f7975 100644 --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c @@ -601,7 +601,6 @@ static int rockchip_pcie_configure_rc(struct platform_device *pdev, pp = &rockchip->pci.pp; pp->ops = &rockchip_pcie_host_ops; - pp->use_linkup_irq = true; ret = dw_pcie_host_init(pp); if (ret) { -- 2.52.0

16 hours, 20 minutes

1
0
0 0

[PATCH] clockevents: add a error handling in tick_broadcast_init_sysfs()

by Haoxiang Li

If device_register() fails, call put_device() to drop the device reference. Fixes: 501f867064e9 ("clockevents: Provide sysfs interface") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- kernel/time/clockevents.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c index a59bc75ab7c5..94e223cf9c74 100644 --- a/kernel/time/clockevents.c +++ b/kernel/time/clockevents.c @@ -733,8 +733,12 @@ static __init int tick_broadcast_init_sysfs(void) { int err = device_register(&tick_bc_dev); - if (!err) - err = device_create_file(&tick_bc_dev, &dev_attr_current_device); + if (err) { + put_deivce(&tick_bc_dev); + return err; + } + + err = device_create_file(&tick_bc_dev, &dev_attr_current_device); return err; } #else -- 2.25.1

16 hours, 38 minutes

3
6
0 0

[PATCH] powerpc/pseries/cmm: fix the error handling in cmm_sysfs_register()

by Haoxiang Li

If device_register() fails, put_device() should be called to drop the device reference. Thus add put_device() after subsys_unregister label and change device_unregister() to device_del() in fail label. Found by code review. Fixes: 6c9d29095264 ("power: cmm - convert sysdev_class to a regular subsystem") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- arch/powerpc/platforms/pseries/cmm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c index 4cbbe2ee58ab..0666d3300bdb 100644 --- a/arch/powerpc/platforms/pseries/cmm.c +++ b/arch/powerpc/platforms/pseries/cmm.c @@ -419,8 +419,9 @@ static int cmm_sysfs_register(struct device *dev) fail: while (--i >= 0) device_remove_file(dev, cmm_attrs[i]); - device_unregister(dev); + device_del(dev); subsys_unregister: + put_device(dev); bus_unregister(&cmm_subsys); return rc; } -- 2.25.1

16 hours, 43 minutes

2
1
0 0

[PATCH] dmaengine: fix a reference leak in __dma_async_device_channel_register()

by Haoxiang Li

After device_register() is called, put_device() is required to drop the device reference. In this case, put_device() -> chan_dev_release() will finally release chan->dev. Thus there is no need to call kfree again to release the chan->dev. Found by code review. Fixes: d2fb0a043838 ("dmaengine: break out channel registration") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/dma/dmaengine.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c index ca13cd39330b..9d7cea1d6e91 100644 --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -1071,6 +1071,7 @@ static int __dma_async_device_channel_register(struct dma_device *device, const char *name) { int rc; + bool dev_registered = false; chan->local = alloc_percpu(typeof(*chan->local)); if (!chan->local) @@ -1102,6 +1103,7 @@ static int __dma_async_device_channel_register(struct dma_device *device, else dev_set_name(&chan->dev->device, "%s", name); rc = device_register(&chan->dev->device); + dev_registered = true; if (rc) goto err_out_ida; chan->client_count = 0; @@ -1112,7 +1114,10 @@ static int __dma_async_device_channel_register(struct dma_device *device, err_out_ida: ida_free(&device->chan_ida, chan->chan_id); err_free_dev: - kfree(chan->dev); + if (dev_registered) + put_device(&chan->dev->device); + else + kfree(chan->dev); err_free_local: free_percpu(chan->local); chan->local = NULL; -- 2.25.1

18 hours, 54 minutes

1
0
0 0

[PATCH 0/2] LoongArch: KVM: fix "unreliable stack" issue

by Xianglai Li

When starting multi-core loongarch virtualization on loongarch physical machine, loading livepatch on the physical machine will cause an error similar to the following: [ 411.686289] livepatch: klp_try_switch_task: CPU 31/KVM:3116 has an unreliable stack The specific test steps are as follows: 1.Start a multi-core virtual machine on a physical machine 2.Enter the following command on the physical machine to turn on the debug switch: echo "file kernel/livepatch/transition.c +p" > /sys/kernel/debug/\ dynamic_debug/control 3.Load livepatch: modprobe livepatch-sample Through the above steps, similar prints can be viewed in dmesg. The reason for this issue is that the code of the kvm_exc_entry function was copied in the function kvm_loongarch_env_init. When the cpu needs to execute kvm_exc_entry, it will switch to the copied address for execution. The new address of the kvm_exc_entry function cannot be recognized in ORC, which eventually leads to the arch_stack_walk_reliable function returning an error and printing an exception message. To solve the above problems, we directly compile the switch.S file into the kernel instead of the module. In this way, the function kvm_exc_entry will no longer need to be copied. Cc: Huacai Chen <chenhuacai(a)kernel.org> Cc: WANG Xuerui <kernel(a)xen0n.name> Cc: Tianrui Zhao <zhaotianrui(a)loongson.cn> Cc: Bibo Mao <maobibo(a)loongson.cn> Cc: Charlie Jenkins <charlie(a)rivosinc.com> Cc: Xianglai Li <lixianglai(a)loongson.cn> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Xianglai Li (2): LoongArch: KVM: Compile the switch.S file directly into the kernel LoongArch: KVM: fix "unreliable stack" issue arch/loongarch/Kbuild | 2 +- arch/loongarch/include/asm/asm-prototypes.h | 16 ++++++++++ arch/loongarch/include/asm/kvm_host.h | 5 +-- arch/loongarch/include/asm/kvm_vcpu.h | 20 ++++++------ arch/loongarch/kvm/Makefile | 2 +- arch/loongarch/kvm/main.c | 35 ++------------------- arch/loongarch/kvm/switch.S | 24 +++++++++++--- 7 files changed, 51 insertions(+), 53 deletions(-) base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 -- 2.39.1

19 hours, 19 minutes

3
6
0 0

[PATCH 6.1.y] spi: cadence-qspi: fix pointer reference in runtime PM hooks

by Zhaoyang Li

From: Théo Lebrun <theo.lebrun(a)bootlin.com> [ Upstream commit 32ce3bb57b6b402de2aec1012511e7ac4e7449dc ] dev_get_drvdata() gets used to acquire the pointer to cqspi and the SPI controller. Neither embed the other; this lead to memory corruption. On a given platform (Mobileye EyeQ5) the memory corruption is hidden inside cqspi->f_pdata. Also, this uninitialised memory is used as a mutex (ctlr->bus_lock_mutex) by spi_controller_suspend(). Fixes: 2087e85bb66e ("spi: cadence-quadspi: fix suspend-resume implementations") Reviewed-by: Dhruva Gole <d-gole(a)ti.com> Signed-off-by: Théo Lebrun <theo.lebrun(a)bootlin.com> Link: https://msgid.link/r/20240222-cdns-qspi-pm-fix-v4-1-6b6af8bcbf59@bootlin.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Zhaoyang Li <lizy04(a)hust.edu.cn> --- drivers/spi/spi-cadence-quadspi.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c index 42861bc45073..02c5f00c8a57 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -1775,10 +1775,9 @@ static int cqspi_remove(struct platform_device *pdev) static int cqspi_suspend(struct device *dev) { struct cqspi_st *cqspi = dev_get_drvdata(dev); - struct spi_master *master = dev_get_drvdata(dev); int ret; - ret = spi_master_suspend(master); + ret = spi_master_suspend(cqspi->master); cqspi_controller_enable(cqspi, 0); clk_disable_unprepare(cqspi->clk); @@ -1789,7 +1788,6 @@ static int cqspi_suspend(struct device *dev) static int cqspi_resume(struct device *dev) { struct cqspi_st *cqspi = dev_get_drvdata(dev); - struct spi_master *master = dev_get_drvdata(dev); clk_prepare_enable(cqspi->clk); cqspi_wait_idle(cqspi); @@ -1798,7 +1796,7 @@ static int cqspi_resume(struct device *dev) cqspi->current_cs = -1; cqspi->sclk = 0; - return spi_master_resume(master); + return spi_master_resume(cqspi->master); } static DEFINE_SIMPLE_DEV_PM_OPS(cqspi_dev_pm_ops, cqspi_suspend, cqspi_resume); -- 2.25.1

19 hours, 33 minutes

3
3
0 0

[PATCHv3 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

by Pingfan Liu

The kexec segment index will be required to extract the corresponding information for that segment in kimage_map_segment(). Additionally, kexec_segment already holds the kexec relocation destination address and size. Therefore, the prototype of kimage_map_segment() can be changed. Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") Signed-off-by: Pingfan Liu <piliu(a)redhat.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Baoquan He <bhe(a)redhat.com> Cc: Mimi Zohar <zohar(a)linux.ibm.com> Cc: Roberto Sassu <roberto.sassu(a)huawei.com> Cc: Alexander Graf <graf(a)amazon.com> Cc: Steven Chen <chenste(a)linux.microsoft.com> Cc: linux-kernel(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> To: kexec(a)lists.infradead.org To: linux-integrity(a)vger.kernel.org --- include/linux/kexec.h | 4 ++-- kernel/kexec_core.c | 9 ++++++--- security/integrity/ima/ima_kexec.c | 4 +--- 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/include/linux/kexec.h b/include/linux/kexec.h index ff7e231b0485..8a22bc9b8c6c 100644 --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print; #define kexec_dprintk(fmt, arg...) \ do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0) -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size); +extern void *kimage_map_segment(struct kimage *image, int idx); extern void kimage_unmap_segment(void *buffer); #else /* !CONFIG_KEXEC_CORE */ struct pt_regs; @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { } static inline void crash_kexec(struct pt_regs *regs) { } static inline int kexec_should_crash(struct task_struct *p) { return 0; } static inline int kexec_crash_loaded(void) { return 0; } -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size) +static inline void *kimage_map_segment(struct kimage *image, int idx) { return NULL; } static inline void kimage_unmap_segment(void *buffer) { } #define kexec_in_progress false diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index 0f92acdd354d..1a79c5b18d8f 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -953,17 +953,20 @@ int kimage_load_segment(struct kimage *image, int idx) return result; } -void *kimage_map_segment(struct kimage *image, - unsigned long addr, unsigned long size) +void *kimage_map_segment(struct kimage *image, int idx) { + unsigned long addr, size, eaddr; unsigned long src_page_addr, dest_page_addr = 0; - unsigned long eaddr = addr + size; kimage_entry_t *ptr, entry; struct page **src_pages; unsigned int npages; void *vaddr = NULL; int i; + addr = image->segment[idx].mem; + size = image->segment[idx].memsz; + eaddr = addr + size; + /* * Collect the source pages and map them in a contiguous VA range. */ diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c index 7362f68f2d8b..5beb69edd12f 100644 --- a/security/integrity/ima/ima_kexec.c +++ b/security/integrity/ima/ima_kexec.c @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image) if (!image->ima_buffer_addr) return; - ima_kexec_buffer = kimage_map_segment(image, - image->ima_buffer_addr, - image->ima_buffer_size); + ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index); if (!ima_kexec_buffer) { pr_err("Could not map measurements buffer.\n"); return; -- 2.49.0

20 hours, 53 minutes

2
2
0 0

RE: Patch "cpufreq: dt-platdev: Add JH7110S SOC to the allowlist" has been added to the 6.6-stable tree

by Hal Feng

> On 19.12.25 20:34, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable- > queue.git;a=summary > > The filename of the patch is: > cpufreq-dt-platdev-add-jh7110s-soc-to-the-allowlist.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, please let > <stable(a)vger.kernel.org> know about it. As series [1] is accepted, this patch will be not needed and will be reverted in the mainline. [1] https://lore.kernel.org/all/20251212211934.135602-1-e@freeshell.de/ So we should not add it to the stable tree. Thanks. Best regards, Hal > > > > commit 62295dd3b326acf42f033124c4a48278b71b53a4 > Author: Hal Feng <hal.feng(a)starfivetech.com> > Date: Thu Oct 16 16:00:48 2025 +0800 > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > [ Upstream commit 6e7970cab51d01b8f7c56f120486c571c22e1b80 ] > > Add the compatible strings for supporting the generic > cpufreq driver on the StarFive JH7110S SoC. > > Signed-off-by: Hal Feng <hal.feng(a)starfivetech.com> > Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> > Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq- > dt-platdev.c > index c58c1defd7458..8b53388280d73 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -87,6 +87,7 @@ static const struct of_device_id allowlist[] __initconst = { > { .compatible = "st-ericsson,u9540", }, > > { .compatible = "starfive,jh7110", }, > + { .compatible = "starfive,jh7110s", }, > > { .compatible = "ti,omap2", }, > { .compatible = "ti,omap4", },

21 hours, 5 minutes

1
0
0 0

[PATCH net v3] net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()

by Xiaolei Wang

In the non-RT kernel, local_bh_disable() merely disables preemption, whereas it maps to an actual spin lock in the RT kernel. Consequently, when attempting to refill RX buffers via netdev_alloc_skb() in macb_mac_link_up(), a deadlock scenario arises as follows: WARNING: possible circular locking dependency detected 6.18.0-08691-g2061f18ad76e #39 Not tainted ------------------------------------------------------ kworker/0:0/8 is trying to acquire lock: ffff00080369bbe0 (&bp->lock){+.+.}-{3:3}, at: macb_start_xmit+0x808/0xb7c but task is already holding lock: ffff000803698e58 (&queue->tx_ptr_lock){+...}-{3:3}, at: macb_start_xmit +0x148/0xb7c which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&queue->tx_ptr_lock){+...}-{3:3}: rt_spin_lock+0x50/0x1f0 macb_start_xmit+0x148/0xb7c dev_hard_start_xmit+0x94/0x284 sch_direct_xmit+0x8c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 -> #2 (_xmit_ETHER#2){+...}-{3:3}: rt_spin_lock+0x50/0x1f0 sch_direct_xmit+0x11c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 -> #1 ((softirq_ctrl.lock)){+.+.}-{3:3}: lock_release+0x250/0x348 __local_bh_enable_ip+0x7c/0x240 __netdev_alloc_skb+0x1b4/0x1d8 gem_rx_refill+0xdc/0x240 gem_init_rings+0xb4/0x108 macb_mac_link_up+0x9c/0x2b4 phylink_resolve+0x170/0x614 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 -> #0 (&bp->lock){+.+.}-{3:3}: __lock_acquire+0x15a8/0x2084 lock_acquire+0x1cc/0x350 rt_spin_lock+0x50/0x1f0 macb_start_xmit+0x808/0xb7c dev_hard_start_xmit+0x94/0x284 sch_direct_xmit+0x8c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 other info that might help us debug this: Chain exists of: &bp->lock --> _xmit_ETHER#2 --> &queue->tx_ptr_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&queue->tx_ptr_lock); lock(_xmit_ETHER#2); lock(&queue->tx_ptr_lock); lock(&bp->lock); *** DEADLOCK *** Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0xa0/0xf0 dump_stack+0x18/0x24 print_circular_bug+0x28c/0x370 check_noncircular+0x198/0x1ac __lock_acquire+0x15a8/0x2084 lock_acquire+0x1cc/0x350 rt_spin_lock+0x50/0x1f0 macb_start_xmit+0x808/0xb7c dev_hard_start_xmit+0x94/0x284 sch_direct_xmit+0x8c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 Notably, invoking the mog_init_rings() callback upon link establishment is unnecessary. Instead, we can exclusively call mog_init_rings() within the ndo_open() callback. This adjustment resolves the deadlock issue. Furthermore, since MACB_CAPS_MACB_IS_EMAC cases do not use mog_init_rings() when opening the network interface via at91ether_open(), moving mog_init_rings() to macb_open() also eliminates the MACB_CAPS_MACB_IS_EMAC check. Fixes: 633e98a711ac ("net: macb: use resolved link config in mac_link_up()") Cc: stable(a)vger.kernel.org Suggested-by: Kevin Hao <kexin.hao(a)windriver.com> Signed-off-by: Xiaolei Wang <xiaolei.wang(a)windriver.com> --- V1: https://patchwork.kernel.org/project/netdevbpf/patch/20251128103647.351259-… V2: Update the correct lock dependency chain and add the Fix tag. V3: update commit log, Add full deadlock log added explanations: because MACB_CAPS_MACB_IS_EMAC cases do not use mog_init_rings(), we don't need the MACB_CAPS_MACB_IS_EMAC check when moving mog_init_rings() to macb_open(). drivers/net/ethernet/cadence/macb_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index ca2386b83473..064fccdcf699 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -744,7 +744,6 @@ static void macb_mac_link_up(struct phylink_config *config, /* Initialize rings & buffers as clearing MACB_BIT(TE) in link down * cleared the pipeline and control registers. */ - bp->macbgem_ops.mog_init_rings(bp); macb_init_buffers(bp); for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) @@ -2991,6 +2990,8 @@ static int macb_open(struct net_device *dev) goto pm_exit; } + bp->macbgem_ops.mog_init_rings(bp); + for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) { napi_enable(&queue->napi_rx); napi_enable(&queue->napi_tx); -- 2.43.0

21 hours, 6 minutes

1
0
0 0

RE: Patch "cpufreq: dt-platdev: Add JH7110S SOC to the allowlist" has been added to the 6.12-stable tree

by Hal Feng

> On 19.12.25 20:33, Sasha Levin wrote: > > This is a note to let you know that I've just added the patch titled > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable- > queue.git;a=summary > > The filename of the patch is: > cpufreq-dt-platdev-add-jh7110s-soc-to-the-allowlist.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, please let > <stable(a)vger.kernel.org> know about it. As series [1] is accepted, this patch will be not needed and will be reverted in the mainline. [1] https://lore.kernel.org/all/20251212211934.135602-1-e@freeshell.de/ So we should not add it to the stable tree. Thanks. Best regards, Hal > > > > commit fb0dfa5be2ce8716ed8a7a6c8ffb8d36f5e03541 > Author: Hal Feng <hal.feng(a)starfivetech.com> > Date: Thu Oct 16 16:00:48 2025 +0800 > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > [ Upstream commit 6e7970cab51d01b8f7c56f120486c571c22e1b80 ] > > Add the compatible strings for supporting the generic > cpufreq driver on the StarFive JH7110S SoC. > > Signed-off-by: Hal Feng <hal.feng(a)starfivetech.com> > Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> > Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq- > dt-platdev.c > index 67bac12d4d55b..dbd73cd0cf535 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -87,6 +87,7 @@ static const struct of_device_id allowlist[] __initconst = { > { .compatible = "st-ericsson,u9540", }, > > { .compatible = "starfive,jh7110", }, > + { .compatible = "starfive,jh7110s", }, > > { .compatible = "ti,omap2", }, > { .compatible = "ti,omap4", },

21 hours, 6 minutes

1
0
0 0

RE: Patch "cpufreq: dt-platdev: Add JH7110S SOC to the allowlist" has been added to the 6.18-stable tree

by Hal Feng

> On 19.12.25 20:31, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > to the 6.18-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable- > queue.git;a=summary > > The filename of the patch is: > cpufreq-dt-platdev-add-jh7110s-soc-to-the-allowlist.patch > and it can be found in the queue-6.18 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, please let > <stable(a)vger.kernel.org> know about it. As series [1] is accepted, this patch will be not needed and will be reverted in the mainline. [1] https://lore.kernel.org/all/20251212211934.135602-1-e@freeshell.de/ So we should not add it to the stable tree. Thanks. Best regards, Hal > > > > commit f922a9b37397e7db449e3fa61c33c542ad783f87 > Author: Hal Feng <hal.feng(a)starfivetech.com> > Date: Thu Oct 16 16:00:48 2025 +0800 > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > [ Upstream commit 6e7970cab51d01b8f7c56f120486c571c22e1b80 ] > > Add the compatible strings for supporting the generic > cpufreq driver on the StarFive JH7110S SoC. > > Signed-off-by: Hal Feng <hal.feng(a)starfivetech.com> > Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> > Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq- > dt-platdev.c > index cd1816a12bb99..dc11b62399ad5 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -87,6 +87,7 @@ static const struct of_device_id allowlist[] __initconst = { > { .compatible = "st-ericsson,u9540", }, > > { .compatible = "starfive,jh7110", }, > + { .compatible = "starfive,jh7110s", }, > > { .compatible = "ti,omap2", }, > { .compatible = "ti,omap4", },

21 hours, 8 minutes

1
0
0 0

ARMv7 Linux + Rust doesn't boot when compiling with only LLVM=1

by Rudraksha Gupta

Hello all, I have the following problem: https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/issues/2635 In short, what is happening is the following: - The kernel boots and outputs via UART when I build the kernel with the following: make LLVM=1 ARCH="$arm" CC="${CC:-gcc}" - The kernel doesn't boot and there is no output via UART when I build the kernel with the following: make LLVM=1 ARCH="$arm" The only difference being: CC="${CC:-gcc}". Is this expected? I think this was present in the Linux kernel ever since Rust was enabled for ARMv7, and I never encountered it because postmarketOS was originally building the first way. Thanks, Rudraksha

23 hours, 2 minutes

5
11
0 0

[PATCH v2] net: usb: sr9700: fix incorrect command used to write single register

by Ethan Nelson-Moore

This fixes the device failing to initialize with "error reading MAC address" for me, probably because the incorrect write of NCR_RST to SR_NCR is not actually resetting the device. Fixes: c9b37458e95629b1d1171457afdcc1bf1eb7881d ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support") Cc: stable(a)vger.kernel.org Signed-off-by: Ethan Nelson-Moore <enelsonmoore(a)gmail.com> --- drivers/net/usb/sr9700.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c index 091bc2aca7e8..5d97e95a17b0 100644 --- a/drivers/net/usb/sr9700.c +++ b/drivers/net/usb/sr9700.c @@ -52,7 +52,7 @@ static int sr_read_reg(struct usbnet *dev, u8 reg, u8 *value) static int sr_write_reg(struct usbnet *dev, u8 reg, u8 value) { - return usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG, + return usbnet_write_cmd(dev, SR_WR_REG, SR_REQ_WR_REG, value, reg, NULL, 0); } @@ -65,7 +65,7 @@ static void sr_write_async(struct usbnet *dev, u8 reg, u16 length, static void sr_write_reg_async(struct usbnet *dev, u8 reg, u8 value) { - usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG, + usbnet_write_cmd_async(dev, SR_WR_REG, SR_REQ_WR_REG, value, reg, NULL, 0); } -- 2.43.0

23 hours, 12 minutes

2
2
0 0

[PATCH v1 3/5] mm: Take into account mm_cid size for mm_struct static definitions

by Mathieu Desnoyers

Both init_mm and efi_mm static definitions need to make room for the 2 mm_cid cpumasks. This fixes possible out-of-bounds accesses to init_mm and efi_mm. Fixes: af7f588d8f73 ("sched: Introduce per-memory-map concurrency ID") Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org Cc: linux-mm(a)kvack.org --- include/linux/mm_types.h | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index 1531df8cda52..aefa64db3499 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -1368,7 +1368,7 @@ extern struct mm_struct init_mm; #define MM_STRUCT_FLEXIBLE_ARRAY_INIT \ { \ - [0 ... sizeof(cpumask_t)-1] = 0 \ + [0 ... sizeof(cpumask_t) + MM_CID_STATIC_SIZE - 1] = 0 \ } /* Pointer magic because the dynamic array size confuses some compilers. */ @@ -1500,7 +1500,7 @@ static inline int mm_alloc_cid_noprof(struct mm_struct *mm, struct task_struct * mm_init_cid(mm, p); return 0; } -#define mm_alloc_cid(...) alloc_hooks(mm_alloc_cid_noprof(__VA_ARGS__)) +# define mm_alloc_cid(...) alloc_hooks(mm_alloc_cid_noprof(__VA_ARGS__)) static inline void mm_destroy_cid(struct mm_struct *mm) { @@ -1514,6 +1514,8 @@ static inline unsigned int mm_cid_size(void) return cpumask_size() + bitmap_size(num_possible_cpus()); } +/* Use NR_CPUS as worse case for static allocation. */ +# define MM_CID_STATIC_SIZE (2 * sizeof(cpumask_t)) #else /* CONFIG_SCHED_MM_CID */ static inline void mm_init_cid(struct mm_struct *mm, struct task_struct *p) { } static inline int mm_alloc_cid(struct mm_struct *mm, struct task_struct *p) { return 0; } @@ -1522,6 +1524,7 @@ static inline unsigned int mm_cid_size(void) { return 0; } +# define MM_CID_STATIC_SIZE 0 #endif /* CONFIG_SCHED_MM_CID */ struct mmu_gather; -- 2.39.5

23 hours, 33 minutes

1
0
0 0

[PATCH v1 1/5] mm: Add missing static initializer for init_mm::mm_cid.lock

by Mathieu Desnoyers

Initialize the mm_cid.lock struct member of init_mm. Fixes: 8cea569ca785 ("sched/mmcid: Use proper data structures") Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Cc: linux-mm(a)kvack.org --- mm/init-mm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/init-mm.c b/mm/init-mm.c index 4600e7605cab..a514f8ce47e3 100644 --- a/mm/init-mm.c +++ b/mm/init-mm.c @@ -44,6 +44,9 @@ struct mm_struct init_mm = { .mm_lock_seq = SEQCNT_ZERO(init_mm.mm_lock_seq), #endif .user_ns = &init_user_ns, +#ifdef CONFIG_SCHED_MM_CID + .mm_cid.lock = __RAW_SPIN_LOCK_UNLOCKED(init_mm.mm_cid.lock), +#endif .cpu_bitmap = CPU_BITS_NONE, INIT_MM_CONTEXT(init_mm) }; -- 2.39.5

23 hours, 33 minutes

1
0
0 0

[PATCH] iio: imu: inv_icm45600: fix temperature offset reporting

by Jean-Baptiste Maneyrol via B4 Relay

From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> Correct temperature computation is (raw + offset) * scale and not apply scale and offset afterward. Fix temperature offset reporting to the correct value and update commentaries for the new computation. Fixes: 27e072bc34d1 ("iio: imu: inv_icm45600: add IMU IIO gyroscope device") Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> Cc: stable(a)vger.kernel.org --- drivers/iio/imu/inv_icm45600/inv_icm45600_core.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/iio/imu/inv_icm45600/inv_icm45600_core.c b/drivers/iio/imu/inv_icm45600/inv_icm45600_core.c index ab1cb7b9dba435a3280e50ab77cd16e903c7816c..25bd9757a594d0180d7f53b49f959a49a50c64a9 100644 --- a/drivers/iio/imu/inv_icm45600/inv_icm45600_core.c +++ b/drivers/iio/imu/inv_icm45600/inv_icm45600_core.c @@ -960,16 +960,17 @@ int inv_icm45600_temp_read_raw(struct iio_dev *indio_dev, return IIO_VAL_INT; /* * T°C = (temp / 128) + 25 - * Tm°C = 1000 * ((temp * 100 / 12800) + 25) - * scale: 100000 / 13248 = 7.8125 - * offset: 25000 + * Tm°C = ((temp + 25 * 128) / 128)) * 1000 + * Tm°C = (temp + 3200) * (1000 / 128) + * scale: 1000 / 128 = 7.8125 + * offset: 3200 */ case IIO_CHAN_INFO_SCALE: *val = 7; *val2 = 812500; return IIO_VAL_INT_PLUS_MICRO; case IIO_CHAN_INFO_OFFSET: - *val = 25000; + *val = 3200; return IIO_VAL_INT; default: return -EINVAL; --- base-commit: a7b10f0963c651a6406d958a5f64b9c5594f84da change-id: 20251218-inv-icm45600-fix-temperature-offset-reporting-190a09adfdad Best regards, -- Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com>

1 day, 4 hours

2
1
0 0

[PATCH] iio: adc: exynos_adc: fix OF populate on driver rebind

by Johan Hovold

Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable(a)vger.kernel.org # 3.16 Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/iio/adc/exynos_adc.c | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c index 1484adff00df..f2400897818c 100644 --- a/drivers/iio/adc/exynos_adc.c +++ b/drivers/iio/adc/exynos_adc.c @@ -540,15 +540,6 @@ static const struct iio_chan_spec exynos_adc_iio_channels[] = { ADC_CHANNEL(9, "adc9"), }; -static int exynos_adc_remove_devices(struct device *dev, void *c) -{ - struct platform_device *pdev = to_platform_device(dev); - - platform_device_unregister(pdev); - - return 0; -} - static int exynos_adc_probe(struct platform_device *pdev) { struct exynos_adc *info = NULL; @@ -660,8 +651,7 @@ static int exynos_adc_probe(struct platform_device *pdev) return 0; err_of_populate: - device_for_each_child(&indio_dev->dev, NULL, - exynos_adc_remove_devices); + of_platform_depopulate(&indio_dev->dev); iio_device_unregister(indio_dev); err_irq: free_irq(info->irq, info); @@ -681,8 +671,7 @@ static void exynos_adc_remove(struct platform_device *pdev) struct iio_dev *indio_dev = platform_get_drvdata(pdev); struct exynos_adc *info = iio_priv(indio_dev); - device_for_each_child(&indio_dev->dev, NULL, - exynos_adc_remove_devices); + of_platform_depopulate(&indio_dev->dev); iio_device_unregister(indio_dev); free_irq(info->irq, info); if (info->data->exit_hw) -- 2.51.2

1 day, 6 hours

3
2
0 0

[PATCH] fbdev: Use device_create_with_groups() to fix sysfs groups registration race

by Hans de Goede

The fbdev sysfs attributes are registered after sending the uevent for the device creation, leaving a race window where e.g. udev rules may not be able to access the sysfs attributes because the registration is not done yet. Fix this by switching to device_create_with_groups(). This also results in a nice cleanup. After switching to device_create_with_groups() all that is left of fb_init_device() is setting the drvdata and that can be passed to device_create[_with_groups]() too. After which fb_init_device() can be completely removed. Dropping fb_init_device() + fb_cleanup_device() in turn allows removing fb_info.class_flag as they were the only user of this field. Fixes: 5fc830d6aca1 ("fbdev: Register sysfs groups through device_add_group") Cc: stable(a)vger.kernel.org Cc: Shixiong Ou <oushixiong(a)kylinos.cn> Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- Note the fixes tag is technically wrong. This race has existed forever. The commit I picked for the fixes tag is a dependency of this change not the commit introducing the race. I don't believe that backporting this back any further is useful which is why I went with this commit. --- drivers/video/fbdev/core/fbsysfs.c | 36 +++--------------------------- include/linux/fb.h | 1 - 2 files changed, 3 insertions(+), 34 deletions(-) diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c index b8344c40073b..baa2bae0fb5b 100644 --- a/drivers/video/fbdev/core/fbsysfs.c +++ b/drivers/video/fbdev/core/fbsysfs.c @@ -12,8 +12,6 @@ #include "fb_internal.h" -#define FB_SYSFS_FLAG_ATTR 1 - static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var) { int err; @@ -451,33 +449,7 @@ static struct attribute *fb_device_attrs[] = { NULL, }; -static const struct attribute_group fb_device_attr_group = { - .attrs = fb_device_attrs, -}; - -static int fb_init_device(struct fb_info *fb_info) -{ - int ret; - - dev_set_drvdata(fb_info->dev, fb_info); - - fb_info->class_flag |= FB_SYSFS_FLAG_ATTR; - - ret = device_add_group(fb_info->dev, &fb_device_attr_group); - if (ret) - fb_info->class_flag &= ~FB_SYSFS_FLAG_ATTR; - - return 0; -} - -static void fb_cleanup_device(struct fb_info *fb_info) -{ - if (fb_info->class_flag & FB_SYSFS_FLAG_ATTR) { - device_remove_group(fb_info->dev, &fb_device_attr_group); - - fb_info->class_flag &= ~FB_SYSFS_FLAG_ATTR; - } -} +ATTRIBUTE_GROUPS(fb_device); int fb_device_create(struct fb_info *fb_info) { @@ -485,14 +457,13 @@ int fb_device_create(struct fb_info *fb_info) dev_t devt = MKDEV(FB_MAJOR, node); int ret; - fb_info->dev = device_create(fb_class, fb_info->device, devt, NULL, "fb%d", node); + fb_info->dev = device_create_with_groups(fb_class, fb_info->device, devt, fb_info, + fb_device_groups, "fb%d", node); if (IS_ERR(fb_info->dev)) { /* Not fatal */ ret = PTR_ERR(fb_info->dev); pr_warn("Unable to create device for framebuffer %d; error %d\n", node, ret); fb_info->dev = NULL; - } else { - fb_init_device(fb_info); } return 0; @@ -505,7 +476,6 @@ void fb_device_destroy(struct fb_info *fb_info) if (!fb_info->dev) return; - fb_cleanup_device(fb_info); device_destroy(fb_class, devt); fb_info->dev = NULL; } diff --git a/include/linux/fb.h b/include/linux/fb.h index 05cc251035da..c3302d513546 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -497,7 +497,6 @@ struct fb_info { #if defined(CONFIG_FB_DEVICE) struct device *dev; /* This is this fb device */ #endif - int class_flag; /* private sysfs flags */ #ifdef CONFIG_FB_TILEBLITTING struct fb_tile_ops *tileops; /* Tile Blitting */ #endif -- 2.52.0

1 day, 6 hours

1
0
0 0

LDI Show 2025 Attendee List

by Audrey Roberts

Hi Exhibitor, Hope you had a successful experience at LDI Show 2025 (Dec 3–9, Las Vegas). We have access to a verified list of 16,594 attendees and 312 exhibitors across the live events, lighting, audio, staging, and production-technology sectors. This includes lighting designers, audio engineers, production managers, AV integrators, stage/rigging technicians, venue operations heads, broadcast specialists, and other key live-event decision-makers. Don’t miss the opportunity to connect with high-quality prospects after the event. If interested, kindly reply “Send Pricing” to receive the details. Best regards, Audrey Roberts Senior Market Analyst To opt-out, reply “Not Interested”.

1 day, 6 hours

1
0
0 0

[PATCH v2] erofs: fix unexpected EIO under memory pressure

by Junbeom Yeom

erofs readahead could fail with ENOMEM under the memory pressure because it tries to alloc_page with GFP_NOWAIT | GFP_NORETRY, while GFP_KERNEL for a regular read. And if readahead fails (with non-uptodate folios), the original request will then fall back to synchronous read, and `.read_folio()` should return appropriate errnos. However, in scenarios where readahead and read operations compete, read operation could return an unintended EIO because of an incorrect error propagation. To resolve this, this patch modifies the behavior so that, when the PCL is for read(which means pcl.besteffort is true), it attempts actual decompression instead of propagating the privios error except initial EIO. - Page size: 4K - The original size of FileA: 16K - Compress-ratio per PCL: 50% (Uncompressed 8K -> Compressed 4K) [page0, page1] [page2, page3] [PCL0]---------[PCL1] - functions declaration: . pread(fd, buf, count, offset) . readahead(fd, offset, count) - Thread A tries to read the last 4K - Thread B tries to do readahead 8K from 4K - RA, besteffort == false - R, besteffort == true <process A> <process B> pread(FileA, buf, 4K, 12K) do readahead(page3) // failed with ENOMEM wait_lock(page3) if (!uptodate(page3)) goto do_read readahead(FileA, 4K, 8K) // Here create PCL-chain like below: // [null, page1] [page2, null] // [PCL0:RA]-----[PCL1:RA] ... do read(page3) // found [PCL1:RA] and add page3 into it, // and then, change PCL1 from RA to R ... // Now, PCL-chain is as below: // [null, page1] [page2, page3] // [PCL0:RA]-----[PCL1:R] // try to decompress PCL-chain... z_erofs_decompress_queue err = 0; // failed with ENOMEM, so page 1 // only for RA will not be uptodated. // it's okay. err = decompress([PCL0:RA], err) // However, ENOMEM propagated to next // PCL, even though PCL is not only // for RA but also for R. As a result, // it just failed with ENOMEM without // trying any decompression, so page2 // and page3 will not be uptodated. ** BUG HERE ** --> err = decompress([PCL1:R], err) return err as ENOMEM ... wait_lock(page3) if (!uptodate(page3)) return EIO <-- Return an unexpected EIO! ... Fixes: 2349d2fa02db ("erofs: sunset unneeded NOFAILs") Cc: stable(a)vger.kernel.org Reviewed-by: Jaewook Kim <jw5454.kim(a)samsung.com> Reviewed-by: Sungjong Seo <sj1557.seo(a)samsung.com> Signed-off-by: Junbeom Yeom <junbeom.yeom(a)samsung.com> --- v2: - If disk I/Os are successful, handle to decompress each pcluster. fs/erofs/zdata.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c index 27b1f44d10ce..70e1597dec8a 100644 --- a/fs/erofs/zdata.c +++ b/fs/erofs/zdata.c @@ -1262,7 +1262,7 @@ static int z_erofs_parse_in_bvecs(struct z_erofs_backend *be, bool *overlapped) return err; } -static int z_erofs_decompress_pcluster(struct z_erofs_backend *be, int err) +static int z_erofs_decompress_pcluster(struct z_erofs_backend *be, bool eio) { struct erofs_sb_info *const sbi = EROFS_SB(be->sb); struct z_erofs_pcluster *pcl = be->pcl; @@ -1270,7 +1270,7 @@ static int z_erofs_decompress_pcluster(struct z_erofs_backend *be, int err) const struct z_erofs_decompressor *alg = z_erofs_decomp[pcl->algorithmformat]; bool try_free = true; - int i, j, jtop, err2; + int i, j, jtop, err2, err = eio ? -EIO : 0; struct page *page; bool overlapped; const char *reason; @@ -1413,12 +1413,12 @@ static int z_erofs_decompress_queue(const struct z_erofs_decompressqueue *io, .pcl = io->head, }; struct z_erofs_pcluster *next; - int err = io->eio ? -EIO : 0; + int err = 0; for (; be.pcl != Z_EROFS_PCLUSTER_TAIL; be.pcl = next) { DBG_BUGON(!be.pcl); next = READ_ONCE(be.pcl->next); - err = z_erofs_decompress_pcluster(&be, err) ?: err; + err = z_erofs_decompress_pcluster(&be, io->eio) ?: err; } return err; } -- 2.34.1

1 day, 7 hours

2
1
0 0

[PATCH] rapidio: fix a resource leak when rio_add_device() fails

by Haoxiang Li

If rio_add_device() fails, call rio_free_net() to unregister the net device registered by rio_add_net(). Fixes: e8de370188d0 ("rapidio: add mport char device driver") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/rapidio/devices/rio_mport_cdev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rapidio/devices/rio_mport_cdev.c b/drivers/rapidio/devices/rio_mport_cdev.c index 995cfeca972b..4a804b4ad6f7 100644 --- a/drivers/rapidio/devices/rio_mport_cdev.c +++ b/drivers/rapidio/devices/rio_mport_cdev.c @@ -1789,6 +1789,7 @@ static int rio_mport_add_riodev(struct mport_cdev_priv *priv, err = rio_add_device(rdev); if (err) { put_device(&rdev->dev); + rio_free_net(net); return err; } -- 2.25.1

1 day, 10 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror