* [RFC 1/8] arm64/sysreg: Add register fields for MDSELR_EL1
From: Anshuman Khandual @ 2024-04-05 8:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Anshuman Khandual, Jonathan Corbet, Marc Zyngier, Oliver Upton,
James Morse, Suzuki K Poulose, Catalin Marinas, Will Deacon,
Mark Brown, Mark Rutland, kvmarm, linux-kernel
In-Reply-To: <20240405080008.1225223-1-anshuman.khandual@arm.com>
This adds register fields for MDSELR_EL1 as per the definitions based
on DDI0601 2023-12.
Cc: Will Deacon <will@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
arch/arm64/tools/sysreg | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index a4c1dd4741a4..4c58fd7a70e6 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -93,6 +93,17 @@ Res0 63:32
Field 31:0 DTRTX
EndSysreg
+Sysreg MDSELR_EL1 2 0 0 4 2
+Res0 63:6
+Enum 5:4 BANK
+ 0b00 BANK_0
+ 0b01 BANK_1
+ 0b10 BANK_2
+ 0b11 BANK_3
+EndEnum
+Res0 3:0
+EndSysreg
+
Sysreg OSECCR_EL1 2 0 0 6 2
Res0 63:32
Field 31:0 EDECCR
--
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 related
* [PATCH bpf-next] arm64, bpf: add internal-only MOV instruction to resolve per-CPU addrs
From: Puranjay Mohan @ 2024-04-05 9:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Zi Shen Lim, Xu Kuohai, Florent Revest,
linux-arm-kernel, linux-kernel, bpf
Cc: puranjay12
Support an instruction for resolving absolute addresses of per-CPU
data from their per-CPU offsets. This instruction is internal-only and
users are not allowed to use them directly. They will only be used for
internal inlining optimizations for now between BPF verifier and BPF
JITs.
Since commit 7158627686f0 ("arm64: percpu: implement optimised pcpu
access using tpidr_el1"), the per-cpu offset for the CPU is stored in
the tpidr_el1/2 register of that CPU.
To support this BPF instruction in the ARM64 JIT, the following ARM64
instructions are emitted:
mov dst, src // Move src to dst, if src != dst
mrs tmp, tpidr_el1/2 // Move per-cpu offset of the current cpu in tmp.
add dst, dst, tmp // Add the per cpu offset to the dst.
If CONFIG_SMP is not defined, then nothing is emitted if src == dst, and
mov dst, src is emitted if dst != src.
To measure the performance improvement provided by this change, the
benchmark in [1] was used:
Before:
glob-arr-inc : 23.597 ± 0.012M/s
arr-inc : 23.173 ± 0.019M/s
hash-inc : 12.186 ± 0.028M/s
After:
glob-arr-inc : 23.819 ± 0.034M/s
arr-inc : 23.285 ± 0.017M/s
hash-inc : 12.419 ± 0.011M/s
[1] https://github.com/anakryiko/linux/commit/8dec900975ef
Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
---
arch/arm64/include/asm/insn.h | 7 +++++++
arch/arm64/lib/insn.c | 11 +++++++++++
arch/arm64/net/bpf_jit.h | 6 ++++++
arch/arm64/net/bpf_jit_comp.c | 16 ++++++++++++++++
4 files changed, 40 insertions(+)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index db1aeacd4cd9..d16d68550c22 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -135,6 +135,11 @@ enum aarch64_insn_special_register {
AARCH64_INSN_SPCLREG_SP_EL2 = 0xF210
};
+enum aarch64_insn_system_register {
+ AARCH64_INSN_SYSREG_TPIDR_EL1 = 0xC684,
+ AARCH64_INSN_SYSREG_TPIDR_EL2 = 0xE682,
+};
+
enum aarch64_insn_variant {
AARCH64_INSN_VARIANT_32BIT,
AARCH64_INSN_VARIANT_64BIT
@@ -686,6 +691,8 @@ u32 aarch64_insn_gen_cas(enum aarch64_insn_register result,
}
#endif
u32 aarch64_insn_gen_dmb(enum aarch64_insn_mb_type type);
+u32 aarch64_insn_gen_mrs(enum aarch64_insn_register result,
+ enum aarch64_insn_system_register sysreg);
s32 aarch64_get_branch_offset(u32 insn);
u32 aarch64_set_branch_offset(u32 insn, s32 offset);
diff --git a/arch/arm64/lib/insn.c b/arch/arm64/lib/insn.c
index a635ab83fee3..b008a9b46a7f 100644
--- a/arch/arm64/lib/insn.c
+++ b/arch/arm64/lib/insn.c
@@ -1515,3 +1515,14 @@ u32 aarch64_insn_gen_dmb(enum aarch64_insn_mb_type type)
return insn;
}
+
+u32 aarch64_insn_gen_mrs(enum aarch64_insn_register result,
+ enum aarch64_insn_system_register sysreg)
+{
+ u32 insn = aarch64_insn_get_mrs_value();
+
+ insn &= ~GENMASK(19, 0);
+ insn |= sysreg << 5;
+ return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT,
+ insn, result);
+}
diff --git a/arch/arm64/net/bpf_jit.h b/arch/arm64/net/bpf_jit.h
index 23b1b34db088..b627ef7188c7 100644
--- a/arch/arm64/net/bpf_jit.h
+++ b/arch/arm64/net/bpf_jit.h
@@ -297,4 +297,10 @@
#define A64_ADR(Rd, offset) \
aarch64_insn_gen_adr(0, offset, Rd, AARCH64_INSN_ADR_TYPE_ADR)
+/* MRS */
+#define A64_MRS_TPIDR_EL1(Rt) \
+ aarch64_insn_gen_mrs(Rt, AARCH64_INSN_SYSREG_TPIDR_EL1)
+#define A64_MRS_TPIDR_EL2(Rt) \
+ aarch64_insn_gen_mrs(Rt, AARCH64_INSN_SYSREG_TPIDR_EL2)
+
#endif /* _BPF_JIT_H */
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 76b91f36c729..e9ad9f257a18 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -877,6 +877,17 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx,
emit(A64_ORR(1, tmp, dst, tmp), ctx);
emit(A64_MOV(1, dst, tmp), ctx);
break;
+ } else if (insn_is_mov_percpu_addr(insn)) {
+ if (dst != src)
+ emit(A64_MOV(1, dst, src), ctx);
+#ifdef CONFIG_SMP
+ if (cpus_have_cap(ARM64_HAS_VIRT_HOST_EXTN))
+ emit(A64_MRS_TPIDR_EL2(tmp), ctx);
+ else
+ emit(A64_MRS_TPIDR_EL1(tmp), ctx);
+ emit(A64_ADD(1, dst, dst, tmp), ctx);
+#endif
+ break;
}
switch (insn->off) {
case 0:
@@ -2527,6 +2538,11 @@ bool bpf_jit_supports_arena(void)
return true;
}
+bool bpf_jit_supports_percpu_insn(void)
+{
+ return true;
+}
+
void bpf_jit_free(struct bpf_prog *prog)
{
if (prog->jited) {
--
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
* [PATCH 1/2] serial: imx: Introduce timeout when waiting on transmitter empty
From: Esben Haabendal @ 2024-04-05 9:25 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Marc Kleine-Budde, linux-kernel, linux-serial, imx,
linux-arm-kernel
By waiting at most 1 second for USR2_TXDC to be set, we avoid a potentital
deadlock.
In case of the timeout, there is not much we can do, so we simply ignore
the transmitter state and optimistically try to continue.
Signed-off-by: Esben Haabendal <esben@geanix.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/tty/serial/imx.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e14813250616..09c1678ddfd4 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -26,6 +26,7 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/dma-mapping.h>
#include <asm/irq.h>
@@ -2010,7 +2011,7 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count)
struct imx_port *sport = imx_uart_ports[co->index];
struct imx_port_ucrs old_ucr;
unsigned long flags;
- unsigned int ucr1;
+ unsigned int ucr1, usr2;
int locked = 1;
if (sport->port.sysrq)
@@ -2041,8 +2042,8 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count)
* Finally, wait for transmitter to become empty
* and restore UCR1/2/3
*/
- while (!(imx_uart_readl(sport, USR2) & USR2_TXDC));
-
+ read_poll_timeout_atomic(imx_uart_readl, usr2, usr2 & USR2_TXDC,
+ 0, USEC_PER_SEC, false, sport, USR2);
imx_uart_ucrs_restore(sport, &old_ucr);
if (locked)
--
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 1/2] arm64: dts: imx8mm-var-som-symphony: drop redundant status from typec
From: Krzysztof Kozlowski @ 2024-04-05 9:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree,
imx, linux-arm-kernel, linux-kernel
Cc: Krzysztof Kozlowski
"okay" is the default status, so drop redundant property from the typec
node.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index d643381417f1..affbc67c2ef6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -117,7 +117,6 @@ extcon_usbotg1: typec@3d {
interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ptn5150>;
- status = "okay";
};
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: imx8mn-var-som-symphony: drop redundant status from typec
From: Krzysztof Kozlowski @ 2024-04-05 9:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree,
imx, linux-arm-kernel, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240405092819.40994-1-krzysztof.kozlowski@linaro.org>
"okay" is the default status, so drop redundant property from the typec
node.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts
index a6b94d1957c9..3434b189fa58 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts
@@ -126,7 +126,6 @@ extcon_usbotg1: typec@3d {
interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ptn5150>;
- status = "okay";
port {
typec1_dr_sw: endpoint {
--
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 v6 05/16] dt-bindings: net: wireless: describe the ath12k PCI module
From: Kalle Valo @ 2024-04-05 9:33 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Liam Girdwood, Mark Brown, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <CAMRc=MeCjNn7QdDrcQMuj32JFYoemQ6A8WOYcwKJo1YhDTfY+Q@mail.gmail.com>
Bartosz Golaszewski <brgl@bgdev.pl> writes:
> On Mon, Mar 25, 2024 at 3:01 PM Kalle Valo <kvalo@kernel.org> wrote:
>>
>> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>>
>> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>> >
>> > +
>> > +maintainers:
>> > + - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>
>> IMHO it would be better to have just driver maintainers listed here.
>>
>
> Why? What's wrong with having the author of the bindings in the Cc list?
If you want follow the ath12k development and review patches then you
can join the ath12k list. I'm not fond of having too many maintainers,
it's not really helping anything and just extra work to periodically
cleanup the silent maintainers.
I would ask the opposite question: why add you as the maintainer?
There's not even a single ath12k patch from you, nor I haven't seen you
doing any patch review or otherwise helping others related to ath12k.
Don't get me wrong, I value the work you do with this important powerseq
feature and hopefully we get it into the tree soon. But I don't see
adding you as a maintainer at this point.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
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 v6 05/16] dt-bindings: net: wireless: describe the ath12k PCI module
From: Krzysztof Kozlowski @ 2024-04-05 9:37 UTC (permalink / raw)
To: Kalle Valo, Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Liam Girdwood, Mark Brown, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <87cyr440hr.fsf@kernel.org>
On 05/04/2024 11:33, Kalle Valo wrote:
> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>
>> On Mon, Mar 25, 2024 at 3:01 PM Kalle Valo <kvalo@kernel.org> wrote:
>>>
>>> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>>>
>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>
>>>> +
>>>> +maintainers:
>>>> + - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>
>>> IMHO it would be better to have just driver maintainers listed here.
>>>
>>
>> Why? What's wrong with having the author of the bindings in the Cc list?
>
> If you want follow the ath12k development and review patches then you
> can join the ath12k list. I'm not fond of having too many maintainers,
> it's not really helping anything and just extra work to periodically
> cleanup the silent maintainers.
>
> I would ask the opposite question: why add you as the maintainer?
> There's not even a single ath12k patch from you, nor I haven't seen you
> doing any patch review or otherwise helping others related to ath12k.
> Don't get me wrong, I value the work you do with this important powerseq
> feature and hopefully we get it into the tree soon. But I don't see
> adding you as a maintainer at this point.
This is not a maintainer of driver. This is maintainer of bindings, so
someone who has hardware, datasheets, knowledge and/or interest in
keeping the bindings accurate.
All your arguments above suggest you talk about the driver. This is not
the point 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 v6 05/16] dt-bindings: net: wireless: describe the ath12k PCI module
From: Krzysztof Kozlowski @ 2024-04-05 9:41 UTC (permalink / raw)
To: Kalle Valo, Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Liam Girdwood, Mark Brown, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <83dccd7e-e690-4803-adb9-aaedcee7dc94@linaro.org>
On 05/04/2024 11:37, Krzysztof Kozlowski wrote:
> On 05/04/2024 11:33, Kalle Valo wrote:
>> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>>
>>> On Mon, Mar 25, 2024 at 3:01 PM Kalle Valo <kvalo@kernel.org> wrote:
>>>>
>>>> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>>>>
>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>>
>>>>> +
>>>>> +maintainers:
>>>>> + - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>
>>>> IMHO it would be better to have just driver maintainers listed here.
>>>>
>>>
>>> Why? What's wrong with having the author of the bindings in the Cc list?
>>
>> If you want follow the ath12k development and review patches then you
>> can join the ath12k list. I'm not fond of having too many maintainers,
>> it's not really helping anything and just extra work to periodically
>> cleanup the silent maintainers.
>>
>> I would ask the opposite question: why add you as the maintainer?
>> There's not even a single ath12k patch from you, nor I haven't seen you
>> doing any patch review or otherwise helping others related to ath12k.
>> Don't get me wrong, I value the work you do with this important powerseq
>> feature and hopefully we get it into the tree soon. But I don't see
>> adding you as a maintainer at this point.
>
> This is not a maintainer of driver. This is maintainer of bindings, so
> someone who has hardware, datasheets, knowledge and/or interest in
> keeping the bindings accurate.
>
> All your arguments above suggest you talk about the driver. This is not
> the point here.
>
And to clarify: I do not have opinion whether Bartosz is a suitable
person here and whether driver maintainers should be instead or not. I
only want to clarify the purpose of the binding maintainer.
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/64] i2c: reword i2c_algorithm according to newest specification
From: Wolfram Sang @ 2024-04-05 8:48 UTC (permalink / raw)
To: Andi Shyti
Cc: linux-i2c, asahi, chrome-platform, imx, linux-actions,
linux-amlogic, linux-arm-kernel, linux-arm-msm, linux-aspeed,
linux-kernel, linux-mediatek, linux-mips, linux-omap,
linuxppc-dev, linux-renesas-soc, linux-riscv, linux-rockchip,
linux-rpi-kernel, linux-samsung-soc, linux-stm32, linux-sunxi,
linux-tegra, openbmc, virtualization
In-Reply-To: <j2l7tu24itjelylrgwe6gdsy3mfrw3dnve4rdofmri3z7xdroc@se56t5ylmdak>
[-- Attachment #1.1: Type: text/plain, Size: 399 bytes --]
Hi Andi, hi everyone,
thank you for reviewing and waiting. I had a small personal hiatus over
Easter but now I am back. This series needs another cycle, so no need to
hurry. I will address some of the review comments but not all. The
conversion (and API improvements) are some bigger tasks, so
inconsistencies inbetween can't be avoided AFAICS.
I'll keep you updated.
Happy hacking,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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 00/17] HSI2, UFS & UFS phy support for Tensor GS101
From: Krzysztof Kozlowski @ 2024-04-05 7:45 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-1-peter.griffin@linaro.org>
On 04/04/2024 14:25, Peter Griffin wrote:
> Hi folks,
>
> This series adds support for the High Speed Interface (HSI) 2 clock
> management unit, UFS controller and UFS phy calibration/tuning for GS101.
>
> With this series applied, UFS is now functional! The SKhynix HN8T05BZGKX015
> can be enumerated, partitions mounted etc. This then allows us to move away
> from the initramfs rootfs we have been using for development so far.
>
> The intention is this series will be merged via Krzysztofs Samsung Exynos
> tree(s). This series is rebased on next-20240404.
>
> The series is broadly split into the following parts:
> 1) dt-bindings documentation updates
> 2) gs101 device tree updates
> 3) Prepatory patches for samsung-ufs driver
> 4) GS101 ufs-phy support
> 5) Prepatory patches for ufs-exynos driver
> 6) GS101 ufs-exynos support
UFS phy and host should go through their trees. What is the
reason/need/requirement to put it into this patchset and merge via
Samsung SoC tree?
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 1/2] serial: imx: Introduce timeout when waiting on transmitter empty
From: Marc Kleine-Budde @ 2024-04-05 9:49 UTC (permalink / raw)
To: Esben Haabendal
Cc: Greg Kroah-Hartman, Jiri Slaby, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel,
linux-serial, imx, linux-arm-kernel
In-Reply-To: <76cf9ce9cbf9dcdf78bc00ce7a919db1776ebce1.1712309058.git.esben@geanix.com>
[-- Attachment #1.1: Type: text/plain, Size: 838 bytes --]
On 05.04.2024 11:25:13, Esben Haabendal wrote:
> By waiting at most 1 second for USR2_TXDC to be set, we avoid a potentital
> deadlock.
>
> In case of the timeout, there is not much we can do, so we simply ignore
> the transmitter state and optimistically try to continue.
>
> Signed-off-by: Esben Haabendal <esben@geanix.com>
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Where's the cover letter and patch 2/2? Have a look at b4 [1], it's a
great tool to help you with sending git patch series.
[1] https://b4.docs.kernel.org/en/latest/
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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 v6 05/16] dt-bindings: net: wireless: describe the ath12k PCI module
From: Bartosz Golaszewski @ 2024-04-05 9:52 UTC (permalink / raw)
To: Kalle Valo
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Liam Girdwood, Mark Brown, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <87cyr440hr.fsf@kernel.org>
On Fri, Apr 5, 2024 at 11:34 AM Kalle Valo <kvalo@kernel.org> wrote:
>
> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>
> > On Mon, Mar 25, 2024 at 3:01 PM Kalle Valo <kvalo@kernel.org> wrote:
> >>
> >> Bartosz Golaszewski <brgl@bgdev.pl> writes:
> >>
> >> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >> >
> >> > +
> >> > +maintainers:
> >> > + - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>
> >> IMHO it would be better to have just driver maintainers listed here.
> >>
> >
> > Why? What's wrong with having the author of the bindings in the Cc list?
>
> If you want follow the ath12k development and review patches then you
> can join the ath12k list. I'm not fond of having too many maintainers,
> it's not really helping anything and just extra work to periodically
> cleanup the silent maintainers.
>
> I would ask the opposite question: why add you as the maintainer?
> There's not even a single ath12k patch from you, nor I haven't seen you
> doing any patch review or otherwise helping others related to ath12k.
> Don't get me wrong, I value the work you do with this important powerseq
> feature and hopefully we get it into the tree soon. But I don't see
> adding you as a maintainer at this point.
>
In addition to what Krzysztof already said about you seamingly
confusing the maintenance of the driver vs maintenance of the
device-tree bindings (IOW: structured hardware description) and in
response to your question: I don't see any functional change to any
dt-bindings neither from you nor from Jeff. Are you convinced you can
maintain and properly review any changes?
If so, I don't really care, I can drop myself and have less work.
Bartosz
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 07/10] perf/hisi_pcie: Avoid placing cpumask var on stack
From: Jonathan Cameron @ 2024-04-05 9:52 UTC (permalink / raw)
To: Mark Rutland
Cc: Dawei Li, will, yury.norov, linux, xueshuai, renyu.zj, yangyicong,
andersson, konrad.dybcio, linux-arm-kernel, linux-kernel,
linux-arm-msm
In-Reply-To: <Zg1pHsWnzczoXBb4@FVFF77S0Q05N>
On Wed, 3 Apr 2024 15:35:10 +0100
Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Apr 03, 2024 at 08:51:06PM +0800, Dawei Li wrote:
> > For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
> > variable on stack is not recommended since it can cause potential stack
> > overflow.
> >
> > Instead, kernel code should always use *cpumask_var API(s) to allocate
> > cpumask var in config-neutral way, leaving allocation strategy to
> > CONFIG_CPUMASK_OFFSTACK.
> >
> > But dynamic allocation in cpuhp's teardown callback is somewhat problematic
> > for if allocation fails(which is unlikely but still possible):
> > - If -ENOMEM is returned to caller, kernel crashes for non-bringup
> > teardown;
> > - If callback pretends nothing happened and returns 0 to caller, it may
> > trap system into an in-consisitent/compromised state;
> >
> > Use newly-introduced cpumask_any_and_but() to address all issues above.
> > It eliminates usage of temporary cpumask var in generic way, no matter how
> > the cpumask var is allocated.
> >
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
>
> The logic looks good to me, but I'd like the commit message updated the same as
> per my comment on patch 2.
>
> With that commit message:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> Mark.
>
> > ---
> > drivers/perf/hisilicon/hisi_pcie_pmu.c | 9 ++++-----
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/perf/hisilicon/hisi_pcie_pmu.c b/drivers/perf/hisilicon/hisi_pcie_pmu.c
> > index 5d1f0e9fdb08..06b192cc31d5 100644
> > --- a/drivers/perf/hisilicon/hisi_pcie_pmu.c
> > +++ b/drivers/perf/hisilicon/hisi_pcie_pmu.c
> > @@ -673,7 +673,6 @@ static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
> > {
> > struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node, struct hisi_pcie_pmu, node);
> > unsigned int target;
> > - cpumask_t mask;
> > int numa_node;
> >
> > /* Nothing to do if this CPU doesn't own the PMU */
> > @@ -684,10 +683,10 @@ static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
> >
> > /* Choose a local CPU from all online cpus. */
> > numa_node = dev_to_node(&pcie_pmu->pdev->dev);
> > - if (cpumask_and(&mask, cpumask_of_node(numa_node), cpu_online_mask) &&
> > - cpumask_andnot(&mask, &mask, cpumask_of(cpu)))
> > - target = cpumask_any(&mask);
> > - else
> > +
> > + target = cpumask_any_and_but(cpumask_of_node(numa_node),
> > + cpu_online_mask, cpu);
> > + if (target >= nr_cpu_ids)
> > target = cpumask_any_but(cpu_online_mask, cpu);
> >
> > if (target >= nr_cpu_ids) {
> > --
> > 2.27.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 08/10] perf/hisi_uncore: Avoid placing cpumask var on stack
From: Jonathan Cameron @ 2024-04-05 9:53 UTC (permalink / raw)
To: Mark Rutland
Cc: Dawei Li, will, yury.norov, linux, xueshuai, renyu.zj, yangyicong,
andersson, konrad.dybcio, linux-arm-kernel, linux-kernel,
linux-arm-msm
In-Reply-To: <Zg1pQ_rnYyZe40_n@FVFF77S0Q05N>
On Wed, 3 Apr 2024 15:35:47 +0100
Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Apr 03, 2024 at 08:51:07PM +0800, Dawei Li wrote:
> > For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
> > variable on stack is not recommended since it can cause potential stack
> > overflow.
> >
> > Instead, kernel code should always use *cpumask_var API(s) to allocate
> > cpumask var in config-neutral way, leaving allocation strategy to
> > CONFIG_CPUMASK_OFFSTACK.
> >
> > But dynamic allocation in cpuhp's teardown callback is somewhat problematic
> > for if allocation fails(which is unlikely but still possible):
> > - If -ENOMEM is returned to caller, kernel crashes for non-bringup
> > teardown;
> > - If callback pretends nothing happened and returns 0 to caller, it may
> > trap system into an in-consisitent/compromised state;
> >
> > Use newly-introduced cpumask_any_and_but() to address all issues above.
> > It eliminates usage of temporary cpumask var in generic way, no matter how
> > the cpumask var is allocated.
> >
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
>
> The logic looks good to me, but I'd like the commit message updated the same as
> per my comment on patch 2.
>
> With that commit message:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.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 v3 07/10] perf/hisi_pcie: Avoid placing cpumask on the stack
From: Jonathan Cameron @ 2024-04-05 9:54 UTC (permalink / raw)
To: Dawei Li
Cc: will, mark.rutland, yury.norov, linux, xueshuai, renyu.zj,
yangyicong, andersson, konrad.dybcio, linux-arm-kernel,
linux-kernel, linux-arm-msm
In-Reply-To: <20240403155950.2068109-8-dawei.li@shingroup.cn>
On Wed, 3 Apr 2024 23:59:47 +0800
Dawei Li <dawei.li@shingroup.cn> wrote:
> In general it's preferable to avoid placing cpumasks on the stack, as
> for large values of NR_CPUS these can consume significant amounts of
> stack space and make stack overflows more likely.
>
> Use cpumask_any_and_but() to avoid the need for a temporary cpumask on
> the stack.
>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net] net: sparx5: fix reconfiguration of PCS on link mode change
From: Daniel Machon @ 2024-04-05 9:53 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Lars Povlsen, Steen Hegelund, UNGLinuxDriver, Bjarni Jonasson
Cc: netdev, linux-arm-kernel, linux-kernel, Steen Hegelund,
Daniel Machon
It was observed that the PCS would be misconfigured on link mode change,
if the negotiated link mode went from no-inband capabilities to in-band
capabilities. This bug appeared after the neg_mode change of phylink [1],
but is really due to the wrong config being used when reconfiguring the PCS.
Fix this by correctly using the new port configuration instead of the old
one.
[1] https://lore.kernel.org/netdev/ZIxQIBfO9dH5xFlg@shell.armlinux.org.uk/
Fixes: 946e7fd5053a ("net: sparx5: add port module support")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
drivers/net/ethernet/microchip/sparx5/sparx5_port.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_port.c b/drivers/net/ethernet/microchip/sparx5/sparx5_port.c
index 3a1b1a1f5a19..60dd2fd603a8 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_port.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_port.c
@@ -731,7 +731,7 @@ static int sparx5_port_pcs_low_set(struct sparx5 *sparx5,
bool sgmii = false, inband_aneg = false;
int err;
- if (port->conf.inband) {
+ if (conf->inband) {
if (conf->portmode == PHY_INTERFACE_MODE_SGMII ||
conf->portmode == PHY_INTERFACE_MODE_QSGMII)
inband_aneg = true; /* Cisco-SGMII in-band-aneg */
@@ -948,7 +948,7 @@ int sparx5_port_pcs_set(struct sparx5 *sparx5,
if (err)
return -EINVAL;
- if (port->conf.inband) {
+ if (conf->inband) {
/* Enable/disable 1G counters in ASM */
spx5_rmw(ASM_PORT_CFG_CSC_STAT_DIS_SET(high_speed_dev),
ASM_PORT_CFG_CSC_STAT_DIS,
---
base-commit: d76c740b2eaaddc5fc3a8b21eaec5b6b11e8c3f5
change-id: 20240305-link-mode-reconfiguration-fix-df961fef5505
Best regards,
--
Daniel Machon <daniel.machon@microchip.com>
_______________________________________________
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 v3 08/10] perf/hisi_uncore: Avoid placing cpumask on the stack
From: Jonathan Cameron @ 2024-04-05 9:54 UTC (permalink / raw)
To: Dawei Li
Cc: will, mark.rutland, yury.norov, linux, xueshuai, renyu.zj,
yangyicong, andersson, konrad.dybcio, linux-arm-kernel,
linux-kernel, linux-arm-msm
In-Reply-To: <20240403155950.2068109-9-dawei.li@shingroup.cn>
On Wed, 3 Apr 2024 23:59:48 +0800
Dawei Li <dawei.li@shingroup.cn> wrote:
> In general it's preferable to avoid placing cpumasks on the stack, as
> for large values of NR_CPUS these can consume significant amounts of
> stack space and make stack overflows more likely.
>
> Use cpumask_any_and_but() to avoid the need for a temporary cpumask on
> the stack.
>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.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 v3 12/25] media: i2c: imx258: Allow configuration of clock lane behaviour
From: Pavel Machek @ 2024-04-05 9:54 UTC (permalink / raw)
To: Luigi311
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel
In-Reply-To: <6c15e492-411a-40aa-b02e-83b8a6d107da@luigi311.com>
[-- Attachment #1.1: Type: text/plain, Size: 968 bytes --]
On Thu 2024-04-04 16:29:11, Luigi311 wrote:
> On 4/3/24 12:48, Pavel Machek wrote:
> > Hi!
> >
> >> The sensor supports the clock lane either remaining in HS mode
> >> during frame blanking, or dropping to LP11.
> >>
> >> Add configuration of the mode via V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK.
> >
> >> + ret = imx258_write_reg(imx258, IMX258_CLK_BLANK_STOP,
> >> + IMX258_REG_VALUE_08BIT,
> >> + imx258->csi2_flags & V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK ?
> >> + 1 : 0);
> >
> > !! can be used to turn value into 1/0. I find it easier to read than ?
> > 1 : 0 combination, but possibly that's fine, too.
> >
> > Best regards,
> > Pavel
> >
>
> I assume you mean by using
>
> !!(imx258->csi2_flags & V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK)
>
> I can go ahead and use that instead
Yes, I'd do that.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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 0/2] Update Energy Model with perfromance limits
From: Jonathan Cameron @ 2024-04-05 9:56 UTC (permalink / raw)
To: Lukasz Luba
Cc: linux-kernel, linux-pm, dietmar.eggemann, linux-arm-kernel,
sudeep.holla, cristian.marussi, linux-samsung-soc, rafael,
viresh.kumar, quic_sibis
In-Reply-To: <20240403162315.1458337-1-lukasz.luba@arm.com>
On Wed, 3 Apr 2024 17:23:13 +0100
Lukasz Luba <lukasz.luba@arm.com> wrote:
Typo in patch title. performance
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] selftests/arm: Add mm test
From: Dev Jain @ 2024-04-05 8:44 UTC (permalink / raw)
To: shuah, linux-arm-kernel
Cc: linux-kselftest, linux-kernel, Anshuman.Khandual, suzuki.poulose,
ryan.roberts, rob.herring, Catalin.Marinas, broonie, will,
mark.rutland, Dev Jain
In-Reply-To: <20240405084410.256788-1-dev.jain@arm.com>
This patch tests the 4GB VA restriction for 32-bit processes; it is required
to test the compat layer, whether the kernel knows that it is running a 32-bit
process or not. Chunks are allocated until the VA gets exhausted; mmap must
fail beyond 4GB. This is asserted against the VA mappings found
in /proc/self/maps.
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
tools/testing/selftests/arm/mm/compat_va.c | 94 ++++++++++++++++++++++
1 file changed, 94 insertions(+)
create mode 100644 tools/testing/selftests/arm/mm/compat_va.c
diff --git a/tools/testing/selftests/arm/mm/compat_va.c b/tools/testing/selftests/arm/mm/compat_va.c
new file mode 100644
index 000000000000..3a78f240bc87
--- /dev/null
+++ b/tools/testing/selftests/arm/mm/compat_va.c
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024 ARM Limited
+ *
+ * Author : Dev Jain <dev.jain@arm.com>
+ *
+ * Tests 4GB VA restriction for 32 bit process
+ */
+
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <sys/mman.h>
+
+#include <linux/sizes.h>
+#include <kselftest.h>
+
+#define MAP_CHUNK_SIZE SZ_1M
+#define NR_CHUNKS_4G (SZ_1G / MAP_CHUNK_SIZE) * 4 /* prevent overflow */
+
+static int validate_address_hint(void)
+{
+ char *ptr;
+
+ ptr = mmap((void *) (1UL << 29), MAP_CHUNK_SIZE, PROT_READ |
+ PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+
+ if (ptr == MAP_FAILED)
+ return 0;
+
+ return 1;
+}
+
+int main(int argc, char *argv[])
+{
+ char *ptr[NR_CHUNKS_4G + 3];
+ char line[1000];
+ const char *file_name;
+ int chunks;
+ FILE *file;
+ int i;
+
+ ksft_print_header();
+ ksft_set_plan(1);
+
+ /* try allocation beyond 4 GB */
+ for (i = 0; i < NR_CHUNKS_4G + 3; ++i) {
+ ptr[i] = mmap(NULL, MAP_CHUNK_SIZE, PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+
+ if (ptr[i] == MAP_FAILED) {
+ if (validate_address_hint())
+ ksft_exit_fail_msg("VA exhaustion failed\n");
+ break;
+ }
+ }
+
+ chunks = i;
+ if (chunks >= NR_CHUNKS_4G) {
+ ksft_test_result_fail("mmapped chunks beyond 4GB\n");
+ ksft_finished();
+ }
+
+ /* parse /proc/self/maps, confirm 32 bit VA mappings */
+ file_name = "/proc/self/maps";
+ file = fopen(file_name, "r");
+ if (file == NULL)
+ ksft_exit_fail_msg("/proc/self/maps cannot be opened\n");
+
+ while (fgets(line, sizeof(line), file)) {
+ const char *whitespace_loc, *hyphen_loc;
+
+ hyphen_loc = strchr(line, '-');
+ whitespace_loc = strchr(line, ' ');
+
+ if (!(hyphen_loc && whitespace_loc)) {
+ ksft_test_result_skip("Unexpected format");
+ ksft_finished();
+ }
+
+ if ((hyphen_loc - line > 8) ||
+ (whitespace_loc - hyphen_loc) > 9) {
+ ksft_test_result_fail("Memory map more than 32 bits\n");
+ ksft_finished();
+ }
+ }
+
+ for (int i = 0; i < chunks; ++i)
+ munmap(ptr[i], MAP_CHUNK_SIZE);
+
+ ksft_test_result_pass("Test\n");
+ ksft_finished();
+}
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] selftests/arm: Add elf test
From: Dev Jain @ 2024-04-05 8:44 UTC (permalink / raw)
To: shuah, linux-arm-kernel
Cc: linux-kselftest, linux-kernel, Anshuman.Khandual, suzuki.poulose,
ryan.roberts, rob.herring, Catalin.Marinas, broonie, will,
mark.rutland, Dev Jain
In-Reply-To: <20240405084410.256788-1-dev.jain@arm.com>
This patch introduces an ELF parsing test; the 5th byte of the ELF header
must be 0x01 for a 32-bit process. A basic sanity check is required to ensure
that we are actually testing a 32-bit build.
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
tools/testing/selftests/arm/elf/parse_elf.c | 75 +++++++++++++++++++++
1 file changed, 75 insertions(+)
create mode 100644 tools/testing/selftests/arm/elf/parse_elf.c
diff --git a/tools/testing/selftests/arm/elf/parse_elf.c b/tools/testing/selftests/arm/elf/parse_elf.c
new file mode 100644
index 000000000000..decd65699858
--- /dev/null
+++ b/tools/testing/selftests/arm/elf/parse_elf.c
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024 ARM Limited
+ *
+ * Author : Dev Jain <dev.jain@arm.com>
+ *
+ * Parse elf header to confirm 32-bit process
+ */
+
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <elf.h>
+#include <stdint.h>
+
+#include <kselftest.h>
+
+/* The ELF file header. This appears at the start of every ELF file. */
+
+struct elf_header {
+ unsigned char e_ident[16]; /* Magic number and other info */
+ uint16_t e_type; /* Object file type */
+ uint16_t e_machine; /* Architecture */
+ uint32_t e_version; /* Object file version */
+ uint64_t e_entry; /* Entry point virtual address */
+ uint64_t e_phoff; /* Program header table file offset */
+ uint64_t e_shoff; /* Section header table file offset */
+ uint32_t e_flags; /* Processor-specific flags */
+ uint16_t e_ehsize; /* ELF header size in bytes */
+ uint16_t e_phentsize; /* Program header table entry size */
+ uint16_t e_phnum; /* Program header table entry count */
+ uint16_t e_shentsize; /* Section header table entry size */
+ uint16_t e_shnum; /* Section header table entry count */
+ uint16_t e_shstrndx; /* Section header string table index */
+};
+
+static int read_elf_header(const char *elfFile)
+{
+ struct elf_header header;
+ FILE *file;
+
+ file = fopen(elfFile, "r");
+ if (file) {
+
+ /* store header in struct */
+ fread(&header, 1, sizeof(header), file);
+ fclose(file);
+
+ /* sanity check: does it really follow ELF format */
+ if (header.e_ident[0] == 0x7f &&
+ header.e_ident[1] == 'E' &&
+ header.e_ident[2] == 'L' &&
+ header.e_ident[3] == 'F') {
+ if (header.e_ident[4] == 0x01)
+ return 0;
+ return 1;
+ }
+ ksft_exit_fail_msg("Cannot parse /proc/self/exe\n");
+ }
+ ksft_exit_fail_msg("Cannot open /proc/self/exe\n");
+ exit(EXIT_FAILURE);
+}
+
+int main(int argc, char *argv[])
+{
+ const char *file_name;
+
+ ksft_print_header();
+ ksft_set_plan(1);
+
+ file_name = "/proc/self/exe";
+ ksft_test_result(read_elf_header(file_name) == 0, "ELF is 32 bit\n");
+ ksft_finished();
+}
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 0/3] arch: Remove fbdev dependency from video helpers
From: Thomas Zimmermann @ 2024-04-05 9:04 UTC (permalink / raw)
To: arnd, sam, javierm, deller, sui.jingfeng
Cc: linux-arch, dri-devel, linux-fbdev, sparclinux, linux-sh,
linuxppc-dev, linux-parisc, linux-mips, linux-m68k, loongarch,
linux-arm-kernel, linux-snps-arc, linux-kernel
In-Reply-To: <20240329203450.7824-1-tzimmermann@suse.de>
Hi,
if there are no further comments, can this series be merged through
asm-generic?
Best regards
Thomas
Am 29.03.24 um 21:32 schrieb Thomas Zimmermann:
> Make architecture helpers for display functionality depend on general
> video functionality instead of fbdev. This avoids the dependency on
> fbdev and makes the functionality available for non-fbdev code.
>
> Patch 1 replaces the variety of Kconfig options that control the
> Makefiles with CONFIG_VIDEO. More fine-grained control of the build
> can then be done within each video/ directory; see parisc for an
> example.
>
> Patch 2 replaces fb_is_primary_device() with video_is_primary_device(),
> which has no dependencies on fbdev. The implementation remains identical
> on all affected platforms. There's one minor change in fbcon, which is
> the only caller of fb_is_primary_device().
>
> Patch 3 renames the source and header files from fbdev to video.
>
> v3:
> - arc, arm, arm64, sh, um: generate asm/video.h (Sam, Helge, Arnd)
> - fix typos (Sam)
> v2:
> - improve cover letter
> - rebase onto v6.9-rc1
>
> Thomas Zimmermann (3):
> arch: Select fbdev helpers with CONFIG_VIDEO
> arch: Remove struct fb_info from video helpers
> arch: Rename fbdev header and source files
>
> arch/arc/include/asm/fb.h | 8 ------
> arch/arm/include/asm/fb.h | 6 -----
> arch/arm64/include/asm/fb.h | 10 --------
> arch/loongarch/include/asm/{fb.h => video.h} | 8 +++---
> arch/m68k/include/asm/{fb.h => video.h} | 8 +++---
> arch/mips/include/asm/{fb.h => video.h} | 12 ++++-----
> arch/parisc/Makefile | 2 +-
> arch/parisc/include/asm/fb.h | 14 -----------
> arch/parisc/include/asm/video.h | 16 ++++++++++++
> arch/parisc/video/Makefile | 2 +-
> arch/parisc/video/{fbdev.c => video-sti.c} | 9 ++++---
> arch/powerpc/include/asm/{fb.h => video.h} | 8 +++---
> arch/powerpc/kernel/pci-common.c | 2 +-
> arch/sh/include/asm/fb.h | 7 ------
> arch/sparc/Makefile | 4 +--
> arch/sparc/include/asm/{fb.h => video.h} | 15 +++++------
> arch/sparc/video/Makefile | 2 +-
> arch/sparc/video/fbdev.c | 26 --------------------
> arch/sparc/video/video.c | 25 +++++++++++++++++++
> arch/um/include/asm/Kbuild | 2 +-
> arch/x86/Makefile | 2 +-
> arch/x86/include/asm/fb.h | 19 --------------
> arch/x86/include/asm/video.h | 21 ++++++++++++++++
> arch/x86/video/Makefile | 3 ++-
> arch/x86/video/{fbdev.c => video.c} | 21 +++++++---------
> drivers/video/fbdev/core/fbcon.c | 2 +-
> include/asm-generic/Kbuild | 2 +-
> include/asm-generic/{fb.h => video.h} | 17 +++++++------
> include/linux/fb.h | 2 +-
> 29 files changed, 124 insertions(+), 151 deletions(-)
> delete mode 100644 arch/arc/include/asm/fb.h
> delete mode 100644 arch/arm/include/asm/fb.h
> delete mode 100644 arch/arm64/include/asm/fb.h
> rename arch/loongarch/include/asm/{fb.h => video.h} (86%)
> rename arch/m68k/include/asm/{fb.h => video.h} (86%)
> rename arch/mips/include/asm/{fb.h => video.h} (76%)
> delete mode 100644 arch/parisc/include/asm/fb.h
> create mode 100644 arch/parisc/include/asm/video.h
> rename arch/parisc/video/{fbdev.c => video-sti.c} (78%)
> rename arch/powerpc/include/asm/{fb.h => video.h} (76%)
> delete mode 100644 arch/sh/include/asm/fb.h
> rename arch/sparc/include/asm/{fb.h => video.h} (75%)
> delete mode 100644 arch/sparc/video/fbdev.c
> create mode 100644 arch/sparc/video/video.c
> delete mode 100644 arch/x86/include/asm/fb.h
> create mode 100644 arch/x86/include/asm/video.h
> rename arch/x86/video/{fbdev.c => video.c} (66%)
> rename include/asm-generic/{fb.h => video.h} (89%)
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* GS101 pl330 AxCACHE
From: Tudor Ambarus @ 2024-04-05 10:05 UTC (permalink / raw)
To: Arnd Bergmann, 김재원/JAEWON KIM, Vinod Koul,
dmaengine, bumyong.lee, surendran.k, l.stelmach, m.szyprowski
Cc: linux-arm-kernel, linux-samsung-soc, linux-kernel@vger.kernel.org,
André Draszik, Peter Griffin, William McVicker, kernel-team,
Sam Protsenko, Krzysztof Kozlowski, sugar.zhang, Alim Akhtar,
Sylwester Nawrocki, Chanwoo Choi, jassisinghbrar, Simek, Michal
Hi,
I'm trying to enable the pl330 DMA controller in GS101 and I'm facing
some problems related to AxCACHE. I'm writing this with the hope that
someone (from samsung?) knows a bit more about the pl330 integration and
its AxCACHE use.
For simplicity, let's consider just the DMA_MEM_TO_MEM case for the
moment. With the current upstream pl330 driver I see that the dmatest
module complains with errors like:
[ 6572.661927][ T6358] dmatest: dma0chan0-copy0: dstbuf[0x18e0] not
copied! Expected cf, got 3f
Checked the downstream driver and found a fix:
- desc->rqcfg.scctl = CCTRL0;
- desc->rqcfg.dcctl = CCTRL0;
+ desc->rqcfg.scctl = CCTRL2;
+ desc->rqcfg.dcctl = CCTRL2;
According to CoreLing DMA-330 TRM [1], the {dst,src}_cache_ctrl fields
program the state of AxCACHE.
AMBA AXI and ACE Protocol Specification [2] says that these signals
specify the memory attributes of a request.
- CTRL0 -> AxCACHE[3:0] = 0b0000 (Device non-bufferable)
- CTRL2 -> AxCACHE[3:0] = 0b0010 (Normal Non-cacheable Non-bufferable)
AxCACHE[1] bit is the Modifiable bit. I guess that GS101 can not meet
the requirements of Non-modifiable transactions. But why? Culprit could
be TREX, the non-coherent interconnect, which collects requests from
different masters and sends the request to cache coherent interconnect
and to System-Level Cache. But I can't pin-point the exact restriction
that comes with it. Any hints here are appreciated.
Thanks for reading up to here. Let's consider now the DMA_MEM_TO_DEV and
DMA_DEV_TO_MEM cases. I guess that for simplicity the driver author
chose to always set CCTRL0 for both src and dst regardless of the memory
type, device or normal. This is possible because normal non-cacheable
memory can be accessed by any Manager using a device memory transaction
(see "A4.5 Mismatched memory attributes" section of [2]). This can be
improved however, if we use CTRL0 (thus Device non-bufferable) for DEV,
and CTRL2 (thus Normal Non-cacheable Non-bufferable) for MEM. I tried
this suggestion on GS101 for a MEM to DEV transaction and I get
timeouts. I tried the downstream driver as well. The downstream GS101
device tree defines all the USI nodes without DMA support, I guess the
to/from DEV transactions are not sorted out yet. I enabled the DMA use
for USI in downstream and ITMON complains with "Unsupported transaction
error". Any feedback is welcomed.
Thanks!
ta
[1]
https://documentation-service.arm.com/static/5e8e25befd977155116a5ad9?token=
[2]
https://documentation-service.arm.com/static/602a9df190ee6824a1e02b98?token=
_______________________________________________
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] arm64: dts: rockchip: add Protonic MECSBC device-tree
From: Sascha Hauer @ 2024-04-05 10:09 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
David Jander
In-Reply-To: <9d325b4e-031c-4f6c-9788-fa5a68470efa@lunn.ch>
On Thu, Apr 04, 2024 at 05:10:41PM +0200, Andrew Lunn wrote:
> > +&gmac1 {
> > + assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
> > + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&cru CLK_MAC1_2TOP>;
> > + phy-handle = <&rgmii_phy1>;
> > + phy-mode = "rgmii";
> > + clock_in_out = "output";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&gmac1m1_miim
> > + &gmac1m1_tx_bus2
> > + &gmac1m1_rx_bus2
> > + &gmac1m1_rgmii_clk
> > + &gmac1m1_clkinout
> > + &gmac1m1_rgmii_bus>;
> > + status = "okay";
> > + tx_delay = <0x30>;
> > + rx_delay = <0x10>;
> > +};
>
> There was a discussion about phy-mode = "rgmii"; and these
> tx/rx_delays last month. Please could you go read that discussion and
> them make use of rgmii-id, and change the delays.
Ok, I'll switch to rgmii-id.
>
> Also, where did you copy this from? If possible, it would be good to
> fix the example everybody copies into new DT blobs.
These are the default values used in over a dozen boards and a also
given in the example in
Documentation/devicetree/bindings/net/rockchip-dwmac.yaml.
These are also the default values the driver uses when tx_delay and
rx_delay are not given in the device tree.
I can prepare a patch to fix the example.
Do you have a pointer why setting the delays in the phy is preferred
over setting them in the network driver? In the end this requires us
to have the correct phy driver whereas setting them in the network
driver would just work for any phy driver?
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
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 0/2] Update Energy Model with perfromance limits
From: Lukasz Luba @ 2024-04-05 10:11 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-kernel, linux-pm, dietmar.eggemann, linux-arm-kernel,
sudeep.holla, cristian.marussi, linux-samsung-soc, rafael,
viresh.kumar, quic_sibis
In-Reply-To: <20240405105600.000019fd@Huawei.com>
On 4/5/24 10:56, Jonathan Cameron wrote:
> On Wed, 3 Apr 2024 17:23:13 +0100
> Lukasz Luba <lukasz.luba@arm.com> wrote:
>
> Typo in patch title. performance
Thank you, good catch!
Regards,
Lukasz
_______________________________________________
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