The ATU information is already set in the dwc core if it is specified in
the DTS. The driver uses its own value here [1]. This information is
hardware specific and should therefore be maintained in the DTS rather
than in the source.
Backwards compatibility is not an issue here [5], as the driver is
exclusively used by Maxlinear.
Old DTS entry for PCIe:
reg = <0xd1000000 0x1000>,
<0xd3000000 0x20000>,
<0xd0c41000.0x1000>;
reg-names = "dbi", "config", "app";
New DTS entry for PCIe:
reg = <0xd1000000 0x1000>,
<0xd10c0000 0x1000>,
<0xd3000000 0x20000>,
<0xd0c41000.0x1000>;
reg-names = "dbi", "atu", "config", "app";
[1] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-intel-gw.c#L301
[2] https://lore.kernel.org/all/BY3PR19MB507667CE7531D863E1E5F8AEBDD82@BY3PR19MB5076.namprd19.prod.outlook.com/
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
index 54e2890ae6314ac6847fc23f49440d05d66d87d4..e4b781f57e8ae84a3ffc33635a421e1a5761587e 100644
--- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
@@ -29,12 +29,14 @@ properties:
reg:
items:
- description: Controller control and status registers.
+ - description: Internal Address Translation Unit (iATU) registers.
- description: PCIe configuration registers.
- description: Controller application registers.
reg-names:
items:
- const: dbi
+ - const: atu
- const: config
- const: app
@@ -94,9 +96,10 @@ examples:
#address-cells = <3>;
#size-cells = <2>;
reg = <0xd0e00000 0x1000>,
+ <0xd0ec0000 0x1000>,
<0xd2000000 0x800000>,
<0xd0a41000 0x1000>;
- reg-names = "dbi", "config", "app";
+ reg-names = "dbi", "atu", config", "app";
linux,pci-domain = <0>;
max-link-speed = <4>;
bus-range = <0x00 0x08>;
--
2.47.3On Mon, Mar 30, 2026 at 11:07:16AM +0200, Florian Eckert wrote: > The ATU information is already set in the dwc core if it is specified in > the DTS. The driver uses its own value here [1]. This information is > hardware specific and should therefore be maintained in the DTS rather > than in the source. > > Backwards compatibility is not an issue here [5], as the driver is > exclusively used by Maxlinear. > > Old DTS entry for PCIe: > > reg = <0xd1000000 0x1000>, > <0xd3000000 0x20000>, > <0xd0c41000.0x1000>; > reg-names = "dbi", "config", "app"; > > New DTS entry for PCIe: > > reg = <0xd1000000 0x1000>, > <0xd10c0000 0x1000>, > <0xd3000000 0x20000>, > <0xd0c41000.0x1000>; > reg-names = "dbi", "atu", "config", "app"; > > [1] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-intel-gw.c#L301 > [2] https://lore.kernel.org/all/BY3PR19MB507667CE7531D863E1E5F8AEBDD82@BY3PR19MB5076.namprd19.prod.outlook.com/ > > Signed-off-by: Florian Eckert <fe@dev.tdt.de> > --- > Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml > index 54e2890ae6314ac6847fc23f49440d05d66d87d4..e4b781f57e8ae84a3ffc33635a421e1a5761587e 100644 > --- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml > +++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml > @@ -29,12 +29,14 @@ properties: > reg: > items: > - description: Controller control and status registers. > + - description: Internal Address Translation Unit (iATU) registers. > - description: PCIe configuration registers. > - description: Controller application registers. > > reg-names: > items: > - const: dbi > + - const: atu Put this at the end and add 'minItems: 3' and you avoid any ABI issues. > - const: config > - const: app >
On 2026-03-31 17:21, Rob Herring wrote: > On Mon, Mar 30, 2026 at 11:07:16AM +0200, Florian Eckert wrote: >> The ATU information is already set in the dwc core if it is specified >> in >> the DTS. The driver uses its own value here [1]. This information is >> hardware specific and should therefore be maintained in the DTS rather >> than in the source. >> >> Backwards compatibility is not an issue here [5], as the driver is >> exclusively used by Maxlinear. >> >> Old DTS entry for PCIe: >> >> reg = <0xd1000000 0x1000>, >> <0xd3000000 0x20000>, >> <0xd0c41000.0x1000>; >> reg-names = "dbi", "config", "app"; >> >> New DTS entry for PCIe: >> >> reg = <0xd1000000 0x1000>, >> <0xd10c0000 0x1000>, >> <0xd3000000 0x20000>, >> <0xd0c41000.0x1000>; >> reg-names = "dbi", "atu", "config", "app"; >> >> [1] >> https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-intel-gw.c#L301 >> [2] >> https://lore.kernel.org/all/BY3PR19MB507667CE7531D863E1E5F8AEBDD82@BY3PR19MB5076.namprd19.prod.outlook.com/ >> >> Signed-off-by: Florian Eckert <fe@dev.tdt.de> >> --- >> Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml >> b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml >> index >> 54e2890ae6314ac6847fc23f49440d05d66d87d4..e4b781f57e8ae84a3ffc33635a421e1a5761587e >> 100644 >> --- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml >> +++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml >> @@ -29,12 +29,14 @@ properties: >> reg: >> items: >> - description: Controller control and status registers. >> + - description: Internal Address Translation Unit (iATU) >> registers. >> - description: PCIe configuration registers. >> - description: Controller application registers. >> >> reg-names: >> items: >> - const: dbi >> + - const: atu > > Put this at the end and add 'minItems: 3' and you avoid any ABI issues. Unfortunately, I misunderstood what you meant. This is still wrong in v3 [1] I send to day. I’ve only changed it in the documentation. I forgot to do that in the example, as I didn’t realize that we can not always access resources by name, but also by index. That’s why the order matters. I’ve got it now. Thanks! My mistake – I’ll change that in v4 tomorrow so that your bot is happy too. -- Florian [1] https://lore.kernel.org/all/20260401-pcie-intel-gw-v3-0-63b008c5b7b2@dev.tdt.de/T/#t > >> - const: config >> - const: app >>
On Mon, 30 Mar 2026 11:07:16 +0200, Florian Eckert wrote: > The ATU information is already set in the dwc core if it is specified in > the DTS. The driver uses its own value here [1]. This information is > hardware specific and should therefore be maintained in the DTS rather > than in the source. > > Backwards compatibility is not an issue here [5], as the driver is > exclusively used by Maxlinear. > > Old DTS entry for PCIe: > > reg = <0xd1000000 0x1000>, > <0xd3000000 0x20000>, > <0xd0c41000.0x1000>; > reg-names = "dbi", "config", "app"; > > New DTS entry for PCIe: > > reg = <0xd1000000 0x1000>, > <0xd10c0000 0x1000>, > <0xd3000000 0x20000>, > <0xd0c41000.0x1000>; > reg-names = "dbi", "atu", "config", "app"; > > [1] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-intel-gw.c#L301 > [2] https://lore.kernel.org/all/BY3PR19MB507667CE7531D863E1E5F8AEBDD82@BY3PR19MB5076.namprd19.prod.outlook.com/ > > Signed-off-by: Florian Eckert <fe@dev.tdt.de> > --- > Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: Lexical error: Documentation/devicetree/bindings/pci/intel-gw-pcie.example.dts:28.37-43 Unexpected 'config' Error: Documentation/devicetree/bindings/pci/intel-gw-pcie.example.dts:28.37-43 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [scripts/Makefile.dtbs:140: Documentation/devicetree/bindings/pci/intel-gw-pcie.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1601: dt_binding_check] Error 2 make: *** [Makefile:248: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.kernel.org/project/devicetree/patch/20260330-pcie-intel-gw-v2-6-8bd07367a298@dev.tdt.de The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
On 30/03/2026 11:07, Florian Eckert wrote: > The ATU information is already set in the dwc core if it is specified in > the DTS. The driver uses its own value here [1]. This information is > hardware specific and should therefore be maintained in the DTS rather > than in the source. > > Backwards compatibility is not an issue here [5], as the driver is > exclusively used by Maxlinear. What does that mean exactly? It is not used outside of Maxlinear company, so it is purely internal device and no one outside of Maxlinear has it? Then we can as well remove it and I don't quite get why you are working on this (since no one can use it outside of Maxlinear...). > > Old DTS entry for PCIe: > > reg = <0xd1000000 0x1000>, > <0xd3000000 0x20000>, > <0xd0c41000.0x1000>; > reg-names = "dbi", "config", "app"; > > New DTS entry for PCIe: > > reg = <0xd1000000 0x1000>, > <0xd10c0000 0x1000>, > <0xd3000000 0x20000>, > <0xd0c41000.0x1000>; > reg-names = "dbi", "atu", "config", "app"; Drop, irrelevant. You still break all users of this binding. Best regards, Krzysztof
On 2026-03-30 11:50, Krzysztof Kozlowski wrote: > On 30/03/2026 11:07, Florian Eckert wrote: >> The ATU information is already set in the dwc core if it is specified >> in >> the DTS. The driver uses its own value here [1]. This information is >> hardware specific and should therefore be maintained in the DTS rather >> than in the source. >> >> Backwards compatibility is not an issue here [5], as the driver is >> exclusively used by Maxlinear. > > What does that mean exactly? It is not used outside of Maxlinear > company, so it is purely internal device and no one outside of > Maxlinear > has it? Background information: The PCIe IP core is only available for Maxlinear’s URX851 and URX850 SoCs. However, the chip was originally developed by Intel when they acquired Lantiq’s home networking division in 2015 [1] for this SoCs. In 2020 the home network division was sold to Maxlinear [2]. Since then, Maxlinear has been responsible for the driver. However, their SDK is outdated and based on kernel 5.15. Other than that, not much is happening! Even the developers listed as maintainers can no longer be reached. When it came to the patch set, the email couldn't be delivered to the responsible developer 'Chuanhua Lei <lchuanhua@maxlinear.com>' either. The email bounced back. The company I work for is using the chip and is currently in the process of extracting the key components from the SDK so that the SoC URX851/URX850 can work again with a mainline kernel again. [1] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home [2] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform > Then we can as well remove it and I don't quite get why you are working > on this (since no one can use it outside of Maxlinear...). Maxlinear continues to sell that SoC. They are *not' EOL. It’s just that their Board Support Package (SDK) is no longer up to date. >> >> Old DTS entry for PCIe: >> >> reg = <0xd1000000 0x1000>, >> <0xd3000000 0x20000>, >> <0xd0c41000.0x1000>; >> reg-names = "dbi", "config", "app"; >> >> New DTS entry for PCIe: >> >> reg = <0xd1000000 0x1000>, >> <0xd10c0000 0x1000>, >> <0xd3000000 0x20000>, >> <0xd0c41000.0x1000>; >> reg-names = "dbi", "atu", "config", "app"; > > Drop, irrelevant. You still break all users of this binding. As noted in link [3], a Maxlinear developer has stated that backwards compatibility is not necessary here, as the IP core is used exclusively by Maxlinear`s URX851 and URX850 SoC`s. We use these SoCs in our Produkt for internet home gateway routers. [3] https://lore.kernel.org/all/BY3PR19MB507667CE7531D863E1E5F8AEBDD82@BY3PR19MB5076.namprd19.prod.outlook.com/ > Best regards, > Krzysztof
On Mon, Mar 30, 2026 at 12:52:16PM +0200, Florian Eckert wrote: > > > On 2026-03-30 11:50, Krzysztof Kozlowski wrote: > > On 30/03/2026 11:07, Florian Eckert wrote: > > > The ATU information is already set in the dwc core if it is > > > specified in > > > the DTS. The driver uses its own value here [1]. This information is > > > hardware specific and should therefore be maintained in the DTS rather > > > than in the source. > > > > > > Backwards compatibility is not an issue here [5], as the driver is > > > exclusively used by Maxlinear. > > > > What does that mean exactly? It is not used outside of Maxlinear > > company, so it is purely internal device and no one outside of Maxlinear > > has it? > > Background information: > > The PCIe IP core is only available for Maxlinear’s URX851 and > URX850 SoCs. However, the chip was originally developed by Intel when > they acquired Lantiq’s home networking division in 2015 [1] for this > SoCs. In 2020 the home network division was sold to Maxlinear [2]. > > Since then, Maxlinear has been responsible for the driver. However, > their SDK is outdated and based on kernel 5.15. Other than that, not v5.15 DTS user of this binding is still valid user. Why would you break it? > much is happening! Even the developers listed as maintainers can no > longer be reached. When it came to the patch set, the email couldn't > be delivered to the responsible developer > 'Chuanhua Lei <lchuanhua@maxlinear.com>' either. The email bounced > back. Not really relevant to my question. I understand that this is not maintained, but I asked about backwards compatibility. Backwards compatibility of the ABI means that existing in-tree and ALL out-of-tree users of given ABI must keep working fine. Properties with lists have strictly defined order, so changing that order is considered ABI break, unless you prove otherwise. Calling code unmantained is not proving that ABI is not broken. > > The company I work for is using the chip and is currently in the > process of extracting the key components from the SDK so that the > SoC URX851/URX850 can work again with a mainline kernel again. > > [1] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home > [2] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform > > > Then we can as well remove it and I don't quite get why you are working > > on this (since no one can use it outside of Maxlinear...). > > Maxlinear continues to sell that SoC. They are *not' EOL. > It’s just that their Board Support Package (SDK) is no longer > up to date. > > > > > > > Old DTS entry for PCIe: > > > > > > reg = <0xd1000000 0x1000>, > > > <0xd3000000 0x20000>, > > > <0xd0c41000.0x1000>; > > > reg-names = "dbi", "config", "app"; > > > > > > New DTS entry for PCIe: > > > > > > reg = <0xd1000000 0x1000>, > > > <0xd10c0000 0x1000>, > > > <0xd3000000 0x20000>, > > > <0xd0c41000.0x1000>; > > > reg-names = "dbi", "atu", "config", "app"; > > > > Drop, irrelevant. You still break all users of this binding. > > As noted in link [3], a Maxlinear developer has stated that > backwards compatibility is not necessary here, as the IP core > is used exclusively by Maxlinear`s URX851 and URX850 SoC`s. > > We use these SoCs in our Produkt for internet home gateway > routers. > > [3] https://lore.kernel.org/all/BY3PR19MB507667CE7531D863E1E5F8AEBDD82@BY3PR19MB5076.namprd19.prod.outlook.com/ OK, yet I do not understand "driver is only used for internally". How Maxlinear engineer can know all projects around the world and all 7 billion people if they use that ABI? And if they are right and no one uses it outside of Maxlinear, then let's drop this code. It's dead code, no? Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.