* [PATCH 5/9] arm64: dts: hisilicon: hip07: move non-MMIO node out of soc
From: Krzysztof Kozlowski @ 2024-04-02 19:31 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240402193148.62323-1-krzk@kernel.org>
Non-MMIO devices, which are BTW not really part of the SoC, should not
be within simple-bus, as reported by dtc W=1 warning:
hi p07.dtsi:1486.20-1493.5: Warning (unit_address_vs_reg): /soc/ethernet@4: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 72 ++++++++++++------------
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 81d907ef43ed..9d1e86553ea8 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1013,6 +1013,42 @@ p1_its_dsa_b: msi-controller@408c6000000 {
};
};
+ eth0: ethernet-0 {
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <4>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth1: ethernet-1 {
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <5>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth2: ethernet-2 {
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <0>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth3: ethernet-3 {
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <1>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
@@ -1483,42 +1519,6 @@ port@5 {
};
};
- eth0: ethernet@4 {
- compatible = "hisilicon,hns-nic-v2";
- ae-handle = <&dsaf0>;
- port-idx-in-ae = <4>;
- local-mac-address = [00 00 00 00 00 00];
- status = "disabled";
- dma-coherent;
- };
-
- eth1: ethernet@5 {
- compatible = "hisilicon,hns-nic-v2";
- ae-handle = <&dsaf0>;
- port-idx-in-ae = <5>;
- local-mac-address = [00 00 00 00 00 00];
- status = "disabled";
- dma-coherent;
- };
-
- eth2: ethernet@0 {
- compatible = "hisilicon,hns-nic-v2";
- ae-handle = <&dsaf0>;
- port-idx-in-ae = <0>;
- local-mac-address = [00 00 00 00 00 00];
- status = "disabled";
- dma-coherent;
- };
-
- eth3: ethernet@1 {
- compatible = "hisilicon,hns-nic-v2";
- ae-handle = <&dsaf0>;
- port-idx-in-ae = <1>;
- local-mac-address = [00 00 00 00 00 00];
- status = "disabled";
- dma-coherent;
- };
-
infiniband@c4000000 {
compatible = "hisilicon,hns-roce-v1";
reg = <0x0 0xc4000000 0x0 0x100000>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/9] arm64: dts: hisilicon: hip06: correct unit addresses
From: Krzysztof Kozlowski @ 2024-04-02 19:31 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240402193148.62323-1-krzk@kernel.org>
Correct dsa and pcie unit addresses to fix dtc W=1 warnings:
hip06.dtsi:439.23-571.5: Warning (simple_bus_reg): /soc/dsa@c7000000: simple-bus unit address format error, expected "c5000000"
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index 249ca3b4b703..3d7285e6700e 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -472,7 +472,7 @@ phy1: ethernet-phy@1 {
};
};
- dsaf0: dsa@c7000000 {
+ dsaf0: dsa@c5000000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "hisilicon,hns-dsaf-v2";
@@ -733,7 +733,7 @@ sas2: sas@a3000000 {
status = "disabled";
};
- pcie0: pcie@a0090000 {
+ pcie0: pcie@b0000000 {
compatible = "hisilicon,hip06-pcie-ecam";
reg = <0 0xb0000000 0 0x2000000>,
<0 0xa0090000 0 0x10000>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/9] arm64: dts: hisilicon: hip06: move non-MMIO node out of soc
From: Krzysztof Kozlowski @ 2024-04-02 19:31 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240402193148.62323-1-krzk@kernel.org>
Non-MMIO devices, which are BTW not really part of the SoC, should not
be within simple-bus, as reported by dtc W=1 warning:
hip06.dtsi:377.18-381.5: Warning (simple_bus_reg): /soc/refclk: missing or empty reg/ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 84 ++++++++++++------------
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index f46c33d10750..249ca3b4b703 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -258,6 +258,48 @@ its_dsa: msi-controller@c6000000 {
};
};
+ eth2: ethernet-0 {
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <0>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth3: ethernet-1 {
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <1>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth0: ethernet-4 {
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <4>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth1: ethernet-5 {
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <5>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ refclk: refclk {
+ compatible = "fixed-clock";
+ clock-frequency = <50000000>;
+ #clock-cells = <0>;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
@@ -374,12 +416,6 @@ uart0: serial@2f8 {
};
};
- refclk: refclk {
- compatible = "fixed-clock";
- clock-frequency = <50000000>;
- #clock-cells = <0>;
- };
-
usb_ohci: usb@a7030000 {
compatible = "generic-ohci";
reg = <0x0 0xa7030000 0x0 0x10000>;
@@ -570,42 +606,6 @@ port@5 {
};
};
- eth0: ethernet-4 {
- compatible = "hisilicon,hns-nic-v2";
- ae-handle = <&dsaf0>;
- port-idx-in-ae = <4>;
- local-mac-address = [00 00 00 00 00 00];
- status = "disabled";
- dma-coherent;
- };
-
- eth1: ethernet-5 {
- compatible = "hisilicon,hns-nic-v2";
- ae-handle = <&dsaf0>;
- port-idx-in-ae = <5>;
- local-mac-address = [00 00 00 00 00 00];
- status = "disabled";
- dma-coherent;
- };
-
- eth2: ethernet-0 {
- compatible = "hisilicon,hns-nic-v2";
- ae-handle = <&dsaf0>;
- port-idx-in-ae = <0>;
- local-mac-address = [00 00 00 00 00 00];
- status = "disabled";
- dma-coherent;
- };
-
- eth3: ethernet-1 {
- compatible = "hisilicon,hns-nic-v2";
- ae-handle = <&dsaf0>;
- port-idx-in-ae = <1>;
- local-mac-address = [00 00 00 00 00 00];
- status = "disabled";
- dma-coherent;
- };
-
sas0: sas@c3000000 {
compatible = "hisilicon,hip06-sas-v2";
reg = <0 0xc3000000 0 0x10000>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/9] arm64: dts: hisilicon: hip05: move non-MMIO node out of soc
From: Krzysztof Kozlowski @ 2024-04-02 19:31 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Non-MMIO devices, which are BTW not really part of the SoC, should not
be within simple-bus, as reported by dtc W=1 warning:
hip05.dtsi:301.30-305.5: Warning (simple_bus_reg): /soc/refclk200mhz: missing or empty reg/ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/hisilicon/hip05.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
index 65ddc0698f82..d0912ca5f237 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
@@ -279,6 +279,12 @@ its_dsa: msi-controller@c6000000 {
};
};
+ refclk200mhz: refclk200mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <200000000>;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
@@ -298,12 +304,6 @@ soc {
#size-cells = <2>;
ranges;
- refclk200mhz: refclk200mhz {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <200000000>;
- };
-
uart0: serial@80300000 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x80300000 0x0 0x10000>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/9] arm64: dts: hisilicon: hip05-d02: correct local-bus unit addresses
From: Krzysztof Kozlowski @ 2024-04-02 19:31 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240402193148.62323-1-krzk@kernel.org>
Correct local-bus children unit addresses to fix dtc W=1 warnings:
hip05-d02.dts:57.16-76.4: Warning (simple_bus_reg): /soc/local-bus@80380000/nor-flash@0,0: simple-bus unit address format error, expected "0"
hip05-d02.dts:78.11-81.4: Warning (simple_bus_reg): /soc/local-bus@80380000/cpld@1,0: simple-bus unit address format error, expected "100000000"
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
index c4eaebbb448f..b7792d443189 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
@@ -54,7 +54,7 @@ &lbc {
ranges = <0 0 0x0 0x90000000 0x08000000>,
<1 0 0x0 0x98000000 0x08000000>;
- nor-flash@0,0 {
+ nor-flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "numonyx,js28f00a", "cfi-flash";
@@ -75,7 +75,7 @@ partition@1000000 {
};
};
- cpld@1,0 {
+ cpld@100000000 {
compatible = "hisilicon,hip05-cpld";
reg = <1 0x0 0x100>;
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v1 1/1] spi: pxa2xx: Call pxa_ssp_free() after getting the SSP type
From: Mark Brown @ 2024-04-02 19:30 UTC (permalink / raw)
To: linux-arm-kernel, linux-spi, linux-kernel, Andy Shevchenko
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik
In-Reply-To: <20240402144523.3402063-1-andriy.shevchenko@linux.intel.com>
On Tue, 02 Apr 2024 17:45:23 +0300, Andy Shevchenko wrote:
> pxa_ssp_request() implies a reference counting, hence the pxa_ssp_free()
> must be called when we are done. Add missed call.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: pxa2xx: Call pxa_ssp_free() after getting the SSP type
commit: 33aa27a09e9df5860fe495032a067504d025db77
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: marvell: turris-mox: drop unneeded flash address/size-cells
From: Marek Behún @ 2024-04-02 19:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Robert Marko, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20240402183240.49193-2-krzk@kernel.org>
On Tue, 2 Apr 2024 20:32:39 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Flash node uses single "partition" node to describe partitions, so
> remove deprecated address/size-cells properties to also fix dtc W=1
> warnings:
>
> armada-3720-turris-mox.dts:218.10-255.4: Warning (avoid_unnecessary_addr_size): /soc/internal-regs@d0000000/spi@10600/flash@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
> index f1a9f2234359..54453b0a91f9 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
> @@ -216,8 +216,6 @@ &spi0 {
> assigned-clock-rates = <20000000>;
>
> flash@0 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> compatible = "jedec,spi-nor";
> reg = <0>;
> spi-max-frequency = <20000000>;
Reviewed-by: Marek Behún <kabel@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: marvell: espressobin-ultra: fix Ethernet Switch unit address
From: Andrew Lunn @ 2024-04-02 19:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Robert Marko, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240402183240.49193-3-krzk@kernel.org>
On Tue, Apr 02, 2024 at 08:32:40PM +0200, Krzysztof Kozlowski wrote:
> The Espressobin Ultra DTS includes Espressobin DTSI which defines
> ethernet-switch@1 node. The Ultra DTS overrides "reg" to 3, but that
> leaves still old unit address which conflicts with the new phy@1 node
> (W=1 dtc warning):
>
> armada-3720-espressobin.dtsi:148.29-203.4: Warning (unique_unit_address_if_enabled): /soc/internal-regs@d0000000/mdio@32004/ethernet-switch@1: duplicate unit-address (also used in node /soc/internal-regs@d0000000/mdio@32004/ethernet-phy@1)
>
> Fix this by deleting ethernet-switch@1 node and merging original node
> with code from Ultra DTS into new ethernet-switch@3.
That is a bit ugly, having the exact same code twice.
Could the bulk of the switch node be put into a .dtsi file, and then
included as needed
&mdio {
switch0: ethernet-switch@1 {
reg = <1>;
include "armada-3720-espressobin-switch.dtsi"
}
}
&mdio {
switch0: ethernet-switch@3 {
reg = <3>;
include "armada-3720-espressobin-switch.dtsi"
}
}
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: marvell: turris-mox: drop unneeded flash address/size-cells
From: Andrew Lunn @ 2024-04-02 19:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Robert Marko, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240402183240.49193-2-krzk@kernel.org>
On Tue, Apr 02, 2024 at 08:32:39PM +0200, Krzysztof Kozlowski wrote:
> Flash node uses single "partition" node to describe partitions, so
> remove deprecated address/size-cells properties to also fix dtc W=1
> warnings:
>
> armada-3720-turris-mox.dts:218.10-255.4: Warning (avoid_unnecessary_addr_size): /soc/internal-regs@d0000000/spi@10600/flash@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: marvell: eDPU: drop redundant address/size-cells
From: Andrew Lunn @ 2024-04-02 19:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Robert Marko, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240402183240.49193-1-krzk@kernel.org>
On Tue, Apr 02, 2024 at 08:32:38PM +0200, Krzysztof Kozlowski wrote:
> The ethernet-switch node does not have children with unit addresses, so
> address/size-cells are not really correct, as reported by dtc W=1
> warning:
>
> armada-3720-eDPU.dts:26.19-60.4: Warning (avoid_unnecessary_addr_size): /soc/internal-regs@d0000000/mdio@32004/switch@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> This probably also fixes dtbs_check warning, but I could not find it, so
> not sure about that.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 05/13] mm/arch: Provide pud_pfn() fallback
From: Nathan Chancellor @ 2024-04-02 19:05 UTC (permalink / raw)
To: peterx
Cc: linux-mm, linux-kernel, Yang Shi, Kirill A . Shutemov,
Mike Kravetz, John Hubbard, Michael Ellerman, Andrew Jones,
Muchun Song, linux-riscv, linuxppc-dev, Christophe Leroy,
Andrew Morton, Christoph Hellwig, Lorenzo Stoakes, Matthew Wilcox,
Rik van Riel, linux-arm-kernel, Andrea Arcangeli,
David Hildenbrand, Aneesh Kumar K . V, Vlastimil Babka,
James Houghton, Jason Gunthorpe, Mike Rapoport, Axel Rasmussen,
Huacai Chen, WANG Xuerui, loongarch
In-Reply-To: <20240327152332.950956-6-peterx@redhat.com>
Hi Peter (and LoongArch folks),
On Wed, Mar 27, 2024 at 11:23:24AM -0400, peterx@redhat.com wrote:
> From: Peter Xu <peterx@redhat.com>
>
> The comment in the code explains the reasons. We took a different approach
> comparing to pmd_pfn() by providing a fallback function.
>
> Another option is to provide some lower level config options (compare to
> HUGETLB_PAGE or THP) to identify which layer an arch can support for such
> huge mappings. However that can be an overkill.
>
> Cc: Mike Rapoport (IBM) <rppt@kernel.org>
> Cc: Matthew Wilcox <willy@infradead.org>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
> arch/riscv/include/asm/pgtable.h | 1 +
> arch/s390/include/asm/pgtable.h | 1 +
> arch/sparc/include/asm/pgtable_64.h | 1 +
> arch/x86/include/asm/pgtable.h | 1 +
> include/linux/pgtable.h | 10 ++++++++++
> 5 files changed, 14 insertions(+)
>
> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> index 20242402fc11..0ca28cc8e3fa 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -646,6 +646,7 @@ static inline unsigned long pmd_pfn(pmd_t pmd)
>
> #define __pud_to_phys(pud) (__page_val_to_pfn(pud_val(pud)) << PAGE_SHIFT)
>
> +#define pud_pfn pud_pfn
> static inline unsigned long pud_pfn(pud_t pud)
> {
> return ((__pud_to_phys(pud) & PUD_MASK) >> PAGE_SHIFT);
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 1a71cb19c089..6cbbe473f680 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -1414,6 +1414,7 @@ static inline unsigned long pud_deref(pud_t pud)
> return (unsigned long)__va(pud_val(pud) & origin_mask);
> }
>
> +#define pud_pfn pud_pfn
> static inline unsigned long pud_pfn(pud_t pud)
> {
> return __pa(pud_deref(pud)) >> PAGE_SHIFT;
> diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
> index 4d1bafaba942..26efc9bb644a 100644
> --- a/arch/sparc/include/asm/pgtable_64.h
> +++ b/arch/sparc/include/asm/pgtable_64.h
> @@ -875,6 +875,7 @@ static inline bool pud_leaf(pud_t pud)
> return pte_val(pte) & _PAGE_PMD_HUGE;
> }
>
> +#define pud_pfn pud_pfn
> static inline unsigned long pud_pfn(pud_t pud)
> {
> pte_t pte = __pte(pud_val(pud));
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index cefc7a84f7a4..273f7557218c 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -234,6 +234,7 @@ static inline unsigned long pmd_pfn(pmd_t pmd)
> return (pfn & pmd_pfn_mask(pmd)) >> PAGE_SHIFT;
> }
>
> +#define pud_pfn pud_pfn
> static inline unsigned long pud_pfn(pud_t pud)
> {
> phys_addr_t pfn = pud_val(pud);
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 600e17d03659..75fe309a4e10 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -1817,6 +1817,16 @@ typedef unsigned int pgtbl_mod_mask;
> #define pte_leaf_size(x) PAGE_SIZE
> #endif
>
> +/*
> + * We always define pmd_pfn for all archs as it's used in lots of generic
> + * code. Now it happens too for pud_pfn (and can happen for larger
> + * mappings too in the future; we're not there yet). Instead of defining
> + * it for all archs (like pmd_pfn), provide a fallback.
> + */
> +#ifndef pud_pfn
> +#define pud_pfn(x) ({ BUILD_BUG(); 0; })
> +#endif
> +
> /*
> * Some architectures have MMUs that are configurable or selectable at boot
> * time. These lead to variable PTRS_PER_x. For statically allocated arrays it
> --
> 2.44.0
>
This BUILD_BUG() triggers for LoongArch with their defconfig, so it
seems like they need to provide an implementation of pud_pfn()?
In function 'follow_huge_pud',
inlined from 'follow_pud_mask' at mm/gup.c:1075:10,
inlined from 'follow_p4d_mask' at mm/gup.c:1105:9,
inlined from 'follow_page_mask' at mm/gup.c:1151:10:
include/linux/compiler_types.h:460:45: error: call to '__compiletime_assert_382' declared with attribute error: BUILD_BUG failed
460 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler_types.h:441:25: note: in definition of macro '__compiletime_assert'
441 | prefix ## suffix(); \
| ^~~~~~
include/linux/compiler_types.h:460:9: note: in expansion of macro '_compiletime_assert'
460 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:59:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
| ^~~~~~~~~~~~~~~~
include/linux/pgtable.h:1887:23: note: in expansion of macro 'BUILD_BUG'
1887 | #define pud_pfn(x) ({ BUILD_BUG(); 0; })
| ^~~~~~~~~
mm/gup.c:679:29: note: in expansion of macro 'pud_pfn'
679 | unsigned long pfn = pud_pfn(pud);
| ^~~~~~~
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 0/3] gpiolib: Get rid of gpio_free_array()/gpio_request_array()
From: Andy Shevchenko @ 2024-04-02 18:43 UTC (permalink / raw)
To: linux-gpio, linux-doc, linux-kernel, linux-arm-kernel
Cc: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Alex Shi,
Yanteng Si, Hu Haowen, Daniel Mack, Haojian Zhuang,
Robert Jarzmik, Russell King
In-Reply-To: <20240307135109.3778316-1-andriy.shevchenko@linux.intel.com>
On Thu, Mar 07, 2024 at 03:49:02PM +0200, Andy Shevchenko wrote:
> There are only two users left of the gpio_free_array()/gpio_request_array().
> Convert them to very basic legacy APIs (it requires much less work for
> now) and drop no more used gpio_free_array()/gpio_request_array().
Any comments on this? We really want to get rid of the legacy APIs.
While at here, would be also good to have a comment/tag for
https://lore.kernel.org/r/20240327193138.2385910-7-andriy.shevchenko@linux.intel.com
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 13/13] mm/gup: Handle hugetlb in the generic follow_page_mask code
From: David Hildenbrand @ 2024-04-02 18:43 UTC (permalink / raw)
To: Peter Xu
Cc: Ryan Roberts, linux-mm, linux-kernel, Yang Shi,
Kirill A . Shutemov, Mike Kravetz, John Hubbard, Michael Ellerman,
Andrew Jones, Muchun Song, linux-riscv, linuxppc-dev,
Christophe Leroy, Andrew Morton, Christoph Hellwig,
Lorenzo Stoakes, Matthew Wilcox, Rik van Riel, linux-arm-kernel,
Andrea Arcangeli, Aneesh Kumar K . V, Vlastimil Babka,
James Houghton, Jason Gunthorpe, Mike Rapoport, Axel Rasmussen
In-Reply-To: <ZgxG8-LNZ0Hqtp6J@x1n>
On 02.04.24 19:57, Peter Xu wrote:
> On Tue, Apr 02, 2024 at 06:39:31PM +0200, David Hildenbrand wrote:
>> On 02.04.24 18:20, Peter Xu wrote:
>>> On Tue, Apr 02, 2024 at 05:26:28PM +0200, David Hildenbrand wrote:
>>>> On 02.04.24 16:48, Ryan Roberts wrote:
>>>>> Hi Peter,
>>>
>>> Hey, Ryan,
>>>
>>> Thanks for the report!
>>>
>>>>>
>>>>> On 27/03/2024 15:23, peterx@redhat.com wrote:
>>>>>> From: Peter Xu <peterx@redhat.com>
>>>>>>
>>>>>> Now follow_page() is ready to handle hugetlb pages in whatever form, and
>>>>>> over all architectures. Switch to the generic code path.
>>>>>>
>>>>>> Time to retire hugetlb_follow_page_mask(), following the previous
>>>>>> retirement of follow_hugetlb_page() in 4849807114b8.
>>>>>>
>>>>>> There may be a slight difference of how the loops run when processing slow
>>>>>> GUP over a large hugetlb range on cont_pte/cont_pmd supported archs: each
>>>>>> loop of __get_user_pages() will resolve one pgtable entry with the patch
>>>>>> applied, rather than relying on the size of hugetlb hstate, the latter may
>>>>>> cover multiple entries in one loop.
>>>>>>
>>>>>> A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over
>>>>>> a tight loop of slow gup after the path switched. That shouldn't be a
>>>>>> problem because slow-gup should not be a hot path for GUP in general: when
>>>>>> page is commonly present, fast-gup will already succeed, while when the
>>>>>> page is indeed missing and require a follow up page fault, the slow gup
>>>>>> degrade will probably buried in the fault paths anyway. It also explains
>>>>>> why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
>>>>>> accelerate thp gup even for "pages != NULL"") lands, the latter not part of
>>>>>> a performance analysis but a side benefit. If the performance will be a
>>>>>> concern, we can consider handle CONT_PTE in follow_page().
>>>>>>
>>>>>> Before that is justified to be necessary, keep everything clean and simple.
>>>>>>
>>>>>> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
>>>>>> Signed-off-by: Peter Xu <peterx@redhat.com>
>>>>>
>>>>> Afraid I'm seeing an oops when running gup_longterm test on arm64 with current mm-unstable. Git bisect blames this patch. The oops reproduces for me every time on 2 different machines:
>>>>>
>>>>>
>>>>> [ 9.340416] kernel BUG at mm/gup.c:778!
>>>>> [ 9.340746] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
>>>>> [ 9.341199] Modules linked in:
>>>>> [ 9.341481] CPU: 1 PID: 1159 Comm: gup_longterm Not tainted 6.9.0-rc2-00210-g910ff1a347e4 #11
>>>>> [ 9.342232] Hardware name: linux,dummy-virt (DT)
>>>>> [ 9.342647] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>>>> [ 9.343195] pc : follow_page_mask+0x4d4/0x880
>>>>> [ 9.343580] lr : follow_page_mask+0x4d4/0x880
>>>>> [ 9.344018] sp : ffff8000898b3aa0
>>>>> [ 9.344345] x29: ffff8000898b3aa0 x28: fffffdffc53973e8 x27: 00003c0005d08000
>>>>> [ 9.345028] x26: ffff00014e5cfd08 x25: ffffd3513a40c000 x24: fffffdffc5d08000
>>>>> [ 9.345682] x23: ffffc1ffc0000000 x22: 0000000000080101 x21: ffff8000898b3ba8
>>>>> [ 9.346337] x20: 0000fffff4200000 x19: ffff00014e52d508 x18: 0000000000000010
>>>>> [ 9.347005] x17: 5f656e6f7a5f7369 x16: 2120262620296567 x15: 6170286461654865
>>>>> [ 9.347713] x14: 6761502128454741 x13: 2929656761702865 x12: 6761705f65636976
>>>>> [ 9.348371] x11: 65645f656e6f7a5f x10: ffffd3513b31d6e0 x9 : ffffd3513852f090
>>>>> [ 9.349062] x8 : 00000000ffffefff x7 : ffffd3513b31d6e0 x6 : 0000000000000000
>>>>> [ 9.349753] x5 : ffff00017ff98cc8 x4 : 0000000000000fff x3 : 0000000000000000
>>>>> [ 9.350397] x2 : 0000000000000000 x1 : ffff000190e8b480 x0 : 0000000000000052
>>>>> [ 9.351097] Call trace:
>>>>> [ 9.351312] follow_page_mask+0x4d4/0x880
>>>>> [ 9.351700] __get_user_pages+0xf4/0x3e8
>>>>> [ 9.352089] __gup_longterm_locked+0x204/0xa70
>>>>> [ 9.352516] pin_user_pages+0x88/0xc0
>>>>> [ 9.352873] gup_test_ioctl+0x860/0xc40
>>>>> [ 9.353249] __arm64_sys_ioctl+0xb0/0x100
>>>>> [ 9.353648] invoke_syscall+0x50/0x128
>>>>> [ 9.354022] el0_svc_common.constprop.0+0x48/0xf8
>>>>> [ 9.354488] do_el0_svc+0x28/0x40
>>>>> [ 9.354822] el0_svc+0x34/0xe0
>>>>> [ 9.355128] el0t_64_sync_handler+0x13c/0x158
>>>>> [ 9.355489] el0t_64_sync+0x190/0x198
>>>>> [ 9.355793] Code: aa1803e0 d000d8e1 91220021 97fff560 (d4210000)
>>>>> [ 9.356280] ---[ end trace 0000000000000000 ]---
>>>>> [ 9.356651] note: gup_longterm[1159] exited with irqs disabled
>>>>> [ 9.357141] note: gup_longterm[1159] exited with preempt_count 2
>>>>> [ 9.358033] ------------[ cut here ]------------
>>>>> [ 9.358800] WARNING: CPU: 1 PID: 0 at kernel/context_tracking.c:128 ct_kernel_exit.constprop.0+0x108/0x120
>>>>> [ 9.360157] Modules linked in:
>>>>> [ 9.360541] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 6.9.0-rc2-00210-g910ff1a347e4 #11
>>>>> [ 9.361626] Hardware name: linux,dummy-virt (DT)
>>>>> [ 9.362087] pstate: 204003c5 (nzCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>>>> [ 9.362758] pc : ct_kernel_exit.constprop.0+0x108/0x120
>>>>> [ 9.363306] lr : ct_idle_enter+0x10/0x20
>>>>> [ 9.363845] sp : ffff8000801abdc0
>>>>> [ 9.364222] x29: ffff8000801abdc0 x28: 0000000000000000 x27: 0000000000000000
>>>>> [ 9.364961] x26: 0000000000000000 x25: ffff00014149d780 x24: 0000000000000000
>>>>> [ 9.365557] x23: 0000000000000000 x22: ffffd3513b299d48 x21: ffffd3513a785730
>>>>> [ 9.366239] x20: ffffd3513b299c28 x19: ffff00017ffa7da0 x18: 0000fffff5ffffff
>>>>> [ 9.366869] x17: 0000000000000000 x16: 1fffe0002a21a8c1 x15: 0000000000000000
>>>>> [ 9.367524] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000002
>>>>> [ 9.368207] x11: 0000000000000001 x10: 0000000000000ad0 x9 : ffffd35138589230
>>>>> [ 9.369123] x8 : ffff00014149e2b0 x7 : 0000000000000000 x6 : 000000000f8c0fb2
>>>>> [ 9.370403] x5 : 4000000000000002 x4 : ffff2cb045825000 x3 : ffff8000801abdc0
>>>>> [ 9.371170] x2 : ffffd3513a782da0 x1 : 4000000000000000 x0 : ffffd3513a782da0
>>>>> [ 9.372279] Call trace:
>>>>> [ 9.372519] ct_kernel_exit.constprop.0+0x108/0x120
>>>>> [ 9.373216] ct_idle_enter+0x10/0x20
>>>>> [ 9.373562] default_idle_call+0x3c/0x160
>>>>> [ 9.374055] do_idle+0x21c/0x280
>>>>> [ 9.374394] cpu_startup_entry+0x3c/0x50
>>>>> [ 9.374797] secondary_start_kernel+0x140/0x168
>>>>> [ 9.375220] __secondary_switched+0xb8/0xc0
>>>>> [ 9.375875] ---[ end trace 0000000000000000 ]---
>>>>>
>>>>>
>>>>> The oops trigger is at mm/gup.c:778:
>>>>> VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page);
>>>>>
>>>>>
>>>>> This is the output of gup_longterm (last output is just before oops):
>>>>>
>>>>> # [INFO] detected hugetlb page size: 2048 KiB
>>>>> # [INFO] detected hugetlb page size: 32768 KiB
>>>>> # [INFO] detected hugetlb page size: 64 KiB
>>>>> # [INFO] detected hugetlb page size: 1048576 KiB
>>>>> TAP version 13
>>>>> 1..70
>>>>> # [RUN] R/W longterm GUP pin in MAP_SHARED file mapping ... with memfd
>>>>> ok 1 Should have worked
>>>>> # [RUN] R/W longterm GUP pin in MAP_SHARED file mapping ... with tmpfile
>>>>> ok 2 Should have failed
>>>>> # [RUN] R/W longterm GUP pin in MAP_SHARED file mapping ... with local tmpfile
>>>>> ok 3 Should have failed
>>>>> # [RUN] R/W longterm GUP pin in MAP_SHARED file mapping ... with memfd hugetlb (2048 kB)
>>>>> ok 4 Should have worked
>>>>> # [RUN] R/W longterm GUP pin in MAP_SHARED file mapping ... with memfd hugetlb (32768 kB)
>>>>>
>>>>>
>>>>> So 2M passed ok, and its failing for 32M, which is cont-pmd. I'm guessing you're trying to iterate 2M into a cont-pmd folio and ending up with an unexpected tail page?
>>>>
>>>> I assume we find the expected tail page, it's just that the check
>>>>
>>>> VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page);
>>>>
>>>> Doesn't make sense with hugetlb folios. We might have a tail page mapped in
>>>> a cont-pmd entry. As soon as we call follow_huge_pmd() on "not the first
>>>> cont-pmd entry", we trigger this check.
>>>>
>>>> Likely this sanity check must also allow for hugetlb folios. Or we should
>>>> just remove it completely.
>>>
>>> Right, IMHO it'll be easier we remove it, actually I see there's one more
>>> at the end, so I think we need to remove both.
>>>
>>>>
>>>> In the past, we wanted to make sure that we never get tail pages of THP from
>>>> PMD entries, because something would currently be broken (we don't support
>>>> THP > PMD).
>>>
>>> There's probably one more thing we need to do, on allowing
>>> PageAnonExclusive() to work with hugetlb tails. Even if we remove the
>>> warnings and if I read the code right, we can BUG_ON again on checking tail
>>> pages over anon-exclusive for PageHuge.
>>>
>>> So I assume to fix it completely, we may need two changes: Patch 1 to
>>> prepare PageAnonExclusive() to work on hugetlb tails, then patch 2 to be
>>> squashed into the patch "mm/gup: handle huge pmd for follow_pmd_mask()".
>>> Note: not this patch to fixup, as this patch only does the "switchover" to
>>> the new path, the culprit should be the other patch..
>>>
>>> I have them attached below first, before I'll also go and see whether I can
>>> run some arm tests later today or tomorrow. David, any comments from
>>> anon-exclusive side?
>>
>> I added the PageAnonExclusive checks for hugetlb back then, because calling
>> it on a tail page indicated real trouble for hugetlb.
>>
>> Well, and I didn't want to have runtime-hugetlb checks in PageAnonExclusive
>> code called on certainly-not-hugetlb code paths.
>>
>> Personally, I'd fixup the problematic callsite where we know nothing nasty
>> is happening (like we did for gup_must_unshare(), because we don't expect
>> hugetlb tail pages from arbitrary other code).
>>
>> But as I'm getting closer to a folio_test_anon_exclusive() implementation as
>> we speak (closer, but not done :) ... ), where I'd remove any such hugetlb
>> special handling, I don't particularly care how we handle GUP here in the
>> meantime.
>
> That's what I was looking for and found missing just now, when I wanted to
> allow follow_huge_pmd() pass page / folio (which will be the head then)
> properly into different checks. I think that patch 1 is the simplest I can
> come up with that works mostly like what you said before a follow up
> cleanup on top if possible. It mostly pushed the existing runtime check in
> gup_must_unshare() to be more generic.
>
> IIUC it's also a matter of whether you'd want PageAnonExclusive() to take
> care of both thp + hugetlb in one shot, rather than let callers handle it
> by things like "if (PageHuge()) ... else ...", which I would try to avoid.
I tried to not let the caller pass in things that didn't make any sense.
Getting a tail page on a hugetlb folio in a page table walker except
GUP-fast was completely bogus before your patch.
PageAnonExclusive was designed to be set on the page that was pointed to
by a PTE, like having an additional PTE bit. Cont-pte/cont-pmd with the
hugetlb fuzz around it we all love (huge_pte_offset()) did the right
thing, because it abstracted the "multiple cont-pte/cont-pmd" PTEs to
just a single logical PTE, with a single dedicated PageAnonExclusive.
So "conceptually", the caller that knows how the "single logical PTE"
was the one to handle it. That meant, GUP-fast needed to be special,
because it was unaware of the huge_pte_offset() logic.
But that seems to change now as we are changing our page table walkers,
so I don't particularly care how we handle it.
> It seems so far cleaner to allow PageAnonExclusive() take whatever tail
> pages, thp or hugetlb. But maybe your ultimate patchset can be even better
> than that.
At least that part will be much cleaner.
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] arm64: dts: marvell: espressobin-ultra: fix Ethernet Switch unit address
From: Krzysztof Kozlowski @ 2024-04-02 18:32 UTC (permalink / raw)
To: Robert Marko, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240402183240.49193-1-krzk@kernel.org>
The Espressobin Ultra DTS includes Espressobin DTSI which defines
ethernet-switch@1 node. The Ultra DTS overrides "reg" to 3, but that
leaves still old unit address which conflicts with the new phy@1 node
(W=1 dtc warning):
armada-3720-espressobin.dtsi:148.29-203.4: Warning (unique_unit_address_if_enabled): /soc/internal-regs@d0000000/mdio@32004/ethernet-switch@1: duplicate unit-address (also used in node /soc/internal-regs@d0000000/mdio@32004/ethernet-phy@1)
Fix this by deleting ethernet-switch@1 node and merging original node
with code from Ultra DTS into new ethernet-switch@3.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Not tested on hardware.
---
.../marvell/armada-3720-espressobin-ultra.dts | 104 +++++++++++-------
1 file changed, 67 insertions(+), 37 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
index 870bb380a40a..b3cc2b7b5d19 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
@@ -114,54 +114,84 @@ &usb3 {
};
&mdio {
+ /* Switch is @3, not @1 */
+ /delete-node/ ethernet-switch@1;
extphy: ethernet-phy@1 {
reg = <1>;
reset-gpios = <&gpionb 2 GPIO_ACTIVE_LOW>;
};
-};
-&switch0 {
- reg = <3>;
+ switch0: ethernet-switch@3 {
+ compatible = "marvell,mv88e6085";
+ reg = <3>;
- reset-gpios = <&gpiosb 23 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpiosb 23 GPIO_ACTIVE_LOW>;
+ dsa,member = <0 0>;
- ethernet-ports {
- switch0port1: ethernet-port@1 {
- reg = <1>;
- label = "lan0";
- phy-handle = <&switch0phy0>;
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch0port0: ethernet-port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <ð0>;
+ phy-mode = "rgmii-id";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ switch0port1: ethernet-port@1 {
+ reg = <1>;
+ label = "lan0";
+ phy-handle = <&switch0phy0>;
+ };
+
+ switch0port2: ethernet-port@2 {
+ reg = <2>;
+ label = "lan1";
+ phy-handle = <&switch0phy1>;
+ };
+
+ switch0port3: ethernet-port@3 {
+ reg = <3>;
+ label = "lan2";
+ phy-handle = <&switch0phy2>;
+ };
+
+ switch0port4: ethernet-port@4 {
+ reg = <4>;
+ label = "lan3";
+ phy-handle = <&switch0phy3>;
+ };
+
+ switch0port5: ethernet-port@5 {
+ reg = <5>;
+ label = "wan";
+ phy-handle = <&extphy>;
+ phy-mode = "sgmii";
+ };
};
- switch0port2: ethernet-port@2 {
- reg = <2>;
- label = "lan1";
- phy-handle = <&switch0phy1>;
- };
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
- switch0port3: ethernet-port@3 {
- reg = <3>;
- label = "lan2";
- phy-handle = <&switch0phy2>;
- };
-
- switch0port4: ethernet-port@4 {
- reg = <4>;
- label = "lan3";
- phy-handle = <&switch0phy3>;
- };
-
- switch0port5: ethernet-port@5 {
- reg = <5>;
- label = "wan";
- phy-handle = <&extphy>;
- phy-mode = "sgmii";
- };
- };
-
- mdio {
- switch0phy3: ethernet-phy@14 {
- reg = <0x14>;
+ switch0phy0: ethernet-phy@11 {
+ reg = <0x11>;
+ };
+ switch0phy1: ethernet-phy@12 {
+ reg = <0x12>;
+ };
+ switch0phy2: ethernet-phy@13 {
+ reg = <0x13>;
+ };
+ switch0phy3: ethernet-phy@14 {
+ reg = <0x14>;
+ };
};
};
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: marvell: turris-mox: drop unneeded flash address/size-cells
From: Krzysztof Kozlowski @ 2024-04-02 18:32 UTC (permalink / raw)
To: Robert Marko, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240402183240.49193-1-krzk@kernel.org>
Flash node uses single "partition" node to describe partitions, so
remove deprecated address/size-cells properties to also fix dtc W=1
warnings:
armada-3720-turris-mox.dts:218.10-255.4: Warning (avoid_unnecessary_addr_size): /soc/internal-regs@d0000000/spi@10600/flash@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
index f1a9f2234359..54453b0a91f9 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
@@ -216,8 +216,6 @@ &spi0 {
assigned-clock-rates = <20000000>;
flash@0 {
- #address-cells = <1>;
- #size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <20000000>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: marvell: eDPU: drop redundant address/size-cells
From: Krzysztof Kozlowski @ 2024-04-02 18:32 UTC (permalink / raw)
To: Robert Marko, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski
The ethernet-switch node does not have children with unit addresses, so
address/size-cells are not really correct, as reported by dtc W=1
warning:
armada-3720-eDPU.dts:26.19-60.4: Warning (avoid_unnecessary_addr_size): /soc/internal-regs@d0000000/mdio@32004/switch@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
This probably also fixes dtbs_check warning, but I could not find it, so
not sure about that.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts b/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts
index d6d37a1f6f38..91c2f8b4edfa 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts
@@ -25,8 +25,6 @@ &mdio {
/* Actual device is MV88E6361 */
switch: switch@0 {
compatible = "marvell,mv88e6190";
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
status = "disabled";
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 3/3] phy: freescale: imx8q-hsio: Add i.MX8Q HSIO PHY driver support
From: kernel test robot @ 2024-04-02 18:26 UTC (permalink / raw)
To: Richard Zhu, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
frank.li, conor+dt
Cc: oe-kbuild-all, hongxing.zhu, linux-phy, devicetree,
linux-arm-kernel, linux-kernel, kernel, imx
In-Reply-To: <1712036704-21064-4-git-send-email-hongxing.zhu@nxp.com>
Hi Richard,
kernel test robot noticed the following build warnings:
[auto build test WARNING on robh/for-next]
[also build test WARNING on linus/master v6.9-rc2]
[cannot apply to next-20240402]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Richard-Zhu/dt-bindings-phy-phy-imx8-pcie-Add-binding-for-i-MX8Q-HSIO-SerDes-PHY/20240402-140347
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link: https://lore.kernel.org/r/1712036704-21064-4-git-send-email-hongxing.zhu%40nxp.com
patch subject: [PATCH v2 3/3] phy: freescale: imx8q-hsio: Add i.MX8Q HSIO PHY driver support
config: arm-allmodconfig (https://download.01.org/0day-ci/archive/20240403/202404030236.zuDJQOtw-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240403/202404030236.zuDJQOtw-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404030236.zuDJQOtw-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/phy/freescale/phy-fsl-imx8q-hsio.c:34: warning: "MODE_MASK" redefined
34 | #define MODE_MASK GENMASK(20, 17)
|
In file included from arch/arm/include/asm/ptrace.h:10,
from arch/arm/include/asm/irqflags.h:7,
from include/linux/irqflags.h:18,
from arch/arm/include/asm/bitops.h:28,
from include/linux/bitops.h:68,
from include/linux/kernel.h:23,
from include/linux/clk.h:13,
from drivers/phy/freescale/phy-fsl-imx8q-hsio.c:6:
arch/arm/include/uapi/asm/ptrace.h:67: note: this is the location of the previous definition
67 | #define MODE_MASK 0x0000001f
|
vim +/MODE_MASK +34 drivers/phy/freescale/phy-fsl-imx8q-hsio.c
27
28 /* i.MX8Q HSIO registers */
29 #define CTRL0 0x0
30 #define APB_RSTN_0 BIT(0)
31 #define APB_RSTN_1 BIT(1)
32 #define PIPE_RSTN_0_MASK GENMASK(25, 24)
33 #define PIPE_RSTN_1_MASK GENMASK(27, 26)
> 34 #define MODE_MASK GENMASK(20, 17)
35 #define MODE_PCIE 0x0
36 #define MODE_SATA 0x4
37 #define DEVICE_TYPE_MASK GENMASK(27, 24)
38 #define EPCS_TXDEEMP BIT(5)
39 #define EPCS_TXDEEMP_SEL BIT(6)
40 #define EPCS_PHYRESET_N BIT(7)
41 #define RESET_N BIT(12)
42
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: rockchip: grf: Add missing type to 'pcie-phy' node
From: Conor Dooley @ 2024-04-02 18:23 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20240401204959.1698106-1-robh@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 251 bytes --]
On Mon, Apr 01, 2024 at 03:49:58PM -0500, Rob Herring wrote:
> 'pcie-phy' is missing any type. Add 'type: object' to indicate it's a
> node.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: phy: Add i.MX8Q HSIO SerDes PHY binding
From: Conor Dooley @ 2024-04-02 18:16 UTC (permalink / raw)
To: Frank Li
Cc: Richard Zhu, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-phy, devicetree, linux-arm-kernel, linux-kernel,
kernel, imx
In-Reply-To: <ZgwU8edE3VFYngWR@lizhi-Precision-Tower-5810>
[-- Attachment #1.1: Type: text/plain, Size: 1310 bytes --]
On Tue, Apr 02, 2024 at 10:23:45AM -0400, Frank Li wrote:
> On Tue, Apr 02, 2024 at 01:45:03PM +0800, Richard Zhu wrote:
> > Add i.MX8QM and i.MX8QXP HSIO SerDes PHY binding.
> > - Use the controller ID to specify which controller is binded to the
> > PHY.
> > - Introduce one HSIO configuration, mandatory required to set
> > "PCIE_AB_SELECT" and "PHY_X1_EPCS_SEL" during the initialization.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
>
> You missed all conor's comments.
> Please double check v1's comments.
> > + fsl,refclk-pad-mode:
> > + description: |
> > + Specifies the mode of the refclk pad used. It can be UNUSED(PHY
> > + refclock is derived from SoC internal source), INPUT(PHY refclock
> > + is provided externally via the refclk pad) or OUTPUT(PHY refclock
> > + is derived from SoC internal source and provided on the refclk pad).
> > + Refer include/dt-bindings/phy/phy-imx8-pcie.h for the constants
> > + to be used.
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + enum: [ 0, 1, 2 ]
>
> I remember needn't enum because there are header file.
Yah, specifically my comments about this property were missed and were
probably the most meaningful comments I left.
Thanks for the reminder Frank.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 17/18] dt-bindings: pci: rockchip,rk3399-pcie-ep: Add ep-gpios property
From: Krzysztof Kozlowski @ 2024-04-02 18:10 UTC (permalink / raw)
To: Damien Le Moal, Manivannan Sadhasivam, Lorenzo Pieralisi,
Kishon Vijay Abraham I, Shawn Lin, Krzysztof Wilczyński,
Bjorn Helgaas, Heiko Stuebner, linux-pci, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
Cc: linux-rockchip, linux-arm-kernel, Rick Wertenbroek,
Wilfred Mallawa, Niklas Cassel
In-Reply-To: <be2a0fa0-9d5d-45c3-810a-56d6924c8891@kernel.org>
On 02/04/2024 09:55, Damien Le Moal wrote:
> On 4/2/24 16:38, Damien Le Moal wrote:
>> On 4/2/24 16:33, Krzysztof Kozlowski wrote:
>>> On 02/04/2024 01:36, Damien Le Moal wrote:
>>>> On 4/1/24 18:57, Krzysztof Kozlowski wrote:
>>>>> On 01/04/2024 01:06, Damien Le Moal wrote:
>>>>>> On 3/30/24 18:16, Krzysztof Kozlowski wrote:
>>>>>>> On 30/03/2024 05:19, Damien Le Moal wrote:
>>>>>>>> From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
>>>>>>>>
>>>>>>>> Describe the `ep-gpios` property which is used to map the PERST# input
>>>>>>>> signal for endpoint mode.
>>>>>>>>
>>>>>>>> Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
>>>>>>>> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
>>>>>>>> ---
>>>>>>>> .../devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml | 3 +++
>>>>>>>> 1 file changed, 3 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
>>>>>>>> index 6b62f6f58efe..9331d44d6963 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
>>>>>>>> @@ -30,6 +30,9 @@ properties:
>>>>>>>> maximum: 32
>>>>>>>> default: 32
>>>>>>>>
>>>>>>>> + ep-gpios:
>>>>>>>> + description: Input GPIO configured for the PERST# signal.
>>>>>>>
>>>>>>> Missing maxItems. But more important: why existing property perst-gpios,
>>>>>>> which you already have there in common schema, is not correct for this case?
>>>>>>
>>>>>> I am confused... Where do you find perst-gpios defined for the rk3399 ?
>>>>>> Under Documentation/devicetree/bindings/pci/, the only schema I see using
>>>>>> perst-gpios property are for the qcom (Qualcomm) controllers.
>>>>>
>>>>> You are right, it's so far only in Qualcomm.
>>>>>
>>>>>> The RC bindings for the rockchip rk3399 PCIe controller
>>>>>> (pci/rockchip,rk3399-pcie.yaml) already define the ep-gpios property. So if
>>>>>
>>>>> Any reason why this cannot be named like GPIO? Is there already a user
>>>>> of this in Linux kernel? Commit msg says nothing about this, so that's
>>>>> why I would expect name matching the signal.
>>>>
>>>> The RC-mode PCIe controller node of the rk3399 DTS already defines the ep-gpios
>>>> property for RC side PERST# signal handling. So we simply reused the exact same
>>>> name to be consistent between RC and EP. I personnally have no preferences. If
>>>> there is an effort to rename such signal with some preferred pattern, I will
>>>> follow. For the EP node, there was no PERST signal handling in the driver and
>>>> no property defined for it, so any name is fine. "perst-gpios" would indeed be
>>>> a better name, but again, given that the RC controller node has ep-gpios, we
>>>> reused that. What is your recommendation here ?
>>>
>>> Actually I don't know, perst and ep would work for me. If you do not
>>> have code for this in the driver yet (nothing is shared between ep and
>>> host), then maybe let's go with perst to match the actual name.
>>
>> That works for me. The other simple solution would be to move the RC node
>> ep-gpios description to the common schema pci/rockchip,rk3399-pcie-common.yaml,
>> maybe ? Otherwise, perst-gpios like the Qualcomm schemas would be nice too.
>
> Thinking more about this, I think moving the ep-gpios description to the common
> schema is the right thing to do given that the driver uses common code between
> RC and EP to get that property. But if that is not acceptable, I can rename it
> and get that property in the controller EP mode initialization code. That will
> be add a little more code in the driver.
I forgot that it is actually the same hardware, so if host has
"ep-gpios" already then EP mode should have the same property. Common
schema is good idea.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: watchdog: Convert Aspeed binding to DT schema
From: Rob Herring @ 2024-04-02 18:07 UTC (permalink / raw)
To: Andrew Jeffery
Cc: wim, linux, krzysztof.kozlowski+dt, conor+dt, joel, zev,
linux-watchdog, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20240402120118.282035-1-andrew@codeconstruct.com.au>
On Tue, Apr 02, 2024 at 10:31:18PM +1030, Andrew Jeffery wrote:
> Squash warnings such as:
>
> ```
> arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-galaxy100.dtb: /ahb/apb@1e600000/watchdog@1e785000: failed to match any schema with compatible: ['aspeed,ast2400-wdt']
> ```
>
> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
> ---
> .../bindings/watchdog/aspeed,ast2400-wdt.yaml | 130 ++++++++++++++++++
> .../bindings/watchdog/aspeed-wdt.txt | 73 ----------
> 2 files changed, 130 insertions(+), 73 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> delete mode 100644 Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml b/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> new file mode 100644
> index 000000000000..10fcb50c4051
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> @@ -0,0 +1,130 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/watchdog/aspeed,ast2400-wdt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed watchdog timer controllers
> +
> +maintainers:
> + - Andrew Jeffery <andrew@codeconstruct.com.au>
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2400-wdt
> + - aspeed,ast2500-wdt
> + - aspeed,ast2600-wdt
> +
> + reg:
> + maxItems: 1
> +
> + clocks: true
# and order/function if more than 1 must be defined.
Please note it was missing from the original binding in the commit
message.
> +
> + aspeed,reset-type:
> + enum:
> + - cpu
> + - soc
> + - system
> + - none
> + description: |
> + Reset behaviour - The watchdog can be programmed to generate one of three
> + different types of reset when a timeout occcurs.
> +
> + Specifying 'cpu' will only reset the processor on a timeout event.
> +
> + Specifying 'soc' will reset a configurable subset of the SoC's controllers
> + on a timeout event. Controllers critical to the SoC's operation may remain untouched.
> +
> + Specifying 'system' will reset all controllers on a timeout event, as if EXTRST had been asserted.
> + Specifying "none" will cause the timeout event to have no reset effect.
> + Another watchdog engine on the chip must be used for chip reset operations.
> +
> + The default reset type is "system"
Express as schema:
default: system
> +
> + aspeed,alt-boot:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
Don't need '|' if no formatting to preserve.
> + Direct the watchdog to configure the SoC to boot from the alternative boot
> + region if a timeout occurs.
> +
> + aspeed,external-signal:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + Assert the timeout event on an external signal pin associated with the
> + watchdog controller instance. The pin must be muxed appropriately.
> +
> + aspeed,ext-pulse-duration:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + The duration, in microseconds, of the pulse emitted on the external signal pin
Wrap at <80. Period at end needed.
> +
> + aspeed,ext-push-pull:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + If aspeed,external-signal is specified in the node, set the external
> + signal pin's drive type to push-pull. If aspeed,ext-push-pull is not
> + specified then the pin is configured as open-drain.
> +
> + aspeed,ext-active-high:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + If both aspeed,external-signal and aspeed,ext-push-pull are specified in
> + the node, set the pulse polarity to active-high. If aspeed,ext-active-high
> + is not specified then the pin is configured as active-low.
> +
> + aspeed,reset-mask:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 2
> + description: |
> + A bitmaks indicating which peripherals will be reset if the watchdog
> + timer expires. On AST2500 SoCs this should be a single word defined using
> + the AST2500_WDT_RESET_* macros; on AST2600 SoCs this should be a two-word
> + array with the first word defined using the AST2600_WDT_RESET1_* macros,
> + and the second word defined using the AST2600_WDT_RESET2_* macros.
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - if:
> + anyOf:
> + - required:
> + - aspeed,ext-push-pull
> + - required:
> + - aspeed,ext-active-high
> + - required:
> + - aspeed,reset-mask
> + then:
> + properties:
> + compatible:
> + enum:
> + - aspeed,ast2500-wdt
> + - aspeed,ast2600-wdt
> + - if:
> + required:
> + - aspeed,ext-active-high
> + then:
> + required:
> + - aspeed,ext-push-pull
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + wdt1: watchdog@1e785000 {
Drop unused labels.
> + compatible = "aspeed,ast2400-wdt";
> + reg = <0x1e785000 0x1c>;
> + aspeed,reset-type = "system";
> + aspeed,external-signal;
> + };
> + - |
> + #include <dt-bindings/watchdog/aspeed-wdt.h>
> + wdt2: watchdog@1e785040 {
> + compatible = "aspeed,ast2600-wdt";
> + reg = <0x1e785040 0x40>;
> + aspeed,reset-mask = <AST2600_WDT_RESET1_DEFAULT
> + (AST2600_WDT_RESET2_DEFAULT & ~AST2600_WDT_RESET2_LPC)>;
> + };
> diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> deleted file mode 100644
> index 3208adb3e52e..000000000000
> --- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> +++ /dev/null
> @@ -1,73 +0,0 @@
> -Aspeed Watchdog Timer
> -
> -Required properties:
> - - compatible: must be one of:
> - - "aspeed,ast2400-wdt"
> - - "aspeed,ast2500-wdt"
> - - "aspeed,ast2600-wdt"
> -
> - - reg: physical base address of the controller and length of memory mapped
> - region
> -
> -Optional properties:
> -
> - - aspeed,reset-type = "cpu|soc|system|none"
> -
> - Reset behavior - Whenever a timeout occurs the watchdog can be programmed
> - to generate one of three different, mutually exclusive, types of resets.
> -
> - Type "none" can be specified to indicate that no resets are to be done.
> - This is useful in situations where another watchdog engine on chip is
> - to perform the reset.
> -
> - If 'aspeed,reset-type=' is not specified the default is to enable system
> - reset.
> -
> - Reset types:
> -
> - - cpu: Reset CPU on watchdog timeout
> -
> - - soc: Reset 'System on Chip' on watchdog timeout
> -
> - - system: Reset system on watchdog timeout
> -
> - - none: No reset is performed on timeout. Assumes another watchdog
> - engine is responsible for this.
> -
> - - aspeed,alt-boot: If property is present then boot from alternate block.
> - - aspeed,external-signal: If property is present then signal is sent to
> - external reset counter (only WDT1 and WDT2). If not
> - specified no external signal is sent.
> - - aspeed,ext-pulse-duration: External signal pulse duration in microseconds
> -
> -Optional properties for AST2500-compatible watchdogs:
> - - aspeed,ext-push-pull: If aspeed,external-signal is present, set the pin's
> - drive type to push-pull. The default is open-drain.
> - - aspeed,ext-active-high: If aspeed,external-signal is present and and the pin
> - is configured as push-pull, then set the pulse
> - polarity to active-high. The default is active-low.
> -
> -Optional properties for AST2500- and AST2600-compatible watchdogs:
> - - aspeed,reset-mask: A bitmask indicating which peripherals will be reset if
> - the watchdog timer expires. On AST2500 this should be a
> - single word defined using the AST2500_WDT_RESET_* macros;
> - on AST2600 this should be a two-word array with the first
> - word defined using the AST2600_WDT_RESET1_* macros and the
> - second word defined using the AST2600_WDT_RESET2_* macros.
> -
> -Examples:
> -
> - wdt1: watchdog@1e785000 {
> - compatible = "aspeed,ast2400-wdt";
> - reg = <0x1e785000 0x1c>;
> - aspeed,reset-type = "system";
> - aspeed,external-signal;
> - };
> -
> - #include <dt-bindings/watchdog/aspeed-wdt.h>
> - wdt2: watchdog@1e785040 {
> - compatible = "aspeed,ast2600-wdt";
> - reg = <0x1e785040 0x40>;
> - aspeed,reset-mask = <AST2600_WDT_RESET1_DEFAULT
> - (AST2600_WDT_RESET2_DEFAULT & ~AST2600_WDT_RESET2_LPC)>;
> - };
> --
> 2.39.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Krzysztof Kozlowski @ 2024-04-02 18:06 UTC (permalink / raw)
To: Siddharth Vadapalli
Cc: lee, robh, krzk+dt, conor+dt, devicetree, linux-kernel,
linux-arm-kernel, srk
In-Reply-To: <30065bdc-ccef-4610-b1c1-7661f801b8e9@ti.com>
On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
>>> contain the MAC Address programmed in the eFuse. Add compatible for
>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
>>> registers within the System Controller device-tree node. The default MAC
>>> Address for the interface corresponding to the first MAC port will be set
>>> to the value programmed in the eFuse.
>>>
>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>> ---
>>>
>>> This patch is based on linux-next tagged next-20240402.
>>
>> Where is the DTS using it?
>
> The current implementation in the device-tree for older TI K3 SoCs is as
> follows:
>
> cpsw_port1: port@1 {
> reg = <1>;
> ti,mac-only;
> label = "port1";
> phys = <&phy_gmii_sel 1>;
> mac-address = [00 00 00 00 00 00];
> ti,syscon-efuse = <&wkup_conf 0x200>;
> };
>
> The "ti,syscon-efuse" property passes the reference to the System
> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> within the CTRL_MMR space.
Please reference upstream DTS or lore link to patch under review.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 13/13] mm/gup: Handle hugetlb in the generic follow_page_mask code
From: Peter Xu @ 2024-04-02 17:58 UTC (permalink / raw)
To: Ryan Roberts
Cc: David Hildenbrand, linux-mm, linux-kernel, Yang Shi,
Kirill A . Shutemov, Mike Kravetz, John Hubbard, Michael Ellerman,
Andrew Jones, Muchun Song, linux-riscv, linuxppc-dev,
Christophe Leroy, Andrew Morton, Christoph Hellwig,
Lorenzo Stoakes, Matthew Wilcox, Rik van Riel, linux-arm-kernel,
Andrea Arcangeli, Aneesh Kumar K . V, Vlastimil Babka,
James Houghton, Jason Gunthorpe, Mike Rapoport, Axel Rasmussen
In-Reply-To: <f4aff3e9-1d78-4bb8-a6f3-2887b9928b54@arm.com>
On Tue, Apr 02, 2024 at 05:46:57PM +0100, Ryan Roberts wrote:
> I'll leave you to do the testing on this, if that's ok.
Definitely. I'll test and send formal patches.
>
> Just to make my config explicit, I have this kernel command line, which reserves
> hugetlbs of all sizes for the tests:
>
> "transparent_hugepage=madvise earlycon root=/dev/vda2 secretmem.enable
> hugepagesz=1G hugepages=0:2,1:2 hugepagesz=32M hugepages=0:2,1:2
> default_hugepagesz=2M hugepages=0:64,1:64 hugepagesz=64K hugepages=0:2,1:2"
This helps, thanks.
--
Peter Xu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 13/13] mm/gup: Handle hugetlb in the generic follow_page_mask code
From: Peter Xu @ 2024-04-02 17:57 UTC (permalink / raw)
To: David Hildenbrand
Cc: Ryan Roberts, linux-mm, linux-kernel, Yang Shi,
Kirill A . Shutemov, Mike Kravetz, John Hubbard, Michael Ellerman,
Andrew Jones, Muchun Song, linux-riscv, linuxppc-dev,
Christophe Leroy, Andrew Morton, Christoph Hellwig,
Lorenzo Stoakes, Matthew Wilcox, Rik van Riel, linux-arm-kernel,
Andrea Arcangeli, Aneesh Kumar K . V, Vlastimil Babka,
James Houghton, Jason Gunthorpe, Mike Rapoport, Axel Rasmussen
In-Reply-To: <8b0b24bb-3c38-4f27-a2c9-f7d7adc4a115@redhat.com>
On Tue, Apr 02, 2024 at 06:39:31PM +0200, David Hildenbrand wrote:
> On 02.04.24 18:20, Peter Xu wrote:
> > On Tue, Apr 02, 2024 at 05:26:28PM +0200, David Hildenbrand wrote:
> > > On 02.04.24 16:48, Ryan Roberts wrote:
> > > > Hi Peter,
> >
> > Hey, Ryan,
> >
> > Thanks for the report!
> >
> > > >
> > > > On 27/03/2024 15:23, peterx@redhat.com wrote:
> > > > > From: Peter Xu <peterx@redhat.com>
> > > > >
> > > > > Now follow_page() is ready to handle hugetlb pages in whatever form, and
> > > > > over all architectures. Switch to the generic code path.
> > > > >
> > > > > Time to retire hugetlb_follow_page_mask(), following the previous
> > > > > retirement of follow_hugetlb_page() in 4849807114b8.
> > > > >
> > > > > There may be a slight difference of how the loops run when processing slow
> > > > > GUP over a large hugetlb range on cont_pte/cont_pmd supported archs: each
> > > > > loop of __get_user_pages() will resolve one pgtable entry with the patch
> > > > > applied, rather than relying on the size of hugetlb hstate, the latter may
> > > > > cover multiple entries in one loop.
> > > > >
> > > > > A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over
> > > > > a tight loop of slow gup after the path switched. That shouldn't be a
> > > > > problem because slow-gup should not be a hot path for GUP in general: when
> > > > > page is commonly present, fast-gup will already succeed, while when the
> > > > > page is indeed missing and require a follow up page fault, the slow gup
> > > > > degrade will probably buried in the fault paths anyway. It also explains
> > > > > why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
> > > > > accelerate thp gup even for "pages != NULL"") lands, the latter not part of
> > > > > a performance analysis but a side benefit. If the performance will be a
> > > > > concern, we can consider handle CONT_PTE in follow_page().
> > > > >
> > > > > Before that is justified to be necessary, keep everything clean and simple.
> > > > >
> > > > > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> > > > > Signed-off-by: Peter Xu <peterx@redhat.com>
> > > >
> > > > Afraid I'm seeing an oops when running gup_longterm test on arm64 with current mm-unstable. Git bisect blames this patch. The oops reproduces for me every time on 2 different machines:
> > > >
> > > >
> > > > [ 9.340416] kernel BUG at mm/gup.c:778!
> > > > [ 9.340746] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
> > > > [ 9.341199] Modules linked in:
> > > > [ 9.341481] CPU: 1 PID: 1159 Comm: gup_longterm Not tainted 6.9.0-rc2-00210-g910ff1a347e4 #11
> > > > [ 9.342232] Hardware name: linux,dummy-virt (DT)
> > > > [ 9.342647] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > [ 9.343195] pc : follow_page_mask+0x4d4/0x880
> > > > [ 9.343580] lr : follow_page_mask+0x4d4/0x880
> > > > [ 9.344018] sp : ffff8000898b3aa0
> > > > [ 9.344345] x29: ffff8000898b3aa0 x28: fffffdffc53973e8 x27: 00003c0005d08000
> > > > [ 9.345028] x26: ffff00014e5cfd08 x25: ffffd3513a40c000 x24: fffffdffc5d08000
> > > > [ 9.345682] x23: ffffc1ffc0000000 x22: 0000000000080101 x21: ffff8000898b3ba8
> > > > [ 9.346337] x20: 0000fffff4200000 x19: ffff00014e52d508 x18: 0000000000000010
> > > > [ 9.347005] x17: 5f656e6f7a5f7369 x16: 2120262620296567 x15: 6170286461654865
> > > > [ 9.347713] x14: 6761502128454741 x13: 2929656761702865 x12: 6761705f65636976
> > > > [ 9.348371] x11: 65645f656e6f7a5f x10: ffffd3513b31d6e0 x9 : ffffd3513852f090
> > > > [ 9.349062] x8 : 00000000ffffefff x7 : ffffd3513b31d6e0 x6 : 0000000000000000
> > > > [ 9.349753] x5 : ffff00017ff98cc8 x4 : 0000000000000fff x3 : 0000000000000000
> > > > [ 9.350397] x2 : 0000000000000000 x1 : ffff000190e8b480 x0 : 0000000000000052
> > > > [ 9.351097] Call trace:
> > > > [ 9.351312] follow_page_mask+0x4d4/0x880
> > > > [ 9.351700] __get_user_pages+0xf4/0x3e8
> > > > [ 9.352089] __gup_longterm_locked+0x204/0xa70
> > > > [ 9.352516] pin_user_pages+0x88/0xc0
> > > > [ 9.352873] gup_test_ioctl+0x860/0xc40
> > > > [ 9.353249] __arm64_sys_ioctl+0xb0/0x100
> > > > [ 9.353648] invoke_syscall+0x50/0x128
> > > > [ 9.354022] el0_svc_common.constprop.0+0x48/0xf8
> > > > [ 9.354488] do_el0_svc+0x28/0x40
> > > > [ 9.354822] el0_svc+0x34/0xe0
> > > > [ 9.355128] el0t_64_sync_handler+0x13c/0x158
> > > > [ 9.355489] el0t_64_sync+0x190/0x198
> > > > [ 9.355793] Code: aa1803e0 d000d8e1 91220021 97fff560 (d4210000)
> > > > [ 9.356280] ---[ end trace 0000000000000000 ]---
> > > > [ 9.356651] note: gup_longterm[1159] exited with irqs disabled
> > > > [ 9.357141] note: gup_longterm[1159] exited with preempt_count 2
> > > > [ 9.358033] ------------[ cut here ]------------
> > > > [ 9.358800] WARNING: CPU: 1 PID: 0 at kernel/context_tracking.c:128 ct_kernel_exit.constprop.0+0x108/0x120
> > > > [ 9.360157] Modules linked in:
> > > > [ 9.360541] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 6.9.0-rc2-00210-g910ff1a347e4 #11
> > > > [ 9.361626] Hardware name: linux,dummy-virt (DT)
> > > > [ 9.362087] pstate: 204003c5 (nzCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > [ 9.362758] pc : ct_kernel_exit.constprop.0+0x108/0x120
> > > > [ 9.363306] lr : ct_idle_enter+0x10/0x20
> > > > [ 9.363845] sp : ffff8000801abdc0
> > > > [ 9.364222] x29: ffff8000801abdc0 x28: 0000000000000000 x27: 0000000000000000
> > > > [ 9.364961] x26: 0000000000000000 x25: ffff00014149d780 x24: 0000000000000000
> > > > [ 9.365557] x23: 0000000000000000 x22: ffffd3513b299d48 x21: ffffd3513a785730
> > > > [ 9.366239] x20: ffffd3513b299c28 x19: ffff00017ffa7da0 x18: 0000fffff5ffffff
> > > > [ 9.366869] x17: 0000000000000000 x16: 1fffe0002a21a8c1 x15: 0000000000000000
> > > > [ 9.367524] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000002
> > > > [ 9.368207] x11: 0000000000000001 x10: 0000000000000ad0 x9 : ffffd35138589230
> > > > [ 9.369123] x8 : ffff00014149e2b0 x7 : 0000000000000000 x6 : 000000000f8c0fb2
> > > > [ 9.370403] x5 : 4000000000000002 x4 : ffff2cb045825000 x3 : ffff8000801abdc0
> > > > [ 9.371170] x2 : ffffd3513a782da0 x1 : 4000000000000000 x0 : ffffd3513a782da0
> > > > [ 9.372279] Call trace:
> > > > [ 9.372519] ct_kernel_exit.constprop.0+0x108/0x120
> > > > [ 9.373216] ct_idle_enter+0x10/0x20
> > > > [ 9.373562] default_idle_call+0x3c/0x160
> > > > [ 9.374055] do_idle+0x21c/0x280
> > > > [ 9.374394] cpu_startup_entry+0x3c/0x50
> > > > [ 9.374797] secondary_start_kernel+0x140/0x168
> > > > [ 9.375220] __secondary_switched+0xb8/0xc0
> > > > [ 9.375875] ---[ end trace 0000000000000000 ]---
> > > >
> > > >
> > > > The oops trigger is at mm/gup.c:778:
> > > > VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page);
> > > >
> > > >
> > > > This is the output of gup_longterm (last output is just before oops):
> > > >
> > > > # [INFO] detected hugetlb page size: 2048 KiB
> > > > # [INFO] detected hugetlb page size: 32768 KiB
> > > > # [INFO] detected hugetlb page size: 64 KiB
> > > > # [INFO] detected hugetlb page size: 1048576 KiB
> > > > TAP version 13
> > > > 1..70
> > > > # [RUN] R/W longterm GUP pin in MAP_SHARED file mapping ... with memfd
> > > > ok 1 Should have worked
> > > > # [RUN] R/W longterm GUP pin in MAP_SHARED file mapping ... with tmpfile
> > > > ok 2 Should have failed
> > > > # [RUN] R/W longterm GUP pin in MAP_SHARED file mapping ... with local tmpfile
> > > > ok 3 Should have failed
> > > > # [RUN] R/W longterm GUP pin in MAP_SHARED file mapping ... with memfd hugetlb (2048 kB)
> > > > ok 4 Should have worked
> > > > # [RUN] R/W longterm GUP pin in MAP_SHARED file mapping ... with memfd hugetlb (32768 kB)
> > > >
> > > >
> > > > So 2M passed ok, and its failing for 32M, which is cont-pmd. I'm guessing you're trying to iterate 2M into a cont-pmd folio and ending up with an unexpected tail page?
> > >
> > > I assume we find the expected tail page, it's just that the check
> > >
> > > VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page);
> > >
> > > Doesn't make sense with hugetlb folios. We might have a tail page mapped in
> > > a cont-pmd entry. As soon as we call follow_huge_pmd() on "not the first
> > > cont-pmd entry", we trigger this check.
> > >
> > > Likely this sanity check must also allow for hugetlb folios. Or we should
> > > just remove it completely.
> >
> > Right, IMHO it'll be easier we remove it, actually I see there's one more
> > at the end, so I think we need to remove both.
> >
> > >
> > > In the past, we wanted to make sure that we never get tail pages of THP from
> > > PMD entries, because something would currently be broken (we don't support
> > > THP > PMD).
> >
> > There's probably one more thing we need to do, on allowing
> > PageAnonExclusive() to work with hugetlb tails. Even if we remove the
> > warnings and if I read the code right, we can BUG_ON again on checking tail
> > pages over anon-exclusive for PageHuge.
> >
> > So I assume to fix it completely, we may need two changes: Patch 1 to
> > prepare PageAnonExclusive() to work on hugetlb tails, then patch 2 to be
> > squashed into the patch "mm/gup: handle huge pmd for follow_pmd_mask()".
> > Note: not this patch to fixup, as this patch only does the "switchover" to
> > the new path, the culprit should be the other patch..
> >
> > I have them attached below first, before I'll also go and see whether I can
> > run some arm tests later today or tomorrow. David, any comments from
> > anon-exclusive side?
>
> I added the PageAnonExclusive checks for hugetlb back then, because calling
> it on a tail page indicated real trouble for hugetlb.
>
> Well, and I didn't want to have runtime-hugetlb checks in PageAnonExclusive
> code called on certainly-not-hugetlb code paths.
>
> Personally, I'd fixup the problematic callsite where we know nothing nasty
> is happening (like we did for gup_must_unshare(), because we don't expect
> hugetlb tail pages from arbitrary other code).
>
> But as I'm getting closer to a folio_test_anon_exclusive() implementation as
> we speak (closer, but not done :) ... ), where I'd remove any such hugetlb
> special handling, I don't particularly care how we handle GUP here in the
> meantime.
That's what I was looking for and found missing just now, when I wanted to
allow follow_huge_pmd() pass page / folio (which will be the head then)
properly into different checks. I think that patch 1 is the simplest I can
come up with that works mostly like what you said before a follow up
cleanup on top if possible. It mostly pushed the existing runtime check in
gup_must_unshare() to be more generic.
IIUC it's also a matter of whether you'd want PageAnonExclusive() to take
care of both thp + hugetlb in one shot, rather than let callers handle it
by things like "if (PageHuge()) ... else ...", which I would try to avoid.
It seems so far cleaner to allow PageAnonExclusive() take whatever tail
pages, thp or hugetlb. But maybe your ultimate patchset can be even better
than that.
Thanks,
--
Peter Xu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFT 01/10] arm64: dts: microchip: sparx5: fix mdio reg
From: Conor Dooley @ 2024-04-02 17:46 UTC (permalink / raw)
To: Steen Hegelund
Cc: Rob Herring, Daniel Machon, Bjarni Jonasson, linux-kernel,
Krzysztof Kozlowski, Claudiu Beznea, devicetree, linux-arm-kernel,
Krzysztof Kozlowski, UNGLinuxDriver, David S. Miller,
Lars Povlsen
In-Reply-To: <b3d818df8819d2fb3e96fa61b277d49941d9b01b.camel@microchip.com>
[-- Attachment #1.1: Type: text/plain, Size: 2259 bytes --]
Hey,
On Tue, Apr 02, 2024 at 04:00:32PM +0200, Steen Hegelund wrote:
> On Mon, 2024-04-01 at 17:37 +0200, Krzysztof Kozlowski wrote:
> > [Some people who received this message don't often get email from
> > krzk@kernel.org. Learn why this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> >
> > Correct the reg address of mdio node to match unit address. Assume
> > the
> > reg is not correct and unit address was correct, because there is
> > alerady node using the existing reg 0x110102d4.
> >
> > sparx5.dtsi:443.25-451.5: Warning (simple_bus_reg):
> > /axi@600000000/mdio@6110102f8: simple-bus unit address format error,
> > expected "6110102d4"
> >
> > Fixes: d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch
> > node")
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> >
> > ---
> >
> > Not tested on hardware
> > ---
> > arch/arm64/boot/dts/microchip/sparx5.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > index 24075cd91420..5d820da8c69d 100644
> > --- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > @@ -447,7 +447,7 @@ mdio2: mdio@6110102f8 {
> > pinctrl-names = "default";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > - reg = <0x6 0x110102d4 0x24>;
> > + reg = <0x6 0x110102f8 0x24>;
> > };
> >
> > mdio3: mdio@61101031c {
> > --
> > 2.34.1
> >
>
> I did a check of our current Sparx5 EVBs and none of them uses
> controller 2 in any revision, so this is probably why it has not come
> up before, so as it stands we have no platform to test this change on
> currently.
>
> Besides that the change looks good to me.
>
> Best Regards
> Steen
>
> Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
Are you okay with the rest of the series, or have you only looked at
this one patch?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox