Re: [PATCH v10 07/26] scsi: ufs: mediatek: Rework 0.9V regulator

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

New issues:
- [Medium] `ufs_mtk_get_supplies()` uses `dev_err()` instead of `dev_err_probe()`, resulting in excessive log spam when the regulator probe defers.

Pre-existing issues:
- [High] Missing error handling in `ufs_mtk_mphy_power_on()` leads to PHY framework reference count underflow and state desynchronization.
--

--- Patch [7]: [PATCH v10 07/26] scsi: ufs: mediatek: Rework 0.9V regulator ---
Note: The format of this report has been altered due to recitation restrictions. The original patch diff is not quoted, and findings are provided as a free-form summary.

commit 53fa70c9d3d751e82ebb61d97d0c2282f65046c5
Author: Nicolas Frattaroli <[email protected]>
scsi: ufs: mediatek: Rework 0.9V regulator

This commit reworks the 0.9V regulator handling in the Mediatek UFS host
driver. It removes the custom downstream naming, uses the standard regulator
API with the avdd09 supply name, and eliminates manual stabilization delays.

[Severity: High]
This is a pre-existing issue, but does ufs_mtk_mphy_power_on() handle
failures correctly during PHY power transitions?

When calling phy_power_on(), the return value is not checked. If hardware
initialization fails, host->mphy_powered_on is still set to true.

Additionally, on the power-off path, if the newly added ufs_mtk_09v_off()
fails, the function returns early without setting host->mphy_powered_on
to false.

Could this desynchronize the driver's state from the PHY hardware state?
If the driver incorrectly records the power state as true, subsequent
suspend or error handling paths might blindly call phy_power_off() again,
which would lead to power_count underflows in the PHY framework and
permanently break the PHY until a system reboot.

[Severity: Medium]
In the newly added ufs_mtk_get_supplies(), dev_err() is used to log
failures from devm_regulator_get_optional() for the avdd09 regulator.

If the regulator returns -EPROBE_DEFER, will this dev_err() call cause
excessive log spam during the device probe phase?

Would it make sense to use dev_err_probe() here instead to properly handle
and suppress expected probe deferral messages?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=7