devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Johan Hovold <johan+linaro@kernel.org>,
	Vinod Koul <vkoul@kernel.org>, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@somainline.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 09/15] dt-bindings: phy: qcom,qmp-pcie: mark current bindings as legacy
Date: Tue, 18 Oct 2022 09:06:39 +0200	[thread overview]
Message-ID: <Y05Qf2nDCIVg23Zh@hovoldconsulting.com> (raw)
In-Reply-To: <5e153119-f853-ff57-8277-2d782e255be2@linaro.org>

On Mon, Oct 17, 2022 at 01:15:45PM -0400, Krzysztof Kozlowski wrote:
> On 17/10/2022 10:53, Johan Hovold 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).
> > 
> > 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@kernel.org>
> > ---
> >  .../{qcom,qmp-pcie-phy.yaml => qcom,qmp-pcie-phy-legacy.yaml} | 4 ++--
> 
> I don't think we should rename anything as legacy. These are "normal"
> platforms, not legacy ones. SM8450 is not even that old.

I'm not really referring to the platforms as legacy, but the rather the
format of the bindings. The intent is that by marking the current ones
as such, people will not base new bindings on the old scheme.

There's no problem supporting both schemes in the driver also for the
current compatibles, but expressing such a deprecation in DT schema
sounds like it would be painful. We instead decided to simple draw the
line at SC8280XP and have future bindings be based on its binding.

> The recommendation is to keep names matching the compatibles, not adding
> some legacy/newer/newest suffixes.

Yeah, I know, but that's not what the current bindings do. And if we
keep 

	qcom,qmp-pcie-phy.yaml

and add

	qcom,sc8280xp-qmp-pcie-phy.yaml

then I fear that people will base their bindings on the former rather
than the latter.

I guess I can just add a comment in the old schema file with a reference
to the sc8280xp bindings to try to prevent people from adding new ones
in the wrong place.

If I understand you correctly this is what you are suggesting? And that
the new file should still be named "qcom,sc8280xp-qmp-pcie-phy.yaml"
also as new bindings are added to that file?

I could also rename the old schema file after one of the old platforms
platforms therein (e.g. qcom,msm8998-qmp-pcie-phy) to make it sounds
less like a generic schema for new bindings.

That is

	qcom,msm8998-qmp-pcie-phy.yaml + comment (for current bindings)
	qcom,sc8280xp-qmp-pcie-phy.yaml (for new bindings)

Johan

  reply	other threads:[~2022-10-18  7:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-17 14:53 [PATCH 00/15] phy: qcom-qmp-pcie: add support for sc8280xp Johan Hovold
2022-10-17 14:53 ` [PATCH 01/15] phy: qcom-qmp-pcie: sort device-id table Johan Hovold
2022-10-17 14:53 ` [PATCH 02/15] phy: qcom-qmp-pcie: move " Johan Hovold
2022-10-17 14:53 ` [PATCH 03/15] phy: qcom-qmp-pcie: merge driver data Johan Hovold
2022-10-17 14:53 ` [PATCH 04/15] phy: qcom-qmp-pcie: clean up device-tree parsing Johan Hovold
2022-10-17 14:53 ` [PATCH 05/15] phy: qcom-qmp-pcie: clean up probe initialisation Johan Hovold
2022-10-17 14:53 ` [PATCH 06/15] phy: qcom-qmp-pcie: rename PHY ops structure Johan Hovold
2022-10-17 14:53 ` [PATCH 07/15] phy: qcom-qmp-pcie: clean up PHY lane init Johan Hovold
2022-10-17 14:53 ` [PATCH 08/15] phy: qcom-qmp-pcie: add register init helper Johan Hovold
2022-10-17 14:53 ` [PATCH 09/15] dt-bindings: phy: qcom,qmp-pcie: mark current bindings as legacy Johan Hovold
2022-10-17 17:15   ` Krzysztof Kozlowski
2022-10-18  7:06     ` Johan Hovold [this message]
2022-10-18 15:27       ` Krzysztof Kozlowski
2022-10-18 15:49         ` Johan Hovold
2022-10-18  9:52   ` Dmitry Baryshkov
2022-10-18 10:21     ` Johan Hovold
2022-10-18 11:37       ` Dmitry Baryshkov
2022-10-18 12:44         ` Johan Hovold
2022-10-18 15:32         ` Krzysztof Kozlowski
2022-10-18 16:04           ` Johan Hovold
2022-10-18 16:44             ` Krzysztof Kozlowski
2022-10-19  9:33               ` Johan Hovold
2022-10-17 14:53 ` [PATCH 10/15] dt-bindings: phy: qcom,qmp-pcie: add sc8280xp bindings Johan Hovold
2022-10-17 17:20   ` Krzysztof Kozlowski
2022-10-18  9:40     ` Johan Hovold
2022-10-18 15:22       ` Krzysztof Kozlowski
2022-10-18 15:47         ` Johan Hovold
2022-10-17 14:53 ` [PATCH 11/15] phy: qcom-qmp-pcie: restructure PHY creation Johan Hovold
2022-10-17 14:53 ` [PATCH 12/15] phy: qcom-qmp-pcie: fix initialisation reset Johan Hovold
2022-10-17 14:53 ` [PATCH 13/15] phy: qcom-qmp-pcie: add support for pipediv2 clock Johan Hovold
2022-10-18 13:05   ` Dmitry Baryshkov
2022-10-18 14:53     ` Johan Hovold
2022-10-17 14:53 ` [PATCH 14/15] phy: qcom-qmp-pcie: add support for sc8280xp Johan Hovold
2022-10-17 14:53 ` [PATCH 15/15] phy: qcom-qmp-pcie: add support for sc8280xp 4-lane PHYs Johan Hovold

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=Y05Qf2nDCIVg23Zh@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=johan+linaro@kernel.org \
    --cc=konrad.dybcio@somainline.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=robh+dt@kernel.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;
as well as URLs for NNTP newsgroup(s).