[PATCH v4 3/5] phy: core: Add phy bulk data helper functions

[Inochi Amaoto]

On Sun, Oct 18, 2026 at 06:09:49PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Oct 05, 2026 at 07:41:52PM +0800, Inochi Amaoto wrote:
> > On Mon, Oct 05, 2026 at 12:12:51PM +0200, Vinod Koul wrote:
> > > On 29-09-26, 16:52, Inochi Amaoto wrote:
> > > > Add several helper functions that allow drivers to get several phy
> > > > consumers in one operation. If any of the phy cannot be acquired then
> > > > any phys that were got will be put before returning to the caller.
> > > 
> > > Do we have many such examples? Phy is not a many resource like
> > > clock/regulators... Do we really need this. How many in kernel users
> > > will benefit from this API?
> > > 
> > 
> > 
> > I guess the following driver may benefit from bulk api. Most of them
> > are PCIe drivers....
> > 
> > drivers/ata/ahci_imx.c
> > drivers/pci/controller/cadence/pcie-cadence.c
> > drivers/pci/controller/dwc/pci-dra7xx.c
> > drivers/pci/controller/dwc/pcie-tegra194.c
> > drivers/pci/controller/pcie-rockchip.c
> > drivers/pci/controller/dwc/pcie-qcom.c
> > 
> > Note: I mean the bulk api, not just the things I added. I guess many
> > may want devm_phy_bulk_get() or devm_of_phy_bulk_get() instead of
> > devm_phy_bulk_get_all().
> > 
> 
> No. I don't think the PCIe host controllers need the PHY bulk APIs. Most of the
> time they need to control each PHY independently in a multi-port setup. So
> having the bulk API doesn't seem logical to me.
> 
> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்

Sorry for missing this one. For multi-port setup, the answer is no. The bulk
API is not a good choice. But for multi-lane setup of one port, I think the
answer is yes, the driver can just control the phy together and do not need
a loop for that. At least for pcie-rockchip.c, I think it is reasonable, its
logic show it use multi-lane setup, so I think it is fine to port.

Regards,
Inochi