Re: [PATCH RFC v5 7/7] mfd: ls2kbmc: Capture the reset event of BMC through GPIO
[email protected] Mon, 03 Aug 2026 17:15:55 +0000
| Newsgroups | dev.linux.lists.mfd |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: New issues: - [Low] Casting between `phys_addr_t` and `void *` causes compiler warnings= and potential data truncation on 32-bit platforms. Pre-existing issues: - [High] The driver dynamically modifies the global `ls2k_bmc_cells` array = during probe, violating the `static const` requirement and creating a race = condition. -- --- Patch [7]: [PATCH RFC v5 7/7] mfd: ls2kbmc: Capture the reset event of = BMC through GPIO --- commit 535a8683905c93577231c2208f8f76431cb9049d Author: Miao Wang <[email protected]> mfd: ls2kbmc: Capture the reset event of BMC through GPIO This patch modifies the driver to capture the BMC reset event through the GPIO framework rather than directly accessing the controller via a fixed address. It attempts to find the GPIO pin via ACPI _CRS resources, falling back to a fixed address and pin number if not found. This helps prevent conflicts when the same GPIO controller is probed by an ACPI GPIO driver. > diff --git a/drivers/mfd/ls2k-bmc-core.c b/drivers/mfd/ls2k-bmc-core.c > index e7bebfe696ac4..97a666a136fe4 100644 > --- a/drivers/mfd/ls2k-bmc-core.c > +++ b/drivers/mfd/ls2k-bmc-core.c [ ... ] > @@ -375,6 +368,91 @@ static void ls2k_bmc_save_pci_data(struct pci_dev *p= dev, struct ls2k_bmc_ddata * > pci_read_config_dword(pdev, PCI_INTERRUPT_LINE, &ddata->bmc_pci_data.in= terrupt_line); > } > =20 > +static struct fwnode_handle *gpio_dev_get_fwnode(struct gpio_device *gde= v) > +{ > + struct device *gdev_dev; > + > + gdev_dev =3D gpio_device_to_device(gdev); > + return dev_fwnode(gdev_dev); > +} > + > +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 =3D gpio_dev_get_fwnode(gc->gpiodev); > + phys_addr_t start_addr =3D (phys_addr_t) data; [Severity: Low] Does casting data from a void pointer back to a phys_addr_t cause data truncation on 32-bit platforms where phys_addr_t is a 64-bit type? Can this also trigger pointer-to-int cast warnings during compilation? > + int ret, found =3D 0; > + [ ... ] > +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 =3D 0x1FE00500; > + static const unsigned int LS2K_BMC_RESET_GPIO =3D 14; > + int ret; > + struct gpio_device *gdev __free(gpio_device_put) =3D NULL; > + struct property_entry ls2k_bmc_swnode_properties[2] =3D { 0 }; > + > + dev_dbg(ddata->dev, "Searching for GPIO chip at address %pa\n", &LOONGS= ON_GPIO_REG_BASE); > + > + gdev =3D gpio_device_find((void *)LOONGSON_GPIO_REG_BASE, ls2k_bmc_gpio= chip_find); [Severity: Low] Can passing the 64-bit LOONGSON_GPIO_REG_BASE by casting it to a void point= er truncate the upper 32 bits on 32-bit architectures? Does this also trigger int-to-pointer cast warnings during the build? [ ... ] [Severity: High] This isn't a bug introduced by this patch, but does ls2k_bmc_probe() dynamically modify the global ls2k_bmc_cells array during probe? drivers/mfd/ls2k-bmc-core.c:ls2k_bmc_probe() { ... ls2k_bmc_cells[LS2K_BMC_DISPLAY].platform_data =3D &pd; ls2k_bmc_cells[LS2K_BMC_DISPLAY].pdata_size =3D sizeof(pd); ... } The MFD subsystem guide requires mfd_cell arrays to be static const. Does this assignment create a race condition on concurrent probes (if multi= ple PCI devices were present) since instances would overwrite the shared platform_data pointer? Additionally, since pd is a stack variable, does this leave a dangling poin= ter in the global array after ls2k_bmc_probe() returns? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260804-ls2kbmc-mo= [email protected]?part=3D7