On 05/07/2022 12:20, Johan Hovold wrote: > On Tue, Jul 05, 2022 at 12:08:36PM +0200, Krzysztof Kozlowski wrote: >> On 05/07/2022 11:42, Johan Hovold wrote: >>> The QMP PHY DT schema is getting unwieldy. Break out the odd-bird >>> msm8996-qmp-pcie-phy which is the only QMP PHY that uses separate >>> "per-lane" nodes. >>> >>> Signed-off-by: Johan Hovold <johan+linaro@xxxxxxxxxx> >>> --- >>> .../phy/qcom,msm8996-qmp-pcie-phy.yaml | 114 ++++++++++++++++++ >>> .../devicetree/bindings/phy/qcom,qmp-phy.yaml | 32 ----- >>> 2 files changed, 114 insertions(+), 32 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-pcie-phy.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-pcie-phy.yaml >>> new file mode 100644 >>> index 000000000000..14fd86fd91ec >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-pcie-phy.yaml >>> @@ -0,0 +1,114 @@ >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>> + >> >> No line break >> >>> +%YAML 1.2 >>> +--- >>> +$id: "http://devicetree.org/schemas/phy/qcom,msm8996-qmp-pcie-phy.yaml#"; >>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; >> >> Drop the quotes from two above. > > This comes from the current binding. I can clean that one up first. You now selectively copy pieces from old binding into new one. Copy while correcting obvious issues. > >>> + >>> +title: Qualcomm QMP PHY controller (MSM8996 PCIe) >>> + >>> +maintainers: >>> + - Vinod Koul <vkoul@xxxxxxxxxx> >>> + >>> +description: >>> + QMP PHY controller supports physical layer functionality for a number of >>> + controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB. >>> + >>> +properties: >>> + compatible: >>> + const: qcom,msm8996-qmp-pcie-phy >>> + >>> + reg: >>> + minItems: 1 >>> + items: >>> + - description: Address and length of PHY's common serdes block. >>> + - description: Address and length of PHY's DP_COM control block. >> >> Are two reg items applicable here? > > No, but see below. > >>> + >>> + "#address-cells": >>> + enum: [ 1, 2 ] >>> + >>> + "#size-cells": >>> + enum: [ 1, 2 ] >>> + >>> + ranges: true >>> + >>> + clocks: >>> + minItems: 1 >>> + maxItems: 4 >> >> Define clocks here, not in allOf:if:then. > > To remain sane, and to help reviewers, I decided not to do changes to > the binding while splitting it up which would only make them harder > to review. > > Hence the split followed by cleanup/tightening of constraints. It's confusing. I look at this commit and it is not correct. How do I know that next commits will correct it? I responded in further patches that most of them they should be squashed with this copy. > >> How about an example? > > That's also a new addition to the binding and goes in a later separate > patch. > Best regards, Krzysztof
