* Re: [PATCH 1/6] arm64: dts: marvell: ap80x: fix IOMMU unit address
From: Andrew Lunn @ 2024-04-01 14:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-1-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:46PM +0200, Krzysztof Kozlowski wrote:
> Correct the IOMMU device node unit address to match "reg" and fix dtc
> W=1 warnings:
>
> armada-ap80x.dtsi:64.24-80.6: Warning (simple_bus_reg): /ap807/config-space@f0000000/iommu@5000000: simple-bus unit address format error, expected "100000"
>
> 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 2/6] arm64: dts: marvell: cn9130-db: drop unneeded flash address/size-cells
From: Andrew Lunn @ 2024-04-01 14:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-2-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:47PM +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:
>
> cn9130-db.dtsi:313.10-336.4: Warning (avoid_unnecessary_addr_size): /cp0/config-space@f2000000/spi@700680/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 3/6] arm64: dts: marvell: cn9131-db: drop unneeded flash address/size-cells
From: Andrew Lunn @ 2024-04-01 14:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-3-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:48PM +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:
>
> cn9131-db.dtsi:140.10-163.4: Warning (avoid_unnecessary_addr_size): /cp1/config-space@f4000000/spi@700680/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 4/6] arm64: dts: marvell: cn9130-db: drop wrong unit-addresses
From: Andrew Lunn @ 2024-04-01 14:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-4-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:49PM +0200, Krzysztof Kozlowski wrote:
> Top-level nodes, not being on MMIO bus, do not have "reg" properties and
> should not have unit addresses. Correct their name as well to match
> "Generic node names" recommendation from Devicetree specification.
> This also fixes dtc W=1 warnings:
>
> cn9130-db.dtsi:28.11-31.4: Warning (unique_unit_address_if_enabled): /memory@0: duplicate unit-address (also used in node /ap0_sd_vccq@0)
> cn9130-db.dtsi:28.11-31.4: Warning (unique_unit_address_if_enabled): /memory@0: duplicate unit-address (also used in node /cp0_usb3_vbus@0)
> cn9130-db.dtsi:33.33-40.4: Warning (unique_unit_address_if_enabled): /ap0_sd_vccq@0: duplicate unit-address (also used in node /cp0_usb3_vbus@0)
> cn9130-db.dtsi:28.11-31.4: Warning (unique_unit_address_if_enabled): /memory@0: duplicate unit-address (also used in node /cp0_usb3_phy@0)
> cn9130-db.dtsi:33.33-40.4: Warning (unit_address_vs_reg): /ap0_sd_vccq@0: node has a unit name, but no reg or ranges property
> cn9130-db.dtsi:42.38-49.4: Warning (unit_address_vs_reg): /cp0_usb3_vbus@0: node has a unit name, but no reg or ranges property
> cn9130-db.dtsi:51.34-54.4: Warning (unit_address_vs_reg): /cp0_usb3_phy@0: node has a unit name, but no reg or ranges property
> cn9130-db.dtsi:56.38-63.4: Warning (unit_address_vs_reg): /cp0_usb3_vbus@1: node has a unit name, but no reg or ranges 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 5/6] arm64: dts: marvell: cn9130-crb: drop wrong unit-addresses
From: Andrew Lunn @ 2024-04-01 14:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-5-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:50PM +0200, Krzysztof Kozlowski wrote:
> Top-level nodes, not being on MMIO bus, do not have "reg" properties and
> should not have unit addresses. Correct their name as well to match
> "Generic node names" recommendation from Devicetree specification.
> This also fixes dtc W=1 warnings:
>
> cn9130-crb.dtsi:29.35-37.4: Warning (unit_address_vs_reg): /ap0_mmc_vccq@0: node has a unit name, but no reg or ranges property
> cn9130-crb.dtsi:39.38-46.4: Warning (unit_address_vs_reg): /cp0_usb3_vbus@1: node has a unit name, but no reg or ranges property
> cn9130-crb.dtsi:57.33-65.4: Warning (unit_address_vs_reg): /cp0_sd_vccq@0: node has a unit name, but no reg or ranges property
> cn9130-crb.dtsi:67.31-75.4: Warning (unit_address_vs_reg): /cp0_sd_vcc@0: node has a unit name, but no reg or ranges 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 6/6] arm64: dts: marvell: cn9130-crb: drop unneeded "status"
From: Andrew Lunn @ 2024-04-01 14:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240401141051.98233-6-krzk@kernel.org>
On Mon, Apr 01, 2024 at 04:10:51PM +0200, Krzysztof Kozlowski wrote:
> Devices are enabled by default.
>
> 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
* [PATCH] ARM: davinci: da850: fix selecting ARCH_DAVINCI_DA8XX
From: David Lechner @ 2024-04-01 15:09 UTC (permalink / raw)
To: Bartosz Golaszewski, Russell King, Arnd Bergmann
Cc: David Lechner, Bartosz Golaszewski, linux-arm-kernel,
linux-kernel
Chips in the DA850 family need to have ARCH_DAVINCI_DA8XX to be selected
in order to enable some peripheral drivers.
This was accidentally removed in a previous commit.
Fixes: dec85a95167a ("ARM: davinci: clean up platform support")
Signed-off-by: David Lechner <dlechner@baylibre.com>
---
arch/arm/mach-davinci/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 2a8a9fe46586..3fa15f342240 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -27,6 +27,7 @@ config ARCH_DAVINCI_DA830
config ARCH_DAVINCI_DA850
bool "DA850/OMAP-L138/AM18x based system"
+ select ARCH_DAVINCI_DA8XX
select DAVINCI_CP_INTC
config ARCH_DAVINCI_DA8XX
---
base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
change-id: 20240401-da850-fix-select-da8xx-989725eec11f
_______________________________________________
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] ASoC: dt-bindings: mt2701-wm8960: Convert to dtschema
From: Rob Herring @ 2024-04-01 15:14 UTC (permalink / raw)
To: Kartik Agarwala
Cc: lgirdwood, broonie, krzysztof.kozlowski+dt, conor+dt,
matthias.bgg, angelogioacchino.delregno, linux-sound, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20240401043505.40972-1-agarwala.kartik@gmail.com>
On Mon, Apr 01, 2024 at 10:05:05AM +0530, Kartik Agarwala wrote:
> Convert mt2701-wm890 bindings from text to dtschema. This is used by MediaTek mt77623a/n SoC.
Wrap lines at 75.
>
> Signed-off-by: Kartik Agarwala <agarwala.kartik@gmail.com>
> ---
> .../sound/mediatek,mt2701-wm8960.yaml | 59 +++++++++++++++++++
> .../bindings/sound/mt2701-wm8960.txt | 24 --------
> 2 files changed, 59 insertions(+), 24 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
> delete mode 100644 Documentation/devicetree/bindings/sound/mt2701-wm8960.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
> new file mode 100644
> index 000000000..771f14a59
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/mediatek,mt2701-wm8960.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT2701 with WM8960 CODEC
> +
> +maintainers:
> + - Kartik Agarwala <agarwala.kartik@gmail.com>
> +
> +properties:
> + compatible:
> + const: mediatek,mt2701-wm8960-machine
> +
> + mediatek,platform:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: The phandle of MT2701 ASoC platform.
> +
> + audio-routing:
> + $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> + description: |
Don't need '|'.
> + A list of the connections between audio components. Each entry is a
> + pair of strings, the first being the connection's sink, the second
> + being the connection's source.
> +
> + mediatek,audio-codec:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: The phandle of the WM8960 audio codec.
> +
> + pinctrl-names:
> + const: default
> +
> + pinctrl-0: true
You can drop pinctrl properties. Those are implicitly supported.
> +
> +unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - mediatek,platform
> + - audio-routing
> + - mediatek,audio-codec
> + - pinctrl-names
> + - pinctrl-0
> +
> +examples:
> + - |
> + sound {
> + compatible = "mediatek,mt2701-wm8960-machine";
> + mediatek,platform = <&afe>;
> + audio-routing =
> + "Headphone", "HP_L",
> + "Headphone", "HP_R",
> + "LINPUT1", "AMIC",
> + "RINPUT1", "AMIC";
> + mediatek,audio-codec = <&wm8960>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&aud_pins_default>;
> + };
_______________________________________________
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: realtek: rtc16xx: add missing unit address to soc node
From: Krzysztof Kozlowski @ 2024-04-01 14:09 UTC (permalink / raw)
To: Andreas Färber, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-kernel, linux-realtek-soc, devicetree,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401140912.97157-1-krzk@kernel.org>
"soc" node has "ranges" property thus add matching unit address to fix
dtc W=1 warnings:
rtd16xx.dtsi:130.6-198.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/realtek/rtd16xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/realtek/rtd16xx.dtsi b/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
index 34802cc62983..c10c7eaf1b03 100644
--- a/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
@@ -127,7 +127,7 @@ osc27M: osc {
#clock-cells = <0>;
};
- soc {
+ soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
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/4] arm64: dts: uniphier: ld20-global: use generic node name for audio-codec
From: Krzysztof Kozlowski @ 2024-04-01 14:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kunihiko Hayashi,
Masami Hiramatsu, devicetree, linux-arm-kernel, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401140952.97923-1-krzk@kernel.org>
Devicetree specification expects node names to be generic, representing
the class of devices.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
index a01579cb3b79..a4c86137f424 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
@@ -111,7 +111,7 @@ &comp_spdif_hiecout1 {
&i2c0 {
status = "okay";
- tas5707@1b {
+ audio-codec@1b {
compatible = "ti,tas5711";
reg = <0x1b>;
reset-gpios = <&gpio UNIPHIER_GPIO_PORT(0, 0) GPIO_ACTIVE_LOW>;
--
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] ath9k: use unmanaged PCI functions in ath9k_pci_owl_loader
From: Heiner Kallweit @ 2024-04-01 15:30 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Kalle Valo, Andreas Färber,
Manivannan Sadhasivam, Martin Blumenstingl
Cc: linux-wireless, linux-arm-kernel@lists.infradead.org,
linux-actions, linux-pci@vger.kernel.org
Using the device-managed versions has no benefit here, because
resources are released as part of the asynchronous fw loading.
Actual reason why I got here is that I was looking for places with
dubious use of pcim_pin_device().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
index a5eb43f30..bc93ca075 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
+++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
@@ -65,7 +65,7 @@ static int ath9k_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
dev_info(&pdev->dev, "fixup device configuration\n");
- mem = pcim_iomap(pdev, 0, 0);
+ mem = pci_iomap(pdev, 0, 0);
if (!mem) {
dev_err(&pdev->dev, "ioremap error\n");
return -EINVAL;
@@ -103,7 +103,7 @@ static int ath9k_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
pci_write_config_word(pdev, PCI_COMMAND, cmd);
pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, bar0);
- pcim_iounmap(pdev, mem);
+ pci_iounmap(pdev, mem);
pci_disable_device(pdev);
@@ -200,11 +200,9 @@ static int owl_probe(struct pci_dev *pdev,
const char *eeprom_name;
int err = 0;
- if (pcim_enable_device(pdev))
+ if (pci_enable_device(pdev))
return -EIO;
- pcim_pin_device(pdev);
-
ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
--
2.44.0
_______________________________________________
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] clk: nxp: Remove an unused field in struct lpc18xx_pll
From: Christophe JAILLET @ 2024-04-01 15:31 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Vladimir Zapolskiy
Cc: linux-kernel, kernel-janitors, Christophe JAILLET, linux-clk,
linux-arm-kernel
In "struct lpc18xx_pll", the 'lock' field is unused.
Remove it.
Found with cppcheck, unusedStructMember.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Compile tested only.
---
drivers/clk/nxp/clk-lpc18xx-cgu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/nxp/clk-lpc18xx-cgu.c b/drivers/clk/nxp/clk-lpc18xx-cgu.c
index 69ebf65081b8..81efa885069b 100644
--- a/drivers/clk/nxp/clk-lpc18xx-cgu.c
+++ b/drivers/clk/nxp/clk-lpc18xx-cgu.c
@@ -250,7 +250,6 @@ static struct lpc18xx_cgu_base_clk lpc18xx_cgu_base_clks[] = {
struct lpc18xx_pll {
struct clk_hw hw;
void __iomem *reg;
- spinlock_t *lock;
u8 flags;
};
--
2.44.0
_______________________________________________
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 02/10] arm64: dts: microchip: sparx5: correct serdes unit address
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
Unit address should match "reg" property, as reported by dtc W=1
warnings:
sparx5.dtsi:463.27-468.5: Warning (simple_bus_reg): /axi@600000000/serdes@10808000: simple-bus unit address format error, expected "610808000"
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
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 5d820da8c69d..c3029e0abacc 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -460,7 +460,7 @@ mdio3: mdio@61101031c {
reg = <0x6 0x1101031c 0x24>;
};
- serdes: serdes@10808000 {
+ serdes: serdes@610808000 {
compatible = "microchip,sparx5-serdes";
#phy-cells = <1>;
clocks = <&sys_clk>;
--
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 03/10] arm64: dts: microchip: sparx5_pcb134: add missing I2C mux unit addresses
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
The children of I2C mux should be named "i2c", according to DT schema
and bindings, and they should have unit address.
This fixes dtbs_check warnings like:
sparx5_pcb134_emmc.dtb: i2c0-imux@0: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c_sfp1', ...
and dtc W=1 warnings:
sparx5_pcb134_board.dtsi:548.23-555.4: Warning (simple_bus_reg): /axi@600000000/sfp-eth12: missing or empty reg/ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
.../dts/microchip/sparx5_pcb134_board.dtsi | 40 +++++++++----------
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index f3e226de5e5e..e816e6e9d62d 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -427,62 +427,62 @@ &i2c0_imux {
pinctrl-10 = <&i2cmux_10>;
pinctrl-11 = <&i2cmux_11>;
pinctrl-12 = <&i2cmux_pins_i>;
- i2c_sfp1: i2c_sfp1 {
+ i2c_sfp1: i2c@0 {
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp2: i2c_sfp2 {
+ i2c_sfp2: i2c@1 {
reg = <0x1>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp3: i2c_sfp3 {
+ i2c_sfp3: i2c@2 {
reg = <0x2>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp4: i2c_sfp4 {
+ i2c_sfp4: i2c@3 {
reg = <0x3>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp5: i2c_sfp5 {
+ i2c_sfp5: i2c@4 {
reg = <0x4>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp6: i2c_sfp6 {
+ i2c_sfp6: i2c@5 {
reg = <0x5>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp7: i2c_sfp7 {
+ i2c_sfp7: i2c@6 {
reg = <0x6>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp8: i2c_sfp8 {
+ i2c_sfp8: i2c@7 {
reg = <0x7>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp9: i2c_sfp9 {
+ i2c_sfp9: i2c@8 {
reg = <0x8>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp10: i2c_sfp10 {
+ i2c_sfp10: i2c@9 {
reg = <0x9>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp11: i2c_sfp11 {
+ i2c_sfp11: i2c@a {
reg = <0xa>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp12: i2c_sfp12 {
+ i2c_sfp12: i2c@b {
reg = <0xb>;
#address-cells = <1>;
#size-cells = <0>;
@@ -495,42 +495,42 @@ &gpio 60 GPIO_ACTIVE_HIGH
&gpio 61 GPIO_ACTIVE_HIGH
&gpio 54 GPIO_ACTIVE_HIGH>;
idle-state = <0x8>;
- i2c_sfp13: i2c_sfp13 {
+ i2c_sfp13: i2c@0 {
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp14: i2c_sfp14 {
+ i2c_sfp14: i2c@1 {
reg = <0x1>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp15: i2c_sfp15 {
+ i2c_sfp15: i2c@2 {
reg = <0x2>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp16: i2c_sfp16 {
+ i2c_sfp16: i2c@3 {
reg = <0x3>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp17: i2c_sfp17 {
+ i2c_sfp17: i2c@4 {
reg = <0x4>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp18: i2c_sfp18 {
+ i2c_sfp18: i2c@5 {
reg = <0x5>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp19: i2c_sfp19 {
+ i2c_sfp19: i2c@6 {
reg = <0x6>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp20: i2c_sfp20 {
+ i2c_sfp20: i2c@7 {
reg = <0x7>;
#address-cells = <1>;
#size-cells = <0>;
--
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 04/10] arm64: dts: microchip: sparx5_pcb135: add missing I2C mux unit addresses
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
The children of I2C mux should be named "i2c", according to DT schema
and bindings, and they should have unit address.
This fixes dtbs_check warnings like:
sparx5_pcb135.dtb: i2c0-imux@0: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c_sfp1', 'i2c_sfp2', 'i2c_sfp3', 'i2c_sfp4' were unexpected)
and dtc W=1 warnings:
sparx5_pcb135_board.dtsi:172.23-180.4: Warning (simple_bus_reg): /axi@600000000/sfp-eth60: missing or empty reg/ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index 82ce007d9959..bf51a6e11cf1 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -146,22 +146,22 @@ &i2c0_imux {
pinctrl-2 = <&i2cmux_s31>;
pinctrl-3 = <&i2cmux_s32>;
pinctrl-4 = <&i2cmux_pins_i>;
- i2c_sfp1: i2c_sfp1 {
+ i2c_sfp1: i2c@0 {
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp2: i2c_sfp2 {
+ i2c_sfp2: i2c@1 {
reg = <0x1>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp3: i2c_sfp3 {
+ i2c_sfp3: i2c@2 {
reg = <0x2>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp4: i2c_sfp4 {
+ i2c_sfp4: i2c@3 {
reg = <0x3>;
#address-cells = <1>;
#size-cells = <0>;
--
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 06/10] arm64: dts: microchip: sparx5_pcb135: align I2C mux node name with bindings
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
DT schema expects node names to match certain. This fixes dtbs_check
warnings like:
sparx5_pcb135_emmc.dtb: i2c0-imux@0: $nodename:0: 'i2c0-imux@0' does not match '^(i2c-?)?mux'
and dtc W=1 warnings:
sparx5_pcb135_board.dtsi:132.25-137.4: Warning (simple_bus_reg): /axi@600000000/i2c0-imux@0: missing or empty reg/ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index bf51a6e11cf1..860975ffe0a1 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -129,7 +129,7 @@ &sgpio2 {
};
&axi {
- i2c0_imux: i2c0-imux@0 {
+ i2c0_imux: i2c-mux {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
#size-cells = <0>;
--
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 05/10] arm64: dts: microchip: sparx5_pcb134: align I2C mux node name with bindings
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
DT schema expects node names to match certain. This fixes dtbs_check
warnings like:
sparx5_pcb134_emmc.dtb: i2c0-emux@0: $nodename:0: 'i2c0-emux@0' does not match '^(i2c-?)?mux'
and dtc W=1 warnings:
sparx5_pcb134_board.dtsi:398.25-403.4: Warning (unique_unit_address_if_enabled): /axi@600000000/i2c0-imux@0: duplicate unit-address (also used in node /axi@600000000/i2c0-emux@0)
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index e816e6e9d62d..cafec6ef0d0f 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -395,13 +395,13 @@ i2cmux_11: i2cmux-11-pins {
};
&axi {
- i2c0_imux: i2c0-imux@0 {
+ i2c0_imux: i2c-mux-0 {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
#size-cells = <0>;
i2c-parent = <&i2c0>;
};
- i2c0_emux: i2c0-emux@0 {
+ i2c0_emux: i2c-mux-1 {
compatible = "i2c-mux-gpio";
#address-cells = <1>;
#size-cells = <0>;
--
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 07/10] arm64: dts: microchip: sparx5_pcb134: drop LED unit addresses
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
GPIO leds should not have unit addresses (no "reg" property), as
reported by dtc W=1 warnings:
sparx5_pcb134_board.dtsi:18.9-21.5: Warning (unit_address_vs_reg): /leds/led@0: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
.../dts/microchip/sparx5_pcb134_board.dtsi | 96 +++++++++----------
1 file changed, 48 insertions(+), 48 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index cafec6ef0d0f..f165a409bc1d 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -15,234 +15,234 @@ gpio-restart {
leds {
compatible = "gpio-leds";
- led@0 {
+ led-0 {
label = "twr0:green";
gpios = <&sgpio_out0 8 0 GPIO_ACTIVE_LOW>;
};
- led@1 {
+ led-1 {
label = "twr0:yellow";
gpios = <&sgpio_out0 8 1 GPIO_ACTIVE_LOW>;
};
- led@2 {
+ led-2 {
label = "twr1:green";
gpios = <&sgpio_out0 9 0 GPIO_ACTIVE_LOW>;
};
- led@3 {
+ led-3 {
label = "twr1:yellow";
gpios = <&sgpio_out0 9 1 GPIO_ACTIVE_LOW>;
};
- led@4 {
+ led-4 {
label = "twr2:green";
gpios = <&sgpio_out0 10 0 GPIO_ACTIVE_LOW>;
};
- led@5 {
+ led-5 {
label = "twr2:yellow";
gpios = <&sgpio_out0 10 1 GPIO_ACTIVE_LOW>;
};
- led@6 {
+ led-6 {
label = "twr3:green";
gpios = <&sgpio_out0 11 0 GPIO_ACTIVE_LOW>;
};
- led@7 {
+ led-7 {
label = "twr3:yellow";
gpios = <&sgpio_out0 11 1 GPIO_ACTIVE_LOW>;
};
- led@8 {
+ led-8 {
label = "eth12:green";
gpios = <&sgpio_out0 12 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@9 {
+ led-9 {
label = "eth12:yellow";
gpios = <&sgpio_out0 12 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@10 {
+ led-10 {
label = "eth13:green";
gpios = <&sgpio_out0 13 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@11 {
+ led-11 {
label = "eth13:yellow";
gpios = <&sgpio_out0 13 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@12 {
+ led-12 {
label = "eth14:green";
gpios = <&sgpio_out0 14 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@13 {
+ led-13 {
label = "eth14:yellow";
gpios = <&sgpio_out0 14 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@14 {
+ led-14 {
label = "eth15:green";
gpios = <&sgpio_out0 15 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@15 {
+ led-15 {
label = "eth15:yellow";
gpios = <&sgpio_out0 15 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@16 {
+ led-16 {
label = "eth48:green";
gpios = <&sgpio_out1 16 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@17 {
+ led-17 {
label = "eth48:yellow";
gpios = <&sgpio_out1 16 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@18 {
+ led-18 {
label = "eth49:green";
gpios = <&sgpio_out1 17 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@19 {
+ led-19 {
label = "eth49:yellow";
gpios = <&sgpio_out1 17 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@20 {
+ led-20 {
label = "eth50:green";
gpios = <&sgpio_out1 18 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@21 {
+ led-21 {
label = "eth50:yellow";
gpios = <&sgpio_out1 18 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@22 {
+ led-22 {
label = "eth51:green";
gpios = <&sgpio_out1 19 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@23 {
+ led-23 {
label = "eth51:yellow";
gpios = <&sgpio_out1 19 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@24 {
+ led-24 {
label = "eth52:green";
gpios = <&sgpio_out1 20 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@25 {
+ led-25 {
label = "eth52:yellow";
gpios = <&sgpio_out1 20 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@26 {
+ led-26 {
label = "eth53:green";
gpios = <&sgpio_out1 21 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@27 {
+ led-27 {
label = "eth53:yellow";
gpios = <&sgpio_out1 21 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@28 {
+ led-28 {
label = "eth54:green";
gpios = <&sgpio_out1 22 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@29 {
+ led-29 {
label = "eth54:yellow";
gpios = <&sgpio_out1 22 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@30 {
+ led-30 {
label = "eth55:green";
gpios = <&sgpio_out1 23 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@31 {
+ led-31 {
label = "eth55:yellow";
gpios = <&sgpio_out1 23 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@32 {
+ led-32 {
label = "eth56:green";
gpios = <&sgpio_out1 24 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@33 {
+ led-33 {
label = "eth56:yellow";
gpios = <&sgpio_out1 24 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@34 {
+ led-34 {
label = "eth57:green";
gpios = <&sgpio_out1 25 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@35 {
+ led-35 {
label = "eth57:yellow";
gpios = <&sgpio_out1 25 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@36 {
+ led-36 {
label = "eth58:green";
gpios = <&sgpio_out1 26 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@37 {
+ led-37 {
label = "eth58:yellow";
gpios = <&sgpio_out1 26 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@38 {
+ led-38 {
label = "eth59:green";
gpios = <&sgpio_out1 27 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@39 {
+ led-39 {
label = "eth59:yellow";
gpios = <&sgpio_out1 27 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@40 {
+ led-40 {
label = "eth60:green";
gpios = <&sgpio_out1 28 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@41 {
+ led-41 {
label = "eth60:yellow";
gpios = <&sgpio_out1 28 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@42 {
+ led-42 {
label = "eth61:green";
gpios = <&sgpio_out1 29 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@43 {
+ led-43 {
label = "eth61:yellow";
gpios = <&sgpio_out1 29 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@44 {
+ led-44 {
label = "eth62:green";
gpios = <&sgpio_out1 30 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@45 {
+ led-45 {
label = "eth62:yellow";
gpios = <&sgpio_out1 30 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@46 {
+ led-46 {
label = "eth63:green";
gpios = <&sgpio_out1 31 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@47 {
+ led-47 {
label = "eth63:yellow";
gpios = <&sgpio_out1 31 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
--
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 08/10] arm64: dts: microchip: sparx5_pcb135: drop LED unit addresses
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
GPIO leds should not have unit addresses (no "reg" property), as
reported by dtc W=1 warnings:
sparx5_pcb135_board.dtsi:18.9-22.5: Warning (unit_address_vs_reg): /leds/led@0: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
.../boot/dts/microchip/sparx5_pcb135_board.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index 860975ffe0a1..20016efb3656 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -15,42 +15,42 @@ gpio-restart {
leds {
compatible = "gpio-leds";
- led@0 {
+ led-0 {
label = "eth60:yellow";
gpios = <&sgpio_out1 28 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@1 {
+ led-1 {
label = "eth60:green";
gpios = <&sgpio_out1 28 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@2 {
+ led-2 {
label = "eth61:yellow";
gpios = <&sgpio_out1 29 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@3 {
+ led-3 {
label = "eth61:green";
gpios = <&sgpio_out1 29 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@4 {
+ led-4 {
label = "eth62:yellow";
gpios = <&sgpio_out1 30 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@5 {
+ led-5 {
label = "eth62:green";
gpios = <&sgpio_out1 30 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@6 {
+ led-6 {
label = "eth63:yellow";
gpios = <&sgpio_out1 31 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@7 {
+ led-7 {
label = "eth63:green";
gpios = <&sgpio_out1 31 1 GPIO_ACTIVE_LOW>;
default-state = "off";
--
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 RFT 09/10] arm64: dts: microchip: sparx5_pcb134: drop duplicated NOR flash
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
Since beginning the DTS extended the SPI0 in two places adding two SPI
muxes, each with same SPI NOR flash. Both used exactly the same
chip-selects, so this was clearly buggy code. Without checking in
datasheet, assume device has only one SPI NOR flash, so code was
duplicated.
Fixes dtc W=1 warnings:
sparx5_pcb134_board.dtsi:277.10-281.4: Warning (unique_unit_address_if_enabled): /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also used in node /axi@600000000/spi@600104000/spi@0)
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Not tested on hardware
---
.../boot/dts/microchip/sparx5_pcb134_board.dtsi | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index f165a409bc1d..dc7b59dfcb40 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -281,22 +281,6 @@ flash@0 {
};
};
-&spi0 {
- status = "okay";
- spi@0 {
- compatible = "spi-mux";
- mux-controls = <&mux>;
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>; /* CS0 */
- flash@9 {
- compatible = "jedec,spi-nor";
- spi-max-frequency = <8000000>;
- reg = <0x9>; /* SPI */
- };
- };
-};
-
&sgpio0 {
status = "okay";
microchip,sgpio-port-ranges = <8 15>;
--
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 RFT 10/10] arm64: dts: microchip: sparx5_pcb135: drop duplicated NOR flash
From: Krzysztof Kozlowski @ 2024-04-01 15:37 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, David S. Miller, Bjarni Jonasson,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240401153740.123978-1-krzk@kernel.org>
Since beginning the DTS extended the SPI0 in two places adding two SPI
muxes, each with same SPI NOR flash. Both used exactly the same
chip-selects, so this was clearly buggy code. Without checking in
datasheet, assume device has only one SPI NOR flash, so code was
duplicated.
Fixes dtc W=1 warnings:
sparx5_pcb135_board.dtsi:92.10-96.4: Warning (unique_unit_address_if_enabled): /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also used in node /axi@600000000/spi@600104000/spi@0)
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Not tested on hardware
---
.../boot/dts/microchip/sparx5_pcb135_board.dtsi | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index 20016efb3656..d64e642e3873 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -96,22 +96,6 @@ flash@0 {
};
};
-&spi0 {
- status = "okay";
- spi@0 {
- compatible = "spi-mux";
- mux-controls = <&mux>;
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>; /* CS0 */
- flash@9 {
- compatible = "jedec,spi-nor";
- spi-max-frequency = <8000000>;
- reg = <0x9>; /* SPI */
- };
- };
-};
-
&sgpio1 {
status = "okay";
microchip,sgpio-port-ranges = <24 31>;
--
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 v4 4/4] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
From: Mathieu Poirier @ 2024-04-01 15:46 UTC (permalink / raw)
To: Arnaud POULIQUEN
Cc: Bjorn Andersson, Jens Wiklander, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-stm32, linux-arm-kernel, linux-remoteproc,
linux-kernel, op-tee, devicetree
In-Reply-To: <2cd23e93-1a3a-4128-b947-35fe2b04ccab@foss.st.com>
On Fri, Mar 29, 2024 at 11:57:43AM +0100, Arnaud POULIQUEN wrote:
>
>
> On 3/27/24 18:14, Mathieu Poirier wrote:
> > On Tue, Mar 26, 2024 at 08:31:33PM +0100, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 3/25/24 17:51, Mathieu Poirier wrote:
> >>> On Fri, Mar 08, 2024 at 03:47:08PM +0100, Arnaud Pouliquen wrote:
> >>>> The new TEE remoteproc device is used to manage remote firmware in a
> >>>> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
> >>>> introduced to delegate the loading of the firmware to the trusted
> >>>> execution context. In such cases, the firmware should be signed and
> >>>> adhere to the image format defined by the TEE.
> >>>>
> >>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >>>> ---
> >>>> Updates from V3:
> >>>> - remove support of the attach use case. Will be addressed in a separate
> >>>> thread,
> >>>> - add st_rproc_tee_ops::parse_fw ops,
> >>>> - inverse call of devm_rproc_alloc()and tee_rproc_register() to manage cross
> >>>> reference between the rproc struct and the tee_rproc struct in tee_rproc.c.
> >>>> ---
> >>>> drivers/remoteproc/stm32_rproc.c | 60 +++++++++++++++++++++++++++++---
> >>>> 1 file changed, 56 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
> >>>> index 8cd838df4e92..13df33c78aa2 100644
> >>>> --- a/drivers/remoteproc/stm32_rproc.c
> >>>> +++ b/drivers/remoteproc/stm32_rproc.c
> >>>> @@ -20,6 +20,7 @@
> >>>> #include <linux/remoteproc.h>
> >>>> #include <linux/reset.h>
> >>>> #include <linux/slab.h>
> >>>> +#include <linux/tee_remoteproc.h>
> >>>> #include <linux/workqueue.h>
> >>>>
> >>>> #include "remoteproc_internal.h"
> >>>> @@ -49,6 +50,9 @@
> >>>> #define M4_STATE_STANDBY 4
> >>>> #define M4_STATE_CRASH 5
> >>>>
> >>>> +/* Remote processor unique identifier aligned with the Trusted Execution Environment definitions */
> >>>
> >>> Why is this the case? At least from the kernel side it is possible to call
> >>> tee_rproc_register() with any kind of value, why is there a need to be any
> >>> kind of alignment with the TEE?
> >>
> >>
> >> The use of the proc_id is to identify a processor in case of multi co-processors.
> >>
> >
> > That is well understood.
> >
> >> For instance we can have a system with A DSP and a modem. We would use the same
> >> TEE service, but
> >
> > That too.
> >
> >> the TEE driver will probably be different, same for the signature key.
> >
> > What TEE driver are we talking about here?
>
> In OP-TEE remoteproc frameork is divided in 2 or 3 layers:
>
> - the remoteproc Trusted Application (TA) [1] which is platform agnostic
> - The remoteproc Pseudo Trusted Application (PTA) [2] which is platform
> dependent and can rely on the proc ID to retrieve the context.
> - the remoteproc driver (optional for some platforms) [3], which is in charge
> of DT parsing and platform configuration.
>
That part makes sense.
> Here TEE driver can be interpreted by remote PTA and/or platform driver.
>
I have to guess PTA means "Platform Trusted Application" but I have no
guarantee, adding to the level of (already high) confusion brought on by this
patchset.
> [1]
> https://elixir.bootlin.com/op-tee/latest/source/ta/remoteproc/src/remoteproc_core.c
> [2]
> https://elixir.bootlin.com/op-tee/latest/source/core/pta/stm32mp/remoteproc_pta.c
> [3]
> https://elixir.bootlin.com/op-tee/latest/source/core/drivers/remoteproc/stm32_remoteproc.c
>
> >
> >> In such case the proc ID allows to identify the the processor you want to address.
> >>
> >
> > That too is well understood, but there is no alignment needed with the TEE, i.e
> > the TEE application is not expecting a value of '0'. We could set
> > STM32_MP1_M4_PROC_ID to 0xDEADBEEF and things would work. This driver won't go
> > anywhere for as long as it is not the case.
>
>
> Here I suppose that you do not challenge the rproc_ID use in general, but for
> the stm32mp1 platform as we have only one remote processor. I'm right?
That is correct - I understand the need for an rproc_ID. The problem is with
the comment that states that '0' is aligned with the TEE definitions, which in
my head means hard coded value and a big red flag. What it should say is
"aligned with the TEE device tree definition".
>
> In OP-TEE the check is done here:
> https://elixir.bootlin.com/op-tee/latest/source/core/drivers/remoteproc/stm32_remoteproc.c#L64
>
> If driver does not register the proc ID an error is returned indicating that the
> feature is not supported.
>
> In case of stm32mp1 yes we could consider it as useless as we have only one
> remote proc.
>
> Nevertheless I can not guaranty that a customer will not add an external
> companion processor that uses OP-TEE to authenticate the associated firmware. As
> the trusted Application is the unique entry point. he will need the proc_id to
> identify the target at PTA level.
>
> So from my point of view having a proc ID on stm32MP1 (and on stm32mp2 that will
> reuse same driver) aligned between Linux and OP-TEE is useful.
I agree, for as long as it is not hard coded. The way remote processors are
discovered in the DT is perfectly acceptable, i.e the first remote processor is
for application X, the second for application Y...
>
> That said using a TEE_REMOTEPROC_DEFAULT_ID is something that could be
> more generic (for linux and OP-TEE). This ID could be reuse in the stm32mp
> driver and platform drivers with an unique internal remote processor.
>
I can't find the definition of TEE_REMOTEPROC_DEFAULT_ID anywhere, something
that doesn't help the confusion I referred to above.
> It that solution would be ok for you?
>
> Regards,
> Arnaud
>
>
> >
> >>
> >>>
> >>>> +#define STM32_MP1_M4_PROC_ID 0
> >>>> +
> >>>> struct stm32_syscon {
> >>>> struct regmap *map;
> >>>> u32 reg;
> >>>> @@ -257,6 +261,19 @@ static int stm32_rproc_release(struct rproc *rproc)
> >>>> return 0;
> >>>> }
> >>>>
> >>>> +static int stm32_rproc_tee_stop(struct rproc *rproc)
> >>>> +{
> >>>> + int err;
> >>>> +
> >>>> + stm32_rproc_request_shutdown(rproc);
> >>>> +
> >>>> + err = tee_rproc_stop(rproc);
> >>>> + if (err)
> >>>> + return err;
> >>>> +
> >>>> + return stm32_rproc_release(rproc);
> >>>> +}
> >>>> +
> >>>> static int stm32_rproc_prepare(struct rproc *rproc)
> >>>> {
> >>>> struct device *dev = rproc->dev.parent;
> >>>> @@ -693,8 +710,19 @@ static const struct rproc_ops st_rproc_ops = {
> >>>> .get_boot_addr = rproc_elf_get_boot_addr,
> >>>> };
> >>>>
> >>>> +static const struct rproc_ops st_rproc_tee_ops = {
> >>>> + .prepare = stm32_rproc_prepare,
> >>>> + .start = tee_rproc_start,
> >>>> + .stop = stm32_rproc_tee_stop,
> >>>> + .kick = stm32_rproc_kick,
> >>>> + .load = tee_rproc_load_fw,
> >>>> + .parse_fw = tee_rproc_parse_fw,
> >>>> + .find_loaded_rsc_table = tee_rproc_find_loaded_rsc_table,
> >>>> +};
> >>>> +
> >>>> static const struct of_device_id stm32_rproc_match[] = {
> >>>> - { .compatible = "st,stm32mp1-m4" },
> >>>> + {.compatible = "st,stm32mp1-m4",},
> >>>> + {.compatible = "st,stm32mp1-m4-tee",},
> >>>> {},
> >>>> };
> >>>> MODULE_DEVICE_TABLE(of, stm32_rproc_match);
> >>>> @@ -853,6 +881,7 @@ static int stm32_rproc_probe(struct platform_device *pdev)
> >>>> struct device *dev = &pdev->dev;
> >>>> struct stm32_rproc *ddata;
> >>>> struct device_node *np = dev->of_node;
> >>>> + struct tee_rproc *trproc = NULL;
> >>>> struct rproc *rproc;
> >>>> unsigned int state;
> >>>> int ret;
> >>>> @@ -861,9 +890,26 @@ static int stm32_rproc_probe(struct platform_device *pdev)
> >>>> if (ret)
> >>>> return ret;
> >>>>
> >>>> - rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
> >>>> - if (!rproc)
> >>>> - return -ENOMEM;
> >>>> + if (of_device_is_compatible(np, "st,stm32mp1-m4-tee")) {
> >>>> + /*
> >>>> + * Delegate the firmware management to the secure context.
> >>>> + * The firmware loaded has to be signed.
> >>>> + */
> >>>> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_tee_ops, NULL, sizeof(*ddata));
> >>>> + if (!rproc)
> >>>> + return -ENOMEM;
> >>>> +
> >>>> + trproc = tee_rproc_register(dev, rproc, STM32_MP1_M4_PROC_ID);
> >>>> + if (IS_ERR(trproc)) {
> >>>> + dev_err_probe(dev, PTR_ERR(trproc),
> >>>> + "signed firmware not supported by TEE\n");
> >>>> + return PTR_ERR(trproc);
> >>>> + }
> >>>> + } else {
> >>>> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
> >>>> + if (!rproc)
> >>>> + return -ENOMEM;
> >>>> + }
> >>>>
> >>>> ddata = rproc->priv;
> >>>>
> >>>> @@ -915,6 +961,9 @@ static int stm32_rproc_probe(struct platform_device *pdev)
> >>>> dev_pm_clear_wake_irq(dev);
> >>>> device_init_wakeup(dev, false);
> >>>> }
> >>>> + if (trproc)
> >>>
> >>> if (rproc->tee_interface)
> >>>
> >>>
> >>> I am done reviewing this set.
> >>
> >> Thank for your review!
> >> Arnaud
> >>
> >>>
> >>> Thanks,
> >>> Mathieu
> >>>
> >>>> + tee_rproc_unregister(trproc);
> >>>> +
> >>>> return ret;
> >>>> }
> >>>>
> >>>> @@ -935,6 +984,9 @@ static void stm32_rproc_remove(struct platform_device *pdev)
> >>>> dev_pm_clear_wake_irq(dev);
> >>>> device_init_wakeup(dev, false);
> >>>> }
> >>>> + if (rproc->tee_interface)
> >>>> + tee_rproc_unregister(rproc->tee_interface);
> >>>> +
> >>>> }
> >>>>
> >>>> static int stm32_rproc_suspend(struct device *dev)
> >>>> --
> >>>> 2.25.1
> >>>>
_______________________________________________
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 1/4] remoteproc: Add TEE support
From: Mathieu Poirier @ 2024-04-01 15:54 UTC (permalink / raw)
To: Arnaud POULIQUEN
Cc: Bjorn Andersson, Jens Wiklander, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-stm32, linux-arm-kernel, linux-remoteproc,
linux-kernel, op-tee, devicetree
In-Reply-To: <a4a1f938-d185-46d7-9f57-af7bf3a65e9c@foss.st.com>
On Fri, Mar 29, 2024 at 09:58:11AM +0100, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 3/27/24 18:07, Mathieu Poirier wrote:
> > On Tue, Mar 26, 2024 at 08:18:23PM +0100, Arnaud POULIQUEN wrote:
> >> Hello Mathieu,
> >>
> >> On 3/25/24 17:46, Mathieu Poirier wrote:
> >>> On Fri, Mar 08, 2024 at 03:47:05PM +0100, Arnaud Pouliquen wrote:
> >>>> Add a remoteproc TEE (Trusted Execution Environment) driver
> >>>> that will be probed by the TEE bus. If the associated Trusted
> >>>> application is supported on secure part this device offers a client
> >>>
> >>> Device or driver? I thought I touched on that before.
> >>
> >> Right, I changed the first instance and missed this one
> >>
> >>>
> >>>> interface to load a firmware in the secure part.
> >>>> This firmware could be authenticated by the secure trusted application.
> >>>>
> >>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >>>> ---
> >>>> Updates from V3:
> >>>> - rework TEE_REMOTEPROC description in Kconfig
> >>>> - fix some namings
> >>>> - add tee_rproc_parse_fw to support rproc_ops::parse_fw
> >>>> - add proc::tee_interface;
> >>>> - add rproc struct as parameter of the tee_rproc_register() function
> >>>> ---
> >>>> drivers/remoteproc/Kconfig | 10 +
> >>>> drivers/remoteproc/Makefile | 1 +
> >>>> drivers/remoteproc/tee_remoteproc.c | 434 ++++++++++++++++++++++++++++
> >>>> include/linux/remoteproc.h | 4 +
> >>>> include/linux/tee_remoteproc.h | 112 +++++++
> >>>> 5 files changed, 561 insertions(+)
> >>>> create mode 100644 drivers/remoteproc/tee_remoteproc.c
> >>>> create mode 100644 include/linux/tee_remoteproc.h
> >>>>
> >>>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> >>>> index 48845dc8fa85..2cf1431b2b59 100644
> >>>> --- a/drivers/remoteproc/Kconfig
> >>>> +++ b/drivers/remoteproc/Kconfig
> >>>> @@ -365,6 +365,16 @@ config XLNX_R5_REMOTEPROC
> >>>>
> >>>> It's safe to say N if not interested in using RPU r5f cores.
> >>>>
> >>>> +
> >>>> +config TEE_REMOTEPROC
> >>>> + tristate "remoteproc support by a TEE application"
> >>>
> >>> s/remoteproc/Remoteproc
> >>>
> >>>> + depends on OPTEE
> >>>> + help
> >>>> + Support a remote processor with a TEE application. The Trusted
> >>>> + Execution Context is responsible for loading the trusted firmware
> >>>> + image and managing the remote processor's lifecycle.
> >>>> + This can be either built-in or a loadable module.
> >>>> +
> >>>> endif # REMOTEPROC
> >>>>
> >>>> endmenu
> >>>> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> >>>> index 91314a9b43ce..fa8daebce277 100644
> >>>> --- a/drivers/remoteproc/Makefile
> >>>> +++ b/drivers/remoteproc/Makefile
> >>>> @@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC) += rcar_rproc.o
> >>>> obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
> >>>> obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> >>>> obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
> >>>> +obj-$(CONFIG_TEE_REMOTEPROC) += tee_remoteproc.o
> >>>> obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
> >>>> obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
> >>>> obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> >>>> diff --git a/drivers/remoteproc/tee_remoteproc.c b/drivers/remoteproc/tee_remoteproc.c
> >>>> new file mode 100644
> >>>> index 000000000000..c855210e52e3
> >>>> --- /dev/null
> >>>> +++ b/drivers/remoteproc/tee_remoteproc.c
> >>>> @@ -0,0 +1,434 @@
> >>>> +// SPDX-License-Identifier: GPL-2.0-or-later
> >>>> +/*
> >>>> + * Copyright (C) STMicroelectronics 2024 - All Rights Reserved
> >>>> + * Author: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >>>> + */
> >>>> +
> >>>> +#include <linux/firmware.h>
> >>>> +#include <linux/io.h>
> >>>> +#include <linux/module.h>
> >>>> +#include <linux/remoteproc.h>
> >>>> +#include <linux/slab.h>
> >>>> +#include <linux/tee_drv.h>
> >>>> +#include <linux/tee_remoteproc.h>
> >>>> +
> >>>> +#include "remoteproc_internal.h"
> >>>> +
> >>>> +#define MAX_TEE_PARAM_ARRY_MEMBER 4
> >>>> +
> >>>> +/*
> >>>> + * Authentication of the firmware and load in the remote processor memory
> >>>> + *
> >>>> + * [in] params[0].value.a: unique 32bit identifier of the remote processor
> >>>> + * [in] params[1].memref: buffer containing the image of the buffer
> >>>> + */
> >>>> +#define TA_RPROC_FW_CMD_LOAD_FW 1
> >>>> +
> >>>> +/*
> >>>> + * Start the remote processor
> >>>> + *
> >>>> + * [in] params[0].value.a: unique 32bit identifier of the remote processor
> >>>> + */
> >>>> +#define TA_RPROC_FW_CMD_START_FW 2
> >>>> +
> >>>> +/*
> >>>> + * Stop the remote processor
> >>>> + *
> >>>> + * [in] params[0].value.a: unique 32bit identifier of the remote processor
> >>>> + */
> >>>> +#define TA_RPROC_FW_CMD_STOP_FW 3
> >>>> +
> >>>> +/*
> >>>> + * Return the address of the resource table, or 0 if not found
> >>>> + * No check is done to verify that the address returned is accessible by
> >>>> + * the non secure context. If the resource table is loaded in a protected
> >>>> + * memory the access by the non secure context will lead to a data abort.
> >>>> + *
> >>>> + * [in] params[0].value.a: unique 32bit identifier of the remote processor
> >>>> + * [out] params[1].value.a: 32bit LSB resource table memory address
> >>>> + * [out] params[1].value.b: 32bit MSB resource table memory address
> >>>> + * [out] params[2].value.a: 32bit LSB resource table memory size
> >>>> + * [out] params[2].value.b: 32bit MSB resource table memory size
> >>>> + */
> >>>> +#define TA_RPROC_FW_CMD_GET_RSC_TABLE 4
> >>>> +
> >>>> +/*
> >>>> + * Return the address of the core dump
> >>>> + *
> >>>> + * [in] params[0].value.a: unique 32bit identifier of the remote processor
> >>>> + * [out] params[1].memref: address of the core dump image if exist,
> >>>> + * else return Null
> >>>> + */
> >>>> +#define TA_RPROC_FW_CMD_GET_COREDUMP 5
> >>>> +
> >>>> +struct tee_rproc_context {
> >>>> + struct list_head sessions;
> >>>> + struct tee_context *tee_ctx;
> >>>> + struct device *dev;
> >>>> +};
> >>>> +
> >>>> +static struct tee_rproc_context *tee_rproc_ctx;
> >>>> +
> >>>> +static void tee_rproc_prepare_args(struct tee_rproc *trproc, int cmd,
> >>>> + struct tee_ioctl_invoke_arg *arg,
> >>>> + struct tee_param *param,
> >>>> + unsigned int num_params)
> >>>> +{
> >>>> + memset(arg, 0, sizeof(*arg));
> >>>> + memset(param, 0, MAX_TEE_PARAM_ARRY_MEMBER * sizeof(*param));
> >>>> +
> >>>> + arg->func = cmd;
> >>>> + arg->session = trproc->session_id;
> >>>> + arg->num_params = num_params + 1;
> >>>> +
> >>>> + param[0] = (struct tee_param) {
> >>>> + .attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
> >>>> + .u.value.a = trproc->rproc_id,
> >>>> + };
> >>>> +}
> >>>> +
> >>>> +int tee_rproc_load_fw(struct rproc *rproc, const struct firmware *fw)
> >>>> +{
> >>>> + struct tee_ioctl_invoke_arg arg;
> >>>> + struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
> >>>> + struct tee_rproc *trproc = rproc->tee_interface;
> >>>> + struct tee_shm *fw_shm;
> >>>> + int ret;
> >>>
> >>> Declarations in reverse ascending order here and everywhere in the driver.
> >>> Sometimes it is done properly, sometimes it isn't.
> >>>
> >>>> +
> >>>> + if (!trproc)
> >>>> + return -EINVAL;
> >>>> +
> >>>> + fw_shm = tee_shm_register_kernel_buf(tee_rproc_ctx->tee_ctx, (void *)fw->data, fw->size);
> >>>> + if (IS_ERR(fw_shm))
> >>>> + return PTR_ERR(fw_shm);
> >>>> +
> >>>> + tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_LOAD_FW, &arg, param, 1);
> >>>> +
> >>>> + /* Provide the address of the firmware image */
> >>>> + param[1] = (struct tee_param) {
> >>>> + .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT,
> >>>> + .u.memref = {
> >>>> + .shm = fw_shm,
> >>>> + .size = fw->size,
> >>>> + .shm_offs = 0,
> >>>> + },
> >>>> + };
> >>>> +
> >>>> + ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
> >>>> + if (ret < 0 || arg.ret != 0) {
> >>>> + dev_err(tee_rproc_ctx->dev,
> >>>> + "TA_RPROC_FW_CMD_LOAD_FW invoke failed TEE err: %x, ret:%x\n",
> >>>> + arg.ret, ret);
> >>>> + if (!ret)
> >>>> + ret = -EIO;
> >>>> + }
> >>>> +
> >>>> + tee_shm_free(fw_shm);
> >>>> +
> >>>> + return ret;
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(tee_rproc_load_fw);
> >>>> +
> >>>> +struct resource_table *tee_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
> >>>> +{
> >>>> + struct tee_ioctl_invoke_arg arg;
> >>>> + struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
> >>>> + struct tee_rproc *trproc = rproc->tee_interface;
> >>>> + struct resource_table *rsc_table;
> >>>> + int ret;
> >>>> +
> >>>> + if (!trproc)
> >>>> + return ERR_PTR(-EINVAL);
> >>>> +
> >>>> + tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_GET_RSC_TABLE, &arg, param, 2);
> >>>> +
> >>>> + param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
> >>>> + param[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
> >>>> +
> >>>> + ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
> >>>> + if (ret < 0 || arg.ret != 0) {
> >>>> + dev_err(tee_rproc_ctx->dev,
> >>>> + "TA_RPROC_FW_CMD_GET_RSC_TABLE invoke failed TEE err: %x, ret:%x\n",
> >>>> + arg.ret, ret);
> >>>> + return ERR_PTR(-EIO);
> >>>> + }
> >>>> +
> >>>> + *table_sz = param[2].u.value.a;
> >>>> +
> >>>> + /* If the size is null no resource table defined in the image */
> >>>> + if (!*table_sz)
> >>>> + return NULL;
> >>>> +
> >>>> + /* Store the resource table address that would be updated by the remote core. */
> >>>> + rsc_table = ioremap_wc(param[1].u.value.a, *table_sz);
> >>>> + if (IS_ERR_OR_NULL(rsc_table)) {
> >>>> + dev_err(tee_rproc_ctx->dev, "Unable to map memory region: %lld+%zx\n",
> >>>> + param[1].u.value.a, *table_sz);
> >>>> + return ERR_PTR(-ENOMEM);
> >>>> + }
> >>>> +
> >>>> + return rsc_table;
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(tee_rproc_get_loaded_rsc_table);
> >>>> +
> >>>> +int tee_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
> >>>> +{
> >>>> + struct tee_rproc *trproc = rproc->tee_interface;
> >>>> + struct resource_table *rsc_table;
> >>>> + size_t table_sz;
> >>>> + int ret;
> >>>> +
> >>>> + ret = tee_rproc_load_fw(rproc, fw);
> >>>> + if (ret)
> >>>> + return ret;
> >>>> +
> >>>> + rsc_table = tee_rproc_get_loaded_rsc_table(rproc, &table_sz);
> >>>> + if (IS_ERR(rsc_table))
> >>>> + return PTR_ERR(rsc_table);
> >>>> +
> >>>> + /* Create a copy of the resource table to have same behaviour than the elf loader. */
> >>>> + rproc->cached_table = kmemdup(rsc_table, table_sz, GFP_KERNEL);
> >>>> + if (!rproc->cached_table)
> >>>> + return -ENOMEM;
> >>>
> >>> Why not ->table_ptr and setting ->cached_table to NULL?
> >>
> >> It was my plan preparing this version. But during implementarion it looks
> >> to me that having exactly same behavior than the ELF loader would be
> >> simpler to maintain the remoteproc avoiding to update in the remoteproc core
> >> to manage for the cached resource table (see also my comment below abourt recovery)
> >> That why I propose this implementation
> >>
> >> That said what you proposal should also work (with some updates in
> >> remoteproc_core for the management of the cached table).
> >>
> >
> > Yes
> >
> >> So please just comfirm your preference.
> >>
> >
> > Definitely keep ->cached_table to NULL.
> >
> >>>
> >>>> +
> >>>> + rproc->table_ptr = rproc->cached_table;
> >>>> + rproc->table_sz = table_sz;
> >>>> + trproc->rsc_table = rsc_table;
> >>>
> >>> I really don't see why this is needed, please remove and use rproc->table_ptr
> >>> instead.
> >>
> >> I need to store it for the iounmap in tee_rproc_remove.
> >
> > iounmap(entry->rproc->rsc_table);
> >
> > What am I missing?
>
> rproc->rsc_table is a field that can be updated by remoteproc_core.
> How can we garanty in tee_remoteproc that it still points to the mapped resource
> table?
By making sure the core doesn't touch rproc->rsc_table when
rproc->tee_interface is valid.
> As the remoteproc_tee maps the pointer, it seems reliable that it stores it for
> unmap.
>
Doing so creates a shadow value that is confusing and really hard to maintain
going forward.
> Seems also that I also missed to handle the case where rproc_fw_boot() fails[3]
> (not done yet).
>
> [3]https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/remoteproc_core.c#L1442
>
>
> >
> >>
> >>>
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(tee_rproc_parse_fw);
> >>>> +
> >>>> +struct resource_table *tee_rproc_find_loaded_rsc_table(struct rproc *rproc,
> >>>> + const struct firmware *fw)
> >>>> +{
> >>>> + struct tee_rproc *trproc = rproc->tee_interface;
> >>>> + struct resource_table *rsc_table;
> >>>> + size_t table_sz;
> >>>> +
> >>>> + if (!trproc)
> >>>> + return ERR_PTR(-EINVAL);
> >>>> +
> >>>> + /* Check if the resourse table has already been obtained in tee_rproc_parse_fw() */
> >>>> + if (trproc->rsc_table)
> >>>> + return trproc->rsc_table;
> >>>
> >>> Again, why not simply use rproc->rsc_table? This function should only return
> >>> the resource table that was set in tee_rproc_parse_fw().
> >>
> >> In case of recovery rproc->_rsc_table point to the cached table [1]
> >
> > In [1], on line 1554, add a check for rproc->tee_interface and if it is valid
> > call rproc_find_loaded_rsc_table().
> >
> >> and we need to reapply the configuration in rproc_start() called during the
> >> recovery[2]
> >
> > 1) Rename rproc_set_rsc_table() to rproc_set_rsc_table_on_attach()
> > 2) Introduce a new function called rproc_set_rsc_table_on_start()
> > 3) Move code from [2], line 1278 to 1292, to that new function. In the new
> > function, add a check on rproc->tee_interface. If it is valid then call
> > rproc_find_loaded_rsc_table().
> > 4) in rproc_start(), replace lines 1278 to 1292 with a call to
> > rproc_set_rsc_table_on_start().
>
>
> I will try this
>
Ok
> Thanks!
> Arnaud
>
> >
> >> [1]https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/remoteproc_core.c#L1586
> >> [2]https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/remoteproc_core.c#L1287
> >>
> >>>
> >>>> +
> >>>> + rsc_table = tee_rproc_get_loaded_rsc_table(rproc, &table_sz);
> >>>> + if (IS_ERR(rsc_table))
> >>>> + return rsc_table;
> >>>> +
> >>>> + rproc->table_sz = table_sz;
> >>>> + trproc->rsc_table = rsc_table;
> >>>> +
> >>>> + return rsc_table;
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(tee_rproc_find_loaded_rsc_table);
> >>>> +
> >>>> +int tee_rproc_start(struct rproc *rproc)
> >>>> +{
> >>>> + struct tee_ioctl_invoke_arg arg;
> >>>> + struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
> >>>> + struct tee_rproc *trproc = rproc->tee_interface;
> >>>> + int ret;
> >>>> +
> >>>> + if (!trproc)
> >>>> + return -EINVAL;
> >>>> +
> >>>> + tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_START_FW, &arg, param, 0);
> >>>> +
> >>>> + ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
> >>>> + if (ret < 0 || arg.ret != 0) {
> >>>> + dev_err(tee_rproc_ctx->dev,
> >>>> + "TA_RPROC_FW_CMD_START_FW invoke failed TEE err: %x, ret:%x\n",
> >>>> + arg.ret, ret);
> >>>> + if (!ret)
> >>>> + ret = -EIO;
> >>>> + }
> >>>> +
> >>>> + return ret;
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(tee_rproc_start);
> >>>> +
> >>>> +int tee_rproc_stop(struct rproc *rproc)
> >>>> +{
> >>>> + struct tee_ioctl_invoke_arg arg;
> >>>> + struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
> >>>> + struct tee_rproc *trproc = rproc->tee_interface;
> >>>> + int ret;
> >>>> +
> >>>> + if (!trproc)
> >>>> + return -EINVAL;
> >>>> +
> >>>> + tee_rproc_prepare_args(trproc, TA_RPROC_FW_CMD_STOP_FW, &arg, param, 0);
> >>>> +
> >>>> + ret = tee_client_invoke_func(tee_rproc_ctx->tee_ctx, &arg, param);
> >>>> + if (ret < 0 || arg.ret != 0) {
> >>>> + dev_err(tee_rproc_ctx->dev,
> >>>> + "TA_RPROC_FW_CMD_STOP_FW invoke failed TEE err: %x, ret:%x\n",
> >>>> + arg.ret, ret);
> >>>> + if (!ret)
> >>>> + ret = -EIO;
> >>>> + }
> >>>> +
> >>>> + if (!rproc->table_ptr)
> >>>> + return ret;
> >>>> +
> >>>> + iounmap(trproc->rsc_table);
> >>>> + trproc->rsc_table = NULL;
> >>>> + rproc->table_ptr = NULL;
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(tee_rproc_stop);
> >>>> +
> >>>> +static const struct tee_client_device_id stm32_tee_rproc_id_table[] = {
> >>>> + {UUID_INIT(0x80a4c275, 0x0a47, 0x4905,
> >>>> + 0x82, 0x85, 0x14, 0x86, 0xa9, 0x77, 0x1a, 0x08)},
> >>>> + {}
> >>>> +};
> >>>> +
> >>>> +struct tee_rproc *tee_rproc_register(struct device *dev, struct rproc *rproc, unsigned int rproc_id)
> >>>> +{
> >>>> + struct tee_client_device *tee_device;
> >>>> + struct tee_ioctl_open_session_arg sess_arg;
> >>>> + struct tee_param param[MAX_TEE_PARAM_ARRY_MEMBER];
> >>>> + struct tee_rproc *trproc;
> >>>> + int ret;
> >>>> +
> >>>> + /*
> >>>> + * Test if the device has been probed by the TEE bus. In case of failure, we ignore the
> >>>> + * reason. The bus could be not yet probed or the service not available in the secure
> >>>> + * firmware.The assumption in such a case is that the TEE remoteproc is not probed.
> >>>> + */
> >>>> + if (!tee_rproc_ctx)
> >>>> + return ERR_PTR(-EPROBE_DEFER);
> >>>> +
> >>>> + trproc = devm_kzalloc(dev, sizeof(*trproc), GFP_KERNEL);
> >>>> + if (!trproc)
> >>>> + return ERR_PTR(-ENOMEM);
> >>>> +
> >>>> + tee_device = to_tee_client_device(tee_rproc_ctx->dev);
> >>>> + memset(&sess_arg, 0, sizeof(sess_arg));
> >>>> +
> >>>> + memcpy(sess_arg.uuid, tee_device->id.uuid.b, TEE_IOCTL_UUID_LEN);
> >>>> +
> >>>> + sess_arg.clnt_login = TEE_IOCTL_LOGIN_REE_KERNEL;
> >>>> + sess_arg.num_params = 1;
> >>>> +
> >>>> + param[0] = (struct tee_param) {
> >>>> + .attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
> >>>> + .u.value.a = rproc_id,
> >>>> + };
> >>>> +
> >>>> + ret = tee_client_open_session(tee_rproc_ctx->tee_ctx, &sess_arg, param);
> >>>> + if (ret < 0 || sess_arg.ret != 0) {
> >>>> + dev_err(dev, "tee_client_open_session failed, err: %x\n", sess_arg.ret);
> >>>> + return ERR_PTR(-EINVAL);
> >>>> + }
> >>>> +
> >>>> + trproc->parent = dev;
> >>>> + trproc->rproc_id = rproc_id;
> >>>> + trproc->session_id = sess_arg.session;
> >>>> +
> >>>> + trproc->rproc = rproc;
> >>>> + rproc->tee_interface = trproc;
> >>>> +
> >>>> + list_add_tail(&trproc->node, &tee_rproc_ctx->sessions);
> >>>> +
> >>>> + return trproc;
> >>>
> >>> Once this function was called by a client, what prevents a user from unloading
> >>> the tee_remoteproc module and breaking everything?
> >>
> >> Good point! seems better toremove the module build capability
> >>
> >
> > I was thinking more along the lines of try_module_get() and module_put() to
> > avoid bloating the core.
> >
> >> Thanks,
> >> Arnaud
> >>
> >>>
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(tee_rproc_register);
> >>>> +
> >>>> +int tee_rproc_unregister(struct tee_rproc *trproc)
> >>>> +{
> >>>
> >>> If you pass a struct_rproc instead of a struct tee_rproc there is no need for
> >>> tee_rproc::rproc, which is only ever used in this function.
> >>>
> >>>
> >>>> + struct rproc *rproc = trproc->rproc;
> >>>> + int ret;
> >>>> +
> >>>> + ret = tee_client_close_session(tee_rproc_ctx->tee_ctx, trproc->session_id);
> >>>> + if (ret < 0)
> >>>> + dev_err(trproc->parent, "tee_client_close_session failed, err: %x\n", ret);
> >>>> +
> >>>> + list_del(&trproc->node);
> >>>> + rproc->tee_interface = NULL;
> >>>> +
> >>>> + return ret;
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(tee_rproc_unregister);
> >>>> +
> >>>> +static int tee_rproc_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> >>>> +{
> >>>> + /* Today we support only the OP-TEE, could be extend to other tees */
> >>>> + return (ver->impl_id == TEE_IMPL_ID_OPTEE);
> >>>> +}
> >>>> +
> >>>> +static int tee_rproc_probe(struct device *dev)
> >>>> +{
> >>>> + struct tee_context *tee_ctx;
> >>>> + int ret;
> >>>> +
> >>>> + /* Open context with TEE driver */
> >>>> + tee_ctx = tee_client_open_context(NULL, tee_rproc_ctx_match, NULL, NULL);
> >>>> + if (IS_ERR(tee_ctx))
> >>>> + return PTR_ERR(tee_ctx);
> >>>> +
> >>>> + tee_rproc_ctx = devm_kzalloc(dev, sizeof(*tee_ctx), GFP_KERNEL);
> >>>> + if (!tee_rproc_ctx) {
> >>>> + ret = -ENOMEM;
> >>>> + goto err;
> >>>> + }
> >>>> +
> >>>> + tee_rproc_ctx->dev = dev;
> >>>> + tee_rproc_ctx->tee_ctx = tee_ctx;
> >>>> + INIT_LIST_HEAD(&tee_rproc_ctx->sessions);
> >>>> +
> >>>> + return 0;
> >>>> +err:
> >>>> + tee_client_close_context(tee_ctx);
> >>>> +
> >>>> + return ret;
> >>>> +}
> >>>> +
> >>>> +static int tee_rproc_remove(struct device *dev)
> >>>> +{
> >>>> + struct tee_rproc *entry, *tmp;
> >>>> +
> >>>> + list_for_each_entry_safe(entry, tmp, &tee_rproc_ctx->sessions, node) {
> >>>> + tee_client_close_session(tee_rproc_ctx->tee_ctx, entry->session_id);
> >>>> + list_del(&entry->node);
> >>>> + if (entry->rsc_table)
> >>>> + iounmap(entry->rsc_table);
> >>>> + kfree(entry);
> >>>> + }
> >>>> +
> >>>> + tee_client_close_context(tee_rproc_ctx->tee_ctx);
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>> +
> >>>> +MODULE_DEVICE_TABLE(tee, stm32_tee_rproc_id_table);
> >>>> +
> >>>> +static struct tee_client_driver tee_rproc_fw_driver = {
> >>>> + .id_table = stm32_tee_rproc_id_table,
> >>>> + .driver = {
> >>>> + .name = KBUILD_MODNAME,
> >>>> + .bus = &tee_bus_type,
> >>>> + .probe = tee_rproc_probe,
> >>>> + .remove = tee_rproc_remove,
> >>>> + },
> >>>> +};
> >>>> +
> >>>> +static int __init tee_rproc_fw_mod_init(void)
> >>>> +{
> >>>> + return driver_register(&tee_rproc_fw_driver.driver);
> >>>> +}
> >>>> +
> >>>> +static void __exit tee_rproc_fw_mod_exit(void)
> >>>> +{
> >>>> + driver_unregister(&tee_rproc_fw_driver.driver);
> >>>> +}
> >>>> +
> >>>> +module_init(tee_rproc_fw_mod_init);
> >>>> +module_exit(tee_rproc_fw_mod_exit);
> >>>> +
> >>>> +MODULE_DESCRIPTION(" TEE remote processor control driver");
> >>>> +MODULE_LICENSE("GPL");
> >>>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> >>>> index b4795698d8c2..8b678009e481 100644
> >>>> --- a/include/linux/remoteproc.h
> >>>> +++ b/include/linux/remoteproc.h
> >>>> @@ -503,6 +503,8 @@ enum rproc_features {
> >>>> RPROC_MAX_FEATURES,
> >>>> };
> >>>>
> >>>> +struct tee_rproc;
> >>>> +
> >>>> /**
> >>>> * struct rproc - represents a physical remote processor device
> >>>> * @node: list node of this rproc object
> >>>> @@ -545,6 +547,7 @@ enum rproc_features {
> >>>> * @cdev: character device of the rproc
> >>>> * @cdev_put_on_release: flag to indicate if remoteproc should be shutdown on @char_dev release
> >>>> * @features: indicate remoteproc features
> >>>> + * @tee_interface: pointer to the remoteproc tee context
> >>>> */
> >>>> struct rproc {
> >>>> struct list_head node;
> >>>> @@ -586,6 +589,7 @@ struct rproc {
> >>>> struct cdev cdev;
> >>>> bool cdev_put_on_release;
> >>>> DECLARE_BITMAP(features, RPROC_MAX_FEATURES);
> >>>> + struct tee_rproc *tee_interface;
> >>>> };
> >>>>
> >>>> /**
> >>>> diff --git a/include/linux/tee_remoteproc.h b/include/linux/tee_remoteproc.h
> >>>> new file mode 100644
> >>>> index 000000000000..571e47190d02
> >>>> --- /dev/null
> >>>> +++ b/include/linux/tee_remoteproc.h
> >>>> @@ -0,0 +1,112 @@
> >>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> >>>> +/*
> >>>> + * Copyright(c) 2024 STMicroelectronics - All Rights Reserved
> >>>> + */
> >>>> +
> >>>> +#ifndef TEE_REMOTEPROC_H
> >>>> +#define TEE_REMOTEPROC_H
> >>>> +
> >>>> +#include <linux/tee_drv.h>
> >>>> +#include <linux/firmware.h>
> >>>> +#include <linux/remoteproc.h>
> >>>> +
> >>>> +struct rproc;
> >>>> +
> >>>> +/**
> >>>> + * struct tee_rproc - TEE remoteproc structure
> >>>> + * @node: Reference in list
> >>>> + * @rproc: Remoteproc reference
> >>>> + * @parent: Parent device
> >>>> + * @rproc_id: Identifier of the target firmware
> >>>> + * @session_id: TEE session identifier
> >>>> + * @rsc_table: Resource table virtual address.
> >>>> + */
> >>>> +struct tee_rproc {
> >>>> + struct list_head node;
> >>>> + struct rproc *rproc;
> >>>> + struct device *parent;
> >>>> + u32 rproc_id;
> >>>> + u32 session_id;
> >>>> + struct resource_table *rsc_table;
> >>>> +};
> >>>> +
> >>>> +#if IS_REACHABLE(CONFIG_TEE_REMOTEPROC)
> >>>> +
> >>>> +struct tee_rproc *tee_rproc_register(struct device *dev, struct rproc *rproc,
> >>>> + unsigned int rproc_id);
> >>>> +int tee_rproc_unregister(struct tee_rproc *trproc);
> >>>> +int tee_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw);
> >>>> +int tee_rproc_load_fw(struct rproc *rproc, const struct firmware *fw);
> >>>> +struct resource_table *tee_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz);
> >>>> +struct resource_table *tee_rproc_find_loaded_rsc_table(struct rproc *rproc,
> >>>> + const struct firmware *fw);
> >>>> +int tee_rproc_start(struct rproc *rproc);
> >>>> +int tee_rproc_stop(struct rproc *rproc);
> >>>> +
> >>>> +#else
> >>>> +
> >>>> +static inline struct tee_rproc *tee_rproc_register(struct device *dev, struct rproc *rproc,
> >>>> + unsigned int rproc_id)
> >>>> +{
> >>>> + return ERR_PTR(-ENODEV);
> >>>> +}
> >>>> +
> >>>> +static int tee_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
> >>>> +{
> >>>> + /* This shouldn't be possible */
> >>>> + WARN_ON(1);
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>> +
> >>>> +static inline int tee_rproc_unregister(struct tee_rproc *trproc)
> >>>> +{
> >>>> + /* This shouldn't be possible */
> >>>> + WARN_ON(1);
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>> +
> >>>> +static inline int tee_rproc_load_fw(struct rproc *rproc, const struct firmware *fw)
> >>>> +{
> >>>> + /* This shouldn't be possible */
> >>>> + WARN_ON(1);
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>> +
> >>>> +static inline int tee_rproc_start(struct rproc *rproc)
> >>>> +{
> >>>> + /* This shouldn't be possible */
> >>>> + WARN_ON(1);
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>> +
> >>>> +static inline int tee_rproc_stop(struct rproc *rproc)
> >>>> +{
> >>>> + /* This shouldn't be possible */
> >>>> + WARN_ON(1);
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>> +
> >>>> +static inline struct resource_table *
> >>>> +tee_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
> >>>> +{
> >>>> + /* This shouldn't be possible */
> >>>> + WARN_ON(1);
> >>>> +
> >>>> + return NULL;
> >>>> +}
> >>>> +
> >>>> +static inline struct resource_table *
> >>>> +tee_rproc_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *fw)
> >>>> +{
> >>>> + /* This shouldn't be possible */
> >>>> + WARN_ON(1);
> >>>> +
> >>>> + return NULL;
> >>>> +}
> >>>> +#endif /* CONFIG_TEE_REMOTEPROC */
> >>>> +#endif /* TEE_REMOTEPROC_H */
> >>>> --
> >>>> 2.25.1
> >>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [External] Re: [PATCH bpf-next v2 1/9] bpf: tracing: add support to record and check the accessed args
From: Steven Rostedt @ 2024-04-01 15:59 UTC (permalink / raw)
To: 梦龙董
Cc: Alexei Starovoitov, Jiri Olsa, Andrii Nakryiko,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Eddy Z,
Song Liu, Yonghong Song, John Fastabend, KP Singh,
Stanislav Fomichev, Hao Luo, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, David S. Miller,
David Ahern, Dave Hansen, X86 ML, Mathieu Desnoyers,
Quentin Monnet, bpf, linux-arm-kernel, LKML, linux-riscv,
linux-s390, Network Development, linux-trace-kernel,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32
In-Reply-To: <CALz3k9j_RGqSMdN+GvbHEjRqMWYe4R9VNZRANG7jbfL_jVpoVg@mail.gmail.com>
On Mon, 1 Apr 2024 10:28:17 +0800
梦龙董 <dongmenglong.8@bytedance.com> wrote:
> On Sun, Mar 31, 2024 at 3:34 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Sat, 30 Mar 2024 11:18:29 +0800
> > 梦龙董 <dongmenglong.8@bytedance.com> wrote:
> >
> > > > If you really want to have thousands of functions, why not just register it
> > > > with ftrace itself. It will give you the arguments via the ftrace_regs
> > > > structure. Can't you just register a program as the callback?
> > > >
> > >
> > > Ennn...I don't understand. The main purpose for
> > > me to use TRACING is:
> > >
> > > 1. we can directly access the memory, which is more
> > > efficient.
> >
> > I'm not sure what you mean by the above. Access what memory?
> >
>
> We need to use the helper of bpf_probe_read_kernel
> when we read "skb->sk" in kprobe, and the "skb" is the
> 1st arg in ip_rcv(). And we can directly read "skb->sk"
> in tracing, which is more efficient. Isn't it?
If you add a ftrace_ops function handler that calls a BPF program, I don't
see why you can't just give it the parameters it needs instead of using bpf
helpers. It's no different than using a trampoline to do the same thing.
-- Steve
_______________________________________________
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 5/6] dt-bindings: clock: meson: add A1 CPU clock controller bindings
From: Rob Herring @ 2024-04-01 14:57 UTC (permalink / raw)
To: Dmitry Rokosov
Cc: sboyd, neil.armstrong, jbrunet, khilman, rockosov, linux-clk,
linux-kernel, krzysztof.kozlowski+dt, kernel, devicetree,
linux-amlogic, robh+dt, mturquette, linux-arm-kernel,
martin.blumenstingl
In-Reply-To: <20240329205904.25002-6-ddrokosov@salutedevices.com>
On Fri, 29 Mar 2024 23:58:45 +0300, Dmitry Rokosov wrote:
> Add the documentation and dt bindings for Amlogic A1 CPU clock
> controller.
>
> This controller consists of the general 'cpu_clk' and two main parents:
> 'cpu fixed clock' and 'syspll'. The 'cpu fixed clock' is an internal
> fixed clock, while the 'syspll' serves as an external input from the A1
> PLL clock controller.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> ---
> .../bindings/clock/amlogic,a1-cpu-clkc.yaml | 64 +++++++++++++++++++
> .../dt-bindings/clock/amlogic,a1-cpu-clkc.h | 19 ++++++
> 2 files changed, 83 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/amlogic,a1-cpu-clkc.yaml
> create mode 100644 include/dt-bindings/clock/amlogic,a1-cpu-clkc.h
>
Reviewed-by: Rob Herring <robh@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
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