* Re: [PATCH v10 09/11] arm64: dts: imx93-11x11-evk: enable usb and typec nodes
From: Shawn Guo @ 2024-04-02 9:07 UTC (permalink / raw)
To: Xu Yang
Cc: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt,
s.hauer, kernel, festevam, linux-imx, peter.chen, jun.li,
linux-usb, devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240321081439.541799-9-xu.yang_2@nxp.com>
On Thu, Mar 21, 2024 at 04:14:37PM +0800, Xu Yang wrote:
> There are 2 Type-C ports and 2 USB controllers on i.MX93. Enable them.
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
>
> ---
> Changes in v2:
> - remove status property in ptn5110 nodes
> - fix dt-schema warnings
> Changes in v3:
> - no changes
> Changes in v4:
> - no changes
> Changes in v5:
> - no changes
> Changes in v6:
> - no changes
> Changes in v7:
> - no changes
> Changes in v8:
> - no changes
> Changes in v9:
> - use compatible "nxp,ptn5110", "tcpci"
> Changes in v10:
> - no changes
> ---
> .../boot/dts/freescale/imx93-11x11-evk.dts | 118 ++++++++++++++++++
> 1 file changed, 118 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> index 9921ea13ab48..ecc01d872e95 100644
> --- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> @@ -5,6 +5,7 @@
>
> /dts-v1/;
>
> +#include <dt-bindings/usb/pd.h>
> #include "imx93.dtsi"
>
> / {
> @@ -104,6 +105,80 @@ &mu2 {
> status = "okay";
> };
>
> +&lpi2c3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-frequency = <400000>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pinctrl_lpi2c3>;
> + pinctrl-1 = <&pinctrl_lpi2c3>;
Do you really need "sleep" pinctrl state?
> + status = "okay";
> +
> + ptn5110: tcpc@50 {
> + compatible = "nxp,ptn5110", "tcpci";
> + reg = <0x50>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> +
> + typec1_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
> + power-role = "dual";
> + data-role = "dual";
> + try-power-role = "sink";
> + source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> + sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
> + PDO_VAR(5000, 20000, 3000)>;
> + op-sink-microwatt = <15000000>;
> + self-powered;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
Have a newline between properties and child node.
Shawn
> + typec1_dr_sw: endpoint {
> + remote-endpoint = <&usb1_drd_sw>;
> + };
> + };
> + };
> + };
> + };
> +
> + ptn5110_2: tcpc@51 {
> + compatible = "nxp,ptn5110", "tcpci";
> + reg = <0x51>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> +
> + typec2_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
> + power-role = "dual";
> + data-role = "dual";
> + try-power-role = "sink";
> + source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> + sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
> + PDO_VAR(5000, 20000, 3000)>;
> + op-sink-microwatt = <15000000>;
> + self-powered;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + typec2_dr_sw: endpoint {
> + remote-endpoint = <&usb2_drd_sw>;
> + };
> + };
> + };
> + };
> + };
> +};
> +
> &eqos {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_eqos>;
> @@ -156,6 +231,42 @@ &lpuart5 {
> status = "okay";
> };
>
> +&usbotg1 {
> + dr_mode = "otg";
> + hnp-disable;
> + srp-disable;
> + adp-disable;
> + usb-role-switch;
> + disable-over-current;
> + samsung,picophy-pre-emp-curr-control = <3>;
> + samsung,picophy-dc-vol-level-adjust = <7>;
> + status = "okay";
> +
> + port {
> + usb1_drd_sw: endpoint {
> + remote-endpoint = <&typec1_dr_sw>;
> + };
> + };
> +};
> +
> +&usbotg2 {
> + dr_mode = "otg";
> + hnp-disable;
> + srp-disable;
> + adp-disable;
> + usb-role-switch;
> + disable-over-current;
> + samsung,picophy-pre-emp-curr-control = <3>;
> + samsung,picophy-dc-vol-level-adjust = <7>;
> + status = "okay";
> +
> + port {
> + usb2_drd_sw: endpoint {
> + remote-endpoint = <&typec2_dr_sw>;
> + };
> + };
> +};
> +
> &usdhc1 {
> pinctrl-names = "default", "state_100mhz", "state_200mhz";
> pinctrl-0 = <&pinctrl_usdhc1>;
> @@ -222,6 +333,13 @@ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
> >;
> };
>
> + pinctrl_lpi2c3: lpi2c3grp {
> + fsl,pins = <
> + MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
> + MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
> + >;
> + };
> +
> pinctrl_uart1: uart1grp {
> fsl,pins = <
> MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
> --
> 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
* [PATCH 0/2] Fix the regulator-state-standby definition
From: Andrei Simion @ 2024-04-02 9:12 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, mihai.sain
Cc: linux-arm-kernel, linux-kernel, devicetree, Andrei Simion
make dtbs_check DT_SCHEMA_FILES=microchip,mcp16502.yaml
at91-sama7g5ek.dtb: mcp16502@5b: regulators:VDD_(CORE|OTHER)|LDO[1-2]:
regulator-state-standby 'regulator-suspend-voltage' does not match any of
the regexes 'pinctrl-[0-9]+' from schema
$id: http://devicetree.org/schemas/regulator/microchip,mcp16502.yaml#
at91-sama7g54_curiosity.dtb: pmic@5b: regulators:VDD_(CORE|OTHER)|LDO[1-2]:
regulator-state-standby 'regulator-suspend-voltage' does not match any of
the regexes 'pinctrl-[0-9]+' from schema
$id: http://devicetree.org/schemas/regulator/microchip,mcp16502.yaml#
This patch series proposes to correct the typo that was entered by mistake
into devicetree definition regulator-state-standby by replacing
regulator-suspend-voltage with regulator-suspend-microvolt.
Andrei Simion (2):
ARM: boot: dts: microchip: at91-sama7g5ek: Replace
regulator-suspend-voltage with the valid property
ARM: boot: dts: microchip: at91-sama7g54_curiosity: Replace
regulator-suspend-voltage with the valid property
arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts | 8 ++++----
arch/arm/boot/dts/microchip/at91-sama7g5ek.dts | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
--
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
* [PATCH 2/2] ARM: boot: dts: microchip: at91-sama7g54_curiosity: Replace regulator-suspend-voltage with the valid property
From: Andrei Simion @ 2024-04-02 9:12 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, mihai.sain
Cc: linux-arm-kernel, linux-kernel, devicetree, Andrei Simion
In-Reply-To: <20240402091228.110362-1-andrei.simion@microchip.com>
Replace regulator-suspend-voltage with regulator-suspend-microvolt.
Fixes: ebd6591f8ddb ("ARM: dts: microchip: sama7g54_curiosity: Add initial device tree of the board")
Signed-off-by: Andrei Simion <andrei.simion@microchip.com>
---
arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts b/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts
index 4f609e9e510e..009d2c832421 100644
--- a/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts
@@ -242,7 +242,7 @@ vddcore: VDD_CORE {
regulator-state-standby {
regulator-on-in-suspend;
- regulator-suspend-voltage = <1150000>;
+ regulator-suspend-microvolt = <1150000>;
regulator-mode = <4>;
};
@@ -263,7 +263,7 @@ vddcpu: VDD_OTHER {
regulator-state-standby {
regulator-on-in-suspend;
- regulator-suspend-voltage = <1050000>;
+ regulator-suspend-microvolt = <1050000>;
regulator-mode = <4>;
};
@@ -280,7 +280,7 @@ vldo1: LDO1 {
regulator-always-on;
regulator-state-standby {
- regulator-suspend-voltage = <1800000>;
+ regulator-suspend-microvolt = <1800000>;
regulator-on-in-suspend;
};
@@ -296,7 +296,7 @@ vldo2: LDO2 {
regulator-always-on;
regulator-state-standby {
- regulator-suspend-voltage = <3300000>;
+ regulator-suspend-microvolt = <3300000>;
regulator-on-in-suspend;
};
--
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/2] ARM: boot: dts: microchip: at91-sama7g5ek: Replace regulator-suspend-voltage with the valid property
From: Andrei Simion @ 2024-04-02 9:12 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, mihai.sain
Cc: linux-arm-kernel, linux-kernel, devicetree, Andrei Simion
In-Reply-To: <20240402091228.110362-1-andrei.simion@microchip.com>
Replace regulator-suspend-voltage with regulator-suspend-microvolt.
Fixes: 85b1304b9daa ("ARM: dts: at91: sama7g5ek: set regulator voltages for standby state")
Signed-off-by: Andrei Simion <andrei.simion@microchip.com>
---
arch/arm/boot/dts/microchip/at91-sama7g5ek.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts b/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts
index 217e9b96c61e..20b2497657ae 100644
--- a/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts
@@ -293,7 +293,7 @@ vddcore: VDD_CORE {
regulator-state-standby {
regulator-on-in-suspend;
- regulator-suspend-voltage = <1150000>;
+ regulator-suspend-microvolt = <1150000>;
regulator-mode = <4>;
};
@@ -314,7 +314,7 @@ vddcpu: VDD_OTHER {
regulator-state-standby {
regulator-on-in-suspend;
- regulator-suspend-voltage = <1050000>;
+ regulator-suspend-microvolt = <1050000>;
regulator-mode = <4>;
};
@@ -331,7 +331,7 @@ vldo1: LDO1 {
regulator-always-on;
regulator-state-standby {
- regulator-suspend-voltage = <1800000>;
+ regulator-suspend-microvolt = <1800000>;
regulator-on-in-suspend;
};
@@ -346,7 +346,7 @@ vldo2: LDO2 {
regulator-max-microvolt = <3700000>;
regulator-state-standby {
- regulator-suspend-voltage = <1800000>;
+ regulator-suspend-microvolt = <1800000>;
regulator-on-in-suspend;
};
--
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 2/2] arm64: acpi: Honour firmware_signature field of FACS, if it exists
From: David Woodhouse @ 2024-04-02 9:29 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Robert Moore, Rafael J. Wysocki,
Len Brown, mediou, alisaidi, linux-kernel, linux-acpi,
acpica-devel, Saket Dumbre
In-Reply-To: <20240312134148.727454-2-dwmw2@infradead.org>
[-- Attachment #1.1: Type: text/plain, Size: 1968 bytes --]
On Tue, 2024-03-12 at 13:41 +0000, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> If the firmware_signature changes then OSPM should not attempt to resume
> from hibernate, but should instead perform a clean reboot. Set the global
> swsusp_hardware_signature to allow the generic code to include the value
> in the swsusp header on disk, and perform the appropriate check on resume.
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Ping?
> ---
> arch/arm64/kernel/acpi.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index dba8fcec7f33..e0e7b93c16cc 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -26,6 +26,7 @@
> #include <linux/libfdt.h>
> #include <linux/smp.h>
> #include <linux/serial_core.h>
> +#include <linux/suspend.h>
> #include <linux/pgtable.h>
>
> #include <acpi/ghes.h>
> @@ -227,6 +228,15 @@ void __init acpi_boot_table_init(void)
> if (earlycon_acpi_spcr_enable)
> early_init_dt_scan_chosen_stdout();
> } else {
> +#ifdef CONFIG_HIBERNATION
> + struct acpi_table_header *facs = NULL;
> + acpi_get_table(ACPI_SIG_FACS, 1, &facs);
> + if (facs) {
> + swsusp_hardware_signature =
> + ((struct acpi_table_facs *)facs)->hardware_signature;
> + acpi_put_table(facs);
> + }
> +#endif
> acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
> if (IS_ENABLED(CONFIG_ACPI_BGRT))
> acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 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 v1 6/6] clk: meson: a1: add Amlogic A1 CPU clock controller driver
From: Jerome Brunet @ 2024-04-02 9:27 UTC (permalink / raw)
To: Dmitry Rokosov
Cc: Martin Blumenstingl, neil.armstrong, jbrunet, mturquette, sboyd,
robh+dt, krzysztof.kozlowski+dt, khilman, kernel, rockosov,
linux-amlogic, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240401171237.qoewp2pgcdrqvc3e@CAB-WSD-L081021>
On Mon 01 Apr 2024 at 20:12, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
> Hello Martin,
>
> Thank you for quick response. Please find my thoughts below.
>
> On Sun, Mar 31, 2024 at 11:40:13PM +0200, Martin Blumenstingl wrote:
>> Hi Dmitry,
>>
>> On Fri, Mar 29, 2024 at 9:59 PM Dmitry Rokosov
>> <ddrokosov@salutedevices.com> wrote:
>> [...]
>> > +static struct clk_regmap cpu_fclk = {
>> > + .data = &(struct clk_regmap_mux_data) {
>> > + .offset = CPUCTRL_CLK_CTRL0,
>> > + .mask = 0x1,
>> > + .shift = 10,
>> > + },
>> > + .hw.init = &(struct clk_init_data) {
>> > + .name = "cpu_fclk",
>> > + .ops = &clk_regmap_mux_ops,
>> > + .parent_hws = (const struct clk_hw *[]) {
>> > + &cpu_fsel0.hw,
>> > + &cpu_fsel1.hw,
>> Have you considered the CLK_SET_RATE_GATE flag for &cpu_fsel0.hw and
>> &cpu_fsel1.hw and then dropping the clock notifier below?
>> We use that approach with the Mali GPU clock on other SoCs, see for
>> example commit 8daeaea99caa ("clk: meson: meson8b: make the CCF use
>> the glitch-free mali mux").
>> It may differ from what Amlogic does in their BSP,
>
> Amlogic in their BSP takes a different approach, which is slightly
> different from mine. They cleverly change the parent of cpu_clk directly
> by forking the cpufreq driver to a custom version. I must admit, it's
> quite an "interesting and amazing" idea :) but it's not architecturally
> correct totally.
I disagree. Martin's suggestion is correct for the fsel part which is
symetric.
>
>> but I don't think
>> that there's any harm (if it works in general) because CCF (common
>> clock framework) will set all clocks in the "inactive" tree and then
>> as a last step just change the mux (&cpu_fclk.hw). So at no point in
>> time will we get any other rate than a) the original CPU clock rate
>> before the rate change b) the new desired CPU clock rate. This is
>> because we have two symmetric clock trees.
>
> Now, let's dive into the specifics of the issue we're facing. I've
> examined the CLK_SET_RATE_GATE flag, which, to my understanding, blocks
> rate changes for the entire clock chain. However, in this particular
> situation, it doesn't provide the solution we need.
>
> Here's the problem we're dealing with:
>
> 1) The CPU clock can have the following frequency points:
>
> available frequency steps: 128 MHz, 256 MHz, 512 MHz, 768 MHz, 1.01 GHz, 1.20 GHz
>
> When we run the cpupower, we get the following information:
> # cpupower -c 0,1 frequency-info
> analyzing CPU 0:
> driver: cpufreq-dt
> CPUs which run at the same hardware frequency: 0 1
> CPUs which need to have their frequency coordinated by software: 0 1
> maximum transition latency: 50.0 us
> hardware limits: 128 MHz - 1.20 GHz
> available frequency steps: 128 MHz, 256 MHz, 512 MHz, 768 MHz, 1.01 GHz, 1.20 GHz
> available cpufreq governors: conservative ondemand userspace performance schedutil
> current policy: frequency should be within 128 MHz and 128 MHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency: 128 MHz (asserted by call to hardware)
> analyzing CPU 1:
> driver: cpufreq-dt
> CPUs which run at the same hardware frequency: 0 1
> CPUs which need to have their frequency coordinated by software: 0 1
> maximum transition latency: 50.0 us
> hardware limits: 128 MHz - 1.20 GHz
> available frequency steps: 128 MHz, 256 MHz, 512 MHz, 768 MHz, 1.01 GHz, 1.20 GHz
> available cpufreq governors: conservative ondemand userspace performance schedutil
> current policy: frequency should be within 128 MHz and 128 MHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency: 128 MHz (asserted by call to hardware)
>
> 2) For the frequency points 128 MHz, 256 MHz, and 512 MHz, the CPU fixed
> clock should be used.
Apparently, you are relying on the SYS PLL lowest possible rate to
enfore this contraint, which I suppose is 24 * 32 = 768MHz. It would be
nice to clearly say so.
> Fortunately, we don't encounter any freeze
> problems when we attempt to change its rate at these frequencies.
That does not sound very solid ...
>
> 3) However, for the frequency points 768 MHz, 1.01 GHz, and 1.20 GHz,
> the sys_pll is used as the clock source because it's a faster option.
> Now, let's imagine that we want to change the CPU clock from 768 MHz to
> 1.01 GHz. Unfortunately, it's not possible due to the broken sys_pll,
> and any execution attempts will result in a hang.
... Because PLL needs to relock, it is going to be off for a while. That
is not "broken", unless there is something else ?
>
> 4) As you can observe, in this case, we actually don't need to lock the
> rate for the sys_pll chain.
In which case ? I'm lost.
> We want to change the rate instead.
... How are you going to do that without relocking the PLL ?
> Hence,
> I'm not aware of any other method to achieve this except by switching
> the cpu_clk parent to a stable clock using clock notifier block.
> Interestingly, I've noticed a similar approach in the CPU clock drivers
> of Rockchip, Qualcomm, and Mediatek.
There is an example of syspll notifier in the g12 clock controller.
You should have a look at it
--
Jerome
_______________________________________________
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] arm: kasan: clear stale stack poison
From: Mark Rutland @ 2024-04-02 9:36 UTC (permalink / raw)
To: boy.wu
Cc: Russell King, Matthias Brugger, AngeloGioacchino Del Regno,
linux-arm-kernel, linux-kernel, linux-mediatek, Andrey Ryabinin,
Linus Walleij
In-Reply-To: <20231222022741.8223-1-boy.wu@mediatek.com>
Hi,
On Fri, Dec 22, 2023 at 10:27:41AM +0800, boy.wu wrote:
> From: Boy Wu <boy.wu@mediatek.com>
>
> We found below OOB crash:
>
> [ 33.452494] ==================================================================
> [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
> [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0
> [ 33.455515]
> [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1
> [ 33.456880] Hardware name: Generic DT based system
> [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c
> [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c
> [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4
> [ 33.459863] print_report from kasan_report+0x9c/0x148
> [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0
> [ 33.461424] kasan_check_range from memset+0x20/0x3c
> [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
> [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c
> [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354
> [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24
> [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4
> [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18
> [ 33.467397]
> [ 33.467644] The buggy address belongs to stack of task swapper/0/0
> [ 33.468493] and is located at offset 112 in frame:
> [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec
> [ 33.469917]
> [ 33.470165] This frame has 2 objects:
> [ 33.470696] [32, 76) 'global_zone_diff'
> [ 33.470729] [112, 276) 'global_node_diff'
> [ 33.471294]
> [ 33.472095] The buggy address belongs to the physical page:
> [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03
> [ 33.473944] flags: 0x1000(reserved|zone=0)
> [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001
> [ 33.475656] raw: 00000000
> [ 33.476050] page dumped because: kasan: bad access detected
> [ 33.476816]
> [ 33.477061] Memory state around the buggy address:
> [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
> [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1
> [ 33.480415] ^
> [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3
> [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
> [ 33.482978] ==================================================================
>
> We find the root cause of this OOB is that arm does not clear stale stack
> poison in the case of cpuidle.
>
> This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.
>
> Signed-off-by: Boy Wu <boy.wu@mediatek.com>
It looks like you're specifically referring to what arm64 did in commit:
0d97e6d8024c71cc ("arm64: kasan: clear stale stack poison")
Where the commit message explained the problem:
| Functions which the compiler has instrumented for KASAN place poison on
| the stack shadow upon entry and remove this poison prior to returning.
|
| In the case of cpuidle, CPUs exit the kernel a number of levels deep in
| C code. Any instrumented functions on this critical path will leave
| portions of the stack shadow poisoned.
|
| If CPUs lose context and return to the kernel via a cold path, we
| restore a prior context saved in __cpu_suspend_enter are forgotten, and
| we never remove the poison they placed in the stack shadow area by
| functions calls between this and the actual exit of the kernel.
|
| Thus, (depending on stackframe layout) subsequent calls to instrumented
| functions may hit this stale poison, resulting in (spurious) KASAN
| splats to the console.
|
| To avoid this, clear any stale poison from the idle thread for a CPU
| prior to bringing a CPU online.
... which we then extended to check for CONFIG_KASAN_STACK in commit:
d56a9ef84bd0e1e8 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")
If you can fold in the description above (i.e. cite commit 0d97e6d8024c71cc and
a copy of its commit message):
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm/kernel/sleep.S | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
> index a86a1d4f3461..93afd1005b43 100644
> --- a/arch/arm/kernel/sleep.S
> +++ b/arch/arm/kernel/sleep.S
> @@ -127,6 +127,10 @@ cpu_resume_after_mmu:
> instr_sync
> #endif
> bl cpu_init @ restore the und/abt/irq banked regs
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> + mov r0, sp
> + bl kasan_unpoison_task_stack_below
> +#endif
> mov r0, #0 @ return zero on success
> ldmfd sp!, {r4 - r11, pc}
> ENDPROC(cpu_resume_after_mmu)
> --
> 2.18.0
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: ti: k3-am62p-main: use eFuse MAC Address for CPSW3G Port 1
From: Siddharth Vadapalli @ 2024-04-02 9:42 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzysztof.kozlowski+dt, conor+dt
Cc: devicetree, linux-kernel, linux-arm-kernel, srk, s-vadapalli
Assign the MAC Address programmed in the eFuse registers as the default
MAC Address for CPSW3G MAC Port 1. Utilize the "ti,syscon-efuse"
device-tree property to do so.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
---
This patch is based on linux-next tagged next-20240402.
Regards,
Siddharth.
arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
index 7337a9e13535..eb126f4a04dd 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
@@ -696,6 +696,7 @@ cpsw_port1: port@1 {
label = "port1";
phys = <&phy_gmii_sel 1>;
mac-address = [00 00 00 00 00 00];
+ ti,syscon-efuse = <&wkup_conf 0x200>;
};
cpsw_port2: port@2 {
--
2.40.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 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-04-02 9:48 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <ZgvIMRDfeQaeVxYt@shell.armlinux.org.uk>
On 02/04/2024 10:56, Russell King (Oracle) wrote:
> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>> Merging
>>> =======
>>> All further patches depend on the first amba patch, therefore please ack
>>> and this should go via one tree.
>>>
>>> Description
>>> ===========
>>> Modules registering driver with amba_driver_register() often forget to
>>> set .owner field.
>>>
>>> Solve the problem by moving this task away from the drivers to the core
>>> amba bus code, just like we did for platform_driver in commit
>>> 9447057eaff8 ("platform_device: use a macro instead of
>>> platform_driver_register").
>>>
>>> Best regards,
>>
>> I tried to submit this series to Russell patch tracker and failed. This
>> is ridiculous. It's 2024 and instead of normal process, like every other
>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>> standard patches.
>
> Sorry but no. Stop being offensive.
>
>> First, it depends some weird, duplicated signed-off-by's.
>
> Eh? There is no such logic in there.
In the web system there is - read the error message I pasted. It wants
another SoB from the unrelated email account, the one used purely for
registering in some web system, not the one used for code handling.
>
>> Second it > submitting patch-by-patch, all with clicking on some web
>> (!!!) interface.
>
> Again, no it doesn't, and you're just throwing crap out because you
> failed. Unlike most of the "normal" processes, the patch system allows
> you to submit both by *email* and also by *web* for those cases where
The email one requires additional steps, so this is unnecessary work
confusing submitters. I submit dozens or hundreds of patches every
release cycle. That's the only subsystem which is odd to use.
> the emails get screwed up by ones company mail server. That's why the
> web interface exists - to give people *flexibility*.
No, they are not. None of my emails are screwed by my company system.
>
> The fact is, the web interface is merely a front end interface that
> generates an email and submits it in the usual way by email - an
> email that you can perfectly well generate that is *very* close to
> the standard email that git format-patch generates.
>
> The *only* difference is that the patch system wants a KernelVersion:
> tag in the email _somewhere_ and it doesn't matter where it appears.
> Git even has support to do this.
>
> git format-patch --add-header="KernelVersion: $foo"
>
> Why does it want the kernel version? Because when we were running 2.4
> and 2.5 kernel versions in parallel, it was important to know which
> tree the patch was being submitted for. It has continued to be required
Which is absolutely ridiculous now. Expecting submitters to adhere to
some rule for 20 year old kernel is not reasonable.
> because it means when there's problems applying a patch, it gives me
> the additional information about the base used for the patch (and it
> keeps on being useful to have.)
>
>> That's the response:
>> -------------
>> Your patch has not been logged because:
>>
>> Error: Please supply a summary subject line briefly describing
>> your patch.
>>
>>
>> Error: Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
>> "---".
>>
>> Error: the patch you are submitting has one or more missing or incorrect
>> Signed-off-by lines:
>>
>> - author signoff <krzkreg@gmail.com> is missing.
^^^ here you have additional SoB expectation.
>>
>> Please see the file Documentation/SubmittingPatches, section 11
>> for details on signing off patches.
>
> Lots of people use it without a problem. I've just run the parser
> through its offline tests, and it parses email content correctly.
> I've no idea what you're doing wrong, but it looks like something
> pretty serious if it didn't parse the subject line.
>
> Rather than getting stressed about it, why don't you send me an email
> the first time something goes wrong so I can investigate, turn on
> debugging to capture the problem email?
I don't know any person who enjoyed working with your patch workflow.
From few people I talked, it was always "now I have to learn this weird
system" or "I need to get through this process which is different than
everything in the kernel".
Plus you entirely ignored poor usability of this system which:
1. Allows submitting patches only 1-by-1, so 19 useless steps in my case.
2. Accepts the first/second/all patches without problem encouraging me
to submit the rest... and then tells me via email they were wrong and
could not be accepted.
This is the poorest user-experience one can imagine. If you put effort
into some web form, make it at least helpful so reject the patch if it
does not match your expectations.
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] arm: kasan: clear stale stack poison
From: Andrey Ryabinin @ 2024-04-02 9:48 UTC (permalink / raw)
To: Mark Rutland
Cc: boy.wu, Russell King, Matthias Brugger,
AngeloGioacchino Del Regno, linux-arm-kernel, linux-kernel,
linux-mediatek, Linus Walleij
In-Reply-To: <ZgvRmhbvVoGHcLqu@FVFF77S0Q05N>
On Tue, Apr 2, 2024 at 11:36 AM Mark Rutland <mark.rutland@arm.com> wrote:
...
> It looks like you're specifically referring to what arm64 did in commit:
>
> 0d97e6d8024c71cc ("arm64: kasan: clear stale stack poison")
>
> Where the commit message explained the problem:
>
> | Functions which the compiler has instrumented for KASAN place poison on
> | the stack shadow upon entry and remove this poison prior to returning.
> |
> | In the case of cpuidle, CPUs exit the kernel a number of levels deep in
> | C code. Any instrumented functions on this critical path will leave
> | portions of the stack shadow poisoned.
> |
> | If CPUs lose context and return to the kernel via a cold path, we
> | restore a prior context saved in __cpu_suspend_enter are forgotten, and
> | we never remove the poison they placed in the stack shadow area by
> | functions calls between this and the actual exit of the kernel.
> |
> | Thus, (depending on stackframe layout) subsequent calls to instrumented
> | functions may hit this stale poison, resulting in (spurious) KASAN
> | splats to the console.
> |
> | To avoid this, clear any stale poison from the idle thread for a CPU
> | prior to bringing a CPU online.
>
> ... which we then extended to check for CONFIG_KASAN_STACK in commit:
>
> d56a9ef84bd0e1e8 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")
>
> If you can fold in the description above (i.e. cite commit 0d97e6d8024c71cc and
> a copy of its commit message):
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
>
Agreed with the above, feel free to add:
Acked-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
_______________________________________________
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] media: mediatek: vcodec: fix h264 multi statless decoder smatch warning
From: AngeloGioacchino Del Regno @ 2024-04-02 9:50 UTC (permalink / raw)
To: Yunfei Dong, Nícolas F . R . A . Prado, Nicolas Dufresne,
Hans Verkuil, Benjamin Gaignard, Nathan Hebert
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, linux-media,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240229095611.6698-2-yunfei.dong@mediatek.com>
Il 29/02/24 10:56, Yunfei Dong ha scritto:
> Fix smatch static checker warning for vdec_h264_req_multi_if.c.
> Leading to kernel crash when fb is NULL.
>
> Fixes: 397edc703a10 ("media: mediatek: vcodec: add h264 decoder")
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
> .../vcodec/decoder/vdec/vdec_h264_req_multi_if.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
> index 0e741e0dc8ba..ab8e708e0df1 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
> @@ -724,11 +724,16 @@ static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs
> return vpu_dec_reset(vpu);
>
> fb = inst->ctx->dev->vdec_pdata->get_cap_buffer(inst->ctx);
> + if (!fb) {
> + mtk_vdec_err(inst->ctx, "fb buffer is NULL");
> + return -EBUSY;
> + }
> +
> src_buf_info = container_of(bs, struct mtk_video_dec_buf, bs_buffer);
> dst_buf_info = container_of(fb, struct mtk_video_dec_buf, frame_buffer);
>
> - y_fb_dma = fb ? (u64)fb->base_y.dma_addr : 0;
> - c_fb_dma = fb ? (u64)fb->base_c.dma_addr : 0;
You're changing the behavior here, can you please explain why this change is valid
into the commit description?
Thanks,
Angelo
> + y_fb_dma = (u64)fb->base_y.dma_addr;
> + c_fb_dma = (u64)fb->base_c.dma_addr;
> mtk_vdec_debug(inst->ctx, "[h264-dec] [%d] y_dma=%llx c_dma=%llx",
> inst->ctx->decoded_frame_cnt, y_fb_dma, c_fb_dma);
>
_______________________________________________
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/4] arm64: kexec: Change relocate_kernel to C code
From: Mark Rutland @ 2024-04-02 9:55 UTC (permalink / raw)
To: Pingfan Liu
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Kees Cook, Pasha Tatashin
In-Reply-To: <20240328115656.24090-5-piliu@redhat.com>
On Thu, Mar 28, 2024 at 07:56:54PM +0800, Pingfan Liu wrote:
> The kexec_relocate.o is a self-contained section, and it should be PIE.
>
> Beside that, C function call requires stack, which is built on the idmap
> of the rear of kimage->control_code_page.
>
> Signed-off-by: Pingfan Liu <piliu@redhat.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> To: linux-arm-kernel@lists.infradead.org
> ---
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/asm-offsets.c | 10 --
> arch/arm64/kernel/machine_kexec.c | 9 +-
> arch/arm64/kernel/relocate_kernel.S | 100 --------------
> arch/arm64/kernel/relocate_kernel.c | 197 ++++++++++++++++++++++++++++
> arch/arm64/kernel/vmlinux.lds.S | 1 +
> 6 files changed, 206 insertions(+), 112 deletions(-)
> delete mode 100644 arch/arm64/kernel/relocate_kernel.S
> create mode 100644 arch/arm64/kernel/relocate_kernel.c
> +static void __kexec_section turn_mmu_off(void)
> +{
> + u64 tmp = INIT_SCTLR_EL1_MMU_OFF;
> +
> + /* pre_disable_mmu_workaround */
> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
> + isb();
> +#endif
> + write_sysreg(tmp, sctlr_el1);
> + isb();
> +}
Disabling the MMU cannot be done from C; as soon as we write to SCTLR_EL1 (even
before the ISB) we cannot safely access the stack until that has been explcitly
cleaned+invalidated to the PoC (and that has to be done by VA).
I don't think we should bother trying to move this to C; the MMU-off portions
should remain as asssembly.
If you want to move the MMU-on portions to C, then *maybe* that's worthwhile, but
given the diffstat I reckon it's better to leave this all as asm for now. We
can make this more legibile without converting it to C.
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] arm64: dts: ti: k3-am62p-main: use eFuse MAC Address for CPSW3G Port 1
From: Vignesh Raghavendra @ 2024-04-02 9:55 UTC (permalink / raw)
To: Siddharth Vadapalli, nm, kristo, robh, krzysztof.kozlowski+dt,
conor+dt
Cc: devicetree, linux-kernel, linux-arm-kernel, srk
In-Reply-To: <20240402094200.4036076-1-s-vadapalli@ti.com>
On 02/04/24 15:12, Siddharth Vadapalli wrote:
> Assign the MAC Address programmed in the eFuse registers as the default
> MAC Address for CPSW3G MAC Port 1. Utilize the "ti,syscon-efuse"
> device-tree property to do so.
>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> ---
>
> This patch is based on linux-next tagged next-20240402.
>
> Regards,
> Siddharth.
>
> arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> index 7337a9e13535..eb126f4a04dd 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> @@ -696,6 +696,7 @@ cpsw_port1: port@1 {
> label = "port1";
> phys = <&phy_gmii_sel 1>;
> mac-address = [00 00 00 00 00 00];
> + ti,syscon-efuse = <&wkup_conf 0x200>;
Sorry, how does this work? wkup_conf is not marked as "syscon" compatible?
> };
>
> cpsw_port2: port@2 {
--
Regards
Vignesh
_______________________________________________
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 6/6] clk: meson: a1: add Amlogic A1 CPU clock controller driver
From: Jerome Brunet @ 2024-04-02 9:35 UTC (permalink / raw)
To: Dmitry Rokosov
Cc: neil.armstrong, jbrunet, mturquette, sboyd, robh+dt,
krzysztof.kozlowski+dt, khilman, martin.blumenstingl, kernel,
rockosov, linux-amlogic, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240329205904.25002-7-ddrokosov@salutedevices.com>
On Fri 29 Mar 2024 at 23:58, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
> The CPU clock controller plays a general role in the Amlogic A1 SoC
> family by generating CPU clocks. As an APB slave module, it offers the
> capability to inherit the CPU clock from two sources: the internal fixed
> clock known as 'cpu fixed clock' and the external input provided by the
> A1 PLL clock controller, referred to as 'syspll'.
>
> It is important for the driver to handle cpu_clk rate switching
> effectively by transitioning to the CPU fixed clock to avoid any
> potential execution freezes.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> ---
> drivers/clk/meson/Kconfig | 10 ++
> drivers/clk/meson/Makefile | 1 +
> drivers/clk/meson/a1-cpu.c | 324 +++++++++++++++++++++++++++++++++++++
> drivers/clk/meson/a1-cpu.h | 16 ++
> 4 files changed, 351 insertions(+)
> create mode 100644 drivers/clk/meson/a1-cpu.c
> create mode 100644 drivers/clk/meson/a1-cpu.h
>
> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
> index 80c4a18c83d2..148d4495eee3 100644
> --- a/drivers/clk/meson/Kconfig
> +++ b/drivers/clk/meson/Kconfig
> @@ -111,6 +111,16 @@ config COMMON_CLK_AXG_AUDIO
> Support for the audio clock controller on AmLogic A113D devices,
> aka axg, Say Y if you want audio subsystem to work.
>
> +config COMMON_CLK_A1_CPU
> + tristate "Amlogic A1 SoC CPU controller support"
> + depends on ARM64
> + select COMMON_CLK_MESON_REGMAP
> + select COMMON_CLK_MESON_CLKC_UTILS
> + help
> + Support for the CPU clock controller on Amlogic A113L based
> + device, A1 SoC Family. Say Y if you want A1 CPU clock controller
> + to work.
> +
> config COMMON_CLK_A1_PLL
> tristate "Amlogic A1 SoC PLL controller support"
> depends on ARM64
> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> index 4968fc7ad555..2a06eb0303d6 100644
> --- a/drivers/clk/meson/Makefile
> +++ b/drivers/clk/meson/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_AUDIO_RSTC) += meson-audio-rstc.o
>
> obj-$(CONFIG_COMMON_CLK_AXG) += axg.o axg-aoclk.o
> obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
> +obj-$(CONFIG_COMMON_CLK_A1_CPU) += a1-cpu.o
> obj-$(CONFIG_COMMON_CLK_A1_PLL) += a1-pll.o
> obj-$(CONFIG_COMMON_CLK_A1_PERIPHERALS) += a1-peripherals.o
> obj-$(CONFIG_COMMON_CLK_A1_AUDIO) += a1-audio.o
> diff --git a/drivers/clk/meson/a1-cpu.c b/drivers/clk/meson/a1-cpu.c
> new file mode 100644
> index 000000000000..5f5d8ae112e5
> --- /dev/null
> +++ b/drivers/clk/meson/a1-cpu.c
> @@ -0,0 +1,324 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Amlogic A1 SoC family CPU Clock Controller driver.
> + *
> + * Copyright (c) 2024, SaluteDevices. All Rights Reserved.
> + * Author: Dmitry Rokosov <ddrokosov@salutedevices.com>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/platform_device.h>
> +#include "a1-cpu.h"
> +#include "clk-regmap.h"
> +#include "meson-clkc-utils.h"
> +
> +#include <dt-bindings/clock/amlogic,a1-cpu-clkc.h>
> +
> +static u32 cpu_fsource_sel_table[] = { 0, 1, 2 };
> +static const struct clk_parent_data cpu_fsource_sel_parents[] = {
> + { .fw_name = "xtal" },
> + { .fw_name = "fclk_div2" },
> + { .fw_name = "fclk_div3" },
> +};
> +
> +static struct clk_regmap cpu_fsource_sel0 = {
> + .data = &(struct clk_regmap_mux_data) {
> + .offset = CPUCTRL_CLK_CTRL0,
> + .mask = 0x3,
> + .shift = 0,
> + .table = cpu_fsource_sel_table,
> + },
> + .hw.init = &(struct clk_init_data) {
> + .name = "cpu_fsource_sel0",
> + .ops = &clk_regmap_mux_ops,
> + .parent_data = cpu_fsource_sel_parents,
> + .num_parents = ARRAY_SIZE(cpu_fsource_sel_parents),
> + .flags = CLK_SET_RATE_PARENT,
> + },
> +};
> +
> +static struct clk_regmap cpu_fsource_div0 = {
> + .data = &(struct clk_regmap_div_data) {
> + .offset = CPUCTRL_CLK_CTRL0,
> + .shift = 4,
> + .width = 6,
> + },
> + .hw.init = &(struct clk_init_data) {
> + .name = "cpu_fsource_div0",
> + .ops = &clk_regmap_divider_ops,
> + .parent_hws = (const struct clk_hw *[]) {
> + &cpu_fsource_sel0.hw
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + },
> +};
> +
> +static struct clk_regmap cpu_fsel0 = {
> + .data = &(struct clk_regmap_mux_data) {
> + .offset = CPUCTRL_CLK_CTRL0,
> + .mask = 0x1,
> + .shift = 2,
> + },
> + .hw.init = &(struct clk_init_data) {
> + .name = "cpu_fsel0",
> + .ops = &clk_regmap_mux_ops,
> + .parent_hws = (const struct clk_hw *[]) {
> + &cpu_fsource_sel0.hw,
> + &cpu_fsource_div0.hw,
> + },
> + .num_parents = 2,
> + .flags = CLK_SET_RATE_PARENT,
> + },
> +};
> +
> +static struct clk_regmap cpu_fsource_sel1 = {
> + .data = &(struct clk_regmap_mux_data) {
> + .offset = CPUCTRL_CLK_CTRL0,
> + .mask = 0x3,
> + .shift = 16,
> + .table = cpu_fsource_sel_table,
> + },
> + .hw.init = &(struct clk_init_data) {
> + .name = "cpu_fsource_sel1",
> + .ops = &clk_regmap_mux_ops,
> + .parent_data = cpu_fsource_sel_parents,
> + .num_parents = ARRAY_SIZE(cpu_fsource_sel_parents),
> + .flags = CLK_SET_RATE_PARENT,
> + },
> +};
> +
> +static struct clk_regmap cpu_fsource_div1 = {
> + .data = &(struct clk_regmap_div_data) {
> + .offset = CPUCTRL_CLK_CTRL0,
> + .shift = 20,
> + .width = 6,
> + },
> + .hw.init = &(struct clk_init_data) {
> + .name = "cpu_fsource_div1",
> + .ops = &clk_regmap_divider_ops,
> + .parent_hws = (const struct clk_hw *[]) {
> + &cpu_fsource_sel1.hw
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + },
> +};
> +
> +static struct clk_regmap cpu_fsel1 = {
> + .data = &(struct clk_regmap_mux_data) {
> + .offset = CPUCTRL_CLK_CTRL0,
> + .mask = 0x1,
> + .shift = 18,
> + },
> + .hw.init = &(struct clk_init_data) {
> + .name = "cpu_fsel1",
> + .ops = &clk_regmap_mux_ops,
> + .parent_hws = (const struct clk_hw *[]) {
> + &cpu_fsource_sel1.hw,
> + &cpu_fsource_div1.hw,
> + },
> + .num_parents = 2,
> + .flags = CLK_SET_RATE_PARENT,
> + },
> +};
> +
> +static struct clk_regmap cpu_fclk = {
> + .data = &(struct clk_regmap_mux_data) {
> + .offset = CPUCTRL_CLK_CTRL0,
> + .mask = 0x1,
> + .shift = 10,
> + },
> + .hw.init = &(struct clk_init_data) {
> + .name = "cpu_fclk",
> + .ops = &clk_regmap_mux_ops,
> + .parent_hws = (const struct clk_hw *[]) {
> + &cpu_fsel0.hw,
> + &cpu_fsel1.hw,
> + },
> + .num_parents = 2,
> + .flags = CLK_SET_RATE_PARENT,
> + },
> +};
> +
> +static struct clk_regmap cpu_clk = {
> + .data = &(struct clk_regmap_mux_data) {
> + .offset = CPUCTRL_CLK_CTRL0,
> + .mask = 0x1,
> + .shift = 11,
> + },
> + .hw.init = &(struct clk_init_data) {
> + .name = "cpu_clk",
> + .ops = &clk_regmap_mux_ops,
> + .parent_data = (const struct clk_parent_data []) {
> + { .hw = &cpu_fclk.hw },
> + { .fw_name = "sys_pll", },
> + },
> + .num_parents = 2,
> + .flags = CLK_SET_RATE_PARENT | CLK_IS_CRITICAL,
> + },
> +};
> +
> +/* Array of all clocks registered by this provider */
> +static struct clk_hw *a1_cpu_hw_clks[] = {
> + [CLKID_CPU_FSOURCE_SEL0] = &cpu_fsource_sel0.hw,
> + [CLKID_CPU_FSOURCE_DIV0] = &cpu_fsource_div0.hw,
> + [CLKID_CPU_FSEL0] = &cpu_fsel0.hw,
> + [CLKID_CPU_FSOURCE_SEL1] = &cpu_fsource_sel1.hw,
> + [CLKID_CPU_FSOURCE_DIV1] = &cpu_fsource_div1.hw,
> + [CLKID_CPU_FSEL1] = &cpu_fsel1.hw,
> + [CLKID_CPU_FCLK] = &cpu_fclk.hw,
> + [CLKID_CPU_CLK] = &cpu_clk.hw,
> +};
> +
> +static struct clk_regmap *const a1_cpu_regmaps[] = {
> + &cpu_fsource_sel0,
> + &cpu_fsource_div0,
> + &cpu_fsel0,
> + &cpu_fsource_sel1,
> + &cpu_fsource_div1,
> + &cpu_fsel1,
> + &cpu_fclk,
> + &cpu_clk,
> +};
> +
> +static struct regmap_config a1_cpu_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = CPUCTRL_CLK_CTRL1,
> +};
> +
> +static struct meson_clk_hw_data a1_cpu_clks = {
> + .hws = a1_cpu_hw_clks,
> + .num = ARRAY_SIZE(a1_cpu_hw_clks),
> +};
> +
> +struct a1_cpu_clk_nb_data {
> + const struct clk_ops *mux_ops;
That's fishy ...
> + struct clk_hw *cpu_clk;
> + struct notifier_block nb;
> + u8 parent;
> +};
> +
> +#define MESON_A1_CPU_CLK_GET_PARENT(nbd) \
> + ((nbd)->mux_ops->get_parent((nbd)->cpu_clk))
> +#define MESON_A1_CPU_CLK_SET_PARENT(nbd, index) \
> + ((nbd)->mux_ops->set_parent((nbd)->cpu_clk, index))
... Directly going for the mux ops ??!?? No way !
We have a framework to handle the clocks, the whole point is to use it,
not bypass it !
> +
> +static int meson_a1_cpu_clk_notifier_cb(struct notifier_block *nb,
> + unsigned long event, void *data)
> +{
> + struct a1_cpu_clk_nb_data *nbd;
> + int ret = 0;
> +
> + nbd = container_of(nb, struct a1_cpu_clk_nb_data, nb);
> +
> + switch (event) {
> + case PRE_RATE_CHANGE:
> + nbd->parent = MESON_A1_CPU_CLK_GET_PARENT(nbd);
> + /* Fallback to the CPU fixed clock */
> + ret = MESON_A1_CPU_CLK_SET_PARENT(nbd, 0);
> + /* Wait for clock propagation */
> + udelay(100);
> + break;
> +
> + case POST_RATE_CHANGE:
> + case ABORT_RATE_CHANGE:
> + /* Back to the original parent clock */
> + ret = MESON_A1_CPU_CLK_SET_PARENT(nbd, nbd->parent);
> + /* Wait for clock propagation */
> + udelay(100);
> + break;
> +
> + default:
> + pr_warn("Unknown event %lu for %s notifier block\n",
> + event, clk_hw_get_name(nbd->cpu_clk));
> + break;
> + }
> +
> + return notifier_from_errno(ret);
> +}
> +
> +static struct a1_cpu_clk_nb_data a1_cpu_clk_nb_data = {
> + .mux_ops = &clk_regmap_mux_ops,
> + .cpu_clk = &cpu_clk.hw,
> + .nb.notifier_call = meson_a1_cpu_clk_notifier_cb,
> +};
> +
> +static int meson_a1_dvfs_setup(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct clk *notifier_clk;
> + int ret;
> +
> + /* Setup clock notifier for cpu_clk */
> + notifier_clk = devm_clk_hw_get_clk(dev, &cpu_clk.hw, "dvfs");
> + if (IS_ERR(notifier_clk))
> + return dev_err_probe(dev, PTR_ERR(notifier_clk),
> + "can't get cpu_clk as notifier clock\n");
> +
> + ret = devm_clk_notifier_register(dev, notifier_clk,
> + &a1_cpu_clk_nb_data.nb);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "can't register cpu_clk notifier\n");
> +
> + return ret;
> +}
> +
> +static int meson_a1_cpu_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + void __iomem *base;
> + struct regmap *map;
> + int clkid, i, err;
> +
> + base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(base))
> + return dev_err_probe(dev, PTR_ERR(base),
> + "can't ioremap resource\n");
> +
> + map = devm_regmap_init_mmio(dev, base, &a1_cpu_regmap_cfg);
> + if (IS_ERR(map))
> + return dev_err_probe(dev, PTR_ERR(map),
> + "can't init regmap mmio region\n");
> +
> + /* Populate regmap for the regmap backed clocks */
> + for (i = 0; i < ARRAY_SIZE(a1_cpu_regmaps); i++)
> + a1_cpu_regmaps[i]->map = map;
> +
> + for (clkid = 0; clkid < a1_cpu_clks.num; clkid++) {
> + err = devm_clk_hw_register(dev, a1_cpu_clks.hws[clkid]);
> + if (err)
> + return dev_err_probe(dev, err,
> + "clock[%d] registration failed\n",
> + clkid);
> + }
> +
> + err = devm_of_clk_add_hw_provider(dev, meson_clk_hw_get, &a1_cpu_clks);
> + if (err)
> + return dev_err_probe(dev, err, "can't add clk hw provider\n");
I wonder if there is a window of opportunity to poke the syspll without
your notifier here. That being said, the situation would be similar on g12.
> +
> + return meson_a1_dvfs_setup(pdev);
> +}
> +
> +static const struct of_device_id a1_cpu_clkc_match_table[] = {
> + { .compatible = "amlogic,a1-cpu-clkc", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, a1_cpu_clkc_match_table);
> +
> +static struct platform_driver a1_cpu_clkc_driver = {
> + .probe = meson_a1_cpu_probe,
> + .driver = {
> + .name = "a1-cpu-clkc",
> + .of_match_table = a1_cpu_clkc_match_table,
> + },
> +};
> +
> +module_platform_driver(a1_cpu_clkc_driver);
> +MODULE_AUTHOR("Dmitry Rokosov <ddrokosov@salutedevices.com>");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/clk/meson/a1-cpu.h b/drivers/clk/meson/a1-cpu.h
> new file mode 100644
> index 000000000000..e9af4117e26f
> --- /dev/null
> +++ b/drivers/clk/meson/a1-cpu.h
There is not point putting the definition here in a header
These are clearly not going to be shared with another driver.
Please drop this file
> @@ -0,0 +1,16 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Amlogic A1 CPU Clock Controller internals
> + *
> + * Copyright (c) 2024, SaluteDevices. All Rights Reserved.
> + * Author: Dmitry Rokosov <ddrokosov@salutedevices.com>
> + */
> +
> +#ifndef __A1_CPU_H
> +#define __A1_CPU_H
> +
> +/* cpu clock controller register offset */
> +#define CPUCTRL_CLK_CTRL0 0x80
> +#define CPUCTRL_CLK_CTRL1 0x84
You are claiming the registers from 0x00 to 0x84 (included), but only
using these 2 registers ? What is the rest ? Are you sure there is only
clocks in there ?
> +
> +#endif /* __A1_CPU_H */
--
Jerome
_______________________________________________
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/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core
From: AngeloGioacchino Del Regno @ 2024-04-02 9:56 UTC (permalink / raw)
To: Mathieu Poirier
Cc: andersson, matthias.bgg, tzungbi, tinghan.shen, linux-remoteproc,
linux-kernel, linux-arm-kernel, linux-mediatek, wenst, kernel
In-Reply-To: <ZgWA/E46i/CaoM74@p14s>
Il 28/03/24 15:38, Mathieu Poirier ha scritto:
> On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
>> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
>>> On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
>>>> When probing multi-core SCP, this driver is parsing all sub-nodes of
>>>> the scp-cluster node, but one of those could be not an actual SCP core
>>>> and that would make the entire SCP cluster to fail probing for no good
>>>> reason.
>>>>
>>>> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
>>>> parsing only available subnodes having compatible "mediatek,scp-core".
>>>>
>>>> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>>> ---
>>>> drivers/remoteproc/mtk_scp.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
>>>> index 67518291a8ad..fbe1c232dae7 100644
>>>> --- a/drivers/remoteproc/mtk_scp.c
>>>> +++ b/drivers/remoteproc/mtk_scp.c
>>>> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
>>>> cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
>>>> for_each_available_child_of_node(np, child) {
>>>> + if (!of_device_is_compatible(child, "mediatek,scp-core"))
>>>> + continue;
>>>> +
>>>
>>> Interesting - what else gets stashed under the remote processor node? I don't
>>> see anything specified in the bindings.
>>>
>>
>> Sorry for the late reply - well, in this precise moment in time, upstream,
>> nothing yet.
>>
>> I have noticed this while debugging some lockups and wanted to move the scp_adsp
>> clock controller node as child of the SCP node (as some of those clocks are located
>> *into the SCP's CFG register space*, and it's correct for that to be a child as one
>> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
>> the unexpected behavior, as the SCP driver was treating those as an SCP core.
>>
>> There was no kernel panic, but the SCP would fail probing.
>>
>> This is anyway a missed requirement ... for platforms that want *both* two SCP
>> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
>> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
>> lines back.
>>
>> ...and that's why this commit was sent :-)
>>
>
> Please update the bindings with the extra clock requirement in your next
> revision.
>
Ok.
Can you please take only patch 1/2 of this series so that I can delay this one
for a bit? I don't have time to work on that exactly right now.
Thanks,
Angelo
_______________________________________________
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 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-04-02 9:57 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <ZgvKh/Cwudh3gCDr@shell.armlinux.org.uk>
On 02/04/2024 11:06, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 09:56:17AM +0100, Russell King (Oracle) wrote:
>> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>>
>>>> Description
>>>> ===========
>>>> Modules registering driver with amba_driver_register() often forget to
>>>> set .owner field.
>>>>
>>>> Solve the problem by moving this task away from the drivers to the core
>>>> amba bus code, just like we did for platform_driver in commit
>>>> 9447057eaff8 ("platform_device: use a macro instead of
>>>> platform_driver_register").
>>>>
>>>> Best regards,
>>>
>>> I tried to submit this series to Russell patch tracker and failed. This
>>> is ridiculous. It's 2024 and instead of normal process, like every other
>>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>>> standard patches.
>>
>> Sorry but no. Stop being offensive.
>>
>>> First, it depends some weird, duplicated signed-off-by's.
>>
>> Eh? There is no such logic in there.
>>
>>> Second it > submitting patch-by-patch, all with clicking on some web
>>> (!!!) interface.
>>
>> Again, no it doesn't, and you're just throwing crap out because you
>> failed. Unlike most of the "normal" processes, the patch system allows
>> you to submit both by *email* and also by *web* for those cases where
>> the emails get screwed up by ones company mail server. That's why the
>> web interface exists - to give people *flexibility*.
>>
>> The fact is, the web interface is merely a front end interface that
>> generates an email and submits it in the usual way by email - an
>> email that you can perfectly well generate that is *very* close to
>> the standard email that git format-patch generates.
>>
>> The *only* difference is that the patch system wants a KernelVersion:
>> tag in the email _somewhere_ and it doesn't matter where it appears.
>> Git even has support to do this.
>>
>> git format-patch --add-header="KernelVersion: $foo"
>>
>> Why does it want the kernel version? Because when we were running 2.4
>> and 2.5 kernel versions in parallel, it was important to know which
>> tree the patch was being submitted for. It has continued to be required
>> because it means when there's problems applying a patch, it gives me
>> the additional information about the base used for the patch (and it
>> keeps on being useful to have.)
>>
>>> That's the response:
>>> -------------
>>> Your patch has not been logged because:
>>>
>>> Error: Please supply a summary subject line briefly describing
>>> your patch.
>>>
>>>
>>> Error: Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
>>> "---".
>>>
>>> Error: the patch you are submitting has one or more missing or incorrect
>>> Signed-off-by lines:
>>>
>>> - author signoff <krzkreg@gmail.com> is missing.
>>>
>>> Please see the file Documentation/SubmittingPatches, section 11
>>> for details on signing off patches.
>>
>> Lots of people use it without a problem. I've just run the parser
>> through its offline tests, and it parses email content correctly.
>> I've no idea what you're doing wrong, but it looks like something
>> pretty serious if it didn't parse the subject line.
>>
>> Rather than getting stressed about it, why don't you send me an email
>> the first time something goes wrong so I can investigate, turn on
>> debugging to capture the problem email?
>
> ... and I'll also point out one of the biggest problems is people.
> People who think it's more complex than it is, or who can't read
> instructions.
We all read submitting-patches instructions (and many more). A need to
learn one more set of instructions for one more process leads to people
needing to learn 100 different processes for 100 different subsystems.
That's not the way how people should be contributing to Linux kernel.
>
> For example, trying to tell people to use the standard format subject
> line:
>
> [PATCH ...] blah
>
> has proven to be hopeless - unless one states to them the exact
> sequence of keys on their keyboard to press - yes, it *really* takes
> that patronising level to get everyone to understand. If one tries to
> do it any other way, then you get stuff like:
>
> "[PATCH ...] ..."
>
> with the quotes. Or some other stupid variation.
>
> The patch system is as forgiving as possible. It takes standard git
> formatted patches (with the exception of wanting an additional tag).
The additional tag about kernel version is redundant and not helping
anyone. I doubt you apply patches on top of linux-next or top of
previous release (e.g. v6.8-rc1). Almost every maintainer applies on top
of current RC, so v6.9-rc1 currently, thus version is just unnecessary
obstacle.
>
> It is possible that bugs creep in - particularly when Debian updates
> get applied and change the way Perl works, but I don't think that's
> what has happened with your situation.
>
> I _guess_ you're putting the entire email-like output from git
> format-patch as the patch file. That won't work - that isn't a "patch
> file", that is an email/email template, and the patch system will
> attempt to parse that as the patch itself.
Yes, that's what every sane person's workflow is. git format-patch -19
(cover letter goes from branch description).
>
> I suppose you term "patch" to be the email as well, rather than what
> I interpret it to be, which is only the output of "diff" - call me
> old fashioned but that's what a patch file used to be before the
> waters got muddied by git "patch files".
Well, world is now using git as a standard. It's true there is quilt out
there, but even Andrew I think is going slowly towards git in some parts
of his workflow.
But then even Andrew accepted standard patch from the mailing lists. No
need for any other step, no need for any double submission (one public,
second to patches@armlinux or webform) with any other requirement.
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 00/19] amba: store owner from modules with amba_driver_register()
From: Russell King (Oracle) @ 2024-04-02 9:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <324e9c02-c005-4e18-9872-8408695fb1fe@linaro.org>
On Tue, Apr 02, 2024 at 11:48:08AM +0200, Krzysztof Kozlowski wrote:
> On 02/04/2024 10:56, Russell King (Oracle) wrote:
> > On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
> >> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> >>> Merging
> >>> =======
> >>> All further patches depend on the first amba patch, therefore please ack
> >>> and this should go via one tree.
> >>>
> >>> Description
> >>> ===========
> >>> Modules registering driver with amba_driver_register() often forget to
> >>> set .owner field.
> >>>
> >>> Solve the problem by moving this task away from the drivers to the core
> >>> amba bus code, just like we did for platform_driver in commit
> >>> 9447057eaff8 ("platform_device: use a macro instead of
> >>> platform_driver_register").
> >>>
> >>> Best regards,
> >>
> >> I tried to submit this series to Russell patch tracker and failed. This
> >> is ridiculous. It's 2024 and instead of normal process, like every other
> >> maintainer, so b4 or Patchwork, we have some unusable system rejecting
> >> standard patches.
> >
> > Sorry but no. Stop being offensive.
> >
> >> First, it depends some weird, duplicated signed-off-by's.
> >
> > Eh? There is no such logic in there.
>
> In the web system there is - read the error message I pasted. It wants
> another SoB from the unrelated email account, the one used purely for
> registering in some web system, not the one used for code handling.
So you're disagreeing with the author of this system. Of course you
know best, you know the code behind it. I have only one word for
that kind of attitude: idiotic.
> >> Second it > submitting patch-by-patch, all with clicking on some web
> >> (!!!) interface.
> >
> > Again, no it doesn't, and you're just throwing crap out because you
> > failed. Unlike most of the "normal" processes, the patch system allows
> > you to submit both by *email* and also by *web* for those cases where
>
> The email one requires additional steps, so this is unnecessary work
> confusing submitters. I submit dozens or hundreds of patches every
> release cycle. That's the only subsystem which is odd to use.
Lots of people use it without issue. People even send patches to the
mailing list copied to the patch system.
> > the emails get screwed up by ones company mail server. That's why the
> > web interface exists - to give people *flexibility*.
>
> No, they are not. None of my emails are screwed by my company system.
So why are you using the web interface?
> > Why does it want the kernel version? Because when we were running 2.4
> > and 2.5 kernel versions in parallel, it was important to know which
> > tree the patch was being submitted for. It has continued to be required
>
> Which is absolutely ridiculous now. Expecting submitters to adhere to
> some rule for 20 year old kernel is not reasonable.
You aren't listening to me, so it's pointless discussing this further.
You have a bee in your bonet and you want to make it a huge issue
rather than work constructively. Sorry but no, I'm not going to continue
this confrontational exchange.
You clearly don't want to understand anything.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
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] arm64: remove redundant 'extern'
From: Mark Rutland @ 2024-04-02 10:01 UTC (permalink / raw)
To: Steven Price; +Cc: Catalin Marinas, Will Deacon, linux-arm-kernel, linux-kernel
In-Reply-To: <20240327112439.200455-1-steven.price@arm.com>
On Wed, Mar 27, 2024 at 11:24:39AM +0000, Steven Price wrote:
> It isn't necessary to mark function definitions extern and goes against
> the kernel coding style. Remove the redundant extern keyword.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
We (unfortunately) have extern misused in a number of places:
| [mark@lakrids:~/src/linux]% git grep 'extern.*(' -- arch/arm64/include | cut -d: -f 1 | uniq -c
| 11 arch/arm64/include/asm/cacheflush.h
| 1 arch/arm64/include/asm/checksum.h
| 1 arch/arm64/include/asm/cpu_ops.h
| 4 arch/arm64/include/asm/cpufeature.h
| 2 arch/arm64/include/asm/efi.h
| 2 arch/arm64/include/asm/elf.h
| 1 arch/arm64/include/asm/exec.h
| 1 arch/arm64/include/asm/fixmap.h
| 48 arch/arm64/include/asm/fpsimd.h
| 3 arch/arm64/include/asm/ftrace.h
| 10 arch/arm64/include/asm/hugetlb.h
| 11 arch/arm64/include/asm/hw_breakpoint.h
| 6 arch/arm64/include/asm/io.h
| 4 arch/arm64/include/asm/kexec.h
| 1 arch/arm64/include/asm/kgdb.h
| 16 arch/arm64/include/asm/kvm_asm.h
| 3 arch/arm64/include/asm/kvm_host.h
| 11 arch/arm64/include/asm/kvm_hyp.h
| 2 arch/arm64/include/asm/kvm_pkvm.h
| 2 arch/arm64/include/asm/memory.h
| 8 arch/arm64/include/asm/mmu.h
| 2 arch/arm64/include/asm/page.h
| 1 arch/arm64/include/asm/percpu.h
| 2 arch/arm64/include/asm/perf_event.h
| 2 arch/arm64/include/asm/pgalloc.h
| 18 arch/arm64/include/asm/pgtable.h
| 3 arch/arm64/include/asm/pointer_auth.h
| 3 arch/arm64/include/asm/proc-fns.h
| 2 arch/arm64/include/asm/processor.h
| 3 arch/arm64/include/asm/ptrace.h
| 12 arch/arm64/include/asm/smp.h
| 1 arch/arm64/include/asm/stacktrace.h
| 14 arch/arm64/include/asm/string.h
| 2 arch/arm64/include/asm/suspend.h
| 1 arch/arm64/include/asm/system_misc.h
| 6 arch/arm64/include/asm/uaccess.h
... so it'd probably be best to make the commit title more specific to this
instance, and maybe go clean those up in bulk as a series to avoid a steady
stream of copycat patches.
Mark.
> ---
> arch/arm64/include/asm/fixmap.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
> index 87e307804b99..75b22b89db1a 100644
> --- a/arch/arm64/include/asm/fixmap.h
> +++ b/arch/arm64/include/asm/fixmap.h
> @@ -107,7 +107,7 @@ void __init early_fixmap_init(void);
> #define __late_set_fixmap __set_fixmap
> #define __late_clear_fixmap(idx) __set_fixmap((idx), 0, FIXMAP_PAGE_CLEAR)
>
> -extern void __set_fixmap(enum fixed_addresses idx, phys_addr_t phys, pgprot_t prot);
> +void __set_fixmap(enum fixed_addresses idx, phys_addr_t phys, pgprot_t prot);
>
> #include <asm-generic/fixmap.h>
>
> --
> 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
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-04-02 10:04 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <ZgvWfhSEYIUaIn6h@shell.armlinux.org.uk>
On 02/04/2024 11:57, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 11:48:08AM +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 10:56, Russell King (Oracle) wrote:
>>> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>>>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>>>> Merging
>>>>> =======
>>>>> All further patches depend on the first amba patch, therefore please ack
>>>>> and this should go via one tree.
>>>>>
>>>>> Description
>>>>> ===========
>>>>> Modules registering driver with amba_driver_register() often forget to
>>>>> set .owner field.
>>>>>
>>>>> Solve the problem by moving this task away from the drivers to the core
>>>>> amba bus code, just like we did for platform_driver in commit
>>>>> 9447057eaff8 ("platform_device: use a macro instead of
>>>>> platform_driver_register").
>>>>>
>>>>> Best regards,
>>>>
>>>> I tried to submit this series to Russell patch tracker and failed. This
>>>> is ridiculous. It's 2024 and instead of normal process, like every other
>>>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>>>> standard patches.
>>>
>>> Sorry but no. Stop being offensive.
>>>
>>>> First, it depends some weird, duplicated signed-off-by's.
>>>
>>> Eh? There is no such logic in there.
>>
>> In the web system there is - read the error message I pasted. It wants
>> another SoB from the unrelated email account, the one used purely for
>> registering in some web system, not the one used for code handling.
>
> So you're disagreeing with the author of this system. Of course you
> know best, you know the code behind it. I have only one word for
> that kind of attitude: idiotic.
I pasted you the error which the system reported to me.
>
>>>> Second it > submitting patch-by-patch, all with clicking on some web
>>>> (!!!) interface.
>>>
>>> Again, no it doesn't, and you're just throwing crap out because you
>>> failed. Unlike most of the "normal" processes, the patch system allows
>>> you to submit both by *email* and also by *web* for those cases where
>>
>> The email one requires additional steps, so this is unnecessary work
>> confusing submitters. I submit dozens or hundreds of patches every
>> release cycle. That's the only subsystem which is odd to use.
>
> Lots of people use it without issue. People even send patches to the
> mailing list copied to the patch system.
>
I will try that.
>>> the emails get screwed up by ones company mail server. That's why the
>>> web interface exists - to give people *flexibility*.
>>
>> No, they are not. None of my emails are screwed by my company system.
>
> So why are you using the web interface?
>
>>> Why does it want the kernel version? Because when we were running 2.4
>>> and 2.5 kernel versions in parallel, it was important to know which
>>> tree the patch was being submitted for. It has continued to be required
>>
>> Which is absolutely ridiculous now. Expecting submitters to adhere to
>> some rule for 20 year old kernel is not reasonable.
>
> You aren't listening to me, so it's pointless discussing this further.
> You have a bee in your bonet and you want to make it a huge issue
Well, all my comments were about the actual topic - patch submission
process made for ARM subsystem by you. Your replies include comments
about me and what do I have in my bonet.
You brought no argument for keeping the kernel-version-header
requirement nowadays, yet you call me of not working constructively. I
brought that argument - it is redundant and it is an obstacle for the
contributor.
> rather than work constructively. Sorry but no, I'm not going to continue
> this confrontational exchange.
>
> You clearly don't want to understand anything.
I understood a lot, although I did not answer under every point "I
understand this part, I disagree here".
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 00/11] drm/mediatek: drop driver owner initialization
From: AngeloGioacchino Del Regno @ 2024-04-02 10:06 UTC (permalink / raw)
To: Krzysztof Kozlowski, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Daniel Vetter, Matthias Brugger
Cc: dri-devel, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20240330-b4-module-owner-drm-mediatek-v1-0-fd5c4b8d633e@linaro.org>
Il 30/03/24 21:43, Krzysztof Kozlowski ha scritto:
> Simplify the code by dropping unnecessary .owner initialization in the
> driver.
>
For the entire series:
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Best regards,
> Krzysztof
>
> ---
> Krzysztof Kozlowski (11):
> drm/mediatek: aal: drop driver owner initialization
> drm/mediatek: ccorr: drop driver owner initialization
> drm/mediatek: color: drop driver owner initialization
> drm/mediatek: gamma: drop driver owner initialization
> drm/mediatek: merge: drop driver owner initialization
> drm/mediatek: ovl: drop driver owner initialization
> drm/mediatek: ovl_adaptor: drop driver owner initialization
> drm/mediatek: rdma: drop driver owner initialization
> drm/mediatek: ethdr: drop driver owner initialization
> drm/mediatek: mdp_rdma: drop driver owner initialization
> drm/mediatek: padding: drop driver owner initialization
>
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 1 -
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 1 -
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 1 -
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 1 -
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 1 -
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 -
> drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 1 -
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 1 -
> drivers/gpu/drm/mediatek/mtk_ethdr.c | 1 -
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 1 -
> drivers/gpu/drm/mediatek/mtk_padding.c | 1 -
> 11 files changed, 11 deletions(-)
> ---
> base-commit: 7fdcff3312e16ba8d1419f8a18f465c5cc235ecf
> change-id: 20240330-b4-module-owner-drm-mediatek-aa525b70f033
>
> Best regards,
_______________________________________________
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 v5 09/11] regulator: tps6594-regulator: Add TI TPS65224 PMIC regulators
From: Dan Carpenter @ 2024-04-02 10:06 UTC (permalink / raw)
To: Bhargav Raviprakash
Cc: linux-kernel, m.nirmaladevi, lee, robh+dt, krzysztof.kozlowski+dt,
conor+dt, jpanis, devicetree, arnd, gregkh, lgirdwood, broonie,
linus.walleij, linux-gpio, linux-arm-kernel, nm, vigneshr, kristo,
eblanc
In-Reply-To: <20240328124016.161959-10-bhargav.r@ltts.com>
On Thu, Mar 28, 2024 at 06:10:14PM +0530, Bhargav Raviprakash wrote:
> static irqreturn_t tps6594_regulator_irq_handler(int irq, void *data)
> {
> struct tps6594_regulator_irq_data *irq_data = data;
> @@ -369,17 +513,23 @@ static irqreturn_t tps6594_regulator_irq_handler(int irq, void *data)
> static int tps6594_request_reg_irqs(struct platform_device *pdev,
^^^^^^^
This function is not beautiful. I think since you're changing it from
being tps6594 specific, maybe you want to rename a bunch of stuff.
> struct regulator_dev *rdev,
> struct tps6594_regulator_irq_data *irq_data,
> - struct tps6594_regulator_irq_type *tps6594_regs_irq_types,
> + struct tps6594_regulator_irq_type *regs_irq_types,
> int *irq_idx)
> {
> struct tps6594_regulator_irq_type *irq_type;
> struct tps6594 *tps = dev_get_drvdata(pdev->dev.parent);
> - int j;
> + size_t j;
> int irq;
> int error;
> + size_t interrupt_cnt;
> +
> + if (tps->chip_id == TPS6594)
> + interrupt_cnt = ARRAY_SIZE(tps6594_buck1_irq_types);
> + else
> + interrupt_cnt = ARRAY_SIZE(tps65224_buck1_irq_types);
Either 1) pass both the array and the size or 2) just use tps->chip_id
to determine both the array and the arrays_size. Passing the array and
then determining which array was passed by looking at the type is ugly.
regards,
dan carpenter
>
> - for (j = 0; j < REGS_INT_NB; j++) {
> - irq_type = &tps6594_regs_irq_types[j];
> + for (j = 0; j < interrupt_cnt; j++) {
> + irq_type = ®s_irq_types[j];
> irq = platform_get_irq_byname(pdev, irq_type->irq_name);
> if (irq < 0)
> return -EINVAL;
_______________________________________________
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] drm/mediatek: Init `ddp_comp` with devm_kcalloc()
From: AngeloGioacchino Del Regno @ 2024-04-02 10:10 UTC (permalink / raw)
To: Douglas Anderson, Chun-Kuang Hu, Philipp Zabel
Cc: CK Hu, Daniel Vetter, David Airlie, Jason-JH.Lin,
Matthias Brugger, Nathan Lu, dri-devel, linux-arm-kernel,
linux-kernel, linux-mediatek
In-Reply-To: <20240328092248.1.I2e73c38c0f264ee2fa4a09cdd83994e37ba9f541@changeid>
Il 28/03/24 17:22, Douglas Anderson ha scritto:
> In the case where `conn_routes` is true we allocate an extra slot in
> the `ddp_comp` array but mtk_drm_crtc_create() never seemed to
> initialize it in the test case I ran. For me, this caused a later
> crash when we looped through the array in mtk_drm_crtc_mode_valid().
> This showed up for me when I booted with `slub_debug=FZPUA` which
> poisons the memory initially. Without `slub_debug` I couldn't
> reproduce, presumably because the later code handles the value being
> NULL and in most cases (not guaranteed in all cases) the memory the
> allocator returned started out as 0.
>
> It really doesn't hurt to initialize the array with devm_kcalloc()
> since the array is small and the overhead of initting a handful of
> elements to 0 is small. In general initting memory to zero is a safer
> practice and usually it's suggested to only use the non-initting alloc
> functions if you really need to.
>
> Let's switch the function to use an allocation function that zeros the
> memory. For me, this avoids the crash.
>
> Fixes: 01389b324c97 ("drm/mediatek: Add connector dynamic selection capability")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
P.S.: I really dislike the dynamic selection stuff, as that's only a partial
solution for something that should've been in DT from day 1 instead.
P.P.S.: I took care of that already - a series is about to come in a few days.
Cheers,
Angelo
_______________________________________________
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/2] pinctrl: mediatek: paris: Fix PIN_CONFIG_INPUT_SCHMITT_ENABLE readback
From: Dan Carpenter @ 2024-04-02 10:10 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, linux-mediatek, linux-arm-kernel,
linux-gpio, linux-kernel
In-Reply-To: <20240327091336.3434141-2-wenst@chromium.org>
On Wed, Mar 27, 2024 at 05:13:33PM +0800, Chen-Yu Tsai wrote:
> In the generic pin config library, readback of some options are handled
> differently compared to the setting of those options: the argument value
> is used to convey enable/disable of an option in the set path, but
> success or -EINVAL is used to convey if an option is enabled or disabled
> in the debugfs readback path.
>
> PIN_CONFIG_INPUT_SCHMITT_ENABLE is one such option. Fix the readback of
> the option in the mediatek-paris library, so that the debugfs dump is
> not showing "input schmitt enabled" for pins that don't have it enabled.
>
> Fixes: 1bea6afbc842 ("pinctrl: mediatek: Refine mtk_pinconf_get()")
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> drivers/pinctrl/mediatek/pinctrl-paris.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
> index b6bc31abd2b0..9353f78a52f0 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
> @@ -193,6 +193,8 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
> }
>
> err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_SMT, &ret);
> + if (!ret)
> + err = -EINVAL;
In this function "ret" contains a mix of different data depending on
what the param is. It's not always clear what "ret" means from one
line to the next. I think it would be more clear to say
if (ret == MTK_DISABLE) in this case...
(I'm sorry to the list for sending so many nit picks today).
regards,
dan carpenter
_______________________________________________
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 00/19] amba: store owner from modules with amba_driver_register()
From: Russell King (Oracle) @ 2024-04-02 10:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <65f0ed39-4c2f-4cea-b488-2a8ba6fdbeff@linaro.org>
On Tue, Apr 02, 2024 at 12:04:07PM +0200, Krzysztof Kozlowski wrote:
> You brought no argument for keeping the kernel-version-header
> requirement nowadays, yet you call me of not working constructively. I
So add inability to read to your failings, because I _did_ state that
_I_ still _use_ it.
End of discussion, I'm not engaging with you in your current
confrontational mood where you clearly don't want to understand
anything (or intentionally misinterpreting) I'm writing - making it
pointless to continue.
I even think you're intentionally misinterpreting the responses
from the patch system.
Overall, I can only draw the conclusion that you are playing politics
and want the patch system gone, and you want me to use "standard"
tooling that will _increase_ the amount of effort I need to put in.
No, that's not going to happen.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
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 00/19] amba: store owner from modules with amba_driver_register()
From: Russell King (Oracle) @ 2024-04-02 10:15 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Linus Walleij, Andi Shyti,
Olivia Mackall, Herbert Xu, Vinod Koul, Dmitry Torokhov,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <ZgvaFNLTqgQrPeiO@shell.armlinux.org.uk>
On Tue, Apr 02, 2024 at 11:12:36AM +0100, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 12:04:07PM +0200, Krzysztof Kozlowski wrote:
> > You brought no argument for keeping the kernel-version-header
> > requirement nowadays, yet you call me of not working constructively. I
>
> So add inability to read to your failings, because I _did_ state that
> _I_ still _use_ it.
>
> End of discussion, I'm not engaging with you in your current
> confrontational mood where you clearly don't want to understand
> anything (or intentionally misinterpreting) I'm writing - making it
> pointless to continue.
>
> I even think you're intentionally misinterpreting the responses
> from the patch system.
>
> Overall, I can only draw the conclusion that you are playing politics
> and want the patch system gone, and you want me to use "standard"
> tooling that will _increase_ the amount of effort I need to put in.
> No, that's not going to happen.
... and this is your final chance to change to a constructive discourse,
if not, you are going to end up in my kill file. Whether you do is
entirely up to the tone of your reply to this email.
I am always more than willing to work with a submitter to diagnose
what the problem is, but the tone of your emails make me want to
ignore you.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
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