[PATCH 09/15] dt-bindings: phy: qcom,qmp-pcie: mark current bindings as legacy

[Johan Hovold]

On Tue, Oct 18, 2022 at 12:52:03PM +0300, Dmitry Baryshkov wrote:
> Hi,
> 
> On Mon, 17 Oct 2022 at 17:54, Johan Hovold <johan+linaro at kernel.org> wrote:
> >
> > The current QMP PCIe PHY bindings are based on the original MSM8996
> > binding which provided multiple PHYs per IP block and these in turn were
> > described by child nodes.
> >
> > Later QMP PCIe PHY blocks only provide a single PHY and the remnant
> > child node does not really reflect the hardware.
> >
> > The original MSM8996 binding also ended up describing the individual
> > register blocks as belonging to either the wrapper node or the PHY child
> > nodes.
> >
> > This is an unnecessary level of detail which has lead to problems when
> > later IP blocks using different register layouts have been forced to fit
> > the original mould rather than updating the binding. The bindings are
> > arguable also incomplete as they only the describe register blocks used
> > by the current Linux drivers (e.g. does not include the per lane PCS
> > registers).
> 
> I'd like to point out that it's not only a problem peculiar to the
> PCIe PHYs. Other QMP PHY families also follow the same approach of
> separating the serdes into the common part and rx/tx/PCS/whatever into
> the PHY subnodes.

Yeah, I already mentioned that in the cover letter.

> For the USB+DP combo PHYs we have to have subnodes, however it would
> also be logical to move serdes register to the subnode devices,
> leaving only DP_COM in the base node.

No, not at all. First, we may not even need the subnodes (the individual
PHYs can be indexed), but even if we do keep them for the combo case,
the register block should go in the wrapper node as the registers can be
and are shared (e.g. for sc8280xp for which the current binding is
completely broken).

> That said, I think we should rethink and agree on QMP PHY bindings,
> before renaming the bindings.

Isn't that what we are doing just now?

> And yes, I think we should also upgrade
> older DTs, keeping drivers backwards compatible (for some time?).

Possibly, but I'm not sure it's worth the dts churn. As I mentioned
elsewhere, supporting both the old and new binding in the driver is
mostly trivial, while encoding the deprecated bindings in DT schema
sounds like it would be painful.

On the other hand, adding support for new features to (or fixing bugs
in) old platforms using the current bindings may potentially become
easier if they are also converted.

> > In preparation for adding new bindings for SC8280XP which further
> > bindings can be based on, mark the current bindings as "legacy".
> >
> > Signed-off-by: Johan Hovold <johan+linaro at kernel.org>
> > ---
> >  .../{qcom,qmp-pcie-phy.yaml => qcom,qmp-pcie-phy-legacy.yaml} | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >  rename Documentation/devicetree/bindings/phy/{qcom,qmp-pcie-phy.yaml => qcom,qmp-pcie-phy-legacy.yaml} (98%)

Johan