On Fri, 12 Apr 2024 11:29:50 +0800
Yuntao Wang wrote:
> There is a space at the end of extra_init_args. In the current logic,
> copying extra_init_args to saved_command_line will cause extra spaces
> in saved_command_line here or there. Remove the trailing space from
> extra_init_args to make
On Thu, Apr 11, 2024 at 5:17 PM Beau Belgrave wrote:
>
> In the Open Telemetry profiling SIG [1], we are trying to find a way to
> grab a tracing association quickly on a per-sample basis. The team at
> Elastic has a bespoke way to do this [2], however, I'd like to see a
> more general way to
There is a space at the end of extra_init_args. In the current logic,
copying extra_init_args to saved_command_line will cause extra spaces
in saved_command_line here or there. Remove the trailing space from
extra_init_args to make the string in saved_command_line look more perfect.
Quoting Duje Mihanović (2024-04-11 03:15:34)
> On 4/11/2024 10:00 AM, Stephen Boyd wrote:
> >
> > Is there a reason this file can't be a platform driver?
>
> Not that I know of, I did it like this only because the other in-tree
> MMP clk drivers do so. I guess the initialization should look
From: Qiang Zhang
On the time to free xbc memory, memblock has handed over memory to buddy
allocator. So it doesn't make sense to free memory back to memblock.
memblock_free() called by xbc_exit() even causes UAF bugs on architectures
with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86. Following
On Fri, Apr 12, 2024 at 10:03:26AM +0800, qiang4.zh...@linux.intel.com wrote:
>From: Qiang Zhang
>
>On the time to free xbc memory, memblock has handed over memory to buddy
>allocator. So it doesn't make sense to free memory back to memblock.
>memblock_free() called by xbc_exit() even causes UAF
From: Qiang Zhang
On the time to free xbc memory, memblock has handed over memory to buddy
allocator. So it doesn't make sense to free memory back to memblock.
memblock_free() called by xbc_exit() even causes UAF bugs on architectures
with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86. Following
On Fri, 12 Apr 2024 08:08:39 +0900, Masami Hiramatsu (Google)
wrote:
> On Thu, 11 Apr 2024 23:29:40 +0800
> Yuntao Wang wrote:
>
> > On Thu, 11 Apr 2024 23:07:45 +0900, Masami Hiramatsu (Google)
> > wrote:
> >
> > > On Thu, 11 Apr 2024 09:19:32 +0200
> > > Geert Uytterhoeven wrote:
> > >
On Sat, 06 Apr 2024 17:27:20 +0200, Luca Weiss wrote:
> Enable the vibrator connected to PM8941 found on the Sony shinano
> platform.
>
>
Applied, thanks!
[1/1] ARM: dts: qcom: msm8974-sony-shinano: Enable vibrator
commit: 5c94b0b906436aad74e559195007afdd328211f4
Best regards,
--
When samples are generated, there is no way via the perf_event ABI to
fetch per-thread data. This data is very useful in tracing scenarios
that involve correlation IDs, such as OpenTelemetry. They are also
useful for tracking per-thread performance details directly within a
cooperating user
In the Open Telemetry profiling SIG [1], we are trying to find a way to
grab a tracing association quickly on a per-sample basis. The team at
Elastic has a bespoke way to do this [2], however, I'd like to see a
more general way to achieve this. The folks I've been talking with seem
open to the
Now that perf supports TLS dumps, x86-64 can provide the details for how
to get TLS data for user threads.
Enable HAVE_PERF_USER_TLS_DUMP Kconfig only for x86-64. I do not have
access to x86 to validate 32-bit.
Utilize mmap_is_ia32() to determine 32/64 bit threads. Use fsbase for
64-bit and
We now have two user dump sources (stack and tls). Both are doing the
same logic to ensure the user dump ABI output is properly handled. The
only difference is one gets the address within the method, and the other
is passed the address.
Add perf_output_sample_udump() and utilize it for both stack
Factor out perf_prepare_dump_data() so that the same logic is used for
dumping stack data as other types, such as TLS.
Slightly refactor perf_sample_ustack_size() to perf_sample_dump_size().
Move reg checks up into perf_ustack_task_size() since the task size
must now be calculated before
On Thu, 11 Apr 2024 23:29:40 +0800
Yuntao Wang wrote:
> On Thu, 11 Apr 2024 23:07:45 +0900, Masami Hiramatsu (Google)
> wrote:
>
> > On Thu, 11 Apr 2024 09:19:32 +0200
> > Geert Uytterhoeven wrote:
> >
> > > CC Hiramatsu-san (now for real :-)
> >
> > Thanks!
> >
> > >
> > > On Thu, Apr
On Thu, 11 Apr 2024 17:40:02 +0200 Michal Koutný wrote:
> Hello.
>
> On Mon, Apr 08, 2024 at 01:29:55PM -0700, Andrew Morton
> wrote:
> > That seems like a large change.
>
> In what sense is it large?
A large increase in the maximum number of processes. Or did I misinterpret?
Hi Mike.
On Thu, Apr 11, 2024 at 07:00:42PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Several architectures override module_alloc() only to define address
> range for code allocations different than VMALLOC address space.
>
> Provide a generic implementation in execmem that
On Thu, Apr 11, 2024 at 09:59:35PM +0200, Krzysztof Kozlowski wrote:
> On 10/04/2024 04:20, Ondřej Jirman wrote:
> > On Mon, Apr 08, 2024 at 10:12:30PM GMT, Krzysztof Kozlowski wrote:
> >> On 08/04/2024 17:17, Ondřej Jirman wrote:
> >>>
> >>> Now for things to not fail during suspend/resume based
On 10/04/2024 04:20, Ondřej Jirman wrote:
> On Mon, Apr 08, 2024 at 10:12:30PM GMT, Krzysztof Kozlowski wrote:
>> On 08/04/2024 17:17, Ondřej Jirman wrote:
>>>
>>> Now for things to not fail during suspend/resume based on PM callbacks
>>> invocation order, anx7688 driver needs to enable this
On Thu, Apr 11, 2024 at 07:00:36PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Hi,
>
> Since v3 I looked into making execmem more of an utility toolbox, as we
> discussed at LPC with Mark Rutland, but it was getting more hairier than
> having a struct describing architecture
On Thu, Apr 11, 2024 at 07:00:41PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> module_alloc() is used everywhere as a mean to allocate memory for code.
>
> Beside being semantically wrong, this unnecessarily ties all subsystems
> that need to allocate code, such as ftrace,
On Thu, Apr 11, 2024 at 11:00 AM David Matlack wrote:
>
> On Thu, Apr 11, 2024 at 10:28 AM David Matlack wrote:
> >
> > On 2024-04-11 10:08 AM, David Matlack wrote:
> > > On 2024-04-01 11:29 PM, James Houghton wrote:
> > > > Only handle the TDP MMU case for now. In other cases, if a bitmap was
>
On 4/11/24 11:12 AM, Mathieu Poirier wrote:
> On Wed, Apr 10, 2024 at 05:36:30PM -0500, Tanmay Shah wrote:
>>
>>
>> On 4/10/24 11:59 AM, Mathieu Poirier wrote:
>> > On Mon, Apr 08, 2024 at 01:53:14PM -0700, Tanmay Shah wrote:
>> >> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM
On Thu, Apr 11, 2024 at 06:55:44PM +0200, Paolo Bonzini wrote:
> On Mon, Apr 8, 2024 at 3:56 PM Peter Xu wrote:
> > Paolo,
> >
> > I may miss a bunch of details here (as I still remember some change_pte
> > patches previously on the list..), however not sure whether we considered
> > enable it?
My original, naive, FPU support patch had the FPCSR register stored
during both the *mode switch* and *context switch*. This is wasteful.
Also, the original patches did not save the FPU state when handling
signals during the system call fast path.
We fix this by moving the FPCSR state to
Allow disabling FPU related code sequences to save space.
Signed-off-by: Stafford Horne
---
arch/openrisc/Kconfig | 9 +
arch/openrisc/kernel/ptrace.c | 6 ++
arch/openrisc/kernel/traps.c | 3 ++-
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git
OpenRISC exception handling sends signals to user processes on floating
point exceptions and trap instructions (for debugging) among others.
There is a bug where the trap handling logic may send signals to kernel
threads, we should not send these signals to kernel threads, if that
happens we treat
The die function calls show_registers unconditionally. Remove calls to
show_registers before calling die to avoid printing all registers and
stack status two times during a crash.
This was found when testing kernel trap and floating point exception
handling.
Signed-off-by: Stafford Horne
---
The pr_* macros are the convention and my upcoming patches add even more
printk's. Use this opportunity to convert the printks in this file to
the pr_* macros to avoid patch check warnings.
Signed-off-by: Stafford Horne
---
arch/openrisc/kernel/traps.c | 88 ++--
This series has some fixups found when I was doing a deep dive
documentation of the OpenRISC FPU support which was added in 2023.
http://stffrdhrn.github.io/hardware/embedded/openrisc/2023/08/24/or1k-fpu-linux-and-compilers.html
The FPU handling has issues of being inefficient and also not
On Thu, Apr 11, 2024 at 10:28 AM David Matlack wrote:
>
> On 2024-04-11 10:08 AM, David Matlack wrote:
> > On 2024-04-01 11:29 PM, James Houghton wrote:
> > > Only handle the TDP MMU case for now. In other cases, if a bitmap was
> > > not provided, fallback to the slowpath that takes mmu_lock,
On Thu, Apr 11, 2024 at 07:00:36PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Hi,
>
> Since v3 I looked into making execmem more of an utility toolbox, as we
> discussed at LPC with Mark Rutland, but it was getting more hairier than
> having a struct describing architecture
On 2024-04-11 10:08 AM, David Matlack wrote:
> On 2024-04-01 11:29 PM, James Houghton wrote:
> > Only handle the TDP MMU case for now. In other cases, if a bitmap was
> > not provided, fallback to the slowpath that takes mmu_lock, or, if a
> > bitmap was provided, inform the caller that the bitmap
On 2024-04-01 11:29 PM, James Houghton wrote:
> Only handle the TDP MMU case for now. In other cases, if a bitmap was
> not provided, fallback to the slowpath that takes mmu_lock, or, if a
> bitmap was provided, inform the caller that the bitmap is unreliable.
>
> Suggested-by: Yu Zhao
>
This series implements some missing OpenRISC relocations to allow
module loading to work. I tested a few modules and these relocations
were enough to allow for several modules I tested with.
In the series we:
1. Update the relocations to add all of the relocation types currently
defined
On Wed, Apr 10, 2024 at 11:30 PM Andrew Morton
wrote:
> On Fri, 5 Apr 2024 07:58:11 -0400 Paolo Bonzini wrote:
> > Please review! Also feel free to take the KVM patches through the mm
> > tree, as I don't expect any conflicts.
>
> It's mainly a KVM thing and the MM changes are small and
On Mon, Apr 8, 2024 at 3:56 PM Peter Xu wrote:
> Paolo,
>
> I may miss a bunch of details here (as I still remember some change_pte
> patches previously on the list..), however not sure whether we considered
> enable it? Asked because I remember Andrea used to have a custom tree
> maintaining
When testing modules in OpenRISC I found R_OR1K_AHI16 (signed adjusted
high 16-bit) and R_OR1K_SLO16 (split low 16-bit) relocations are used in
modules but not implemented yet.
This patch implements the relocations. I have tested with a few modules.
Signed-off-by: Stafford Horne
---
This defines the current OpenRISC relocation types using the current
R_OR1K_* naming conventions.
The old R_OR32_* definitions are left for backwards compatibility.
Note, the R_OR32_VTENTRY and R_OR32_VTINHERIT macros were defined with
the wrong values the have always been 7 and 8 respectively,
On Thu, 11 Apr 2024, Karel Balej wrote:
> Lee Jones, 2024-04-11T12:37:26+01:00:
> [...]
> > > diff --git a/drivers/mfd/88pm886.c b/drivers/mfd/88pm886.c
> > > new file mode 100644
> > > index ..e06d418a5da9
> > > --- /dev/null
> > > +++ b/drivers/mfd/88pm886.c
> > > @@ -0,0 +1,157 @@
On Wed, Apr 10, 2024 at 05:36:30PM -0500, Tanmay Shah wrote:
>
>
> On 4/10/24 11:59 AM, Mathieu Poirier wrote:
> > On Mon, Apr 08, 2024 at 01:53:14PM -0700, Tanmay Shah wrote:
> >> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> >> is available in device-tree. Parse TCM
From: "Mike Rapoport (IBM)"
Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module
text allocations.
Signed-off-by: Mike Rapoport (IBM)
---
arch/x86/mm/init.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/x86/mm/init.c
From: "Mike Rapoport (IBM)"
Using large pages to map text areas reduces iTLB pressure and improves
performance.
Extend execmem_alloc() with an ability to use PMD_SIZE'ed pages with ROX
permissions as a cache for smaller allocations.
To populate the cache, a writable large page is allocated
From: "Mike Rapoport (IBM)"
When module text memory will be allocated with ROX permissions, the
memory at the actual address where the module will live will contain
invalid instructions and there will be a writable copy that contains the
actual module code.
Update relocations and alternatives
From: Song Liu
ftrace_process_locs sorts module mcount, which is inside RO memory. Add a
ftrace_swap_func so that archs can use RO-memory-poke function to do the
sorting.
Signed-off-by: Song Liu
Signed-off-by: Mike Rapoport (IBM)
---
include/linux/ftrace.h | 2 ++
kernel/trace/ftrace.c |
From: "Mike Rapoport (IBM)"
In order to support ROX allocations for module text, it is necessary to
handle modifications to the code, such as relocations and alternatives
patching, without write access to that memory.
One option is to use text patching, but this would make module loading
From: "Mike Rapoport (IBM)"
vmalloc allocations with VM_ALLOW_HUGE_VMAP that do not explictly
specify node ID will use huge pages only if size_per_node is larger than
PMD_SIZE.
Still the actual allocated memory is not distributed between nodes and
there is no advantage in such approach.
On the
From: "Mike Rapoport (IBM)"
Several architectures support text patching, but they name the header
files that declare patching functions differently.
Make all such headers consistently named text-patching.h and add an empty
header in asm-generic for architectures that do not support text
From: "Mike Rapoport (IBM)"
Hi,
These patches add support for using large ROX pages for allocations of
executable memory on x86.
They address Andy's comments [1] about having executable mappings for code
that was not completely formed.
The approach taken is to allocate ROX memory along with
From: "Mike Rapoport (IBM)"
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT on CONFIG_MODULES and make it select
From: "Mike Rapoport (IBM)"
kprobes depended on CONFIG_MODULES because it has to allocate memory for
code.
Since code allocations are now implemented with execmem, kprobes can be
enabled in non-modular kernels.
Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside
modules,
From: "Mike Rapoport (IBM)"
There are places where CONFIG_MODULES guards the code that depends on
memory allocation being done with module_alloc().
Replace CONFIG_MODULES with CONFIG_EXECMEM in such places.
Signed-off-by: Mike Rapoport (IBM)
---
arch/powerpc/Kconfig | 2 +-
From: "Mike Rapoport (IBM)"
Dynamic ftrace must allocate memory for code and this was impossible
without CONFIG_MODULES.
With execmem separated from the modules code, execmem_text_alloc() is
available regardless of CONFIG_MODULES.
Remove dependency of dynamic ftrace on CONFIG_MODULES and make
From: "Mike Rapoport (IBM)"
execmem does not depend on modules, on the contrary modules use
execmem.
To make execmem available when CONFIG_MODULES=n, for instance for
kprobes, split execmem_params initialization out from
arch/*/kernel/module.c and compile it when CONFIG_EXECMEM=y
From: "Mike Rapoport (IBM)"
powerpc overrides kprobes::alloc_insn_page() to remove writable
permissions when STRICT_MODULE_RWX is on.
Add definition of EXECMEM_KRPOBES to execmem_params to allow using the
generic kprobes::alloc_insn_page() with the desired permissions.
As powerpc uses
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on RISC-V are not placed in
the modules area and these custom allocations are implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec().
Slightly reorder execmem_params initialization to support both 32 and
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on arm64 can be placed
anywhere in vmalloc address space and currently this is implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec() in arm64.
Define EXECMEM_KPROBES and EXECMEM_BPF ranges in
From: "Mike Rapoport (IBM)"
Extend execmem parameters to accommodate more complex overrides of
module_alloc() by architectures.
This includes specification of a fallback range required by arm, arm64
and powerpc, EXECMEM_MODULE_DATA type required by powerpc, support for
allocation of KASAN
From: "Mike Rapoport (IBM)"
Several architectures override module_alloc() only to define address
range for code allocations different than VMALLOC address space.
Provide a generic implementation in execmem that uses the parameters for
address space ranges, required alignment and page
From: "Mike Rapoport (IBM)"
module_alloc() is used everywhere as a mean to allocate memory for code.
Beside being semantically wrong, this unnecessarily ties all subsystems
that need to allocate code, such as ftrace, kprobes and BPF to modules and
puts the burden of code allocation to the
From: "Mike Rapoport (IBM)"
Move the logic related to the memory allocation and freeing into
module_memory_alloc() and module_memory_free().
Signed-off-by: Mike Rapoport (IBM)
---
kernel/module/main.c | 64 +++-
1 file changed, 39 insertions(+), 25
From: "Mike Rapoport (IBM)"
nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26
cannot reach all of vmalloc address space.
Define module space as 32MiB below the kernel base and switch nios2 to
use vmalloc for module allocations.
Suggested-by: Thomas Gleixner
Acked-by:
From: "Mike Rapoport (IBM)"
and MODULE_END to MODULES_END to match other architectures that define
custom address space for modules.
Signed-off-by: Mike Rapoport (IBM)
---
arch/mips/include/asm/pgtable-64.h | 4 ++--
arch/mips/kernel/module.c | 4 ++--
arch/mips/mm/fault.c
From: "Mike Rapoport (IBM)"
Since commit f6f37d9320a1 ("arm64: select KASAN_VMALLOC for SW/HW_TAGS
modes") KASAN_VMALLOC is always enabled when KASAN is on. This means
that allocations in module_alloc() will be tracked by KASAN protection
for vmalloc() and that kasan_alloc_module_shadow() will
From: "Mike Rapoport (IBM)"
Hi,
Since v3 I looked into making execmem more of an utility toolbox, as we
discussed at LPC with Mark Rutland, but it was getting more hairier than
having a struct describing architecture constraints and a type identifying
the consumer of execmem.
And I do think
On Fri, Apr 12, 2024 at 12:55:19AM +0900, Masami Hiramatsu wrote:
> On Wed, 10 Apr 2024 08:35:42 -0700
> Beau Belgrave wrote:
>
> > On Wed, Apr 10, 2024 at 10:06:28PM +0900, Masami Hiramatsu wrote:
> > > On Thu, 4 Apr 2024 12:26:41 -0700
> > > Beau Belgrave wrote:
> > >
> > > > Hello,
> > > >
On Thu, 11 Apr 2024 12:20:57 +0200
Marco Elver wrote:
> Add "sched_prepare_exec" tracepoint, which is run right after the point
> of no return but before the current task assumes its new exec identity.
>
> Unlike the tracepoint "sched_process_exec", the "sched_prepare_exec"
> tracepoint runs
On Wed, 10 Apr 2024 08:35:42 -0700
Beau Belgrave wrote:
> On Wed, Apr 10, 2024 at 10:06:28PM +0900, Masami Hiramatsu wrote:
> > On Thu, 4 Apr 2024 12:26:41 -0700
> > Beau Belgrave wrote:
> >
> > > Hello,
> > >
> > > I'm looking into the possibility of capturing user data that is pointed
> > >
On Thu, Apr 11, 2024 at 02:12:59PM +0200, Geert Uytterhoeven wrote:
> Hi Stafford,
>
> On Wed, Apr 10, 2024 at 10:52 PM Stafford Horne wrote:
> > This patch adds the relocations. Note, we use the old naming R_OR32_*
> > instead or the new naming R_OR1K_* to avoid change as this header is
> >
On Thu, 11 Apr 2024 12:20:57 +0200, Marco Elver wrote:
> Add "sched_prepare_exec" tracepoint, which is run right after the point
> of no return but before the current task assumes its new exec identity.
>
> Unlike the tracepoint "sched_process_exec", the "sched_prepare_exec"
> tracepoint runs
Hello.
On Mon, Apr 08, 2024 at 01:29:55PM -0700, Andrew Morton
wrote:
> That seems like a large change.
In what sense is it large?
I tried to lookup the code parts that depend on this default and either
add the other patches or mention the impact (that part could be more
thorough) in the
On Thu, 11 Apr 2024 08:15:05 -0700
Kees Cook wrote:
> This looks good to me. If tracing wants to take it:
>
> Acked-by: Kees Cook
>
> If not, I can take it in my tree if I get a tracing Ack. :)
You can take it.
Acked-by: Steven Rostedt (Google)
-- Steve
On Thu, 11 Apr 2024 23:07:45 +0900, Masami Hiramatsu (Google)
wrote:
> On Thu, 11 Apr 2024 09:19:32 +0200
> Geert Uytterhoeven wrote:
>
> > CC Hiramatsu-san (now for real :-)
>
> Thanks!
>
> >
> > On Thu, Apr 11, 2024 at 6:13 AM Yuntao Wang wrote:
> > > extra_init_args ends with a space,
On Thu, Apr 11, 2024 at 12:20:57PM +0200, Marco Elver wrote:
> Add "sched_prepare_exec" tracepoint, which is run right after the point
> of no return but before the current task assumes its new exec identity.
>
> Unlike the tracepoint "sched_process_exec", the "sched_prepare_exec"
> tracepoint
Lee Jones, 2024-04-11T12:37:26+01:00:
[...]
> > diff --git a/drivers/mfd/88pm886.c b/drivers/mfd/88pm886.c
> > new file mode 100644
> > index ..e06d418a5da9
> > --- /dev/null
> > +++ b/drivers/mfd/88pm886.c
> > @@ -0,0 +1,157 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> >
On Thu, 11 Apr 2024 09:19:32 +0200
Geert Uytterhoeven wrote:
> CC Hiramatsu-san (now for real :-)
Thanks!
>
> On Thu, Apr 11, 2024 at 6:13 AM Yuntao Wang wrote:
> > extra_init_args ends with a space, so when concatenating extra_init_args
> > to saved_command_line, be sure to remove the extra
Hi,
> > Do we have anything that blocks klp-convert-mini to be merged, or something
> > that
> > needs to be fixed?
>
> there is feedback from Petr and I agree with him that a selftest would be
> appropriate.
>
> Lukas, are you planning to send v2 with everything addressed?
Yes, I definitely
On Mon, Apr 08, 2024 at 09:00:06AM -0700, Luis Chamberlain wrote:
> On Mon, Apr 08, 2024 at 10:05:58AM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > The sysfs_create_link() return code is marked as __must_check, but the
> > module_add_driver() function tries hard to not care, by
Hi Stafford,
On Wed, Apr 10, 2024 at 10:52 PM Stafford Horne wrote:
> This patch adds the relocations. Note, we use the old naming R_OR32_*
> instead or the new naming R_OR1K_* to avoid change as this header is
> exported as a user api.
> --- a/arch/openrisc/include/uapi/asm/elf.h
> +++
On 31/03/2024 12:46, Karel Balej wrote:
> Marvell 88PM886 is a PMIC with several subdevices such as onkey,
> regulators or battery and charger. It comes in at least two revisions,
> A0 and A1 -- only A1 is described here at the moment.
>
> Reviewed-by: Krzysztof Kozlowski
> Signed-off-by: Karel
On Sun, 31 Mar 2024, Karel Balej wrote:
> Marvell 88PM886 is a PMIC which provides various functions such as
> onkey, battery, charger and regulators. It is found for instance in the
> samsung,coreprimevelte smartphone with which this was tested. Implement
> basic support to allow for the use of
On 4/11/2024 10:00 AM, Stephen Boyd wrote:
Quoting Duje Mihanović (2024-04-02 13:55:41)
diff --git a/drivers/clk/mmp/clk-of-pxa1908.c b/drivers/clk/mmp/clk-of-pxa1908.c
new file mode 100644
index ..6f1f6e25a718
--- /dev/null
+++ b/drivers/clk/mmp/clk-of-pxa1908.c
@@ -0,0 +1,328 @@
Add "sched_prepare_exec" tracepoint, which is run right after the point
of no return but before the current task assumes its new exec identity.
Unlike the tracepoint "sched_process_exec", the "sched_prepare_exec"
tracepoint runs before flushing the old exec, i.e. while the task still
has the
From: hepeilin
Introduce a tracepoint for icmp_send, which can help users to get more
detail information conveniently when icmp abnormal events happen.
1. Giving an usecase example:
=
When an application experiences packet loss due to an unreachable UDP
destination
The RSS hash report is a feature that's part of the virtio specification.
Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
(still a work in progress as per [1]) support this feature. While the
capability to obtain the RSS hash has been enabled in the normal path,
it's
> > > OK, then I'll push this to for-next at this moment.
> > > Please share if you have a good idea for the batch interface which can be
> > > backported. I guess it should involve updating userspace changes too.
> >
> > Did you (or anyone else) need anything more from me on this one so that it
Quoting Duje Mihanović (2024-04-02 13:55:41)
> diff --git a/drivers/clk/mmp/clk-of-pxa1908.c
> b/drivers/clk/mmp/clk-of-pxa1908.c
> new file mode 100644
> index ..6f1f6e25a718
> --- /dev/null
> +++ b/drivers/clk/mmp/clk-of-pxa1908.c
> @@ -0,0 +1,328 @@
> +// SPDX-License-Identifier:
Quoting Duje Mihanović (2024-04-02 13:55:40)
> Add dt bindings and documentation for the Marvell PXA1908 clock
> controller.
>
> Reviewed-by: Conor Dooley
> Signed-off-by: Duje Mihanović
> ---
Reviewed-by: Stephen Boyd
Quoting Duje Mihanović (2024-04-02 13:55:37)
> From: Andy Shevchenko
>
> The struct mmp_clk_factor_tbl repeats the generic struct u32_fract.
> Kill the custom one and use the generic one instead.
>
> Signed-off-by: Andy Shevchenko
> Tested-by: Duje Mihanović
> Reviewed-by: Linus Walleij
>
Il 11/04/24 09:34, AngeloGioacchino Del Regno ha scritto:
Il 11/04/24 05:37, olivia.wen ha scritto:
Under different applications, the MT8188 SCP can be used as single-core
or dual-core.
Signed-off-by: olivia.wen
---
Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 3 ++-
1 file
Il 11/04/24 05:37, olivia.wen ha scritto:
Under different applications, the MT8188 SCP can be used as single-core
or dual-core.
Signed-off-by: olivia.wen
---
Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Il 11/04/24 05:37, olivia.wen ha scritto:
To Support MT8188 SCP core 1 for ISP driver.
The SCP on different chips will require different code sizes
and IPI buffer sizes based on varying requirements.
Signed-off-by: olivia.wen
---
drivers/remoteproc/mtk_common.h| 5 +--
>> >> >[...]
>> >> >> >I think my understanding based on what Eric depicted differs from =
>you:
>> >> >> >we're supposed to filter out those many invalid cases and only tra=
>ce
>> >> >> >the valid action of sending a icmp, so where to add a new tracepoi=
>nt
>> >> >> >is important instead of
pios = < 140 GPIO_ACTIVE_HIGH>;
+
connector@0 {
compatible = "usb-c-connector";
reg = <0>;
---
base-commit: 65b0418f6e86eef0f62fc053fb3622fbaa3e506e
change-id: 20240411-fp5-usb-c-gpio-afd22741adcd
Best regards,
--
Luca Weiss
On Thu, Apr 11, 2024 at 12:57 PM Peilin He wrote:
>
> >> >[...]
> >> >> >I think my understanding based on what Eric depicted differs from you:
> >> >> >we're supposed to filter out those many invalid cases and only trace
> >> >> >the valid action of sending a icmp, so where to add a new
Hi,
> > Summary of changes in this minimal version
> >
> >
> > - rebase for v6.5
> > - cleaned-up SoB chains (suggested by pmladek)
> > - klp-convert: remove the symbol map auto-resolving solution
> > - klp-convert: add macro for flagging variables inside a LP src to be
On Mon, Apr 8, 2024 at 2:41 PM Jason Wang wrote:
>
> On Mon, Apr 1, 2024 at 11:38 AM Liang Chen wrote:
> >
> > On Thu, Feb 29, 2024 at 4:37 PM Liang Chen
> > wrote:
> > >
> > > On Tue, Feb 27, 2024 at 4:42 AM John Fastabend
> > > wrote:
> > > >
> > > > Jason Wang wrote:
> > > > > On Fri, Feb
On 11/04/2024 05:37, olivia.wen wrote:
> +};
> +
> static const struct of_device_id mtk_scp_of_match[] = {
> { .compatible = "mediatek,mt8183-scp", .data = _of_data },
> { .compatible = "mediatek,mt8186-scp", .data = _of_data },
> @@ -1323,6 +1362,7 @@ static const struct of_device_id
On 11/04/2024 05:37, olivia.wen wrote:
> Under different applications, the MT8188 SCP can be used as single-core
> or dual-core.
>
> Signed-off-by: olivia.wen
Are you sure you use full name, not email login as name?
> ---
> Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 3 ++-
>
99 matches
Mail list logo
