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: <eb77eec0-7d51-46a0-b5c6-83c68316ef32@kernel.org>
Date: Thu, 30 Jan 2025 08:31:54 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: matthew.gerlach@...ux.intel.com
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 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.

>>> +#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.

> 
>>
>>> +&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".

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.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ