[PATCH 2/2] drivers: remoteproc: Add C906L controller for Sophgo CV1800B SoC

Add initial support for the C906L remote processor found in the Sophgo CV1800B SoC. The C906L is an asymmetric core typically used to run an RTOS. This driver enables firmware loading and start/stop control of the C906L processor via the remoteproc framework. The C906L and the main application pro

[PATCH 1/2] dt-bindings: remoteproc: Add C906L rproc for Sophgo CV1800B SoC

Add C906L remote processor for CV1800B SoC, which is an asymmetric processor typically running RTOS. Signed-off-by: Junhui Liu --- .../bindings/remoteproc/sophgo,cv1800b-c906l.yaml | 68 ++ 1 file changed, 68 insertions(+) diff --git a/Documentation/devicetree/bindings/rem

[PATCH 0/2] remoteproc: cv1800b: Add initial support for C906L processor

This patch series introduces initial support for the C906L remote processor in the Sophgo CV1800B SoC. The CV1800B SoC integrates multiple cores, including a main application core running Linux, a C906L core typically running RTOS, and an 8051 MCU. The C906L is an asymmetric processor designed to

Re: [PATCH v4 6/7] mm/maps: read proc/pid/maps under per-vma lock

On Sat, Jun 7, 2025 at 10:43 AM Lorenzo Stoakes wrote: > > Hi Suren, > > Forgive me but I am going to ask a lot of questions here :p just want to > make sure I'm getting everything right here. No worries and thank you for reviewing! > > On Wed, Jun 04, 2025 at 04:11:50PM -0700, Suren Baghdasarya

Re: [PATCH v4 2/4] media: qcom: camss: Add support for MSM8939

Le vendredi 06 juin 2025 à 13:59 +0300, Vladimir Zapolskiy a écrit : > Hello Vincent. > > On 6/2/25 20:27, Vincent Knecht via B4 Relay wrote: > > From: Vincent Knecht > > > > The camera subsystem for the MSM8939 is the same as MSM8916 except with > > 3 CSID instead of 2, and some higher clock ra

Re: [PATCH] vhost-scsi: Fix check for inline_sg_cnt exceeding preallocated limit

On 6/7/25 2:40 PM, Alok Tiwari wrote: > The condition comparing ret to VHOST_SCSI_PREALLOC_SGLS was incorrect, > as ret holds the result of kstrtouint() (typically 0 on success), > not the parsed value. Update the check to use cnt, which contains the > actual user-provided value. > > prevents sile

[PATCH] vhost-scsi: Fix check for inline_sg_cnt exceeding preallocated limit

The condition comparing ret to VHOST_SCSI_PREALLOC_SGLS was incorrect, as ret holds the result of kstrtouint() (typically 0 on success), not the parsed value. Update the check to use cnt, which contains the actual user-provided value. prevents silently accepting values exceeding the maximum inline

Re: [PATCH v4 6/7] mm/maps: read proc/pid/maps under per-vma lock

Hi Suren, Forgive me but I am going to ask a lot of questions here :p just want to make sure I'm getting everything right here. On Wed, Jun 04, 2025 at 04:11:50PM -0700, Suren Baghdasaryan wrote: > With maple_tree supporting vma tree traversal under RCU and per-vma > locks, /proc/pid/maps can be

[PATCH 1/2] module: Fix memory deallocation on error path in move_module()

The function move_module() uses the variable t to track how many memory types it has allocated and consequently how many should be freed if an error occurs. The variable is initially set to 0 and is updated when a call to module_memory_alloc() fails. However, move_module() can fail for other reaso

[PATCH 2/2] module: Avoid unnecessary return value initialization in move_module()

All error conditions in move_module() set the return value by updating the ret variable. Therefore, it is not necessary to the initialize the variable when declaring it. Remove the unnecessary initialization. Signed-off-by: Petr Pavlu --- kernel/module/main.c | 2 +- 1 file changed, 1 insertion

[PATCH 0/2] module: Fix memory deallocation on error path in move_module()

The first patch is an actual fix. The second patch is a minor related cleanup. Petr Pavlu (2): module: Fix memory deallocation on error path in move_module() module: Avoid unnecessary return value initialization in move_module() kernel/module/main.c | 9 + 1 file changed, 5 insertion

Re: [PATCH v2] selftests/bpf: Validate UDP length in cls_redirect test

> I don't quite see the point. > This is a test prog. It's not supposed to be used as production code. It was marked as a TODO and so I sent a patch for it. I'm sorry I didn't think of the practical implications of it.