As discussed in [1], some drivers may do not care the difference between
phys. Instead, they only need to treat them as a group and operate them
together. This means a bulk operation is needed.

Add some bulk helper functions for phy core by referencing the design of
clock/reset subsystem. This can relieve the driver owners' life who needs
to handle many phys, as well as each phy error reporting.

[1] https://lore.kernel.org/linux-pci/ak9KzNFF26B0Kttz@ashevche-desk.local/

Changed from v1:
- https://lore.kernel.org/linux-phy/20260831025319.94886-1-inochiama@gmail.com/
patch 1:
1. Update document.
patch 2:
1. Fix document format.
2. Fix several document description.
patch 3:
1. Split into two patches: one for non devm helpers, one for devm helpers.
2. All the bulk helper now use unsigned int for counts.
3. Fix multiple the while loop statement.
4. Rename of_phy_get_parent_count() to of_phy_get_count().
5. Fix some 80 line function problems.
6. Use PTR_ERR_OR_ZERO() to simplify the error handle.
7. Fix zero value in the document
8. Use two separate release function for devm helpers.

Inochi Amaoto (4):
  phy: core: Add common helper to add phy phandle device link
  phy: core: Add common helper for get phy phandle by index
  phy: core: Add phy bulk data helper functions
  phy: core: Add managed phy bulk data helper functions

 drivers/phy/phy-core.c  | 700 +++++++++++++++++++++++++++++++++++++---
 include/linux/phy/phy.h | 186 +++++++++++
 2 files changed, 850 insertions(+), 36 deletions(-)

--
2.55.0

Hi Inochi,

On Fri, Sep 04, 2026 at 04:37:04PM +0800, Inochi Amaoto wrote:
> As discussed in [1], some drivers may do not care the difference between
> phys. Instead, they only need to treat them as a group and operate them
> together. This means a bulk operation is needed.
> 
> Add some bulk helper functions for phy core by referencing the design of
> clock/reset subsystem. This can relieve the driver owners' life who needs
> to handle many phys, as well as each phy error reporting.
> 
> [1] https://lore.kernel.org/linux-pci/ak9KzNFF26B0Kttz@ashevche-desk.local/
> 
> Changed from v1:
> - https://lore.kernel.org/linux-phy/20260831025319.94886-1-inochiama@gmail.com/
> patch 1:
> 1. Update document.
> patch 2:
> 1. Fix document format.
> 2. Fix several document description.
> patch 3:
> 1. Split into two patches: one for non devm helpers, one for devm helpers.
> 2. All the bulk helper now use unsigned int for counts.
> 3. Fix multiple the while loop statement.
> 4. Rename of_phy_get_parent_count() to of_phy_get_count().
> 5. Fix some 80 line function problems.
> 6. Use PTR_ERR_OR_ZERO() to simplify the error handle.
> 7. Fix zero value in the document
> 8. Use two separate release function for devm helpers.
> 
> Inochi Amaoto (4):
>   phy: core: Add common helper to add phy phandle device link
>   phy: core: Add common helper for get phy phandle by index
>   phy: core: Add phy bulk data helper functions
>   phy: core: Add managed phy bulk data helper functions
> 
>  drivers/phy/phy-core.c  | 700 +++++++++++++++++++++++++++++++++++++---
>  include/linux/phy/phy.h | 186 +++++++++++
>  2 files changed, 850 insertions(+), 36 deletions(-)
> 
> --
> 2.55.0

Please include a user of this API in the next patch submission.
We should avoid, as much as possible, to introduce unused code.

Also, please address Sashiko's feedback (excluding the pre-existing
issues).

On Mon, Sep 07, 2026 at 01:28:49PM +0300, Vladimir Oltean wrote:
> Hi Inochi,
> 
> On Fri, Sep 04, 2026 at 04:37:04PM +0800, Inochi Amaoto wrote:
> > As discussed in [1], some drivers may do not care the difference between
> > phys. Instead, they only need to treat them as a group and operate them
> > together. This means a bulk operation is needed.
> > 
> > Add some bulk helper functions for phy core by referencing the design of
> > clock/reset subsystem. This can relieve the driver owners' life who needs
> > to handle many phys, as well as each phy error reporting.
> > 
> > [1] https://lore.kernel.org/linux-pci/ak9KzNFF26B0Kttz@ashevche-desk.local/
> > 
> > Changed from v1:
> > - https://lore.kernel.org/linux-phy/20260831025319.94886-1-inochiama@gmail.com/
> > patch 1:
> > 1. Update document.
> > patch 2:
> > 1. Fix document format.
> > 2. Fix several document description.
> > patch 3:
> > 1. Split into two patches: one for non devm helpers, one for devm helpers.
> > 2. All the bulk helper now use unsigned int for counts.
> > 3. Fix multiple the while loop statement.
> > 4. Rename of_phy_get_parent_count() to of_phy_get_count().
> > 5. Fix some 80 line function problems.
> > 6. Use PTR_ERR_OR_ZERO() to simplify the error handle.
> > 7. Fix zero value in the document
> > 8. Use two separate release function for devm helpers.
> > 
> > Inochi Amaoto (4):
> >   phy: core: Add common helper to add phy phandle device link
> >   phy: core: Add common helper for get phy phandle by index
> >   phy: core: Add phy bulk data helper functions
> >   phy: core: Add managed phy bulk data helper functions
> > 
> >  drivers/phy/phy-core.c  | 700 +++++++++++++++++++++++++++++++++++++---
> >  include/linux/phy/phy.h | 186 +++++++++++
> >  2 files changed, 850 insertions(+), 36 deletions(-)
> > 
> > --
> > 2.55.0
> 
> Please include a user of this API in the next patch submission.
> We should avoid, as much as possible, to introduce unused code.
> 

Yes, I have one for it. This is the spacemit pcie driver.
https://lore.kernel.org/linux-pci/20260907112606.465778-1-inochiama@gmail.com/

But it only uses a few of these helpers. So should I remove all the
things that are not directly used, and let others add these if they
need?

> Also, please address Sashiko's feedback (excluding the pre-existing
> issues).
> 

Yes, I will, thanks.

Regards,
Inochi

On Mon, Sep 07, 2026 at 07:29:49PM +0800, Inochi Amaoto wrote:
> Yes, I have one for it. This is the spacemit pcie driver.
> https://lore.kernel.org/linux-pci/20260907112606.465778-1-inochiama@gmail.com/
> 
> But it only uses a few of these helpers. So should I remove all the
> things that are not directly used, and let others add these if they
> need?

How many functions would go away, and how difficult would they be to
reconstruct, if we only were to add them on an "as-needed" basis?

If the answer is "many", I suppose you could also leave a note in
phy.rst that links to v2 and mentions unimplemented functions because
they lack a user.

On Mon, Sep 07, 2026 at 02:57:12PM +0300, Vladimir Oltean wrote:
> On Mon, Sep 07, 2026 at 07:29:49PM +0800, Inochi Amaoto wrote:
> > Yes, I have one for it. This is the spacemit pcie driver.
> > https://lore.kernel.org/linux-pci/20260907112606.465778-1-inochiama@gmail.com/
> > 
> > But it only uses a few of these helpers. So should I remove all the
> > things that are not directly used, and let others add these if they
> > need?
> 
> How many functions would go away, and how difficult would they be to
> reconstruct, if we only were to add them on an "as-needed" basis?
> 
> If the answer is "many", I suppose you could also leave a note in
> phy.rst that links to v2 and mentions unimplemented functions because
> they lack a user.
> 

In fact I think it is happy. This PCIe driver only use three APIs:
- devm_of_phy_bulk_get_all
- phy_bulk_init
- phy_bulk_exit

So most of them will be removed as only a few are on the path.
I will follow you suggestion. Thanks.

Regards,
Inochi

On Mon, Sep 07, 2026 at 08:05:57PM +0800, Inochi Amaoto wrote:
> On Mon, Sep 07, 2026 at 02:57:12PM +0300, Vladimir Oltean wrote:
> > On Mon, Sep 07, 2026 at 07:29:49PM +0800, Inochi Amaoto wrote:
> > > Yes, I have one for it. This is the spacemit pcie driver.
> > > https://lore.kernel.org/linux-pci/20260907112606.465778-1-inochiama@gmail.com/
> > > 
> > > But it only uses a few of these helpers. So should I remove all the
> > > things that are not directly used, and let others add these if they
> > > need?
> > 
> > How many functions would go away, and how difficult would they be to
> > reconstruct, if we only were to add them on an "as-needed" basis?
> > 
> > If the answer is "many", I suppose you could also leave a note in
> > phy.rst that links to v2 and mentions unimplemented functions because
> > they lack a user.
> > 
> 
> In fact I think it is happy. This PCIe driver only use three APIs:
> - devm_of_phy_bulk_get_all
> - phy_bulk_init
> - phy_bulk_exit
> 
> So most of them will be removed as only a few are on the path.
> I will follow you suggestion. Thanks.
> 
> Regards,
> Inochi

I think you should call phy_bulk_power_on()/phy_bulk_power_off() as
well from the PCI controller driver, even if the PHY provider driver
doesn't (currently) implement them. The Generic PHY API is about
offering some degree of mutual consumer<->provider intercompatibility,
not just a pretentious indirect function call k1_pcie_init() ->
k1_pcie_phy_init().

So those 2 functions should also make it to your v3 patch set.

BTW, do you need a stable tag to be provided by linux-phy, to continue
your work on PCI in this development cycle? You should mention this in
your cover letter, because it does require a bit of maintainer
preparation beforehand.

On Mon, Sep 07, 2026 at 03:16:53PM +0300, Vladimir Oltean wrote:
> On Mon, Sep 07, 2026 at 08:05:57PM +0800, Inochi Amaoto wrote:
> > On Mon, Sep 07, 2026 at 02:57:12PM +0300, Vladimir Oltean wrote:
> > > On Mon, Sep 07, 2026 at 07:29:49PM +0800, Inochi Amaoto wrote:
> > > > Yes, I have one for it. This is the spacemit pcie driver.
> > > > https://lore.kernel.org/linux-pci/20260907112606.465778-1-inochiama@gmail.com/
> > > > 
> > > > But it only uses a few of these helpers. So should I remove all the
> > > > things that are not directly used, and let others add these if they
> > > > need?
> > > 
> > > How many functions would go away, and how difficult would they be to
> > > reconstruct, if we only were to add them on an "as-needed" basis?
> > > 
> > > If the answer is "many", I suppose you could also leave a note in
> > > phy.rst that links to v2 and mentions unimplemented functions because
> > > they lack a user.
> > > 
> > 
> > In fact I think it is happy. This PCIe driver only use three APIs:
> > - devm_of_phy_bulk_get_all
> > - phy_bulk_init
> > - phy_bulk_exit
> > 
> > So most of them will be removed as only a few are on the path.
> > I will follow you suggestion. Thanks.
> > 
> > Regards,
> > Inochi
> 
> I think you should call phy_bulk_power_on()/phy_bulk_power_off() as
> well from the PCI controller driver, even if the PHY provider driver
> doesn't (currently) implement them. The Generic PHY API is about
> offering some degree of mutual consumer<->provider intercompatibility,
> not just a pretentious indirect function call k1_pcie_init() ->
> k1_pcie_phy_init().
> 
> So those 2 functions should also make it to your v3 patch set.
> 

Good. That's the point I have missed. I will add them, thanks.

> BTW, do you need a stable tag to be provided by linux-phy, to continue
> your work on PCI in this development cycle? You should mention this in
> your cover letter, because it does require a bit of maintainer
> preparation beforehand.
> 

I think I need. The most problem of PCI driver is already fixed so I
think there is a chance for it to get merged.

Regards,
Inochi

On Mon, Sep 07, 2026 at 03:16:53PM +0300, Vladimir Oltean wrote:
> On Mon, Sep 07, 2026 at 08:05:57PM +0800, Inochi Amaoto wrote:
> > On Mon, Sep 07, 2026 at 02:57:12PM +0300, Vladimir Oltean wrote:
> > > On Mon, Sep 07, 2026 at 07:29:49PM +0800, Inochi Amaoto wrote:
> > > > Yes, I have one for it. This is the spacemit pcie driver.
> > > > https://lore.kernel.org/linux-pci/20260907112606.465778-1-inochiama@gmail.com/
> > > > 
> > > > But it only uses a few of these helpers. So should I remove all the
> > > > things that are not directly used, and let others add these if they
> > > > need?
> > > 
> > > How many functions would go away, and how difficult would they be to
> > > reconstruct, if we only were to add them on an "as-needed" basis?
> > > 
> > > If the answer is "many", I suppose you could also leave a note in
> > > phy.rst that links to v2 and mentions unimplemented functions because
> > > they lack a user.
> > > 
> > 
> > In fact I think it is happy. This PCIe driver only use three APIs:
> > - devm_of_phy_bulk_get_all
> > - phy_bulk_init
> > - phy_bulk_exit
> > 
> > So most of them will be removed as only a few are on the path.
> > I will follow you suggestion. Thanks.
> > 
> > Regards,
> > Inochi
> 
> I think you should call phy_bulk_power_on()/phy_bulk_power_off() as
> well from the PCI controller driver, even if the PHY provider driver
> doesn't (currently) implement them. The Generic PHY API is about
> offering some degree of mutual consumer<->provider intercompatibility,
> not just a pretentious indirect function call k1_pcie_init() ->
> k1_pcie_phy_init().
> 
> So those 2 functions should also make it to your v3 patch set.
> 
> BTW, do you need a stable tag to be provided by linux-phy, to continue
> your work on PCI in this development cycle? You should mention this in
> your cover letter, because it does require a bit of maintainer
> preparation beforehand.

Since we were talking about drivers/ata/libahci_platform.c on the other
patch - you could consider also converting this to the PHY bulk API and
this would give you some more coverage so that you don't remove unused
functions from your submission.