All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 9/9] ARM: dts: uniphier: Remove compatible "snps,dw-pcie-ep" from Pro5 pcie-ep node
Date: Thu, 4 Aug 2022 15:26:31 +0900	[thread overview]
Message-ID: <445840cd-84e3-40bc-223f-4feacbcbcdf6@socionext.com> (raw)
In-Reply-To: <751115c3-086c-7207-8281-3ffbb5d45872@linaro.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 9/9] ARM: dts: uniphier: Remove compatible "snps,dw-pcie-ep" from Pro5 pcie-ep node
Date: Thu, 4 Aug 2022 15:26:31 +0900	[thread overview]
Message-ID: <445840cd-84e3-40bc-223f-4feacbcbcdf6@socionext.com> (raw)
In-Reply-To: <751115c3-086c-7207-8281-3ffbb5d45872@linaro.org>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-08-04  6:26 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-04  0:20 [PATCH 0/9] Update UniPhier armv7 devicetree Kunihiko Hayashi
2022-07-04  0:20 ` Kunihiko Hayashi
2022-07-04  0:20 ` [PATCH 1/9] ARM: dts: uniphier: Fix USB interrupts for PXs2 SoC Kunihiko Hayashi
2022-07-04  0:20   ` Kunihiko Hayashi
2022-07-04  0:20 ` [PATCH 2/9] ARM: dts: uniphier: Rename pvtctl node to thermal-sensor Kunihiko Hayashi
2022-07-04  0:20   ` Kunihiko Hayashi
2022-07-04  0:20 ` [PATCH 3/9] ARM: dts: uniphier: Rename usb-phy node to usb-glue Kunihiko Hayashi
2022-07-04  0:20   ` Kunihiko Hayashi
2022-07-04  0:20 ` [PATCH 4/9] ARM: dts: uniphier: Rename gpio-hog node Kunihiko Hayashi
2022-07-04  0:20   ` Kunihiko Hayashi
2022-07-04  0:20 ` [PATCH 5/9] ARM: dts: uniphier: Use GIC interrupt definitions Kunihiko Hayashi
2022-07-04  0:20   ` Kunihiko Hayashi
2022-07-04  0:20 ` [PATCH 6/9] ARM: dts: uniphier: Add ahci controller and glue layer nodes for Pro4 Kunihiko Hayashi
2022-07-04  0:20   ` Kunihiko Hayashi
2022-07-04  0:20 ` [PATCH 7/9] ARM: dts: uniphier: Add ahci controller and glue layer nodes for PXs2 Kunihiko Hayashi
2022-07-04  0:20   ` Kunihiko Hayashi
2022-07-04  0:20 ` [PATCH 8/9] ARM: dts: uniphier: Move interrupt-parent property to each child node in uniphier-support-card Kunihiko Hayashi
2022-07-04  0:20   ` Kunihiko Hayashi
2022-07-04  0:20 ` [PATCH 9/9] ARM: dts: uniphier: Remove compatible "snps,dw-pcie-ep" from Pro5 pcie-ep node Kunihiko Hayashi
2022-07-04  0:20   ` Kunihiko Hayashi
2022-07-30 11:58   ` Arnd Bergmann
2022-07-30 11:58     ` Arnd Bergmann
2022-08-02  8:33     ` Krzysztof Kozlowski
2022-08-02  8:33       ` Krzysztof Kozlowski
2022-08-02 13:10       ` Kunihiko Hayashi
2022-08-02 13:10         ` Kunihiko Hayashi
2022-08-03  6:11         ` Krzysztof Kozlowski
2022-08-03  6:11           ` Krzysztof Kozlowski
2022-08-04  6:26           ` Kunihiko Hayashi [this message]
2022-08-04  6:26             ` Kunihiko Hayashi

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=445840cd-84e3-40bc-223f-4feacbcbcdf6@socionext.com \
    --to=hayashi.kunihiko@socionext.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=robh+dt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.