On Thu, Jun 06, 2024 at 06:49:59AM +, Aditya Garg wrote:
> Hi
>
> I am Aditya Garg. I often require using out of tree drivers to support
> various hardwares on Linux.
Just stop buying hardwarew that requires this, or improve and upstream
the drivers to make your life easier instead of
Hi Arnaud,
kernel test robot noticed the following build errors:
[auto build test ERROR on 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0]
url:
https://github.com/intel-lab-lkp/linux/commits/Arnaud-Pouliquen/remoteproc-core-Introduce-rproc_pa_to_va-helper/20240607-183305
base:
Hi Johannes,
kernel test robot noticed the following build warnings:
[auto build test WARNING on mcgrof/modules-next]
[also build test WARNING on arnd-asm-generic/master tip/timers/core net/main
net-next/main linus/master horms-ipvs/master v6.10-rc2 next-20240607]
[If your patch is applied to
Hi Arnaud,
kernel test robot noticed the following build errors:
[auto build test ERROR on 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0]
url:
https://github.com/intel-lab-lkp/linux/commits/Arnaud-Pouliquen/remoteproc-core-Introduce-rproc_pa_to_va-helper/20240607-183305
base:
On 5/11/2024 2:56 PM, Dmitry Baryshkov wrote:
Request in-kernel protection domain mapper to be started before starting
Qualcomm DSP and release it once DSP is stopped. Once all DSPs are
stopped, the PD mapper will be stopped too.
Signed-off-by: Dmitry Baryshkov
---
On 5/11/2024 2:56 PM, Dmitry Baryshkov wrote:
Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if firmware location is changed (or if firmware was
not available at the time pd-mapper was
On Tue, May 28, 2024 at 09:01:10AM -0700, Dave Hansen wrote:
> On 5/17/24 04:06, Dmitrii Kuvaiskii wrote:
> > We wrote a trivial stress test to reproduce the hangs observed in
> > real-world applications. The test stresses #PF-based page allocation and
> > SGX_IOC_ENCLAVE_REMOVE_PAGES flows in the
On 6/3/24 11:42, Haitao Huang wrote:
>> Second, convince me that this _needs_ a new bit. Why can't we just have
>> a bit that effectively means "return EBUSY if you see this bit when
>> handling a fault".
>
> IIUC, reclaimer_writing_to_pcmd() also uses
> SGX_ENCL_PAGE_BEING_RECLAIMED to check if
On Tue, May 28, 2024 at 09:23:13AM -0700, Dave Hansen wrote:
> On 5/17/24 04:06, Dmitrii Kuvaiskii wrote:
> ...
>
> First, why is SGX so special here? How is the SGX problem different
> than what the core mm code does?
Here is my understanding why SGX is so special and why I have to introduce
a
Hi Miroslav,
On Fri, Jun 7, 2024 at 2:07 AM Miroslav Benes wrote:
>
> Hi,
>
> On Tue, 4 Jun 2024, Song Liu wrote:
>
> > On Tue, May 21, 2024 at 1:04 AM Petr Mladek wrote:
> > [...]
> > > >
> > > > Yes, but the information you get is limited compared to what is
> > > > available
> > > > now.
Hi Miroslav,
Thanks for reviewing the patch!
On Fri, Jun 7, 2024 at 6:06 AM Miroslav Benes wrote:
>
> Hi,
>
> On Tue, 4 Jun 2024, Song Liu wrote:
>
> > With CONFIG_LTO_CLANG, the compiler may postfix symbols with .llvm.
> > to avoid symbol duplication. scripts/kallsyms.c sorted the symbols
> >
On Fri, 07 Jun 2024 11:33:24 +0200, Arnaud Pouliquen wrote:
> 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
From: Johannes Berg
The __print_symbolic() could only ever print the core
drop reasons, since that's the way the infrastructure
works. Now that we have __print_sym() with all the
advantages mentioned in that commit, convert to that
and get all the drop reasons from all subsystems. As
we already
From: Johannes Berg
Now that we have drop_reason_lookup(), we can just use it for
drop_monitor as well, rather than exporting the list itself.
Signed-off-by: Johannes Berg
---
v3:
- look up SKB_DROP_REASON_NOT_SPECIFIED if initial lookup
returns NULL, to preserve previous behaviour
---
From: Johannes Berg
The way __print_symbolic() works is limited and inefficient
in multiple ways:
- you can only use it with a static list of symbols, but
e.g. the SKB dropreasons are now a dynamic list
- it builds the list in memory _three_ times, so it takes
a lot of memory:
- The
From: Johannes Berg
Use the new __print_sym() in the timer tracing, just to show
how to convert something. This adds ~80 bytes of .text for a
saving of ~1.5K of data in my builds.
Note the format changes from
print fmt: "success=%d dependency=%s", REC->success,
Before I forget again ...
v2 was:
- rebased on 6.9-rc1
- always search for __print_sym() and get rid of the DYNPRINT flag
and associated code; I think ideally we'll just remove the older
__print_symbolic() entirely
- use ':' as the separator instead of "//" since that makes searching
On Fri, 7 Jun 2024 17:02:28 +0200
Peter Zijlstra wrote:
> > There may be following resolutions:
>
> Oh gawd, sodding weak functions again.
>
> I would suggest changing scipts/kallsyms.c to emit readily identifiable
> symbol names for all the weak junk, eg:
>
> __weak_junk_N
>
> That
On Fri, Jun 07, 2024 at 09:32:26AM +0200, Krzysztof Kozlowski wrote:
> On 06/06/2024 17:00, Frank Li wrote:
> > "fsl,imx8qxp-cm4" and "fsl,imx8qm-cm4" need minimum 2 power domains. Keep
> > the same restriction for other compatible string.
> >
> > Signed-off-by: Frank Li
> > ---
> >
> > Notes:
On Fri, Jun 07, 2024 at 07:52:11PM +0800, Zheng Yejian wrote:
> ftrace_location() was changed to not only return the __fentry__ location
> when called for the __fentry__ location, but also when called for the
> sym+0 location after commit aebfd12521d9 ("x86/ibt,ftrace: Search for
> __fentry__
On 6/6/24 9:37 AM, Yan Zhai wrote:
> # cat /sys/kernel/debug/tracing/events/skb/kfree_skb/format
> name: kfree_skb
> ID: 2260
> format:
> field:unsigned short common_type; offset:0;
> size:2; signed:0;
> field:unsigned char common_flags; offset:2;
> size:1; signed:0;
>
On Sun, Apr 28, 2024 at 05:53:37PM GMT, Jonathan Cameron wrote:
> On Tue, 23 Apr 2024 18:33:05 -0400
> Aren Moynihan wrote:
>
> > From: Ondrej Jirman
> >
> > VDD power input can be used to completely power off the chip during
> > system suspend. Do so if available.
> >
> > Signed-off-by:
On Thu, 06 Jun 2024 20:53:11 -0500, chenridong
wrote:
I think it is better when _misc_cg_res_alloc fails, it just calls
_misc_cg_res_free(cg, index)(add index parameter, it means ending of
iterator), so it can avoid calling ->free() that do not call ->alloc().
And in misc_cg_free, just
Hello RT-list!
I'm pleased to announce the 4.19.315-rt135 stable release.
This is just an update to the v4.19.315 stable release, not RT specifc changes.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v4.19-rt
From: "Steven Rostedt (Google)"
When CONFIG_DYNAMIC_FTRACE is not set, the function
fgraph_update_pid_func() doesn't do anything. Currently, most of its logic
is within a "#ifdef CONFIG_DYNAMIC_FTRACE" block, but its variables were
declared outside that, and when DYNAMIC_FTRACE is not set, it
Hi Johannes,
kernel test robot noticed the following build errors:
[auto build test ERROR on mcgrof/modules-next]
[also build test ERROR on arnd-asm-generic/master tip/timers/core net/main
net-next/main linus/master horms-ipvs/master v6.10-rc2 next-20240607]
[If your patch is applied to the
Hi Johannes,
kernel test robot noticed the following build errors:
[auto build test ERROR on mcgrof/modules-next]
[also build test ERROR on arnd-asm-generic/master tip/timers/core net/main
net-next/main linus/master horms-ipvs/master v6.10-rc2 next-20240607]
[If your patch is applied to the
On bpf syscall map operations the bpf_disable_instrumentation function
is called for the reason described in the comment to the function.
The description matches the bug case. The function increments a per CPU
integer variable bpf_prog_active. The variable is not processed in the
bpf trace path.
Hi,
On Tue, 4 Jun 2024, Song Liu wrote:
> With CONFIG_LTO_CLANG, the compiler may postfix symbols with .llvm.
> to avoid symbol duplication. scripts/kallsyms.c sorted the symbols
> without these postfixes. The default symbol lookup also removes these
> postfixes before comparing symbols.
>
> On
Use appropriate frag_page API instead of caller accessing
'page_frag_cache' directly.
CC: Alexander Duyck
Signed-off-by: Yunsheng Lin
---
drivers/vhost/net.c | 2 +-
include/linux/page_frag_cache.h | 10 ++
mm/page_frag_test.c | 2 +-
net/core/skbuff.c
Currently the page_frag API is returning 'virtual address'
or 'va' when allocing and expecting 'virtual address' or
'va' as input when freeing.
As we are about to support new use cases that the caller
need to deal with 'struct page' or need to deal with both
'va' and 'struct page'. In order to
On Thu, Jun 06, 2024 at 09:01:36PM +0200, Luca Weiss wrote:
> When the mailbox driver has not probed yet, the error message "failed to
> parse smd edge" is just going to confuse users, so improve the error
> prints a bit.
>
> Cover the last remaining exits from qcom_smd_parse_edge with proper
>
ftrace_location() was changed to not only return the __fentry__ location
when called for the __fentry__ location, but also when called for the
sym+0 location after commit aebfd12521d9 ("x86/ibt,ftrace: Search for
__fentry__ location"). That is, if sym+0 location is not __fentry__,
On Fri, Jun 7, 2024 at 12:52 PM Peter Zijlstra wrote:
>
> I'm sorry, but 30+ years of reading ! as NOT (or factorial) isn't going
> to go away. So I'm reading your macros do NOT rule.
It makes it clear what is macro call or not. They could have gone for
UPPERCASE names (for instance), yes. On
On Fri, Jun 07, 2024 at 09:43:29AM +, Alice Ryhl wrote:
> Peter Zijlstra wrote:
> > On Thu, Jun 06, 2024 at 09:09:00PM +0200, Miguel Ojeda wrote:
> > > On Thu, Jun 6, 2024 at 7:19 PM Peter Zijlstra
> > > wrote:
> > > >
> > > > This is absolutely unreadable gibberish -- how am I supposed to
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 in the secure part.
This firmware could be authenticated by the secure trusted
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
When a resource table is loaded by an external entity such as U-boot or
OP-TEE, We not necessary 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
---
Main updates from the previous version [1][2]:
--
1) Rework resource table management
- Rework tee_rproc_parse_fw to temporary map the resource table address
to create a cached_table (similar to what is done in
rproc_elf_load_rsc_table()).
-
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
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
Peter Zijlstra wrote:
> On Thu, Jun 06, 2024 at 09:09:00PM +0200, Miguel Ojeda wrote:
> > On Thu, Jun 6, 2024 at 7:19 PM Peter Zijlstra wrote:
> > >
> > > This is absolutely unreadable gibberish -- how am I supposed to keep
> > > this in sync with the rest of the static_call infrastructure?
> >
Hi,
On Tue, 4 Jun 2024, Song Liu wrote:
> On Tue, May 21, 2024 at 1:04 AM Petr Mladek wrote:
> [...]
> > >
> > > Yes, but the information you get is limited compared to what is available
> > > now. You would obtain the information that a patched function was called
> > > but ftrace could also
Added kernel-doc comments for the unregister_ftrace_direct() function to
improve code documentation and readability.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9300
Signed-off-by: Yang Li
---
kernel/trace/ftrace.c | 2 ++
1 file changed, 2 insertions(+)
Added kernel-doc comments for the ftrace_graph_ret_addr() function to
improve code documentation and readability.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9299
Signed-off-by: Yang Li
---
kernel/trace/fgraph.c | 6 ++
1 file changed, 6 insertions(+)
On 5/28/24 01:43, Steven Rostedt wrote:
> On Mon, 27 May 2024 11:36:55 +0200
> Petr Pavlu wrote:
>
static void rb_check_pages(struct ring_buffer_per_cpu *cpu_buffer)
{
@@ -2200,8 +2205,13 @@ int ring_buffer_resize(struct trace_buffer *buffer,
unsigned long size,
Hi,
On Fri, 31 May 2024, Joe Lawrence wrote:
> On 5/31/24 07:23, Miroslav Benes wrote:
> > Hi,
> >
> > On Tue, 21 Jul 2020, Joe Lawrence wrote:
> >
> >> In light of [PATCH] Revert "kbuild: use -flive-patching when
> >> CONFIG_LIVEPATCH is enabled" [1], we should add some loud disclaimers
> >>
On 06/06/2024 17:00, Frank Li wrote:
> "fsl,imx8qxp-cm4" and "fsl,imx8qm-cm4" need minimum 2 power domains. Keep
> the same restriction for other compatible string.
>
> Signed-off-by: Frank Li
> ---
>
> Notes:
> Change from v1 to v2
> - set minitem to 2 at top
> - Add imx8qm
On 06/06/2024 21:18, Luca Weiss wrote:
> The qcom,ipc-N properties are essentially providing a reference to a
> mailbox, so allow using the mboxes property to do the same in a more
> structured way.
>
> Since multiple SMSM hosts are supported, we need to be able to provide
> the correct mailbox
On 6/6/2024 8:19 PM, Krzysztof Kozlowski wrote:
On 06/06/2024 16:38, Naina Mehta wrote:
Document the MPSS Peripheral Authentication Service on SDX75 platform.
Signed-off-by: Naina Mehta
---
.../devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml | 1 +
1 file changed, 1
Hi Denis,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.10-rc2 next-20240607]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as
On 6/6/2024 8:20 PM, Krzysztof Kozlowski wrote:
On 06/06/2024 16:38, Naina Mehta wrote:
The qlink_logging memory region is also used by the modem firmware,
add it to reserved memory regions.
Also split MPSS DSM region into 2 separate regions.
Signed-off-by: Naina Mehta
---
On 07/06/2024 00:49, Ira Weiny wrote:
> Li Zhijian wrote:
>> Don't allocate devs again when it's valid pointer which has pionted to
>> the memory allocated above with size (count + 2 * sizeof(dev)).
>>
>> A kmemleak reports:
>> unreferenced object 0x88800dda1980 (size 16):
>>comm
> On Jun 6, 2024, at 23:01, Joe Lawrence wrote:
>
> Hi Wardenjohn,
>
> To follow up, Red Hat kpatch QE pointed me toward this test:
>
> https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/tree/main/general/kpatch/kpatch-trace?ref_type=heads
>
> which reports a few
On 07/06/2024 00:27, Dave Jiang wrote:
>
>
> On 6/3/24 8:16 PM, Li Zhijian wrote:
>> Don't allocate devs again when it's valid pointer which has pionted to
>> the memory allocated above with size (count + 2 * sizeof(dev)).
>>
>> A kmemleak reports:
>> unreferenced object 0x88800dda1980
I think it is better when _misc_cg_res_alloc fails, it just calls
_misc_cg_res_free(cg, index)(add index parameter, it means ending of
iterator), so it can avoid calling ->free() that do not call ->alloc().
And in misc_cg_free, just call _misc_cg_res_free(cg, MISC_CG_RES_TYPES)
to free all.
On Thu, Jun 06, 2024 at 09:29:51PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2024 at 12:00:36PM -0700, Boqun Feng wrote:
> > On Thu, Jun 06, 2024 at 07:35:44PM +0200, Peter Zijlstra wrote:
> > > On Thu, Jun 06, 2024 at 08:49:06AM -0700, Boqun Feng wrote:
> > >
> > > > Long-term plan is to 1)
Memory management folks. Please review this patch.
Specifically the "map_pages()" function below.
On Thu, 06 Jun 2024 17:17:43 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Add an option to the trace_instance kernel command line parameter that
> allows it to use the
From: "Steven Rostedt (Google)"
If an instance is mapped to memory on boot up, create a new file called
"last_boot_info" that will hold information that can be used to properly
parse the raw data in the ring buffer.
It will export the delta of the addresses for text and data from what it
was
From: "Steven Rostedt (Google)"
The addresses of a stack trace event are relative to the kallsyms. As that
can change between boots, when printing the stack trace from a buffer that
was from the last boot, it needs all the addresses to be added to the
"text_delta" that gives the delta between
From: "Steven Rostedt (Google)"
When a ring buffer is mapped to a specific address, save the address of a
text function and some data. This will be used to determine the delta
between the last boot and the current boot for pointers to functions as
well as to data.
Signed-off-by: Steven Rostedt
From: "Steven Rostedt (Google)"
For a persistent ring buffer that is saved across boots, if function
tracing was performed in the previous boot, it only saves the address of
the functions and uses "%pS" to print their names. But the current boot,
those functions may be in different locations.
From: "Steven Rostedt (Google)"
Use the saved text_delta and data_delta of a persistent memory mapped ring
buffer that was saved from a previous boot, and use the delta in the trace
event print output so that strings and functions show up normally.
That is, for an event like trace_kmalloc()
From: "Steven Rostedt (Google)"
Add an option to the trace_instance kernel command line parameter that
allows it to use the reserved memory from memmap boot parameter.
memmap=12M$0x28450 trace_instance=boot_mapped@0x28450:12M
The above will reserves 12 megs at the physical address
From: "Steven Rostedt (Google)"
Make sure all the events in each of the sub-buffers that were mapped in a
memory region are valid. This moves the code that walks the buffers for
time-stamp validation out of the CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS
ifdef block and is used to validate the
From: "Steven Rostedt (Google)"
Add a buffer_meta per-cpu file for the trace instance that is mapped to
boot memory. This shows the current meta-data and can be used by user
space tools to record off the current mappings to help reconstruct the
ring buffer after a reboot.
It does not expose any
From: "Steven Rostedt (Google)"
Add a test against the ring buffer memory range to see if it has valid
data. The ring_buffer_meta structure is given a new field called
"first_buffer" which holds the address of the first sub-buffer. This is
used to both determine if the other fields are valid as
From: "Steven Rostedt (Google)"
Populate the ring_buffer_meta array. It holds the pointer to the
head_buffer (next to read), the commit_buffer (next to write) the size of
the sub-buffers, number of sub-buffers and an array that keeps track of
the order of the sub-buffers.
This information will
From: "Steven Rostedt (Google)"
Allow for creating a new instance by passing in an address and size to map
the ring buffer for the instance to.
This will allow features like a pstore memory mapped region to be used for
an tracing instance ring buffer that can be retrieved from one boot to the
This is a way to map a ring buffer instance across reboots.
The requirement is that you have a memory region that is not erased.
I tested this on a Debian VM running on qemu on a Debian server,
and even tested it on a baremetal box running Fedora. I was
surprised that it worked on the baremetal
From: "Steven Rostedt (Google)"
In preparation to allowing the trace ring buffer to be allocated in a
range of memory that is persistent across reboots, add
ring_buffer_alloc_range(). It takes a contiguous range of memory and will
split it up evenly for the per CPU ring buffers.
If there's not
From: "Steven Rostedt (Google)"
In preparation for having the ring buffer mapped to a dedicated location,
which will have the same restrictions as user space memory mapped buffers,
allow it to use the "mapped" field of the ring_buffer_per_cpu structure
without having the user space meta page
On Wed, Jun 05, 2024 at 12:45:17PM -0500, Tanmay Shah wrote:
>
>
> On 6/4/24 10:34 AM, Mathieu Poirier wrote:
>
> Hi Mathieu,
>
> Thanks for reviews.
> Please find my comments below.
>
> > Hi Tanmay,
> >
> > On Mon, Jun 03, 2024 at 01:34:38PM -0700, Tanmay Shah wrote:
> >> It is possible
On Wed, 5 Jun 2024 at 11:47, Tanmay Shah wrote:
>
>
>
> On 6/4/24 3:23 PM, Bjorn Andersson wrote:
> > On Mon, Jun 03, 2024 at 01:34:38PM -0700, Tanmay Shah wrote:
> >> It is possible that remote processor is already running before
> >> linux boot or remoteproc platform driver probe. Implement
From: Johannes Berg
Now that we have drop_reason_lookup(), we can just use it for
drop_monitor as well, rather than exporting the list itself.
Signed-off-by: Johannes Berg
---
v3:
- look up SKB_DROP_REASON_NOT_SPECIFIED if initial lookup
returns NULL, to preserve previous behaviour
---
From: Johannes Berg
The way __print_symbolic() works is limited and inefficient
in multiple ways:
- you can only use it with a static list of symbols, but
e.g. the SKB dropreasons are now a dynamic list
- it builds the list in memory _three_ times, so it takes
a lot of memory:
- The
From: Johannes Berg
The __print_symbolic() could only ever print the core
drop reasons, since that's the way the infrastructure
works. Now that we have __print_sym() with all the
advantages mentioned in that commit, convert to that
and get all the drop reasons from all subsystems. As
we already
Completely forgot about this again ... here's another respin.
v2 was:
- rebased on 6.9-rc1
- always search for __print_sym() and get rid of the DYNPRINT flag
and associated code; I think ideally we'll just remove the older
__print_symbolic() entirely
- use ':' as the separator instead of
From: Johannes Berg
Use the new __print_sym() in the timer tracing, just to show
how to convert something. This adds ~80 bytes of .text for a
saving of ~1.5K of data in my builds.
Note the format changes from
print fmt: "success=%d dependency=%s", REC->success,
On Thu, Jun 06, 2024 at 09:09:00PM +0200, Miguel Ojeda wrote:
> On Thu, Jun 6, 2024 at 7:19 PM Peter Zijlstra wrote:
> >
> > This is absolutely unreadable gibberish -- how am I supposed to keep
> > this in sync with the rest of the static_call infrastructure?
>
> Yeah, they are macros, which
On Thu, Jun 06, 2024 at 12:00:36PM -0700, Boqun Feng wrote:
> On Thu, Jun 06, 2024 at 07:35:44PM +0200, Peter Zijlstra wrote:
> > On Thu, Jun 06, 2024 at 08:49:06AM -0700, Boqun Feng wrote:
> >
> > > Long-term plan is to 1) compile the C helpers in some IR and 2) inline
> > > the helpers with
Take a shot at converting the last driver that requires direct
"qcom,ipc*" syscon references in devicetree by allowing the smsm driver
to use the mailbox interface to achieve the same effect.
Still not sure if the devicetree bindings are the prettiest but they're
functional.
One alternative I'm
Add support for using the mbox interface instead of manually writing to
the syscon. With this change the driver will attempt to get the mailbox
first, and if that fails it will fall back to the existing way of using
qcom,ipc-* properties and converting to syscon.
Reviewed-by: Konrad Dybcio
The qcom,ipc-N properties are essentially providing a reference to a
mailbox, so allow using the mboxes property to do the same in a more
structured way.
Since multiple SMSM hosts are supported, we need to be able to provide
the correct mailbox for each host. The old qcom,ipc-N properties map to
On Thu, Jun 06, 2024 at 12:50:56PM +0200, AngeloGioacchino Del Regno wrote:
> Il 05/06/24 21:35, Nícolas F. R. A. Prado ha scritto:
> > The scp_get() helper has two users: the mtk-vcodec and the mtk-mdp3
> > drivers. mdp3 considers the mediatek,scp phandle optional, and when it's
> > missing mdp3
On Thu, Jun 6, 2024 at 7:19 PM Peter Zijlstra wrote:
>
> This is absolutely unreadable gibberish -- how am I supposed to keep
> this in sync with the rest of the static_call infrastructure?
Yeah, they are macros, which look different from "normal" Rust code.
Is there something we could do to
On Tue, May 21, 2024 at 01:53:27AM +0900, Masahiro Yamada wrote:
> On Fri, May 17, 2024 at 1:31???PM Kris Van Hees
> wrote:
> >
> > The offset range data for builtin modules is generated using:
> > - modules.builtin.modinfo: associates object files with module names
> > - vmlinux.map: provides
When the mailbox driver has not probed yet, the error message "failed to
parse smd edge" is just going to confuse users, so improve the error
prints a bit.
Cover the last remaining exits from qcom_smd_parse_edge with proper
error prints, especially the one for the mbox_chan deserved
dev_err_probe
On Thu, Jun 06, 2024 at 07:35:44PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2024 at 08:49:06AM -0700, Boqun Feng wrote:
>
> > Long-term plan is to 1) compile the C helpers in some IR and 2) inline
> > the helpers with Rust in IR-level, as what Gary has:
> >
> >
> >
On Thu, 6 Jun 2024 18:53:12 +0100
Mark Rutland wrote:
> On Wed, Jun 05, 2024 at 02:03:36PM -0400, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > While adding comments to the function __ftrace_hash_rec_update() and
> > trying to describe in detail what the parameter for
On Wed, Jun 05, 2024 at 02:03:39PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Describe what ftrace_hash_move() does and add some more comments to some
> other functions to make it easier to understand.
>
> Signed-off-by: Steven Rostedt (Google)
Acked-by: Mark Rutland
On Wed, Jun 05, 2024 at 02:03:38PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The parameter "inc" in the function ftrace_hash_rec_update_modify() is
> boolean. Change it to be such.
>
> Also add documentation to what the function does.
>
> Signed-off-by: Steven Rostedt
On Wed, Jun 05, 2024 at 02:03:36PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> While adding comments to the function __ftrace_hash_rec_update() and
> trying to describe in detail what the parameter for "ftrace_hash" does, I
> realized that it basically does exactly the
On Thu, Jun 06, 2024 at 08:49:06AM -0700, Boqun Feng wrote:
> Long-term plan is to 1) compile the C helpers in some IR and 2) inline
> the helpers with Rust in IR-level, as what Gary has:
>
>
> https://lore.kernel.org/rust-for-linux/20240529202817.3641974-1-g...@garyguo.net/
Urgh, that
On Thu, Jun 06, 2024 at 03:05:26PM +, 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 Thu, Jun 06, 2024 at 03:05:25PM +, Alice Ryhl wrote:
> 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.
Urgh, more unreadable gibberish :-(
Can
On Thu, Jun 06, 2024 at 03:05:24PM +, Alice Ryhl wrote:
> Add static_call support by mirroring how C does. When the platform does
> not support static calls (right now, that means that it is not x86),
> then the function pointer is loaded from a global and called. Otherwise,
> we generate a
Li Zhijian wrote:
> Don't allocate devs again when it's valid pointer which has pionted to
> the memory allocated above with size (count + 2 * sizeof(dev)).
>
> A kmemleak reports:
> unreferenced object 0x88800dda1980 (size 16):
> comm "kworker/u10:5", pid 69, jiffies 4294671781
> hex
On Thu, Jun 6, 2024 at 9:46 AM Jiri Olsa wrote:
>
> On Wed, Jun 05, 2024 at 10:50:11PM +0200, Jiri Olsa wrote:
> > On Wed, Jun 05, 2024 at 07:56:19PM +0200, Oleg Nesterov wrote:
> > > On 06/05, Andrii Nakryiko wrote:
> > > >
> > > > so any such
> > > > limitations will cause problems, issue
On Wed, Jun 05, 2024 at 10:50:11PM +0200, Jiri Olsa wrote:
> On Wed, Jun 05, 2024 at 07:56:19PM +0200, Oleg Nesterov wrote:
> > On 06/05, Andrii Nakryiko wrote:
> > >
> > > so any such
> > > limitations will cause problems, issue reports, investigation, etc.
> >
> > Agreed...
> >
> > > As one
1 - 100 of 4333181 matches
Mail list logo
