[PATCH v2 3/4] eventfs: Update all the eventfs_inodes from the events descriptor

[Steven Rostedt]

From: "Steven Rostedt (Google)" 

The change to update the permissions of the eventfs_inode had the
misconception that using the tracefs_inode would find all the
eventfs_inodes that have been updated and reset them on remount.
The problem with this approach is that the eventfs_inodes are freed when
they are no longer used (basically the reason the eventfs system exists).
When they are freed, the updated eventfs_inodes are not reset on a remount
because their tracefs_inodes have been freed.

Instead, since the events directory eventfs_inode always has a
tracefs_inode pointing to it (it is not freed when finished), and the
events directory has a link to all its children, have the
eventfs_remount() function only operate on the events eventfs_inode and
have it descend into its children updating their uid and gids.

Link: 
https://lore.kernel.org/all/cak7lnarxgaww3kh9jgrnh4vk6fr8ldknkf3wq8nhmwjrvwj...@mail.gmail.com/

Cc: sta...@vger.kernel.org
Fixes: baa23a8d4360d ("tracefs: Reset permissions on remount if permissions are 
options")
Reported-by: Masahiro Yamada 
Signed-off-by: Steven Rostedt (Google) 
---
 fs/tracefs/event_inode.c | 44 
 1 file changed, 31 insertions(+), 13 deletions(-)

diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
index 5dfb1ccd56ea..129d0f54ba62 100644
--- a/fs/tracefs/event_inode.c
+++ b/fs/tracefs/event_inode.c
@@ -305,27 +305,27 @@ static const struct file_operations 
eventfs_file_operations = {
.llseek = generic_file_llseek,
 };
 
-/*
- * On a remount of tracefs, if UID or GID options are set, then
- * the mount point inode permissions should be used.
- * Reset the saved permission flags appropriately.
- */
-void eventfs_remount(struct tracefs_inode *ti, bool update_uid, bool 
update_gid)
+static void eventfs_set_attrs(struct eventfs_inode *ei, bool update_uid, 
kuid_t uid,
+ bool update_gid, kgid_t gid, int level)
 {
-   struct eventfs_inode *ei = ti->private;
+   struct eventfs_inode *ei_child;
 
-   if (!ei)
+   /* Update events// */
+   if (WARN_ON_ONCE(level > 3))
return;
 
if (update_uid) {
ei->attr.mode &= ~EVENTFS_SAVE_UID;
-   ei->attr.uid = ti->vfs_inode.i_uid;
+   ei->attr.uid = uid;
}
 
-
if (update_gid) {
ei->attr.mode &= ~EVENTFS_SAVE_GID;
-   ei->attr.gid = ti->vfs_inode.i_gid;
+   ei->attr.gid = gid;
+   }
+
+   list_for_each_entry(ei_child, >children, list) {
+   eventfs_set_attrs(ei_child, update_uid, uid, update_gid, gid, 
level + 1);
}
 
if (!ei->entry_attrs)
@@ -334,13 +334,31 @@ void eventfs_remount(struct tracefs_inode *ti, bool 
update_uid, bool update_gid)
for (int i = 0; i < ei->nr_entries; i++) {
if (update_uid) {
ei->entry_attrs[i].mode &= ~EVENTFS_SAVE_UID;
-   ei->entry_attrs[i].uid = ti->vfs_inode.i_uid;
+   ei->entry_attrs[i].uid = uid;
}
if (update_gid) {
ei->entry_attrs[i].mode &= ~EVENTFS_SAVE_GID;
-   ei->entry_attrs[i].gid = ti->vfs_inode.i_gid;
+   ei->entry_attrs[i].gid = gid;
}
}
+
+}
+
+/*
+ * On a remount of tracefs, if UID or GID options are set, then
+ * the mount point inode permissions should be used.
+ * Reset the saved permission flags appropriately.
+ */
+void eventfs_remount(struct tracefs_inode *ti, bool update_uid, bool 
update_gid)
+{
+   struct eventfs_inode *ei = ti->private;
+
+   /* Only the events directory does the updates */
+   if (!ei || !ei->is_events || ei->is_freed)
+   return;
+
+   eventfs_set_attrs(ei, update_uid, ti->vfs_inode.i_uid,
+ update_gid, ti->vfs_inode.i_gid, 0);
 }
 
 /* Return the evenfs_inode of the "events" directory */
-- 
2.43.0

[PATCH v2 4/4] tracefs: Clear EVENT_INODE flag in tracefs_drop_inode()

[Steven Rostedt]

From: "Steven Rostedt (Google)" 

When the inode is being dropped from the dentry, the TRACEFS_EVENT_INODE
flag needs to be cleared to prevent a remount from calling
eventfs_remount() on the tracefs_inode private data. There's a race
between the inode is dropped (and the dentry freed) to where the inode is
actually freed. If a remount happens between the two, the eventfs_inode
could be accessed after it is freed (only the dentry keeps a ref count on
it).

Currently the TRACEFS_EVENT_INODE flag is cleared from the dentry iput()
function. But this is incorrect, as it is possible that the inode has
another reference to it. The flag should only be cleared when the inode is
really being dropped and has no more references. That happens in the
drop_inode callback of the inode, as that gets called when the last
reference of the inode is released.

Remove the tracefs_d_iput() function and move its logic to the more
appropriate tracefs_drop_inode() callback function.

Cc: sta...@vger.kernel.org
Fixes: baa23a8d4360d ("tracefs: Reset permissions on remount if permissions are 
options")
Signed-off-by: Steven Rostedt (Google) 
---
 fs/tracefs/inode.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 9252e0d78ea2..7c29f4afc23d 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -426,10 +426,26 @@ static int tracefs_show_options(struct seq_file *m, 
struct dentry *root)
return 0;
 }
 
+static int tracefs_drop_inode(struct inode *inode)
+{
+   struct tracefs_inode *ti = get_tracefs(inode);
+
+   /*
+* This inode is being freed and cannot be used for
+* eventfs. Clear the flag so that it doesn't call into
+* eventfs during the remount flag updates. The eventfs_inode
+* gets freed after an RCU cycle, so the content will still
+* be safe if the iteration is going on now.
+*/
+   ti->flags &= ~TRACEFS_EVENT_INODE;
+
+   return 1;
+}
+
 static const struct super_operations tracefs_super_operations = {
.alloc_inode= tracefs_alloc_inode,
.free_inode = tracefs_free_inode,
-   .drop_inode = generic_delete_inode,
+   .drop_inode = tracefs_drop_inode,
.statfs = simple_statfs,
.show_options   = tracefs_show_options,
 };
@@ -455,22 +471,7 @@ static int tracefs_d_revalidate(struct dentry *dentry, 
unsigned int flags)
return !(ei && ei->is_freed);
 }
 
-static void tracefs_d_iput(struct dentry *dentry, struct inode *inode)
-{
-   struct tracefs_inode *ti = get_tracefs(inode);
-
-   /*
-* This inode is being freed and cannot be used for
-* eventfs. Clear the flag so that it doesn't call into
-* eventfs during the remount flag updates. The eventfs_inode
-* gets freed after an RCU cycle, so the content will still
-* be safe if the iteration is going on now.
-*/
-   ti->flags &= ~TRACEFS_EVENT_INODE;
-}
-
 static const struct dentry_operations tracefs_dentry_operations = {
-   .d_iput = tracefs_d_iput,
.d_revalidate = tracefs_d_revalidate,
.d_release = tracefs_d_release,
 };
-- 
2.43.0

[PATCH v2 2/4] tracefs: Update inode permissions on remount

[Steven Rostedt]

From: "Steven Rostedt (Google)" 

When a remount happens, if a gid or uid is specified update the inodes to
have the same gid and uid. This will allow the simplification of the
permissions logic for the dynamically created files and directories.

Cc: sta...@vger.kernel.org
Fixes: baa23a8d4360d ("tracefs: Reset permissions on remount if permissions are 
options")
Signed-off-by: Steven Rostedt (Google) 
---
 fs/tracefs/event_inode.c | 17 +
 fs/tracefs/inode.c   | 15 ---
 2 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
index 55a40a730b10..5dfb1ccd56ea 100644
--- a/fs/tracefs/event_inode.c
+++ b/fs/tracefs/event_inode.c
@@ -317,20 +317,29 @@ void eventfs_remount(struct tracefs_inode *ti, bool 
update_uid, bool update_gid)
if (!ei)
return;
 
-   if (update_uid)
+   if (update_uid) {
ei->attr.mode &= ~EVENTFS_SAVE_UID;
+   ei->attr.uid = ti->vfs_inode.i_uid;
+   }
+
 
-   if (update_gid)
+   if (update_gid) {
ei->attr.mode &= ~EVENTFS_SAVE_GID;
+   ei->attr.gid = ti->vfs_inode.i_gid;
+   }
 
if (!ei->entry_attrs)
return;
 
for (int i = 0; i < ei->nr_entries; i++) {
-   if (update_uid)
+   if (update_uid) {
ei->entry_attrs[i].mode &= ~EVENTFS_SAVE_UID;
-   if (update_gid)
+   ei->entry_attrs[i].uid = ti->vfs_inode.i_uid;
+   }
+   if (update_gid) {
ei->entry_attrs[i].mode &= ~EVENTFS_SAVE_GID;
+   ei->entry_attrs[i].gid = ti->vfs_inode.i_gid;
+   }
}
 }
 
diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index a827f6a716c4..9252e0d78ea2 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -373,12 +373,21 @@ static int tracefs_apply_options(struct super_block *sb, 
bool remount)
 
rcu_read_lock();
list_for_each_entry_rcu(ti, _inodes, list) {
-   if (update_uid)
+   if (update_uid) {
ti->flags &= ~TRACEFS_UID_PERM_SET;
+   ti->vfs_inode.i_uid = fsi->uid;
+   }
 
-   if (update_gid)
+   if (update_gid) {
ti->flags &= ~TRACEFS_GID_PERM_SET;
-
+   ti->vfs_inode.i_gid = fsi->gid;
+   }
+
+   /*
+* Note, the above ti->vfs_inode updates are
+* used in eventfs_remount() so they must come
+* before calling it.
+*/
if (ti->flags & TRACEFS_EVENT_INODE)
eventfs_remount(ti, update_uid, update_gid);
}
-- 
2.43.0

[PATCH v2 1/4] eventfs: Keep the directories from having the same inode number as files

[Steven Rostedt]

From: "Steven Rostedt (Google)" 

The directories require unique inode numbers but all the eventfs files
have the same inode number. Prevent the directories from having the same
inode numbers as the files as that can confuse some tooling.

Cc: sta...@vger.kernel.org
Fixes: 834bf76add3e6 ("eventfs: Save directory inodes in the eventfs_inode 
structure")
Signed-off-by: Steven Rostedt (Google) 
---
 fs/tracefs/event_inode.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
index 0256afdd4acf..55a40a730b10 100644
--- a/fs/tracefs/event_inode.c
+++ b/fs/tracefs/event_inode.c
@@ -50,8 +50,12 @@ static struct eventfs_root_inode *get_root_inode(struct 
eventfs_inode *ei)
 /* Just try to make something consistent and unique */
 static int eventfs_dir_ino(struct eventfs_inode *ei)
 {
-   if (!ei->ino)
+   if (!ei->ino) {
ei->ino = get_next_ino();
+   /* Must not have the file inode number */
+   if (ei->ino == EVENTFS_FILE_INODE_INO)
+   ei->ino = get_next_ino();
+   }
 
return ei->ino;
 }
-- 
2.43.0

[PATCH v2 0/4] tracefs/eventfs: Fix failed second run of test_ownership

[Steven Rostedt]

The test_ownership test of the kselftests was failing again.
That's because the original fix was incorrect and a fix to
a race condition showed how the original fix was broken.

Instead of using tracefs_inodes to find the eventfs_inode that
needs to be reset on remount, use the "events" directory descriptor
to descend into its files and directories to catch all changes.

Changes since v1: 
https://lore.kernel.org/linux-trace-kernel/20240522124504.28982...@gandalf.local.home

 - Added other fixes underneath and rebased it on:
   https://lore.kernel.org/lkml/20240522164320.469785...@goodmis.org/

 - The real fix is to not use the tracefs_inodes to find the eventfs_inodes
   that need to be cleared on remount. Instead, the events descriptor
   needs to be used to descend its directories and files to update
   their attributes

 - The d_iput callback logic was misplaced. It should be done in the
   drop_inode callback.

  git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
eventfs/urgent

Head SHA1: 41b7db11bcac4638fa489c58d35e7d2146b665ab


Steven Rostedt (Google) (4):
  eventfs: Keep the directories from having the same inode number as files
  tracefs: Update inode permissions on remount
  eventfs: Update all the eventfs_inodes from the events descriptor
  tracefs: Clear EVENT_INODE flag in tracefs_drop_inode()


 fs/tracefs/event_inode.c | 57 +---
 fs/tracefs/inode.c   | 48 
 2 files changed, 73 insertions(+), 32 deletions(-)

Re: [PATCH] ftrace: riscv: move from REGS to ARGS

[patchwork-bot+linux-riscv]

Hello:

This patch was applied to riscv/linux.git (for-next)
by Palmer Dabbelt :

On Fri,  5 Apr 2024 14:24:53 + you wrote:
> This commit replaces riscv's support for FTRACE_WITH_REGS with support
> for FTRACE_WITH_ARGS. This is required for the ongoing effort to stop
> relying on stop_machine() for RISCV's implementation of ftrace.
> 
> The main relevant benefit that this change will bring for the above
> use-case is that now we don't have separate ftrace_caller and
> ftrace_regs_caller trampolines. This will allow the callsite to call
> ftrace_caller by modifying a single instruction. Now the callsite can
> do something similar to:
> 
> [...]

Here is the summary with links:
  - ftrace: riscv: move from REGS to ARGS
https://git.kernel.org/riscv/c/aa4cc1761cca

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH 01/12] soc: qcom: add firmware name helper

[Bjorn Andersson]

On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote:
> On Tue, 21 May 2024 at 13:20, Kalle Valo  wrote:
> >
> > Dmitry Baryshkov  writes:
> >
> > > On Tue, 21 May 2024 at 12:52,  wrote:
> > >>
> > >> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> > >> > Qualcomm platforms have different sets of the firmware files, which
> > >> > differ from platform to platform (and from board to board, due to the
> > >> > embedded signatures). Rather than listing all the firmware files,
> > >> > including full paths, in the DT, provide a way to determine firmware
> > >> > path based on the root DT node compatible.
> > >>
> > >> Ok this looks quite over-engineered but necessary to handle the legacy,
> > >> but I really think we should add a way to look for a board-specific path
> > >> first and fallback to those SoC specific paths.
> > >
> > > Again, CONFIG_FW_LOADER_USER_HELPER => delays.
> >
> > To me this also looks like very over-engineered, can you elaborate more
> > why this is needed? Concrete examples would help to understand better.
> 
> Sure. During the meeting last week Arnd suggested evaluating if we can
> drop firmware-name from the board DT files. Several reasons for that:
> - DT should describe the hardware, not the Linux-firmware locations
> - having firmware name in DT complicates updating the tree to use
> different firmware API (think of mbn vs mdt vs any other format)
> - If the DT gets supplied by the vendor (e.g. for
> SystemReady-certified devices), there should be a sync between the
> vendor's DT, linux kernel and the rootfs. Dropping firmware names from
> DT solves that by removing one piece of the equation
> 
> Now for the complexity of the solution. Each SoC family has their own
> firmware set. This includes firmware for the DSPs, for modem, WiFi
> bits, GPU shader, etc.
> For the development boards these devices are signed by the testing key
> and the actual signature is not validated against the root of trust
> certificate.
> For the end-user devices the signature is actually validated against
> the bits fused to the SoC during manufacturing process. CA certificate
> (and thus the fuses) differ from vendor to vendor (and from the device
> to device)
> 
> Not all of the firmware files are a part of the public linux-firmware
> tree. However we need to support the rootfs bundled with the firmware
> for different platforms (both public and vendor). The non-signed files
> come from the Adreno GPU and can be shared between platforms. All
> other files are SoC-specific and in some cases device-specific.
> 
> So for example the SDM845 db845c (open device) loads following firmware files:
> Not signed:
> - qcom/a630_sqe.fw
> - qcom/a630_gmu.bin
> 
> Signed, will work for any non-secured sdm845 device:
> - qcom/sdm845/a630_zap.mbn
> - qcom/sdm845/adsp.mbn
> - qcom/sdm845/cdsp.mbn
> - qcom/sdm485/mba.mbn
> - qcom/sdm845/modem.mbn
> - qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP)
> - qcom/venus-5.2/venus.mbn
> 
> Signed, works only for DB845c.
> - qcom/sdm845/Thundercomm/db845c/slpi.mbn
> 
> In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the
> following firmware files:
> - qcom/a630_sqe.fw (the same, non-signed file)
> - qcom/a630_gmu.bin (the same, non-signed file)
> - qcom/sdm845/Google/blueline/a630_zap.mbn

How do you get from "a630_zap.mbn" to this? By extending the lookup
table for every target, or what am I missing?

Regards,
Bjorn

> - qcom/sdm845/Google/blueline/adsp.mbn
> - qcom/sdm845/Google/blueline/cdsp.mbn
> - qcom/sdm845/Google/blueline/ipa_fws.mbn
> - qcom/sdm845/Google/blueline/mba.mbn
> - qcom/sdm845/Google/blueline/modem.mbn
> - qcom/sdm845/Google/blueline/venus.mbn
> - qcom/sdm845/Google/blueline/wlanmdsp.mbn
> - qcom/sdm845/Google/blueline/slpi.mbn
> 
> The Lenovo Yoga C630 WoS laptop (SDM850 is a variant of SDM845) uses
> another set of files:
> - qcom/a630_sqe.fw (the same, non-signed file)
> - qcom/a630_gmu.bin (the same, non-signed file)
> - qcom/sdm850/LENOVO/81JL/qcdxkmsuc850.mbn
> - qcom/sdm850/LENOVO/81JL/qcadsp850.mbn
> - qcom/sdm850/LENOVO/81JL/qccdsp850.mbn
> - qcom/sdm850/LENOVO/81JL/ipa_fws.elf
> - qcom/sdm850/LENOVO/81JL/qcdsp1v2850.mbn
> - qcom/sdm850/LENOVO/81JL/qcdsp2850.mbn
> - qcom/sdm850/LENOVO/81JL/qcvss850.mbn
> - qcom/sdm850/LENOVO/81JL/wlanmdsp.mbn
> - qcom/sdm850/LENOVO/81JL/qcslpi850.mbn
> 
> If we look at one of the recent platforms, e.g. SM8650-QRD, this list
> also grows up:
> - qcom/gen70900_sqe.fw (generic, non-signed)
> - qcom/gmu_gen70900.bin (generic, non-signed)
> - qcom/sm8650/gen70900_zap.mbn
> - qcom/sm8650/adsp.mbn
> - qcom/sm8650/adsp_dtb.mbn
> - qcom/sm8650/cdsp.mbn
> - qcom/sm8650/cdsp_dtb.mbn
> - qcom/sm8650/ipa_fws.mbn
> - qcom/sm8650/modem.mbn
> - qcom/sm8650/modem_dtb.mbn
> - qcom/sm8650/vpu33_4v.mbn (or maybe qcom/vpu-33/vpu_4v.mbn)
> 
> -- 
> With best wishes
> Dmitry
> 
> 
> 
> 
> 
> 
> 
> 
> 

[PATCH v2 1/1] x86/vector: Fix vector leak during CPU offline

[Dongli Zhang]

The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.

When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but if the old vector on the original CPU remains online, it is not
immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the
reclaiming process is delayed until the next trigger of the interrupt on
the new CPU.

Upon the subsequent triggering of the interrupt on the new CPU,
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
remains online. Subsequently, the timer on the old CPU iterates over its
vector_cleanup list, reclaiming old vectors.

However, a rare scenario arises if the old CPU is outgoing before the
interrupt triggers again on the new CPU. The irq_force_complete_move() may
not have the chance to be invoked on the outgoing CPU to reclaim the old
apicd->prev_vector. This is because the interrupt isn't currently affine to
the outgoing CPU, and irq_needs_fixup() returns false. Even though
__vector_schedule_cleanup() is later called on the new CPU, it doesn't
reclaim apicd->prev_vector; instead, it simply resets both
apicd->move_in_progress and apicd->prev_vector to 0.

As a result, the vector remains unreclaimed in vector_matrix, leading to a
CPU vector leak.

To address this issue, move the invocation of irq_force_complete_move()
before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
interrupt is currently or used to affine to the outgoing CPU. Additionally,
reclaim the vector in __vector_schedule_cleanup() as well, following a
warning message, although theoretically it should never see
apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.

Fixes: f0383c24b485 ("genirq/cpuhotplug: Add support for cleaning up move in 
progress")
Cc: Joe Jin 
Signed-off-by: Dongli Zhang 
---
Changed since v1:
- Add Fixes (suggested by Thomas)
- Add warning to __vector_schedule_cleanup() (suggested by Thomas)
- Use free_moved_vector() not irq_matrix_free() (suggested by Thomas)
- Move irq_force_complete_move() to early migrate_one_irq()
- Add more conditions in irq_force_complete_move() (suggested by Thomas)

 arch/x86/kernel/apic/vector.c |  9 ++---
 kernel/irq/cpuhotplug.c   | 16 
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 9eec52925fa3..b385bb5eac10 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -1035,7 +1035,8 @@ static void __vector_schedule_cleanup(struct 
apic_chip_data *apicd)
add_timer_on(>timer, cpu);
}
} else {
-   apicd->prev_vector = 0;
+   pr_warn("IRQ %u schedule cleanup for offline CPU %u\n", 
apicd->irq, cpu);
+   free_moved_vector(apicd);
}
raw_spin_unlock(_lock);
 }
@@ -1072,6 +1073,7 @@ void irq_complete_move(struct irq_cfg *cfg)
  */
 void irq_force_complete_move(struct irq_desc *desc)
 {
+   unsigned int cpu = smp_processor_id();
struct apic_chip_data *apicd;
struct irq_data *irqd;
unsigned int vector;
@@ -1096,10 +1098,11 @@ void irq_force_complete_move(struct irq_desc *desc)
goto unlock;
 
/*
-* If prev_vector is empty, no action required.
+* If prev_vector is empty or the descriptor is neither currently
+* nor previously on the outgoing CPU no action required.
 */
vector = apicd->prev_vector;
-   if (!vector)
+   if (!vector || (apicd->cpu != cpu && apicd->prev_cpu != cpu))
goto unlock;
 
/*
diff --git a/kernel/irq/cpuhotplug.c b/kernel/irq/cpuhotplug.c
index 75cadbc3c232..eb8628390156 100644
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -69,6 +69,14 @@ static bool migrate_one_irq(struct irq_desc *desc)
return false;
}
 
+   /*
+* Complete an eventually pending irq move cleanup. If this
+* interrupt was moved in hard irq context, then the vectors need
+* to be cleaned up. It can't wait until this interrupt actually
+* happens and this CPU was involved.
+*/
+   irq_force_complete_move(desc);
+
/*
 * No move required, if:
 * - Interrupt is per cpu
@@ -87,14 +95,6 @@ static bool migrate_one_irq(struct irq_desc *desc)
return false;
}
 
-   /*
-* Complete an eventually pending irq move cleanup. If this
-* interrupt was moved in hard irq context, then the vectors need
-* to be cleaned up. It can't wait until this interrupt actually
-* happens and this CPU was involved.
-*/
-   irq_force_complete_move(desc);

Re: [PATCH 1/1] x86/vector: Fix vector leak during CPU offline

[Dongli Zhang]

On 5/21/24 5:00 AM, Thomas Gleixner wrote:
> On Wed, May 15 2024 at 12:51, Dongli Zhang wrote:
>> On 5/13/24 3:46 PM, Thomas Gleixner wrote:
>>> So yes, moving the invocation of irq_force_complete_move() before the
>>> irq_needs_fixup() call makes sense, but it wants this to actually work
>>> correctly:
>>> @@ -1097,10 +1098,11 @@ void irq_force_complete_move(struct irq_
>>> goto unlock;
>>>  
>>> /*
>>> -* If prev_vector is empty, no action required.
>>> +* If prev_vector is empty or the descriptor was previously
>>> +* not on the outgoing CPU no action required.
>>>  */
>>> vector = apicd->prev_vector;
>>> -   if (!vector)
>>> +   if (!vector || apicd->prev_cpu != smp_processor_id())
>>> goto unlock;
>>>  
>>
>> The above may not work. migrate_one_irq() relies on 
>> irq_force_complete_move() to
>> always reclaim the apicd->prev_vector. Otherwise, the call of
>> irq_do_set_affinity() later may return -EBUSY.
> 
> You're right. But that still can be handled in irq_force_complete_move()
> with a single unconditional invocation in migrate_one_irq():
> 
>   cpu = smp_processor_id();
>   if (!vector || (apicd->cur_cpu != cpu && apicd->prev_cpu != cpu))
>   goto unlock;

The current affine is apicd->cpu :)

Thank you very much for the suggestion!

> 
> because there are only two cases when a cleanup is required:
> 
>1) The outgoing CPU is the current target
> 
>2) The outgoing CPU was the previous target
> 
> No?

I agree with this statement.

My only concern is: while we use "apicd->cpu", the irq_needs_fixup() uses a
different way. It uses d->common->effective_affinity or d->common->affinity to
decide whether to move forward to migrate the interrupt.

I have spent some time reading about the discussion that happened in the year
2017 (below link). According to my understanding,
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK always relies on CONFIG_SMP, and we do not
have the chance to encounter the issue for x86.

https://lore.kernel.org/all/alpine.DEB.2.20.1710042208400.2406@nanos/T/#u

I have tested the new patch for a while and never encountered any issue.

Therefore, I will send v2.

Thank you very much for all suggestions!

Dongli Zhang

Re: [PATCH 09/12] remoteproc: qcom_wcnss: make use of QCOM_FW_HELPER

[Dmitry Baryshkov]

On Wed, 22 May 2024 at 22:22, Jeff Johnson  wrote:
>
> On 5/21/2024 2:45 AM, Dmitry Baryshkov wrote:
> > Make the driver use qcom_fw_helper to autodetect the path to the
> > calibration data file.
> >
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >  drivers/remoteproc/qcom_wcnss.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/remoteproc/qcom_wcnss.c 
> > b/drivers/remoteproc/qcom_wcnss.c
> > index 421a3943a90d..45fc578ae30b 100644
> > --- a/drivers/remoteproc/qcom_wcnss.c
> > +++ b/drivers/remoteproc/qcom_wcnss.c
> > @@ -23,6 +23,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -555,8 +556,13 @@ static int wcnss_probe(struct platform_device *pdev)
> >   if (ret < 0 && ret != -EINVAL)
> >   return ret;
> >
> > + fw_name = qcom_get_board_fw(fw_name);
> > + if (!fw_name)
> > + return -ENOMEM;
> > +
> >   rproc = devm_rproc_alloc(>dev, pdev->name, _ops,
> >fw_name, sizeof(*wcnss));
> > + kfree(fw_name);
> >   if (!rproc) {
> >   dev_err(>dev, "unable to allocate remoteproc\n");
> >   return -ENOMEM;
> >
>
> can you cleanly bisect to this patch? seems it depends upon patch 10.
> should 09 & 10 be swapped, or perhaps squashed?

Yes. I think I got this mixed during rebasing and squashing of the
changes. For v2, if the approach is found to be generally acceptable,
I'll squash them.

-- 
With best wishes
Dmitry

Re: [PATCH 09/12] remoteproc: qcom_wcnss: make use of QCOM_FW_HELPER

[Jeff Johnson]

On 5/21/2024 2:45 AM, Dmitry Baryshkov wrote:
> Make the driver use qcom_fw_helper to autodetect the path to the
> calibration data file.
> 
> Signed-off-by: Dmitry Baryshkov 
> ---
>  drivers/remoteproc/qcom_wcnss.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
> index 421a3943a90d..45fc578ae30b 100644
> --- a/drivers/remoteproc/qcom_wcnss.c
> +++ b/drivers/remoteproc/qcom_wcnss.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -555,8 +556,13 @@ static int wcnss_probe(struct platform_device *pdev)
>   if (ret < 0 && ret != -EINVAL)
>   return ret;
>  
> + fw_name = qcom_get_board_fw(fw_name);
> + if (!fw_name)
> + return -ENOMEM;
> +
>   rproc = devm_rproc_alloc(>dev, pdev->name, _ops,
>fw_name, sizeof(*wcnss));
> + kfree(fw_name);
>   if (!rproc) {
>   dev_err(>dev, "unable to allocate remoteproc\n");
>   return -ENOMEM;
> 

can you cleanly bisect to this patch? seems it depends upon patch 10.
should 09 & 10 be swapped, or perhaps squashed?

Re: [PATCH] tracefs: Remove unneeded buggy tracefs iput callback

[Steven Rostedt]

On Wed, 22 May 2024 12:45:04 -0400
Steven Rostedt  wrote:

> From: "Steven Rostedt (Google)" 
> 
> The iput callback was added because the remount could call into the
> eventfs code and touch the ei->entry_attrs array, which could have been
> freed when an eventfs directory is freed (via a synthetic event). But the
> entry_attrs was freed incorrectly and since been fixed to be freed after
> the last reference of the ei is done.
> 
> The iput clears the TRACEFS_EVENT_INODE flag of the tracefs_inode
> preventing it from calling the eventfs_remount() function. But the iput
> can be called after the last reference to the inode is done but the
> eventfs_inode still exists, causing the eventfs_remount() not to be called
> on an tracefs_inode when it should be.

Testing this more, I found that the iput is still needed, as the deletion
of the eventfs inodes can happen before the inode is released.

Will produce a v2 that handles this properly.

-- Steve

Re: [PATCH RFC 1/2] dt-bindings: soc: qcom,smsm: Allow specifying mboxes instead of qcom,ipc

[Luca Weiss]

On Mittwoch, 22. Mai 2024 08:49:43 MESZ Krzysztof Kozlowski wrote:
> On 21/05/2024 22:35, Luca Weiss wrote:
> > On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
> >> On 20/05/2024 17:11, Luca Weiss wrote:
> >>> Hi Krzysztof
> >>>
> >>> Ack, sounds good.
> >>>
> >>> Maybe also from you, any opinion between these two binding styles?
> >>>
> >>> So first using index of mboxes for the numbering, where for the known
> >>> usages the first element (and sometimes the 3rd - ipc-2) are empty <>.
> >>>
> >>> The second variant is using mbox-names to get the correct channel-mbox
> >>> mapping.
> >>>
> >>> -   qcom,ipc-1 = < 8 13>;
> >>> -   qcom,ipc-2 = < 8 9>;
> >>> -   qcom,ipc-3 = < 8 19>;
> >>> +   mboxes = <0>, < 13>, < 9>, < 19>;
> >>>
> >>> vs.
> >>>
> >>> -   qcom,ipc-1 = < 8 13>;
> >>> -   qcom,ipc-2 = < 8 9>;
> >>> -   qcom,ipc-3 = < 8 19>;
> >>> +   mboxes = < 13>, < 9>, < 19>;
> >>> +   mbox-names = "ipc-1", "ipc-2", "ipc-3";
> >>
> >> Sorry, don't get, ipc-1 is the first mailbox, so why would there be <0>
> >> in first case?
> > 
> > Actually not, ipc-0 would be permissible by the driver, used for the 0th 
> > host
> > 
> > e.g. from:
> > 
> > /* Iterate over all hosts to check whom wants a kick */
> > for (host = 0; host < smsm->num_hosts; host++) {
> > hostp = >hosts[host];
> > 
> > Even though no mailbox is specified in any upstream dts for this 0th host I
> > didn't want the bindings to restrict that, that's why in the first example
> > there's an empty element (<0>) for the 0th smsm host
> > 
> >> Anyway, the question is if you need to know that some
> >> mailbox is missing. But then it is weird to name them "ipc-1" etc.
> > 
> > In either case we'd just query the mbox (either by name or index) and then
> > see if it's there? Not quite sure I understand the sentence..
> > Pretty sure either binding would work the same way.
> 
> The question is: does the driver care only about having some mailboxes
> or the driver cares about each specific mailbox? IOW, is skipping ipc-0
> important for the driver?

There's nothing special from driver side about any mailbox. Some SoCs have
a mailbox for e.g. hosts 1&2&3, some have only 1&3, and apq8064 even has
1&2&3&4.

And if the driver doesn't find a mailbox for a host, it just ignores it
but then of course it can't 'ring' the mailbox for that host when necessary.

Not sure how much more I can add here, to be fair I barely understand what
this driver is doing myself apart from the obvious.

Regards
Luca

> 
> 
> Best regards,
> Krzysztof
> 
> 

[PATCH] tracefs: Remove unneeded buggy tracefs iput callback

[Steven Rostedt]

From: "Steven Rostedt (Google)" 

The iput callback was added because the remount could call into the
eventfs code and touch the ei->entry_attrs array, which could have been
freed when an eventfs directory is freed (via a synthetic event). But the
entry_attrs was freed incorrectly and since been fixed to be freed after
the last reference of the ei is done.

The iput clears the TRACEFS_EVENT_INODE flag of the tracefs_inode
preventing it from calling the eventfs_remount() function. But the iput
can be called after the last reference to the inode is done but the
eventfs_inode still exists, causing the eventfs_remount() not to be called
on an tracefs_inode when it should be.

Link: 
https://lore.kernel.org/all/cak7lnarxgaww3kh9jgrnh4vk6fr8ldknkf3wq8nhmwjrvwj...@mail.gmail.com/

Cc: sta...@vger.kernel.org
Reported-by: Masahiro Yamada 
Fixes: ee4e0379475e4 ("eventfs: Free all of the eventfs_inode after RCU")
Signed-off-by: Steven Rostedt (Google) 
---
 fs/tracefs/inode.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 9252e0d78ea2..62ca9c23b93c 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -455,22 +455,7 @@ static int tracefs_d_revalidate(struct dentry *dentry, 
unsigned int flags)
return !(ei && ei->is_freed);
 }
 
-static void tracefs_d_iput(struct dentry *dentry, struct inode *inode)
-{
-   struct tracefs_inode *ti = get_tracefs(inode);
-
-   /*
-* This inode is being freed and cannot be used for
-* eventfs. Clear the flag so that it doesn't call into
-* eventfs during the remount flag updates. The eventfs_inode
-* gets freed after an RCU cycle, so the content will still
-* be safe if the iteration is going on now.
-*/
-   ti->flags &= ~TRACEFS_EVENT_INODE;
-}
-
 static const struct dentry_operations tracefs_dentry_operations = {
-   .d_iput = tracefs_d_iput,
.d_revalidate = tracefs_d_revalidate,
.d_release = tracefs_d_release,
 };
-- 
2.43.0

Re: [PATCH v2 1/2] drivers: remoteproc: xlnx: add attach detach support

[Tanmay Shah]

On 5/21/24 12:56 PM, Mathieu Poirier wrote:
> Hi Tanmay,
> 
> On Fri, May 10, 2024 at 05:51:25PM -0700, Tanmay Shah wrote:
>> It is possible that remote processor is already running before
>> linux boot or remoteproc platform driver probe. Implement required
>> remoteproc framework ops to provide resource table address and
>> connect or disconnect with remote processor in such case.
>> 
>> Signed-off-by: Tanmay Shah 
>> ---
>> 
>> Changes in v2:
>>   - Fix following sparse warnings
>> 
>> drivers/remoteproc/xlnx_r5_remoteproc.c:827:21: sparse:expected struct 
>> rsc_tbl_data *rsc_data_va
>> drivers/remoteproc/xlnx_r5_remoteproc.c:844:18: sparse:expected struct 
>> resource_table *rsc_addr
>> drivers/remoteproc/xlnx_r5_remoteproc.c:898:24: sparse:expected void 
>> volatile [noderef] __iomem *addr
>> 
>>  drivers/remoteproc/xlnx_r5_remoteproc.c | 164 +++-
>>  1 file changed, 160 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
>> b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> index 84243d1dff9f..039370cffa32 100644
>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> @@ -25,6 +25,10 @@
>>  /* RX mailbox client buffer max length */
>>  #define MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \
>>   sizeof(struct zynqmp_ipi_message))
>> +
>> +#define RSC_TBL_XLNX_MAGIC  ((uint32_t)'x' << 24 | (uint32_t)'a' << 16 | \
>> + (uint32_t)'m' << 8 | (uint32_t)'p')
>> +
>>  /*
>>   * settings for RPU cluster mode which
>>   * reflects possible values of xlnx,cluster-mode dt-property
>> @@ -73,6 +77,15 @@ struct mbox_info {
>>  struct mbox_chan *rx_chan;
>>  };
>>  
>> +/* Xilinx Platform specific data structure */
>> +struct rsc_tbl_data {
>> +const int version;
>> +const u32 magic_num;
>> +const u32 comp_magic_num;
> 
> Why is a complement magic number needed?

Actually magic number is 64-bit. There is good chance that
firmware can have 32-bit op-code or data same as magic number, but very less
chance of its complement in the next address. So, we can assume magic number
is 64-bit. 

> 
>> +const u32 rsc_tbl_size;
>> +const uintptr_t rsc_tbl;
>> +} __packed;
>> +
>>  /*
>>   * Hardcoded TCM bank values. This will stay in driver to maintain backward
>>   * compatibility with device-tree that does not have TCM information.
>> @@ -95,20 +108,24 @@ static const struct mem_bank_data 
>> zynqmp_tcm_banks_lockstep[] = {
>>  /**
>>   * struct zynqmp_r5_core
>>   *
>> + * @rsc_tbl_va: resource table virtual address
>>   * @dev: device of RPU instance
>>   * @np: device node of RPU instance
>>   * @tcm_bank_count: number TCM banks accessible to this RPU
>>   * @tcm_banks: array of each TCM bank data
>>   * @rproc: rproc handle
>> + * @rsc_tbl_size: resource table size retrieved from remote
>>   * @pm_domain_id: RPU CPU power domain id
>>   * @ipi: pointer to mailbox information
>>   */
>>  struct zynqmp_r5_core {
>> +struct resource_table *rsc_tbl_va;
> 
> Shouldn't this be of type "void __iomem *"?  Did sparse give you trouble on 
> that
> one?

I fixed sparse warnings with typecast below [1].

> 
>>  struct device *dev;
>>  struct device_node *np;
>>  int tcm_bank_count;
>>  struct mem_bank_data **tcm_banks;
>>  struct rproc *rproc;
>> +u32 rsc_tbl_size;
>>  u32 pm_domain_id;
>>  struct mbox_info *ipi;
>>  };
>> @@ -621,10 +638,19 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
>>  {
>>  int ret;
>>  
>> -ret = add_tcm_banks(rproc);
>> -if (ret) {
>> -dev_err(>dev, "failed to get TCM banks, err %d\n", ret);
>> -return ret;
>> +/**
> 
> Using "/**" is for comments that will endup in the documentation, which I 
> don't
> think is needed here.  Please correct throughout the patch.

Thanks. Ack, I will use only /* format.

> 
>> + * For attach/detach use case, Firmware is already loaded so
>> + * TCM isn't really needed at all. Also, for security TCM can be
>> + * locked in such case and linux may not have access at all.
>> + * So avoid adding TCM banks. TCM power-domains requested during attach
>> + * callback.
>> + */
>> +if (rproc->state != RPROC_DETACHED) {
>> +ret = add_tcm_banks(rproc);
>> +if (ret) {
>> +dev_err(>dev, "failed to get TCM banks, err 
>> %d\n", ret);
>> +return ret;
>> +}
>>  }
>>  
>>  ret = add_mem_regions_carveout(rproc);
>> @@ -662,6 +688,123 @@ static int zynqmp_r5_rproc_unprepare(struct rproc 
>> *rproc)
>>  return 0;
>>  }
>>  
>> +static struct resource_table *zynqmp_r5_get_loaded_rsc_table(struct rproc 
>> *rproc,
>> + size_t *size)
>> +{
>> +struct zynqmp_r5_core *r5_core;
>> +
>> +r5_core = rproc->priv;
>> +
>> +*size = r5_core->rsc_tbl_size;

Re: [PATCH 2/5] dt-bindings: mailbox: qcom-ipcc: Add GPDSP0 and GPDSP1 clients

[Krzysztof Kozlowski]

On 22/05/2024 14:08, Bartosz Golaszewski wrote:
> From: Tengfei Fan 
> 
> Add GPDSP0 and GPDSP1 clients for SA8775p platform.
> 
> Signed-off-by: Tengfei Fan 
> Signed-off-by: Bartosz Golaszewski 
> ---

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH 1/5] dt-bindings: remoteproc: qcom,sm8550-pas: Document the SA8775p ADSP, CDSP and GPDSP

[Bartosz Golaszewski]

On Wed, May 22, 2024 at 3:06 PM  wrote:
>
> On 22/05/2024 15:04, Bartosz Golaszewski wrote:
> > On Wed, May 22, 2024 at 2:42 PM  wrote:
> >>
> >> On 22/05/2024 14:08, Bartosz Golaszewski wrote:
> >>> From: Tengfei Fan 
> >>>
> >>> Document the compatibles for the components used to boot the ADSP, CDSP0,
> >>> CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC.
> >>>
> >>> Signed-off-by: Tengfei Fan 
> >>> Co-developed-by: Bartosz Golaszewski 
> >>> Signed-off-by: Bartosz Golaszewski 
> >>> ---
> >>>.../bindings/remoteproc/qcom,sm8550-pas.yaml   | 76 
> >>> +-
> >>>1 file changed, 75 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git 
> >>> a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml 
> >>> b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> >>> index 73fda7565cd1..9d3a862c39e1 100644
> >>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> >>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> >>> @@ -16,6 +16,11 @@ description:
> >>>properties:
> >>>  compatible:
> >>>enum:
> >>> +  - qcom,sa8775p-adsp-pas
> >>> +  - qcom,sa8775p-cdsp0-pas
> >>> +  - qcom,sa8775p-cdsp1-pas
> >>> +  - qcom,sa8775p-gpdsp0-pas
> >>> +  - qcom,sa8775p-gpdsp1-pas
> >>>  - qcom,sm8550-adsp-pas
> >>>  - qcom,sm8550-cdsp-pas
> >>>  - qcom,sm8550-mpss-pas
> >>> @@ -44,12 +49,13 @@ properties:
> >>>
> >>>  firmware-name:
> >>>$ref: /schemas/types.yaml#/definitions/string-array
> >>> +minItems: 1
> >>
> >> This will allow a single firmware name for all compatible,
> >> which is wrong
> >>
> >
> > So increasing the limit from the default under allOf doesn't seem to
> > work, should I instead keep this and make the lower limit stricter for
> > all other models?
>
> Yes add minItems in all the allOf:if: and add the missing allOf:if: for
> the new compatibles to set the minItems, same for memory-region.
>
> Or you may simply spin off a new yaml, this one is getting quite large.
>

Yeah, maybe that's a better idea.

Bart

> Neil
>
> >
> > Bart
> >
> >>>items:
> >>>  - description: Firmware name of the Hexagon core
> >>>  - description: Firmware name of the Hexagon Devicetree
> >>>
> >>>  memory-region:
> >>> -minItems: 2
> >>> +minItems: 1
> >>
> >> Same here
> >>
> >>>items:
> >>>  - description: Memory region for main Firmware authentication
> >>>  - description: Memory region for Devicetree Firmware 
> >>> authentication
> >>> @@ -81,6 +87,21 @@ allOf:
> >>>  maxItems: 5
> >>>memory-region:
> >>>  maxItems: 2
> >>> +  - if:
> >>> +  properties:
> >>> +compatible:
> >>> +  enum:
> >>> +- qcom,sa8775p-adsp-pas
> >>> +- qcom,sa8775p-cdsp0-pas
> >>> +- qcom,sa8775p-cdsp1-pas
> >>> +- qcom,sa8775p-gpdsp0-pas
> >>> +- qcom,sa8775p-gpdsp1-pas
> >>> +then:
> >>> +  properties:
> >>> +interrupts:
> >>> +  maxItems: 5
> >>> +interrupt-names:
> >>> +  maxItems: 5
> >>>  - if:
> >>>  properties:
> >>>compatible:
> >>> @@ -128,6 +149,7 @@ allOf:
> >>>  properties:
> >>>compatible:
> >>>  enum:
> >>> +- qcom,sa8775p-adsp-pas
> >>>- qcom,sm8550-adsp-pas
> >>>- qcom,sm8650-adsp-pas
> >>>- qcom,x1e80100-adsp-pas
> >>> @@ -177,6 +199,58 @@ allOf:
> >>>- const: cx
> >>>- const: mxc
> >>>- const: nsp
> >>> +  - if:
> >>> +  properties:
> >>> +compatible:
> >>> +  enum:
> >>> +- qcom,sa8775p-cdsp-pas
> >>> +then:
> >>> +  properties:
> >>> +power-domains:
> >>> +  items:
> >>> +- description: CX power domain
> >>> +- description: MXC power domain
> >>> +- description: NSP0 power domain
> >>> +power-domain-names:
> >>> +  items:
> >>> +- const: cx
> >>> +- const: mxc
> >>> +- const: nsp0
> >>> +
> >>> +  - if:
> >>> +  properties:
> >>> +compatible:
> >>> +  enum:
> >>> +- qcom,sa8775p-cdsp1-pas
> >>> +then:
> >>> +  properties:
> >>> +power-domains:
> >>> +  items:
> >>> +- description: CX power domain
> >>> +- description: MXC power domain
> >>> +- description: NSP1 power domain
> >>> +power-domain-names:
> >>> +  items:
> >>> +- const: cx
> >>> +- const: mxc
> >>> +- const: nsp1
> >>> +
> >>> +  - if:
> >>> +  properties:
> >>> +compatible:
> >>> +  enum:
> >>> +- qcom,sa8775p-gpdsp0-pas
> >>> +- qcom,sa8775p-gpdsp1-pas
> >>> +then:
> >>> +  properties:
> >>> 

Re: [PATCH 1/5] dt-bindings: remoteproc: qcom,sm8550-pas: Document the SA8775p ADSP, CDSP and GPDSP

[neil . armstrong]

On 22/05/2024 15:04, Bartosz Golaszewski wrote:

On Wed, May 22, 2024 at 2:42 PM  wrote:


On 22/05/2024 14:08, Bartosz Golaszewski wrote:

From: Tengfei Fan 

Document the compatibles for the components used to boot the ADSP, CDSP0,
CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC.

Signed-off-by: Tengfei Fan 
Co-developed-by: Bartosz Golaszewski 
Signed-off-by: Bartosz Golaszewski 
---
   .../bindings/remoteproc/qcom,sm8550-pas.yaml   | 76 
+-
   1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml 
b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
index 73fda7565cd1..9d3a862c39e1 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
@@ -16,6 +16,11 @@ description:
   properties:
 compatible:
   enum:
+  - qcom,sa8775p-adsp-pas
+  - qcom,sa8775p-cdsp0-pas
+  - qcom,sa8775p-cdsp1-pas
+  - qcom,sa8775p-gpdsp0-pas
+  - qcom,sa8775p-gpdsp1-pas
 - qcom,sm8550-adsp-pas
 - qcom,sm8550-cdsp-pas
 - qcom,sm8550-mpss-pas
@@ -44,12 +49,13 @@ properties:

 firmware-name:
   $ref: /schemas/types.yaml#/definitions/string-array
+minItems: 1


This will allow a single firmware name for all compatible,
which is wrong



So increasing the limit from the default under allOf doesn't seem to
work, should I instead keep this and make the lower limit stricter for
all other models?


Yes add minItems in all the allOf:if: and add the missing allOf:if: for
the new compatibles to set the minItems, same for memory-region.

Or you may simply spin off a new yaml, this one is getting quite large.

Neil



Bart


   items:
 - description: Firmware name of the Hexagon core
 - description: Firmware name of the Hexagon Devicetree

 memory-region:
-minItems: 2
+minItems: 1


Same here


   items:
 - description: Memory region for main Firmware authentication
 - description: Memory region for Devicetree Firmware authentication
@@ -81,6 +87,21 @@ allOf:
 maxItems: 5
   memory-region:
 maxItems: 2
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-adsp-pas
+- qcom,sa8775p-cdsp0-pas
+- qcom,sa8775p-cdsp1-pas
+- qcom,sa8775p-gpdsp0-pas
+- qcom,sa8775p-gpdsp1-pas
+then:
+  properties:
+interrupts:
+  maxItems: 5
+interrupt-names:
+  maxItems: 5
 - if:
 properties:
   compatible:
@@ -128,6 +149,7 @@ allOf:
 properties:
   compatible:
 enum:
+- qcom,sa8775p-adsp-pas
   - qcom,sm8550-adsp-pas
   - qcom,sm8650-adsp-pas
   - qcom,x1e80100-adsp-pas
@@ -177,6 +199,58 @@ allOf:
   - const: cx
   - const: mxc
   - const: nsp
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-cdsp-pas
+then:
+  properties:
+power-domains:
+  items:
+- description: CX power domain
+- description: MXC power domain
+- description: NSP0 power domain
+power-domain-names:
+  items:
+- const: cx
+- const: mxc
+- const: nsp0
+
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-cdsp1-pas
+then:
+  properties:
+power-domains:
+  items:
+- description: CX power domain
+- description: MXC power domain
+- description: NSP1 power domain
+power-domain-names:
+  items:
+- const: cx
+- const: mxc
+- const: nsp1
+
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-gpdsp0-pas
+- qcom,sa8775p-gpdsp1-pas
+then:
+  properties:
+power-domains:
+  items:
+- description: CX power domain
+- description: MXC power domain
+power-domain-names:
+  items:
+- const: cx
+- const: mxc

   unevaluatedProperties: false

Re: [PATCH 1/5] dt-bindings: remoteproc: qcom,sm8550-pas: Document the SA8775p ADSP, CDSP and GPDSP

[Bartosz Golaszewski]

On Wed, May 22, 2024 at 2:42 PM  wrote:
>
> On 22/05/2024 14:08, Bartosz Golaszewski wrote:
> > From: Tengfei Fan 
> >
> > Document the compatibles for the components used to boot the ADSP, CDSP0,
> > CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC.
> >
> > Signed-off-by: Tengfei Fan 
> > Co-developed-by: Bartosz Golaszewski 
> > Signed-off-by: Bartosz Golaszewski 
> > ---
> >   .../bindings/remoteproc/qcom,sm8550-pas.yaml   | 76 
> > +-
> >   1 file changed, 75 insertions(+), 1 deletion(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml 
> > b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> > index 73fda7565cd1..9d3a862c39e1 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> > @@ -16,6 +16,11 @@ description:
> >   properties:
> > compatible:
> >   enum:
> > +  - qcom,sa8775p-adsp-pas
> > +  - qcom,sa8775p-cdsp0-pas
> > +  - qcom,sa8775p-cdsp1-pas
> > +  - qcom,sa8775p-gpdsp0-pas
> > +  - qcom,sa8775p-gpdsp1-pas
> > - qcom,sm8550-adsp-pas
> > - qcom,sm8550-cdsp-pas
> > - qcom,sm8550-mpss-pas
> > @@ -44,12 +49,13 @@ properties:
> >
> > firmware-name:
> >   $ref: /schemas/types.yaml#/definitions/string-array
> > +minItems: 1
>
> This will allow a single firmware name for all compatible,
> which is wrong
>

So increasing the limit from the default under allOf doesn't seem to
work, should I instead keep this and make the lower limit stricter for
all other models?

Bart

> >   items:
> > - description: Firmware name of the Hexagon core
> > - description: Firmware name of the Hexagon Devicetree
> >
> > memory-region:
> > -minItems: 2
> > +minItems: 1
>
> Same here
>
> >   items:
> > - description: Memory region for main Firmware authentication
> > - description: Memory region for Devicetree Firmware authentication
> > @@ -81,6 +87,21 @@ allOf:
> > maxItems: 5
> >   memory-region:
> > maxItems: 2
> > +  - if:
> > +  properties:
> > +compatible:
> > +  enum:
> > +- qcom,sa8775p-adsp-pas
> > +- qcom,sa8775p-cdsp0-pas
> > +- qcom,sa8775p-cdsp1-pas
> > +- qcom,sa8775p-gpdsp0-pas
> > +- qcom,sa8775p-gpdsp1-pas
> > +then:
> > +  properties:
> > +interrupts:
> > +  maxItems: 5
> > +interrupt-names:
> > +  maxItems: 5
> > - if:
> > properties:
> >   compatible:
> > @@ -128,6 +149,7 @@ allOf:
> > properties:
> >   compatible:
> > enum:
> > +- qcom,sa8775p-adsp-pas
> >   - qcom,sm8550-adsp-pas
> >   - qcom,sm8650-adsp-pas
> >   - qcom,x1e80100-adsp-pas
> > @@ -177,6 +199,58 @@ allOf:
> >   - const: cx
> >   - const: mxc
> >   - const: nsp
> > +  - if:
> > +  properties:
> > +compatible:
> > +  enum:
> > +- qcom,sa8775p-cdsp-pas
> > +then:
> > +  properties:
> > +power-domains:
> > +  items:
> > +- description: CX power domain
> > +- description: MXC power domain
> > +- description: NSP0 power domain
> > +power-domain-names:
> > +  items:
> > +- const: cx
> > +- const: mxc
> > +- const: nsp0
> > +
> > +  - if:
> > +  properties:
> > +compatible:
> > +  enum:
> > +- qcom,sa8775p-cdsp1-pas
> > +then:
> > +  properties:
> > +power-domains:
> > +  items:
> > +- description: CX power domain
> > +- description: MXC power domain
> > +- description: NSP1 power domain
> > +power-domain-names:
> > +  items:
> > +- const: cx
> > +- const: mxc
> > +- const: nsp1
> > +
> > +  - if:
> > +  properties:
> > +compatible:
> > +  enum:
> > +- qcom,sa8775p-gpdsp0-pas
> > +- qcom,sa8775p-gpdsp1-pas
> > +then:
> > +  properties:
> > +power-domains:
> > +  items:
> > +- description: CX power domain
> > +- description: MXC power domain
> > +power-domain-names:
> > +  items:
> > +- const: cx
> > +- const: mxc
> >
> >   unevaluatedProperties: false
> >
> >
>

Re: [PATCH 1/5] dt-bindings: remoteproc: qcom,sm8550-pas: Document the SA8775p ADSP, CDSP and GPDSP

[neil . armstrong]

On 22/05/2024 14:08, Bartosz Golaszewski wrote:

From: Tengfei Fan 

Document the compatibles for the components used to boot the ADSP, CDSP0,
CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC.

Signed-off-by: Tengfei Fan 
Co-developed-by: Bartosz Golaszewski 
Signed-off-by: Bartosz Golaszewski 
---
  .../bindings/remoteproc/qcom,sm8550-pas.yaml   | 76 +-
  1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml 
b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
index 73fda7565cd1..9d3a862c39e1 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
@@ -16,6 +16,11 @@ description:
  properties:
compatible:
  enum:
+  - qcom,sa8775p-adsp-pas
+  - qcom,sa8775p-cdsp0-pas
+  - qcom,sa8775p-cdsp1-pas
+  - qcom,sa8775p-gpdsp0-pas
+  - qcom,sa8775p-gpdsp1-pas
- qcom,sm8550-adsp-pas
- qcom,sm8550-cdsp-pas
- qcom,sm8550-mpss-pas
@@ -44,12 +49,13 @@ properties:
  
firmware-name:

  $ref: /schemas/types.yaml#/definitions/string-array
+minItems: 1


This will allow a single firmware name for all compatible,
which is wrong


  items:
- description: Firmware name of the Hexagon core
- description: Firmware name of the Hexagon Devicetree
  
memory-region:

-minItems: 2
+minItems: 1


Same here


  items:
- description: Memory region for main Firmware authentication
- description: Memory region for Devicetree Firmware authentication
@@ -81,6 +87,21 @@ allOf:
maxItems: 5
  memory-region:
maxItems: 2
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-adsp-pas
+- qcom,sa8775p-cdsp0-pas
+- qcom,sa8775p-cdsp1-pas
+- qcom,sa8775p-gpdsp0-pas
+- qcom,sa8775p-gpdsp1-pas
+then:
+  properties:
+interrupts:
+  maxItems: 5
+interrupt-names:
+  maxItems: 5
- if:
properties:
  compatible:
@@ -128,6 +149,7 @@ allOf:
properties:
  compatible:
enum:
+- qcom,sa8775p-adsp-pas
  - qcom,sm8550-adsp-pas
  - qcom,sm8650-adsp-pas
  - qcom,x1e80100-adsp-pas
@@ -177,6 +199,58 @@ allOf:
  - const: cx
  - const: mxc
  - const: nsp
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-cdsp-pas
+then:
+  properties:
+power-domains:
+  items:
+- description: CX power domain
+- description: MXC power domain
+- description: NSP0 power domain
+power-domain-names:
+  items:
+- const: cx
+- const: mxc
+- const: nsp0
+
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-cdsp1-pas
+then:
+  properties:
+power-domains:
+  items:
+- description: CX power domain
+- description: MXC power domain
+- description: NSP1 power domain
+power-domain-names:
+  items:
+- const: cx
+- const: mxc
+- const: nsp1
+
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-gpdsp0-pas
+- qcom,sa8775p-gpdsp1-pas
+then:
+  properties:
+power-domains:
+  items:
+- description: CX power domain
+- description: MXC power domain
+power-domain-names:
+  items:
+- const: cx
+- const: mxc
  
  unevaluatedProperties: false
  

[ANNOUNCE] 4.19.312-rt134

[Daniel Wagner]

Hello RT-list!

I'm pleased to announce the 4.19.312-rt134 stable release.

This updates the rt-stable branch to the upstream stable v4.19.312
release. This took a bit longer because there were some more complex
merge conflict . Stable backported one of the preempt-rt preparation
patches which v4.19-rt already shipped. Sebastian helped out to get this
merge correct, thanks a lot!

Cheers,
Daniel

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v4.19-rt
  Head SHA1: 1c3b7281e2711af8488ce40c9202ad19f3eeb557

Or to build 4.19.312-rt134 directly, the following patches should be applied:

  https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.19.tar.xz

  https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.19.312.xz

  
https://www.kernel.org/pub/linux/kernel/projects/rt/4.19/older/patch-4.19.312-rt134.patch.xz

Signing key fingerprint:

  5BF6 7BC5 0826 72CA BB45  ACAE 587C 5ECA 5D0A 306C

All keys used for the above files and repositories can be found on the
following git repository:

   git://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git

Enjoy!
Daniel

Changes from v4.19.307-rt133:
---

Daniel Wagner (1):
  Linux 4.19.312-rt134
---
localversion-rt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/localversion-rt b/localversion-rt
index c2c7e0fb6685..6067da4c8c99 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt133
+-rt134

[PATCH 4/5] arm64: dts: qcom: sa8775p: add ADSP, CDSP and GPDSP nodes

[Bartosz Golaszewski]

From: Tengfei Fan 

Add nodes for remoteprocs: ADSP, CDSP0, CDSP1, GPDSP0 and GPDSP1 for
SA8775p SoCs.

Signed-off-by: Tengfei Fan 
Co-developed-by: Bartosz Golaszewski 
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm64/boot/dts/qcom/sa8775p.dtsi | 332 ++
 1 file changed, 332 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sa8775p.dtsi 
b/arch/arm64/boot/dts/qcom/sa8775p.dtsi
index 31de73594839..5c0b61a5624b 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p.dtsi
+++ b/arch/arm64/boot/dts/qcom/sa8775p.dtsi
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -544,6 +545,121 @@ cpucp_fw_mem: cpucp-fw@db20 {
};
};
 
+   smp2p-adsp {
+   compatible = "qcom,smp2p";
+   qcom,smem = <443>, <429>;
+   interrupts-extended = < IPCC_CLIENT_LPASS
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+   mboxes = < IPCC_CLIENT_LPASS IPCC_MPROC_SIGNAL_SMP2P>;
+
+   qcom,local-pid = <0>;
+   qcom,remote-pid = <2>;
+
+   smp2p_adsp_out: master-kernel {
+   qcom,entry-name = "master-kernel";
+   #qcom,smem-state-cells = <1>;
+   };
+
+   smp2p_adsp_in: slave-kernel {
+   qcom,entry-name = "slave-kernel";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+   };
+
+   smp2p-cdsp0 {
+   compatible = "qcom,smp2p";
+   qcom,smem = <94>, <432>;
+   interrupts-extended = < IPCC_CLIENT_CDSP
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+   mboxes = < IPCC_CLIENT_CDSP IPCC_MPROC_SIGNAL_SMP2P>;
+
+   qcom,local-pid = <0>;
+   qcom,remote-pid = <5>;
+
+   smp2p_cdsp0_out: master-kernel {
+   qcom,entry-name = "master-kernel";
+   #qcom,smem-state-cells = <1>;
+   };
+
+   smp2p_cdsp0_in: slave-kernel {
+   qcom,entry-name = "slave-kernel";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+   };
+
+   smp2p-cdsp1 {
+   compatible = "qcom,smp2p";
+   qcom,smem = <617>, <616>;
+   interrupts-extended = < IPCC_CLIENT_NSP1
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+   mboxes = < IPCC_CLIENT_NSP1 IPCC_MPROC_SIGNAL_SMP2P>;
+
+   qcom,local-pid = <0>;
+   qcom,remote-pid = <12>;
+
+   smp2p_cdsp1_out: master-kernel {
+   qcom,entry-name = "master-kernel";
+   #qcom,smem-state-cells = <1>;
+   };
+
+   smp2p_cdsp1_in: slave-kernel {
+   qcom,entry-name = "slave-kernel";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+   };
+
+   smp2p-gpdsp0 {
+   compatible = "qcom,smp2p";
+   qcom,smem = <617>, <616>;
+   interrupts-extended = < IPCC_CLIENT_GPDSP0
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+   mboxes = < IPCC_CLIENT_GPDSP0 IPCC_MPROC_SIGNAL_SMP2P>;
+
+   qcom,local-pid = <0>;
+   qcom,remote-pid = <17>;
+
+   smp2p_gpdsp0_out: master-kernel {
+   qcom,entry-name = "master-kernel";
+   #qcom,smem-state-cells = <1>;
+   };
+
+   smp2p_gpdsp0_in: slave-kernel {
+   qcom,entry-name = "slave-kernel";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+   };
+
+   smp2p-gpdsp1 {
+   compatible = "qcom,smp2p";
+   qcom,smem = <617>, <616>;
+   interrupts-extended = < IPCC_CLIENT_GPDSP1
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+   mboxes = < IPCC_CLIENT_GPDSP1 IPCC_MPROC_SIGNAL_SMP2P>;
+
+   qcom,local-pid = <0>;
+   qcom,remote-pid = <18>;
+
+   smp2p_gpdsp1_out: master-kernel {
+   qcom,entry-name = "master-kernel";
+   #qcom,smem-state-cells = <1>;
+   };
+
+   smp2p_gpdsp1_in: slave-kernel {
+   qcom,entry-name = "slave-kernel";
+   interrupt-controller;
+ 

[PATCH 5/5] arm64: dts: qcom: sa8775p-ride: enable remoteprocs

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Enable all remoteproc nodes on the sa8775p-ride board and point to the
appropriate firmware files.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm64/boot/dts/qcom/sa8775p-ride.dts | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dts 
b/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
index 26ad05bd3b3f..071fcaf09364 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
+++ b/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
@@ -727,6 +727,31 @@ _phy {
status = "okay";
 };
 
+_adsp {
+   firmware-name = "qcom/sa8775p/adsp.mbn";
+   status = "okay";
+};
+
+_cdsp0 {
+   firmware-name = "qcom/sa8775p/cdsp0.mbn";
+   status = "okay";
+};
+
+_cdsp1 {
+   firmware-name = "qcom/sa8775p/cdsp1.mbn";
+   status = "okay";
+};
+
+_gpdsp0 {
+   firmware-name = "qcom/sa8775p/gpdsp0.mbn";
+   status = "okay";
+};
+
+_gpdsp1 {
+   firmware-name = "qcom/sa8775p/gpdsp1.mbn";
+   status = "okay";
+};
+
  {
compatible = "qcom,geni-debug-uart";
pinctrl-0 = <_uart10_default>;

-- 
2.43.0

[PATCH 3/5] remoteproc: qcom_q6v5_pas: Add support for SA8775p ADSP, CDSP and GPDSP

[Bartosz Golaszewski]

From: Tengfei Fan 

Add support for PIL loading on ADSP, CDSP0, CDSP1, GPDSP0 and GPDSP1 on
SA8775p SoCs.

Signed-off-by: Tengfei Fan 
Co-developed-by: Bartosz Golaszewski 
Signed-off-by: Bartosz Golaszewski 
---
 drivers/remoteproc/qcom_q6v5_pas.c | 92 ++
 1 file changed, 92 insertions(+)

diff --git a/drivers/remoteproc/qcom_q6v5_pas.c 
b/drivers/remoteproc/qcom_q6v5_pas.c
index 54d8005d40a3..16053aa99298 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -820,6 +820,23 @@ static const struct adsp_data adsp_resource_init = {
.ssctl_id = 0x14,
 };
 
+static const struct adsp_data sa8775p_adsp_resource = {
+   .crash_reason_smem = 423,
+   .firmware_name = "adsp.mdt",
+   .pas_id = 1,
+   .minidump_id = 5,
+   .auto_boot = true,
+   .proxy_pd_names = (char*[]){
+   "lcx",
+   "lmx",
+   NULL
+   },
+   .load_state = "adsp",
+   .ssr_name = "lpass",
+   .sysmon_name = "adsp",
+   .ssctl_id = 0x14,
+};
+
 static const struct adsp_data sdm845_adsp_resource_init = {
.crash_reason_smem = 423,
.firmware_name = "adsp.mdt",
@@ -933,6 +950,42 @@ static const struct adsp_data cdsp_resource_init = {
.ssctl_id = 0x17,
 };
 
+static const struct adsp_data sa8775p_cdsp0_resource = {
+   .crash_reason_smem = 601,
+   .firmware_name = "cdsp0.mdt",
+   .pas_id = 18,
+   .minidump_id = 7,
+   .auto_boot = true,
+   .proxy_pd_names = (char*[]){
+   "cx",
+   "mxc",
+   "nsp0",
+   NULL
+   },
+   .load_state = "cdsp",
+   .ssr_name = "cdsp",
+   .sysmon_name = "cdsp",
+   .ssctl_id = 0x17,
+};
+
+static const struct adsp_data sa8775p_cdsp1_resource = {
+   .crash_reason_smem = 633,
+   .firmware_name = "cdsp1.mdt",
+   .pas_id = 30,
+   .minidump_id = 20,
+   .auto_boot = true,
+   .proxy_pd_names = (char*[]){
+   "cx",
+   "mxc",
+   "nsp1",
+   NULL
+   },
+   .load_state = "nsp",
+   .ssr_name = "cdsp1",
+   .sysmon_name = "cdsp1",
+   .ssctl_id = 0x20,
+};
+
 static const struct adsp_data sdm845_cdsp_resource_init = {
.crash_reason_smem = 601,
.firmware_name = "cdsp.mdt",
@@ -1074,6 +1127,40 @@ static const struct adsp_data sm8350_cdsp_resource = {
.ssctl_id = 0x17,
 };
 
+static const struct adsp_data sa8775p_gpdsp0_resource = {
+   .crash_reason_smem = 640,
+   .firmware_name = "gpdsp0.mdt",
+   .pas_id = 39,
+   .minidump_id = 21,
+   .auto_boot = true,
+   .proxy_pd_names = (char*[]){
+   "cx",
+   "mxc",
+   NULL
+   },
+   .load_state = "gpdsp0",
+   .ssr_name = "gpdsp0",
+   .sysmon_name = "gpdsp0",
+   .ssctl_id = 0x21,
+};
+
+static const struct adsp_data sa8775p_gpdsp1_resource = {
+   .crash_reason_smem = 641,
+   .firmware_name = "gpdsp1.mdt",
+   .pas_id = 40,
+   .minidump_id = 22,
+   .auto_boot = true,
+   .proxy_pd_names = (char*[]){
+   "cx",
+   "mxc",
+   NULL
+   },
+   .load_state = "gpdsp1",
+   .ssr_name = "gpdsp1",
+   .sysmon_name = "gpdsp1",
+   .ssctl_id = 0x22,
+};
+
 static const struct adsp_data mpss_resource_init = {
.crash_reason_smem = 421,
.firmware_name = "modem.mdt",
@@ -1315,6 +1402,11 @@ static const struct of_device_id adsp_of_match[] = {
{ .compatible = "qcom,qcs404-adsp-pas", .data = _resource_init },
{ .compatible = "qcom,qcs404-cdsp-pas", .data = _resource_init },
{ .compatible = "qcom,qcs404-wcss-pas", .data = _resource_init },
+   { .compatible = "qcom,sa8775p-adsp-pas", .data = 
_adsp_resource},
+   { .compatible = "qcom,sa8775p-cdsp0-pas", .data = 
_cdsp0_resource},
+   { .compatible = "qcom,sa8775p-cdsp1-pas", .data = 
_cdsp1_resource},
+   { .compatible = "qcom,sa8775p-gpdsp0-pas", .data = 
_gpdsp0_resource},
+   { .compatible = "qcom,sa8775p-gpdsp1-pas", .data = 
_gpdsp1_resource},
{ .compatible = "qcom,sc7180-adsp-pas", .data = _adsp_resource},
{ .compatible = "qcom,sc7180-mpss-pas", .data = _resource_init},
{ .compatible = "qcom,sc7280-adsp-pas", .data = _adsp_resource},

-- 
2.43.0

[PATCH 2/5] dt-bindings: mailbox: qcom-ipcc: Add GPDSP0 and GPDSP1 clients

[Bartosz Golaszewski]

From: Tengfei Fan 

Add GPDSP0 and GPDSP1 clients for SA8775p platform.

Signed-off-by: Tengfei Fan 
Signed-off-by: Bartosz Golaszewski 
---
 include/dt-bindings/mailbox/qcom-ipcc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/mailbox/qcom-ipcc.h 
b/include/dt-bindings/mailbox/qcom-ipcc.h
index fbfa3febc66d..fd85a79381b3 100644
--- a/include/dt-bindings/mailbox/qcom-ipcc.h
+++ b/include/dt-bindings/mailbox/qcom-ipcc.h
@@ -33,5 +33,7 @@
 #define IPCC_CLIENT_NSP1   18
 #define IPCC_CLIENT_TME23
 #define IPCC_CLIENT_WPSS   24
+#define IPCC_CLIENT_GPDSP0 31
+#define IPCC_CLIENT_GPDSP1 32
 
 #endif

-- 
2.43.0

[PATCH 1/5] dt-bindings: remoteproc: qcom,sm8550-pas: Document the SA8775p ADSP, CDSP and GPDSP

[Bartosz Golaszewski]

From: Tengfei Fan 

Document the compatibles for the components used to boot the ADSP, CDSP0,
CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC.

Signed-off-by: Tengfei Fan 
Co-developed-by: Bartosz Golaszewski 
Signed-off-by: Bartosz Golaszewski 
---
 .../bindings/remoteproc/qcom,sm8550-pas.yaml   | 76 +-
 1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml 
b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
index 73fda7565cd1..9d3a862c39e1 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
@@ -16,6 +16,11 @@ description:
 properties:
   compatible:
 enum:
+  - qcom,sa8775p-adsp-pas
+  - qcom,sa8775p-cdsp0-pas
+  - qcom,sa8775p-cdsp1-pas
+  - qcom,sa8775p-gpdsp0-pas
+  - qcom,sa8775p-gpdsp1-pas
   - qcom,sm8550-adsp-pas
   - qcom,sm8550-cdsp-pas
   - qcom,sm8550-mpss-pas
@@ -44,12 +49,13 @@ properties:
 
   firmware-name:
 $ref: /schemas/types.yaml#/definitions/string-array
+minItems: 1
 items:
   - description: Firmware name of the Hexagon core
   - description: Firmware name of the Hexagon Devicetree
 
   memory-region:
-minItems: 2
+minItems: 1
 items:
   - description: Memory region for main Firmware authentication
   - description: Memory region for Devicetree Firmware authentication
@@ -81,6 +87,21 @@ allOf:
   maxItems: 5
 memory-region:
   maxItems: 2
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-adsp-pas
+- qcom,sa8775p-cdsp0-pas
+- qcom,sa8775p-cdsp1-pas
+- qcom,sa8775p-gpdsp0-pas
+- qcom,sa8775p-gpdsp1-pas
+then:
+  properties:
+interrupts:
+  maxItems: 5
+interrupt-names:
+  maxItems: 5
   - if:
   properties:
 compatible:
@@ -128,6 +149,7 @@ allOf:
   properties:
 compatible:
   enum:
+- qcom,sa8775p-adsp-pas
 - qcom,sm8550-adsp-pas
 - qcom,sm8650-adsp-pas
 - qcom,x1e80100-adsp-pas
@@ -177,6 +199,58 @@ allOf:
 - const: cx
 - const: mxc
 - const: nsp
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-cdsp-pas
+then:
+  properties:
+power-domains:
+  items:
+- description: CX power domain
+- description: MXC power domain
+- description: NSP0 power domain
+power-domain-names:
+  items:
+- const: cx
+- const: mxc
+- const: nsp0
+
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-cdsp1-pas
+then:
+  properties:
+power-domains:
+  items:
+- description: CX power domain
+- description: MXC power domain
+- description: NSP1 power domain
+power-domain-names:
+  items:
+- const: cx
+- const: mxc
+- const: nsp1
+
+  - if:
+  properties:
+compatible:
+  enum:
+- qcom,sa8775p-gpdsp0-pas
+- qcom,sa8775p-gpdsp1-pas
+then:
+  properties:
+power-domains:
+  items:
+- description: CX power domain
+- description: MXC power domain
+power-domain-names:
+  items:
+- const: cx
+- const: mxc
 
 unevaluatedProperties: false
 

-- 
2.43.0

[PATCH 0/5] arm64: qcom: sa8775p: enable remoteprocs - ADSP, CDSP and GPDSP

[Bartosz Golaszewski]

Add DT bindings, relevant DT defines, DTS nodes and driver changes
required to enable the remoteprocs on sa8775p.

Signed-off-by: Bartosz Golaszewski 
---
Bartosz Golaszewski (1):
  arm64: dts: qcom: sa8775p-ride: enable remoteprocs

Tengfei Fan (4):
  dt-bindings: remoteproc: qcom,sm8550-pas: Document the SA8775p ADSP, CDSP 
and GPDSP
  dt-bindings: mailbox: qcom-ipcc: Add GPDSP0 and GPDSP1 clients
  remoteproc: qcom_q6v5_pas: Add support for SA8775p ADSP, CDSP and GPDSP
  arm64: dts: qcom: sa8775p: add ADSP, CDSP and GPDSP nodes

 .../bindings/remoteproc/qcom,sm8550-pas.yaml   |  76 -
 arch/arm64/boot/dts/qcom/sa8775p-ride.dts  |  25 ++
 arch/arm64/boot/dts/qcom/sa8775p.dtsi  | 332 +
 drivers/remoteproc/qcom_q6v5_pas.c |  92 ++
 include/dt-bindings/mailbox/qcom-ipcc.h|   2 +
 5 files changed, 526 insertions(+), 1 deletion(-)
---
base-commit: 124cfbcd6d185d4f50be02d5f5afe61578916773
change-id: 20240507-topic-lemans-iot-remoteproc-6647b50281e2

Best regards,
-- 
Bartosz Golaszewski 

Re: [PATCHv6 9/9] man2: Add uretprobe syscall page

[Jiri Olsa]

On Wed, May 22, 2024 at 12:59:46PM +0200, Alejandro Colomar wrote:
> Hi Jirka,
> 
> On Wed, May 22, 2024 at 09:54:58AM GMT, Jiri Olsa wrote:
> > ok, thanks
> > 
> > jirka
> > 
> > 
> > ---
> > diff --git a/man/man2/uretprobe.2 b/man/man2/uretprobe.2
> > new file mode 100644
> > index ..5b5f340b59b6
> > --- /dev/null
> > +++ b/man/man2/uretprobe.2
> > @@ -0,0 +1,56 @@
> > +.\" Copyright (C) 2024, Jiri Olsa 
> > +.\"
> > +.\" SPDX-License-Identifier: Linux-man-pages-copyleft
> > +.\"
> > +.TH uretprobe 2 (date) "Linux man-pages (unreleased)"
> > +.SH NAME
> > +uretprobe \- execute pending return uprobes
> > +.SH SYNOPSIS
> > +.nf
> > +.B int uretprobe(void)
> > +.fi
> > +.SH DESCRIPTION
> > +The
> > +.BR uretprobe ()
> > +system call is an alternative to breakpoint instructions for triggering 
> > return
> > +uprobe consumers.
> > +.P
> > +Calls to
> > +.BR uretprobe ()
> > +system call are only made from the user-space trampoline provided by the 
> > kernel.
> > +Calls from any other place result in a
> > +.BR SIGILL .
> > +.SH RETURN VALUE
> > +The
> > +.BR uretprobe ()
> > +system call return value is architecture-specific.
> > +.SH ERRORS
> > +.TP
> > +.B SIGILL
> > +The
> > +.BR uretprobe ()
> > +system call was called by user.
> 
> Maybe 'a user-space program'?
> Anyway, LGTM.  Thanks!
> 
>   Reviewed-by: Alejandro Colomar 

ok, will change, thanks a lot

jirka

> 
> Have a lovely day!
> Alex
> 
> > +.SH VERSIONS
> > +Details of the
> > +.BR uretprobe ()
> > +system call behavior vary across systems.
> > +.SH STANDARDS
> > +None.
> > +.SH HISTORY
> > +TBD
> > +.SH NOTES
> > +The
> > +.BR uretprobe ()
> > +system call was initially introduced for the x86_64 architecture
> > +where it was shown to be faster than breakpoint traps.
> > +It might be extended to other architectures.
> > +.P
> > +The
> > +.BR uretprobe ()
> > +system call exists only to allow the invocation of return uprobe consumers.
> > +It should
> > +.B never
> > +be called directly.
> > +Details of the arguments (if any) passed to
> > +.BR uretprobe ()
> > +and the return value are architecture-specific.
> 
> -- 
> 

Re: [PATCH v2 6/6] selftests: livepatch: Test livepatching function using an external symbol

[Petr Mladek]

On Thu 2024-05-16 15:30:09, Lukas Hruska wrote:
> The test proves that klp-convert works as intended and it is possible to
> livepatch a function that use an external symbol.
> 
> Signed-off-by: Lukas Hruska 

> --- a/tools/testing/selftests/livepatch/functions.sh
> +++ b/tools/testing/selftests/livepatch/functions.sh
> @@ -7,6 +7,7 @@
>  MAX_RETRIES=600
>  RETRY_INTERVAL=".1"  # seconds
>  KLP_SYSFS_DIR="/sys/kernel/livepatch"
> +MODULE_SYSFS_DIR="/sys/module"
>  
>  # Kselftest framework requirement - SKIP code is 4
>  ksft_skip=4
> @@ -299,7 +300,7 @@ function check_result {
>   result=$(dmesg | awk -v last_dmesg="$LAST_DMESG" 'p; $0 == last_dmesg { 
> p=1 }' | \
>grep -e 'livepatch:' -e 'test_klp' | \
>grep -v '\(tainting\|taints\) kernel' | \
> -  sed 's/^\[[ 0-9.]*\] //')
> +  sed 's/^\[[ 0-9.]*\] //' | sed 's/^test_klp_log: //')

The prefix "test_klp_log:" is not used anywhere. It seems that this
change is not needed in the final version.

>  
>   if [[ "$expect" == "$result" ]] ; then
>   echo "ok"

Otherwise, it looks and works nice. With the hunk removed:

Reviewed-by: Petr Mladek 
Tested-by: Petr Mladek 

Best Regards,
Petr

Re: [GIT PULL] virtio: features, fixes, cleanups

[Xuan Zhuo]

On Wed, 22 May 2024 07:38:01 -0400, "Michael S. Tsirkin"  
wrote:
> On Wed, May 22, 2024 at 06:22:45PM +0800, Xuan Zhuo wrote:
> > On Wed, 22 May 2024 06:03:01 -0400, "Michael S. Tsirkin"  
> > wrote:
> > > Things to note here:
> > >
> > > - the new Marvell OCTEON DPU driver is not here: latest v4 keeps causing
> > >   build failures on mips. I deferred the pull hoping to get it in
> > >   and I might merge a new version post rc1
> > >   (supposed to be ok for new drivers as they can't cause regressions),
> > >   but we'll see.
> > > - there are also a couple bugfixes under review, to be merged after rc1
> > > - I merged a trivial patch (removing a comment) that also got
> > >   merged through net.
> > >   git handles this just fine and it did not seem worth it
> > >   rebasing to drop it.
> > > - there is a trivial conflict in the header file. Shouldn't be any
> > >   trouble to resolve, but fyi the resolution by Stephen is here
> > >   diff --cc drivers/virtio/virtio_mem.c
> > >   index e8355f55a8f7,6d4dfbc53a66..
> > >   --- a/drivers/virtio/virtio_mem.c
> > >   +++ b/drivers/virtio/virtio_mem.c
> > >   @@@ -21,7 -21,7 +21,8 @@@
> > > #include 
> > > #include 
> > > #include 
> > >+#include 
> > >   + #include 
> > >   Also see it here:
> > >   https://lore.kernel.org/all/20240423145947.14217...@canb.auug.org.au/
> > >
> > >
> > >
> > > The following changes since commit 
> > > 18daea77cca626f590fb140fc11e3a43c5d41354:
> > >
> > >   Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 
> > > (2024-04-30 12:40:41 -0700)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git 
> > > tags/for_linus
> > >
> > > for you to fetch changes up to 0b8dbbdcf2e42273fbac9b752919e2e5b2abac21:
> > >
> > >   Merge tag 'for_linus' into vhost (2024-05-12 08:15:28 -0400)
> > >
> > > 
> > > virtio: features, fixes, cleanups
> > >
> > > Several new features here:
> > >
> > > - virtio-net is finally supported in vduse.
> > >
> > > - Virtio (balloon and mem) interaction with suspend is improved
> > >
> > > - vhost-scsi now handles signals better/faster.
> > >
> > > - virtio-net now supports premapped mode by default,
> > >   opening the door for all kind of zero copy tricks.
> > >
> > > Fixes, cleanups all over the place.
> > >
> > > Signed-off-by: Michael S. Tsirkin 
> > >
> > > 
> > > Christophe JAILLET (1):
> > >   vhost-vdpa: Remove usage of the deprecated ida_simple_xx() API
> > >
> > > David Hildenbrand (1):
> > >   virtio-mem: support suspend+resume
> > >
> > > David Stevens (2):
> > >   virtio_balloon: Give the balloon its own wakeup source
> > >   virtio_balloon: Treat stats requests as wakeup events
> > >
> > > Eugenio P閞ez (2):
> > >   MAINTAINERS: add Eugenio P閞ez as reviewer
> > >   MAINTAINERS: add Eugenio P閞ez as reviewer
> > >
> > > Jiri Pirko (1):
> > >   virtio: delete vq in vp_find_vqs_msix() when request_irq() fails
> > >
> > > Krzysztof Kozlowski (24):
> > >   virtio: balloon: drop owner assignment
> > >   virtio: input: drop owner assignment
> > >   virtio: mem: drop owner assignment
> > >   um: virt-pci: drop owner assignment
> > >   virtio_blk: drop owner assignment
> > >   bluetooth: virtio: drop owner assignment
> > >   hwrng: virtio: drop owner assignment
> > >   virtio_console: drop owner assignment
> > >   crypto: virtio - drop owner assignment
> > >   firmware: arm_scmi: virtio: drop owner assignment
> > >   gpio: virtio: drop owner assignment
> > >   drm/virtio: drop owner assignment
> > >   iommu: virtio: drop owner assignment
> > >   misc: nsm: drop owner assignment
> > >   net: caif: virtio: drop owner assignment
> > >   net: virtio: drop owner assignment
> > >   net: 9p: virtio: drop owner assignment
> > >   vsock/virtio: drop owner assignment
> > >   wifi: mac80211_hwsim: drop owner assignment
> > >   nvdimm: virtio_pmem: drop owner assignment
> > >   rpmsg: virtio: drop owner assignment
> > >   scsi: virtio: drop owner assignment
> > >   fuse: virtio: drop owner assignment
> > >   sound: virtio: drop owner assignment
> > >
> > > Li Zhijian (1):
> > >   vdpa: Convert sprintf/snprintf to sysfs_emit
> > >
> > > Maxime Coquelin (6):
> > >   vduse: validate block features only with block devices
> > >   vduse: Temporarily fail if control queue feature requested
> > >   vduse: enable Virtio-net device type
> > >   vduse: validate block features only with block devices
> > >   vduse: Temporarily fail if control queue feature requested
> > >   vduse: enable Virtio-net device type
> > >
> > > Michael S. Tsirkin (2):
> > >   Merge tag 'stable/vduse-virtio-net' into vhost
> > >   Merge tag 'for_linus' 

Re: [GIT PULL] virtio: features, fixes, cleanups

[Michael S. Tsirkin]

On Wed, May 22, 2024 at 06:03:08AM -0400, Michael S. Tsirkin wrote:
> Things to note here:

Sorry Linus, author of one of the patchsets I merged wants to drop it now.
I could revert but it seems cleaner to do that, re-test and re-post.
Will drop a duplicate as long as I do it.



> - the new Marvell OCTEON DPU driver is not here: latest v4 keeps causing
>   build failures on mips. I deferred the pull hoping to get it in
>   and I might merge a new version post rc1
>   (supposed to be ok for new drivers as they can't cause regressions),
>   but we'll see.
> - there are also a couple bugfixes under review, to be merged after rc1
> - I merged a trivial patch (removing a comment) that also got
>   merged through net.
>   git handles this just fine and it did not seem worth it
>   rebasing to drop it.
> - there is a trivial conflict in the header file. Shouldn't be any
>   trouble to resolve, but fyi the resolution by Stephen is here
>   diff --cc drivers/virtio/virtio_mem.c
>   index e8355f55a8f7,6d4dfbc53a66..
>   --- a/drivers/virtio/virtio_mem.c
>   +++ b/drivers/virtio/virtio_mem.c
>   @@@ -21,7 -21,7 +21,8 @@@
> #include 
> #include 
> #include 
>+#include 
>   + #include 
>   Also see it here:
>   https://lore.kernel.org/all/20240423145947.14217...@canb.auug.org.au/
> 
> 
> 
> The following changes since commit 18daea77cca626f590fb140fc11e3a43c5d41354:
> 
>   Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 
> (2024-04-30 12:40:41 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
> 
> for you to fetch changes up to 0b8dbbdcf2e42273fbac9b752919e2e5b2abac21:
> 
>   Merge tag 'for_linus' into vhost (2024-05-12 08:15:28 -0400)
> 
> 
> virtio: features, fixes, cleanups
> 
> Several new features here:
> 
> - virtio-net is finally supported in vduse.
> 
> - Virtio (balloon and mem) interaction with suspend is improved
> 
> - vhost-scsi now handles signals better/faster.
> 
> - virtio-net now supports premapped mode by default,
>   opening the door for all kind of zero copy tricks.
> 
> Fixes, cleanups all over the place.
> 
> Signed-off-by: Michael S. Tsirkin 
> 
> 
> Christophe JAILLET (1):
>   vhost-vdpa: Remove usage of the deprecated ida_simple_xx() API
> 
> David Hildenbrand (1):
>   virtio-mem: support suspend+resume
> 
> David Stevens (2):
>   virtio_balloon: Give the balloon its own wakeup source
>   virtio_balloon: Treat stats requests as wakeup events
> 
> Eugenio Pérez (2):
>   MAINTAINERS: add Eugenio Pérez as reviewer
>   MAINTAINERS: add Eugenio Pérez as reviewer
> 
> Jiri Pirko (1):
>   virtio: delete vq in vp_find_vqs_msix() when request_irq() fails
> 
> Krzysztof Kozlowski (24):
>   virtio: balloon: drop owner assignment
>   virtio: input: drop owner assignment
>   virtio: mem: drop owner assignment
>   um: virt-pci: drop owner assignment
>   virtio_blk: drop owner assignment
>   bluetooth: virtio: drop owner assignment
>   hwrng: virtio: drop owner assignment
>   virtio_console: drop owner assignment
>   crypto: virtio - drop owner assignment
>   firmware: arm_scmi: virtio: drop owner assignment
>   gpio: virtio: drop owner assignment
>   drm/virtio: drop owner assignment
>   iommu: virtio: drop owner assignment
>   misc: nsm: drop owner assignment
>   net: caif: virtio: drop owner assignment
>   net: virtio: drop owner assignment
>   net: 9p: virtio: drop owner assignment
>   vsock/virtio: drop owner assignment
>   wifi: mac80211_hwsim: drop owner assignment
>   nvdimm: virtio_pmem: drop owner assignment
>   rpmsg: virtio: drop owner assignment
>   scsi: virtio: drop owner assignment
>   fuse: virtio: drop owner assignment
>   sound: virtio: drop owner assignment
> 
> Li Zhijian (1):
>   vdpa: Convert sprintf/snprintf to sysfs_emit
> 
> Maxime Coquelin (6):
>   vduse: validate block features only with block devices
>   vduse: Temporarily fail if control queue feature requested
>   vduse: enable Virtio-net device type
>   vduse: validate block features only with block devices
>   vduse: Temporarily fail if control queue feature requested
>   vduse: enable Virtio-net device type
> 
> Michael S. Tsirkin (2):
>   Merge tag 'stable/vduse-virtio-net' into vhost
>   Merge tag 'for_linus' into vhost
> 
> Mike Christie (9):
>   vhost-scsi: Handle vhost_vq_work_queue failures for events
>   vhost-scsi: Handle vhost_vq_work_queue failures for cmds
>   vhost-scsi: Use system wq to flush dev for TMFs
>   vhost: Remove vhost_vq_flush
>   vhost_scsi: Handle vhost_vq_work_queue failures for TMFs
>   vhost: Use virtqueue mutex for 

Re: [GIT PULL] virtio: features, fixes, cleanups

[Michael S. Tsirkin]

On Wed, May 22, 2024 at 06:22:45PM +0800, Xuan Zhuo wrote:
> On Wed, 22 May 2024 06:03:01 -0400, "Michael S. Tsirkin"  
> wrote:
> > Things to note here:
> >
> > - the new Marvell OCTEON DPU driver is not here: latest v4 keeps causing
> >   build failures on mips. I deferred the pull hoping to get it in
> >   and I might merge a new version post rc1
> >   (supposed to be ok for new drivers as they can't cause regressions),
> >   but we'll see.
> > - there are also a couple bugfixes under review, to be merged after rc1
> > - I merged a trivial patch (removing a comment) that also got
> >   merged through net.
> >   git handles this just fine and it did not seem worth it
> >   rebasing to drop it.
> > - there is a trivial conflict in the header file. Shouldn't be any
> >   trouble to resolve, but fyi the resolution by Stephen is here
> > diff --cc drivers/virtio/virtio_mem.c
> > index e8355f55a8f7,6d4dfbc53a66..
> > --- a/drivers/virtio/virtio_mem.c
> > +++ b/drivers/virtio/virtio_mem.c
> > @@@ -21,7 -21,7 +21,8 @@@
> >   #include 
> >   #include 
> >   #include 
> >  +#include 
> > + #include 
> >   Also see it here:
> >   https://lore.kernel.org/all/20240423145947.14217...@canb.auug.org.au/
> >
> >
> >
> > The following changes since commit 18daea77cca626f590fb140fc11e3a43c5d41354:
> >
> >   Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 
> > (2024-04-30 12:40:41 -0700)
> >
> > are available in the Git repository at:
> >
> >   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git 
> > tags/for_linus
> >
> > for you to fetch changes up to 0b8dbbdcf2e42273fbac9b752919e2e5b2abac21:
> >
> >   Merge tag 'for_linus' into vhost (2024-05-12 08:15:28 -0400)
> >
> > 
> > virtio: features, fixes, cleanups
> >
> > Several new features here:
> >
> > - virtio-net is finally supported in vduse.
> >
> > - Virtio (balloon and mem) interaction with suspend is improved
> >
> > - vhost-scsi now handles signals better/faster.
> >
> > - virtio-net now supports premapped mode by default,
> >   opening the door for all kind of zero copy tricks.
> >
> > Fixes, cleanups all over the place.
> >
> > Signed-off-by: Michael S. Tsirkin 
> >
> > 
> > Christophe JAILLET (1):
> >   vhost-vdpa: Remove usage of the deprecated ida_simple_xx() API
> >
> > David Hildenbrand (1):
> >   virtio-mem: support suspend+resume
> >
> > David Stevens (2):
> >   virtio_balloon: Give the balloon its own wakeup source
> >   virtio_balloon: Treat stats requests as wakeup events
> >
> > Eugenio Pérez (2):
> >   MAINTAINERS: add Eugenio Pérez as reviewer
> >   MAINTAINERS: add Eugenio Pérez as reviewer
> >
> > Jiri Pirko (1):
> >   virtio: delete vq in vp_find_vqs_msix() when request_irq() fails
> >
> > Krzysztof Kozlowski (24):
> >   virtio: balloon: drop owner assignment
> >   virtio: input: drop owner assignment
> >   virtio: mem: drop owner assignment
> >   um: virt-pci: drop owner assignment
> >   virtio_blk: drop owner assignment
> >   bluetooth: virtio: drop owner assignment
> >   hwrng: virtio: drop owner assignment
> >   virtio_console: drop owner assignment
> >   crypto: virtio - drop owner assignment
> >   firmware: arm_scmi: virtio: drop owner assignment
> >   gpio: virtio: drop owner assignment
> >   drm/virtio: drop owner assignment
> >   iommu: virtio: drop owner assignment
> >   misc: nsm: drop owner assignment
> >   net: caif: virtio: drop owner assignment
> >   net: virtio: drop owner assignment
> >   net: 9p: virtio: drop owner assignment
> >   vsock/virtio: drop owner assignment
> >   wifi: mac80211_hwsim: drop owner assignment
> >   nvdimm: virtio_pmem: drop owner assignment
> >   rpmsg: virtio: drop owner assignment
> >   scsi: virtio: drop owner assignment
> >   fuse: virtio: drop owner assignment
> >   sound: virtio: drop owner assignment
> >
> > Li Zhijian (1):
> >   vdpa: Convert sprintf/snprintf to sysfs_emit
> >
> > Maxime Coquelin (6):
> >   vduse: validate block features only with block devices
> >   vduse: Temporarily fail if control queue feature requested
> >   vduse: enable Virtio-net device type
> >   vduse: validate block features only with block devices
> >   vduse: Temporarily fail if control queue feature requested
> >   vduse: enable Virtio-net device type
> >
> > Michael S. Tsirkin (2):
> >   Merge tag 'stable/vduse-virtio-net' into vhost
> >   Merge tag 'for_linus' into vhost
> >
> > Mike Christie (9):
> >   vhost-scsi: Handle vhost_vq_work_queue failures for events
> >   vhost-scsi: Handle vhost_vq_work_queue failures for cmds
> >   vhost-scsi: Use system wq to flush dev for TMFs
> >   vhost: Remove vhost_vq_flush
> >   vhost_scsi: 

Re: [PATCH v2 4/6] livepatch: Add sample livepatch module

[Petr Mladek]

On Thu 2024-05-16 15:30:07, Lukas Hruska wrote:
> From: Josh Poimboeuf 
> 
> Add a new livepatch sample in samples/livepatch/ to make use of symbols
> that must be post-processed to enable load-time relocation resolution.
> As the new sample is to be used as an example, it is annotated with
> KLP_RELOC_SYMBOL macro.
> 
> The livepatch sample updates the function cmdline_proc_show to print the
> string referenced by the symbol saved_command_line appended by the
> string "livepatch=1".
> 
> Signed-off-by: Josh Poimboeuf 
> Signed-off-by: Lukas Hruska 
> Reviewed-by: Petr Mladek 
> ---
>  samples/livepatch/Makefile  |  1 +
>  samples/livepatch/livepatch-extern-symbol.c | 84 +
>  2 files changed, 85 insertions(+)
>  create mode 100644 samples/livepatch/livepatch-extern-symbol.c
> 
> diff --git a/samples/livepatch/Makefile b/samples/livepatch/Makefile
> index 9f853eeb6140..f2b41f4d6c16 100644
> --- a/samples/livepatch/Makefile
> +++ b/samples/livepatch/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-shadow-fix2.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-demo.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-mod.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-busymod.o
> +obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-annotated-sample.o

It seems that the sample has been renamed without updating
the Makefile rule. There should be:

+obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-extern-symbol.o

Otherwise, I get:

make[4]: *** No rule to make target 
'samples/livepatch/livepatch-annotated-sample.o', needed by 
'samples/livepatch/'.  Stop.
make[3]: *** [scripts/Makefile.build:485: samples/livepatch] Error 2
make[2]: *** [scripts/Makefile.build:485: samples] Error 2
make[1]: *** [/prace/kernel/linux/Makefile:1921: .] Error 2
make: *** [Makefile:240: __sub-make] Error 2

> diff --git a/samples/livepatch/livepatch-extern-symbol.c 
> b/samples/livepatch/livepatch-extern-symbol.c
> new file mode 100644
> index ..276a43d157b4
> --- /dev/null
> +++ b/samples/livepatch/livepatch-extern-symbol.c
> @@ -0,0 +1,84 @@

The test module works as expected after fixing the Makefile.

Best Regards,
Petr

Re: [PATCHv6 9/9] man2: Add uretprobe syscall page

[Alejandro Colomar]

Hi Jirka,

On Wed, May 22, 2024 at 09:54:58AM GMT, Jiri Olsa wrote:
> ok, thanks
> 
> jirka
> 
> 
> ---
> diff --git a/man/man2/uretprobe.2 b/man/man2/uretprobe.2
> new file mode 100644
> index ..5b5f340b59b6
> --- /dev/null
> +++ b/man/man2/uretprobe.2
> @@ -0,0 +1,56 @@
> +.\" Copyright (C) 2024, Jiri Olsa 
> +.\"
> +.\" SPDX-License-Identifier: Linux-man-pages-copyleft
> +.\"
> +.TH uretprobe 2 (date) "Linux man-pages (unreleased)"
> +.SH NAME
> +uretprobe \- execute pending return uprobes
> +.SH SYNOPSIS
> +.nf
> +.B int uretprobe(void)
> +.fi
> +.SH DESCRIPTION
> +The
> +.BR uretprobe ()
> +system call is an alternative to breakpoint instructions for triggering 
> return
> +uprobe consumers.
> +.P
> +Calls to
> +.BR uretprobe ()
> +system call are only made from the user-space trampoline provided by the 
> kernel.
> +Calls from any other place result in a
> +.BR SIGILL .
> +.SH RETURN VALUE
> +The
> +.BR uretprobe ()
> +system call return value is architecture-specific.
> +.SH ERRORS
> +.TP
> +.B SIGILL
> +The
> +.BR uretprobe ()
> +system call was called by user.

Maybe 'a user-space program'?
Anyway, LGTM.  Thanks!

Reviewed-by: Alejandro Colomar 

Have a lovely day!
Alex

> +.SH VERSIONS
> +Details of the
> +.BR uretprobe ()
> +system call behavior vary across systems.
> +.SH STANDARDS
> +None.
> +.SH HISTORY
> +TBD
> +.SH NOTES
> +The
> +.BR uretprobe ()
> +system call was initially introduced for the x86_64 architecture
> +where it was shown to be faster than breakpoint traps.
> +It might be extended to other architectures.
> +.P
> +The
> +.BR uretprobe ()
> +system call exists only to allow the invocation of return uprobe consumers.
> +It should
> +.B never
> +be called directly.
> +Details of the arguments (if any) passed to
> +.BR uretprobe ()
> +and the return value are architecture-specific.

-- 



signature.asc
Description: PGP signature

Re: [GIT PULL] virtio: features, fixes, cleanups

[Xuan Zhuo]

On Wed, 22 May 2024 06:03:01 -0400, "Michael S. Tsirkin"  
wrote:
> Things to note here:
>
> - the new Marvell OCTEON DPU driver is not here: latest v4 keeps causing
>   build failures on mips. I deferred the pull hoping to get it in
>   and I might merge a new version post rc1
>   (supposed to be ok for new drivers as they can't cause regressions),
>   but we'll see.
> - there are also a couple bugfixes under review, to be merged after rc1
> - I merged a trivial patch (removing a comment) that also got
>   merged through net.
>   git handles this just fine and it did not seem worth it
>   rebasing to drop it.
> - there is a trivial conflict in the header file. Shouldn't be any
>   trouble to resolve, but fyi the resolution by Stephen is here
>   diff --cc drivers/virtio/virtio_mem.c
>   index e8355f55a8f7,6d4dfbc53a66..
>   --- a/drivers/virtio/virtio_mem.c
>   +++ b/drivers/virtio/virtio_mem.c
>   @@@ -21,7 -21,7 +21,8 @@@
> #include 
> #include 
> #include 
>+#include 
>   + #include 
>   Also see it here:
>   https://lore.kernel.org/all/20240423145947.14217...@canb.auug.org.au/
>
>
>
> The following changes since commit 18daea77cca626f590fb140fc11e3a43c5d41354:
>
>   Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 
> (2024-04-30 12:40:41 -0700)
>
> are available in the Git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
>
> for you to fetch changes up to 0b8dbbdcf2e42273fbac9b752919e2e5b2abac21:
>
>   Merge tag 'for_linus' into vhost (2024-05-12 08:15:28 -0400)
>
> 
> virtio: features, fixes, cleanups
>
> Several new features here:
>
> - virtio-net is finally supported in vduse.
>
> - Virtio (balloon and mem) interaction with suspend is improved
>
> - vhost-scsi now handles signals better/faster.
>
> - virtio-net now supports premapped mode by default,
>   opening the door for all kind of zero copy tricks.
>
> Fixes, cleanups all over the place.
>
> Signed-off-by: Michael S. Tsirkin 
>
> 
> Christophe JAILLET (1):
>   vhost-vdpa: Remove usage of the deprecated ida_simple_xx() API
>
> David Hildenbrand (1):
>   virtio-mem: support suspend+resume
>
> David Stevens (2):
>   virtio_balloon: Give the balloon its own wakeup source
>   virtio_balloon: Treat stats requests as wakeup events
>
> Eugenio Pérez (2):
>   MAINTAINERS: add Eugenio Pérez as reviewer
>   MAINTAINERS: add Eugenio Pérez as reviewer
>
> Jiri Pirko (1):
>   virtio: delete vq in vp_find_vqs_msix() when request_irq() fails
>
> Krzysztof Kozlowski (24):
>   virtio: balloon: drop owner assignment
>   virtio: input: drop owner assignment
>   virtio: mem: drop owner assignment
>   um: virt-pci: drop owner assignment
>   virtio_blk: drop owner assignment
>   bluetooth: virtio: drop owner assignment
>   hwrng: virtio: drop owner assignment
>   virtio_console: drop owner assignment
>   crypto: virtio - drop owner assignment
>   firmware: arm_scmi: virtio: drop owner assignment
>   gpio: virtio: drop owner assignment
>   drm/virtio: drop owner assignment
>   iommu: virtio: drop owner assignment
>   misc: nsm: drop owner assignment
>   net: caif: virtio: drop owner assignment
>   net: virtio: drop owner assignment
>   net: 9p: virtio: drop owner assignment
>   vsock/virtio: drop owner assignment
>   wifi: mac80211_hwsim: drop owner assignment
>   nvdimm: virtio_pmem: drop owner assignment
>   rpmsg: virtio: drop owner assignment
>   scsi: virtio: drop owner assignment
>   fuse: virtio: drop owner assignment
>   sound: virtio: drop owner assignment
>
> Li Zhijian (1):
>   vdpa: Convert sprintf/snprintf to sysfs_emit
>
> Maxime Coquelin (6):
>   vduse: validate block features only with block devices
>   vduse: Temporarily fail if control queue feature requested
>   vduse: enable Virtio-net device type
>   vduse: validate block features only with block devices
>   vduse: Temporarily fail if control queue feature requested
>   vduse: enable Virtio-net device type
>
> Michael S. Tsirkin (2):
>   Merge tag 'stable/vduse-virtio-net' into vhost
>   Merge tag 'for_linus' into vhost
>
> Mike Christie (9):
>   vhost-scsi: Handle vhost_vq_work_queue failures for events
>   vhost-scsi: Handle vhost_vq_work_queue failures for cmds
>   vhost-scsi: Use system wq to flush dev for TMFs
>   vhost: Remove vhost_vq_flush
>   vhost_scsi: Handle vhost_vq_work_queue failures for TMFs
>   vhost: Use virtqueue mutex for swapping worker
>   vhost: Release worker mutex during flushes
>   vhost_task: Handle SIGKILL by flushing work and exiting
>   kernel: Remove signal hacks for vhost_tasks
>
> Uwe Kleine-König (1):
>   

Re: [PATCH v2 2/6] livepatch: Add klp-convert tool

[Petr Mladek]

On Thu 2024-05-16 15:30:05, Lukas Hruska wrote:
> Livepatches need to access external symbols which can't be handled
> by the normal relocation mechanism. It is needed for two types
> of symbols:
> 
>   + Symbols which can be local for the original livepatched function.
> The alternative implementation in the livepatch sees them
> as external symbols.
> 
>   + Symbols in modules which are exported via EXPORT_SYMBOL*(). They
> must be handled special way otherwise the livepatch module would
> depend on the livepatched one. Loading such livepatch would cause
> loading the other module as well.
> 
> The address of these symbols can be found via kallsyms. Or they can
> be relocated using livepatch specific relocation sections as specified
> in Documentation/livepatch/module-elf-format.txt.
> 
> --- /dev/null
> +++ b/scripts/livepatch/klp-convert.c
> +/* Converts rela symbol names */
> +static bool convert_symbol(struct symbol *s)
> +{
> + char lp_obj_name[MODULE_NAME_LEN];
> + char sym_obj_name[MODULE_NAME_LEN];
> + char sym_name[KSYM_NAME_LEN];
> + char *klp_sym_name;
> + unsigned long sym_pos;
> + int poslen;
> + unsigned int length;
> +
> + static_assert(MODULE_NAME_LEN >= 56 && KSYM_NAME_LEN == 512,
> + "Update limit in the below sscanf()");
> +
> + if (sscanf(s->name, KLP_SYM_RELA_PREFIX "%55[^.].%55[^.].%511[^,],%lu",
> + lp_obj_name, sym_obj_name, sym_name, _pos) != 4) {
> + WARN("Invalid format of symbol (%s)\n", s->name);
> + return false;
> + }
> +
> + poslen = calc_digits(sym_pos);
> +
> + length = strlen(KLP_SYM_PREFIX) + strlen(sym_obj_name)
> +  + strlen(sym_name) + sizeof(poslen) + 3;

There should be "poslen" instead of "sizeof(poslen)".

> +
> + klp_sym_name = calloc(1, length);
> + if (!klp_sym_name) {
> + WARN("Memory allocation failed (%s%s.%s,%lu)\n", KLP_SYM_PREFIX,
> + sym_obj_name, sym_name, sym_pos);
> + return false;
> + }
> +
> + if (safe_snprintf(klp_sym_name, length, KLP_SYM_PREFIX "%s.%s,%lu",
> +   sym_obj_name, sym_name, sym_pos)) {
> +
> + WARN("Length error (%s%s.%s,%lu)", KLP_SYM_PREFIX,
> + sym_obj_name, sym_name, sym_pos);
> + free(klp_sym_name);
> + return false;
> + }
> +
> + s->name = klp_sym_name;
> + s->sec = NULL;
> + s->sym.st_name = -1;
> + s->sym.st_shndx = SHN_LIVEPATCH;
> +
> + return true;
> +}
> --- /dev/null
> +++ b/scripts/livepatch/klp-convert.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2016 Josh Poimboeuf 
> + * Copyright (C) 2017 Joao Moreira   
> + *
> + */
> +
> +#define SHN_LIVEPATCH0xff20
> +#define SHF_RELA_LIVEPATCH   0x0010
> +#define MODULE_NAME_LEN  (64 - sizeof(GElf_Addr))
> +#define WARN(format, ...) \
> + fprintf(stderr, "klp-convert: " format "\n", ##__VA_ARGS__)

Nit: I would remove "\n" here and add it to all callers. Half of the
 callers already have it ;-)

> +
> +/*
> + * klp-convert uses macros and structures defined in the linux sources
> + * package (see include/uapi/linux/livepatch.h). To prevent the
> + * dependency when building locally, they are defined below. Also notice
> + * that these should match the definitions from the targeted kernel.
> + */
> +
> +#define KLP_RELA_PREFIX  ".klp.rela."
> +#define KLP_SYM_RELA_PREFIX  ".klp.sym.rela."
> +#define KLP_SYM_PREFIX   ".klp.sym."

Otherwise, it looks good.

Best Regards,
Petr

[GIT PULL] virtio: features, fixes, cleanups

[Michael S. Tsirkin]

Things to note here:

- the new Marvell OCTEON DPU driver is not here: latest v4 keeps causing
  build failures on mips. I deferred the pull hoping to get it in
  and I might merge a new version post rc1
  (supposed to be ok for new drivers as they can't cause regressions),
  but we'll see.
- there are also a couple bugfixes under review, to be merged after rc1
- I merged a trivial patch (removing a comment) that also got
  merged through net.
  git handles this just fine and it did not seem worth it
  rebasing to drop it.
- there is a trivial conflict in the header file. Shouldn't be any
  trouble to resolve, but fyi the resolution by Stephen is here
diff --cc drivers/virtio/virtio_mem.c
index e8355f55a8f7,6d4dfbc53a66..
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@@ -21,7 -21,7 +21,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  Also see it here:
  https://lore.kernel.org/all/20240423145947.14217...@canb.auug.org.au/



The following changes since commit 18daea77cca626f590fb140fc11e3a43c5d41354:

  Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 
(2024-04-30 12:40:41 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus

for you to fetch changes up to 0b8dbbdcf2e42273fbac9b752919e2e5b2abac21:

  Merge tag 'for_linus' into vhost (2024-05-12 08:15:28 -0400)


virtio: features, fixes, cleanups

Several new features here:

- virtio-net is finally supported in vduse.

- Virtio (balloon and mem) interaction with suspend is improved

- vhost-scsi now handles signals better/faster.

- virtio-net now supports premapped mode by default,
  opening the door for all kind of zero copy tricks.

Fixes, cleanups all over the place.

Signed-off-by: Michael S. Tsirkin 


Christophe JAILLET (1):
  vhost-vdpa: Remove usage of the deprecated ida_simple_xx() API

David Hildenbrand (1):
  virtio-mem: support suspend+resume

David Stevens (2):
  virtio_balloon: Give the balloon its own wakeup source
  virtio_balloon: Treat stats requests as wakeup events

Eugenio Pérez (2):
  MAINTAINERS: add Eugenio Pérez as reviewer
  MAINTAINERS: add Eugenio Pérez as reviewer

Jiri Pirko (1):
  virtio: delete vq in vp_find_vqs_msix() when request_irq() fails

Krzysztof Kozlowski (24):
  virtio: balloon: drop owner assignment
  virtio: input: drop owner assignment
  virtio: mem: drop owner assignment
  um: virt-pci: drop owner assignment
  virtio_blk: drop owner assignment
  bluetooth: virtio: drop owner assignment
  hwrng: virtio: drop owner assignment
  virtio_console: drop owner assignment
  crypto: virtio - drop owner assignment
  firmware: arm_scmi: virtio: drop owner assignment
  gpio: virtio: drop owner assignment
  drm/virtio: drop owner assignment
  iommu: virtio: drop owner assignment
  misc: nsm: drop owner assignment
  net: caif: virtio: drop owner assignment
  net: virtio: drop owner assignment
  net: 9p: virtio: drop owner assignment
  vsock/virtio: drop owner assignment
  wifi: mac80211_hwsim: drop owner assignment
  nvdimm: virtio_pmem: drop owner assignment
  rpmsg: virtio: drop owner assignment
  scsi: virtio: drop owner assignment
  fuse: virtio: drop owner assignment
  sound: virtio: drop owner assignment

Li Zhijian (1):
  vdpa: Convert sprintf/snprintf to sysfs_emit

Maxime Coquelin (6):
  vduse: validate block features only with block devices
  vduse: Temporarily fail if control queue feature requested
  vduse: enable Virtio-net device type
  vduse: validate block features only with block devices
  vduse: Temporarily fail if control queue feature requested
  vduse: enable Virtio-net device type

Michael S. Tsirkin (2):
  Merge tag 'stable/vduse-virtio-net' into vhost
  Merge tag 'for_linus' into vhost

Mike Christie (9):
  vhost-scsi: Handle vhost_vq_work_queue failures for events
  vhost-scsi: Handle vhost_vq_work_queue failures for cmds
  vhost-scsi: Use system wq to flush dev for TMFs
  vhost: Remove vhost_vq_flush
  vhost_scsi: Handle vhost_vq_work_queue failures for TMFs
  vhost: Use virtqueue mutex for swapping worker
  vhost: Release worker mutex during flushes
  vhost_task: Handle SIGKILL by flushing work and exiting
  kernel: Remove signal hacks for vhost_tasks

Uwe Kleine-König (1):
  virtio-mmio: Convert to platform remove callback returning void

Xuan Zhuo (7):
  virtio_ring: introduce dma map api for page
  virtio_ring: enable premapped mode whatever use_dma_api
  virtio_net: replace private by pp struct inside page
  virtio_net: big mode 

Re: [PATCHv6 bpf-next 0/9] uprobe: uretprobe speed up

[Jiri Olsa]

On Tue, May 21, 2024 at 01:57:33PM -0700, Alexei Starovoitov wrote:
> On Tue, May 21, 2024 at 1:49 PM Deepak Gupta  wrote:
> >
> > On Tue, May 21, 2024 at 12:48:16PM +0200, Jiri Olsa wrote:
> > >hi,
> > >as part of the effort on speeding up the uprobes [0] coming with
> > >return uprobe optimization by using syscall instead of the trap
> > >on the uretprobe trampoline.
> >
> > I understand this provides an optimization on x86. I believe primary reason
> > is syscall is straight-line microcode and short sequence while trap delivery
> > still does all the GDT / IDT and segmentation checks and it makes delivery
> > of the trap slow.
> >
> > So doing syscall improves that. Although it seems x86 is going to get rid of
> > that as part of FRED [1, 2]. And linux kernel support for FRED is already 
> > upstream [2].
> > So I am imagining x86 hardware already exists with FRED support.
> >
> > On other architectures, I believe trap delivery for breakpoint instruction
> > is same as syscall instruction.
> >
> > Given that x86 trap delivery is pretty much going following the suit here 
> > and
> > intend to make trap delivery cost similar to syscall delivery.
> >
> > Sorry for being buzzkill here but ...
> > Is it worth introducing this syscall which otherwise has no use on other 
> > arches
> > and x86 (and x86 kernel) has already taken steps to match trap delivery 
> > latency with
> > syscall latency would have similar cost?
> >
> > Did you do any study of this on FRED enabled x86 CPUs?

nope.. interesting, will check, thanks

> 
> afaik CPUs with FRED do not exist on the market and it's
> not clear when they will be available.
> And when they finally will be on the shelves
> the overhead of FRED vs int3 would still have to be measured.
> int3 with FRED might still be higher than syscall with FRED.

+1, also it's not really a complicated change and the wiring of the
new syscall to uretprobe is really simple and we could go back to int3
with just one single patch if we see no longer any benefit to it,
but at the moment it provides speed up

jirka

> 
> >
> > [1] - 
> > https://www.intel.com/content/www/us/en/content-details/780121/flexible-return-and-event-delivery-fred-specification.html
> > [2] - https://docs.kernel.org/arch/x86/x86_64/fred.html
> >
> > >
> > >The speed up depends on instruction type that uprobe is installed
> > >and depends on specific HW type, please check patch 1 for details.
> > >

Re: [PATCHv6 9/9] man2: Add uretprobe syscall page

[Jiri Olsa]

On Tue, May 21, 2024 at 10:54:36PM +0200, Alejandro Colomar wrote:
> Hi Jirka,
> 
> On Tue, May 21, 2024 at 10:24:30PM GMT, Jiri Olsa wrote:
> > how about the change below?
> 
> Much better.  I still have a few comments below.  :-)
> 
> > 
> > thanks,
> > jirka
> > 
> > 
> > ---
> > diff --git a/man/man2/uretprobe.2 b/man/man2/uretprobe.2
> > new file mode 100644
> > index ..959b7a47102b
> > --- /dev/null
> > +++ b/man/man2/uretprobe.2
> > @@ -0,0 +1,55 @@
> > +.\" Copyright (C) 2024, Jiri Olsa 
> > +.\"
> > +.\" SPDX-License-Identifier: Linux-man-pages-copyleft
> > +.\"
> > +.TH uretprobe 2 (date) "Linux man-pages (unreleased)"
> > +.SH NAME
> > +uretprobe \- execute pending return uprobes
> > +.SH SYNOPSIS
> > +.nf
> > +.B int uretprobe(void)
> > +.fi
> > +.SH DESCRIPTION
> > +The
> > +.BR uretprobe ()
> > +system call is an alternative to breakpoint instructions for triggering 
> > return
> > +uprobe consumers.
> > +.P
> > +Calls to
> > +.BR uretprobe ()
> > +system call are only made from the user-space trampoline provided by the 
> > kernel.
> > +Calls from any other place result in a
> > +.BR SIGILL .
> > +.SH RETURN VALUE
> > +The
> > +.BR uretprobe ()
> > +system call return value is architecture-specific.
> > +.SH ERRORS
> > +.BR SIGILL
> 
> This should be a tagged paragraph, preceeded with '.TP'.  See any manual
> page with an ERRORS section for an example.
> 
> Also, BR is Bold alternating with Roman, but this is just bold, so it
> should use '.B'.
> 
> .TP
> .B SIGILL

ok

> 
> > +The
> > +.BR uretprobe ()
> > +system call was called by user.
> > +.SH VERSIONS
> > +Details of the
> > +.BR uretprobe ()
> > +system call behavior vary across systems.
> > +.SH STANDARDS
> > +None.
> > +.SH HISTORY
> > +TBD
> > +.SH NOTES
> > +The
> > +.BR uretprobe ()
> > +system call was initially introduced for the x86_64 architecture where it 
> > was shown
> 
> We have a strong-ish limit at column 80.  Please break after
> 'architecture', which is a clause boundary.
> 

ok, thanks

jirka


---
diff --git a/man/man2/uretprobe.2 b/man/man2/uretprobe.2
new file mode 100644
index ..5b5f340b59b6
--- /dev/null
+++ b/man/man2/uretprobe.2
@@ -0,0 +1,56 @@
+.\" Copyright (C) 2024, Jiri Olsa 
+.\"
+.\" SPDX-License-Identifier: Linux-man-pages-copyleft
+.\"
+.TH uretprobe 2 (date) "Linux man-pages (unreleased)"
+.SH NAME
+uretprobe \- execute pending return uprobes
+.SH SYNOPSIS
+.nf
+.B int uretprobe(void)
+.fi
+.SH DESCRIPTION
+The
+.BR uretprobe ()
+system call is an alternative to breakpoint instructions for triggering return
+uprobe consumers.
+.P
+Calls to
+.BR uretprobe ()
+system call are only made from the user-space trampoline provided by the 
kernel.
+Calls from any other place result in a
+.BR SIGILL .
+.SH RETURN VALUE
+The
+.BR uretprobe ()
+system call return value is architecture-specific.
+.SH ERRORS
+.TP
+.B SIGILL
+The
+.BR uretprobe ()
+system call was called by user.
+.SH VERSIONS
+Details of the
+.BR uretprobe ()
+system call behavior vary across systems.
+.SH STANDARDS
+None.
+.SH HISTORY
+TBD
+.SH NOTES
+The
+.BR uretprobe ()
+system call was initially introduced for the x86_64 architecture
+where it was shown to be faster than breakpoint traps.
+It might be extended to other architectures.
+.P
+The
+.BR uretprobe ()
+system call exists only to allow the invocation of return uprobe consumers.
+It should
+.B never
+be called directly.
+Details of the arguments (if any) passed to
+.BR uretprobe ()
+and the return value are architecture-specific.

Re: [PATCH RFC 1/2] dt-bindings: soc: qcom,smsm: Allow specifying mboxes instead of qcom,ipc

[Krzysztof Kozlowski]

On 21/05/2024 22:35, Luca Weiss wrote:
> On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
>> On 20/05/2024 17:11, Luca Weiss wrote:
>>> Hi Krzysztof
>>>
>>> Ack, sounds good.
>>>
>>> Maybe also from you, any opinion between these two binding styles?
>>>
>>> So first using index of mboxes for the numbering, where for the known
>>> usages the first element (and sometimes the 3rd - ipc-2) are empty <>.
>>>
>>> The second variant is using mbox-names to get the correct channel-mbox
>>> mapping.
>>>
>>> -   qcom,ipc-1 = < 8 13>;
>>> -   qcom,ipc-2 = < 8 9>;
>>> -   qcom,ipc-3 = < 8 19>;
>>> +   mboxes = <0>, < 13>, < 9>, < 19>;
>>>
>>> vs.
>>>
>>> -   qcom,ipc-1 = < 8 13>;
>>> -   qcom,ipc-2 = < 8 9>;
>>> -   qcom,ipc-3 = < 8 19>;
>>> +   mboxes = < 13>, < 9>, < 19>;
>>> +   mbox-names = "ipc-1", "ipc-2", "ipc-3";
>>
>> Sorry, don't get, ipc-1 is the first mailbox, so why would there be <0>
>> in first case?
> 
> Actually not, ipc-0 would be permissible by the driver, used for the 0th host
> 
> e.g. from:
> 
>   /* Iterate over all hosts to check whom wants a kick */
>   for (host = 0; host < smsm->num_hosts; host++) {
>   hostp = >hosts[host];
> 
> Even though no mailbox is specified in any upstream dts for this 0th host I
> didn't want the bindings to restrict that, that's why in the first example
> there's an empty element (<0>) for the 0th smsm host
> 
>> Anyway, the question is if you need to know that some
>> mailbox is missing. But then it is weird to name them "ipc-1" etc.
> 
> In either case we'd just query the mbox (either by name or index) and then
> see if it's there? Not quite sure I understand the sentence..
> Pretty sure either binding would work the same way.

The question is: does the driver care only about having some mailboxes
or the driver cares about each specific mailbox? IOW, is skipping ipc-0
important for the driver?


Best regards,
Krzysztof

Re: [PATCH v3 1/2] LoongArch: KVM: Add steal time support in kvm side

[kernel test robot]

Hi Bibo,

kernel test robot noticed the following build errors:

[auto build test ERROR on 3c999d1ae3c75991902a1a7dad0cb62c2a3008b4]

url:
https://github.com/intel-lab-lkp/linux/commits/Bibo-Mao/LoongArch-KVM-Add-steal-time-support-in-kvm-side/20240521-104902
base:   3c999d1ae3c75991902a1a7dad0cb62c2a3008b4
patch link:
https://lore.kernel.org/r/20240521024556.419436-2-maobibo%40loongson.cn
patch subject: [PATCH v3 1/2] LoongArch: KVM: Add steal time support in kvm side
config: loongarch-randconfig-r051-20240522 
(https://download.01.org/0day-ci/archive/20240522/202405221317.lctbjh1f-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240522/202405221317.lctbjh1f-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202405221317.lctbjh1f-...@intel.com/

All errors (new ones prefixed by >>):

   arch/loongarch/kvm/exit.c: In function 'kvm_save_notify':
>> arch/loongarch/kvm/exit.c:711:63: error: 'struct sched_info' has no member 
>> named 'run_delay'
 711 | vcpu->arch.st.last_steal = 
current->sched_info.run_delay;
 |   ^
--
   arch/loongarch/kvm/vcpu.c: In function 'kvm_update_stolen_time':
>> arch/loongarch/kvm/vcpu.c:67:37: error: 'struct sched_info' has no member 
>> named 'run_delay'
  67 | steal += current->sched_info.run_delay -
 | ^
   arch/loongarch/kvm/vcpu.c:69:55: error: 'struct sched_info' has no member 
named 'run_delay'
  69 | vcpu->arch.st.last_steal = current->sched_info.run_delay;
 |   ^
   arch/loongarch/kvm/vcpu.c: In function 'kvm_loongarch_pvtime_set_attr':
   arch/loongarch/kvm/vcpu.c:138:63: error: 'struct sched_info' has no member 
named 'run_delay'
 138 | vcpu->arch.st.last_steal = 
current->sched_info.run_delay;
 |   ^


vim +711 arch/loongarch/kvm/exit.c

   692  
   693  static long kvm_save_notify(struct kvm_vcpu *vcpu)
   694  {
   695  unsigned long id, data;
   696  
   697  id   = kvm_read_reg(vcpu, LOONGARCH_GPR_A1);
   698  data = kvm_read_reg(vcpu, LOONGARCH_GPR_A2);
   699  switch (id) {
   700  case KVM_FEATURE_STEAL_TIME:
   701  if (!kvm_pvtime_supported())
   702  return KVM_HCALL_INVALID_CODE;
   703  
   704  if (data & ~(KVM_STEAL_PHYS_MASK | 
KVM_STEAL_PHYS_VALID))
   705  return KVM_HCALL_INVALID_PARAMETER;
   706  
   707  vcpu->arch.st.guest_addr = data;
   708  if (!(data & KVM_STEAL_PHYS_VALID))
   709  break;
   710  
 > 711  vcpu->arch.st.last_steal = 
 > current->sched_info.run_delay;
   712  kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
   713  break;
   714  default:
   715  break;
   716  };
   717  
   718  return 0;
   719  };
   720  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki