Re: [PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p
Bartosz Golaszewski <[email protected]> Mon, 29 Jun 2026 07:07:24 -0700
| Newsgroups | dev.linux.lists.sophgo,dev.linux.lists.imx,dev.linux.lists.linux-sunxi,org.infradead.lists.linux-amlogic,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.infradead.lists.linux-rockchip,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-mips,org.kernel.vger.linux-renesas-soc,org.kernel.vger.netdev |
|---|---|
| Message-ID | <CAMRc=Me3jaZXiXa1sFXr=8Do4sCd+XN1pKTcWC8-0j78SjCkKA@mail.gmail.com> |
On Mon, 29 Jun 2026 15:51:31 +0200, Geert Uytterhoeven <[email protected]> said: > Hi Bartosz, > > Thanks for your patch! > > On Mon, 29 Jun 2026 at 13:29, Bartosz Golaszewski > <[email protected]> wrote: >> Describe the SGMII/SerDes PHY present on the Qualcomm sa8255p platforms. >> This is essentially the same hardware as sa8775p rev3 but the PHY is >> managed by firmware over SCMI. > > So why can't it be reuse the DT bindings, and be compatible with > qcom,sa8775p-dwmac-sgmii-phy? > >> Signed-off-by: Bartosz Golaszewski <[email protected]> > >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-dwmac-sgmii-phy.yaml > >> + power-domains: >> + maxItems: 1 >> + >> + power-domain-names: >> + items: >> + - const: serdes > >> +examples: >> + - | >> + phy@8901000 { >> + compatible = "qcom,sa8255p-dwmac-sgmii-phy"; >> + reg = <0x08901000 0xe10>; >> + #phy-cells = <0>; >> + power-domains = <&scmi7_dvfs 0>; >> + power-domain-names = "serdes"; > > Ah, this uses power-domains, while the existing bindings for > qcom,sa8775p-dwmac-sgmii-phy use a clock. > I guess the clock is the correct hardware description? > > Adding to my list of examples for backing a hardware-to-SCMI remapping > driver... > Russell King asked me to put the PHY logic for SCMI pm domains into the PHY driver instead of the MAC driver where it was previously. Instead of cramming both HLOS and firmware handling into the same driver, I figured it makes more sense to have a dedicated, cleaner driver as the two share very little code (if any). Bart