Re: [PATCH -fixes] riscv: Fix ftrace syscall handling which are now prefixed with __riscv_

[Björn Töpel]

Alexandre Ghiti  writes:

> ftrace creates entries for each syscall in the tracefs but has failed
> since commit 08d0ce30e0e4 ("riscv: Implement syscall wrappers") which
> prefixes all riscv syscalls with __riscv_.
>
> So fix this by implementing arch_syscall_match_sym_name() which allows us
> to ignore this prefix.
>
> And also ignore compat syscalls like x86/arm64 by implementing
> arch_trace_is_compat_syscall().
>
> Fixes: 08d0ce30e0e4 ("riscv: Implement syscall wrappers")
> Signed-off-by: Alexandre Ghiti 

This fix does the BPF test suite happier!

Tested-by: Björn Töpel 

Re: [PATCH -fixes] riscv: Fix ftrace syscall handling which are now prefixed with __riscv_

[Björn Töpel]

Alexandre Ghiti  writes:

> @Conor Dooley This fails checkpatch but the documentation here states
> that this is how to do:
> https://elixir.bootlin.com/linux/latest/source/Documentation/trace/ftrace-design.rst#L246

FWIW, I'll relax the PW CI checkpatch test going forward. It's way too
strict...

Re: [PATCH v4 2/2] dax/kmem: allow kmem to add memory with memmap_on_memory

[Aneesh Kumar K V]

On 10/4/23 5:18 AM, Verma, Vishal L wrote:
> On Tue, 2023-10-03 at 09:34 +0530, Aneesh Kumar K V wrote:
>> On 9/29/23 2:00 AM, Vishal Verma wrote:
>>> Large amounts of memory managed by the kmem driver may come in via CXL,
>>> and it is often desirable to have the memmap for this memory on the new
>>> memory itself.
>>>
>>> Enroll kmem-managed memory for memmap_on_memory semantics if the dax
>>> region originates via CXL. For non-CXL dax regions, retain the existing
>>> default behavior of hot adding without memmap_on_memory semantics.
>>>
>>
>> Are we not looking at doing altmap space for CXL DAX regions? Last 
>> discussion around
>> this was suggesting we look at doing this via altmap reservation so that
>> we get contigous space for device memory enabling us to map them
>> via 1G direct mapping entries? 
>>
> Hey Aneesh - was this on a previous posting or something - do you have
> a link so I can refresh myself on what the discussion was?
> 
> If it is enabling something in CXL similar to the --map=mem mode for
> pmem + device dax, that could be incremental to this.

Yes. Agree that we can do that incremental to this. 

https://lore.kernel.org/linux-mm/b6753402-2de9-25b2-36e9-eacd49752...@redhat.com

-aneesh

Re: [PATCH v2] trace: tracing_event_filter: fast path when no subsystem filters

[Steven Rostedt]

On Mon,  2 Oct 2023 10:41:48 -0400
Nicholas Lowell  wrote:

> @@ -2411,7 +2418,12 @@ int apply_subsystem_event_filter(struct 
> trace_subsystem_dir *dir,
>   }
>  
>   if (!strcmp(strstrip(filter_string), "0")) {
> - filter_free_subsystem_preds(dir, tr);
> + /* If nothing was freed, we do not need to sync */
> + if (!filter_free_subsystem_preds(dir, tr)) {
> + if(!(WARN_ON_ONCE(system->filter)))
> + goto out_unlock;
> + }
> +
>   remove_filter_string(system->filter);
>   filter = system->filter;
>   system->filter = NULL;
> -- 

This is why I asked for the warning:

trace-cmd record -o /tmp/trace.dat -e sched -f "(common_pid == $$) || 
((common_pid > 10) && common_pid < 100) || (common_pid >= 1000 && common_pid <= 
1050) || (common_pid > 1 && common_pid < 2)" sleep 5


Causes:

[ cut here ]
 WARNING: CPU: 5 PID: 944 at kernel/trace/trace_events_filter.c:2423 
apply_subsystem_event_filter+0x18c/0x5e0
 Modules linked in:
 CPU: 5 PID: 944 Comm: trace-cmd Not tainted 6.6.0-rc4-test-9-gff7cd7446fe5 
#102
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.16.2-debian-1.16.2-1 04/01/2014
 RIP: 0010:apply_subsystem_event_filter+0x18c/0x5e0
 Code: 44 24 08 00 00 00 00 48 8b 6d 00 4c 39 f5 75 bc 48 8b 44 24 18 4c 8b 60 
18 4c 89 e5 45 84 ff 75 14 48 85 ed 0f 84 37 ff ff ff <0f> 0b eb 10 e8 4b be fd 
ff eb b0 4d 85 e4 0f 84 a3 02 00 00 48 8b
 RSP: 0018:9b4941607db8 EFLAGS: 00010286
 RAX: 8b2780a77280 RBX: 8b2780a77400 RCX: 
 RDX:  RSI: 8b2781c11c38 RDI: 8b2781c11c38
 RBP: 8b28df449030 R08: 8b2781c11c38 R09: 
 R10: 8b2781c11c38 R11:  R12: 8b28df449030
 R13: aaf64de0 R14: aaf66bb8 R15: 
 FS:  7fd221def3c0() GS:8b28f7d4() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 56117c93e160 CR3: 00010173a003 CR4: 00170ee0
 Call Trace:
  
  ? apply_subsystem_event_filter+0x18c/0x5e0
  ? __warn+0x81/0x130
  ? apply_subsystem_event_filter+0x18c/0x5e0
  ? report_bug+0x191/0x1c0
  ? handle_bug+0x3c/0x80
  ? exc_invalid_op+0x17/0x70
  ? asm_exc_invalid_op+0x1a/0x20
  ? apply_subsystem_event_filter+0x18c/0x5e0
  ? apply_subsystem_event_filter+0x5b/0x5e0
  ? __check_object_size+0x25b/0x2c0
  subsystem_filter_write+0x41/0x70
  vfs_write+0xf2/0x440
  ? kmem_cache_free+0x22/0x350
  ksys_write+0x6f/0xf0
  do_syscall_64+0x3f/0xc0
  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
 RIP: 0033:0x7fd221ee7ae0

-- Steve

Re: [RFC PATCH] tracing: change syscall number type in struct syscall_trace_*

[Steven Rostedt]

On Mon,  2 Oct 2023 15:52:42 +0200
Artem Savkov  wrote:

> linux-rt-devel tree contains a patch that adds an extra member to struct
> trace_entry. This causes the offset of args field in struct
> trace_event_raw_sys_enter be different from the one in struct
> syscall_trace_enter:

This patch looks like it's fixing the symptom and not the issue. No code
should rely on the two event structures to be related. That's an unwanted
coupling, that will likely cause issues down the road (like the RT patch
you mentioned).


> 
> struct trace_event_raw_sys_enter {
> struct trace_entry ent;  /* 012 */
> 
> /* XXX last struct has 3 bytes of padding */
> /* XXX 4 bytes hole, try to pack */
> 
> long int   id;   /*16 8 */
> long unsigned int  args[6];  /*2448 */
> /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
> char   __data[]; /*72 0 */
> 
> /* size: 72, cachelines: 2, members: 4 */
> /* sum members: 68, holes: 1, sum holes: 4 */
> /* paddings: 1, sum paddings: 3 */
> /* last cacheline: 8 bytes */
> };
> 
> struct syscall_trace_enter {
> struct trace_entry ent;  /* 012 */
> 
> /* XXX last struct has 3 bytes of padding */
> 
> intnr;   /*12 4 */
> long unsigned int  args[];   /*16 0 */
> 
> /* size: 16, cachelines: 1, members: 3 */
> /* paddings: 1, sum paddings: 3 */
> /* last cacheline: 16 bytes */
> };
> 
> This, in turn, causes perf_event_set_bpf_prog() fail while running bpf
> test_profiler testcase because max_ctx_offset is calculated based on the
> former struct, while off on the latter:

The above appears to be pointing to the real bug. The "is calculated based
on the former struct while off on the latter" Why are the two being used
together? They are supposed to be *unrelated*!


> 
>   10488 if (is_tracepoint || is_syscall_tp) {
>   10489 int off = trace_event_get_offsets(event->tp_event);

So basically this is clumping together the raw_syscalls with the syscalls
events as if they are the same. But the are not. They are created
differently. It's basically like using one structure to get the offsets of
another structure. That would be a bug anyplace else in the kernel. Sounds
like it's a bug here too.

I think the issue is with this code, not the tracing code.

We could expose the struct syscall_trace_enter and syscall_trace_exit if
the offsets to those are needed.

-- Steve


>   10490
>   10491 if (prog->aux->max_ctx_offset > off)
>   10492 return -EACCES;
>   10493 }
> 
> This patch changes the type of nr member in syscall_trace_* structs to
> be long so that "args" offset is equal to that in struct
> trace_event_raw_sys_enter.
> 

Re: [PATCH -fixes] riscv: Fix ftrace syscall handling which are now prefixed with __riscv_

[Google]

On Tue,  3 Oct 2023 20:24:07 +0200
Alexandre Ghiti  wrote:

> ftrace creates entries for each syscall in the tracefs but has failed
> since commit 08d0ce30e0e4 ("riscv: Implement syscall wrappers") which
> prefixes all riscv syscalls with __riscv_.
> 
> So fix this by implementing arch_syscall_match_sym_name() which allows us
> to ignore this prefix.
> 
> And also ignore compat syscalls like x86/arm64 by implementing
> arch_trace_is_compat_syscall().
> 

Looks good to me,

Acked-by: Masami Hiramatsu (Google) 

Thank you,

> Fixes: 08d0ce30e0e4 ("riscv: Implement syscall wrappers")
> Signed-off-by: Alexandre Ghiti 
> ---
>  arch/riscv/include/asm/ftrace.h | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
> index 740a979171e5..2b2f5df7ef2c 100644
> --- a/arch/riscv/include/asm/ftrace.h
> +++ b/arch/riscv/include/asm/ftrace.h
> @@ -31,6 +31,27 @@ static inline unsigned long ftrace_call_adjust(unsigned 
> long addr)
>   return addr;
>  }
>  
> +/*
> + * Let's do like x86/arm64 and ignore the compat syscalls.
> + */
> +#define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
> +static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
> +{
> + return is_compat_task();
> +}
> +
> +#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> +static inline bool arch_syscall_match_sym_name(const char *sym,
> +const char *name)
> +{
> + /*
> +  * Since all syscall functions have __riscv_ prefix, we must skip it.
> +  * However, as we described above, we decided to ignore compat
> +  * syscalls, so we don't care about __riscv_compat_ prefix here.
> +  */
> + return !strcmp(sym + 8, name);
> +}
> +
>  struct dyn_arch_ftrace {
>  };
>  #endif
> -- 
> 2.39.2
> 


-- 
Masami Hiramatsu (Google) 

Re: [PATCH V3] tracing/timerlat: Hotplug support for the user-space interface

[Steven Rostedt]

On Fri, 29 Sep 2023 17:02:46 +0200
Daniel Bristot de Oliveira  wrote:

> The osnoise/per_cpu/CPU$/timerlat_fd is create for each possible
> CPU, but it might create confusion if the CPU is not online.
> 
> Create the file only for online CPUs, also follow hotplug by
> creating and deleting as CPUs come and go.
> 
> Fixes: e88ed227f639 ("tracing/timerlat: Add user-space interface")

Is this a fix that needs to go in now and Cc'd to stable? Or is this
something that can wait till the next merge window?

-- Steve


> Signed-off-by: Daniel Bristot de Oliveira 
> ---
> 
> Changes from V2:
>   - Better split the code into the generic (per_cpu/cpu$)
> and timerlat (/timerlat_fd) specific function (Daniel)
>   - Fixed a cpus_read_lock/unlock() usage (kbuild test)
>   Link: 
> https://lore.kernel.org/lkml/6b9a5f306e488bc77bf8521faeade420a0adf3e4.1695224204.git.bris...@kernel.org/
> 
> Changes from V1:
>   - Fix compilation issue when !HOTPLUG
>   - Fix init interface | hotplug race
>   Link: 
> https://lore.kernel.org/lkml/b619d9fd08a3bb47018cf40afa95783844a3c1fd.1694789910.git.bris...@kernel.org/
> 
>  kernel/trace/trace_osnoise.c | 149 ---
>  1 file changed, 121 insertions(+), 28 deletions(-)
> 
>

Re: [PATCH RESEND v2 1/2] mm/damon/core: add a tracepoint for damos apply target regions

[Steven Rostedt]

On Wed, 13 Sep 2023 02:20:49 +
SeongJae Park  wrote:

> DAMON provides damon_aggregated tracepoint, which exposes details of
> each region and its access monitoring results.  It is useful for
> getting whole monitoring results, e.g., for recording purposes.
> 
> For investigations of DAMOS, DAMON Sysfs interface provides DAMOS
> statistics and tried_regions directory.  But, those provides only
> statistics and snapshots.  If the scheme is frequently applied and if
> the user needs to know every detail of DAMOS behavior, the
> snapshot-based interface could be insufficient and expensive.
> 
> As a last resort, userspace users need to record the all monitoring
> results via damon_aggregated tracepoint and simulate how DAMOS would
> worked.  It is unnecessarily complicated.  DAMON kernel API users,
> meanwhile, can do that easily via before_damos_apply() callback field of
> 'struct damon_callback', though.
> 
> Add a tracepoint that will be called just after before_damos_apply()
> callback for more convenient investigations of DAMOS.  The tracepoint
> exposes all details about each regions, similar to damon_aggregated
> tracepoint.
> 
> Please note that DAMOS is currently not only for memory management but
> also for query-like efficient monitoring results retrievals (when 'stat'
> action is used).  Until now, only statistics or snapshots were
> supported.  Addition of this tracepoint allows efficient full recording
> of DAMOS-based filtered monitoring results.
> 

From a tracing point of view.

Reviewed-by: Steven Rostedt (Google) 

-- Steve

Re: [PATCH v3 03/13] mm/execmem, arch: convert simple overrides of module_alloc to execmem

[Edgecombe, Rick P]

On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> +
> +static void execmem_init_missing(struct execmem_params *p)
> +{
> +   struct execmem_range *default_range = 
> >ranges[EXECMEM_DEFAULT];
> +
> +   for (int i = EXECMEM_DEFAULT + 1; i < EXECMEM_TYPE_MAX; i++)
> {
> +   struct execmem_range *r = >ranges[i];
> +
> +   if (!r->start) {
> +   r->pgprot = default_range->pgprot;
> +   r->alignment = default_range->alignment;
> +   r->start = default_range->start;
> +   r->end = default_range->end;
> +   }
> +   }
> +}
> +

It seems a bit weird to copy all of this. Is it trying to be faster or
something?

Couldn't it just check r->start in execmem_text/data_alloc() path and
switch to EXECMEM_DEFAULT if needed then? The execmem_range_is_data()
part that comes later could be added to the logic there too. So this
seems like unnecessary complexity to me or I don't see the reason.

Re: [PATCH v3 04/13] mm/execmem, arch: convert remaining overrides of module_alloc to execmem

[Edgecombe, Rick P]

On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> index 5f71a0cf4399..9d37375e2f05 100644
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -36,55 +37,30 @@ do
> {\
>  } while (0)
>  #endif
>  
> -#ifdef CONFIG_RANDOMIZE_BASE
> -static unsigned long module_load_offset;
> +static struct execmem_params execmem_params __ro_after_init = {
> +   .ranges = {
> +   [EXECMEM_DEFAULT] = {
> +   .flags = EXECMEM_KASAN_SHADOW,
> +   .alignment = MODULE_ALIGN,
> +   },
> +   },
> +};
>  
> -/* Mutex protects the module_load_offset. */
> -static DEFINE_MUTEX(module_kaslr_mutex);
> -
> -static unsigned long int get_module_load_offset(void)
> -{
> -   if (kaslr_enabled()) {
> -   mutex_lock(_kaslr_mutex);
> -   /*
> -    * Calculate the module_load_offset the first time
> this
> -    * code is called. Once calculated it stays the same
> until
> -    * reboot.
> -    */
> -   if (module_load_offset == 0)
> -   module_load_offset =
> -   get_random_u32_inclusive(1, 1024) *
> PAGE_SIZE;
> -   mutex_unlock(_kaslr_mutex);
> -   }
> -   return module_load_offset;
> -}
> -#else
> -static unsigned long int get_module_load_offset(void)
> -{
> -   return 0;
> -}
> -#endif
> -
> -void *module_alloc(unsigned long size)
> +struct execmem_params __init *execmem_arch_params(void)
>  {
> -   gfp_t gfp_mask = GFP_KERNEL;
> -   void *p;
> -
> -   if (PAGE_ALIGN(size) > MODULES_LEN)
> -   return NULL;
> +   unsigned long module_load_offset = 0;
> +   unsigned long start;
>  
> -   p = __vmalloc_node_range(size, MODULE_ALIGN,
> -    MODULES_VADDR +
> get_module_load_offset(),
> -    MODULES_END, gfp_mask, PAGE_KERNEL,
> -    VM_FLUSH_RESET_PERMS |
> VM_DEFER_KMEMLEAK,
> -    NUMA_NO_NODE,
> __builtin_return_address(0));
> +   if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && kaslr_enabled())
> +   module_load_offset =
> +   get_random_u32_inclusive(1, 1024) *
> PAGE_SIZE;

Minor:
I think you can skip the IS_ENABLED(CONFIG_RANDOMIZE_BASE) part because
CONFIG_RANDOMIZE_MEMORY depends on CONFIG_RANDOMIZE_BASE (which is
checked in kaslr_enabled()).

Re: [PATCH v4 2/2] dax/kmem: allow kmem to add memory with memmap_on_memory

[Verma, Vishal L]

On Tue, 2023-10-03 at 09:34 +0530, Aneesh Kumar K V wrote:
> On 9/29/23 2:00 AM, Vishal Verma wrote:
> > Large amounts of memory managed by the kmem driver may come in via CXL,
> > and it is often desirable to have the memmap for this memory on the new
> > memory itself.
> > 
> > Enroll kmem-managed memory for memmap_on_memory semantics if the dax
> > region originates via CXL. For non-CXL dax regions, retain the existing
> > default behavior of hot adding without memmap_on_memory semantics.
> > 
> 
> Are we not looking at doing altmap space for CXL DAX regions? Last discussion 
> around
> this was suggesting we look at doing this via altmap reservation so that
> we get contigous space for device memory enabling us to map them
> via 1G direct mapping entries? 
> 
Hey Aneesh - was this on a previous posting or something - do you have
a link so I can refresh myself on what the discussion was?

If it is enabling something in CXL similar to the --map=mem mode for
pmem + device dax, that could be incremental to this.

[PATCH v4] eventfs: Remove eventfs_file and just use eventfs_inode

[Steven Rostedt]

From: "Steven Rostedt (Google)" 

Instead of having a descriptor for every file represented in the eventfs
directory, only have the directory itself represented. Change the API to
send in a list of entries that represent all the files in the directory
(but not other directories). The entry list contains a name and a callback
function that will be used to create the files when they are accessed.

struct eventfs_inode *eventfs_create_events_dir(const char *name, struct dentry 
*parent,
const struct eventfs_entry 
*entries,
int size, void *data);

is used for the top level eventfs directory, and returns an eventfs_inode
that will be used by:

struct eventfs_inode *eventfs_create_dir(const char *name, struct eventfs_inode 
*parent,
 const struct eventfs_entry *entries,
 int size, void *data);

where both of the above take an array of struct eventfs_entry entries for
every file that is in the directory.

The entries are defined by:

typedef int (*eventfs_callback)(const char *name, umode_t *mode, void **data,
const struct file_operations **fops);

struct eventfs_entry {
const char  *name;
eventfs_callbackcallback;
};

Where the name is the name of the file and the callback gets called when
the file is being created. The callback passes in the name (in case the
same callback is used for multiple files), a pointer to the mode, data and
fops. The data will be pointing to the data that was passed in
eventfs_create_dir() or eventfs_create_events_dir() but may be overridden
to point to something else, as it will be used to point to the
inode->i_private that is created. The information passed back from the
callback is used to create the dentry/inode.

If the callback fills the data and the file should be created, it must
return a positive number. On zero or negative, the file is ignored.

This logic may also be used as a prototype to convert entire pseudo file
systems into just-in-time allocation.

The "show_events_dentry" file has been updated to show the directories,
and any files they have.

With just the eventfs_file allocations:

 Before after deltas for meminfo (in kB):

   MemFree: -14360
   MemAvailable:-14260
   Buffers: 40
   Cached:  24
   Active:  44
   Inactive:48
   Inactive(anon):  28
   Active(file):44
   Inactive(file):  20
   Dirty:   -4
   AnonPages:   28
   Mapped:  4
   KReclaimable:132
   Slab:1604
   SReclaimable:132
   SUnreclaim:  1472
   Committed_AS:12

 Before after deltas for slabinfo:

   : [ *  = ]

   ext4_inode_cache 27  [* 1184 = 31968 ]
   extent_status102 [*   40 = 4080 ]
   tracefs_inode_cache  144 [*  656 = 94464 ]
   buffer_head  39  [*  104 = 4056 ]
   shmem_inode_cache49  [*  800 = 39200 ]
   filp -53 [*  256 = -13568 ]
   dentry   251 [*  192 = 48192 ]
   lsm_file_cache   277 [*   32 = 8864 ]
   vm_area_struct   -14 [*  184 = -2576 ]
   trace_event_file 1748[*   88 = 153824 ]
   kmalloc-1k   35  [* 1024 = 35840 ]
   kmalloc-256  49  [*  256 = 12544 ]
   kmalloc-192  -28 [*  192 = -5376 ]
   kmalloc-128  -30 [*  128 = -3840 ]
   kmalloc-96   10581   [*   96 = 1015776 ]
   kmalloc-64   3056[*   64 = 195584 ]
   kmalloc-32   1291[*   32 = 41312 ]
   kmalloc-16   2310[*   16 = 36960 ]
   kmalloc-89216[*8 = 73728 ]

 Free memory dropped by 14,360 kB
 Available memory dropped by 14,260 kB
 Total slab additions in size: 1,771,032 bytes

With this change:

 Before after deltas for meminfo (in kB):

   MemFree: -12084
   MemAvailable:-11976
   Buffers: 32
   Cached:  32
   Active:  72
   Inactive:168
   Inactive(anon):  176
   Active(file):72
   Inactive(file):  -8
   Dirty:   24
   AnonPages:   196
   Mapped:  8
   KReclaimable:148
   Slab:836
   SReclaimable:148
   SUnreclaim:  688
   Committed_AS:324

 Before after deltas for slabinfo:

   : [ *  = ]

   tracefs_inode_cache  144 [* 656 = 94464 ]
   shmem_inode_cache-23 [* 800 = -18400 ]
   filp -92 [* 256 = -23552 ]
   dentry   179 [* 192 = 34368 ]
   lsm_file_cache   -3   

Re: [RFC PATCH] tracing: change syscall number type in struct syscall_trace_*

[Andrii Nakryiko]

On Mon, Oct 2, 2023 at 6:53 AM Artem Savkov  wrote:
>
> linux-rt-devel tree contains a patch that adds an extra member to struct

can you please point to the patch itself that makes that change?

> trace_entry. This causes the offset of args field in struct
> trace_event_raw_sys_enter be different from the one in struct
> syscall_trace_enter:
>
> struct trace_event_raw_sys_enter {
> struct trace_entry ent;  /* 012 */
>
> /* XXX last struct has 3 bytes of padding */
> /* XXX 4 bytes hole, try to pack */
>
> long int   id;   /*16 8 */
> long unsigned int  args[6];  /*2448 */
> /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
> char   __data[]; /*72 0 */
>
> /* size: 72, cachelines: 2, members: 4 */
> /* sum members: 68, holes: 1, sum holes: 4 */
> /* paddings: 1, sum paddings: 3 */
> /* last cacheline: 8 bytes */
> };
>
> struct syscall_trace_enter {
> struct trace_entry ent;  /* 012 */
>
> /* XXX last struct has 3 bytes of padding */
>
> intnr;   /*12 4 */
> long unsigned int  args[];   /*16 0 */
>
> /* size: 16, cachelines: 1, members: 3 */
> /* paddings: 1, sum paddings: 3 */
> /* last cacheline: 16 bytes */
> };
>
> This, in turn, causes perf_event_set_bpf_prog() fail while running bpf
> test_profiler testcase because max_ctx_offset is calculated based on the
> former struct, while off on the latter:
>
>   10488 if (is_tracepoint || is_syscall_tp) {
>   10489 int off = trace_event_get_offsets(event->tp_event);
>   10490
>   10491 if (prog->aux->max_ctx_offset > off)
>   10492 return -EACCES;
>   10493 }
>
> This patch changes the type of nr member in syscall_trace_* structs to
> be long so that "args" offset is equal to that in struct
> trace_event_raw_sys_enter.
>
> Signed-off-by: Artem Savkov 
> ---
>  kernel/trace/trace.h  | 4 ++--
>  kernel/trace/trace_syscalls.c | 7 ---
>  2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 77debe53f07cf..cd1d24df85364 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -135,13 +135,13 @@ enum trace_type {
>   */
>  struct syscall_trace_enter {
> struct trace_entry  ent;
> -   int nr;
> +   longnr;
> unsigned long   args[];
>  };
>
>  struct syscall_trace_exit {
> struct trace_entry  ent;
> -   int nr;
> +   longnr;
> longret;
>  };
>
> diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> index de753403cdafb..c26939119f2e4 100644
> --- a/kernel/trace/trace_syscalls.c
> +++ b/kernel/trace/trace_syscalls.c
> @@ -101,7 +101,7 @@ find_syscall_meta(unsigned long syscall)
> return NULL;
>  }
>
> -static struct syscall_metadata *syscall_nr_to_meta(int nr)
> +static struct syscall_metadata *syscall_nr_to_meta(long nr)
>  {
> if (IS_ENABLED(CONFIG_HAVE_SPARSE_SYSCALL_NR))
> return xa_load(_metadata_sparse, (unsigned long)nr);
> @@ -132,7 +132,8 @@ print_syscall_enter(struct trace_iterator *iter, int 
> flags,
> struct trace_entry *ent = iter->ent;
> struct syscall_trace_enter *trace;
> struct syscall_metadata *entry;
> -   int i, syscall;
> +   int i;
> +   long syscall;
>
> trace = (typeof(trace))ent;
> syscall = trace->nr;
> @@ -177,7 +178,7 @@ print_syscall_exit(struct trace_iterator *iter, int flags,
> struct trace_seq *s = >seq;
> struct trace_entry *ent = iter->ent;
> struct syscall_trace_exit *trace;
> -   int syscall;
> +   long syscall;
> struct syscall_metadata *entry;
>
> trace = (typeof(trace))ent;
> --
> 2.41.0
>
>

Re: [PATCH] visl: use canonical ftrace path

[Steven Rostedt]

Could this go through the linux-media tree, or if you give it an Ack, I'll
take it through the tracing tree.

-- Steve


On Tue, 29 Aug 2023 14:46:01 -0600
Ross Zwisler  wrote:

> From: Ross Zwisler 
> 
> The canonical location for the tracefs filesystem is at /sys/kernel/tracing.
> 
> But, from Documentation/trace/ftrace.rst:
> 
>   Before 4.1, all ftrace tracing control files were within the debugfs
>   file system, which is typically located at /sys/kernel/debug/tracing.
>   For backward compatibility, when mounting the debugfs file system,
>   the tracefs file system will be automatically mounted at:
> 
>   /sys/kernel/debug/tracing
> 
> Update the visl decoder driver documentation to use this tracefs path.
> 
> Signed-off-by: Ross Zwisler 
> ---
>  Documentation/admin-guide/media/visl.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/admin-guide/media/visl.rst 
> b/Documentation/admin-guide/media/visl.rst
> index 7d2dc78341c9..4328c6c72d30 100644
> --- a/Documentation/admin-guide/media/visl.rst
> +++ b/Documentation/admin-guide/media/visl.rst
> @@ -78,7 +78,7 @@ The trace events are defined on a per-codec basis, e.g.:
>  
>  .. code-block:: bash
>  
> -$ ls /sys/kernel/debug/tracing/events/ | grep visl
> +$ ls /sys/kernel/tracing/events/ | grep visl
>  visl_fwht_controls
>  visl_h264_controls
>  visl_hevc_controls
> @@ -90,13 +90,13 @@ For example, in order to dump HEVC SPS data:
>  
>  .. code-block:: bash
>  
> -$ echo 1 >  
> /sys/kernel/debug/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
> +$ echo 1 >  
> /sys/kernel/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
>  
>  The SPS data will be dumped to the trace buffer, i.e.:
>  
>  .. code-block:: bash
>  
> -$ cat /sys/kernel/debug/tracing/trace
> +$ cat /sys/kernel/tracing/trace
>  video_parameter_set_id 0
>  seq_parameter_set_id 0
>  pic_width_in_luma_samples 1920

Re: [PATCH v5 11/18] x86/sgx: store unreclaimable pages in LRU lists

[Huang, Kai]

On Tue, 2023-10-03 at 00:15 -0500, Haitao Huang wrote:
> On Thu, 28 Sep 2023 04:41:33 -0500, Huang, Kai  wrote:
> 
> > 
> > > --- a/arch/x86/kernel/cpu/sgx/encl.c
> > > +++ b/arch/x86/kernel/cpu/sgx/encl.c
> > > @@ -746,6 +746,7 @@ void sgx_encl_release(struct kref *ref)
> > >   xa_destroy(>page_array);
> > > 
> > >   if (!encl->secs_child_cnt && encl->secs.epc_page) {
> > > + sgx_drop_epc_page(encl->secs.epc_page);
> > >   sgx_encl_free_epc_page(encl->secs.epc_page);
> > >   encl->secs.epc_page = NULL;
> > >   }
> > 
> > The "record" of SECS/VA pages should be done together with this.  I see  
> > no
> > reason why the "record" and "drop" are separated into different patches.
> 
> "record" of SECS/VA pages are done in this patch. Before nothing done in  
> "record" for them because no tracking LRU lists for them. Now they are  
> tracked.
> 
> 

I was talking about calling sgx_record_epc_page() for SECS/VA:

@@ -113,6 +113,9 @@ static int sgx_encl_create(struct sgx_encl *encl, struct
sgx_secs *secs)
encl->attributes = secs->attributes;
encl->attributes_mask = SGX_ATTR_UNPRIV_MASK;
 
+   sgx_record_epc_page(encl->secs.epc_page,
+   SGX_EPC_PAGE_UNRECLAIMABLE);

This piece of code *literally* does the record.

Re: [PATCH v5 09/18] x86/sgx: Store struct sgx_encl when allocating new VA pages

[Huang, Kai]

On Tue, 2023-10-03 at 01:45 -0500, Haitao Huang wrote:
> > 
> > Btw, probably a dumb question:
> > 
> > Theoretically if you only need to find a victim enclave you don't need  
> > to put VA
> > pages to the unreclaimable list, because those VA pages will be freed  
> > anyway
> > when enclave is killed.  So keeping VA pages in the list is for  
> > accounting all
> > the pages that the cgroup is having?
> 
> Yes basically tracking them in cgroups as they are allocated.
> 
> VAs and SECS may also come and go as swapping/unswapping happens. But if a  
> cgroup is OOM, and all reclaimables are gone (swapped out), it'd have to  
> reclaim VAs/SECs in the same cgroup starting from the front of the LRU  
> list. To reclaim a VA/SECS, it identifies the enclave from the owner of  
> the VA/SECS page and kills it, as killing enclave is the only way to  
> reclaim VA/SECS pages.

To kill enclave you just need to track SECS in  the unreclaimable list.  

Only when you want to account the total EPC pages via some list you _probably_
need to track VA as well.  But I am not quite sure about this either.

Re: [PATCH v5 06/18] x86/sgx: Introduce EPC page states

[Huang, Kai]

On Mon, 2023-10-02 at 23:49 -0500, Haitao Huang wrote:
> On Wed, 27 Sep 2023 05:28:36 -0500, Huang, Kai  wrote:
> 
> > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > Use the lower 3 bits in the flags field of sgx_epc_page struct to
> > > track EPC states in its life cycle and define an enum for possible
> > > states. More state(s) will be added later.
> > 
> > This patch does more than what the changelog claims to do.  AFAICT it  
> > does
> > below:
> > 
> >  1) Use the lower 3 bits to track EPC page status
> >  2) Rename SGX_EPC_PAGE_RECLAIMER_TRACKED to SGX_EPC_PAGE_RERCLAIMABLE
> >  3) Introduce a new state SGX_EPC_PAGE_UNRECLAIMABLE
> >  4) Track SECS and VA pages as SGX_EPC_PAGE_UNRECLAIMABLE
> > 
> > The changelog only says 1) IIUC.
> > 
> I don't quite get why you would view 3) as a separate item from 1).

1) is about using some method to track EPC page status, 3) is adding a new
state.

Why cannot they be separated?

> In my view, 4) is not done as long as there is not separate list to track  
> it.

You are literally doing below:

@@ -113,6 +113,9 @@ static int sgx_encl_create(struct sgx_encl *encl, struct
sgx_secs *secs)
encl->attributes = secs->attributes;
encl->attributes_mask = SGX_ATTR_UNPRIV_MASK;
 
+   sgx_record_epc_page(encl->secs.epc_page,
+   SGX_EPC_PAGE_UNRECLAIMABLE);
+

Which obviously is tracking SECS as unreclaimable page here.

The only thing you are not doing now is to put to the actual list, which you
introduced in a later patch.

But why not just doing them together?

Re: [PATCH v4 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks

[Verma, Vishal L]

On Mon, 2023-10-02 at 11:28 +0200, David Hildenbrand wrote:
> 
> > +
> > +static int __ref try_remove_memory(u64 start, u64 size)
> > +{
> > +   int rc, nid = NUMA_NO_NODE;
> > +
> > +   BUG_ON(check_hotplug_memory_range(start, size));
> > +
> > +   /*
> > +    * All memory blocks must be offlined before removing memory.  Check
> > +    * whether all memory blocks in question are offline and return 
> > error
> > +    * if this is not the case.
> > +    *
> > +    * While at it, determine the nid. Note that if we'd have mixed 
> > nodes,
> > +    * we'd only try to offline the last determined one -- which is good
> > +    * enough for the cases we care about.
> > +    */
> > +   rc = walk_memory_blocks(start, size, , 
> > check_memblock_offlined_cb);
> > +   if (rc)
> > +   return rc;
> > +
> > +   /*
> > +    * For memmap_on_memory, the altmaps could have been added on
> > +    * a per-memblock basis. Loop through the entire range if so,
> > +    * and remove each memblock and its altmap.
> > +    */
> > +   if (mhp_memmap_on_memory()) {
> > +   unsigned long memblock_size = memory_block_size_bytes();
> > +   u64 cur_start;
> > +
> > +   for (cur_start = start; cur_start < start + size;
> > +    cur_start += memblock_size)
> > +   __try_remove_memory(nid, cur_start, memblock_size);
> > +   } else {
> > +   __try_remove_memory(nid, start, size);
> > +   }
> > +
> > return 0;
> >   }
> 
> Why is the firmware, memblock and nid handling not kept in this outer
> function?
> 
> We really shouldn't be doing per memory block what needs to be done per 
> memblock: remove_memory_block_devices() and arch_remove_memory().


Ah yes makes sense since we only do create_memory_block_devices() and
arch_add_memory() in the per memory block inner loop during addition.

How should the locking work in this case though?

The original code holds the mem_hotplug_begin() lock over
arch_remove_memory() and all of the nid and memblock stuff. Should I
just hold the lock and release it in the inner loop for each memory
block, and then also acquire and release it separately for the memblock
and nid stuff in the outer function?

Here's the incremental diff for what I'm thinking:

---

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 43dbd71a4910..13380178173d 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -2171,7 +2171,7 @@ void try_offline_node(int nid)
 }
 EXPORT_SYMBOL(try_offline_node);
 
-static void __ref __try_remove_memory(int nid, u64 start, u64 size)
+static void __ref remove_memory_block_and_altmap(int nid, u64 start, u64 size)
 {
int rc = 0;
struct memory_block *mem;
@@ -2187,9 +2187,6 @@ static void __ref __try_remove_memory(int nid, u64 start, 
u64 size)
mem->altmap = NULL;
}
 
-   /* remove memmap entry */
-   firmware_map_remove(start, start + size, "System RAM");
-
/*
 * Memory block device removal under the device_hotplug_lock is
 * a barrier against racing online attempts.
@@ -2206,16 +2203,6 @@ static void __ref __try_remove_memory(int nid, u64 
start, u64 size)
kfree(altmap);
}
 
-   if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) {
-   memblock_phys_free(start, size);
-   memblock_remove(start, size);
-   }
-
-   release_mem_region_adjustable(start, size);
-
-   if (nid != NUMA_NO_NODE)
-   try_offline_node(nid);
-
mem_hotplug_done();
 }
 
@@ -2249,11 +2236,29 @@ static int __ref try_remove_memory(u64 start, u64 size)
 
for (cur_start = start; cur_start < start + size;
 cur_start += memblock_size)
-   __try_remove_memory(nid, cur_start, memblock_size);
+   remove_memory_block_and_altmap(nid, cur_start,
+  memblock_size);
} else {
-   __try_remove_memory(nid, start, size);
+   remove_memory_block_and_altmap(nid, start, size);
}
 
+   /* remove memmap entry */
+   firmware_map_remove(start, start + size, "System RAM");
+
+   mem_hotplug_begin();
+
+   if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) {
+   memblock_phys_free(start, size);
+   memblock_remove(start, size);
+   }
+
+   release_mem_region_adjustable(start, size);
+
+   if (nid != NUMA_NO_NODE)
+   try_offline_node(nid);
+
+   mem_hotplug_done();
+
return 0;
 }

Re: [PATCH v5 02/18] cgroup/misc: Add SGX EPC resource type and export APIs for SGX driver

[Huang, Kai]

On Tue, 2023-10-03 at 02:00 -0500, Haitao Huang wrote:
> On Wed, 27 Sep 2023 22:59:12 -0500, Huang, Kai  wrote:
> 
> > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > From: Kristen Carlson Accardi 
> > > 
> > > Add SGX EPC memory, MISC_CG_RES_SGX_EPC, to be a valid resource type
> > > for the misc controller.
> > > 
> > > Add per resource type private data so that SGX can store additional per
> > > cgroup data in misc_cg->misc_cg_res[MISC_CG_RES_SGX_EPC].
> > 
> > To be honest I don't quite understand why putting the above two changes  
> > in this
> > patch together with exporting misc_cg_root/parent() below.
> > 
> > Any reason why the above two cannot be done together with patch ("  
> > x86/sgx:
> > Limit process EPC usage with misc cgroup controller"), where these  
> > changes are
> > actually related?
> > 
> > We all already know that a new EPC misc cgroup will be added.  There's  
> > no need
> > to actually introduce the new type here only to justify exporting some  
> > helper
> > functions.
> > 
> 
> I think previous authors intended to separate all prerequisite misc  
> changes from SGX changes.
> I can combine them if maintainers are fine with it.

That's fine.  But IMHO for this particular one I think you are mixing things
together:  Adding SGX EPC resource type and exporting APIs don't have dependency
on the code.

It will be easier to review if you separate this two parts out.  For instance,
at least it's not super clear whether adding a 'priv' is a right move here w/o
looking at the later patches.

Also if you take a look at:

7aef27f0b2a8 ("svm/sev: Register SEV and SEV-ES ASIDs to the misc controller")

Adding the resource type is added together with the implementation.

So I have no problem if you want to split out "adding SGX EPC resource type" out
as a separate patch, but this patch looks should be split. 

> 
> > > 
> > > Export misc_cg_root() so the SGX driver can initialize and add those
> > > additional structures to the root misc cgroup as part of initialization
> > > for EPC cgroup support. This bootstraps the same additional
> > > initialization for non-root cgroups in the 'alloc()' callback added in  
> > > the
> > > previous patch.
> > > 
> > > The SGX driver, as the EPC memory provider, will have a background
> > > worker to reclaim EPC pages to make room for new allocations in the same
> > > cgroup when its usage counter reaches near the limit controlled by the
> > > cgroup and its ancestors. Therefore it needs to do a walk from the
> > > current cgroup up to the root. To enable this walk, move parent_misc()
> > > into misc_cgroup.h and make inline to make this function available to
> > > SGX, rename it to misc_cg_parent(), and update kernel/cgroup/misc.c to
> > > use the new name.
> > 
> > Looks too many details in the above two paragraphs.  Could we have a more
> > concise justification for exporting these two functions?
> > 
> 
> This was added to address Jarkko's question, "why does SGX driver need to  
> do iterative walks?"
> See: https://lore.kernel.org/all/CVHOU5G1SCUT.RCBVZ3W8G2NJ@suppilovahvero/

Agree with Jarkko we need a justification (that what I said above too).  What I
am saying is you can make it more concise.  I can try to do if you want me to.

> 
> > And if it were me, I would put it at a relatively later position (e.g.,  
> > before
> > the patch actually implements EPC cgroup) for better review.  This also  
> > applies
> > to the first patch.
> > 
> 
> I was told to move all prerequisites to the front or separate out.
> 
> https://lore.kernel.org/linux-sgx/CU4H43P3H35X.1BCA3CE4D1250@seitikki/
> 
> 

I don't see any conflict.  Please see the first reply.

Re: [PATCH -fixes] riscv: Fix ftrace syscall handling which are now prefixed with __riscv_

[Sami Tolvanen]

On Tue, Oct 3, 2023 at 11:24 AM Alexandre Ghiti  wrote:
>
> ftrace creates entries for each syscall in the tracefs but has failed
> since commit 08d0ce30e0e4 ("riscv: Implement syscall wrappers") which
> prefixes all riscv syscalls with __riscv_.
>
> So fix this by implementing arch_syscall_match_sym_name() which allows us
> to ignore this prefix.
>
> And also ignore compat syscalls like x86/arm64 by implementing
> arch_trace_is_compat_syscall().
>
> Fixes: 08d0ce30e0e4 ("riscv: Implement syscall wrappers")
> Signed-off-by: Alexandre Ghiti 
> ---
>  arch/riscv/include/asm/ftrace.h | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
> index 740a979171e5..2b2f5df7ef2c 100644
> --- a/arch/riscv/include/asm/ftrace.h
> +++ b/arch/riscv/include/asm/ftrace.h
> @@ -31,6 +31,27 @@ static inline unsigned long ftrace_call_adjust(unsigned 
> long addr)
> return addr;
>  }
>
> +/*
> + * Let's do like x86/arm64 and ignore the compat syscalls.
> + */
> +#define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
> +static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
> +{
> +   return is_compat_task();
> +}
> +
> +#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> +static inline bool arch_syscall_match_sym_name(const char *sym,
> +  const char *name)
> +{
> +   /*
> +* Since all syscall functions have __riscv_ prefix, we must skip it.
> +* However, as we described above, we decided to ignore compat
> +* syscalls, so we don't care about __riscv_compat_ prefix here.
> +*/
> +   return !strcmp(sym + 8, name);
> +}

Good catch, thanks for fixing this!

Reviewed-by: Sami Tolvanen 

Sami

Re: [PATCH -fixes] riscv: Fix ftrace syscall handling which are now prefixed with __riscv_

[Alexandre Ghiti]

@Conor Dooley This fails checkpatch but the documentation here states
that this is how to do:
https://elixir.bootlin.com/linux/latest/source/Documentation/trace/ftrace-design.rst#L246

On Tue, Oct 3, 2023 at 8:24 PM Alexandre Ghiti  wrote:
>
> ftrace creates entries for each syscall in the tracefs but has failed
> since commit 08d0ce30e0e4 ("riscv: Implement syscall wrappers") which
> prefixes all riscv syscalls with __riscv_.
>
> So fix this by implementing arch_syscall_match_sym_name() which allows us
> to ignore this prefix.
>
> And also ignore compat syscalls like x86/arm64 by implementing
> arch_trace_is_compat_syscall().
>
> Fixes: 08d0ce30e0e4 ("riscv: Implement syscall wrappers")
> Signed-off-by: Alexandre Ghiti 
> ---
>  arch/riscv/include/asm/ftrace.h | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
> index 740a979171e5..2b2f5df7ef2c 100644
> --- a/arch/riscv/include/asm/ftrace.h
> +++ b/arch/riscv/include/asm/ftrace.h
> @@ -31,6 +31,27 @@ static inline unsigned long ftrace_call_adjust(unsigned 
> long addr)
> return addr;
>  }
>
> +/*
> + * Let's do like x86/arm64 and ignore the compat syscalls.
> + */
> +#define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
> +static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
> +{
> +   return is_compat_task();
> +}
> +
> +#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> +static inline bool arch_syscall_match_sym_name(const char *sym,
> +  const char *name)
> +{
> +   /*
> +* Since all syscall functions have __riscv_ prefix, we must skip it.
> +* However, as we described above, we decided to ignore compat
> +* syscalls, so we don't care about __riscv_compat_ prefix here.
> +*/
> +   return !strcmp(sym + 8, name);
> +}
> +
>  struct dyn_arch_ftrace {
>  };
>  #endif
> --
> 2.39.2
>

[PATCH -fixes] riscv: Fix ftrace syscall handling which are now prefixed with __riscv_

[Alexandre Ghiti]

ftrace creates entries for each syscall in the tracefs but has failed
since commit 08d0ce30e0e4 ("riscv: Implement syscall wrappers") which
prefixes all riscv syscalls with __riscv_.

So fix this by implementing arch_syscall_match_sym_name() which allows us
to ignore this prefix.

And also ignore compat syscalls like x86/arm64 by implementing
arch_trace_is_compat_syscall().

Fixes: 08d0ce30e0e4 ("riscv: Implement syscall wrappers")
Signed-off-by: Alexandre Ghiti 
---
 arch/riscv/include/asm/ftrace.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
index 740a979171e5..2b2f5df7ef2c 100644
--- a/arch/riscv/include/asm/ftrace.h
+++ b/arch/riscv/include/asm/ftrace.h
@@ -31,6 +31,27 @@ static inline unsigned long ftrace_call_adjust(unsigned long 
addr)
return addr;
 }
 
+/*
+ * Let's do like x86/arm64 and ignore the compat syscalls.
+ */
+#define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
+static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
+{
+   return is_compat_task();
+}
+
+#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+static inline bool arch_syscall_match_sym_name(const char *sym,
+  const char *name)
+{
+   /*
+* Since all syscall functions have __riscv_ prefix, we must skip it.
+* However, as we described above, we decided to ignore compat
+* syscalls, so we don't care about __riscv_compat_ prefix here.
+*/
+   return !strcmp(sym + 8, name);
+}
+
 struct dyn_arch_ftrace {
 };
 #endif
-- 
2.39.2

Re: [PATCH 1/1] rpmsg: virtio: Make buffer size and number configurable

[Tanmay Shah]

On 10/3/23 10:28 AM, Divin Raj wrote:
> Hello,
>
> Thanks for all review comments.
> It makes sense to incorporate a variable-length buffer size. However, we 
> still require an implementation that can successfully achieve this objective.
>
> We will be investigating this matter and will return with a feasible solution.

Thanks.

Here is the previous effort:

Series: "Enhance virtio rpmsg bus driver buffer allocation"

https://lore.kernel.org/all/1548949280-31794-1-git-send-email-xiaoxi...@xiaomi.com/

There was discussion to revive the patch and the activity is still pending. 
This can be good start if we want to achieve it.

Thanks,

Tanmay


>
> Thanks,
>
> On 9/28/23 5:10 PM, Tanmay Shah wrote:
>
> Hello,
>
> Thanks for your patch.
>
> Instead of having this in Kconfig, It's better to have buffer size decided 
> dynamically. Probably by resource-table.
>
> We still need implementation that achieves that goal. Meanwhile  I think it's 
> best to keep buffer size fixed.
>
> Thanks.
>
> On 9/28/23 10:38 AM, Divin Raj wrote:
>
>
>
> CAUTION: This message has originated from an External Source. Please use 
> proper judgment and caution when opening attachments, clicking links, or 
> responding to this email.
>
>
> From: Peter Hoyes 
>
> Replace the MAX_RPMSG_BUF_SIZE and MAX_RPMSG_NUM_BUFS #define in
> virtio_rpmsg_bus.c with the Kconfig parameters CONFIG_RPMSG_VIRTIO_BUF_SIZE
> and CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS, allowing user-provided customization.
>
> Making both the number of buffers and size configurable facilitates aligning
> memory requirements between vdev-buffer and vdev-vrings for client drivers
> that require larger buffer sizes, for example.
>
> Signed-off-by: Peter Hoyes 
> Signed-off-by: Divin Raj 
> ---
>  drivers/rpmsg/Kconfig| 23 +++
>  drivers/rpmsg/virtio_rpmsg_bus.c | 27 +++
>  2 files changed, 26 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> index d3795860f5c0..677f4a1ac8bb 100644
> --- a/drivers/rpmsg/Kconfig
> +++ b/drivers/rpmsg/Kconfig
> @@ -81,4 +81,27 @@ config RPMSG_VIRTIO
> select RPMSG_NS
> select VIRTIO
>
> +config RPMSG_VIRTIO_MAX_BUF_SIZE
> +   int "Virtio RPMSG max buffer size (in bytes)"
> +   default 512
> +   depends on RPMSG_VIRTIO
> +   help
> + This option allows you to configure the maximum buffer size (in 
> bytes)
> + for Virtio RPMSG communications. The number of buffers will be 
> computed
> + based on the number of buffers (CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS)
> + supported by the vring. By default, it supports up to a maximum of 
> 512
> + buffers (256 in each direction). Each buffer consists of 16 bytes 
> for the
> + message header and the remaining bytes for the payload.The default 
> values
> + will utilize a maximum total space of 256KB for the buffers.
> +
> +config RPMSG_VIRTIO_MAX_NUM_BUFS
> +   int "Virtio RPMSG max buffer count (even number for TX and Rx)"
> +   default 512
> +   depends on RPMSG_VIRTIO
> +   help
> + This option allows you to configure the maximum number of buffers 
> used
> + for Virtio RPMSG communication. By default, it supports up to a 
> maximum
> + of 512 buffers (256 in each direction). Please note that this value
> + should be an even number, as it accounts for both transmit (TX) and
> + receive (Rx) buffers.
>  endmenu
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c 
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 905ac7910c98..87a9a4fa30e0 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -109,27 +109,6 @@ struct virtio_rpmsg_channel {
>  #define to_virtio_rpmsg_channel(_rpdev) \
> container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
>
> -/*
> - * We're allocating buffers of 512 bytes each for communications. The
> - * number of buffers will be computed from the number of buffers supported
> - * by the vring, upto a maximum of 512 buffers (256 in each direction).
> - *
> - * Each buffer will have 16 bytes for the msg header and 496 bytes for
> - * the payload.
> - *
> - * This will utilize a maximum total space of 256KB for the buffers.
> - *
> - * We might also want to add support for user-provided buffers in time.
> - * This will allow bigger buffer size flexibility, and can also be used
> - * to achieve zero-copy messaging.
> - *
> - * Note that these numbers are purely a decision of this driver - we
> - * can change this without changing anything in the firmware of the remote
> - * processor.
> - */
> -#define MAX_RPMSG_NUM_BUFS (512)
> -#define MAX_RPMSG_BUF_SIZE (512)
> -
>  /*
>   * Local addresses are dynamically allocated on-demand.
>   * We do not dynamically assign addresses from the low 1024 range,
> @@ -902,12 +881,12 @@ 

Re: [PATCH v2 0/2] Remove reset GPIO for AW88261

[Mark Brown]

On Mon, 02 Oct 2023 16:00:10 +0200, Luca Weiss wrote:
> The AW88261 chip doesn't have a reset gpio, so remove it from the
> bindings and from the driver.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/2] ASoC: dt-bindings: awinic,aw88395: Remove reset-gpios from AW88261
  commit: c7b94e8614e35f1919b51c23fe590884149ae341
[2/2] ASoC: codecs: aw88261: Remove non-existing reset gpio
  commit: 4eed047b76fa8f56af478ca7e6d56ca7e5330cf2

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH v5 01/18] cgroup/misc: Add per resource callbacks for CSS events

[Haitao Huang]

On Wed, 27 Sep 2023 04:20:55 -0500, Huang, Kai  wrote:


On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:

From: Kristen Carlson Accardi 

The misc cgroup controller (subsystem) currently does not perform
resource type specific action for Cgroups Subsystem State (CSS) events:
the 'css_alloc' event when a cgroup is created and the 'css_free' event
when a cgroup is destroyed, or in event of user writing the max value to
the misc.max file to set the usage limit of a specific resource
[admin-guide/cgroup-v2.rst, 5-9. Misc].

Define callbacks for those events and allow resource providers to
register the callbacks per resource type as needed. This will be
utilized later by the EPC misc cgroup support implemented in the SGX
driver:
- On css_alloc, allocate and initialize necessary structures for EPC
reclaiming, e.g., LRU list, work queue, etc.
- On css_free, cleanup and free those structures created in alloc.
- On max_write, trigger EPC reclaiming if the new limit is at or below
current usage.


Nit:

Wondering why we should trigger EPC reclaiming if the new limit is *at*  
current

usage?

I actually don't quite care about why here, but writing these details in  
the
changelog may bring unnecessary confusion.  I guess you can just remove  
all the

details about what SGX driver needs to do on these callbacks.


Okay, I'll remove the three bullets on the SGX drive implementation  
details.


Thanks
Haitao

[PATCH v2 08/14] arm64: dts: qcom: msm8916-alcatel-idol347: Add sound and modem

[Stephan Gerhold]

From: Vincent Knecht 

Enable sound and modem for the Alcatel Idol 3 (4.7"). The setup is
similar to most MSM8916 devices, i.e.:

 - QDSP6 audio
 - Microphones via digital/analog codec in MSM8916/PM8916
 - WWAN Internet via BAM-DMUX

except:

 - Stereo NXP TFA9890 codecs for speakers on Quaternary MI2S
   - These are also used as earpieces at the top/bottom.
 - Asahi Kasei AK4375 headphone codec on Secondary MI2S
 -> Primary MI2S is not used for playback

Signed-off-by: Vincent Knecht 
[Stephan: Minor refactoring, add consistent commit message]
Signed-off-by: Stephan Gerhold 
---
There are some trivial conflicts unless
https://lore.kernel.org/linux-arm-msm/20230921-msm8916-rmem-fixups-v1-3-34d2b6e72...@gerhold.net/
is applied first. But given that there are important fixups for the
dynamic reserved memory changes in that series it should preferably
get applied before this one anyway.
---
 .../boot/dts/qcom/msm8916-alcatel-idol347.dts  | 171 +
 1 file changed, 171 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts 
b/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
index fade93c55299..3459145516a1 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
@@ -3,6 +3,8 @@
 /dts-v1/;
 
 #include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
 #include 
 #include 
 #include 
@@ -22,6 +24,19 @@ chosen {
stdout-path = "serial0";
};
 
+   reserved-memory {
+   /delete-node/ reserved@8668;
+   /delete-node/ rmtfs@8670;
+
+   rmtfs: rmtfs@8668 {
+   compatible = "qcom,rmtfs-mem";
+   reg = <0x0 0x8668 0x0 0x16>;
+   no-map;
+
+   qcom,client-id = <1>;
+   };
+   };
+
gpio-keys {
compatible = "gpio-keys";
 
@@ -50,6 +65,17 @@ led-0 {
};
};
 
+   reg_headphones_avdd: regulator-headphones-avdd {
+   compatible = "regulator-fixed";
+   regulator-name = "headphones_avdd";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   gpio = < 121 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   pinctrl-0 = <_avdd_default>;
+   pinctrl-names = "default";
+   };
+
usb_id: usb-id {
compatible = "linux,extcon-usb-gpio";
id-gpios = < 69 GPIO_ACTIVE_HIGH>;
@@ -58,6 +84,43 @@ usb_id: usb-id {
};
 };
 
+_i2c3 {
+   status = "okay";
+
+   headphones: audio-codec@10 {
+   compatible = "asahi-kasei,ak4375";
+   reg = <0x10>;
+   avdd-supply = <_headphones_avdd>;
+   tvdd-supply = <_l6>;
+   pdn-gpios = < 114 GPIO_ACTIVE_HIGH>;
+   pinctrl-0 = <_pdn_default>;
+   pinctrl-names = "default";
+   #sound-dai-cells = <0>;
+   };
+
+   speaker_codec_top: audio-codec@34 {
+   compatible = "nxp,tfa9897";
+   reg = <0x34>;
+   vddd-supply = <_l6>;
+   rcv-gpios = < 50 GPIO_ACTIVE_HIGH>;
+   pinctrl-0 = <_top_default>;
+   pinctrl-names = "default";
+   sound-name-prefix = "Speaker Top";
+   #sound-dai-cells = <0>;
+   };
+
+   speaker_codec_bottom: audio-codec@36 {
+   compatible = "nxp,tfa9897";
+   reg = <0x36>;
+   vddd-supply = <_l6>;
+   rcv-gpios = < 111 GPIO_ACTIVE_HIGH>;
+   pinctrl-0 = <_bottom_default>;
+   pinctrl-names = "default";
+   sound-name-prefix = "Speaker Bottom";
+   #sound-dai-cells = <0>;
+   };
+};
+
 _i2c4 {
status = "okay";
 
@@ -153,6 +216,18 @@ _uart2 {
status = "okay";
 };
 
+_mem {
+   reg = <0x0 0x8680 0x0 0x500>;
+};
+
+_codec {
+   qcom,micbias1-ext-cap;
+   qcom,micbias-lvl = <2800>;
+   qcom,mbhc-vthreshold-low = <75 100 120 180 500>;
+   qcom,mbhc-vthreshold-high = <75 100 120 180 500>;
+   qcom,hphl-jack-type-normally-open;
+};
+
 _resin {
status = "okay";
linux,code = ;
@@ -169,6 +244,17 @@ _vib {
status = "okay";
 };
 
+ {
+   dai@18 {
+   reg = ;
+   qcom,sd-lines = <0>;
+   };
+   dai@22 {
+   reg = ;
+   qcom,sd-lines = <0>;
+   };
+};
+
 _1 {
status = "okay";
 };
@@ -183,6 +269,54 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
 };
 
+ {
+   /* Add pin switches for speakers to allow disabling them individually */
+   model = "alcatel-idol3";
+   widgets =
+   "Speaker", "Speaker Top",
+   "Speaker", "Speaker Bottom";
+   pin-switches = "Speaker Top", "Speaker Bottom";
+   

[PATCH v2 10/14] arm64: dts: qcom: msm8916-longcheer-l8150: Add sound and modem

[Stephan Gerhold]

From: Nikita Travkin 

Enable sound and modem for the Longcheer L8150 (e.g. Wileyfox Swift).
The setup is similar to most MSM8916 devices, i.e.:

 - QDSP6 audio
 - Speaker/earpiece/headphones/microphones via digital/analog codec
   in MSM8916/PM8916
 - Audio jack detection via analog codec in PM8916
 - WWAN Internet via BAM-DMUX

except:

 - The mpss firmware region must be relocated to a different address.
   This is because the wcnss firmware is not relocatable for some
   reason. The mpss firmware is too large to avoid overlap with wcnss
   when placed at the default address (0x8680).

   Surprisingly the vendor kernel does not handle this. The firmware
   regions end up overlapping there and somehow this does not explode.
   We try to handle this more safely by relocating the mpss region to
   the first higher address that is working correctly: 0x8e80.

Signed-off-by: Nikita Travkin 
Co-developed-by: Stephan Gerhold 
Signed-off-by: Stephan Gerhold 
---
 .../boot/dts/qcom/msm8916-longcheer-l8150.dts  | 31 +++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts 
b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
index 47d1c5cb13f4..37fa55166918 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
@@ -3,6 +3,8 @@
 /dts-v1/;
 
 #include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
 #include 
 #include 
 #include 
@@ -25,17 +27,26 @@ chosen {
 
/*
 * For some reason, the signed wcnss firmware is not relocatable.
-* It must be loaded at 0x8b60. All other firmware is relocatable,
-* so place wcnss at the fixed address and then all other firmware
-* regions will be automatically allocated at a fitting place.
+* It must be loaded at 0x8b60. Unfortunately, this also means that
+* mpss_mem does not fit when loaded to the typical address at 
0x8680.
+*
+* Load wcnss_mem to the fixed address and relocate mpss_mem to the next
+* working higher address. For some reason the modem firmware does not
+* boot when placed at 0x8a80 to 0x8e80.
 */
reserved-memory {
+   /delete-node/ mpss@8680;
/delete-node/ wcnss;
 
wcnss_mem: wcnss@8b60 {
reg = <0x0 0x8b60 0x0 0x60>;
no-map;
};
+
+   mpss_mem: mpss@8e80 {
+   reg = <0x0 0x8e80 0x0 0x500>;
+   no-map;
+   };
};
 
gpio-keys {
@@ -225,6 +236,13 @@ _uart2 {
status = "okay";
 };
 
+_codec {
+   qcom,micbias-lvl = <2800>;
+   qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+   qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+   qcom,hphl-jack-type-normally-open;
+};
+
 _resin {
status = "okay";
linux,code = ;
@@ -254,6 +272,13 @@ _2 {
non-removable;
 };
 
+ {
+   audio-routing =
+   "AMIC1", "MIC BIAS Internal1",
+   "AMIC2", "MIC BIAS Internal2",
+   "AMIC3", "MIC BIAS Internal3";
+};
+
  {
status = "okay";
dr_mode = "peripheral";

-- 
2.42.0

[PATCH v2 09/14] arm64: dts: qcom: msm8916-asus-z00l: Add sound and modem

[Stephan Gerhold]

From: "J.R. Divya Antony" 

Enable sound and modem for the ASUS Zenfone 2 Laser. The setup is
similar to most MSM8916 devices, i.e.:

 - QDSP6 audio
 - Speakear/earpiece/headphones/microphones via digital/analog codec
   in MSM8916/PM8916
 - Audio jack detection via analog codec in PM8916
 - WWAN Internet via BAM-DMUX

Signed-off-by: "J.R. Divya Antony" 
[Stephan: rebase and simplify, add consistent commit message]
Reviewed-by: Konrad Dybcio 
Signed-off-by: Stephan Gerhold 
---
 arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts 
b/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
index a8be6ff66893..77618c7374df 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
@@ -3,6 +3,8 @@
 /dts-v1/;
 
 #include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
 #include 
 #include 
 #include 
@@ -130,6 +132,18 @@ _uart2 {
status = "okay";
 };
 
+_mem {
+   reg = <0x0 0x8680 0x0 0x550>;
+};
+
+_codec {
+   qcom,micbias-lvl = <2800>;
+   qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+   qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+   qcom,micbias1-ext-cap;
+   qcom,hphl-jack-type-normally-open;
+};
+
 _rpm_regulators {
pm8916_l17: l17 {
regulator-min-microvolt = <285>;
@@ -151,6 +165,13 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
 };
 
+ {
+   audio-routing =
+   "AMIC1", "MIC BIAS External1",
+   "AMIC2", "MIC BIAS Internal2",
+   "AMIC3", "MIC BIAS External1";
+};
+
  {
status = "okay";
extcon = <_id>, <_id>;

-- 
2.42.0

[PATCH v2 11/14] arm64: dts: qcom: msm8916-longcheer-l8910: Add sound and modem

[Stephan Gerhold]

From: Jonathan Albrieux 

Enable sound and modem for the Longcheer L8910 (BQ Aquaris X5).
The setup is similar to most MSM8916 devices, i.e.:

 - QDSP6 audio
 - Earpiece/headphones/microphones via digital/analog codec in
   MSM8916/PM8916
 - Audio jack detection via analog codec in PM8916
 - WWAN Internet via BAM-DMUX

except:

 - Awinic AW8738 connected to HPH_R (headphones) output of the analog
   codec. Note that unlike for wingtech-wt88047 there is no analog
   switch that would allow disabling output via the headphone jack
   when the speaker is enabled.

Signed-off-by: Jonathan Albrieux 
Co-developed-by: Stephan Gerhold 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Stephan Gerhold 
---
 .../boot/dts/qcom/msm8916-longcheer-l8910.dts  | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts 
b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
index 41cadb906b98..e64bf687ca7d 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
@@ -3,6 +3,8 @@
 /dts-v1/;
 
 #include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
 #include 
 #include 
 #include 
@@ -22,6 +24,16 @@ chosen {
stdout-path = "serial0";
};
 
+   speaker_amp: audio-amplifier {
+   compatible = "awinic,aw8738";
+   mode-gpios = < 114 GPIO_ACTIVE_HIGH>;
+   awinic,mode = <5>;
+   sound-name-prefix = "Speaker Amp";
+
+   pinctrl-0 = <_ext_pa_default>;
+   pinctrl-names = "default";
+   };
+
flash-led-controller {
compatible = "ocs,ocp8110";
enable-gpios = < 49 GPIO_ACTIVE_HIGH>;
@@ -107,6 +119,17 @@ _uart2 {
status = "okay";
 };
 
+_mem {
+   reg = <0x0 0x8680 0x0 0x500>;
+};
+
+_codec {
+   qcom,micbias-lvl = <2800>;
+   qcom,mbhc-vthreshold-low = <75 100 120 180 500>;
+   qcom,mbhc-vthreshold-high = <75 100 120 180 500>;
+   qcom,hphl-jack-type-normally-open;
+};
+
 _resin {
status = "okay";
linux,code = ;
@@ -137,6 +160,28 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
 };
 
+ {
+   /*
+* Provide widgets/pin-switches to allow enabling speaker separately.
+* The hardware does not provide a way to disable the output via the
+* headphone jack when the speaker is enabled.
+*/
+   model = "bq-paella";
+   widgets =
+   "Speaker", "Speaker",
+   "Headphone", "Headphones";
+   pin-switches = "Speaker";
+   audio-routing =
+   "Speaker", "Speaker Amp OUT",
+   "Speaker Amp IN", "HPH_R",
+   "Headphones", "HPH_L",
+   "Headphones", "HPH_R",
+   "AMIC1", "MIC BIAS External1",
+   "AMIC2", "MIC BIAS Internal2",
+   "AMIC3", "MIC BIAS External1";
+   aux-devs = <_amp>;
+};
+
  {
status = "okay";
extcon = <_id>, <_id>;
@@ -205,6 +250,13 @@ sdc2_cd_default: sdc2-cd-default-state {
bias-disable;
};
 
+   spk_ext_pa_default: spk-ext-pa-default-state {
+   pins = "gpio114";
+   function = "gpio";
+   drive-strength = <2>;
+   bias-disable;
+   };
+
usb_id_default: usb-id-default-state {
pins = "gpio110";
function = "gpio";

-- 
2.42.0

[PATCH v2 13/14] arm64: dts: qcom: msm8916-samsung-j5: Add sound and modem

[Stephan Gerhold]

From: "Lin, Meng-Bo" 

Enable sound and modem for the Samsung J5 smartphones. The setup is
similar to most MSM8916 devices, i.e.:

 - QDSP6 audio
 - Speaker/earpiece/headphones/microphones via digital/analog codec
   in MSM8916/PM8916
 - WWAN Internet via BAM-DMUX

except:

 - There is no secondary microphone, so a different "model" is used to
   differentiate that in the UCM configuration.
 - Samsung-specific audio jack detection (not supported yet)

Co-developed-by: Markuss Broks 
Signed-off-by: Markuss Broks 
Signed-off-by: "Lin, Meng-Bo" 
[Stephan: Add consistent commit message]
Signed-off-by: Stephan Gerhold 
---
 arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi | 14 ++
 arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts |  4 
 2 files changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
index fe59be3505fe..5ca2ada266f4 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
@@ -1,6 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0-only
 
 #include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
 #include 
 #include 
 #include 
@@ -135,6 +137,10 @@ _uart2 {
status = "okay";
 };
 
+_mem {
+   reg = <0x0 0x8680 0x0 0x580>;
+};
+
 _resin {
status = "okay";
linux,code = ;
@@ -154,6 +160,14 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
 };
 
+ {
+   model = "msm8916-1mic";
+   audio-routing =
+   "AMIC1", "MIC BIAS External1",
+   "AMIC2", "MIC BIAS Internal2",
+   "AMIC3", "MIC BIAS External1";
+};
+
  {
extcon = <>, <>;
status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts 
b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
index 58c2f5a70e78..ba8650971d6a 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
@@ -19,6 +19,10 @@ _i2c5 {
status = "disabled";
 };
 
+_codec {
+   qcom,micbias1-ext-cap;
+};
+
  {
/* FIXME: Missing sm5703-mfd driver to power up vdd-supply */
 };

-- 
2.42.0

[PATCH v2 14/14] arm64: dts: qcom: msm8939-samsung-a7: Add sound and modem

[Stephan Gerhold]

From: "Lin, Meng-Bo" 

Enable sound and modem for the Samsung A7. The setup is similar to most
MSM8916 devices, i.e.:

 - QDSP6 audio
 - Earpiece/headphones/microphones via digital/analog codec in
   MSM8916/PM8916
 - WWAN Internet via BAM-DMUX

except for the same differences as the MSM8916-based Samsung A2015
devices:

 - NXP TFA9895 codec for speaker on Quaternary MI2S
 - Samsung-specific audio jack detection (not supported yet)

Signed-off-by: "Lin, Meng-Bo" 
[Stephan: Add consistent commit message, minor refactoring]
Signed-off-by: Stephan Gerhold 
---
 arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts | 70 +
 1 file changed, 70 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts 
b/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
index fccd8fec8b8f..aa6c39482a2f 100644
--- a/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
+++ b/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
@@ -3,10 +3,12 @@
 /dts-v1/;
 
 #include "msm8939-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
 
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Samsung Galaxy A7 (2015)";
@@ -287,6 +289,18 @@ muic: extcon@25 {
};
 };
 
+_i2c2 {
+   status = "okay";
+
+   speaker_codec: audio-codec@34 {
+   compatible = "nxp,tfa9895";
+   reg = <0x34>;
+   vddd-supply = <_l5>;
+   sound-name-prefix = "Speaker";
+   #sound-dai-cells = <0>;
+   };
+};
+
 _i2c5 {
status = "okay";
 
@@ -309,6 +323,29 @@ _uart2 {
status = "okay";
 };
 
+/*
+ * For some reason the speaker amplifier is connected to the second SD line
+ * (MI2S_2_D1) instead of the first (MI2S_2_D0). This must be configured in the
+ * device tree, otherwise audio will seemingly play fine on the wrong SD line
+ * but the speaker stays silent.
+ *
+ * When routing audio via QDSP6 (the default) the  node is reserved and
+ * the definitions from  are used. When the modem is disabled audio 
can
+ * be alternatively routed directly to the LPASS hardware with reduced latency.
+ * The definitions for  are here for completeness to simplify changing 
the
+ * setup with minor changes to the DT (either manually or with DT overlays).
+ */
+ {
+   dai-link@3 {
+   reg = ;
+   qcom,playback-sd-lines = <1>;
+   };
+};
+
+_mem {
+   reg = <0x0 0x8680 0x0 0x580>;
+};
+
 _resin {
linux,code = ;
status = "okay";
@@ -321,6 +358,13 @@ pm8916_l17: l17 {
};
 };
 
+ {
+   dai@22 {
+   reg = ;
+   qcom,sd-lines = <1>;
+   };
+};
+
 _1 {
status = "okay";
 };
@@ -335,6 +379,32 @@ _2 {
status = "okay";
 };
 
+ {
+   model = "samsung-a2015";
+   audio-routing =
+   "AMIC1", "MIC BIAS External1",
+   "AMIC2", "MIC BIAS Internal2",
+   "AMIC3", "MIC BIAS External1";
+
+   pinctrl-0 = <_pdm_default _mi2s_default>;
+   pinctrl-1 = <_pdm_sleep _mi2s_sleep>;
+   pinctrl-names = "default", "sleep";
+
+   sound_link_backend2: backend2-dai-link {
+   link-name = "Quaternary MI2S";
+
+   cpu {
+   sound-dai = < QUATERNARY_MI2S_RX>;
+   };
+   platform {
+   sound-dai = <>;
+   };
+   codec {
+   sound-dai = <_codec>;
+   };
+   };
+};
+
  {
extcon = <>, <>;
status = "okay";

-- 
2.42.0

[PATCH v2 12/14] arm64: dts: qcom: msm8916-samsung-gt5: Add sound and modem

[Stephan Gerhold]

From: Jasper Korten 

Enable sound and modem for the Samsung Galaxy Tab A 2015 tablets.
The setup is similar to most MSM8916 devices, i.e.:

 - QDSP6 audio
 - Headphones/microphones via digital/analog codec in
   MSM8916/PM8916. Earpiece exists on samsung-gt58 only.
 - WWAN Internet via BAM-DMUX

except:

 - gt510: Stereo Maxim MAX98357A codecs for speaker on Quaternary MI2S
 - gt58: Mono NXP TFA9895 codec for speaker on Quaternary MI2S
   - For some reason connected to GPIOs where no hardware I2C
 controller is available -> need to use i2c-gpio
- Samsung-specific audio jack detection (not supported yet)

Signed-off-by: Jasper Korten 
Co-developed-by: Siddharth Manthan 
Signed-off-by: Siddharth Manthan 
Co-developed-by: Nikita Travkin 
Signed-off-by: Nikita Travkin 
[Stephan: Add consistent commit message, minor refactoring]
Signed-off-by: Stephan Gerhold 
---
 .../boot/dts/qcom/msm8916-samsung-gt5-common.dtsi  | 54 ++
 arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts | 22 +
 arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts  | 42 +
 3 files changed, 118 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
index 6a16eb5ce07b..fbd2caf405d5 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
@@ -3,9 +3,12 @@
 /dts-v1/;
 
 #include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
 #include 
 #include 
 #include 
+#include 
 
 / {
aliases {
@@ -116,6 +119,29 @@ _uart2 {
status = "okay";
 };
 
+/*
+ * For some reason the speaker amplifier is connected to the second SD line
+ * (MI2S_2_D1) instead of the first (MI2S_2_D0). This must be configured in the
+ * device tree, otherwise audio will seemingly play fine on the wrong SD line
+ * but the speaker stays silent.
+ *
+ * When routing audio via QDSP6 (the default) the  node is reserved and
+ * the definitions from  are used. When the modem is disabled audio 
can
+ * be alternatively routed directly to the LPASS hardware with reduced latency.
+ * The definitions for  are here for completeness to simplify changing 
the
+ * setup with minor changes to the DT (either manually or with DT overlays).
+ */
+ {
+   dai-link@3 {
+   reg = ;
+   qcom,playback-sd-lines = <1>;
+   };
+};
+
+_mem {
+   reg = <0x0 0x8680 0x0 0x540>;
+};
+
 _resin {
linux,code = ;
status = "okay";
@@ -133,6 +159,13 @@ _usbin {
status = "okay";
 };
 
+ {
+   dai@22 {
+   reg = ;
+   qcom,sd-lines = <1>;
+   };
+};
+
 _1 {
status = "okay";
 };
@@ -147,6 +180,27 @@ _2 {
status = "okay";
 };
 
+ {
+   audio-routing =
+   "AMIC1", "MIC BIAS External1",
+   "AMIC2", "MIC BIAS Internal2",
+   "AMIC3", "MIC BIAS External1";
+
+   sound_link_backend2: backend2-dai-link {
+   link-name = "Quaternary MI2S";
+
+   cpu {
+   sound-dai = < QUATERNARY_MI2S_RX>;
+   };
+   platform {
+   sound-dai = <>;
+   };
+   codec {
+   sound-dai = <_codec>;
+   };
+   };
+};
+
  {
dr_mode = "peripheral";
extcon = <_usbin>;
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts 
b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
index c3f1acc55078..5b34529b816c 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
@@ -9,6 +9,14 @@ / {
compatible = "samsung,gt510", "qcom,msm8916";
chassis-type = "tablet";
 
+   speaker_codec: audio-codec {
+   compatible = "maxim,max98357a";
+   sdmode-gpios = < 55 GPIO_ACTIVE_HIGH>;
+   #sound-dai-cells = <0>;
+   pinctrl-0 = <_sdmode_default>;
+   pinctrl-names = "default";
+   };
+
clk_pwm: pwm {
compatible = "clk-pwm";
#pwm-cells = <2>;
@@ -146,7 +154,21 @@ _dsi0_out {
remote-endpoint = <_in>;
 };
 
+ {
+   model = "samsung-gt510";
+   pinctrl-0 = <_pdm_default _mi2s_default>;
+   pinctrl-1 = <_pdm_sleep _mi2s_sleep>;
+   pinctrl-names = "default", "sleep";
+};
+
  {
+   audio_sdmode_default: audio-sdmode-default-state {
+   pins = "gpio55";
+   function = "gpio";
+   drive-strength = <2>;
+   bias-disable;
+   };
+
buckbooster_en_default: buckbooster-en-default-state {
pins = "gpio51";
function = "gpio";
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts 
b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts
index 998625abd409..579312ed53ce 100644
--- 

[PATCH v2 07/14] arm64: dts: qcom: msm8916-wingtech-wt88047: Add sound and modem

[Stephan Gerhold]

Enable sound and modem for the Xiaomi Redmi 2. The setup
is similar to most MSM8916 devices, i.e.:

 - QDSP6 audio
 - Earpiece/headphones/microphones via digital/analog codec in
   MSM8916/PM8916
 - Audio jack detection via analog codec in PM8916
 - WWAN Internet via BAM-DMUX

except:

 - Speaker amplifier is connected to HPH_R (headphones) output of the
   analog codec. There is a separate analog switch that allows disabling
   playback via the headphone jack.

Reviewed-by: Konrad Dybcio 
Signed-off-by: Stephan Gerhold 
---
 .../boot/dts/qcom/msm8916-wingtech-wt88047.dts | 74 ++
 1 file changed, 74 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts 
b/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
index 419f35c1fc92..d4b88c787e59 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
@@ -6,6 +6,8 @@
 /dts-v1/;
 
 #include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
 #include 
 #include 
 #include 
@@ -25,6 +27,28 @@ chosen {
stdout-path = "serial0";
};
 
+   speaker_amp: audio-amplifier {
+   compatible = "simple-audio-amplifier";
+   enable-gpios = < 117 GPIO_ACTIVE_HIGH>;
+   sound-name-prefix = "Speaker Amp";
+   pinctrl-0 = <_amp_default>;
+   pinctrl-names = "default";
+   };
+
+   /*
+* This seems to be actually an analog switch that either routes audio
+* to the headphone jack or nowhere. Given that we need to enable a GPIO
+* to get sound on headphones, modelling it as simple-audio-amplifier
+* works just fine.
+*/
+   headphones_switch: audio-switch {
+   compatible = "simple-audio-amplifier";
+   enable-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   sound-name-prefix = "Headphones Switch";
+   pinctrl-0 = <_switch_default>;
+   pinctrl-names = "default";
+   };
+
flash-led-controller {
compatible = "ocs,ocp8110";
enable-gpios = < 31 GPIO_ACTIVE_HIGH>;
@@ -146,6 +170,18 @@ _uart2 {
status = "okay";
 };
 
+_mem {
+   reg = <0x0 0x8680 0x0 0x510>;
+};
+
+_codec {
+   qcom,micbias1-ext-cap;
+   qcom,micbias-lvl = <2800>;
+   qcom,mbhc-vthreshold-low = <75 100 120 180 500>;
+   qcom,mbhc-vthreshold-high = <75 100 120 180 500>;
+   qcom,hphl-jack-type-normally-open;
+};
+
 _resin {
status = "okay";
linux,code = ;
@@ -180,6 +216,30 @@ _2 {
non-removable;
 };
 
+ {
+   /*
+* Provide widgets/pin-switches to allow enabling speaker and headphones
+* separately. Both are routed via the HPH_L/HPH_R pins of the codec.
+*/
+   model = "wt88047";
+   widgets =
+   "Speaker", "Speaker",
+   "Headphone", "Headphones";
+   pin-switches = "Speaker", "Headphones";
+   audio-routing =
+   "Speaker", "Speaker Amp OUTL",
+   "Speaker", "Speaker Amp OUTR",
+   "Speaker Amp INL", "HPH_R",
+   "Speaker Amp INR", "HPH_R",
+   "Headphones", "Headphones Switch OUTL",
+   "Headphones", "Headphones Switch OUTR",
+   "Headphones Switch INL", "HPH_L",
+   "Headphones Switch INR", "HPH_R",
+   "AMIC1", "MIC BIAS External1",
+   "AMIC2", "MIC BIAS Internal2";
+   aux-devs = <_amp>, <_switch>;
+};
+
  {
status = "okay";
extcon = <_id>, <_id>;
@@ -226,6 +286,13 @@ gpio_keys_default: gpio-keys-default-state {
bias-pull-up;
};
 
+   headphones_switch_default: headphones-switch-default-state {
+   pins = "gpio8";
+   function = "gpio";
+   drive-strength = <2>;
+   bias-disable;
+   };
+
imu_default: imu-default-state {
pins = "gpio115";
function = "gpio";
@@ -234,6 +301,13 @@ imu_default: imu-default-state {
bias-disable;
};
 
+   speaker_amp_default: speaker-amp-default-state {
+   pins = "gpio117";
+   function = "gpio";
+   drive-strength = <2>;
+   bias-disable;
+   };
+
touchscreen_default: touchscreen-default-state {
touchscreen-pins {
pins = "gpio13";

-- 
2.42.0

[PATCH v2 03/14] arm64: dts: qcom: msm8939: Add QDSP6

[Stephan Gerhold]

MSM8939 does not have a dedicated ADSP. Instead, the audio services via
APR are also implemented by the modem DSP. Audio can be either routed
via the modem DSP (necessary for voice call audio etc) or directly sent
to the LPASS hardware (currently used by DB410c). Bypassing QDSP6 audio
is only possible with special firmware (on DB410c) or when the modem
DSP is completely disabled.

Add the typical nodes for QDSP6 audio to msm8939.dtsi. The apr node is
disabled by default to avoid changing behavior for devices like
apq8039-t2 that use the bypassed audio path.

Signed-off-by: Stephan Gerhold 
---
 arch/arm64/boot/dts/qcom/msm8939.dtsi | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi 
b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index 65c68e0e88d5..95610a32750a 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 / {
@@ -1615,6 +1616,54 @@ smd-edge {
qcom,remote-pid = <1>;
 
label = "hexagon";
+
+   apr: apr {
+   compatible = "qcom,apr-v2";
+   qcom,smd-channels = "apr_audio_svc";
+   qcom,domain = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   q6core: service@3 {
+   compatible = "qcom,q6core";
+   reg = ;
+   };
+
+   q6afe: service@4 {
+   compatible = "qcom,q6afe";
+   reg = ;
+
+   q6afedai: dais {
+   compatible = 
"qcom,q6afe-dais";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #sound-dai-cells = <1>;
+   };
+   };
+
+   q6asm: service@7 {
+   compatible = "qcom,q6asm";
+   reg = ;
+
+   q6asmdai: dais {
+   compatible = 
"qcom,q6asm-dais";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #sound-dai-cells = <1>;
+   };
+   };
+
+   q6adm: service@8 {
+   compatible = "qcom,q6adm";
+   reg = ;
+
+   q6routing: routing {
+   compatible = 
"qcom,q6adm-routing";
+   #sound-dai-cells = <0>;
+   };
+   };
+   };
};
};
 

-- 
2.42.0

[PATCH v2 06/14] arm64: dts: qcom: msm8916-samsung-serranove: Add sound and modem

[Stephan Gerhold]

Enable sound and modem for the Samsung S4 Mini Value Edition. The setup
is similar to most MSM8916 devices, i.e.:

 - QDSP6 audio
 - Speaker/earpiece/headphones/microphones via digital/analog codec in
   MSM8916/PM8916
 - WWAN Internet via BAM-DMUX

except:

 - Samsung-specific audio jack detection (not supported yet)

Signed-off-by: Stephan Gerhold 
---
 arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts 
b/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
index 68da2a2d3077..5ce8f1350abc 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
@@ -6,6 +6,8 @@
 /dts-v1/;
 
 #include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
 #include 
 #include 
 #include 
@@ -319,6 +321,10 @@ _uart2 {
status = "okay";
 };
 
+_mem {
+   reg = <0x0 0x8680 0x0 0x5a0>;
+};
+
 _resin {
status = "okay";
linux,code = ;
@@ -350,6 +356,13 @@ _2 {
no-1-8-v;
 };
 
+ {
+   audio-routing =
+   "AMIC1", "MIC BIAS External1",
+   "AMIC2", "MIC BIAS Internal2",
+   "AMIC3", "MIC BIAS External1";
+};
+
  {
status = "okay";
extcon = <>, <>;

-- 
2.42.0

[PATCH v2 04/14] arm64: dts: qcom: msm8916: Add common msm8916-modem-qdsp6.dtsi

[Stephan Gerhold]

Most MSM8916/MSM8939 devices use very similar setups for the modem,
because most of the device-specific details are abstracted by the modem
firmware. There are several definitions (status switches, DAI links
etc) that will be exactly the same for every board.

Introduce a common msm8916-modem-qdsp6.dtsi include that can be used to
simplify enabling the modem for such devices. By default the
digital/analog codec in the SoC/PMIC is used, but boards can define
additional codecs by adding additional backend DAI links.

Signed-off-by: Stephan Gerhold 
---
 arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi | 148 ++
 1 file changed, 148 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
new file mode 100644
index ..039961622633
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
+/*
+ * msm8916-modem-qdsp6.dtsi describes the typical modem setup on MSM8916 
devices
+ * (or similar SoCs) with audio routed via the QDSP6 services provided by the
+ * modem firmware. The digital/analog codec in the SoC/PMIC is used by default,
+ * but boards can define additional codecs by adding additional backend DAI 
links.
+ */
+
+#include 
+#include 
+
+ {
+   status = "okay";
+};
+
+_dmux {
+   status = "okay";
+};
+
+_dmux_dma {
+   status = "okay";
+};
+
+ {
+   status = "reserved"; /* Controlled by QDSP6 */
+};
+
+_codec {
+   status = "okay";
+};
+
+_mem {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_mem {
+   status = "okay";
+};
+
+_codec {
+   status = "okay";
+};
+
+ {
+   dai@16 {
+   reg = ;
+   qcom,sd-lines = <0 1>;
+   };
+   dai@20 {
+   reg = ;
+   qcom,sd-lines = <0 1>;
+   };
+};
+
+ {
+   dai@0 {
+   reg = <0>;
+   direction = ;
+   };
+   dai@1 {
+   reg = <1>;
+   direction = ;
+   };
+   dai@2 {
+   reg = <2>;
+   direction = ;
+   };
+   dai@3 {
+   reg = <3>;
+   direction = ;
+   is-compress-dai;
+   };
+};
+
+ {
+   compatible = "qcom,msm8916-qdsp6-sndcard";
+   model = "msm8916";
+
+   pinctrl-0 = <_pdm_default>;
+   pinctrl-1 = <_pdm_sleep>;
+   pinctrl-names = "default", "sleep";
+
+   status = "okay";
+
+   frontend0-dai-link {
+   link-name = "MultiMedia1";
+
+   cpu {
+   sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA1>;
+   };
+   };
+
+   frontend1-dai-link {
+   link-name = "MultiMedia2";
+
+   cpu {
+   sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA2>;
+   };
+   };
+
+   frontend2-dai-link {
+   link-name = "MultiMedia3";
+
+   cpu {
+   sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA3>;
+   };
+   };
+
+   frontend3-dai-link {
+   link-name = "MultiMedia4";
+
+   cpu {
+   sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA4>;
+   };
+   };
+
+   sound_link_backend0: backend0-dai-link {
+   link-name = "Primary MI2S";
+
+   cpu {
+   sound-dai = < PRIMARY_MI2S_RX>;
+   };
+   platform {
+   sound-dai = <>;
+   };
+   codec {
+   sound-dai = <_codec 0>, <_codec 0>;
+   };
+   };
+
+   sound_link_backend1: backend1-dai-link {
+   link-name = "Tertiary MI2S";
+
+   cpu {
+   sound-dai = < TERTIARY_MI2S_TX>;
+   };
+   platform {
+   sound-dai = <>;
+   };
+   codec {
+   sound-dai = <_codec 1>, <_codec 1>;
+   };
+   };
+};

-- 
2.42.0

[PATCH v2 05/14] arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem

[Stephan Gerhold]

Enable sound and modem for the Samsung A2015 based devices (A3, A5, E5,
E7, Grand Max). The setup is similar to most MSM8916 devices, i.e.:

 - QDSP6 audio
 - Earpiece/headphones/microphones via digital/analog codec in
   MSM8916/PM8916
 - WWAN Internet via BAM-DMUX

except:

 - NXP TFA9895 codec for speaker on Quaternary MI2S
 - Samsung-specific audio jack detection (not supported yet)

[Lin: Add e2015 and grandmax]
Co-developed-by: "Lin, Meng-Bo" 
Signed-off-by: "Lin, Meng-Bo" 
Signed-off-by: Stephan Gerhold 
---
 .../dts/qcom/msm8916-samsung-a2015-common.dtsi | 71 ++
 .../dts/qcom/msm8916-samsung-e2015-common.dtsi |  4 ++
 .../boot/dts/qcom/msm8916-samsung-grandmax.dts |  4 ++
 3 files changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
index 0b29132b74e1..2937495940ea 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
@@ -1,10 +1,13 @@
 // SPDX-License-Identifier: GPL-2.0-only
 
 #include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
 #include 
 #include 
 #include 
 #include 
+#include 
 
 / {
aliases {
@@ -196,6 +199,18 @@ vibrator: vibrator {
};
 };
 
+_i2c1 {
+   status = "okay";
+
+   speaker_codec: audio-codec@34 {
+   compatible = "nxp,tfa9895";
+   reg = <0x34>;
+   vddd-supply = <_l5>;
+   sound-name-prefix = "Speaker";
+   #sound-dai-cells = <0>;
+   };
+};
+
 _i2c2 {
status = "okay";
 
@@ -243,6 +258,25 @@  {
status = "okay";
 };
 
+/*
+ * For some reason the speaker amplifier is connected to the second SD line
+ * (MI2S_2_D1) instead of the first (MI2S_2_D0). This must be configured in the
+ * device tree, otherwise audio will seemingly play fine on the wrong SD line
+ * but the speaker stays silent.
+ *
+ * When routing audio via QDSP6 (the default) the  node is reserved and
+ * the definitions from  are used. When the modem is disabled audio 
can
+ * be alternatively routed directly to the LPASS hardware with reduced latency.
+ * The definitions for  are here for completeness to simplify changing 
the
+ * setup with minor changes to the DT (either manually or with DT overlays).
+ */
+ {
+   dai-link@3 {
+   reg = ;
+   qcom,playback-sd-lines = <1>;
+   };
+};
+
  {
status = "okay";
 };
@@ -253,6 +287,10 @@ _dsi0 {
pinctrl-1 = <_sleep>;
 };
 
+_mem {
+   reg = <0x0 0x8680 0x0 0x540>;
+};
+
 _resin {
status = "okay";
linux,code = ;
@@ -265,6 +303,13 @@ pm8916_l17: l17 {
};
 };
 
+ {
+   dai@22 {
+   reg = ;
+   qcom,sd-lines = <1>;
+   };
+};
+
 _1 {
status = "okay";
 };
@@ -279,6 +324,32 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
 };
 
+ {
+   model = "samsung-a2015";
+   audio-routing =
+   "AMIC1", "MIC BIAS External1",
+   "AMIC2", "MIC BIAS Internal2",
+   "AMIC3", "MIC BIAS External1";
+
+   pinctrl-0 = <_pdm_default _mi2s_default>;
+   pinctrl-1 = <_pdm_sleep _mi2s_sleep>;
+   pinctrl-names = "default", "sleep";
+
+   sound_link_backend2: backend2-dai-link {
+   link-name = "Quaternary MI2S";
+
+   cpu {
+   sound-dai = < QUATERNARY_MI2S_RX>;
+   };
+   platform {
+   sound-dai = <>;
+   };
+   codec {
+   sound-dai = <_codec>;
+   };
+   };
+};
+
  {
status = "okay";
extcon = <>, <>;
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
index 0824ab041d80..3c49dac92d2d 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
@@ -65,6 +65,10 @@ accelerometer@1d {
};
 };
 
+_mem {
+   reg = <0x0 0x8680 0x0 0x5a0>;
+};
+
 _motor_vdd {
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts 
b/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
index 3f145dde4059..5882b3a593b8 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
@@ -49,6 +49,10 @@ _touch_key {
status = "disabled";
 };
 
+ {
+   model = "samsung-gmax"; /* No secondary microphone */
+};
+
  {
gpio_leds_default: gpio-led-default-state {
pins = "gpio60";

-- 
2.42.0

[PATCH v2 02/14] arm64: dts: qcom: msm8916: Add QDSP6

[Stephan Gerhold]

MSM8916 does not have a dedicated ADSP. Instead, the audio services via
APR are also implemented by the modem DSP. Audio can be either routed
via the modem DSP (necessary for voice call audio etc) or directly sent
to the LPASS hardware (currently used by DB410c). Bypassing QDSP6 audio
is only possible with special firmware (on DB410c) or when the modem
DSP is completely disabled.

Add the typical nodes for QDSP6 audio to msm8916.dtsi. The apr node is
disabled by default to avoid changing behavior for devices like DB410c
that use the bypassed audio path.

Signed-off-by: Stephan Gerhold 
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 4f799b536a92..e8a14dd7e7c2 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 / {
@@ -1989,6 +1990,54 @@ smd-edge {
 
label = "hexagon";
 
+   apr: apr {
+   compatible = "qcom,apr-v2";
+   qcom,smd-channels = "apr_audio_svc";
+   qcom,domain = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   q6core: service@3 {
+   compatible = "qcom,q6core";
+   reg = ;
+   };
+
+   q6afe: service@4 {
+   compatible = "qcom,q6afe";
+   reg = ;
+
+   q6afedai: dais {
+   compatible = 
"qcom,q6afe-dais";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #sound-dai-cells = <1>;
+   };
+   };
+
+   q6asm: service@7 {
+   compatible = "qcom,q6asm";
+   reg = ;
+
+   q6asmdai: dais {
+   compatible = 
"qcom,q6asm-dais";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #sound-dai-cells = <1>;
+   };
+   };
+
+   q6adm: service@8 {
+   compatible = "qcom,q6adm";
+   reg = ;
+
+   q6routing: routing {
+   compatible = 
"qcom,q6adm-routing";
+   #sound-dai-cells = <0>;
+   };
+   };
+   };
+
fastrpc {
compatible = "qcom,fastrpc";
qcom,smd-channels = 
"fastrpcsmd-apps-dsp";

-- 
2.42.0

[PATCH v2 00/14] arm64: dts: qcom: msm8916/39: Enable sound and modem with QDSP6

[Stephan Gerhold]

Enable sound and modem on most of the MSM8916/MSM8939 
smartphones/tablets supported upstream by:

 - Adding the BAM-DMUX DT nodes to msm8939.dtsi for WWAN Internet
 - Adding the QDSP6 DT nodes to both msm8916.dtsi and msm8939.dtsi.
   This is needed because audio must be routed through the QDSP6 
   services provided by the modem firmware when the modem is active.
 - Setting up the sound/codec related nodes for all the devices.

Most of the sound/modem setup is very similar on all MSM8916/MSM8939 
devices because the device-specific details are abstracted by the modem 
firmware. Reduce duplication by adding "msm8916-modem-qdsp6.dtsi" which 
contains most of the common definitions. The board-specific DT part is 
limited to extra codecs or board-specific sound setup.

With this patch set, the following functionality works on most 
MSM8916/MSM8939 devices supported upstream:

 - Sound: Speaker/earpiece/headphones/microphones
 - Modem: Calls, SMS, WWAN Internet (e.g. with ModemManager)

And with extra pending patches also:

 - Voice call audio
 - GPS

These patches have been contributed by different people and have been 
used/tested in postmarketOS for several years. Until now they had to 
wait for other changes to be upstreamed (QDSP6 audio support for 
MSM8916, dynamic reserved memory, ...).

Signed-off-by: Stephan Gerhold 
---
Changes in v2:
- msm8916-modem-qdsp6.dtsi: Add some missing new lines (Konrad)
- msm8916-modem-qdsp6.dtsi: Avoid unused template nodes (Konrad)
  - Refactored/cleaned up dai-link nodes a bit to fix this
- Split up msm8916.dtsi and msm8939.dtsi QDSP6 patch (Konrad)
- Clarify purpose of  node with a comment (Konrad)
- Move around status properties a bit for more clarity (Konrad)
- Link to v1: 
https://lore.kernel.org/r/20230926-msm8916-modem-v1-0-398eec74b...@gerhold.net

---
J.R. Divya Antony (1):
  arm64: dts: qcom: msm8916-asus-z00l: Add sound and modem

Jasper Korten (1):
  arm64: dts: qcom: msm8916-samsung-gt5: Add sound and modem

Jonathan Albrieux (1):
  arm64: dts: qcom: msm8916-longcheer-l8910: Add sound and modem

Lin, Meng-Bo (2):
  arm64: dts: qcom: msm8916-samsung-j5: Add sound and modem
  arm64: dts: qcom: msm8939-samsung-a7: Add sound and modem

Nikita Travkin (1):
  arm64: dts: qcom: msm8916-longcheer-l8150: Add sound and modem

Stephan Gerhold (6):
  arm64: dts: qcom: msm8916: Add QDSP6
  arm64: dts: qcom: msm8939: Add QDSP6
  arm64: dts: qcom: msm8916: Add common msm8916-modem-qdsp6.dtsi
  arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem
  arm64: dts: qcom: msm8916-samsung-serranove: Add sound and modem
  arm64: dts: qcom: msm8916-wingtech-wt88047: Add sound and modem

Vincent Knecht (2):
  arm64: dts: qcom: msm8939: Add BAM-DMUX WWAN
  arm64: dts: qcom: msm8916-alcatel-idol347: Add sound and modem

 .../boot/dts/qcom/msm8916-alcatel-idol347.dts  | 171 +
 arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts |  21 +++
 .../boot/dts/qcom/msm8916-longcheer-l8150.dts  |  31 +++-
 .../boot/dts/qcom/msm8916-longcheer-l8910.dts  |  52 +++
 arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi  | 148 ++
 .../dts/qcom/msm8916-samsung-a2015-common.dtsi |  71 +
 .../dts/qcom/msm8916-samsung-e2015-common.dtsi |   4 +
 .../boot/dts/qcom/msm8916-samsung-grandmax.dts |   4 +
 .../boot/dts/qcom/msm8916-samsung-gt5-common.dtsi  |  54 +++
 arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts |  22 +++
 arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts  |  42 +
 .../boot/dts/qcom/msm8916-samsung-j5-common.dtsi   |  14 ++
 arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts|   4 +
 .../boot/dts/qcom/msm8916-samsung-serranove.dts|  13 ++
 .../boot/dts/qcom/msm8916-wingtech-wt88047.dts |  74 +
 arch/arm64/boot/dts/qcom/msm8916.dtsi  |  49 ++
 arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts|  70 +
 arch/arm64/boot/dts/qcom/msm8939.dtsi  |  79 ++
 18 files changed, 920 insertions(+), 3 deletions(-)
---
change-id: 20230922-msm8916-modem-0d8b6c8abf76

Best regards,
-- 
Stephan Gerhold  

[PATCH v2 01/14] arm64: dts: qcom: msm8939: Add BAM-DMUX WWAN

[Stephan Gerhold]

From: Vincent Knecht 

BAM DMUX is used as the network interface to the modem. This is copied
as-is from msm8916.dtsi.

Signed-off-by: Vincent Knecht 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Stephan Gerhold 
---
 arch/arm64/boot/dts/qcom/msm8939.dtsi | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi 
b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index 324b5d26db40..65c68e0e88d5 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -1537,6 +1537,20 @@ spmi_bus: spmi@200f000 {
#interrupt-cells = <4>;
};
 
+   bam_dmux_dma: dma-controller@4044000 {
+   compatible = "qcom,bam-v1.7.0";
+   reg = <0x04044000 0x19000>;
+   interrupts = ;
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+
+   num-channels = <6>;
+   qcom,num-ees = <1>;
+   qcom,powered-remotely;
+
+   status = "disabled";
+   };
+
mpss: remoteproc@408 {
compatible = "qcom,msm8916-mss-pil";
reg = <0x0408 0x100>, <0x0402 0x040>;
@@ -1569,6 +1583,22 @@ mpss: remoteproc@408 {
qcom,halt-regs = < 0x18000 0x19000 0x1a000>;
status = "disabled";
 
+   bam_dmux: bam-dmux {
+   compatible = "qcom,bam-dmux";
+
+   interrupt-parent = <_smsm>;
+   interrupts = <1 IRQ_TYPE_EDGE_BOTH>, <11 
IRQ_TYPE_EDGE_BOTH>;
+   interrupt-names = "pc", "pc-ack";
+
+   qcom,smem-states = <_smsm 1>, <_smsm 
11>;
+   qcom,smem-state-names = "pc", "pc-ack";
+
+   dmas = <_dmux_dma 4>, <_dmux_dma 5>;
+   dma-names = "tx", "rx";
+
+   status = "disabled";
+   };
+
mba {
memory-region = <_mem>;
};

-- 
2.42.0

[PATCH v5] mm: multi-gen LRU: reuse some legacy trace events

[Jaewon Kim]

As the legacy lru provides, the mglru needs some trace events for
debugging. Let's reuse following legacy events for the mglru.

  trace_mm_vmscan_lru_isolate
  trace_mm_vmscan_lru_shrink_inactive

Here's an example
  mm_vmscan_lru_isolate: classzone=2 order=0 nr_requested=4096 nr_scanned=64 
nr_skipped=0 nr_taken=64 lru=inactive_file
  mm_vmscan_lru_shrink_inactive: nid=0 nr_scanned=64 nr_reclaimed=63 nr_dirty=0 
nr_writeback=0 nr_congested=0 nr_immediate=0 nr_activate_anon=0 
nr_activate_file=1 nr_ref_keep=0 nr_unmap_fail=0 priority=2 
flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC

Signed-off-by: Jaewon Kim 
Acked-by: Yu Zhao 
---
v5: reuse the legacy trace events
v4: wrap with #ifdef CONFIG_LRU_GEN
v3: change printk format
v2: use condition and make it aligned
v1: introduce trace events
---
 mm/vmscan.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 6f13394b112e..3f963f3616ea 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -5005,6 +5005,7 @@ static int scan_folios(struct lruvec *lruvec, struct 
scan_control *sc,
int sorted = 0;
int scanned = 0;
int isolated = 0;
+   int skipped = 0;
int remaining = MAX_LRU_BATCH;
struct lru_gen_folio *lrugen = >lrugen;
struct mem_cgroup *memcg = lruvec_memcg(lruvec);
@@ -5018,7 +5019,7 @@ static int scan_folios(struct lruvec *lruvec, struct 
scan_control *sc,
 
for (i = MAX_NR_ZONES; i > 0; i--) {
LIST_HEAD(moved);
-   int skipped = 0;
+   int skipped_zone = 0;
int zone = (sc->reclaim_idx + i) % MAX_NR_ZONES;
struct list_head *head = >folios[gen][type][zone];
 
@@ -5040,16 +5041,17 @@ static int scan_folios(struct lruvec *lruvec, struct 
scan_control *sc,
isolated += delta;
} else {
list_move(>lru, );
-   skipped += delta;
+   skipped_zone += delta;
}
 
-   if (!--remaining || max(isolated, skipped) >= 
MIN_LRU_BATCH)
+   if (!--remaining || max(isolated, skipped_zone) >= 
MIN_LRU_BATCH)
break;
}
 
-   if (skipped) {
+   if (skipped_zone) {
list_splice(, head);
-   __count_zid_vm_events(PGSCAN_SKIP, zone, skipped);
+   __count_zid_vm_events(PGSCAN_SKIP, zone, skipped_zone);
+   skipped += skipped_zone;
}
 
if (!remaining || isolated >= MIN_LRU_BATCH)
@@ -5064,6 +5066,9 @@ static int scan_folios(struct lruvec *lruvec, struct 
scan_control *sc,
__count_memcg_events(memcg, item, isolated);
__count_memcg_events(memcg, PGREFILL, sorted);
__count_vm_events(PGSCAN_ANON + type, isolated);
+   trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, MAX_LRU_BATCH,
+   scanned, skipped, isolated,
+   type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON);
 
/*
 * There might not be eligible folios due to reclaim_idx. Check the
@@ -5194,6 +5199,9 @@ static int evict_folios(struct lruvec *lruvec, struct 
scan_control *sc, int swap
 retry:
reclaimed = shrink_folio_list(, pgdat, sc, , false);
sc->nr_reclaimed += reclaimed;
+   trace_mm_vmscan_lru_shrink_inactive(pgdat->node_id,
+   scanned, reclaimed, , sc->priority,
+   type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON);
 
list_for_each_entry_safe_reverse(folio, next, , lru) {
if (!folio_evictable(folio)) {
-- 
2.17.1

Re: [PATCH v1 1/1] ACPI: NFIT: Switch to use acpi_evaluate_dsm_typed()

[Andy Shevchenko]

On Mon, Oct 02, 2023 at 10:27:02PM +0200, Wilczynski, Michal wrote:
> On 10/2/2023 3:54 PM, Andy Shevchenko wrote:

...

> > +   out_obj = acpi_evaluate_dsm_typed(handle, guid, revid, func, _obj, 
> > ACPI_TYPE_BUFFER);
> 
> This line is 90 characters long, wouldn't it be better to split it ?

I dunno it's a problem, but if people insist, I can redo that.

...

> > +   if (!out_obj || out_obj->buffer.length < sizeof(smart)) {
> > dev_dbg(dev->parent, "%s: failed to retrieve initial health\n",
> > dev_name(dev));
> 
> While at it maybe fix alignment ? :-)

I don't think it's in scope of this change.

> > ACPI_FREE(out_obj);
> 
> Just nitpicks, functionally code seems correct to me.
> Reviewed-by: Michal Wilczynski 

Thank you!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 02/18] cgroup/misc: Add SGX EPC resource type and export APIs for SGX driver

[Haitao Huang]

On Wed, 27 Sep 2023 22:59:12 -0500, Huang, Kai  wrote:


On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:

From: Kristen Carlson Accardi 

Add SGX EPC memory, MISC_CG_RES_SGX_EPC, to be a valid resource type
for the misc controller.

Add per resource type private data so that SGX can store additional per
cgroup data in misc_cg->misc_cg_res[MISC_CG_RES_SGX_EPC].


To be honest I don't quite understand why putting the above two changes  
in this

patch together with exporting misc_cg_root/parent() below.

Any reason why the above two cannot be done together with patch ("  
x86/sgx:
Limit process EPC usage with misc cgroup controller"), where these  
changes are

actually related?

We all already know that a new EPC misc cgroup will be added.  There's  
no need
to actually introduce the new type here only to justify exporting some  
helper

functions.



I think previous authors intended to separate all prerequisite misc  
changes from SGX changes.

I can combine them if maintainers are fine with it.



Export misc_cg_root() so the SGX driver can initialize and add those
additional structures to the root misc cgroup as part of initialization
for EPC cgroup support. This bootstraps the same additional
initialization for non-root cgroups in the 'alloc()' callback added in  
the

previous patch.

The SGX driver, as the EPC memory provider, will have a background
worker to reclaim EPC pages to make room for new allocations in the same
cgroup when its usage counter reaches near the limit controlled by the
cgroup and its ancestors. Therefore it needs to do a walk from the
current cgroup up to the root. To enable this walk, move parent_misc()
into misc_cgroup.h and make inline to make this function available to
SGX, rename it to misc_cg_parent(), and update kernel/cgroup/misc.c to
use the new name.


Looks too many details in the above two paragraphs.  Could we have a more
concise justification for exporting these two functions?



This was added to address Jarkko's question, "why does SGX driver need to  
do iterative walks?"

See: https://lore.kernel.org/all/CVHOU5G1SCUT.RCBVZ3W8G2NJ@suppilovahvero/

And if it were me, I would put it at a relatively later position (e.g.,  
before
the patch actually implements EPC cgroup) for better review.  This also  
applies

to the first patch.



I was told to move all prerequisites to the front or separate out.

https://lore.kernel.org/linux-sgx/CU4H43P3H35X.1BCA3CE4D1250@seitikki/

Re: [PATCH v5 09/18] x86/sgx: Store struct sgx_encl when allocating new VA pages

[Haitao Huang]

On Wed, 27 Sep 2023 06:35:57 -0500, Huang, Kai  wrote:


On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:

From: Sean Christopherson 

In a later patch, when a cgroup has exceeded the max capacity for EPC
pages, it may need to identify and OOM kill a less active enclave to
make room for other enclaves within the same group. Such a victim
enclave would have no active pages other than the unreclaimable Version
Array (VA) and SECS pages.


What does "no active pages" mean?



EPC pages in use.

A "less active enclave" doesn't necessarily mean it has "no active  
pages"?




I'll rephrase the above sentences




Therefore, the cgroup needs examine its

^
needs to


unreclaimable page list, and finding an enclave given a SECS page or a

^
find


VA page. This will require a backpointer from a page to an enclave,
which is not available for VA pages.

Because struct sgx_epc_page instances of VA pages are not owned by an
sgx_encl_page instance, mark their owner as sgx_encl: pass the struct
sgx_encl of the enclave allocating the VA page to sgx_alloc_epc_page(),
which will store this value in the owner field of the struct
sgx_epc_page.


IMHO this paragraph is hard to understand and can be more concise:

One VA page can be shared by multiple enclave pages thus cannot be  
associated
with any 'struct sgx_encl_page' instance.  Set the owner of VA page to  
the

enclave instead.




Agreed


In a later patch, VA pages will be placed in an
unreclaimable queue that can be examined by the cgroup to select the OOM
killed enclave.


The code to "place the VA page to unreclaimable queue" has been done in  
earlier
patch ("x86/sgx: Introduce EPC page states").  Just the unreclaimable  
list isn't
introduced yet.  I think you should just introduce it first then you can  
get rid

of those "in a later patch" staff.



I hope I was able to clarify to you in other threads that VA pages are not  
placed in any queue/list until [PATCH v5 11/18] x86/sgx: store  
unreclaimable pages in LRU lists.


This patch is the first one to implement tracking for unreclaimable pages.  
I'll add that as a transition hint.



And nit: please use "unreclaimable list" consistently (not queue).



Yes will do



Btw, probably a dumb question:

Theoretically if you only need to find a victim enclave you don't need  
to put VA
pages to the unreclaimable list, because those VA pages will be freed  
anyway
when enclave is killed.  So keeping VA pages in the list is for  
accounting all

the pages that the cgroup is having?


Yes basically tracking them in cgroups as they are allocated.

VAs and SECS may also come and go as swapping/unswapping happens. But if a  
cgroup is OOM, and all reclaimables are gone (swapped out), it'd have to  
reclaim VAs/SECs in the same cgroup starting from the front of the LRU  
list. To reclaim a VA/SECS, it identifies the enclave from the owner of  
the VA/SECS page and kills it, as killing enclave is the only way to  
reclaim VA/SECS pages.