Message-ID: <4d9b5ca4-bebc-93c3-7d25-14d12899cab6@linux.intel.com>
Date: Tue, 4 Feb 2025 08:57:57 -0800 (PST)
From: matthew.gerlach@...ux.intel.com
To: Krzysztof Kozlowski <krzk@...nel.org>
cc: lpieralisi@...nel.org, kw@...ux.com, manivannan.sadhasivam@...aro.org, 
    robh@...nel.org, bhelgaas@...gle.com, krzk+dt@...nel.org, 
    conor+dt@...nel.org, dinguyen@...nel.org, joyce.ooi@...el.com, 
    linux-pci@...r.kernel.org, devicetree@...r.kernel.org, 
    linux-kernel@...r.kernel.org, matthew.gerlach@...era.com, 
    peter.colberg@...era.com
Subject: Re: [PATCH v5 4/5] arm64: dts: agilex: add dts enabling PCIe Root
 Port



On Thu, 30 Jan 2025, Krzysztof Kozlowski wrote:

> On 29/01/2025 23:54, matthew.gerlach@...ux.intel.com wrote:
>>
>>
>> On Wed, 29 Jan 2025, Krzysztof Kozlowski wrote:
>>
>>> On 27/01/2025 18:35, Matthew Gerlach wrote:
>>>> Add a device tree enabling PCIe Root Port support on
>>>> an Agilex F-series Development Kit which has the
>>>> P-tile variant PCIe IP.
>>>
>>> Please wrap commit message according to Linux coding style / submission
>>> process (neither too early nor over the limit):
>>> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>>>
>> Thank you for the pointer. I will fix the commit message accordingly.
>>
>>>>
>>>> Signed-off-by: Matthew Gerlach <matthew.gerlach@...ux.intel.com>
>>>> ---
>>>> v3:
>>>>  - Remove accepted patches from patch set.
>>>> ---
>>>>  arch/arm64/boot/dts/intel/Makefile               |  1 +
>>>>  .../socfpga_agilex7f_socdk_pcie_root_port.dts    | 16 ++++++++++++++++
>>>>  2 files changed, 17 insertions(+)
>>>>  create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex7f_socdk_pcie_root_port.dts
>>>>
>>>> diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
>>>> index d39cfb723f5b..737e81c3c3f7 100644
>>>> --- a/arch/arm64/boot/dts/intel/Makefile
>>>> +++ b/arch/arm64/boot/dts/intel/Makefile
>>>> @@ -2,6 +2,7 @@
>>>>  dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
>>>>  				socfpga_agilex_socdk.dtb \
>>>>  				socfpga_agilex_socdk_nand.dtb \
>>>> +				socfpga_agilex7f_socdk_pcie_root_port.dtb \
>>>>  				socfpga_agilex5_socdk.dtb \
>>>>  				socfpga_n5x_socdk.dtb
>>>>  dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
>>>> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex7f_socdk_pcie_root_port.dts b/arch/arm64/boot/dts/intel/socfpga_agilex7f_socdk_pcie_root_port.dts
>>>> new file mode 100644
>>>> index 000000000000..76a989ba6a44
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex7f_socdk_pcie_root_port.dts
>>>> @@ -0,0 +1,16 @@
>>>> +// SPDX-License-Identifier:     GPL-2.0
>>>> +/*
>>>> + * Copyright (C) 2024, Intel Corporation
>>>> + */
>>>> +
>>>> +#include "socfpga_agilex_socdk.dts"
>
>
> Nope, you cannot include a board in other board.

Ok, I understand.

>
>>>> +#include "socfpga_agilex_pcie_root_port.dtsi"
>>>> +
>>>
>>> Missing board compatible, missing bindings.
>>
>> The model and compatible bindings are inherited from socfpga_agilex_socdk.dts.
>
> Then this is the same board, so entire DTS should be removed and instead
> merged into parent DTS. There is no such thing as "inherit" of an
> compatible.

It is the same physical board, but the image programmed into the FPGA is 
different in so far as the PCIe IP is connected and enabled. This 
different FPGA image allows for a PCIe End Point to be plugged in. Is this 
difference enough for it be considered and different board?

>
>>
>>>
>>>> +&pcie_0_pcie_aglx {
>>>> +	status = "okay";
>>>> +	compatible = "altr,pcie-root-port-3.0-p-tile";
>>>
>>> Why do you define the compatible here, not in DTSI? This is highly
>>> unusual and confusing. Also, compatible is never the last property, but
>>> opposite.
>>
>> The current DTSI supports all three variants of the PCI hardware in the
>> Agilex family, referred to as P-Tile, F-Tile, and R-Tile. This particular
>> board has an Agilex chip with the P-Tile variant of the PCI hardware.
>
> And devices are not compatible? If they have common part in the DTSI, I
> would expect that. This is really unusual stuff and needs proper
> justifications, not just "DTSI support something". DTSI represents SoC
> and SoC either has p-tile or something else. It does not have a "wildcard".

Unfortunately, the P-Tile, F-Tile, and R-Tile are not compatible. A small 
number of registers have different offsets.

>
> It's the same with that earlier simple-bus. You wrote DTS which does not
> represent real hardware.
>
>>
>> I will move the compatible property to be the first property.
>>
>>>
>>> Plus:
>>>
>>> Please run scripts/checkpatch.pl and fix reported warnings. After that,
>>> run also `scripts/checkpatch.pl --strict` and (probably) fix more
>>> warnings. Some warnings can be ignored, especially from --strict run,
>>> but the code here looks like it needs a fix. Feel free to get in touch
>>> if the warning is not clear.
>>
>> The only warning I see from scripts/checkpatch.pl --strict is "added,
>> moved or deleted file(s), does MAINTAINERS need updating?". The directory,
>> arch/arm64/boot/dts/intel/, is already mentioned in the MAINTAINERS file.
>> Do I need to do anything to resolve this?
>
> My mistake, I missed the first patch and assumed checkpatch will
> complain about this compatible.
>
>>
>>>
>>> It does not look like you tested the DTS against bindings. Please run
>>> `make dtbs_check W=1` (see
>>> Documentation/devicetree/bindings/writing-schema.rst or
>>> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
>>> for instructions).
>>> Maybe you need to update your dtschema and yamllint. Don't rely on
>>> distro packages for dtschema and be sure you are using the latest
>>> released dtschema.
>>
>> The dtschema check failures are inherited from socfpga_agilex_socdk.dts.
>
> New errors are not inherited from DTS/DTSI. Anyway, you cannot include
> other DTS. DTS is final board. You do not include C files in C code in
> Linux kernel.
>
>> Rob Herring's bot indicates that "Ultimately, it is up to the platform
>> maintainer whether these warnings are acceptable or not." Is this
>> applicable here? Is the correct way to fix the existing dtschema check
>> warnings is with their own patches, rather than adding to this PCIe Root
>> Port patchset?
>
> Any new warning is on you and for example with that simple-bus, you
> brought new ones.

I now see the new warnings that I introduced, and they will be fixed.

>
> Best regards,
> Krzysztof
>

Thanks for the feedback,
Matthew Gerlach

Powered by blists - more mailing lists