[PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state

[Vladimir Oltean]

On Wed, Mar 25, 2026 at 01:57:31PM +0200, Vladimir Oltean wrote:
> On Wed, Mar 25, 2026 at 05:21:14PM +0530, Manivannan Sadhasivam wrote:
> > I believe I added the power_count check for phy_exit(). But since that got
> > moved, the check becomes no longer necessary.
> 
> FYI, the power_count keeps track of the balance of phy_power_on() and
> phy_power_off() calls, whereas it is the init_count keeps track of
> phy_init() and phy_exit() calls. They are only related to the extent
> that you must respect the phy_init() -> phy_power_on() -> phy_power_off()
> -> phy_exit() sequence. But in any case, both should be considered
> PHY-internal fields. The "Order of API calls" section from
> Documentation/driver-api/phy/phy.rst mentions the order that I just
> described above, and consumers should just ensure they follow that.

Ok, so we can close this topic of "checking the power_count not needed"
by linking to the conversation which spun off here:
https://lore.kernel.org/lkml/20260325120122.265973-1-manivannan.sadhasivam@oss.qualcomm.com/

Mani, I spent some more time to figure out what's really going on with
this unexpected phy_power_off() call. Do you think you could
regression-test the patch attached?

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-scsi-ufs-qcom-don-t-call-phy_power_on-before-phy_ini.patch
Type: text/x-diff
Size: 7997 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20260326/530a63c6/attachment-0001.bin>