Re: [PATCH RFC v4 5/9] phy: qcom: qmp-pcie: Refactor pipe clk register and parse_dt helpers

[Qiang Yu]

On Tue, Jun 16, 2026 at 04:05:43PM +0200, Konrad Dybcio wrote:
> On 5/29/26 9:02 AM, Qiang Yu wrote:
> > On Thu, May 28, 2026 at 04:48:24PM +0300, Dmitry Baryshkov wrote:
> >> On Fri, May 22, 2026 at 04:27:35PM +0530, Manivannan Sadhasivam wrote:
> >>> On Wed, May 20, 2026 at 07:25:01PM +0300, Dmitry Baryshkov wrote:
> >>>> On Mon, May 18, 2026 at 10:47:16PM -0700, Qiang Yu wrote:
> >>>>> Some QMP PCIe PHY hardware blocks can be split into multiple sub-PHYs
> >>>>> under a single DT node, each requiring its own pipe clock registration and
> >>>>> DT resource mapping. The current helpers are tightly coupled to a single
> >>>>> qmp_pcie instance, which prevents reuse across sub-PHY instances.
> >>>>>
> >>>>> Refactor __phy_pipe_clk_register() as a generic helper and reduce
> >>>>> phy_pipe_clk_register() to a thin wrapper around it. Similarly, extract
> >>>>> qmp_pcie_parse_dt_common() from qmp_pcie_parse_dt() to hold the register-
> >>>>> mapping and pipe-clock setup that will be shared between sub-PHY instances,
> >>>>> with pipe clock names parameterised per instance.
> >>>>>
> >>>>> This is a preparatory step before adding multi-PHY support. No functional
> >>>>> change for existing platforms.
> >>>>>
> >>>>> Signed-off-by: Qiang Yu <qiang.yu@xxxxxxxxxxxxxxxx>
> >>>>> ---
> >>>>>  drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 76 ++++++++++++++++++--------------
> >>>>>  1 file changed, 44 insertions(+), 32 deletions(-)
> >>>>
> >>>> I'd suggest splitting the Glymur PHY to a separate driver. Otherwise we
> >>>> end up having too many single-platform, single-device specifics which
> >>>> don't apply to other platforms.
> >>>>
> >>>
> >>> I don't think that's really needed. This shared PHY concept is going to be
> >>> applicable to upcoming SoCs as well. And moreover, the split won't be clean
> >>> either. We still need to reuse a lot of common logic in the 'phy-qcom-qmp-pcie'
> >>> driver and may only end up keeping very minimal code in
> >>> 'phy-qcom-qmp-pcie-glymur'.
> >>
> >> Then splitting makes even more sense. Let's not clutter the existing
> >> driver with too many conditions and options.
> >>
> >>>
> >>> If you are concerned about the file size of 'phy-qcom-qmp-pcie', then we should
> >>> move the SoC specific 'cfg' structs into a separate file as that's what
> >>> occupying majority of the space.
> >>
> >> No, it's really the 'shared' part.
> >>
> > 
> > To confirm, are you okay with some code duplication between the new
> > Glymur-specific driver and phy-qcom-qmp-pcie driver.
> 
> That's a necessity, to some degree. See e.g. qmp-combo and qmp-usbc 
>
I've already prototyped a separate Glymur driver, and it turned out better
than expected — there's actually not much duplication. The parts that do
overlap aren't fully identical either; they tend to diverge once the
Glymur-specific handling is factored in.

Currently, I meet an issue when tesing the patch, and will post it after
fixing the issue.

- Qiang Yu