lkml.org

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rss version="2.0">  <channel> <title>lkml.org</title> <link>http://lkml.org</link> <description>lkml.org - the realtime linux kernel mailinglist archive</description> <lastBuildDate>Fri, 21 Mar 2025 20:57:00 +0100</lastBuildDate> <item> <title>s390-linux-ld: Error: unable to disambiguate: -no-pie (did you mea ...</title> <author>kernel test robot <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/22/8</link> <description>kernel test robot writes: (Summary) tree: <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git</a> master head: b3ee1e4609512dfff642a96b34d7e5dfcdc92d05 commit: 00cda11d3b2ea07295490b7d67942014f1cbc5c1 s390: Compile kernel with -fPIC and link with -no-pie date: 11 months ago config: s390-randconfig-002-20250321 (<a href="https://download.01.org/0day-ci/archive/20250322/202503220342.T3fElO9L-lkp@intel.com/config">https://download.01.org/0day-ci/archive/20250322/202503220342.T3fElO9L-lkp@intel.com/config</a>) compiler: s390-linux-gcc (GCC) 8.5.0 reproduce (this is a W=1 build): (<a href="https://download.01.org/0day-ci/archive/20250322/202503220342.T3fElO9L-lkp@intel.com/reproduce">https://download.01.org/0day-ci/archive/20250322/202503220342.T3fElO9L-lkp@intel.com/reproduce</a>) reproduce (this is a W=1 build): (<a href="https://download.01.org/0day-ci/archive/20250322/202503220342.T3fElO9L-lkp@intel.com/reproduce">https://download.01.</description> </item> <item> <title>Re: [PATCH v2] PCI: Fix NULL dereference in SR-IOV VF creation err ...</title> <author>Bjorn Helgaas <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1315</link> <description>Bjorn Helgaas writes: (Summary) On Mon, Mar 10, 2025 at 10:45:24AM +0200, Shay Drory wrote: Signed-off-by: Shay Drory &lt;shayd@nvidia.com&gt; Applied to pci/resource for v6.15, thanks! Applied to pci/resource for v6.15, thanks! I like how pci_iov_scan_device() turned out. I like how pci_iov_scan_device() turned out. --- &gt; @@ -285,23 +285,16 @@ const struct attribute_group sriov_vf_dev_attr_group = { &gt; + struct pci_bus *bus) &gt; + if (rc) { &gt; + } &gt; + if (IS_ERR(virtfn)) { &gt; + } &gt; </description> </item> <item> <title>Re: [PATCH 0/3] Consistently look up fixed buffers before going async</title> <author>Jens Axboe <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1314</link> <description>Jens Axboe writes: (Summary) On Fri, 21 Mar 2025 12:48:16 -0600, Caleb Sander Mateos wrote: [...] Applied, thanks! Applied, thanks! [1/3] io_uring/net: only import send_zc buffer once commit: 8e3100fcc5cbba03518b8b5c059624aba5c29d50 [2/3] io_uring/net: import send_zc fixed buffer before going async commit: 15f4c96bec5d0791904ee68c0f83ba18cab7466d [3/3] io_uring/uring_cmd: import fixed buffer before going async commit: 70085217bec1eb8bbd19e661da9f1734ed8d35ca commit: 70085217bec1eb8bbd19e661da9f1734ed8d35ca Best regards, </description> </item> <item> <title>[PATCH v2] tracing: Disable branch profiling in noinstr code</title> <author>Josh Poimboeuf <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1313</link> <description>Josh Poimboeuf writes: (Summary) KCOV_INSTRUMENT_softirq.o := n diff --git a/kernel/entry/Makefile b/kernel/entry/Makefile index 095c775e001e..d4b8bd0af79b 100644 --- a/kernel/entry/Makefile +++ b/kernel/entry/Makefile @@ -6,6 +6,9 @@ KASAN_SANITIZE := n UBSAN_SANITIZE := n KCOV_INSTRUMENT := n +# Branch profiling isn't noinstr-safe +ccflags-$(CONFIG_TRACE_BRANCH_PROFILING) += -DDISABLE_BRANCH_PROFILING + CFLAGS_REMOVE_common.o = -fstack-protector -fstack-protector-strong CFLAGS_common.o += -fno-stack-protector diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile index 976092b7bd45..8ae86371ddcd 100644 --- a/kernel/sched/Makefile +++ b/kernel/sched/Makefile @@ -22,6 +22,11 @@ ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y) CFLAGS_core.o := $(PROFILING) -fno-omit-frame-pointer endif +# Branch profiling isn't noinstr-safe +ifdef CONFIG_TRACE_BRANCH_PROFILING +CFLAGS_build_policy.o += -DDISABLE_BRANCH_PROFILING +CFLAGS_build_utility.o += -DDISABLE_BRANCH_PROFILING +endif # # Build efficiency: # diff --git a/kernel/time/Mak</description> </item> <item> <title>Re: [PATCH v2 2/5] iio: adc: ad4000: Add support for SPI offload</title> <author>Marcelo Schmitt <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1312</link> <description>Marcelo Schmitt writes: (Summary) Will apply the simplification. ... Unrelated change (adding braces)? Oops, will undo. Oops, will undo. discover the max sample rate. I don't think we should have sampling_frequency_available in this case because there is no clear list of sample frequency values nor they can always be expressed as "[min step max]" triad. <a href="https://web.git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/Documentation/ABI/testing/sysfs-bus-iio?h=testing#n121">https://web.git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/Documentation/ABI/testing/sysfs-bus-iio?h=testing#n121</a> <a href="https://web.git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/Documentation/ABI/testing/sysfs-bus-iio?h=testing#n121">https://web.git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/Documentation/ABI/testing/sysfs-bus-iio?h=testing#n121</a> ... Ack Ack ... Ack<br/</description> </item> <item> <title>Re: [PATCH V1] accel/amdxdna: Add BO import and export</title> <author>Lizhi Hou <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1311</link> <description>Lizhi Hou writes: </description> </item> <item> <title>Re: [PATCH v2 0/3] vsock: add namespace support to vhost-vsock</title> <author>"Michael S. Tsirkin" <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1310</link> <description>&quot;Michael S. Tsirkin&quot; writes: On Wed, Mar 12, 2025 at 01:59:34PM -0700, Bobby Eshleman wrote: disconnected, the CID becomes available again. disconnected, the CID becomes available again. yea that's a sane way to do it. Thanks! Thanks! Bobby Eshleman &lt;bobbyeshleman@gmail.com&gt; Bobby Eshleman &lt;bobbyeshleman@gmail.com&gt; Bobby Eshleman &lt;bobbyeshleman@gmail.com&gt; </description> </item> <item> <title>[PATCH v4 3/3] fs: introduce getfsxattrat and setfsxattrat syscalls</title> <author>Andrey Albershteyn <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1309</link> <description>Andrey Albershteyn writes: (Summary) 3 + 20 files changed, 178 insertions(+), 1 deletion(-) diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl index c59d53d6d3f3490f976ca179ddfe02e69265ae4d..4b9e687494c16b60c6fd6ca1dc4d6564706a7e25 100644 --- a/arch/alpha/kernel/syscalls/syscall.tbl +++ b/arch/alpha/kernel/syscalls/syscall.tbl @@ -506,3 +506,5 @@ 574 common getxattrat sys_getxattrat 575 common listxattrat sys_listxattrat 576 common removexattrat sys_removexattrat +577 common getfsxattrat sys_getfsxattrat +578 common setfsxattrat sys_setfsxattrat diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl index 49eeb2ad8dbd8e074c6240417693f23fb328afa8..66466257f3c2debb3e2299f0b608c6740c98cab2 100644 --- a/arch/arm/tools/syscall.tbl +++ b/arch/arm/tools/syscall.tbl @@ -481,3 +481,5 @@ 464 common getxattrat sys_getxattrat 465 common listxattrat sys_listxattrat 466 common removexattrat sys_removexattrat +467 common getfsxattrat sys_getfsxattrat +468 common setfsxattrat </description> </item> <item> <title>[PATCH v4 2/3] fs: split fileattr/fsxattr converters into helpers</title> <author>Andrey Albershteyn <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1308</link> <description>Andrey Albershteyn writes: (Summary) 2 ++ 2 files changed, 23 insertions(+), 11 deletions(-) diff --git a/fs/ioctl.c b/fs/ioctl.c index 4434c97bc5dff5a3e8635e28745cd99404ff353e..840283d8c406623d8d26790f89b62ebcbd39e2de 100644 --- a/fs/ioctl.c +++ b/fs/ioctl.c @@ -538,6 +538,16 @@ int vfs_fileattr_get(struct dentry *dentry, struct fileattr *fa) } EXPORT_SYMBOL(vfs_fileattr_get); +} + static int copy_fsxattr_from_user(struct fileattr *fa, struct fsxattr __user *ufa) { @@ -571,11 +585,7 @@ static int copy_fsxattr_from_user(struct fileattr *fa, if (copy_from_user(&amp;xfa, ufa, sizeof(xfa))) return -EFAULT; </description> </item> <item> <title>[PATCH v4 0/3] fs: introduce getfsxattrat and setfsxattrat syscalls</title> <author>Andrey Albershteyn <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1307</link> <description>Andrey Albershteyn writes: </description> </item> <item> <title>[PATCH v4 1/3] lsm: introduce new hooks for setting/getting inode ...</title> <author>Andrey Albershteyn <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1306</link> <description>Andrey Albershteyn writes: (Summary) +} + +/** + * security_inode_getfsxattr() - check if retrieving fsxattr is allowed + * @inode: inode to retrieve filesystem extended attributes from + * @fa: extended attributes to get + * + * Called when getfsxattrat() syscall or FS_IOC_FSGETXATTR ioctl() is called on + * inode + * + * Return: Returns 0 if permission is granted. </description> </item> <item> <title>Re: distro support for CONFIG_KUNIT: [PATCH 0/3] bitmap: convert s ...</title> <author>Tamir Duberstein <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1305</link> <description>Tamir Duberstein writes: (Summary) In other words, I'm not aware of something trivial I can run that will exit 0 if and only if the bitmap tests pass. if the bitmap tests pass. - What do _you_ need from the tests? I know for sure that KUnit tests are automatically run by LKP because other tests I converted to KUnit subsequently had warnings reported by LKP. KUnit subsequently had warnings reported by LKP. - How exactly KUNIT helps you testing bitmaps and friends better? </description> </item> <item> <title>[PATCH] iommu/vt-d: Wire up irq_ack() to irq_move_irq() for posted ...</title> <author>Sean Christopherson <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1304</link> <description>Sean Christopherson writes: (Summary) // No EOI * handle_irq_event() * driver_handler() * handle_edge_irq() * irq_chip_ack_parent() - * dummy(); // No EOI * handle_irq_event() * driver_handler() * apic_eoi() * irq_exit() + * */ - -static void dummy_ack(struct irq_data *d) { } - static struct irq_chip intel_ir_chip_post_msi = { .name = "INTEL-IR-POST", - .irq_ack = dummy_ack, + .irq_ack = irq_move_irq, .irq_set_affinity = intel_ir_set_affinity, .irq_compose_msi_msg = intel_ir_compose_msi_msg, .irq_set_vcpu_affinity = intel_ir_set_vcpu_affinity, base-commit: d07de43e3f05576fd275c8c82e413d91932119a5 </description> </item> <item> <title>[PATCH 6.1 v2 2/2] efivarfs: Move efivarfs list into superblock s_ ...</title> <author>Alexey Nepomnyashih <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1303</link> <description>Alexey Nepomnyashih writes: (Summary) 5 +++-- 4 files changed, 18 insertions(+), 15 deletions(-) diff --git a/fs/efivarfs/inode.c b/fs/efivarfs/inode.c index e93f2afd6741..3b5b956dbf44 100644 --- a/fs/efivarfs/inode.c +++ b/fs/efivarfs/inode.c @@ -77,6 +77,7 @@ static bool efivarfs_valid_name(const char *str, int len) static int efivarfs_create(struct user_namespace *mnt_userns, struct inode *dir, struct dentry *dentry, umode_t mode, bool excl) { + struct efivarfs_fs_info *info = dir-&gt;i_sb-&gt;s_fs_info; @@ -119,7 +117,8 @@ static struct dentry *efivarfs_alloc_dentry(struct dentry *parent, char *name) } static int efivarfs_callback(efi_char16_t *name16, efi_guid_t vendor, - unsigned long name_size, void *data) + unsigned long name_size, void *data, + struct list_head *list) { struct super_block *sb = (struct super_block *)data; </description> </item> <item> <title>[PATCH 6.1 v2 1/2] efivarfs: Add uid/gid mount options</title> <author>Alexey Nepomnyashih <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1302</link> <description>Alexey Nepomnyashih writes: (Summary) +} + static const struct super_operations efivarfs_ops = { .statfs = simple_statfs, .drop_inode = generic_delete_inode, .evict_inode = efivarfs_evict_inode, + .show_options = efivarfs_show_options, }; + +static const struct fs_parameter_spec efivarfs_parameters[] = { + fsparam_u32("uid", Opt_uid), + fsparam_u32("gid", Opt_gid), + {}, +}; + + switch (opt) { + case Opt_uid: + opts-&gt;uid = make_kuid(current_user_ns(), result.uint_32); </description> </item> <item> <title>Re: [PATCH] spi: Ensure memory used for spi_write_then_read() is D ...</title> <author>"Arnd Bergmann" <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1301</link> <description>&quot;Arnd Bergmann&quot; writes: (Summary) On Fri, Mar 21, 2025, at 15:45, Mark Brown wrote: fully thought that through yet. My feeling so far is that we want the default regmap interface to just take any buffer (stack, misaligned, vmalloc, kmap) and leave it up to the underlying bus to make sure this works in a sensible way. a sensible way. Using dma_alloc_noncoherent() should make the implementation much nicer than GFP_DMA in the past, so we could add a bus specific helper for SPI that checks if the controller actually wants to do DMA and whether the buffer is problematic at all, and then decides to either allocate a bounce buffer and fill the sg table with the correct DMA address, map the existing buffer, or pass it without mapping depending on what the device needs. what the device needs. Arnd Arnd Arnd </description> </item> <item> <title>Re: [PATCH v14 02/11] rust: add dma coherent allocator abstraction.</title> <author>Danilo Krummrich <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1300</link> <description>Danilo Krummrich writes: (Summary) On Fri, Mar 21, 2025 at 03:25:39PM -0300, Jason Gunthorpe wrote: allocation to hold the CoherentAllocation memory array! One solution that comes immediately to my mind is to have something like a CoherentAllocationPool that holds all the repeating metadata and provides an API to give you continuous allocations of the same kind without any bloat. We have to start somewhere and work it out continuously and keep improving things as required. :) IMHO, it's about finding a good balance. finding a good balance. finding a good balance. </description> </item> <item> <title>Re: [PATCH v7 8/8] vhost: Add a KConfig knob to enable IOCTL VHOST ...</title> <author>"Michael S. Tsirkin" <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1299</link> <description>&quot;Michael S. Tsirkin&quot; writes: </description> </item> <item> <title>[GIT PULL] Documentation for 6.15</title> <author>Jonathan Corbet <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1298</link> <description>Jonathan Corbet writes: (Summary) ---------------------------------------------------------------- Aditya Dutt (1): Documentation/driver-api: fixed spelling mistakes Akira Yokosawa (3): docs: submit-checklist: Expand on build tests against different word sizes docs/ja_JP: Convert SubmitChecklist into reST with belated updates docs/.../submit-checklist: Use Documentation/admin-guide/abi.rst for cross-ref of README Alex Shi (3): docs/zh_CN: add maintainer tree for Chinese doc pickup docs/zh_CN: add few request for Chinese translation docs/Chinese: change the disclaimer words Armin Mahdilou (1): Documentation: typo fixes Brendan Connelly (1): Documentation: input: Add section pertaining to polled input devices Brian Ochoa (1): docs: arch/x86/sva: Fix two grammar errors under Background and FAQ Charles Han (1): Documentation: Remove repeated word in docs Chen Pei (1): Documentation: riscv: Remove KPROBES_ON_FTRACE David Reaver (1): docs: iostats: Rewrite intro</description> </item> <item> <title>Re: [PATCH v2 3/4] rust: pci: impl TryFrom<&Device> for &pci::Device</title> <author>Miguel Ojeda <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1297</link> <description>Miguel Ojeda writes: (Summary) in the sense that it was a restriction before, and now they relaxed it, so more programs are accepted, and the feature would be "you need less `unsafe`" etc. `unsafe`" etc. The blog post seems to mention both sides of the coin ("This code is now allowed", "Relaxed this", "A future version of Rust is expected to generalize this"). generalize this"). en after quite a while of searching. You're welcome! You're welcome! Cheers, Miguel Miguel Miguel </description> </item> <item> <title>Re: [PATCH v7 0/8] vhost: Add support of kthread API</title> <author>"Michael S. Tsirkin" <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1296</link> <description>&quot;Michael S. Tsirkin&quot; writes: On Sun, Mar 02, 2025 at 10:32:02PM +0800, Cindy Lu wrote: userspace applications to configure their thread mode. This seems to be on top of an old tree. Can you rebase pls? Can you rebase pls? 2.45.0 2.45.0 2.45.0 </description> </item> <item> <title>Re: [PATCH v2 3/6] x86/hyperv: Use hv_hvcall_*() to set up hyperca ...</title> <author>Nuno Das Neves <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1295</link> <description>Nuno Das Neves writes: On 3/12/2025 11:19 PM, mhkelley58@gmail.com wrote: 4 files changed, 21 insertions(+), 34 deletions(-) Reviewed-by: Nuno Das Neves &lt;nunodasneves@linux.microsoft.com&gt; Reviewed-by: Nuno Das Neves &lt;nunodasneves@linux.microsoft.com&gt; Reviewed-by: Nuno Das Neves &lt;nunodasneves@linux.microsoft.com&gt; </description> </item> <item> <title>Re: [PATCH] wifi: ath11k: fix ring-buffer corruption</title> <author>Jens Glathe <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1294</link> <description>Jens Glathe writes: (Summary) On 3/21/25 10:49, Johan Hovold wrote: ected 1492 ected 1484 I had this issue on the Windows Dev Kit 2023 and X13s, interestingly never on the HP Omnibook X14. With this patch there have been no occurrences. occurrences. Tested-by: Jens Glathe &lt;jens.glathe@oldschoolsolutions.biz&gt; Tested-by: Jens Glathe &lt;jens.glathe@oldschoolsolutions.biz&gt; with best regards with best regards Jens Jens Jens Jens </description> </item> <item> <title>Re: [PATCH v1 1/1] i3c: master: Drop duplicate check before callin ...</title> <author>Andy Shevchenko <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1293</link> <description>Andy Shevchenko writes: On Fri, Mar 21, 2025 at 09:25:26PM +0200, Andy Shevchenko wrote: for the returned value, no need to check for the parameter. Ignore this, it is partially done. Ignore this, it is partially done. </description> </item> <item> <title>[PATCH v2 1/1] i3c: master: Drop duplicate check before calling OF ...</title> <author>Andy Shevchenko <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1292</link> <description>Andy Shevchenko writes: (Summary) 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c index d5dc4180afbc..fd26c4bb8b34 100644 --- a/drivers/i3c/master.c +++ b/drivers/i3c/master.c @@ -2276,7 +2276,7 @@ static int of_i3c_master_add_dev(struct i3c_master_controller *master, u32 reg[3]; - if (client-&gt;dev.of_node) { - u32 reg[3]; - - if (!of_property_read_u32_array(client-&gt;dev.of_node, "reg", - reg, ARRAY_SIZE(reg))) - lvr = reg[2]; - } + if (!of_property_read_u32_array(client-&gt;dev.of_node, "reg", reg, ARRAY_SIZE(reg))) + lvr = reg[2]; </description> </item> <item> <title>Re: [PATCH] clang-format: add for_each macros from libfdt</title> <author>Bill Wendling <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1291</link> <description>Bill Wendling writes: On Thu, Mar 20, 2025 at 4:59=E2=80=AFPM Changyuan Lyu &lt;changyuanl@google.co= m&gt; wrote: + - 'fdt_for_each_subnode' Could you alphabetize these please? Could you alphabetize these please? 2.49.0.395.g12beb8f557-goog 2.49.0.395.g12beb8f557-goog </description> </item> <item> <title>Re: [PATCH] x86/tsc: Add debugfs entry to mark TSC as unstable aft ...</title> <author>"Guilherme G. Piccoli" <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1290</link> <description>&quot;Guilherme G. Piccoli&quot; writes: </description> </item> <item> <title>[PATCH v1 1/1] i3c: master: Drop duplicate check before calling OF ...</title> <author>Andy Shevchenko <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1289</link> <description>Andy Shevchenko writes: (Summary) 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c index d5dc4180afbc..1580e2630dfe 100644 --- a/drivers/i3c/master.c +++ b/drivers/i3c/master.c @@ -2486,7 +2486,7 @@ static int i3c_master_i2c_adapter_init(struct i3c_master_controller *master) struct i2c_adapter *adap = i3c_master_to_i2c_adapter(master); - int ret, id = -ENODEV; - if (master-&gt;dev.of_node) - id = of_alias_get_id(master-&gt;dev.of_node, "i2c"); if (id &gt;= 0) { adap-&gt;nr = id; </description> </item> <item> <title>Re: [PATCH v2 2/6] x86/hyperv: Use hv_hvcall_*() to set up hyperca ...</title> <author>Nuno Das Neves <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1288</link> <description>Nuno Das Neves writes: On 3/12/2025 11:19 PM, mhkelley58@gmail.com wrote: 4 files changed, 19 insertions(+), 23 deletions(-) Reviewed-by: Nuno Das Neves &lt;nunodasneves@linux.microsoft.com&gt; Reviewed-by: Nuno Das Neves &lt;nunodasneves@linux.microsoft.com&gt; Reviewed-by: Nuno Das Neves &lt;nunodasneves@linux.microsoft.com&gt; </description> </item> <item> <title>Re: [PATCH v2 13/14] x86: runtime_const used for KASAN_SHADOW_END</title> <author>Maciej Wieczor-Retman <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1287</link> <description>Maciej Wieczor-Retman writes: </description> </item> <item> <title>Re: [PATCH v11 6/8] MAINTAINERS: rust: Add new sections for DELAY/ ...</title> <author>Andreas Hindborg <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1286</link> <description>Andreas Hindborg writes: Boqun Feng &lt;boqun.feng@gmail.com&gt; writes: Boqun Feng &lt;boqun.feng@gmail.com&gt; writes: Could you add me as a reviewer in these entries? I would like to be added as well. I would like to be added as well. I would like to be added as well. Best regards, Andreas Hindborg Andreas Hindborg Andreas Hindborg Andreas Hindborg Andreas Hindborg Andreas Hindborg </description> </item> <item> <title>[PATCH net-next 13/13] MIPS: mobileye: eyeq5-epm: add two Cadence ...</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1285</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 11/13] MIPS: mobileye: add EyeQ5 DMA IOCU support</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1284</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>Re: [PATCH v13 2/7] rust: add dma coherent allocator abstraction.</title> <author>Danilo Krummrich <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1283</link> <description>Danilo Krummrich writes: (Summary) On Fri, Mar 21, 2025 at 03:29:01PM -0300, Jason Gunthorpe wrote: that story? Yeah, we can also use them to derive specifically typed Device instances from other entry points of the driver where we know for sure that at this point the device must (still) be bound to the driver. device must (still) be bound to the driver. For instance, bus callbacks, subsystem callbacks, certain (but not all) IOCTLs, IRQ handlers, etc. IRQ handlers, etc. All those cases can be covered by only the type system, without additional locks. </description> </item> <item> <title>[PATCH net-next 08/13] net: macb: introduce DMA descriptor helpers ...</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1282</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 12/13] MIPS: mobileye: eyeq5: add two Cadence GEM ...</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1281</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 03/13] dt-bindings: net: cdns,macb: allow dma-coherent</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1280</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 07/13] net: macb: move HW IP alignment value to ma ...</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1279</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 06/13] net: macb: simplify macb_probe() code touch ...</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1278</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 10/13] net: macb: Add "mobileye,eyeq5-gem" compatible</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1277</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 02/13] dt-bindings: net: cdns,macb: allow tsu_clk ...</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1276</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 09/13] net: macb: sort #includes</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1275</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 05/13] net: macb: add no LSO capability (MACB_CAPS ...</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1274</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 01/13] dt-bindings: net: cdns,macb: add Mobileye E ...</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1273</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 00/13] Support the Cadence MACB/GEM instances on M ...</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1272</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>[PATCH net-next 04/13] net: macb: use BIT() macro for capability d ...</title> <author>Th茅o_Lebrun <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1271</link> <description>Th脙漏o_Lebrun writes: </description> </item> <item> <title>Re: [PATCH v6 01/10] hyperv: Log hypercall status codes as strings</title> <author>Nuno Das Neves <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1270</link> <description>Nuno Das Neves writes: (Summary) However, if it gets used elsewhere it makes more sense if the returned hv_status_info for the "Unknown" case contains the actual status code instead of replacing that information with -2, so then I'd want to return it by value instead of pointer: instead of pointer: +static const struct hv_status_info hv_status_infos[] = { +#define _STATUS_INFO(status, errno) { #status, (status), (errno) } + _STATUS_INFO(HV_STATUS_SUCCESS, 0), &lt;snip&gt; + } + } + + return ret; </description> </item> <item> <title>Re: [PATCH v2 3/4] rust: pci: impl TryFrom<&Device> for &pci::Device</title> <author>Danilo Krummrich <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1269</link> <description>Danilo Krummrich writes: </description> </item> <item> <title>Re: [PATCH v1] ALSA: hda/realtek: Add support for various HP Lapto ...</title> <author>Takashi Iwai <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1268</link> <description>Takashi Iwai writes: On Fri, 21 Mar 2025 18:50:06 +0100, Stefan Binding wrote: Signed-off-by: Stefan Binding &lt;sbinding@opensource.cirrus.com&gt; This seems conflicting with the recent changes. Could you try to rebase to for-linus branch and resubmit? Could you try to rebase to for-linus branch and resubmit? Could you try to rebase to for-linus branch and resubmit? thanks, thanks, Takashi Takashi Takashi </description> </item> <item> <title>Re: [PATCH 6.6 000/166] 6.6.84-rc2 review</title> <author>Hardik Garg <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1267</link> <description>Hardik Garg writes: (Summary) Kernel binary size for x86 build: text data bss dec hex filename 27318662 16715490 4640768 48674920 2e6b868 vmlinux 27318662 16715490 4640768 48674920 2e6b868 vmlinux Kernel binary size for arm64 build: text data bss dec hex filename 34684949 13845466 970368 49500783 2f3526f vmlinux 34684949 13845466 970368 49500783 2f3526f vmlinux 34684949 13845466 970368 49500783 2f3526f vmlinux Tested-by: Hardik Garg &lt;hargar@linux.microsoft.com&gt; </description> </item> <item> <title>Re: [PATCH v2 1/5] iio: adc: ad400: Set transfer bits_per_word to ...</title> <author>Marcelo Schmitt <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1266</link> <description>Marcelo Schmitt writes: (Summary) Hmm, if user space software doesn't check deviceX/scan_elements/in_&lt;channel_type&gt;_type, nor deviceX/bufferY/in_&lt;channel_type&gt;Y_type, then I'd say that's already somewhat broken since at least buffer scan_element type attributes are documented <a href="https://web.git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/Documentation/ABI/testing/sysfs-bus-iio?h=testing#n1470.">https://web.git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/Documentation/ABI/testing/sysfs-bus-iio?h=testing#n1470.</a> <a href="https://web.git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/Documentation/ABI/testing/sysfs-bus-iio?h=testing#n1470.">https://web.git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/Documentation/ABI/testing/sysfs-bus-iio?h=testing#n1470.</a> Anyway, this patch it indeed broke RPi support so I'll revert buffer endianness and SPI transfer bits_per_word configurations the way it was in v1. </description> </item> <item> <title>RE: [PATCH] drm: renesas: Extend RZ/G2L supported KMS formats</title> <author>Kieran Bingham <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1265</link> <description>Kieran Bingham writes: (Summary) Hi Biju, Hi Biju, Quoting Biju Das (2025-03-21 18:40:50) s of the VSPd which prevents ]. s between the supported DRM ntaining the same ordering in by the Planes, but using them nd in rzg2l_du_format_info. 5 direct to an attached DSI SI supports only 3 formats. SI supports only 3 formats. Indeed, I can see that the DSI only supports the three RGB variant formats, but the RPF of the VPSD is very capable and does the pixel format conversion for us here as I understand it! conversion for us here as I understand it! conversion for us here as I understand it! mats. =20 I haven't looked completely, but as long as the VSPD is only configured to /output/ the RGB formats to the DSI then I think this is fine, to /output/ the RGB formats to the DSI then I think this is fine, Biju Thanks, </description> </item> <item> <title>Re: [RFC PATCH v3 00/13] Clavis LSM</title> <author>Paul Moore <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1264</link> <description>Paul Moore writes: (Summary) On Fri, Mar 21, 2025 at 1:22=E2=80=AFPM Jarkko Sakkinen &lt;jarkko@kernel.org&gt;= wrote: On Thu, Mar 20, 2025 at 05:36:41PM -0400, Paul Moore wrote: ... ... no matter which group of villains you might be employed by ;-) Haha :D Haha :D have not really looked into it so far... I haven't looked at it too closely, but the kernel code is very simplistic so I would be surprised if it couldn't be implemented in eBPF, although there might be some issues about *very* early boot (Lockdown can run as an "early" LSM) and integrity which would need to be addressed (there is work ongoing in that are, see the recent Hornet posting as one example of that work). </description> </item> <item> <title>Re: [PATCH v4 08/16] rust: kunit: refactor to use `&raw [const|mut]`</title> <author>Miguel Ojeda <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1263</link> <description>Miguel Ojeda writes: On Fri, Mar 21, 2025 at 6:06=E2=80=AFPM Boqun Feng &lt;boqun.feng@gmail.com&gt; w= rote: code can switch to &amp;raw since that's the direction anyway? Sounds like a good idea to me. Sounds like a good idea to me. Cheers, Miguel Miguel Miguel </description> </item> <item> <title>Re: [RFC] panic: reduce CPU consumption when finished handling panic</title> <author>Thomas Gleixner <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1262</link> <description>Thomas Gleixner writes: (Summary) On Mon, Mar 17 2025 at 17:01, Carlos Bilbao wrote: p. commit below. That's not the way how change logs are written. Your patch is malformed due to white space damage: Your patch is malformed due to white space damage: patch: **** malformed patch at line 31: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 crash_smp_send_stop(); +=C2=A0=C2=A0=C2=A0 /* &gt; +=C2=A0=C2=A0=C2=A0=C2=A0 * Default to a simple busy-wait if no architect= ure-specific halt is &gt; </description> </item> <item> <title>Re: [PATCH v4 08/16] rust: kunit: refactor to use `&raw [const|mut]`</title> <author>Antonio Hickey <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1261</link> <description>Antonio Hickey writes: On Fri, Mar 21, 2025 at 10:06:03AM -0700, Boqun Feng wrote: code can switch to &amp;raw since that's the direction anyway? This would make the most sense to me, it would keep things clippy clean while also allowing new patches to use the feature. This would also potentially help reduce the amount of refactoring my patch series will have to do as it's delayed. have to do as it's delayed. Thanks, Antonio Antonio -- David -- David </description> </item> <item> <title>Re: [PATCH 6.1] efivarfs: Move efivarfs list into superblock s_fs_info</title> <author>Ard Biesheuvel <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1260</link> <description>Ard Biesheuvel writes: On Fri, 21 Mar 2025 at 19:40, Alexey Nepomnyashih &lt;sdl@nppct.ru&gt; wrote: 4 files changed, 28 insertions(+), 15 deletions(-) The original commit has The original commit has fs/efivarfs/inode.c | 3 ++- fs/efivarfs/internal.h | 6 +++--- fs/efivarfs/super.c | 19 ++++++++++--------- fs/efivarfs/vars.c | 5 +++-- 4 files changed, 18 insertions(+), 15 deletions(-) so you will need to explain where those extra 10 lines came from. </description> </item> <item> <title>Re: [PATCH v2 3/4] rust: pci: impl TryFrom<&Device> for &pci::Device</title> <author>Miguel Ojeda <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1259</link> <description>Miguel Ojeda writes: (Summary) = wrote: 82 it a we have to use unsafe and suppress the warning? It was a feature, but it has been fairly annoying -- it affected several series, e.g. the latest KUnit one as well as: <a href="https://lore.kernel.org/rust-for-linux/CANiq72kuebpOa4aPxmTXNMA0eo-SLL+=">https://lore.kernel.org/rust-for-linux/CANiq72kuebpOa4aPxmTXNMA0eo-SLL+=</a> Ht9u1SGHymXBF5_92eA@mail.gmail.com/ Ht9u1SGHymXBF5_92eA@mail.gmail.com/ Please see: Please see: <a href="https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#safely-addressin=">https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#safely-addressin=</a> g-unsafe-statics g-unsafe-statics So, yeah, we use `allow(unused_unsafe)` (no `expect`, since it depends on the version). on the version). I hope that helps. I hope that helps. Cheers, Miguel Miguel Miguel </description> </item> <item> <title>Re: [RFC PATCH v3 00/13] Clavis LSM</title> <author>Paul Moore <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1258</link> <description>Paul Moore writes: (Summary) wrote: wrote: wrote: out the UEFI SB people. <a href="https://lkml.org/lkml/2023/5/26/1057">https://lkml.org/lkml/2023/5/26/1057</a> Those patches proposed loosening Lockdown restrictions, which is particularly concerning given the intent behind Lockdown, and considering the author did not have any existing patches under security/ (they still do not, I just checked) there was room for concern. If your first introduction to your neighbour includes proposing the removal of the locks on their front door, you have to understand that they might not consider this a valuable contribution and might bristle at the idea of handing over responsibility of their home's security to you. home's security to you. You are welcome to continue to criticize me and my handling of things, that's the popular thing to do these days when you disagree with a maintainer, but I will note that I don't recall you offering to step up a</description> </item> <item> <title>Re: [PATCH v1 5/6] i2c: core: Do not dereference fwnode in struct ...</title> <author>Andy Shevchenko <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1257</link> <description>Andy Shevchenko writes: On Wed, Mar 12, 2025 at 08:48:52PM +0200, Andy Shevchenko wrote: Instead, use the specific device_set_node() API for that. drivers/i2c/i2c-core-base.c | 18 ++++++++++-------- This missed i2c-core-of.c changes. This missed i2c-core-of.c changes. </description> </item> <item> <title>Re: [PATCH v3 2/2] platform/x86: asus-wmi: Refactor Ally suspend/r ...</title> <author>Antheas Kapenekakis <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1256</link> <description>Antheas Kapenekakis writes: (Summary) + if (err) { &gt; + } &gt; + } &gt; - if (asus-&gt;ally_mcu_usb_switch) { &gt; - } &gt; - if (asus-&gt;ally_mcu_usb_switch) { &gt; - } &gt; + if (use_ally_mcu_hack) { &gt; + if (use_ally_mcu_hack) { For some reason on my device, even though I go through the compatibility check with a custom log &gt; </description> </item> <item> <title>[PATCH 2/2] wifi: plfxlc: Fix error handling in usb driver probe</title> <author>Murad Masimov <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1255</link> <description>Murad Masimov writes: (Summary) 29 +++++++++++----------- 3 files changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/net/wireless/purelifi/plfxlc/mac.c b/drivers/net/wireless/purelifi/plfxlc/mac.c index 82d1bf7edba2..a7f5d287e369 100644 --- a/drivers/net/wireless/purelifi/plfxlc/mac.c +++ b/drivers/net/wireless/purelifi/plfxlc/mac.c @@ -99,11 +99,6 @@ int plfxlc_mac_init_hw(struct ieee80211_hw *hw) return r; } if ((le16_to_cpu(interface_to_usbdev(intf)-&gt;descriptor.idVendor) == @@ -630,7 +630,7 @@ static int probe(struct usb_interface *intf, } if (r != 0) { dev_err(&amp;intf-&gt;dev, "FPGA download failed (%d)\n", r); </description> </item> <item> <title>Re: [PATCH v1 2/6] i2c: core: Unify the firmware node type check</title> <author>Andy Shevchenko <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1254</link> <description>Andy Shevchenko writes: On Wed, Mar 12, 2025 at 08:48:49PM +0200, Andy Shevchenko wrote: against struct fwnode_handle pointer. drivers/i2c/i2c-core-base.c | 14 ++++++++------ The i2c-core-slave.c can be also modified to follow the same approach. I'll do that way in v2. I'll do that way in v2. </description> </item> <item> <title>Re: [RFC PATCH 0/3] gpu: nova-core: add basic timer subdevice impl ...</title> <author>Danilo Krummrich <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1253</link> <description>Danilo Krummrich writes: (Summary) device resources associated with a DMA coherent allocation should hence never &gt; revocable for rust ideological reasons and in the end the proposal is &gt; It won't achieve anything and does not come across very professional.) &gt; // However, it is neither desirable nor necessary to protect the allocated memory of the DMA &gt; device, there are two kinds of per-device coherent memory allocators &gt; It looks like there are cases where the actual memory must not outlive &gt; So, I'd argue that it is necessary, and changing that on the C side &gt; </description> </item> <item> <title>Re: [PATCH] tracing: Disable branch profiling in noinstr code</title> <author>Josh Poimboeuf <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1252</link> <description>Josh Poimboeuf writes: (Summary) On Fri, Mar 21, 2025 at 02:28:26PM -0400, Steven Rostedt wrote: directory and all its siblings without modifying all the Makefiles? This appears to work: This appears to work: diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild index cf0ad89f5639..ff8f0e2fbf4b 100644 --- a/arch/x86/Kbuild +++ b/arch/x86/Kbuild @@ -1,4 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 + +subdir-ccflags-$(CONFIG_TRACE_BRANCH_PROFILING) += -DDISABLE_BRANCH_PROFILING + obj-$(CONFIG_ARCH_HAS_CC_PLATFORM) += coco/ obj-y += entry/ </description> </item> <item> <title>[PATCH] drm/msm/adreno: Drop fictional address_space_size</title> <author>Rob Clark <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1251</link> <description>Rob Clark writes: (Summary) + ADRENO_QUIRK_4GB_VA, .inactive_period = DRM_MSM_INACTIVE_PERIOD, - .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT, .init = a6xx_gpu_init, .zapfw = "a640_zap.mdt", .a6xx = &amp;(const struct a6xx_info) { @@ -973,7 +980,6 @@ static const struct adreno_info a6xx_gpus[] = { .gmu_cgc_mode = 0x00020202, .prim_fifo_threshold = 0x00300200, }, - .address_space_size = SZ_16G, .speedbins = ADRENO_SPEEDBINS( { 0, 0 }, { 1, 1 }, @@ -1000,7 +1006,6 @@ static const struct adreno_info a6xx_gpus[] = { .gmu_cgc_mode = 0x00020000, .prim_fifo_threshold = 0x00300200, }, - .address_space_size = SZ_16G, }, { .chip_ids = ADRENO_CHIP_IDS(0x06060300), .family = ADRENO_6XX_GEN4, @@ -1019,7 +1024,6 @@ static const struct adreno_info a6xx_gpus[] = { .gmu_cgc_mode = 0x00020200, .prim_fifo_threshold = 0x00300200, }, - .address_space_size = SZ_16G, }, { .chip_ids = ADRENO_CHIP_IDS(0x06030500), .family = ADRENO_6XX_GEN4, @@ -1039,7 +1043,6 @@ static const struct a</description> </item> <item> <title>[PATCH 1/2] wifi: plfxlc: Remove erroneous assert in plfxlc_mac_re ...</title> <author>Murad Masimov <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1250</link> <description>Murad Masimov writes: (Summary) There is also no need to hold mac-&gt;lock for plfxlc_mac_release() itself, as mac data is not affected, except for mac-&gt;flags, which is modified atomically. mac-&gt;flags, which is modified atomically. This bug leads to the following warning: ================================================================ WARNING: CPU: 0 PID: 127 at drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0 Modules linked in: CPU: 0 PID: 127 Comm: kworker/0:2 Not tainted 6.1.124-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: usb_hub_wq hub_event RIP: 0010:plfxlc_mac_release+0x7d/0xa0 drivers/net/wireless/purelifi/plfxlc/mac.c:106 Call Trace: &lt;TASK&gt; 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/purelifi/plfxlc/mac.c b/drivers/net/wireless/purelifi/plfxlc/mac.c index eae93efa6150..82d1bf7edba2 100644 --- a/drivers/net/wireless/purelifi/plfxlc/mac.c +++ b/drivers/net/wireless/purelifi/plfxl</description> </item> <item> <title>[PATCH 0/2] wifi: plfxlc: Fix usb device interface deinitialization</title> <author>Murad Masimov <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1249</link> <description>Murad Masimov writes: (Summary) These patches fix issues during the process of deinitialization that is done when a device is disconnected or when probe fails. done when a device is disconnected or when probe fails. Murad Masimov (2): wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release wifi: plfxlc: Fix error handling in usb driver probe wifi: plfxlc: Fix error handling in usb driver probe drivers/net/wireless/purelifi/plfxlc/mac.c | 29 +++++++++++----------- 3 files changed, 21 insertions(+), 22 deletions(-) -- 2.39.2 </description> </item> <item> <title>Re: [PATCH v5 3/4] rust: add bitmap API.</title> <author>Miguel Ojeda <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1248</link> <description>Miguel Ojeda writes: (Summary) w= rote: guys really use 2-whitespace tabs? Please see <a href="https://docs.kernel.org/rust/coding-guidelines.html.">https://docs.kernel.org/rust/coding-guidelines.html.</a> Please see <a href="https://docs.kernel.org/rust/coding-guidelines.html.">https://docs.kernel.org/rust/coding-guidelines.html.</a> You are right that the example block you quoted should have the formatting fixed. formatting fixed. I am not sure what you mean by separating declarations from body here. It is how we document everything else in Rust, and in fact we are becoming stricter in requesting more examples when people add more APIs (otherwise they never get added :) APIs (otherwise they never get added :) If actual tests are needed (i.e. </description> </item> <item> <title>[PATCH 2/3] io_uring/net: import send_zc fixed buffer before going ...</title> <author>Caleb Sander Mateos <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1247</link> <description>Caleb Sander Mateos writes: (Summary) If the IORING_OP_SEND_ZC operation is followed immediately by a UBLK_U_IO_UNREGISTER_IO_BUF that unregisters the fixed buffer, IORING_RECVSEND_POLL_FIRST will cause the fixed buffer lookup to fail because it happens after the buffer is unregistered. 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/io_uring/net.c b/io_uring/net.c index a29893d567b8..5adc7b80138e 100644 --- a/io_uring/net.c +++ b/io_uring/net.c @@ -1367,21 +1367,21 @@ int io_send_zc(struct io_kiocb *req, unsigned int issue_flags) if (unlikely(!sock)) return -ENOTSOCK; </description> </item> <item> <title>[PATCH 1/3] io_uring/net: only import send_zc buffer once</title> <author>Caleb Sander Mateos <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1246</link> <description>Caleb Sander Mateos writes: (Summary) 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/io_uring/net.c b/io_uring/net.c index 6d13d378358b..a29893d567b8 100644 --- a/io_uring/net.c +++ b/io_uring/net.c @@ -74,10 +74,11 @@ struct io_sr_msg { unsigned nr_multishot_loops; @@ -1222,10 +1223,11 @@ int io_send_zc_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe) struct io_ring_ctx *ctx = req-&gt;ctx; /* we don't support IOSQE_CQE_SKIP_SUCCESS just yet */ @@ -1369,11 +1371,12 @@ int io_send_zc(struct io_kiocb *req, unsigned int issue_flags) if (!(req-&gt;flags &amp; - if (!zc-&gt;done_io) { + if (!zc-&gt;imported) { + zc-&gt;imported = true; </description> </item> <item> <title>[PATCH 3/3] io_uring/uring_cmd: import fixed buffer before going async</title> <author>Caleb Sander Mateos <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1245</link> <description>Caleb Sander Mateos writes: (Summary) } /* to free bio on completion, as req-&gt;bio will be null at that time */ diff --git a/include/linux/io_uring/cmd.h b/include/linux/io_uring/cmd.h index 598cacda4aa3..ea243bfab2a8 100644 --- a/include/linux/io_uring/cmd.h +++ b/include/linux/io_uring/cmd.h @@ -39,12 +39,11 @@ static inline void io_uring_cmd_private_sz_check(size_t cmd_sz) ) #if defined(CONFIG_IO_URING) int io_uring_cmd_import_fixed(u64 ubuf, unsigned long len, int rw, struct iov_iter *iter, - struct io_uring_cmd *ioucmd, - unsigned int issue_flags); </description> </item> <item> <title>[PATCH 0/3] Consistently look up fixed buffers before going async</title> <author>Caleb Sander Mateos <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1244</link> <description>Caleb Sander Mateos writes: (Summary) To use ublk zero copy, an application submits a sequence of io_uring operations: (1) Register a ublk request's buffer into the fixed buffer table (2) Use the fixed buffer in some I/O operation (3) Unregister the buffer from the fixed buffer table (3) Unregister the buffer from the fixed buffer table The ordering of these operations is critical; But it requires the fixed buffer lookup to occur during the initial non-blocking issue. initial non-blocking issue. This patch series fixes the 2 gaps where the initial issue can return EAGAIN before looking up the fixed buffer: - IORING_OP_SEND_ZC using IORING_RECVSEND_POLL_FIRST - IORING_OP_URING_CMD, of which NVMe passthru is currently the only fixed buffer user. </description> </item> <item> <title>Re: [PATCH 0/5] Provide SEV-ES/SEV-SNP support for decrypting the VMSA</title> <author>Kim Phillips <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1243</link> <description>Kim Phillips writes: (Summary) Thanks, Thanks, Kim Kim kvm_amd: SEV-SNP vCPU1 VMCB 00000000759a48a5, last attempted VMRUN on CPU 7 kvm_amd: VMCB Control Area: kvm_amd: cr_read: 0000 kvm_amd: cr_write: 0000 kvm_amd: dr_read: 0080 kvm_amd: dr_write: 0080 kvm_amd: exceptions: 00060002 kvm_amd: intercepts: bccc8007 0111ce43 kvm_amd: pause filter count: 3000 kvm_amd: pause filter threshold:128 kvm_amd: iopm_base_pa: 0000000148e44000 kvm_amd: msrpm_base_pa: 0000000276e3e000 kvm_amd: tsc_offset: ffff6b01ea8aa6f6 kvm_amd: asid: 3 kvm_amd: tlb_ctl: 0 kvm_amd: int_ctl: 07000200 kvm_amd: int_vector: 00000000 kvm_amd: int_state: 00000000 kvm_amd: exit_code: ffffffff kvm_amd: exit_info1: 0000000000000000 kvm_amd: exit_info2: 0000000000000000 kvm_amd: exit_int_info: 00000000 kvm_amd: exit_int_info_err: 00000000 kvm_amd: nested_ctl: 7 kvm_amd: nested_cr3: </description> </item> <item> <title>[PATCH v3] perf trace: Implement syscall summary in BPF</title> <author>Namhyung Kim <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1242</link> <description>Namhyung Kim writes: (Summary) + } + } + + /* update total stats for this syscall */ + data-&gt;nr_events += map_data-&gt;count; */ +#ifndef UTIL_BPF_SKEL_SYSCALL_SUMMARY_H +#define UTIL_BPF_SKEL_SYSCALL_SUMMARY_H + +enum syscall_aggr_mode { + SYSCALL_AGGR_THREAD, + SYSCALL_AGGR_CPU, +}; /* for FILE */ + +enum trace_summary_mode { + SUMMARY__NONE = 0, + SUMMARY__BY_TOTAL, + SUMMARY__BY_THREAD, +}; </description> </item> <item> <title>Re: [PATCH] net: dl2k: fix potential null deref in receive_packet()</title> <author>Qasim Ijaz <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1241</link> <description>Qasim Ijaz writes: </description> </item> <item> <title>Re: Using Restricted DMA for virtio-pci</title> <author>David Woodhouse <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1240</link> <description>David Woodhouse writes: (Summary) The question is *what* does the DMA API do? the DMA API do? For a real passthrough PCI device, perhaps we'd have a vIOMMU exposed to the guest so that it can do real protection with two-stage page tables (IOVA&#8594;GPA under control of the guest, GPA&#8594;HPA under control of the hypervisor). For that to work in the pKVM model though, you'd need pKVM to be talking the guest's stage1 I/O page tables to see if a given access from the VMM ought to be permitted? access from the VMM ought to be permitted? Or for confidential guests there could be DMA ops which are an 'enlightenment'; </description> </item> <item> <title>RE: [PATCH] drm: renesas: Extend RZ/G2L supported KMS formats</title> <author>Biju Das <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1239</link> <description>Biju Das writes: (Summary) + .planes =3D 1, &gt; + .hsub =3D 1, &gt; + .planes =3D 1, &gt; + .hsub =3D 1, &gt; + .planes =3D 1, &gt; + .hsub =3D 1, &gt; + .planes =3D 1, &gt; + .planes =3D 1, &gt; + .planes =3D 1, &gt; + .planes =3D 1, &gt; + .planes =3D 1, &gt; + .planes =3D 1, &gt; + .planes =3D 1, &gt; + .planes =3D 1, &gt; + .planes =3D 1, &gt; </description> </item> <item> <title>[PATCH 6.1] efivarfs: Move efivarfs list into superblock s_fs_info</title> <author>Alexey Nepomnyashih <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1238</link> <description>Alexey Nepomnyashih writes: (Summary) 5 +++-- 4 files changed, 28 insertions(+), 15 deletions(-) diff --git a/fs/efivarfs/inode.c b/fs/efivarfs/inode.c index b3dc7ff42400..a999351e6615 100644 --- a/fs/efivarfs/inode.c +++ b/fs/efivarfs/inode.c @@ -73,6 +73,7 @@ static bool efivarfs_valid_name(const char *str, int len) static int efivarfs_create(struct user_namespace *mnt_userns, struct inode *dir, struct dentry *dentry, umode_t mode, bool excl) { + struct efivarfs_fs_info *info = dir-&gt;i_sb-&gt;s_fs_info; @@ -102,7 +100,8 @@ static struct dentry *efivarfs_alloc_dentry(struct dentry *parent, char *name) } static int efivarfs_callback(efi_char16_t *name16, efi_guid_t vendor, - unsigned long name_size, void *data) + unsigned long name_size, void *data, + struct list_head *list) { struct super_block *sb = (struct super_block *)data; </description> </item> <item> <title>[PATCH v1 1/2] Input: wdt87xx_i2c - tidy up ACPI ID table</title> <author>Andy Shevchenko <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1237</link> <description>Andy Shevchenko writes: (Summary) -#ifdef CONFIG_ACPI static const struct acpi_device_id wdt87xx_acpi_id[] = { - { "WDHT0001", 0 }, + { "WDHT0001" }, { } }; -#endif static struct i2c_driver wdt87xx_driver = { .probe = wdt87xx_ts_probe, @@ -1168,7 +1173,7 @@ static struct i2c_driver wdt87xx_driver = { .name = WDT87XX_NAME, .dev_groups = wdt87xx_groups, .pm = pm_sleep_ptr(&amp;wdt87xx_pm_ops), - .acpi_match_table = ACPI_PTR(wdt87xx_acpi_id), + .acpi_match_table = wdt87xx_acpi_id, }, }; </description> </item> <item> <title>[PATCH v1 2/2] Input: wdt87xx_i2c - switch to use dev_err_probe()</title> <author>Andy Shevchenko <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1236</link> <description>Andy Shevchenko writes: (Summary) 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/drivers/input/touchscreen/wdt87xx_i2c.c b/drivers/input/touchscreen/wdt87xx_i2c.c index 99636d6eb0f3..3e7fbc4d7549 100644 --- a/drivers/input/touchscreen/wdt87xx_i2c.c +++ b/drivers/input/touchscreen/wdt87xx_i2c.c @@ -1033,10 +1033,8 @@ static int wdt87xx_ts_create_input_device(struct wdt87xx_data *wdt) int error; - if (error) { - dev_err(dev, "failed to register input device: %d\n", error); - } + if (error) + return dev_err_probe(dev, error, "failed to register input device\n"); - if (error) { - dev_err(&amp;client-&gt;dev, "request irq failed: %d\n", error); </description> </item> <item> <title>[PATCH v1 0/2] Input: wdt87xx_i2c - a couple of cleanups</title> <author>Andy Shevchenko <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1235</link> <description>Andy Shevchenko writes: A couple of cleanups related to ACPI ID table and probe function. A couple of cleanups related to ACPI ID table and probe function. Andy Shevchenko (2): Input: wdt87xx_i2c - tidy up ACPI ID table Input: wdt87xx_i2c - switch to use dev_err_probe() Input: wdt87xx_i2c - switch to use dev_err_probe() drivers/input/touchscreen/wdt87xx_i2c.c | 40 ++++++++++++------------- 1 file changed, 20 insertions(+), 20 deletions(-) -- 2.47.2 </description> </item> <item> <title>Re: [PATCH v2 1/2] include/uapi/linux/swab.h: move default impleme ...</title> <author>Ignacio Encinas Rubio <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1234</link> <description>Ignacio Encinas Rubio writes: (Summary) What do you think, should we keep patch 1 after all? should we keep patch 1 after all? We could remove __arch_swab for architectures that always assume bit manipulation instructions availability, but then the kernel would fall back into ___constant_swab when CONFIG_ARCH_USE_BUILTIN_BSWAP=n. Thanks! Thanks! [1] <a href="https://lore.kernel.org/all/ce034f2b-2f6e-403a-81f1-680af4c72929@ghiti.fr/">https://lore.kernel.org/all/ce034f2b-2f6e-403a-81f1-680af4c72929@ghiti.fr/</a> [2] <a href="https://lore.kernel.org/all/20250319-riscv-swab-v2-2-d53b6d6ab915@iencinas.com/">https://lore.kernel.org/all/20250319-riscv-swab-v2-2-d53b6d6ab915@iencinas.com/</a> [3] <a href="https://gcc.gnu.org/onlinedocs/gcc-13.3.0/gccint.pdf">https://gcc.gnu.org/onlinedocs/gcc-13.3.0/gccint.pdf</a> [4] <a href="https://lore.kernel.org/all/20230512164815.2150839-1-jcmvbkbc@gmail.com/">https://lore.kernel.org/all/20230512164815.2150839-1-jcmvbkbc@gmail.com/</a> [5] <a href="https://lore.kernel.org/all/1664437198-31260-3</description> </item> <item> <title>[tip: timers/core] timekeeping: Fix possible inconsistencies in _C ...</title> <author>"tip-bot2 for John Stultz" <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1233</link> <description>&quot;tip-bot2 for John Stultz&quot; writes: (Summary) 94 +++++++++++++++++++++++++++----------- 1 file changed, 69 insertions(+), 25 deletions(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 1e67d07..929846b 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -682,20 +682,19 @@ static void timekeeping_update_from_shadow(struct tk_data *tkd, unsigned int act } /** - * timekeeping_forward_now - update clock to the current time + * timekeeping_forward - update clock to given cycle now value * @tk: Pointer to the timekeeper to update + * @cycle_now: Current clocksource read value * * Forward the current clock to update its state since the last call to * update_wall_time(). </description> </item> <item> <title>[tip: timers/core] selftests/timers: Improve skew_consistency by t ...</title> <author>"tip-bot2 for John Stultz" <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1232</link> <description>&quot;tip-bot2 for John Stultz&quot; writes: (Summary) CommitterDate: Fri, 21 Mar 2025 19:16:18 +01:00 CommitterDate: Fri, 21 Mar 2025 19:16:18 +01:00 selftests/timers: Improve skew_consistency by testing with other clockids selftests/timers: Improve skew_consistency by testing with other clockids Lei Chen reported a bug with CLOCK_MONOTONIC_COARSE having inconsistencies when NTP is adjusting the clock frequency. when NTP is adjusting the clock frequency. This has gone seemingly undetected for ~15 years, illustrating a clear gap in our testing. in our testing. The skew_consistency test is intended to catch this sort of problem, but was focused on only evaluating CLOCK_MONOTONIC, and thus missed the problem on CLOCK_MONOTONIC_COARSE. on CLOCK_MONOTONIC_COARSE. So adjust the test to run with all clockids for 60 seconds each instead of 10 minutes with just CLOCK_MONOTONIC. 10 minutes with just CLOCK_MONOTONIC. Reported-by: Lei Chen &lt;lei.chen@smartx.com&gt; Signed-off-by: John Stultz &lt;jstultz@google.com&gt</description> </item> <item> <title>Re: distro support for CONFIG_KUNIT: [PATCH 0/3] bitmap: convert s ...</title> <author>Yury Norov <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1231</link> <description>Yury Norov writes: (Summary) David sent a lengthy email that doesn't address them, either. address them, either. None of you guys submitted anything to bitmaps - neither in library, nor in tests. I always encourage people to increase testing coverage. encourage people to increase testing coverage. If you'd like to add new cases to existing tests - I'll be happy. If you'd like to add completely new tests based on KUNITs or whatever else - I'll be happy just as well. else - I'll be happy just as well. Thanks, Yury Yury Yury </description> </item> <item> <title>Re: Using Restricted DMA for virtio-pci</title> <author>"Michael S. Tsirkin" <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1230</link> <description>&quot;Michael S. Tsirkin&quot; writes: (Summary) On Fri, Mar 21, 2025 at 03:38:10PM +0000, David Woodhouse wrote: &gt; systems without an IOMMU, which could result in the DMA accessing the &gt; Virtio already has a complicated relationship with the DMA API, because &gt; there were a bunch of early VMM bugs where the virtio devices where &gt; emulating the virtio device) not being *allowed* to arbitrarily access &gt; Either a virtual IOMMU needs to determine which guest memory the VMM &gt; reasonable way to allow an untrusted VMM to provide virtio devices with &gt; </description> </item> <item> <title>Re: [RESEND PATCH 0/7] perf vendor events riscv: Update SiFive CPU ...</title> <author>Atish Patra <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1229</link> <description>Atish Patra writes: (Summary) I did not find anything in the perf list or the json file. I am not sure if I missed something. I am not sure if I missed something. ++ -- /cycle-and-instruction-count.json /firmware.json /instruction.json /memory.json /microarch.json /watchpoint.json /cycle-and-instruction-count.json /firmware.json /instruction.json /memory.json /microarch.json /watchpoint.json mware.json (100%) struction.json mory.json croarch.json ware.json ruction.json ry.json oarch.json e-and-instruction-count.json ware.json ruction.json ry.json oarc</description> </item> <item> <title>Re: [PATCH 0/2] perf vendor events arm64: AmpereOne/AmpereOneX: Ad ...</title> <author>Namhyung Kim <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1228</link> <description>Namhyung Kim writes: On Thu, 13 Mar 2025 20:15:57 +0000, Ilkka Koskinen wrote: &gt; Add an errata reference to a impacted event and fix metrics calculation &gt; caused by a scaling issue. &gt; &gt; Ilkka Koskinen (2): &gt; perf vendor events arm64: AmpereOne/AmpereOneX: Mark LD_RETIRED &gt; impacted by errata &gt; perf vendor events arm64 AmpereOneX: Fix frontend_bound calculation &gt; &gt; [...] Applied to perf-tools-next, thanks! Best regards, Namhyung </description> </item> <item> <title>Re: [PATCH v7 00/14] perf: Support multiple system call tables in ...</title> <author>Namhyung Kim <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1227</link> <description>Namhyung Kim writes: On Tue, 18 Mar 2025 22:07:27 -0700, Ian Rogers wrote: Applied to perf-tools-next, thanks! Applied to perf-tools-next, thanks! Best regards, Namhyung Namhyung Namhyung Namhyung Namhyung </description> </item> <item> <title>Re: [PATCH 1/3] perf sort: Keep output fields in the same level</title> <author>Namhyung Kim <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1226</link> <description>Namhyung Kim writes: On Fri, 07 Mar 2025 00:08:27 -0800, Namhyung Kim wrote: Applied to perf-tools-next, thanks! Applied to perf-tools-next, thanks! Best regards, Namhyung Namhyung Namhyung Namhyung Namhyung </description> </item> <item> <title>Re: [PATCH v13 2/7] rust: add dma coherent allocator abstraction.</title> <author>Jason Gunthorpe <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1225</link> <description>Jason Gunthorpe writes: (Summary) On Fri, Mar 21, 2025 at 06:34:53PM +0100, Danilo Krummrich wrote: If just landed patches [1], which are the foundation of addressing this issue. Those patches say: Those patches say: The context types can be extended as required, e.g. to limit availability of certain (bus) device functions to probe(). certain (bus) device functions to probe(). Which is not an appropriate limitation for dma_alloc_coherent, we expect it to be called outside probe in real drivers. </description> </item> <item> <title>Re: [PATCH] tracing: Disable branch profiling in noinstr code</title> <author>Steven Rostedt <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1224</link> <description>Steven Rostedt writes: (Summary) On Fri, 21 Mar 2025 10:21:34 -0700 Josh Poimboeuf &lt;jpoimboe@kernel.org&gt; wrote: Josh Poimboeuf &lt;jpoimboe@kernel.org&gt; wrote: arch/x86 level. Ah, I thought there was a way to do it recursively, but I don't see a way to do that. way to do that. Masahiro, do you know of a way that we can add a CFLAGS option to a directory and all its siblings without modifying all the Makefiles? directory and all its siblings without modifying all the Makefiles? -- Steve -- Steve -- Steve </description> </item> <item> <title>[PATCH 6.1] ALSA: control: Avoid WARN() for symlink errors</title> <author>Alexey Nepomnyashih <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1223</link> <description>Alexey Nepomnyashih writes: (Summary) + if (sysfs_create_link(&amp;card-&gt;ctl_dev.kobj, &amp;led_card-&gt;dev.kobj, + link_name)) + dev_err(card-&gt;dev, + "%s: can't create symlink to controlC%i device\n", + __func__, card-&gt;number); + if (sysfs_create_link(&amp;led_card-&gt;dev.kobj, &amp;card-&gt;card_dev.kobj, + "card")) + dev_err(card-&gt;dev, + "%s: can't create symlink to card%i\n", + __func__, card-&gt;number); </description> </item> <item> <title>Re: [PATCH net-next v2 0/4] virtio_net: Fixes and improvements</title> <author>"Michael S. Tsirkin" <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1222</link> <description>&quot;Michael S. Tsirkin&quot; writes: On Fri, Mar 21, 2025 at 03:48:31PM +0900, Akihiko Odaki wrote: Signed-off-by: Akihiko Odaki &lt;akihiko.odaki@daynix.com&gt; Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt; Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt; Akihiko Odaki &lt;akihiko.odaki@daynix.com&gt; Akihiko Odaki &lt;akihiko.odaki@daynix.com&gt; Akihiko Odaki &lt;akihiko.odaki@daynix.com&gt; </description> </item> <item> <title>[GIT PULL] First batch of KVM changes for Linux 6.15</title> <author>Paolo Bonzini <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1221</link> <description>Paolo Bonzini writes: </description> </item> <item> <title>Re: [PATCH next] Drivers: hv: mshv: Prevent potential NULL dereference</title> <author>Wei Liu <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1220</link> <description>Wei Liu writes: On Fri, Mar 21, 2025 at 09:53:45AM -0700, Nuno Das Neves wrote: Wei could you please apply or squash this into the driver patch? Thank you Dan. I squashed this fix to the original patch. Thank you Dan. I squashed this fix to the original patch. Thank you Dan. I squashed this fix to the original patch. </description> </item> <item> <title>Re: [PATCH v14 02/11] rust: add dma coherent allocator abstraction.</title> <author>Jason Gunthorpe <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1219</link> <description>Jason Gunthorpe writes: (Summary) Let's compare against SMMUv3's use for the CD table.. against SMMUv3's use for the CD table.. This would be the code in arm_smmu_alloc_cd_ptr() This would be the code in arm_smmu_alloc_cd_ptr() It is making a 2 level radix tree. It is making a 2 level radix tree. The cpu_addr is stored in a linear array of pointers: The cpu_addr is stored in a linear array of pointers: struct arm_smmu_cdtab_l2 **l2ptrs; struct arm_smmu_cdtab_l2 **l2ptrs; The dma_addr is encoded into the HW data structure itself: The dma_addr is encoded into the HW data structure itself: arm_smmu_write_cd_l1_desc(&amp;cd_table-&gt;l2.l1tab[idx], l2ptr_dma); l2ptr_dma); The size of the allocation is fixed size: *l2ptr = dma_alloc_coherent(smmu-&gt;dev, sizeof(**l2ptr), ^^^^^^^^^^^^ &amp;l2ptr_dma, GFP_KERNEL); </description> </item> <item> <title>[PATCH 5.10 2/2] efivarfs: Add efivars_lock to synchronize list op ...</title> <author>Alexey Nepomnyashih <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1218</link> <description>Alexey Nepomnyashih writes: (Summary) 4 ++++ 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c index 010febd2ab6b..517bf886ba14 100644 --- a/drivers/firmware/efi/vars.c +++ b/drivers/firmware/efi/vars.c @@ -417,6 +417,7 @@ int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *), const struct efivar_operations *ops; switch (status) { case EFI_SUCCESS: - if (duplicates) + if (duplicates) { + var_present = variable_is_present(variable_name, + &amp;vendor_guid, + head); </description> </item> <item> <title>[PATCH v1 5/7] serial: 8250_ni: use serial_port_in()/serial_port_o ...</title> <author>Andy Shevchenko <invalid@email.com></author> <link>http://lkml.org/lkml/2025/3/21/1217</link> <description>Andy Shevchenko writes: (Summary) 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/tty/serial/8250/8250_ni.c b/drivers/tty/serial/8250/8250_ni.c index 8bb8bb7bb4f2..15bee1b7dc2a 100644 --- a/drivers/tty/serial/8250/8250_ni.c +++ b/drivers/tty/serial/8250/8250_ni.c @@ -90,10 +90,10 @@ static int ni16550_disable_transceivers(struct uart_port *port) { u8 pcr; @@ -120,7 +120,7 @@ static int ni16550_rs485_config(struct uart_port *port, } dev_dbg(port-&gt;dev, "config rs485: write pcr: 0x%02x, acr: %02x\n", pcr, up-&gt;acr); </description> </item> </channel> </rss>

CINXE.COM

lkml.org