Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] mfd: aat2870: Missing GPIO teardown causes backpowering risk --
commit 878c16709c6ee44d1728f13a2ff6e9ad29023883 Author: Svyatoslav Ryhel <[email protected]> mfd: aat2870: Add support for VIN and IN-LDO power supplies This commit adds support for retrieving and managing the VIN and IN-LDO power supplies using the regulator framework to ensure proper power supply dependencies and power-up sequencing. > diff --git a/drivers/mfd/aat2870-core.c b/drivers/mfd/aat2870-core.c > index 909c14ee60323..0bd430b90bc1b 100644 > --- a/drivers/mfd/aat2870-core.c > +++ b/drivers/mfd/aat2870-core.c [ ... ] > @@ -309,6 +310,10 @@ static int aat2870_i2c_probe(struct i2c_client *client) > > aat2870->reg_cache = aat2870_regs; > > + ret = devm_regulator_get_enable(&client->dev, "vin"); > + if (ret) > + return dev_err_probe(&client->dev, ret, "Failed to enable > regulator\n"); > + > aat2870->en_pin = devm_gpiod_get_optional(&client->dev, "enable", > GPIOD_OUT_HIGH); [Severity: High] Does this unwinding order create a backpowering regression when the device is removed? Because the regulator is acquired before the GPIO, devres unwinds in reverse order. It will release the GPIO descriptor first during device unbind (e.g., during parent I2C adapter removal), without actually driving the pin low. After the GPIO descriptor is released, devm_regulator_get_enable() will disable the vin regulator. This leaves the enable GPIO driven high into the unpowered AAT2870 device. Since aat2870_i2c_driver lacks a .remove callback to explicitly drive the GPIO low before devres unwinds, could this backpowering state cause hardware damage? Would it be safer to add a devm action or a .remove callback to pull the enable pin low first? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
