linux-kernel - Re: [PATCH 02/14] dt-bindings: phy: qcom,qmp-usb3-dp: fix sc8280xp bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <61df3c4f-f41c-9525-606d-1b8261163080@linaro.org>
Date:   Tue, 15 Nov 2022 09:12:54 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Johan Hovold <johan@...nel.org>
Cc:     Johan Hovold <johan+linaro@...nel.org>,
        Vinod Koul <vkoul@...nel.org>, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/14] dt-bindings: phy: qcom,qmp-usb3-dp: fix sc8280xp
 bindings

On 14/11/2022 18:08, Johan Hovold wrote:
>>
>> Which is also fine. I don't understand still why it is a problem - even
>> if you have multiple files, one for each SoC/phy. If USB4 brings here 10
>> more clocks and other SoCs/phys might bring many more options, then what
>> else can you do? Grow the binding file with big text-based mapping of
>> IDs? It's not a viable solution. Header or headers is the only
>> maintainable way for such cases.
> 
> So then we must add per-SoC (and PHY type) headers even if we can
> possibly reuse defines from one platform for another as long as they
> appear to be similar enough?

No, you don't have to. I just got impression that future devices will
bring so many changes that anyway you will end up with per-SoC defines.

> For example, using a "SC7180_USB3_DP" infix
> for the current platforms and add a new series of indexes for SC8280XP:
> 
> 	QMP_SC7180_USB3_DP_USB3_PIPE			0
> 	QMP_SC7180_USB3_DP_DP_LINK			1
> 	QMP_SC7180_USB3_DP_DP_VCO_DIV			2
> 
> 	QMP_SC8280XP_USB4_USB3_DP_USB3_PIPE		0
> 	QMP_SC8280XP_USB4_USB3_DP_DP_LINK		1
> 	QMP_SC8280XP_USB4_USB3_DP_DP_VCO_DIV		2
> 	QMP_SC8280XP_USB4_USB3_DP_USB4_PCIE_PIPE	3
> 	...
> 	QMP_SC8280XP_USB4_USB3_DP_USB4_RX1		9

The names are just a names, you can even use QMP_SC7180_* on SC8280XP.
You can skip the SoC part and have something shared. We already have
such patterns - although maybe more often for outside components (like
PMICs). The differences are:
1. For per-SoC name it's quite obvious which clock is supported on fiven
SoC,
2. With shared names, you should document somewhere mapping between
supported clocks and SoCs. Also what to do if new device comes with 10
new clocks entirely different - re-use/map existing defines or add
completely new set of 10 of them?

Best regards,
Krzysztof