| Message ID | 1656894026-15707-10-git-send-email-hayashi.kunihiko@socionext.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Update UniPhier armv7 devicetree | expand |
On Mon, Jul 4, 2022 at 2:20 AM Kunihiko Hayashi <hayashi.kunihiko@socionext.com> wrote: > > UniPhier PCIe endpoint controller doesn't use "snps,dw-pcie-ep" compatible, > so this is no longer needed. Remove the compatible string from the pcie-ep > node to fix the following warning. > > uniphier-pro5-epcore.dtb: pcie@66000000: compatible: ['socionext,uniphier-pro5-pcie-ep', 'snps,dw-pcie-ep'] is too long > From schema: Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml > This sounds like a problem with the binding rather than the dt file. Is this not a designware pci endpoint? Should it be documented in that binding instead? Arnd
On 30/07/2022 13:58, Arnd Bergmann wrote: > On Mon, Jul 4, 2022 at 2:20 AM Kunihiko Hayashi > <hayashi.kunihiko@socionext.com> wrote: >> >> UniPhier PCIe endpoint controller doesn't use "snps,dw-pcie-ep" compatible, >> so this is no longer needed. Remove the compatible string from the pcie-ep >> node to fix the following warning. >> >> uniphier-pro5-epcore.dtb: pcie@66000000: compatible: ['socionext,uniphier-pro5-pcie-ep', 'snps,dw-pcie-ep'] is too long >> From schema: Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml >> > > This sounds like a problem with the binding rather than the dt file. Is this not > a designware pci endpoint? Should it be documented in that binding instead? Depends. We had one or two similar cases, where we dropped the snps/dw generic compatible, because device was actually quite different and could not match against snps/dw compatible. IOW, if device bound/matched via generic compatible it would be entirely non-operational. Logically I think it is okay to drop the generic compatible. Different question is any ABI break. Best regards, Krzysztof
On 2022/08/02 17:33, Krzysztof Kozlowski wrote: > On 30/07/2022 13:58, Arnd Bergmann wrote: >> On Mon, Jul 4, 2022 at 2:20 AM Kunihiko Hayashi >> <hayashi.kunihiko@socionext.com> wrote: >>> >>> UniPhier PCIe endpoint controller doesn't use "snps,dw-pcie-ep" >>> compatible, >>> so this is no longer needed. Remove the compatible string from the >>> pcie-ep >>> node to fix the following warning. >>> >>> uniphier-pro5-epcore.dtb: pcie@66000000: compatible: >>> ['socionext,uniphier-pro5-pcie-ep', 'snps,dw-pcie-ep'] is too long >>> From schema: >>> Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml >>> >> >> This sounds like a problem with the binding rather than the dt file. Is >> this not >> a designware pci endpoint? Should it be documented in that binding >> instead? In term of the binding, it seems that the current binding doesn't allow descriptions that list two compatibles. There is something wrong with the binding. > Depends. We had one or two similar cases, where we dropped the snps/dw > generic compatible, because device was actually quite different and > could not match against snps/dw compatible. IOW, if device bound/matched > via generic compatible it would be entirely non-operational. Logically I > think it is okay to drop the generic compatible. Different question is > any ABI break. In term of the controller, we can add dw general compatible if the more generic driver (pcie-designware-plat) works on the controller. However, the generic driver can't do the initialization what the controller needs, so we can add controller-specific compatible only. The commit bf2942a8b7c3 ("arm64: tegra: Fix Tegra194 PCIe EP compatible string") removes the generic compatible for the same reason. This patch suggests removing the generic compatible for the former reason, though, I might suggest it for the controller reason. Thank you, --- Best Regards Kunihiko Hayashi
On 02/08/2022 15:10, Kunihiko Hayashi wrote: > On 2022/08/02 17:33, Krzysztof Kozlowski wrote: >> On 30/07/2022 13:58, Arnd Bergmann wrote: >>> On Mon, Jul 4, 2022 at 2:20 AM Kunihiko Hayashi >>> <hayashi.kunihiko@socionext.com> wrote: >>>> >>>> UniPhier PCIe endpoint controller doesn't use "snps,dw-pcie-ep" >>>> compatible, >>>> so this is no longer needed. Remove the compatible string from the >>>> pcie-ep >>>> node to fix the following warning. >>>> >>>> uniphier-pro5-epcore.dtb: pcie@66000000: compatible: >>>> ['socionext,uniphier-pro5-pcie-ep', 'snps,dw-pcie-ep'] is too long >>>> From schema: >>>> Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml >>>> >>> >>> This sounds like a problem with the binding rather than the dt file. Is >>> this not >>> a designware pci endpoint? Should it be documented in that binding >>> instead? > > In term of the binding, it seems that the current binding doesn't allow descriptions > that list two compatibles. There is something wrong with the binding. > >> Depends. We had one or two similar cases, where we dropped the snps/dw >> generic compatible, because device was actually quite different and >> could not match against snps/dw compatible. IOW, if device bound/matched >> via generic compatible it would be entirely non-operational. Logically I >> think it is okay to drop the generic compatible. Different question is >> any ABI break. > > In term of the controller, we can add dw general compatible if the more generic > driver (pcie-designware-plat) works on the controller. > > However, the generic driver can't do the initialization what the controller > needs, so we can add controller-specific compatible only. > The commit bf2942a8b7c3 ("arm64: tegra: Fix Tegra194 PCIe EP compatible string") > removes the generic compatible for the same reason. > > This patch suggests removing the generic compatible for the former reason, > though, I might suggest it for the controller reason. The patch does not explain this, though. Best regards, Krzysztof
On 2022/08/03 15:11, Krzysztof Kozlowski wrote: > On 02/08/2022 15:10, Kunihiko Hayashi wrote: >> On 2022/08/02 17:33, Krzysztof Kozlowski wrote: >>> On 30/07/2022 13:58, Arnd Bergmann wrote: >>>> On Mon, Jul 4, 2022 at 2:20 AM Kunihiko Hayashi >>>> <hayashi.kunihiko@socionext.com> wrote: >>>>> >>>>> UniPhier PCIe endpoint controller doesn't use "snps,dw-pcie-ep" >>>>> compatible, >>>>> so this is no longer needed. Remove the compatible string from the >>>>> pcie-ep >>>>> node to fix the following warning. >>>>> >>>>> uniphier-pro5-epcore.dtb: pcie@66000000: compatible: >>>>> ['socionext,uniphier-pro5-pcie-ep', 'snps,dw-pcie-ep'] is too long >>>>> From schema: >>>>> Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml >>>>> >>>> >>>> This sounds like a problem with the binding rather than the dt file. Is >>>> this not >>>> a designware pci endpoint? Should it be documented in that binding >>>> instead? >> >> In term of the binding, it seems that the current binding doesn't allow >> descriptions >> that list two compatibles. There is something wrong with the binding. >> >>> Depends. We had one or two similar cases, where we dropped the snps/dw >>> generic compatible, because device was actually quite different and >>> could not match against snps/dw compatible. IOW, if device bound/matched >>> via generic compatible it would be entirely non-operational. Logically I >>> think it is okay to drop the generic compatible. Different question is >>> any ABI break. >> >> In term of the controller, we can add dw general compatible if the more >> generic >> driver (pcie-designware-plat) works on the controller. >> >> However, the generic driver can't do the initialization what the >> controller >> needs, so we can add controller-specific compatible only. >> The commit bf2942a8b7c3 ("arm64: tegra: Fix Tegra194 PCIe EP compatible >> string") >> removes the generic compatible for the same reason. >> >> This patch suggests removing the generic compatible for the former reason, >> though, I might suggest it for the controller reason. > > The patch does not explain this, though. Yes, I'll resend the patch with an explanation of the reason for the controller like Tegra194. Thank you, --- Best Regards Kunihiko Hayashi
diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi b/arch/arm/boot/dts/uniphier-pro5.dtsi index 64cdd0c62e55..c3e431b3f643 100644 --- a/arch/arm/boot/dts/uniphier-pro5.dtsi +++ b/arch/arm/boot/dts/uniphier-pro5.dtsi @@ -620,8 +620,7 @@ usb1_ssphy0: ss-phy@380 { }; pcie_ep: pcie-ep@66000000 { - compatible = "socionext,uniphier-pro5-pcie-ep", - "snps,dw-pcie-ep"; + compatible = "socionext,uniphier-pro5-pcie-ep"; status = "disabled"; reg-names = "dbi", "dbi2", "link", "addr_space"; reg = <0x66000000 0x1000>, <0x66001000 0x1000>,
UniPhier PCIe endpoint controller doesn't use "snps,dw-pcie-ep" compatible, so this is no longer needed. Remove the compatible string from the pcie-ep node to fix the following warning. uniphier-pro5-epcore.dtb: pcie@66000000: compatible: ['socionext,uniphier-pro5-pcie-ep', 'snps,dw-pcie-ep'] is too long From schema: Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> --- arch/arm/boot/dts/uniphier-pro5.dtsi | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)