mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Inochi Amaoto <inochiama@gmail.com>
Cc: Vinod Koul <vkoul@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Manivannan Sadhasivam <mani@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org,
	Yixun Lan <dlan@gentoo.org>, Longbin Li <looong.bin@gmail.com>
Subject: Re: [PATCH v2 0/4] phy: core: Add phy bulk helpers support
Date: Mon, 7 Sep 2026 16:04:44 +0300	[thread overview]
Message-ID: <20260907130444.zwuiczzhlk6yalpi@skbuf> (raw)
In-Reply-To: <20260907121653.4ajpkjt2i5opmwzc@skbuf>

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.

  reply	other threads:[~2026-09-07 13:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04  8:37 Inochi Amaoto
2026-09-04  8:37 ` [PATCH v2 1/4] phy: core: Add common helper to add phy phandle device link Inochi Amaoto
2026-09-05  8:02   ` Andy Shevchenko
2026-09-07 11:01   ` Vladimir Oltean
2026-09-07 11:33     ` Inochi Amaoto
2026-09-04  8:37 ` [PATCH v2 2/4] phy: core: Add common helper for get phy phandle by index Inochi Amaoto
2026-09-05  8:14   ` Andy Shevchenko
2026-09-07 11:03   ` Vladimir Oltean
2026-09-07 11:30     ` Inochi Amaoto
2026-09-04  8:37 ` [PATCH v2 3/4] phy: core: Add phy bulk data helper functions Inochi Amaoto
2026-09-07 10:56   ` Vladimir Oltean
2026-09-07 11:37     ` Inochi Amaoto
2026-09-07 11:48   ` Vladimir Oltean
2026-09-07 12:15     ` Inochi Amaoto
2026-09-07 12:43       ` Vladimir Oltean
2026-09-07 22:20         ` Inochi Amaoto
2026-09-04  8:37 ` [PATCH v2 4/4] phy: core: Add managed " Inochi Amaoto
2026-09-07 10:28 ` [PATCH v2 0/4] phy: core: Add phy bulk helpers support Vladimir Oltean
2026-09-07 11:29   ` Inochi Amaoto
2026-09-07 11:57     ` Vladimir Oltean
2026-09-07 12:05       ` Inochi Amaoto
2026-09-07 12:16         ` Vladimir Oltean
2026-09-07 13:04           ` Vladimir Oltean [this message]
2026-09-07 22:28           ` Inochi Amaoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260907130444.zwuiczzhlk6yalpi@skbuf \
    --to=olteanv@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dlan@gentoo.org \
    --cc=inochiama@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=looong.bin@gmail.com \
    --cc=mani@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®