Re: [PATCH 9/9] ARM: dts: uniphier: Remove compatible "snps,dw-pcie-ep" from Pro5 pcie-ep node

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> 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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux