On Wed, Jan 18, 2023 at 11:25:31PM +0200, Abel Vesa wrote: > On 23-01-18 17:45:16, Johan Hovold wrote: > > On Wed, Jan 18, 2023 at 02:53:21AM +0200, Abel Vesa wrote: > > > Document the QMP PCIe PHY compatible for SM8550. > > > > > > Signed-off-by: Abel Vesa <abel.vesa@xxxxxxxxxx> > > > --- > > > .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml > > > index 8a85318d9c92..65f26cfff3fb 100644 > > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml > > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml > > > @@ -20,6 +20,8 @@ properties: > > > - qcom,sc8280xp-qmp-gen3x2-pcie-phy > > > - qcom,sc8280xp-qmp-gen3x4-pcie-phy > > > - qcom,sm8350-qmp-gen3x1-pcie-phy > > > + - qcom,sm8550-qmp-gen3x2-pcie-phy > > > + - qcom,sm8550-qmp-gen4x2-pcie-phy > > > > > > reg: > > > minItems: 1 > > > > I don't think I'll have time to look at this week, but I did notice that > > you fail do describe the clocks, regulators, and resets (as you also > > did for the UFS PHY binding) which are currently different from > > sc8280xp. > > Hmm, sorry about that. I will double check against the pcie phy nodes I > have for sm8550. > > As for the UFS, if your are referring to the following patchset [1], the phy > node looks exactly the same as on sc8280xp, therefore no other binding > update, other than compatible, was needed. > > [1] https://lore.kernel.org/all/20230117224148.1914627-2-abel.vesa@xxxxxxxxxx/ Yes, but I was referring to your original submission which added different names for the clocks without updating the binding. In that case, those clocks were really the same ones as the ones on sc8280xp so it was only the driver and dts changes that were wrong: https://lore.kernel.org/all/Y8And9VVvpnSInlj@xxxxxxxxxxxxxxxxxxxx/ > > Please be more careful when adding compatible strings so we get this > > right. You should also double check that the differences are really > > warranted and not just due the vendor using different names for the same > > resource. Johan
