[PATCH RFC v8 0/8] mfd: ls2kbmc: multiple fixes for this driver

[PATCH RFC v8 0/8] mfd: ls2kbmc: multiple fixes for this driver

[Miao Wang via B4 Relay]

Previously, the driver has been introduced to support the Loongson 2K
BMC running on the Loongson Servers, which is essential to prevent
the system from hanging when the BMC is being reset and the default
efi-framebuffer is being used. However, there are some drawbacks in the
driver.

Firstly, the driver tries to read and write to the connected PCI-E host
controller registers, assuming that the BMC is connected to LS7A PCI-E
host controller. This assumption should be true for real products, but
to prevent from accidentally reading and writing to the wrong PCI-E host
controller, this driver should be modified to check this before
accessing the registers.

Secondly, the driver uses non-exported functions to tell the vt
subsystem to redraw the screen, preventing the driver from being
compiling as a module. This can be fixed by using the exported
functions instead.

Thirdly, the driver directly accesses the GPIO controller registers
using hard-coded addresses, which might conflict with the loaded GPIO
controller driver for the same GPIO controller. This is fixed in this
series by using the GPIO subsystem APIs instead. To associate a GPIO pin
with a certian PCI device, it should be declared in the firmware level,
i.e. in the ACPI table or the device tree, and thus the firmware
interface should be discussed and coordinated with Loongson personnels.
Despite of this, the proposed solution in this series should be the
minimum necessary change to express such association. Furthermore, the
conventional GPIO pin number and the controller address are also
provided, to be used as a fallback when the GPIO pin is not declared.

Finally, there is a minor issue in the driver where it changes the
mode string describing the screen resolution during probing, which
prevents the device from being probed again if -EPROBE_DEFER is
returned by the probe function.

I have tested the changes in this series on a single-socket Loongson
3C6000 server with a Loongson 2K BMC, and the driver works as expected
when the corresponding GPIO driver is additionally loaded.

Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
Changes in v8:
- Address issues found by the Sashiko AI review bot
  - Fix the error path of the probe function, preventing unintentionally
    returning 0 on failure
  - Reorder the patches in the series to make the change to the Kconfig
    entry for ls2kbmc to be the last patch, to satisfy the AI bot's
    concern on failure to clean up when the driver is built as a module
    and is being removed.
- Link to v7: https://lore.kernel.org/r/20260810-ls2kbmc-mod-v7-0-8aa0fb5a5462@gmail.com

Changes in v7:
- When parsing the mode string, require the mode string to start with
  "video=", reverting the change in v5. Add a comment to describe the
  reason for this change to satisfy the AI bot's concern.
- When printing the invalid mode string, use %*pE to print the string
  to prevent the string from printing garbage characters, as suggested
  by the AI bot.
- When calculating the stride, check that the multiplication of width
  and depth does not overflow, as suggested by the AI bot.
- Add gpio_device_get_fwnode() into gpiolib.c as a library function to
  get the fwnode of a GPIO device, as suggested by Bartosz.
- Adjust the coding style of the patch as suggested by Bartosz.
- Link to v6: https://lore.kernel.org/r/20260805-ls2kbmc-mod-v6-0-16ccde412d86@gmail.com

Changes in v6:
- Ajdust the Kconfig entry for IPMI_LS2K, moving the dependency on
  MFD_LS2K_BMC_CORE to the IPMI_SI Kconfig entry, as discussed with
  and agreed by Corey.
- Link to v5: https://lore.kernel.org/r/20260804-ls2kbmc-mod-v5-0-e6bc5cdd9a93@gmail.com

Changes in v5:
- Address issues found by the Sashiko AI review bot
  - Maintain the compatibility with possible unexpected mode string when
    parsing, although such mode string is actually not expected, to
    satisfy the AI bot's concern.
  - Add a comment to point out that the adjustment of the Kconfig entry
    for ls2kbmc is in the following patch, to satisfy the AI bot's
    concern.
- Link to v4: https://lore.kernel.org/r/20260731-ls2kbmc-mod-v4-0-d201502ba239@gmail.com

Changes in v4:
- Use a better way to get the GPIO device fwnode.
- Add a comment to describe a problem found by AI bot which is actually
  intended.
- Link to v3: https://lore.kernel.org/r/20260710-ls2kbmc-mod-v3-0-ef718636e78e@gmail.com

Changes in v3:
- Check the return value of devm_add_action_or_reset when registering
  the cleanup hook of the work queue
- Use swnode to create the link between the device to the GPIO chip,
  and prevent borrowing the legacy GPIO APIs
- Link to v2: https://lore.kernel.org/r/20260708-ls2kbmc-mod-v2-0-2afdd1741766@gmail.com

Changes in v2:
- Several fixes suggested by the Sashiko AI review bot
- Add a cleanup function for the wq on removal of the device
- Relax the reverse dependency from CONFIG_IPMI_LS2K to
  CONFIG_MFD_LS2K_BMC_CORE to allow the driver to be built as a module
- Link to v1: https://lore.kernel.org/r/20260708-ls2kbmc-mod-v1-0-c344bf5defa3@gmail.com

---
Miao Wang (8):
      mfd: ls2kbmc: Make a copy when parsing mode string
      mfd: ls2kbmc: Sanity check for the connected pci port
      mfd: ls2kbmc: Redraw using exported functions
      mfd: ls2kbmc: Cancel the work queue on removal
      ipmi: ls2k: adjust dependency to its mfd driver
      gpiolib: add gpio_device_get_fwnode() helper
      mfd: ls2kbmc: Capture the reset event of BMC through GPIO
      mfd: ls2kbmc: Able to be compiled as a module

 drivers/char/ipmi/Kconfig   |   2 +-
 drivers/gpio/gpiolib.c      |  13 +++
 drivers/mfd/Kconfig         |   2 +-
 drivers/mfd/ls2k-bmc-core.c | 247 ++++++++++++++++++++++++++++++++++----------
 include/linux/gpio/driver.h |   1 +
 5 files changed, 206 insertions(+), 59 deletions(-)
---
base-commit: 11028ab62899e4191e074ee364c712b77823a9c4
change-id: 20260626-ls2kbmc-mod-5209193009b2

Best regards,
-- 
Miao Wang <shankerwangmiao@gmail.com>

[PATCH RFC v8 1/8] mfd: ls2kbmc: Make a copy when parsing mode string

[Miao Wang via B4 Relay]

From: Miao Wang <shankerwangmiao@gmail.com>

When parsing the mode string from BMC, the string is manipulated
in-place with strsep(), preventing from parsing it again. Make a copy of
the original string and manipulate the copy instead to fix this.

Fixes: 0d64f6d1ffe9 ("mfd: ls2kbmc: Introduce Loongson-2K BMC core driver")
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
 drivers/mfd/ls2k-bmc-core.c | 51 +++++++++++++++++++++++++++++++++++++--------
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c
index 408056bfb2fe757a5bde43775a483a48352e706d..335590392240ba1e13a2bdf6f9f4efddec045f40 100644
--- a/drivers/mfd/ls2k-bmc-core.c
+++ b/drivers/mfd/ls2k-bmc-core.c
@@ -427,34 +427,67 @@ static int ls2k_bmc_init(struct ls2k_bmc_ddata *ddata)
  */
 static int ls2k_bmc_parse_mode(struct pci_dev *pdev, struct simplefb_platform_data *pd)
 {
-	char *mode;
+	/* Assume 64 bytes is enough for the resolution string */
+	char mode_buf[64], mode_buf_orig[64];
+	char *mode = mode_buf;
+	const void __iomem *mode_base;
 	int depth, ret;
 
 	/* The last 16M of PCI BAR0 is used to store the resolution string. */
-	mode = devm_ioremap(&pdev->dev, pci_resource_start(pdev, 0) + SZ_16M, SZ_16M);
-	if (!mode)
+	mode_base = ioremap(pci_resource_start(pdev, 0) + SZ_16M,
+			    sizeof(mode_buf));
+	if (!mode_base)
 		return -ENOMEM;
+	memcpy_fromio(mode_buf, mode_base, sizeof(mode_buf) - 1);
+	mode_buf[sizeof(mode_buf) - 1] = '\0';
+	iounmap((void __iomem *)mode_base);
+	memcpy(mode_buf_orig, mode_buf, sizeof(mode_buf_orig));
 
-	/* The resolution field starts with the flag "video=". */
+	/* The resolution field is required to start with "video=". */
 	if (!strncmp(mode, "video=", 6))
 		mode = mode + 6;
+	else {
+		ret = -EINVAL;
+		goto invalid_mode;
+	}
 
-	ret = kstrtoint(strsep(&mode, "x"), 10, &pd->width);
+	ret = kstrtouint(strsep(&mode, "x"), 10, &pd->width);
 	if (ret)
-		return ret;
+		goto invalid_mode;
 
-	ret = kstrtoint(strsep(&mode, "-"), 10, &pd->height);
+	if (mode == NULL) {
+		ret = -EINVAL;
+		goto invalid_mode;
+	}
+	ret = kstrtouint(strsep(&mode, "-"), 10, &pd->height);
 	if (ret)
-		return ret;
+		goto invalid_mode;
 
+	if (mode == NULL) {
+		ret = -EINVAL;
+		goto invalid_mode;
+	}
 	ret = kstrtoint(strsep(&mode, "@"), 10, &depth);
 	if (ret)
-		return ret;
+		goto invalid_mode;
+	if (depth <= 0) {
+		ret = -EINVAL;
+		goto invalid_mode;
+	}
+	if (pd->width > U32_MAX / depth) {
+		ret = -EOVERFLOW;
+		goto invalid_mode;
+	}
 
 	pd->stride = pd->width * depth / 8;
 	pd->format = depth == 32 ? "a8r8g8b8" : "r5g6b5";
 
 	return 0;
+
+invalid_mode:
+	dev_err(&pdev->dev, "Invalid resolution string: %*pE\n",
+		(int)strlen(mode_buf_orig), mode_buf_orig);
+	return ret;
 }
 
 static int ls2k_bmc_probe(struct pci_dev *dev, const struct pci_device_id *id)

-- 
2.49.0

[PATCH RFC v8 2/8] mfd: ls2kbmc: Sanity check for the connected pci port

[Miao Wang via B4 Relay]

From: Miao Wang <shankerwangmiao@gmail.com>

When the bmc resets, the recovery procedure require to reconfigure the
parent device. The driver assumes that the parent device should be LS7A.
Add a sanity check on initialization to ensure this and prevent from
accidentally operating on non-LS7A ports.

Fixes: d952bba3fbb5 ("mfd: ls2kbmc: Add Loongson-2K BMC reset function support")
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
 drivers/mfd/ls2k-bmc-core.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c
index 335590392240ba1e13a2bdf6f9f4efddec045f40..434db99ee501be8e18de7258af0f465fc16c0709 100644
--- a/drivers/mfd/ls2k-bmc-core.c
+++ b/drivers/mfd/ls2k-bmc-core.c
@@ -35,6 +35,15 @@
 #define LS2K_IPMI3_RES_START		(LS2K_IPMI2_RES_START + LS2K_IPMI_RES_SIZE)
 #define LS2K_IPMI4_RES_START		(LS2K_IPMI3_RES_START + LS2K_IPMI_RES_SIZE)
 
+/* LS7A port Device IDs */
+#define DEV_LS7A1K_PCIE_PORT0	0x7a09
+#define DEV_LS7A1K_PCIE_PORT1	0x7a19
+#define DEV_LS7A1K_PCIE_PORT2	0x7a29
+#define DEV_LS7A2K_PCIE_PORT0	0x7a39
+#define DEV_LS7A2K_PCIE_PORT1	0x7a49
+#define DEV_LS7A2K_PCIE_PORT2	0x7a59
+#define DEV_LS7A2K_PCIE_PORT3	0x7a69
+
 #define LS7A_PCI_CFG_SIZE		0x100
 
 /* LS7A bridge registers */
@@ -490,6 +499,24 @@ static int ls2k_bmc_parse_mode(struct pci_dev *pdev, struct simplefb_platform_da
 	return ret;
 }
 
+static const struct pci_device_id ls7a_ports[] = {
+	{ PCI_DEVICE(PCI_VENDOR_ID_LOONGSON, DEV_LS7A1K_PCIE_PORT0) },
+	{ PCI_DEVICE(PCI_VENDOR_ID_LOONGSON, DEV_LS7A1K_PCIE_PORT1) },
+	{ PCI_DEVICE(PCI_VENDOR_ID_LOONGSON, DEV_LS7A1K_PCIE_PORT2) },
+	{ PCI_DEVICE(PCI_VENDOR_ID_LOONGSON, DEV_LS7A2K_PCIE_PORT0) },
+	{ PCI_DEVICE(PCI_VENDOR_ID_LOONGSON, DEV_LS7A2K_PCIE_PORT1) },
+	{ PCI_DEVICE(PCI_VENDOR_ID_LOONGSON, DEV_LS7A2K_PCIE_PORT2) },
+	{ PCI_DEVICE(PCI_VENDOR_ID_LOONGSON, DEV_LS7A2K_PCIE_PORT3) },
+	{ }
+};
+
+static bool ls2k_check_parent(struct pci_dev *dev)
+{
+	struct pci_dev *parent = dev->bus->self;
+
+	return parent && pci_match_id(ls7a_ports, parent) != NULL;
+}
+
 static int ls2k_bmc_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
 	struct simplefb_platform_data pd;
@@ -501,6 +528,11 @@ static int ls2k_bmc_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	if (ret)
 		return ret;
 
+	if (!ls2k_check_parent(dev)) {
+		dev_err(&dev->dev, "Expected to be connected to LS7A PCI-E port\n");
+		return -ENODEV;
+	}
+
 	ddata = devm_kzalloc(&dev->dev, sizeof(*ddata), GFP_KERNEL);
 	if (!ddata)
 		return -ENOMEM;

-- 
2.49.0

[PATCH RFC v8 3/8] mfd: ls2kbmc: Redraw using exported functions

[Miao Wang via B4 Relay]

From: Miao Wang <shankerwangmiao@gmail.com>

Use update_screen, i.e. redraw_screen() to trigger the redraw of the
current vt.

Fixes: d952bba3fbb5 ("mfd: ls2kbmc: Add Loongson-2K BMC reset function support")
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
 drivers/mfd/ls2k-bmc-core.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c
index 434db99ee501be8e18de7258af0f465fc16c0709..06ec8143d8cdbe2c8e5a141020d96c21b37fa699 100644
--- a/drivers/mfd/ls2k-bmc-core.c
+++ b/drivers/mfd/ls2k-bmc-core.c
@@ -25,6 +25,7 @@
 #include <linux/platform_device.h>
 #include <linux/stop_machine.h>
 #include <linux/vt_kern.h>
+#include <linux/console.h>
 
 /* LS2K BMC resources */
 #define LS2K_DISPLAY_RES_START		(SZ_16M + SZ_2M)
@@ -310,7 +311,9 @@ static void ls2k_bmc_events_fn(struct work_struct *work)
 
 	if (IS_ENABLED(CONFIG_VT)) {
 		/* Re-push the display due to previous PCI-E loss. */
-		set_console(vt_move_to_console(MAX_NR_CONSOLES - 1, 1));
+		console_lock();
+		update_screen(vc_cons[fg_console].d);
+		console_unlock();
 	}
 }
 

-- 
2.49.0

[PATCH RFC v8 4/8] mfd: ls2kbmc: Cancel the work queue on removal

[Miao Wang via B4 Relay]

From: Miao Wang <shankerwangmiao@gmail.com>

When the device is being removeed, the work queue should be canceled to
avoid any pending work to be executed after the device is removed.

Fixes: d952bba3fbb5 ("mfd: ls2kbmc: Add Loongson-2K BMC reset function support")
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
 drivers/mfd/ls2k-bmc-core.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c
index 06ec8143d8cdbe2c8e5a141020d96c21b37fa699..5eea53f134215456e0c14345ae4ebc5b66bd433d 100644
--- a/drivers/mfd/ls2k-bmc-core.c
+++ b/drivers/mfd/ls2k-bmc-core.c
@@ -375,6 +375,12 @@ static void ls2k_bmc_save_pci_data(struct pci_dev *pdev, struct ls2k_bmc_ddata *
 	pci_read_config_dword(pdev, PCI_INTERRUPT_LINE, &ddata->bmc_pci_data.interrupt_line);
 }
 
+static void ls2k_bmc_cancel_wq(void *data)
+{
+	struct ls2k_bmc_ddata *ddata = data;
+	(void) cancel_work_sync(&ddata->bmc_reset_work);
+}
+
 static int ls2k_bmc_init(struct ls2k_bmc_ddata *ddata)
 {
 	struct pci_dev *pdev = to_pci_dev(ddata->dev);
@@ -385,6 +391,10 @@ static int ls2k_bmc_init(struct ls2k_bmc_ddata *ddata)
 
 	INIT_WORK(&ddata->bmc_reset_work, ls2k_bmc_events_fn);
 
+	ret = devm_add_action_or_reset(ddata->dev, ls2k_bmc_cancel_wq, ddata);
+	if (ret)
+		return ret;
+
 	ret = devm_request_irq(&pdev->dev, pdev->irq, ls2k_bmc_interrupt,
 			       IRQF_SHARED | IRQF_TRIGGER_FALLING, "ls2kbmc pcie", ddata);
 	if (ret) {

-- 
2.49.0

[PATCH RFC v8 5/8] ipmi: ls2k: adjust dependency to its mfd driver

[Miao Wang via B4 Relay]

From: Miao Wang <shankerwangmiao@gmail.com>

There is functional dependency between the IPMI driver and its mfd
driver. Previously, the dependency was set to "select" from
IPMI_LS2K to MFD_LS2K_BMC_CORE. However, the ipmi driver is actually
compiled as a part of the ipmi_si module, and IPMI_LS2K is a bool
option. Therefore, the dependency "select" will force the mfd driver
to be compiled built-in when the ipmi driver is built as a module. This
is not desirable. This patch fixes this by declaring a conditional
dependency from IPMI_SI to MFD_LS2K_BMC_CORE if IPMI_LS2K is selected.
This will allow the mfd driver to be compiled as a module if the ipmi
driver is built as a module. The adjustment to Kconfig for the mfd
driver will be introduced in the later patch in this series.

Fixes: d46651d4e3c0 ("ipmi: Add Loongson-2K BMC support")
Acked-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
 drivers/char/ipmi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index 669f7600019747bcd2b37563477cf336f19a0407..07f3308c71616215871a730b87f1991d2b502e63 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -62,6 +62,7 @@ config IPMI_DEVICE_INTERFACE
 config IPMI_SI
 	tristate 'IPMI System Interface handler'
 	select IPMI_PLAT_DATA
+	select MFD_LS2K_BMC_CORE if IPMI_LS2K
 	help
 	  Provides a driver for System Interfaces (KCS, SMIC, BT).
 	  Currently, only KCS and SMIC are supported.  If
@@ -87,7 +88,6 @@ config IPMI_IPMB
 config IPMI_LS2K
 	bool 'Loongson-2K IPMI interface'
 	depends on LOONGARCH
-	select MFD_LS2K_BMC_CORE
 	help
 	  Provides a driver for Loongson-2K IPMI interfaces.
 

-- 
2.49.0

[PATCH RFC v8 6/8] gpiolib: add gpio_device_get_fwnode() helper

[Miao Wang via B4 Relay]

From: Miao Wang <shankerwangmiao@gmail.com>

Add a helper function to retrieve the fwnode associated with a
struct gpio_device. This is useful for drivers that need to access the
fwnode of a GPIO device for various purposes, such as creating software
nodes or handling GPIOs in a platform-specific manner.

Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
 drivers/gpio/gpiolib.c      | 13 +++++++++++++
 include/linux/gpio/driver.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e5fb60111151f6de20b424551acf213fb058e190..3774ebbbe550cdce0989a2d06f2ab658529c3bab 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1583,6 +1583,19 @@ struct device *gpio_device_to_device(struct gpio_device *gdev)
 }
 EXPORT_SYMBOL_GPL(gpio_device_to_device);
 
+/**
+ * gpio_device_get_fwnode() - Retrieve the fwnode of the underlying device.
+ * @gdev: GPIO device for which to return the fwnode.
+ *
+ * Returns:
+ * The fwnode handle of the underlying device.
+ */
+struct fwnode_handle *gpio_device_get_fwnode(struct gpio_device *gdev)
+{
+	return dev_fwnode(gpio_device_to_device(gdev));
+}
+EXPORT_SYMBOL_GPL(gpio_device_get_fwnode);
+
 #ifdef CONFIG_GPIOLIB_IRQCHIP
 
 /*
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 17511434ed077dde8807bd7630c342e146e5230b..4dd9120707ec72a978f5f916cc5473a91b65d2b9 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -641,6 +641,7 @@ DEFINE_FREE(gpio_device_put, struct gpio_device *,
 	    if (!IS_ERR_OR_NULL(_T)) gpio_device_put(_T))
 
 struct device *gpio_device_to_device(struct gpio_device *gdev);
+struct fwnode_handle *gpio_device_get_fwnode(struct gpio_device *gdev);
 
 bool gpiochip_line_is_irq(struct gpio_chip *gc, unsigned int offset);
 int gpiochip_reqres_irq(struct gpio_chip *gc, unsigned int offset);

-- 
2.49.0

[PATCH RFC v8 7/8] mfd: ls2kbmc: Capture the reset event of BMC through GPIO

[Miao Wang via B4 Relay]

From: Miao Wang <shankerwangmiao@gmail.com>

The reset event of BMC is captured through GPIO. However, this driver
bypasses the GPIO framework and directly accesses the GPIO controller
through the fixed address. When the same GPIO controller is also
exposed through ACPI and probed by the corresponding GPIO driver,
there would be a conflict between the two drivers.

This patch will try to find the GPIO through declared GPIO pin in the
_CRS resources of the ACPI node. If no such delaration is found, the
driver will fall back to search for the correct GPIO controller and pin
according to the fixed address and pin number. A possible DSDT
declaration for the GPIO pin might be as follows:

    Device (BMC0) {
        Name (_ADR, ...) // Match the PCI address of the BMC device
        // \_SB.GPO1 is the ACPI path of the GPIO controller
        Name (_CRS, ResourceTemplate () {
            GpioInt (Edge, ActiveLow, Exclusive, PullNone, 0,
                     "\\_SB.GPO1", 0) {
                14 // 14 is the GPIO pin number
            }
    }

Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
 drivers/mfd/ls2k-bmc-core.c | 149 ++++++++++++++++++++++++++++++--------------
 1 file changed, 102 insertions(+), 47 deletions(-)

diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c
index 5eea53f134215456e0c14345ae4ebc5b66bd433d..f52f0b772f6e9398164ea6c9b9d878b76b075139 100644
--- a/drivers/mfd/ls2k-bmc-core.c
+++ b/drivers/mfd/ls2k-bmc-core.c
@@ -26,6 +26,10 @@
 #include <linux/stop_machine.h>
 #include <linux/vt_kern.h>
 #include <linux/console.h>
+#include <linux/gpio/consumer.h>
+#include <linux/gpio/driver.h>
+#include <linux/gpio/property.h>
+#include <linux/gpio/machine.h>
 
 /* LS2K BMC resources */
 #define LS2K_DISPLAY_RES_START		(SZ_16M + SZ_2M)
@@ -81,18 +85,6 @@
 
 #define PCI_REG_STRIDE			0x4
 
-#define LS2K_BMC_RESET_GPIO		14
-#define LOONGSON_GPIO_REG_BASE		0x1FE00500
-#define LOONGSON_GPIO_REG_SIZE		0x18
-#define LOONGSON_GPIO_OEN		0x0
-#define LOONGSON_GPIO_FUNC		0x4
-#define LOONGSON_GPIO_INTPOL		0x10
-#define LOONGSON_GPIO_INTEN		0x14
-
-#define LOONGSON_IO_INT_BASE		16
-#define LS2K_BMC_RESET_GPIO_INT_VEC	(LS2K_BMC_RESET_GPIO % 8)
-#define LS2K_BMC_RESET_GPIO_GSI		(LOONGSON_IO_INT_BASE + LS2K_BMC_RESET_GPIO_INT_VEC)
-
 enum {
 	LS2K_BMC_DISPLAY,
 	LS2K_BMC_IPMI0,
@@ -186,6 +178,7 @@ struct ls2k_bmc_ddata {
 	struct work_struct bmc_reset_work;
 	struct ls2k_bmc_pci_data bmc_pci_data;
 	struct ls2k_bmc_bridge_pci_data bridge_pci_data;
+	struct gpio_desc *reset_gpio;
 };
 
 static bool ls2k_bmc_bar0_addr_is_set(struct pci_dev *pdev)
@@ -375,6 +368,82 @@ static void ls2k_bmc_save_pci_data(struct pci_dev *pdev, struct ls2k_bmc_ddata *
 	pci_read_config_dword(pdev, PCI_INTERRUPT_LINE, &ddata->bmc_pci_data.interrupt_line);
 }
 
+static int ls2k_bmc_gpiochip_find(struct gpio_chip *gc, const void *data)
+{
+	struct acpi_device *adev;
+	struct list_head resource_list;
+	struct resource_entry *rentry;
+	struct fwnode_handle *fwnode = gpio_device_get_fwnode(gc->gpiodev);
+	phys_addr_t start_addr = (phys_addr_t) data;
+	int ret, found = 0;
+
+	if (!is_acpi_node(fwnode))
+		goto out;
+
+	adev = to_acpi_device_node(fwnode);
+	if (!adev)
+		goto out;
+
+	INIT_LIST_HEAD(&resource_list);
+
+	ret = acpi_dev_get_memory_resources(adev, &resource_list);
+	if (ret < 0)
+		goto out;
+	/*
+	 * ACPI memory resources are ordered and only the first one is
+	 * considered by the driver of the expected GPIO controller. So
+	 * here we also only check the first one to see if it matches the
+	 * expected address.
+	 */
+	rentry = list_first_entry_or_null(&resource_list, struct resource_entry, node);
+	if (!rentry)
+		goto free_resource_list;
+	if (rentry->res->start == start_addr)
+		found = 1;
+
+free_resource_list:
+	acpi_dev_free_resource_list(&resource_list);
+out:
+	return found;
+}
+
+static struct gpio_desc *ls2k_bmc_find_gpio(struct ls2k_bmc_ddata *ddata)
+{
+	/*
+	 * In conventional way, the GPIO should be obtained through ACPI or
+	 * device tree. However, when the information is not available,
+	 * we should find the GPIO according to the convention of the server
+	 * boards with LS2K BMC, the gpio signal reflecting the reset event
+	 * of the BMC should be connected to pin 14 of the GPIO input of
+	 * the first CPU node. The address of that GPIO controller is fixed.
+	 */
+	static const phys_addr_t LOONGSON_GPIO_REG_BASE = 0x1FE00500;
+	static const unsigned int LS2K_BMC_RESET_GPIO = 14;
+	int ret;
+	struct property_entry ls2k_bmc_swnode_properties[2] = { };
+
+	dev_dbg(ddata->dev, "Searching for GPIO chip at address %pa\n", &LOONGSON_GPIO_REG_BASE);
+	struct gpio_device *gdev __free(gpio_device_put) =
+		gpio_device_find((void *)LOONGSON_GPIO_REG_BASE, ls2k_bmc_gpiochip_find);
+
+	if (!gdev) {
+		dev_dbg(ddata->dev, "cannot find GPIO chip at address %pa, deferring\n",
+			&LOONGSON_GPIO_REG_BASE);
+		return ERR_PTR(-EPROBE_DEFER);
+	}
+
+	ls2k_bmc_swnode_properties[0] = PROPERTY_ENTRY_GPIO("gpio",
+		gpio_device_get_fwnode(gdev), LS2K_BMC_RESET_GPIO, GPIO_ACTIVE_HIGH);
+
+	ret = device_create_managed_software_node(ddata->dev, ls2k_bmc_swnode_properties, NULL);
+	if (ret) {
+		return ERR_PTR(dev_err_probe(ddata->dev, ret,
+					     "Failed to create software node for GPIO reset\n"));
+	}
+
+	return devm_gpiod_get_index(ddata->dev, NULL, 0, GPIOD_IN);
+}
+
 static void ls2k_bmc_cancel_wq(void *data)
 {
 	struct ls2k_bmc_ddata *ddata = data;
@@ -384,8 +453,7 @@ static void ls2k_bmc_cancel_wq(void *data)
 static int ls2k_bmc_init(struct ls2k_bmc_ddata *ddata)
 {
 	struct pci_dev *pdev = to_pci_dev(ddata->dev);
-	void __iomem *gpio_base;
-	int gpio_irq, ret, val;
+	int gpio_irq, ret;
 
 	ls2k_bmc_save_pci_data(pdev, ddata);
 
@@ -402,44 +470,31 @@ static int ls2k_bmc_init(struct ls2k_bmc_ddata *ddata)
 		return ret;
 	}
 
-	gpio_base = ioremap(LOONGSON_GPIO_REG_BASE, LOONGSON_GPIO_REG_SIZE);
-	if (!gpio_base)
-		return -ENOMEM;
-
-	/* Disable GPIO output */
-	val = readl(gpio_base + LOONGSON_GPIO_OEN);
-	writel(val | BIT(LS2K_BMC_RESET_GPIO), gpio_base + LOONGSON_GPIO_OEN);
-
-	/* Enable GPIO functionality */
-	val = readl(gpio_base + LOONGSON_GPIO_FUNC);
-	writel(val & ~BIT(LS2K_BMC_RESET_GPIO), gpio_base + LOONGSON_GPIO_FUNC);
-
-	/* Set GPIO interrupts to low-level active */
-	val = readl(gpio_base + LOONGSON_GPIO_INTPOL);
-	writel(val & ~BIT(LS2K_BMC_RESET_GPIO), gpio_base + LOONGSON_GPIO_INTPOL);
-
-	/* Enable GPIO interrupts */
-	val = readl(gpio_base + LOONGSON_GPIO_INTEN);
-	writel(val | BIT(LS2K_BMC_RESET_GPIO), gpio_base + LOONGSON_GPIO_INTEN);
+	ddata->reset_gpio = devm_gpiod_get_index_optional(&pdev->dev, NULL, 0, GPIOD_IN);
+	if (IS_ERR(ddata->reset_gpio))
+		return dev_err_probe(ddata->dev, PTR_ERR(ddata->reset_gpio),
+				     "Failed to get GPIO pin for reset signal\n");
+	if (ddata->reset_gpio == NULL) {
+		ddata->reset_gpio = ls2k_bmc_find_gpio(ddata);
+		if (IS_ERR(ddata->reset_gpio))
+			return dev_err_probe(ddata->dev, PTR_ERR(ddata->reset_gpio),
+					     "Failed to find GPIO pin for reset signal\n");
+	}
 
-	iounmap(gpio_base);
+	gpio_irq = gpiod_to_irq(ddata->reset_gpio);
 
-	/*
-	 * Since gpio_chip->to_irq is not implemented in the Loongson-3 GPIO driver,
-	 * acpi_register_gsi() is used to obtain the GPIO IRQ. The GPIO interrupt is a
-	 * watchdog interrupt that is triggered when the BMC resets.
-	 */
-	gpio_irq = acpi_register_gsi(NULL, LS2K_BMC_RESET_GPIO_GSI, ACPI_EDGE_SENSITIVE,
-				     ACPI_ACTIVE_LOW);
 	if (gpio_irq < 0)
-		return gpio_irq;
+		return dev_err_probe(ddata->dev, gpio_irq,
+				     "Failed to get IRQ for GPIO reset signal input\n");
 
-	ret = devm_request_irq(ddata->dev, gpio_irq, ls2k_bmc_interrupt,
-			       IRQF_SHARED | IRQF_TRIGGER_FALLING, "ls2kbmc gpio", ddata);
-	if (ret)
-		dev_err(ddata->dev, "Failed to request LS2KBMC GPIO IRQ %d.\n", gpio_irq);
+	ret = devm_request_irq(&pdev->dev, gpio_irq, ls2k_bmc_interrupt,
+			       IRQF_SHARED | IRQF_TRIGGER_FALLING, "ls2kbmc reset", ddata);
+
+	if (ret != 0)
+		return dev_err_probe(ddata->dev, ret,
+				     "Failed to request IRQ %d for GPIO reset signal input.\n",
+				     gpio_irq);
 
-	acpi_unregister_gsi(LS2K_BMC_RESET_GPIO_GSI);
 	return ret;
 }
 

-- 
2.49.0

[PATCH RFC v8 8/8] mfd: ls2kbmc: Able to be compiled as a module

[Miao Wang via B4 Relay]

From: Miao Wang <shankerwangmiao@gmail.com>

Make ls2kbmc able to be compiled as a module

Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
 drivers/mfd/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 763ce6a34782bdd5d2b1a4d840c75b040092d83e..a7a9f97af248c88489dc1203a1ba05f2ce4827df 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2494,7 +2494,7 @@ config MFD_LOONGSON_SE
 	  which will forward them to the corresponding engine.
 
 config MFD_LS2K_BMC_CORE
-	bool "Loongson-2K Board Management Controller Support"
+	tristate "Loongson-2K Board Management Controller Support"
 	depends on PCI && ACPI_GENERIC_GSI
 	select MFD_CORE
 	help

-- 
2.49.0

Re: [PATCH RFC v8 0/8] mfd: ls2kbmc: multiple fixes for this driver

[Bartosz Golaszewski]

On Mon, Aug 10, 2026 at 3:04 PM Miao Wang via B4 Relay
<devnull+shankerwangmiao.gmail.com@kernel.org> wrote:
>
> Previously, the driver has been introduced to support the Loongson 2K
> BMC running on the Loongson Servers, which is essential to prevent
> the system from hanging when the BMC is being reset and the default
> efi-framebuffer is being used. However, there are some drawbacks in the
> driver.
>
> Firstly, the driver tries to read and write to the connected PCI-E host
> controller registers, assuming that the BMC is connected to LS7A PCI-E
> host controller. This assumption should be true for real products, but
> to prevent from accidentally reading and writing to the wrong PCI-E host
> controller, this driver should be modified to check this before
> accessing the registers.
>
> Secondly, the driver uses non-exported functions to tell the vt
> subsystem to redraw the screen, preventing the driver from being
> compiling as a module. This can be fixed by using the exported
> functions instead.
>
> Thirdly, the driver directly accesses the GPIO controller registers
> using hard-coded addresses, which might conflict with the loaded GPIO
> controller driver for the same GPIO controller. This is fixed in this
> series by using the GPIO subsystem APIs instead. To associate a GPIO pin
> with a certian PCI device, it should be declared in the firmware level,
> i.e. in the ACPI table or the device tree, and thus the firmware
> interface should be discussed and coordinated with Loongson personnels.
> Despite of this, the proposed solution in this series should be the
> minimum necessary change to express such association. Furthermore, the
> conventional GPIO pin number and the controller address are also
> provided, to be used as a fallback when the GPIO pin is not declared.
>
> Finally, there is a minor issue in the driver where it changes the
> mode string describing the screen resolution during probing, which
> prevents the device from being probed again if -EPROBE_DEFER is
> returned by the probe function.
>
> I have tested the changes in this series on a single-socket Loongson
> 3C6000 server with a Loongson 2K BMC, and the driver works as expected
> when the corresponding GPIO driver is additionally loaded.
>
> Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
> ---
> Changes in v8:
> - Address issues found by the Sashiko AI review bot
>   - Fix the error path of the probe function, preventing unintentionally
>     returning 0 on failure
>   - Reorder the patches in the series to make the change to the Kconfig
>     entry for ls2kbmc to be the last patch, to satisfy the AI bot's
>     concern on failure to clean up when the driver is built as a module
>     and is being removed.
> - Link to v7: https://lore.kernel.org/r/20260810-ls2kbmc-mod-v7-0-8aa0fb5a5462@gmail.com
>

Don't send several versions of the same big series within minutes of
each other. Give reviewers time to respond.

Bart

Re: [PATCH RFC v8 1/8] mfd: ls2kbmc: Make a copy when parsing mode string

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] The global `ls2k_bmc_cells` array is mutated during probe to pass a pointer to a stack-allocated variable (`&pd`), causing an MFD subsystem violation and a stack use-after-free race condition.
- [High] Missing bounds check in `ls2k_bmc_parse_mode` allows the calculated framebuffer size to exceed the fixed 4MB hardware resource.
- [High] The interrupt handler uses a `static unsigned long last_jiffies` for rate-limiting, sharing state across all devices and breaking interrupts for the first 5 minutes of system uptime due to integer underflow.
- [High] The `ls2k_bmc_init` function unconditionally calls `acpi_unregister_gsi()` on the success path, leading to an IRQ mapping use-after-free and silencing hardware interrupts.
--

--- Patch [1]: [PATCH RFC v8 1/8] mfd: ls2kbmc: Make a copy when parsing mode string ---
commit bb986d2e7f482a92c234ff015a64e640a621dc2d
Author: Miao Wang <shankerwangmiao@gmail.com>

mfd: ls2kbmc: Make a copy when parsing mode string

When parsing the mode string from BMC, the string is manipulated
in-place with strsep(), preventing from parsing it again. Make a copy of
the original string and manipulate the copy instead to fix this.

> diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c
> index 408056bfb2fe7..335590392240b 100644
> --- a/drivers/mfd/ls2k-bmc-core.c
> +++ b/drivers/mfd/ls2k-bmc-core.c
[ ... ]
> @@ -427,34 +427,67 @@ static int ls2k_bmc_init(struct ls2k_bmc_ddata *ddata)
>   */
>  static int ls2k_bmc_parse_mode(struct pci_dev *pdev, struct simplefb_platform_data *pd)
>  {
[ ... ]
> +	if (depth <= 0) {
> +		ret = -EINVAL;
> +		goto invalid_mode;
> +	}
> +	if (pd->width > U32_MAX / depth) {
> +		ret = -EOVERFLOW;
> +		goto invalid_mode;
> +	}
>  
>  	pd->stride = pd->width * depth / 8;
>  	pd->format = depth == 32 ? "a8r8g8b8" : "r5g6b5";

[Severity: High]
This is a pre-existing issue, but is there a missing bounds check against
the maximum framebuffer size?

The framebuffer resource ls2k_display_resources is statically defined with
a size of SZ_4M. While the code checks for integer overflow of width * depth,
could a compromised or misconfigured BMC provide a mode string that results
in a stride * height exceeding the 4MB limit?

If simple-framebuffer maps this region restricted to 4MB, fbcon might rely
on this geometry and attempt out-of-bounds writes beyond the 4MB ioremap
boundary, which could trigger a page fault and panic.

[ ... ]

While reviewing this file, I also noticed a few other pre-existing issues
outside of the modified lines:

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_probe() {
    ...
    ls2k_bmc_cells[LS2K_BMC_DISPLAY].platform_data = &pd;
    ls2k_bmc_cells[LS2K_BMC_DISPLAY].pdata_size = sizeof(pd);
    ...
}

[Severity: High]
This isn't a bug introduced by this patch, but does the global
ls2k_bmc_cells array have a race condition during probe?

Mutating a shared static global array during probe causes data races if
multiple devices are probed concurrently.

Also, storing a pointer to a local stack variable (pd) in a global array
means a concurrent probe could dereference a dangling stack pointer. The MFD
subsystem requires cell arrays to be static const to prevent this.


drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_interrupt() {
    static unsigned long last_jiffies;
    ...
    if (system_state != SYSTEM_RUNNING)
        return IRQ_HANDLED;

    /* Skip interrupt in LS2K_BMC_INT_INTERVAL */
    if (time_after(jiffies, last_jiffies + LS2K_BMC_INT_INTERVAL)) {
        ...
    }
}

[Severity: High]
This is a pre-existing issue, but does the interrupt rate-limiting logic
fail during early boot?

Using a static variable inside an ISR incorrectly shares the debounce state
across all instances of the device.

Additionally, last_jiffies implicitly initializes to 0. Since the system
jiffies counter starts at a large negative value during early boot,
time_after() will evaluate to false until jiffies wraps around past 0.

Could this cause BMC reset interrupts to be completely ignored for the first
5 minutes of system uptime?


drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_init() {
    ...
    ret = devm_request_irq(ddata->dev, gpio_irq, ls2k_bmc_interrupt,
                           IRQF_SHARED | IRQF_TRIGGER_FALLING,
                           "ls2kbmc gpio", ddata);
    if (ret)
        dev_err(ddata->dev, "Failed to request LS2KBMC GPIO IRQ %d.\n",
                gpio_irq);

    acpi_unregister_gsi(LS2K_BMC_RESET_GPIO_GSI);
    return ret;
}

[Severity: High]
This is a pre-existing issue, but does ls2k_bmc_init() accidentally destroy
the active IRQ mapping on the success path?

Calling acpi_unregister_gsi() on the success path disposes of the mapping
between the hardware GSI and the assigned Linux IRQ number.

Since the domain mapping is destroyed, will the interrupt controller fail
to deliver interrupts to the driver, breaking the BMC reset functionality?

Furthermore, when the device is removed, the managed IRQ framework will
attempt to free the disposed IRQ mapping, which could lead to use-after-free
warnings in the irqdomain code.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-ls2kbmc-mod-v8-0-16e44f7322f4@gmail.com?part=1

Re: [PATCH RFC v8 0/8] mfd: ls2kbmc: multiple fixes for this driver

[Miao Wang]

Hi,

> 2026年8月10日 21:08，Bartosz Golaszewski <brgl@kernel.org> 写道：
> 
> On Mon, Aug 10, 2026 at 3:04 PM Miao Wang via B4 Relay
> <devnull+shankerwangmiao.gmail.com@kernel.org> wrote:
>> 
>> ---
>> Changes in v8:
>> - Address issues found by the Sashiko AI review bot
>>  - Fix the error path of the probe function, preventing unintentionally
>>    returning 0 on failure
>>  - Reorder the patches in the series to make the change to the Kconfig
>>    entry for ls2kbmc to be the last patch, to satisfy the AI bot's
>>    concern on failure to clean up when the driver is built as a module
>>    and is being removed.
>> - Link to v7: https://lore.kernel.org/r/20260810-ls2kbmc-mod-v7-0-8aa0fb5a5462@gmail.com
>> 
> 
> Don't send several versions of the same big series within minutes of
> each other. Give reviewers time to respond.

Sorry for bothering the maintainers. A reviewer previously required
a clean or justified Sashiko pass first before reviewing and thus I
have to fix the high issues found by the bot. I would be nice if I
can privately send patches to the bot and let it review before I
send it publicly, to reduce the disturbance to other maintainers.
I tried to run that bot locally but failed because the bot was
consuming too many tokens before generating a final result.

Cheers,

Miao Wang

Re: [PATCH RFC v8 2/8] mfd: ls2kbmc: Sanity check for the connected pci port

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

Pre-existing issues:
- [Critical] System stall for 10+ seconds with interrupts disabled due to `stop_machine` delay.
- [Critical] Unconditional remapping of hardcoded physical address allows arbitrary physical memory corruption.
- [High] Dynamic mutation of global static MFD cell array leaving a dangling pointer.
- [High] GPIO GSI mapping is unconditionally destroyed immediately after being successfully requested.
- [Medium] Flawed rate limiting logic ignores interrupts for the first 5 minutes of system uptime and incorrectly shares state.
--

--- Patch [2]: [PATCH RFC v8 2/8] mfd: ls2kbmc: Sanity check for the connected pci port ---
commit 9113421fc798a2bad757ae8e5bd2b98d1ed9d8bb
Author: Miao Wang <shankerwangmiao@gmail.com>

mfd: ls2kbmc: Sanity check for the connected pci port

When the bmc resets, the recovery procedure require to reconfigure the
parent device. The driver assumes that the parent device should be LS7A.
Add a sanity check on initialization to ensure this and prevent from
accidentally operating on non-LS7A ports.

> diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c
> index 335590392240b..434db99ee501b 100644
> --- a/drivers/mfd/ls2k-bmc-core.c
> +++ b/drivers/mfd/ls2k-bmc-core.c
> @@ -35,6 +35,15 @@
>  #define LS2K_IPMI3_RES_START		(LS2K_IPMI2_RES_START + LS2K_IPMI_RES_SIZE)
>  #define LS2K_IPMI4_RES_START		(LS2K_IPMI3_RES_START + LS2K_IPMI_RES_SIZE)
>  
> +/* LS7A port Device IDs */
> +#define DEV_LS7A1K_PCIE_PORT0	0x7a09
> +#define DEV_LS7A1K_PCIE_PORT1	0x7a19
> +#define DEV_LS7A1K_PCIE_PORT2	0x7a29
> +#define DEV_LS7A2K_PCIE_PORT0	0x7a39
> +#define DEV_LS7A2K_PCIE_PORT1	0x7a49
> +#define DEV_LS7A2K_PCIE_PORT2	0x7a59
> +#define DEV_LS7A2K_PCIE_PORT3	0x7a69
> +
>  #define LS7A_PCI_CFG_SIZE		0x100
>  
>  /* LS7A bridge registers */

[ ... ]

> @@ -501,6 +528,11 @@ static int ls2k_bmc_probe(struct pci_dev *dev, const struct pci_device_id *id)
>  	if (ret)
>  		return ret;
>  
> +	if (!ls2k_check_parent(dev)) {
> +		dev_err(&dev->dev, "Expected to be connected to LS7A PCI-E port\n");
> +		return -ENODEV;
> +	}
> +
>  	ddata = devm_kzalloc(&dev->dev, sizeof(*ddata), GFP_KERNEL);
>  	if (!ddata)
>  		return -ENOMEM;

[Severity: High]
This isn't a bug introduced by this patch, but looking at ls2k_bmc_probe()
further down, is it safe to assign a local stack variable to the global
MFD cell array?

ls2k_bmc_probe() {
...
    struct simplefb_platform_data pd;
...
    ls2k_bmc_cells[LS2K_BMC_DISPLAY].platform_data = &pd;
...
}

This leaves a dangling pointer in the global ls2k_bmc_cells array when the
function returns. Additionally, the ls2k_bmc_cells array is dynamically
mutated but not defined as static const, which violates MFD subsystem
guidelines. Can this cause memory corruption if the pointer is reused or
if multiple devices are probed?

[Severity: Critical]
This is a pre-existing issue, but I noticed a potentially severe stall in
the reset recovery path. Does this code stall the system with interrupts
disabled for over 10 seconds?

ls2k_bmc_events_fn() {
...
    stop_machine(ls2k_bmc_recover_pci_data, ddata, NULL);
...
}

Inside the callback:

ls2k_bmc_recover_pci_data() {
...
    mdelay(LS2K_BMC_RESET_WAIT_TIME);
...
}

Since stop_machine() halts all CPUs with local interrupts disabled, wouldn't
a 10-second delay (10,000 ms) trigger NMI hard lockups, RCU stalls, and
system watchdog resets?

[Severity: Critical]
This isn't a bug introduced by this patch, but is it safe to hardcode and
unconditionally map a physical address during initialization?

ls2k_bmc_init() {
...
    gpio_base = ioremap(LOONGSON_GPIO_REG_BASE, LOONGSON_GPIO_REG_SIZE);
...
}

Where LOONGSON_GPIO_REG_BASE is 0x1FE00500. Even with the new PCI ID check,
could an attacker with a spoofed PCIe device trigger this init function
and overwrite host physical memory at this hardcoded address?

[Severity: High]
This is a pre-existing issue, but does this cleanup logic incorrectly destroy
the GSI mapping on the probe success path?

ls2k_bmc_init() {
...
    gpio_irq = acpi_register_gsi(NULL, LS2K_BMC_RESET_GPIO_GSI, ...);
...
    ret = devm_request_irq(ddata->dev, gpio_irq, ls2k_bmc_interrupt, ...);
...
    acpi_unregister_gsi(LS2K_BMC_RESET_GPIO_GSI);
    return ret;
}

Since acpi_unregister_gsi() is called unconditionally, won't this silence
the GPIO interrupt entirely even when initialization succeeds?

[Severity: Medium]
This isn't a bug introduced by this patch, but could this rate limiting logic
ignore interrupts for the first 5 minutes of system uptime?

ls2k_bmc_interrupt() {
...
    static unsigned long last_jiffies;
...
    if (time_after(jiffies, last_jiffies + LS2K_BMC_INT_INTERVAL)) {
        schedule_work(&ddata->bmc_reset_work);
        last_jiffies = jiffies;
    }
...
}

Since last_jiffies is initialized to 0, and jiffies initializes to -300*HZ,
time_after() will evaluate to false for the first ~5 minutes. Also, does
using a static variable incorrectly share this state across all potential
device instances?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-ls2kbmc-mod-v8-0-16e44f7322f4@gmail.com?part=2

Re: [PATCH RFC v8 3/8] mfd: ls2kbmc: Redraw using exported functions

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] System lockup due to 10-second busy-wait inside stop_machine() context.
- [High] MFD subsystem API violation leading to a data race and dangling pointer on a global cell array.
- [High] Use-After-Free of device data due to missing workqueue cleanup on device removal or probe failure.
- [High] Unbalanced resource lifecycle completely breaks the GPIO interrupt delivery.
--

--- Patch [3]: [PATCH RFC v8 3/8] mfd: ls2kbmc: Redraw using exported functions ---
commit 1bc6218749af861d9fbbf175e51a2eba62372b2b
Author: Miao Wang <shankerwangmiao@gmail.com>

mfd: ls2kbmc: Redraw using exported functions

This commit updates the ls2kbmc driver to trigger the redraw of the current
vt using update_screen() inside console_lock() instead of set_console().

> diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c
> index 434db99ee501b..06ec8143d8cdb 100644
> --- a/drivers/mfd/ls2k-bmc-core.c
> +++ b/drivers/mfd/ls2k-bmc-core.c

[ ... ]

> @@ -310,7 +311,9 @@ static void ls2k_bmc_events_fn(struct work_struct *work)
>  
>  	if (IS_ENABLED(CONFIG_VT)) {
>  		/* Re-push the display due to previous PCI-E loss. */
> -		set_console(vt_move_to_console(MAX_NR_CONSOLES - 1, 1));
> +		console_lock();
> +		update_screen(vc_cons[fg_console].d);
> +		console_unlock();

[Severity: High]
This is a pre-existing issue, but can this function trigger a system lockup?

The BMC reset event schedules bmc_reset_work, which executes this
ls2k_bmc_events_fn() function. Right above this diff context, the function
calls stop_machine() to suspend all CPUs with local interrupts disabled:

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_events_fn() {
        ...
        stop_machine(ls2k_bmc_recover_pci_data, ddata, NULL);
        ...
}

Inside ls2k_bmc_recover_pci_data(), the code busy-waits for 10 seconds:

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_recover_pci_data() {
        ...
        /* Waiting for U-Boot and DDR ready */
        mdelay(LS2K_BMC_RESET_WAIT_TIME);
        ...
}

Since stop_machine() runs with interrupts disabled across all CPUs, does
spinning for 10,000 milliseconds here inevitably cause the hard and soft
lockup watchdogs to fire and crash the system?

[Severity: High]
This is a pre-existing issue, but does this driver leave a dangling pointer
in the global cell array during probe?

In ls2k_bmc_probe(), the code assigns the address of a local stack variable
to the global ls2k_bmc_cells array:

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_probe() {
        ...
        ls2k_bmc_cells[LS2K_BMC_DISPLAY].platform_data = &pd;
        ls2k_bmc_cells[LS2K_BMC_DISPLAY].pdata_size = sizeof(pd);
        ...
}

While devm_mfd_add_devices() clones the data during registration, the
global array itself is improperly defined as mutable state rather than
static const:

drivers/mfd/ls2k-bmc-core.c {
        ...
        static struct mfd_cell ls2k_bmc_cells[] = {
        ...
}

Since the global array retains the pointer to the destroyed stack frame
after the probe returns, could this result in a data race on the global
array and potential use of stack memory if multiple instances probe
concurrently or if the device is re-probed?

[Severity: High]
This is a pre-existing issue, but is there a use-after-free vulnerability
if the device is removed or if probe fails?

In ls2k_bmc_init(), the driver initializes a workqueue on a devm-managed
structure and registers an interrupt:

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_init() {
        ...
        INIT_WORK(&ddata->bmc_reset_work, ls2k_bmc_events_fn);
        ...
}

However, the driver lacks a .remove callback and does not register a devm
action to cancel the work:

drivers/mfd/ls2k-bmc-core.c {
        ...
        static struct pci_driver ls2k_bmc_driver = {
                .name = "ls2k-bmc",
                .id_table = ls2k_bmc_devices,
                .probe = ls2k_bmc_probe,
        };
        ...
}

If the driver is unbound, the devm framework will automatically free ddata.
If the shared interrupt fired and scheduled the work before teardown, could
it execute and dereference the freed ddata inside ls2k_bmc_events_fn()?

[Severity: High]
This is a pre-existing issue, but does the initialization logic break the
GPIO interrupt delivery?

In ls2k_bmc_init(), immediately following a successful IRQ registration,
the code unconditionally tears down the GSI mapping:

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_init() {
        ...
        acpi_unregister_gsi(LS2K_BMC_RESET_GPIO_GSI);
        return ret;
}

Because acpi_unregister_gsi() invokes irq_dispose_mapping() and destroys
the hardware-to-Linux IRQ mapping while the IRQ is still registered,
doesn't this prevent the interrupt from ever firing?

>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-ls2kbmc-mod-v8-0-16e44f7322f4@gmail.com?part=3

Re: [PATCH RFC v8 4/8] mfd: ls2kbmc: Cancel the work queue on removal

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

Pre-existing issues:
- [Critical] A 10-second busy-wait delay and sleepable PCI mapping functions are executed within a `stop_machine()` context, causing system lockups.
- [Critical] The shared PCI interrupt handler blindly schedules the BMC reset recovery work without verifying the interrupt source, causing spurious 10-second system stalls on any shared IRQ.
- [High] The global `ls2k_bmc_cells` MFD array is dynamically mutated with a stack pointer, violating subsystem rules and causing memory safety hazards.
- [High] The GSI mapping for the GPIO watchdog interrupt is unconditionally destroyed immediately after being requested, breaking the interrupt.
- [High] A static zero-initialized variable for rate limiting causes legitimate interrupts to be permanently ignored during the first 6 minutes of uptime.
--

--- Patch [4]: [PATCH RFC v8 4/8] mfd: ls2kbmc: Cancel the work queue on removal ---
commit ac625d16d31c097a08a5eeba96a345ec9e2f3716
Author: Miao Wang <shankerwangmiao@gmail.com>

mfd: ls2kbmc: Cancel the work queue on removal

This commit adds a devm action to cancel the bmc_reset_work when the
device is removed. This prevents pending work from executing after the
device has been unbound.

> diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c
> index 06ec8143d8cdb..5eea53f134215 100644
> --- a/drivers/mfd/ls2k-bmc-core.c
> +++ b/drivers/mfd/ls2k-bmc-core.c
> @@ -375,6 +375,12 @@ static void ls2k_bmc_save_pci_data(struct pci_dev *pdev, struct ls2k_bmc_ddata *
>  	pci_read_config_dword(pdev, PCI_INTERRUPT_LINE, &ddata->bmc_pci_data.interrupt_line);
>  }
>  
> +static void ls2k_bmc_cancel_wq(void *data)
> +{
> +	struct ls2k_bmc_ddata *ddata = data;
> +	(void) cancel_work_sync(&ddata->bmc_reset_work);
> +}
> +
>  static int ls2k_bmc_init(struct ls2k_bmc_ddata *ddata)
>  {
>  	struct pci_dev *pdev = to_pci_dev(ddata->dev);
> @@ -385,6 +391,10 @@ static int ls2k_bmc_init(struct ls2k_bmc_ddata *ddata)
>  
>  	INIT_WORK(&ddata->bmc_reset_work, ls2k_bmc_events_fn);
>  
> +	ret = devm_add_action_or_reset(ddata->dev, ls2k_bmc_cancel_wq, ddata);
> +	if (ret)
> +		return ret;
> +
>  	ret = devm_request_irq(&pdev->dev, pdev->irq, ls2k_bmc_interrupt,
>  			       IRQF_SHARED | IRQF_TRIGGER_FALLING, "ls2kbmc pcie", ddata);
>  	if (ret) {

[Severity: High]
This is a pre-existing issue, but the GSI mapping for the GPIO watchdog
interrupt is unconditionally destroyed immediately after being requested:

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_init() {
    ...
    gpio_irq = acpi_register_gsi(NULL, LS2K_BMC_RESET_GPIO_GSI, ACPI_EDGE_SENSITIVE,
                                 ACPI_ACTIVE_LOW);
    ...
    ret = devm_request_irq(ddata->dev, gpio_irq, ls2k_bmc_interrupt,
                           IRQF_SHARED | IRQF_TRIGGER_FALLING, "ls2kbmc gpio", ddata);
    ...
    acpi_unregister_gsi(LS2K_BMC_RESET_GPIO_GSI);
    return ret;
}

Since this executes irq_dispose_mapping(), won't this cause the registered
handler to never trigger and potentially lead to a use-after-free or corrupted
interrupts on removal?

[Severity: Critical]
This is a pre-existing issue, but does the shared PCI interrupt handler
blindly schedule the BMC reset recovery work without verifying the interrupt
source?

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_interrupt() {
    ...
    if (time_after(jiffies, last_jiffies + LS2K_BMC_INT_INTERVAL)) {
        schedule_work(&ddata->bmc_reset_work);
        last_jiffies = jiffies;
    }

    return IRQ_HANDLED;
}

Since the PCI IRQ is requested with IRQF_SHARED, could any interrupt from
another device sharing the PCI IRQ line spuriously trigger the BMC recovery
work?

Since this work executes stop_machine() with a 10-second busy loop,
won't normal activity on shared devices freeze the entire system for 10
seconds?

[Severity: High]
This is a pre-existing issue, but does a static zero-initialized variable
for rate limiting cause legitimate interrupts to be permanently ignored
during early boot?

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_interrupt() {
    ...
    static unsigned long last_jiffies;
    ...
    /* Skip interrupt in LS2K_BMC_INT_INTERVAL */
    if (time_after(jiffies, last_jiffies + LS2K_BMC_INT_INTERVAL)) {
    ...
}

Because the Linux jiffies variable starts at 5 minutes before wrap-around,
time_after(jiffies, 0 + 60*HZ) evaluates to false for the first 6 minutes
of system uptime. 

Will this cause hardware recovery interrupts to be completely ignored during 
this time, and multiple device instances to interfere with each other's 
rate-limiting state?

[Severity: Critical]
This is a pre-existing issue, but are a 10-second busy-wait delay and
sleepable PCI mapping functions executed within a stop_machine() context?

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_events_fn() {
    ...
    stop_machine(ls2k_bmc_recover_pci_data, ddata, NULL);
    ...
}

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_recover_pci_data() {
    ...
    mdelay(LS2K_BMC_RESET_WAIT_TIME);
    ...
}

Will executing a 10-second busy-wait with hard interrupts disabled across
all CPUs trigger the NMI watchdog and crash the system? 

Additionally, since ls2k_bmc_recover_pci_data() calls pci_iomap() via 
ls2k_bmc_pcie_is_connected(), won't invoking sleepable memory allocations 
and locks in an atomic context cause a kernel panic?

[Severity: High]
This is a pre-existing issue, but is the global ls2k_bmc_cells MFD array
dynamically mutated with a stack pointer?

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_probe() {
    ...
    struct simplefb_platform_data pd;
    ...
    ls2k_bmc_cells[LS2K_BMC_DISPLAY].platform_data = &pd;
    ls2k_bmc_cells[LS2K_BMC_DISPLAY].pdata_size = sizeof(pd);
    ...
}

According to MFD subsystem guidelines, mfd_cell arrays must be static const.

Does modifying a global array with a stack pointer create a use-after-free
risk and a concurrency race if multiple instances are probed, since it leaves
the global array permanently holding a dangling stack pointer after probe()
returns?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-ls2kbmc-mod-v8-0-16e44f7322f4@gmail.com?part=4

Re: [PATCH RFC v8 5/8] ipmi: ls2k: adjust dependency to its mfd driver

[sashiko-bot]

> From: Miao Wang <shankerwangmiao@gmail.com>
> 
> There is functional dependency between the IPMI driver and its mfd
> driver. Previously, the dependency was set to "select" from
> IPMI_LS2K to MFD_LS2K_BMC_CORE. However, the ipmi driver is actually
> compiled as a part of the ipmi_si module, and IPMI_LS2K is a bool
> option. Therefore, the dependency "select" will force the mfd driver
> to be compiled built-in when the ipmi driver is built as a module. This
> is not desirable. This patch fixes this by declaring a conditional
> dependency from IPMI_SI to MFD_LS2K_BMC_CORE if IPMI_LS2K is selected.
> This will allow the mfd driver to be compiled as a module if the ipmi
> driver is built as a module. The adjustment to Kconfig for the mfd
> driver will be introduced in the later patch in this series.
> 
> Fixes: d46651d4e3c0 ("ipmi: Add Loongson-2K BMC support")
> Acked-by: Corey Minyard <cminyard@mvista.com>
> Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-ls2kbmc-mod-v8-0-16e44f7322f4@gmail.com?part=5

Re: [PATCH RFC v8 6/8] gpiolib: add gpio_device_get_fwnode() helper

[sashiko-bot]

> From: Miao Wang <shankerwangmiao@gmail.com>
> 
> Add a helper function to retrieve the fwnode associated with a
> struct gpio_device. This is useful for drivers that need to access the
> fwnode of a GPIO device for various purposes, such as creating software
> nodes or handling GPIOs in a platform-specific manner.
> 
> Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-ls2kbmc-mod-v8-0-16e44f7322f4@gmail.com?part=6

Re: [PATCH RFC v8 0/8] mfd: ls2kbmc: multiple fixes for this driver

[Bartosz Golaszewski]

On Mon, 10 Aug 2026 15:20:47 +0200, Miao Wang <shankerwangmiao@gmail.com> said:
> Hi,
>
>> 2026年8月10日 21:08，Bartosz Golaszewski <brgl@kernel.org> 写道：
>>
>> On Mon, Aug 10, 2026 at 3:04 PM Miao Wang via B4 Relay
>> <devnull+shankerwangmiao.gmail.com@kernel.org> wrote:
>>>
>>> ---
>>> Changes in v8:
>>> - Address issues found by the Sashiko AI review bot
>>>  - Fix the error path of the probe function, preventing unintentionally
>>>    returning 0 on failure
>>>  - Reorder the patches in the series to make the change to the Kconfig
>>>    entry for ls2kbmc to be the last patch, to satisfy the AI bot's
>>>    concern on failure to clean up when the driver is built as a module
>>>    and is being removed.
>>> - Link to v7: https://lore.kernel.org/r/20260810-ls2kbmc-mod-v7-0-8aa0fb5a5462@gmail.com
>>>
>>
>> Don't send several versions of the same big series within minutes of
>> each other. Give reviewers time to respond.
>
> Sorry for bothering the maintainers. A reviewer previously required
> a clean or justified Sashiko pass first before reviewing and thus I
> have to fix the high issues found by the bot. I would be nice if I
> can privately send patches to the bot and let it review before I
> send it publicly, to reduce the disturbance to other maintainers.
> I tried to run that bot locally but failed because the bot was
> consuming too many tokens before generating a final result.
>

That doesn't change anything. Sashiko commented on v7 which also contained
changes requested by me. You should wait until I respond before resending the
series with sashiko issues fixed because I may possibly have more comments too.

Bart

Re: [PATCH RFC v8 7/8] mfd: ls2kbmc: Capture the reset event of BMC through GPIO

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] The fallback path will likely fail at `gpiod_to_irq()` on older firmware, causing the driver probe to fail.
- [Low] Casting `phys_addr_t` to `void *` and back causes compiler warnings and potential truncation on 32-bit architectures with 64-bit physical addresses.

Pre-existing issues:
- [High] The probe function assigns a pointer to a local stack variable directly to the global `ls2k_bmc_cells` array, violating MFD subsystem guidelines and creating a concurrency vulnerability.
- [High] The interrupt handler unconditionally returns `IRQ_HANDLED` without checking hardware registers to verify if the interrupt originated from the device, despite being registered with `IRQF_SHARED`.
--

--- Patch [7]: [PATCH RFC v8 7/8] mfd: ls2kbmc: Capture the reset event of BMC through GPIO ---
commit 0a3e35583f83690aea838854a1f8bc9d3f258974
Author: Miao Wang <shankerwangmiao@gmail.com>

mfd: ls2kbmc: Capture the reset event of BMC through GPIO

This commit updates the ls2kbmc driver to retrieve the BMC reset GPIO
from the ACPI node instead of using a hardcoded address. If the ACPI
node lacks the GPIO declaration, it falls back to searching for the
GPIO controller using a fixed address.

> diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c
> index 5eea53f134215..f52f0b772f6e9 100644
> --- a/drivers/mfd/ls2k-bmc-core.c
> +++ b/drivers/mfd/ls2k-bmc-core.c

[ ... ]

> @@ -375,6 +368,82 @@ static void ls2k_bmc_save_pci_data(struct pci_dev *pdev, struct ls2k_bmc_ddata *
[ ... ]
> +static int ls2k_bmc_gpiochip_find(struct gpio_chip *gc, const void *data)
> +{
[ ... ]
> +	phys_addr_t start_addr = (phys_addr_t) data;

[Severity: Low]
Could this cast from a void pointer back to phys_addr_t cause truncation or
compiler warnings on 32-bit architectures that use 64-bit physical
addresses?

[ ... ]

> +static struct gpio_desc *ls2k_bmc_find_gpio(struct ls2k_bmc_ddata *ddata)
> +{
[ ... ]
> +	struct gpio_device *gdev __free(gpio_device_put) =
> +		gpio_device_find((void *)LOONGSON_GPIO_REG_BASE, ls2k_bmc_gpiochip_find);

[Severity: Low]
This is the other side of the cast mentioned above. Can we avoid casting a
physical address integer directly to a void pointer?

[ ... ]

> @@ -402,44 +470,31 @@ static int ls2k_bmc_init(struct ls2k_bmc_ddata *ddata)
[ ... ]
> +	ddata->reset_gpio = devm_gpiod_get_index_optional(&pdev->dev, NULL, 0, GPIOD_IN);
> +	if (IS_ERR(ddata->reset_gpio))
> +		return dev_err_probe(ddata->dev, PTR_ERR(ddata->reset_gpio),
> +				     "Failed to get GPIO pin for reset signal\n");
> +	if (ddata->reset_gpio == NULL) {
> +		ddata->reset_gpio = ls2k_bmc_find_gpio(ddata);
> +		if (IS_ERR(ddata->reset_gpio))
> +			return dev_err_probe(ddata->dev, PTR_ERR(ddata->reset_gpio),
> +					     "Failed to find GPIO pin for reset signal\n");
> +	}
>  
> -	iounmap(gpio_base);
> +	gpio_irq = gpiod_to_irq(ddata->reset_gpio);

[Severity: High]
Might this gpiod_to_irq() call fail on older firmware?

The previous implementation used acpi_register_gsi() directly because the
GPIO controller's ACPI node on older firmware lacked comprehensive IRQ
resource definitions.

If the fallback path triggers on this older firmware, gpiod_to_irq() will
eventually call platform_get_irq(), which relies on those ACPI IRQ
resources.

If they are missing, it might return -ENXIO and cause the entire driver
probe to abort.

>  	if (gpio_irq < 0)
> -		return gpio_irq;
> +		return dev_err_probe(ddata->dev, gpio_irq,
> +				     "Failed to get IRQ for GPIO reset signal input\n");
>  
> -	ret = devm_request_irq(ddata->dev, gpio_irq, ls2k_bmc_interrupt,
> -			       IRQF_SHARED | IRQF_TRIGGER_FALLING, "ls2kbmc gpio", ddata);
> -	if (ret)
> -		dev_err(ddata->dev, "Failed to request LS2KBMC GPIO IRQ %d.\n", gpio_irq);
> +	ret = devm_request_irq(&pdev->dev, gpio_irq, ls2k_bmc_interrupt,
> +			       IRQF_SHARED | IRQF_TRIGGER_FALLING, "ls2kbmc reset", ddata);

[Severity: High]
This is a pre-existing issue, but while we are looking at the IRQ
registration, does ls2k_bmc_interrupt() need to check hardware registers to
verify if the interrupt actually originated from this device?

Since it is registered with IRQF_SHARED, but unconditionally returns
IRQ_HANDLED:

static irqreturn_t ls2k_bmc_interrupt(int irq, void *arg)
{
    ...
    return IRQ_HANDLED;
}

Could this bypass the kernel's spurious interrupt detection and lead to an
interrupt storm if another device sharing the line generates an interrupt?

[ ... ]

[Severity: High]
This is a pre-existing issue, but I noticed a potential concurrency issue in
ls2k_bmc_probe() regarding the global mfd_cell array:

static int ls2k_bmc_probe(struct platform_device *pdev)
{
    ...
    struct ls2k_bmc_pci_data pd;
    ...
    ls2k_bmc_cells[LS2K_BMC_DISPLAY].platform_data = &pd;
    ...
}

Is it safe to assign a pointer to a local stack variable to the global
ls2k_bmc_cells array?

In a multi-probe scenario, multiple threads could concurrently modify
ls2k_bmc_cells. If one thread overwrites the pointer with its own stack
address, could another thread dereference a dangling stack pointer?

The MFD subsystem guidelines typically require mfd_cell arrays to be static
const.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-ls2kbmc-mod-v8-0-16e44f7322f4@gmail.com?part=7

Re: [PATCH RFC v8 8/8] mfd: ls2kbmc: Able to be compiled as a module

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] System panic/freeze due to >10 seconds delay inside `stop_machine` context.
- [High] Dangling pointer in global state and MFD guideline violation due to dynamic modification of `mfd_cell` array.
--

--- Patch [8]: [PATCH RFC v8 8/8] mfd: ls2kbmc: Able to be compiled as a module ---
commit 3dfba1198ec7bd502a9fc1a937060e6136a907cd
Author: Miao Wang <shankerwangmiao@gmail.com>

mfd: ls2kbmc: Able to be compiled as a module
    
Make ls2kbmc able to be compiled as a module.

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 763ce6a34782b..a7a9f97af248c 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2494,7 +2494,7 @@ config MFD_LOONGSON_SE
>  	  which will forward them to the corresponding engine.
>  
>  config MFD_LS2K_BMC_CORE
> -	bool "Loongson-2K Board Management Controller Support"
> +	tristate "Loongson-2K Board Management Controller Support"

[Severity: Critical]
This is a pre-existing issue, but will using stop_machine() with long delays
cause system freezes?

When the driver is built as a module, or even built-in, ls2k_bmc_events_fn()
invokes stop_machine():

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_events_fn() {
    ...
	stop_machine(ls2k_bmc_recover_pci_data, ddata, NULL);
    ...
}

The callback ls2k_bmc_recover_pci_data() executes a loop with mdelay(1) up to
2000 times, and later calls mdelay(LS2K_BMC_RESET_WAIT_TIME) which is
10000 ms:

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_recover_pci_data() {
    ...
	for (i = LS7A_BAR0_CHECK_MAX_TIMES; i > 0 ; i--) {
		if (!ls2k_bmc_bar0_addr_is_set(parent))
			break;
		mdelay(1);
	}
    ...
	/* Waiting for U-Boot and DDR ready */
	mdelay(LS2K_BMC_RESET_WAIT_TIME);
    ...
}

stop_machine() disables local interrupts and halts all online CPUs to run the
provided callback. Busy-waiting for over 10 seconds with interrupts globally
disabled could consistently trigger a kernel panic via the NMI watchdog or
hard lockup detector, causing severe RCU stalls and dropped hardware events.

Is it possible to handle this PCI recovery without halting the entire machine
for 10 seconds?

[Severity: High]
This is a pre-existing issue, but could this code leave a dangling pointer in
the global MFD cell array?

Now that the driver can be compiled as a module, it can be unloaded and
reloaded, making this more likely to cause issues.

drivers/mfd/ls2k-bmc-core.c:
static struct mfd_cell ls2k_bmc_cells[] = {
    ...
};

In ls2k_bmc_probe(), the driver dynamically mutates this global array to
store a pointer to a local stack variable pd:

drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_probe() {
	struct simplefb_platform_data pd;
    ...
	ls2k_bmc_cells[LS2K_BMC_DISPLAY].platform_data = &pd;
	ls2k_bmc_cells[LS2K_BMC_DISPLAY].pdata_size = sizeof(pd);
    ...
}

After ls2k_bmc_probe() returns, the global array retains a dangling pointer
to a freed stack frame. If the driver is unbound and bound again, or if
multiple instances exist, subsequent probes might race or potentially reuse
this stale pointer before it gets overwritten, leading to a stack
use-after-free vulnerability.

Additionally, MFD subsystem guidelines require cell arrays to be static const.

Can this be refactored to avoid mutating the global mfd_cell array with stack
addresses?

>  	depends on PCI && ACPI_GENERIC_GSI
>  	select MFD_CORE
>  	help

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-ls2kbmc-mod-v8-0-16e44f7322f4@gmail.com?part=8

Re: [PATCH RFC v8 6/8] gpiolib: add gpio_device_get_fwnode() helper

[Bartosz Golaszewski]

On Mon, 10 Aug 2026 15:04:29 +0200, Miao Wang via B4 Relay
<devnull+shankerwangmiao.gmail.com@kernel.org> said:
> From: Miao Wang <shankerwangmiao@gmail.com>
>
> Add a helper function to retrieve the fwnode associated with a
> struct gpio_device. This is useful for drivers that need to access the
> fwnode of a GPIO device for various purposes, such as creating software
> nodes or handling GPIOs in a platform-specific manner.
>
> Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
> ---
>  drivers/gpio/gpiolib.c      | 13 +++++++++++++
>  include/linux/gpio/driver.h |  1 +
>  2 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index e5fb60111151f6de20b424551acf213fb058e190..3774ebbbe550cdce0989a2d06f2ab658529c3bab 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1583,6 +1583,19 @@ struct device *gpio_device_to_device(struct gpio_device *gdev)
>  }
>  EXPORT_SYMBOL_GPL(gpio_device_to_device);
>
> +/**
> + * gpio_device_get_fwnode() - Retrieve the fwnode of the underlying device.
> + * @gdev: GPIO device for which to return the fwnode.
> + *
> + * Returns:
> + * The fwnode handle of the underlying device.
> + */

Please extend the kernel doc to also say that the call does not bump the
reference count of the firmware node as the caller already holds a reference
to the GPIO device that owns it so no call to fwnode_handle_put() is required.

With that:

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

And it can go through the MFD tree.

Thanks,
Bartosz

> +struct fwnode_handle *gpio_device_get_fwnode(struct gpio_device *gdev)
> +{
> +	return dev_fwnode(gpio_device_to_device(gdev));
> +}
> +EXPORT_SYMBOL_GPL(gpio_device_get_fwnode);
> +
>  #ifdef CONFIG_GPIOLIB_IRQCHIP
>
>  /*
> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
> index 17511434ed077dde8807bd7630c342e146e5230b..4dd9120707ec72a978f5f916cc5473a91b65d2b9 100644
> --- a/include/linux/gpio/driver.h
> +++ b/include/linux/gpio/driver.h
> @@ -641,6 +641,7 @@ DEFINE_FREE(gpio_device_put, struct gpio_device *,
>  	    if (!IS_ERR_OR_NULL(_T)) gpio_device_put(_T))
>
>  struct device *gpio_device_to_device(struct gpio_device *gdev);
> +struct fwnode_handle *gpio_device_get_fwnode(struct gpio_device *gdev);
>
>  bool gpiochip_line_is_irq(struct gpio_chip *gc, unsigned int offset);
>  int gpiochip_reqres_irq(struct gpio_chip *gc, unsigned int offset);
>
> --
> 2.49.0
>
>
>