This is almost the same as the dts of the Xperia Z3, except for the
battery charge limits.
The current on the l21 regulator for shinano is also bumped up
to stop SD card errors.
Signed-off-by: Valeriy Klimin
---
Valeriy Klimin (3):
ARM: dts: qcom: Add Sony Xperia Z3 Compact smartphone
Add the dts for the Z3 Compact. This is currently almost the same
as the plain Z3 as they share almost the same hardware and
nothing device-specific is currently supported.
Signed-off-by: Valeriy Klimin
---
arch/arm/boot/dts/qcom/Makefile| 1 +
.../qcom-msm8974pro-sony-xperi
Add the compatible for this device.
Signed-off-by: Valeriy Klimin
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
b/Documentation/devicetree/bindings/arm/qcom.yaml
index ae885414b181..e53f061
SD cards would exhibit errors similar to ones described in commit
27fe0fc05f35 ("ARM: dts: msm8974-FP2: Increase load on l20 for sdhci")
This patch applies the same change to the regulator for sdhc2.
Signed-off-by: Valeriy Klimin
---
arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-co
On Fri, Jun 21, 2024 at 2:27 AM Ilya Leoshkevich wrote:
>
> Add KMSAN vmalloc metadata areas to kernel_page_tables.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Fri, 2024-06-21 at 02:25 +0200, Ilya Leoshkevich wrote:
> Add KMSAN vmalloc metadata areas to kernel_page_tables.
>
> Signed-off-by: Ilya Leoshkevich
> ---
> arch/s390/mm/dump_pagetables.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/s390/mm/d
On Fri, Jun 21, 2024 at 2:26 AM Ilya Leoshkevich wrote:
>
> KMSAN_WARN_ON() is required for implementing s390-specific KMSAN
> functions, but right now it's available only to the KMSAN internal
> functions. Expose it to subsystems through .
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexand
On 6/12/24 16:12, John Kacur wrote:
>> +/* There are samples above the threshold */
> IMHO The comment isn't needed because the variable had_samples is
> descriptive, but it's not a big deal either
Yeah, I would not do it too, but it is fine.
I am adding it to my queue.
Thanks Luis
With the PM8008 regulator driver scheduled for Linux v6.11[0] let's add
the dts bits for Fairphone 4 and Fairphone 5 which both use this PMIC
for powering the camera sensors - and the pull-up for the CCI (camera
I2C bus).
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=ib-m
PM8008 regulators are used for the cameras found on FP4. Configure the
chip and its voltages.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 109 +-
1 file changed, 108 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm72
PM8008 regulators are used for the cameras found on FP5. Configure the
chip and its voltages.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 105 -
1 file changed, 104 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/qcm6
On Thu, 2024-06-20 at 17:19 +0100, David Woodhouse wrote:
>
> >
> > > +
> > > + /* Counter frequency, and error margin. Units of (second >> 64) */
> > > + uint64_t counter_period_frac_sec;
> >
> > AFAIU this might limit the precision in case of high counter frequencies.
> > Could the
On 6/12/24 16:54, tglo...@redhat.com wrote:
> @@ -550,6 +555,7 @@ static struct timerlat_top_params
> {"aa-only", required_argument, 0, '5'},
> {"warm-up", required_argument, 0, '6'},
> {"trace-buffe
On 6/12/24 16:54, tglo...@redhat.com wrote:
> +
> + nr_states = cpuidle_state_count(cpu);
> +
Question: Is this library implemented for all archs or only
intel &| arm?
If it is restricted to few archs, it is another point to make
it optional.
-- Daniel
Hi Thomas
On 6/12/24 16:54, tglo...@redhat.com wrote:
> From: Tomas Glozar
I think we can split this into two patches, this first part on tools/Build:
> Add a test for libcpupower into feature tests and use it to add a
> dependency on libcpupower to rtla.
>
> Signed-off-by: Tomas Glozar
> ---
On 6/17/24 20:38, Daniel Wagner wrote:
> Use libtracefs as package name to lookup the CFLAGS for libtracefs. This
> makes it possible to use the distro specific path as include path for
> the header file.
So, I added it to my review branch and tested it. It is fine!
But, as the most important use
On 21/06/2024 10:14, Valeriy Klimin wrote:
> Add the compatible for this device.
>
> Signed-off-by: Valeriy Klimin
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
> b/Documentation/
An important part of a production ready Linux kernel driver is
tracepoints. So to write production ready Linux kernel drivers in Rust,
we must be able to call tracepoints from Rust code. This patch series
adds support for calling tracepoints declared in C from Rust.
To use the tracepoint support,
Add just enough support for static key so that we can use it from
tracepoints. Tracepoints rely on `static_key_false` even though it is
deprecated, so we add the same functionality to Rust.
It is not possible to use the existing C implementation of
arch_static_branch because it passes the argument
Make it possible to have Rust code call into tracepoints defined by C
code. It is still required that the tracepoint is declared in a C
header, and that this header is included in the input to bindgen.
Signed-off-by: Alice Ryhl
---
include/linux/tracepoint.h | 18 +++-
include/t
uild on riscv (and I assume loongarch):
>
> error[E0432]: unresolved import `_static_key_false`
> --> /stuff/linux/rust/kernel/static_key.rs:87:10
> |
> 87 | pub use {_static_key_false, static_key_false};
> | ^ no external crate `_static_key_false`
>
> Cheers,
> Conor.
Thank you. Fixed in v3.
https://lore.kernel.org/all/20240621-tracepoint-v3-0-9e44eeea2...@google.com/
Alice
Hi Andrew,
On 04/06/24 22:40, Andrew Davis wrote:
On 6/4/24 12:17 AM, Beleswar Padhi wrote:
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for mbox handle later during rproc start/attach. This a
Comparing pointers with TASK_SIZE does not make sense when kernel and
userspace overlap. Skip the comparison when this is the case.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
mm/kmsan/instrumentation.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Architectures use assembly code to initialize ftrace_regs and call
ftrace_ops_list_func(). Therefore, from the KMSAN's point of view,
ftrace_regs is poisoned on ftrace_ops_list_func entry(). This causes
KMSAN warnings when running the ftrace testsuite.
Fix by trusting the architecture-specific ass
The value assigned to prot is immediately overwritten on the next line
with PAGE_KERNEL. The right hand side of the assignment has no
side-effects.
Fixes: b073d7f8aee4 ("mm: kmsan: maintain KMSAN metadata for page operations")
Suggested-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Sign
Comparing pointers with TASK_SIZE does not make sense when kernel and
userspace overlap. Assume that we are handling user memory access in
this case.
Reported-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
mm/kmsan/hooks.c | 3 ++-
1 file changed, 2
v6: https://lore.kernel.org/lkml/20240621002616.40684-1-...@linux.ibm.com/
v6 -> v7: Drop the ptdump patch.
All patches are reviewed.
v5: https://lore.kernel.org/lkml/20240619154530.163232-1-...@linux.ibm.com/
v5 -> v6: Include KMSAN vmalloc areas in page table dump.
Fix doc co
KMSAN relies on memblock returning all available pages to it
(see kmsan_memblock_free_pages()). It partitions these pages into 3
categories: pages available to the buddy allocator, shadow pages and
origin pages. This partitioning is static.
If new pages appear after kmsan_init_runtime(), it is con
Add a wrapper for memset() that prevents unpoisoning. This is useful
for filling memory allocator redzones.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
include/linux/kmsan.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/linux/kmsan.h b/
Replace the x86-specific asm/pgtable_64_types.h #include with the
linux/pgtable.h one, which all architectures have.
While at it, sort the headers alphabetically for the sake of
consistency with other KMSAN code.
Fixes: f80be4571b19 ("kmsan: add KMSAN runtime core")
Suggested-by: Heiko Carstens
Avoid false KMSAN negatives with SLUB_DEBUG by allowing
kmsan_slab_free() to poison the freed memory, and by preventing
init_object() from unpoisoning new allocations by using __memset().
There are two alternatives to this approach. First, init_object()
can be marked with __no_sanitize_memory. Thi
x86's alloc_node_data() rounds up node data size to PAGE_SIZE. It's not
explained why it's needed, but it's most likely for performance
reasons, since the padding bytes are not used anywhere. Some other
architectures do it as well, e.g., mips rounds it up to the cache line
size.
kmsan_init_shadow(
It's useful to have both tests and kmsan.panic=1 during development,
but right now the warnings, that the tests cause, lead to kernel
panics.
Temporarily set kmsan.panic=0 for the duration of the KMSAN testing.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
mm/kmsan/kmsan
It should be possible to have inline functions in the s390 header
files, which call kmsan_unpoison_memory(). The problem is that these
header files might be included by the decompressor, which does not
contain KMSAN runtime, causing linker errors.
Not compiling these calls if __SANITIZE_MEMORY__ i
On s390 the virtual address 0 is valid (current CPU's lowcore is mapped
there), therefore KMSAN should not complain about it.
Disable the respective check on s390. There doesn't seem to be a
Kconfig option to describe this situation, so explicitly check for
s390.
Reviewed-by: Alexander Potapenko
The inline assembly block in s390's chsc() stores that much.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
mm/kmsan/instrumentation.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/kmsan/instrumentation.c b/mm/kmsan/instrumentation.c
index c
KMSAN_WARN_ON() is required for implementing s390-specific KMSAN
functions, but right now it's available only to the KMSAN internal
functions. Expose it to subsystems through .
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
include/linux/kmsan.h | 25 ++
When building the kmsan test as a module, modpost fails with the
following error message:
ERROR: modpost: "panic_on_kmsan" [mm/kmsan/kmsan_test.ko] undefined!
Export panic_on_kmsan in order to improve the KMSAN usability for
modules.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leos
Building the kernel with CONFIG_SLUB_DEBUG and CONFIG_KMSAN causes
KMSAN to complain about touching redzones in kfree().
Fix by extending the existing KASAN-related metadata_access_enable()
and metadata_access_disable() functions to KMSAN.
Acked-by: Vlastimil Babka
Reviewed-by: Alexander Potapen
Each s390 CPU has lowcore pages associated with it. Each CPU sees its
own lowcore at virtual address 0 through a hardware mechanism called
prefixing. Additionally, all lowcores are mapped to non-0 virtual
addresses stored in the lowcore_ptr[] array.
When lowcore is accessed through virtual address
The constraints of the DFLTCC inline assembly are not precise: they
do not communicate the size of the output buffers to the compiler, so
it cannot automatically instrument it.
Add the manual kmsan_unpoison_memory() calls for the output buffers.
The logic is the same as in [1].
[1]
https://githu
Like for KASAN, it's useful to temporarily disable KMSAN checks around,
e.g., redzone accesses. Introduce kmsan_disable_current() and
kmsan_enable_current(), which are similar to their KASAN counterparts.
Make them reentrant in order to handle memory allocations in interrupt
context. Repurpose the
Add a KMSAN check to the CKSM inline assembly, similar to how it was
done for ASAN in commit e42ac7789df6 ("s390/checksum: always use cksm
instruction").
Acked-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/include/asm/checksum.h | 2 ++
1
Improve the readability by replacing the custom aligning logic with
ALIGN_DOWN(). Unlike other places where a similar sequence is used,
there is no size parameter that needs to be adjusted, so the standard
macro fits.
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
mm/kmsan
Even though the KMSAN warnings generated by memchr_inv() are suppressed
by metadata_access_enable(), its return value may still be poisoned.
The reason is that the last iteration of memchr_inv() returns
`*start != value ? start : NULL`, where *start is poisoned. Because of
this, somewhat counterin
All other sanitizers are disabled for boot as well. While at it, add a
comment explaining why we need this.
Reviewed-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/boot/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/s39
put_user() uses inline assembly with precise constraints, so Clang is
in principle capable of instrumenting it automatically. Unfortunately,
one of the constraints contains a dereferenced user pointer, and Clang
does not currently distinguish user and kernel pointers. Therefore
KMSAN attempts to ac
KMSAN warns about check_canary() accessing the canary.
The reason is that, even though set_canary() is properly instrumented
and sets shadow, slub explicitly poisons the canary's address range
afterwards.
Unpoisoning the canary is not the right thing to do: only
check_canary() is supposed to ever
Prevent KMSAN from complaining about buffers filled by cpacf_trng()
being uninitialized.
Tested-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Acked-by: Heiko Carstens
Signed-off-by: Ilya Leoshkevich
---
arch/s390/include/asm/cpacf.h | 3 +++
1 file changed, 3 insertions(+)
diff --gi
Adjust the stack size for the KMSAN-enabled kernel like it was done
for the KASAN-enabled one in commit 7fef92ccadd7 ("s390/kasan: double
the stack size"). Both tools have similar requirements.
Reviewed-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
stcctm() uses the "Q" constraint for dest, therefore KMSAN does not
understand that it fills multiple doublewords pointed to by dest, not
just one. This results in false positives.
Unpoison the whole dest manually with kmsan_unpoison_memory().
Reported-by: Alexander Gordeev
Reviewed-by: Alexande
Now that everything else is in place, enable KMSAN in Kconfig.
Acked-by: Heiko Carstens
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index c59d2b54df49..3cba4993d
s390 uses assembly code to initialize ftrace_regs and call
kprobe_ftrace_handler(). Therefore, from the KMSAN's point of view,
ftrace_regs is poisoned on kprobe_ftrace_handler() entry. This causes
KMSAN warnings when running the ftrace testsuite.
Fix by trusting the assembly code and always unpois
The pages for the KMSAN metadata associated with most kernel mappings
are taken from memblock by the common code. However, vmalloc and module
metadata needs to be defined by the architectures.
Be a little bit more careful than x86: allocate exactly MODULES_LEN
for the module shadow and origins, an
Diagnose 224 stores 4k bytes, which currently cannot be deduced from
the inline assembly constraints. This leads to KMSAN false positives.
Fix the constraints by using a 4k-sized struct instead of a raw
pointer. While at it, prettify them too.
Suggested-by: Heiko Carstens
Reviewed-by: Alexander
Lockdep generates the following false positives with KMSAN on s390x:
[6.063666] DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled())
[ ...]
[6.577050] Call Trace:
[6.619637] [<0690d2de>] check_flags+0x1fe/0x210
[6.665411] ([<0690d2da>] check_flags+0x1fa/0x210)
[
Add KMSAN support for the s390 implementations of the string functions.
Do this similar to how it's already done for KASAN, except that the
optimized memset{16,32,64}() functions need to be disabled: it's
important for KMSAN to know that they initialized something.
The way boot code is built with
uaccess.h uses instrument_get_user() and instrument_put_user(), which
are defined in linux/instrumented.h. Currently we get this header from
somewhere else by accident; prefer to be explicit about it and include
it directly.
Suggested-by: Alexander Potapenko
Reviewed-by: Alexander Potapenko
Sign
arch_kmsan_get_meta_or_null() finds the lowcore shadow by querying the
prefix and calling kmsan_get_metadata() again.
kmsan_virt_addr_valid() delegates to virt_addr_valid().
Acked-by: Alexander Gordeev
Reviewed-by: Alexander Potapenko
Signed-off-by: Ilya Leoshkevich
---
arch/s390/include/asm/
This is normally done by the generic entry code, but the
kernel_stack_overflow() flow bypasses it.
Reviewed-by: Alexander Potapenko
Acked-by: Heiko Carstens
Signed-off-by: Ilya Leoshkevich
---
arch/s390/kernel/traps.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/s390/kernel/t
The unwind code can read uninitialized frames. Furthermore, even in
the good case, KMSAN does not emit shadow for backchains. Therefore
disable it for the unwinding functions.
Reviewed-by: Alexander Potapenko
Acked-by: Heiko Carstens
Signed-off-by: Ilya Leoshkevich
---
arch/s390/kernel/unwind_
IPQ8074 needs support for secure pil as well.
Also, currently only unified firmware is supported.
IPQ8074 supports split firmware for q6 and m3, so
adding support for that.
changes since v8:
- Rebased on top of Linux 6.10-rc4
Gokul Sriram Palanisamy (8):
remoteproc: qcom: Add PRNG proxy clock
IPQ8074 supports split firmware for q6 and m3 as well.
So add support for loading the m3 firmware before q6.
Now the drivers works fine for both split and unified
firmwares.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc
PRNG clock is needed by the secure PIL, support for the same
is added in subsequent patches.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 65 +
1 file changed, 47 insertio
IPQ8074 uses secure PIL. Hence, adding the support for the same.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 43 +++--
1 file changed, 40 insertions(+), 3 deletions(-)
diff
Add name for ssr subdevice on IPQ8074 SoC.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
b/drivers/remoteproc/qco
Fixed issue in reading halt-regs parameter from device-tree.
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
Add binding for WCSSAON reset required for Q6v5 reset on IPQ8074 SoC.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
Acked-by: Rob Herring
Acked-by: Stephen Boyd
---
include/dt-bindings/clock/qcom,gcc-ipq8074.h | 1 +
1 file changed, 1 inser
Add WCSSAON reset required for Q6v5 on IPQ8074 SoC.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
Acked-by: Stephen Boyd
---
drivers/clk/qcom/gcc-ipq8074.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/qcom/gcc-ipq8074.c b/
Enable remoteproc WCSS PIL driver with glink. Also,
configure shared memory and enables smp2p required for IPC.
Signed-off-by: Nikhil Prakash V
Signed-off-by: Sricharan R
Signed-off-by: Gokul Sriram Palanisamy
---
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 80 +++
1 file c
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to noop_queue.
In veth_init_queue, the initial tx_num w
On 06/20, Andrii Nakryiko wrote:
>
> On Thu, Jun 20, 2024 at 12:40 PM Oleg Nesterov wrote:
> >
> > But I can't understand what does it do, it calls emit_break() and
> > git grep -w emit_break finds nothing.
> >
>
> It's DEF_EMIT_REG0I15_FORMAT(break, break_op) in
> arch/loongarch/include/asm/inst.
On Fri, Jun 21, 2024 at 12:35 PM Alice Ryhl wrote:
>
> Make it possible to have Rust code call into tracepoints defined by C
> code. It is still required that the tracepoint is declared in a C
> header, and that this header is included in the input to bindgen.
>
> Signed-off-by: Alice Ryhl
> ---
On Fri, Jun 21, 2024 at 02:01:50PM +0200, Oleg Nesterov wrote:
> On 06/20, Andrii Nakryiko wrote:
> >
> > On Thu, Jun 20, 2024 at 12:40 PM Oleg Nesterov wrote:
> > >
> > > But I can't understand what does it do, it calls emit_break() and
> > > git grep -w emit_break finds nothing.
> > >
> >
> > It
On 6/21/24 6:14 AM, Beleswar Prasad Padhi wrote:
Hi Andrew,
On 04/06/24 22:40, Andrew Davis wrote:
On 6/4/24 12:17 AM, Beleswar Padhi wrote:
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for m
On Thu, 2024-06-20 at 14:37 +0200, Peter Hilber wrote:
> Should implement .gettimex64 instead.
Thanks. This look sane?
As noted in the code comment, in the *ideal* case we just build all
three pre/post/device timestamps from the very same counter read. So
sts->pre_ts == sts->post_ts.
In the less
Am 18.06.2024 um 21:58 schrieb Luis Chamberlain:
On Thu, Jun 06, 2024 at 03:31:49PM +0200, Daniel v. Kirschten wrote:
If a module is being loaded, and the .gnu.linkonce.this_module section
in the module's ELF file does not have the WRITE flag, the kernel will
map the finished module struct of th
On 21/06/2024 08:45, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to noop
://lore.kernel.org/r/20240621-sony-aries-v1-0-bcf968769...@gmail.com
---
Valeriy Klimin (3):
dt-bindings: arm: qcom: Add Sony Xperia Z3 Compact
ARM: dts: qcom: Add Sony Xperia Z3 Compact smartphone
ARM: dts: qcom: msm8974-sony-shinano: increase load on l21 for sdhc2
Documentation
Add the compatible for this device.
Signed-off-by: Valeriy Klimin
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
b/Documentation/devicetree/bindings/arm/qcom.yaml
index ae885414b181..e53f061
Add the dts for the Z3 Compact. This is currently almost the same
as the plain Z3 as they share almost the same hardware and
nothing device-specific is currently supported.
Signed-off-by: Valeriy Klimin
---
arch/arm/boot/dts/qcom/Makefile| 1 +
.../qcom-msm8974pro-sony-xperi
SD cards would exhibit errors similar to ones described in commit
27fe0fc05f35 ("ARM: dts: msm8974-FP2: Increase load on l20 for sdhci")
This patch applies the same change to the regulator for sdhc2.
Signed-off-by: Valeriy Klimin
---
arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-co
When a resource table is loaded by an external entity such as U-boot or
OP-TEE, we do not necessarily get the device address(da) but the physical
address(pa).
This helper performs similar translation than the rproc_da_to_va()
but based on a physical address.
Signed-off-by: Arnaud Pouliquen
---
up
The new TEE remoteproc device is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format de
Add a remoteproc TEE (Trusted Execution Environment) driver
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this driver offers a client
interface to load a firmware by the secure part.
This firmware could be authenticated by the secure trusted a
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without remoteproc TEE support.
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 84 +++-
1 file changed, 51 insertions(+), 33 deletions(-
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted Execution Environment
(TEE).
For instance, this compatible is used in both the Linux and OP-TEE device
trees:
- In OP-TEE, a node is defined in the device tree with the
Main updates from version V7[1]
Update the series based on Mathieu Poirier's comments.
Details of the updates are listed in the commit messages of the patches.
[1]
https://lore.kernel.org/linux-arm-kernel/20240611073904.475019-1-arnaud.pouliq...@foss.st.com/
base-commit: 1613e604df0cd359cf2a7fb
This series enables the suspend to ram with R5F remote processors on TI K3
platform.
The 1st patch is actually a fix, independent from the others
The 2nd patch introduces the suspend/resume handlers.
On suspend, the running rprocs will be stopped (or detached) and then
re-loaded in resume.
The lo
This patch adds the support for system suspend/resume to the ti_k3_R5
remoteproc driver.
In order to save maximum power, the approach here is to shutdown
completely the cores that were started by the kernel (i.e. those in
RUNNING state).
Those which were started before the kernel (in attached mode
In the next commit, a RP_MBOX_SHUTDOWN message will be sent in
k3_r5_rproc_stop() to the remote proc (in lockstep on not)
Thus, the sanity check "do not allow core 0 to stop before core 1"
should be moved at the beginning of the function so that the generic case
can be dealt with.
In order to have
Introduce software IPC handshake between the K3-R5 remote proc driver
and the R5 MCU to gracefully stop/reset the remote core.
Upon a stop request, K3-R5 remote proc driver sends a RP_MBOX_SHUTDOWN
mailbox message to the remote R5 core.
The remote core is expected to:
- relinquish all the resource
ret variable was used to test reset status, get from
reset_control_status() call. But this variable was overwritten by
ti_sci_proc_get_status() a few lines bellow.
And as ti_sci_proc_get_status() returns 0 or a negative value (in this
latter case, followed by a return), the expression !ret was alwa
Hi Pedro,
On 6/21/24 11:24 오후, Pedro Tammela wrote:
> On 21/06/2024 08:45, ysk...@gmail.com wrote:
>> From: Yunseong Kim
>>
>> In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
>>
>> qdisc->dev_queue->dev ->name
>>
>> This situation simulated from bunch of veths and Bluetooth
>> d
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
>
> -static int q6v5_wcss_init_clock(struct q6v5_wcss *wcss)
> +static int ipq8074_init_clock(struct q6v5_wcss *wcss)
> +{
> + int ret;
> +
> + wcss->prng_clk = devm_clk_get(wcss->dev, "prng");
Missing binding.
Best regards,
Krzysztof
Function rb_check_pages() validates the integrity of a specified per-CPU
tracing ring buffer. It does so by walking the underlying linked
list and checking its next and prev links.
To guarantee that the list doesn't get modified during the check,
a caller typically needs to take cpu_buffer->reader
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
> Fixed issue in reading halt-regs parameter from device-tree.
What issue?
That's a terrible commit msg. Explain what is the problem, how can it be
reproduced.
>
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
> ---
>
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
> Add binding for WCSSAON reset required for Q6v5 reset on IPQ8074 SoC.
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
Again, three people contributed to this one define?
Best regard
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
> Enable remoteproc WCSS PIL driver with glink. Also,
> configure shared memory and enables smp2p required for IPC.
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
> ---
> arch/arm64/b
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
> Add name for ssr subdevice on IPQ8074 SoC.
Why?
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
Three people developed that single line?
Something is really odd with your DCO chai
1 - 100 of 134 matches
Mail list logo
