* Re: [PATCH v18 net-next 00/11] nbl driver for Nebulamatrix NICs
From: Jakub Kicinski @ 2026-06-15 21:54 UTC (permalink / raw)
To: illusion.wang
Cc: dimon.zhao, alvin.wang, sam.chen, netdev, andrew+netdev, corbet,
horms, linux-doc, pabeni, vadim.fedorenko, lukas.bulwahn,
edumazet, enelsonmoore, skhan, hkallweit1, open list
In-Reply-To: <20260611044916.2383-1-illusion.wang@nebula-matrix.com>
On Thu, 11 Jun 2026 12:48:59 +0800 illusion.wang wrote:
> This patch series represents the first phase. We plan to integrate it in
> two phases: the first phase covers mailbox and chip configuration,
> while the second phase involves net dev configuration.
> Together, they will provide basic PF-based Ethernet port transmission and
> reception capabilities.
7.1 has been tagged and the merge window for 7.2 has started.
It's a bit late to be adding drivers, so please repost this
after 7.2-rc1 has been tagged and net-next re-opened:
https://netdev.bots.linux.dev/net-next.html
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v5 05/15] net: ethernet: oa_tc6: Move constant definitions to header file
From: Jakub Kicinski @ 2026-06-15 20:55 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay
Cc: Selvamani.Rajagopal, Andrew Lunn, Piergiorgio Beruto,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Paolo Abeni, Andrew Lunn, Parthiban Veerasooran, Richard Cochran,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Simon Horman,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, devicetree,
linux-doc, Jerry Ray
In-Reply-To: <20260614-s2500-mac-phy-support-v5-5-89874b72f725@onsemi.com>
On Sun, 14 Jun 2026 10:00:21 -0700 Selvamani Rajagopal via B4 Relay
wrote:
> To help other source files within the module share the
> constant definitions, they are moved to a header file.
>
> The memory map selector(MMS) values that are defined in
> in Table 6 of OPEN Alliance 10BASE-T1x Serial Interface
> specification and currently used are added.
If you're adding kdoc on functions the return value must be documented
(unless it's void of course):
Warning: drivers/net/ethernet/oa_tc6/oa_tc6_ptp.c:34 No description found for return value of 'oa_tc6_ptp_register'
Warning: drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c:143 function parameter 'stats' not described in 'oa_tc6_get_ts_stats'
Warning: drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c:185 No description found for return value of 'oa_tc6_get_ts_info'
Please note that net-next is closed during the merge window, please
wait with the repost per: https://netdev.bots.linux.dev/net-next.html
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 3/3] usb: gadget: f_fs: Introduce rw_proxy file descriptors
From: Neill Kapron @ 2026-06-15 20:35 UTC (permalink / raw)
To: Greg KH; +Cc: corbet, skhan, linux-usb, linux-doc, linux-kernel, kernel-team
In-Reply-To: <2026061503-ripening-jokingly-eb4e@gregkh>
On Mon, Jun 15, 2026 at 04:35:39AM +0200, Greg KH wrote:
> On Sun, Jun 14, 2026 at 06:10:02PM +0000, Neill Kapron wrote:
> > diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
> > index 4c1bafb3eef5..0ccfdcfb1810 100644
> > --- a/drivers/usb/gadget/function/f_fs.c
> > +++ b/drivers/usb/gadget/function/f_fs.c
> > @@ -159,7 +159,9 @@ struct ffs_epfile {
> > struct mutex mutex;
> >
> > struct ffs_data *ffs;
> > - struct ffs_ep *ep; /* P: ffs->eps_lock */
> > + struct ffs_ep *ep; /* P: ffs->eps_lock */
> > + struct ffs_epfile *epfile_in; /* P: ffs->eps_lock */
> > + struct ffs_epfile *epfile_out; /* P: ffs->eps_lock */
> >
> > /*
> > * Buffer for holding data from partial reads which may happen since
> > @@ -219,17 +221,20 @@ struct ffs_epfile {
> > struct ffs_buffer *read_buffer;
> > #define READ_BUFFER_DROP ((struct ffs_buffer *)ERR_PTR(-ESHUTDOWN))
> >
> > - char name[5];
> > + char name[10];
>
> Why change the size? Shouldn't that be a separate patch?
The size change is to handle the new proxy file, in the format of
'epXX_rw' (with a null terminator). The size of 10 is a remnant of an
earlier version of this patch which had a slightly different naming
scheme. I will update v2 with name[8] to which will properly reflect the
necessary size required.
> > atomic_t seqno;
> > +
> > + int opened_count; /* P: ffs->eps_lock */
>
> Attempting to track "is this file open or not" almost always fails
> horribly. Think about file descriptors that can be dup() and passed
> around, the kernel has no idea what is going on with them, nor does it
> have to.
>
> Yes, we do track if the file is opened or not already, but I'd argue
> that too is broken and should probably be removed and just use the
> normal file descriptor logic instead.
>
Ack, responded below.
>
> > @@ -1378,8 +1393,18 @@ ffs_epfile_release(struct inode *inode, struct file *file)
> >
> > mutex_unlock(&epfile->dmabufs_mutex);
> >
> > - __ffs_epfile_read_buffer_free(epfile);
> > - ffs_data_closed(epfile->ffs);
> > + spin_lock_irq(&ffs->eps_lock);
> > + if (epfile->is_rw_proxy) {
> > + epfile->epfile_in->opened_count--;
> > + if (--epfile->epfile_out->opened_count == 0)
> > + __ffs_epfile_read_buffer_free(epfile->epfile_out);
> > + } else {
> > + if (--epfile->opened_count == 0)
> > + __ffs_epfile_read_buffer_free(epfile);
>
> If you drop the opened_count, shouldn't these buffers just get freed
> when the structure themselves get freed? You are treating the count as
> a "reference counted structure" in a hand-rolled way that might not
> really be right here as it's kind of hard to prove.
>
> Either use a real reference count for the whole structure (i.e. kref)
> because you need to, or just tie the lifetime of the buffer to the
> larger structure itself. Otherwise these fake references are going to
> be a pain to track that all is correct with them...
>
I was concerned about the implementation of opened_count, and was
pursuing a proper kref approach, but it became a somewhat invasive patch
and I didn't want to pollute this patchset with said change, as I didn't
want to potentially introduce issues for users which did not need this
series.
Changing the buffer lifetime to match the larger structure is
straightforward and clean. I will implement that in v2 of this series,
as it fixes an existing issue.
Thanks for the suggestions,
Neill
^ permalink raw reply
* Re: [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option
From: Vincent Mailhol @ 2026-06-15 20:33 UTC (permalink / raw)
To: Al Viro
Cc: Jens Axboe, Davidlohr Bueso, Christian Brauner, Jan Kara,
linux-kernel, linux-block, linux-efi, linux-fsdevel,
Richard Henderson, Matt Turner, Magnus Lindholm, linux-alpha,
Vineet Gupta, linux-snps-arc, Russell King, linux-arm-kernel,
Catalin Marinas, Will Deacon, Huacai Chen, WANG Xuerui, loongarch,
Thomas Bogendoerfer, linux-mips, James E.J. Bottomley,
Helge Deller, linux-parisc, Madhavan Srinivasan, Michael Ellerman,
linuxppc-dev, Paul Walmsley, Palmer Dabbelt, Albert Ou,
linux-riscv, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
linux-s390, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260615170432.GW2636677@ZenIV>
On 15/06/2026 at 19:04, Al Viro wrote:
> On Mon, Jun 15, 2026 at 06:08:56PM +0200, Vincent Mailhol wrote:
>
>> Tested with GRUB, which implements the LoaderDevicePartUUID EFI variable
>> in its bli module [3]. With this, I was able to boot a kernel with a
>> completely empty cmdline and no initrd.
>>
>> [1] The Discoverable Partitions Specification (DPS)
>> Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
>>
>> [2] systemd-gpt-auto-generator
>> Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
>>
>> [3] GRUB -- §16.2 bli
>> Link: https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html
>
> So what does that thing, tied to EFI as it is, have to do with architectures where
> * firmware is rather unlike EFI
I made CONFIG_DPS_ROOT_AUTO_DISCOVERY depend on CONFIG_EFI for this reason.
> * firmware wouldn't know what to do with GPT
> * GRUB is *not* ported to, let alone used
> such as, say it, the very first one mentioned at your [1]?
Fair point. I just did:
$ git grep "^config EFI$"
arch/arm/Kconfig:config EFI
arch/arm64/Kconfig:config EFI
arch/loongarch/Kconfig:config EFI
arch/riscv/Kconfig:config EFI
arch/x86/Kconfig:config EFI
Anything not in this list is dead code at the moment.
> Or is that conditional upon "if anyone wants to design replacement firmware
> for those, and if they agree to follow our wishlist"?
No, it was just an oversight from my side. I will just keep arm, arm64,
loongarch, riscv and x86 in my v2.
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [PATCH v6 03/12] PCI: liveupdate: Track incoming preserved PCI devices
From: David Matlack @ 2026-06-15 20:29 UTC (permalink / raw)
To: Pasha Tatashin
Cc: kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Leon Romanovsky,
Lukas Wunner, Mike Rapoport, Parav Pandit, Pranjal Shrivastava,
Pratyush Yadav, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <178144432039.1257322.9644414453415904478.b4-review@b4>
On 2026-06-14 01:38 PM, Pasha Tatashin wrote:
> On Fri, 22 May 2026 20:24:01 +0000, David Matlack <dmatlack@google.com> wrote:
> > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> > index 10c9b65aa242..e68ae5c172d4 100644
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -330,7 +330,7 @@ config VGA_ARB_MAX_GPUS
> >
> > config PCI_LIVEUPDATE
> > bool "PCI Live Update Support"
> > - depends on PCI && LIVEUPDATE
> > + depends on PCI && LIVEUPDATE && 64BIT
>
> Please move this to the first patch, fewer changes between patches, and
> also KHO does not support anything but 64-bit mode.
I think it is preferred to introduce changes when they are needed. This
is the exact patch that requires 64BIT so it makes sense to add the
dependency within this patch no?
>
> >
> > diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> > index 065d5af822f7..96c43b84532c 100644
> > --- a/drivers/pci/liveupdate.c
> > +++ b/drivers/pci/liveupdate.c
> > @@ -128,13 +157,49 @@ static void pci_flb_unpreserve(struct liveupdate_flb_op_args *args)
> > [ ... skip 31 lines ... ]
> > +
> > +err_xa_destroy:
> > + xa_destroy(&incoming->xa);
> > + kfree(incoming);
> > +err_restore_free:
> > + kho_restore_free(ser);
>
> This is the pattern we have been enforcing in other places in LUO. If
> the first retrieval fails, return the same error thereafter.
>
> > @@ -270,6 +335,91 @@ void pci_liveupdate_unpreserve(struct pci_dev *dev)
> > }
> > EXPORT_SYMBOL_GPL(pci_liveupdate_unpreserve);
> >
> > +static struct pci_flb_incoming *pci_liveupdate_flb_get_incoming(void)
> > +{
> > + struct pci_flb_incoming *incoming = NULL;
> > + int ret;
>
> Maybe make the error return static, and avoid another search through compatible
> FLBs if it failed before?
Good idea, will do.
>
> 1. Add "saved_err;"; if it is set, return it right away.
> 2. Change all errors to use goto save_err;, and at the end of the
> function, assign ret to saved_err;
>
> > [ ... skip 15 lines ... ]
> > + * This could mean that no PCI FLB data was passed by the previous
> > + * kernel, but it could also mean the previous kernel used a different
> > + * compatibility string (i.e. a different ABI).
> > + */
> > + if (ret == -ENOENT) {
> > + pr_info_once("No incoming FLB matched %s\n", pci_liveupdate_flb.compatible);
>
> I would assume this is very normal, e.g., no devices were preserved but
> memfd+hugetlb was preserved. Maybe use pr_debug_once().
The problem is described in the comment above. The PCI core cannot
distinguish between:
1. There was not PCI FLB preserved. and
2. There was PCI FLB preserved, but it was not compatible.
I agree we should not log anything for (1) but (2) definitely requires
at least some kind of logging so that's why I went with info-level here
and not debug.
>
> > + return NULL;
> > + }
> > +
> > + /*
> > + * There is incoming FLB data that matches pci_liveupdate_flb.compatible
> > + * but it cannot be retrieved.
> > + */
> > + if (ret) {
> > + WARN_ONCE(ret, "Failed to retrieve incoming FLB data\n");
>
> No need to print backtrace, please just print a warning:
> pr_warn_once("Failed to retrieve incoming FLB data: %pe\n", ERR_PTR(ret));
SGTM
>
> > [ ... skip 34 lines ... ]
> > + * through pci_liveupdate_finish(). This can happen if PCI core probes
> > + * the same device multiple times, e.g. due to hotplug.
> > + */
> > + if (!dev_ser->refcount) {
> > + pci_liveupdate_flb_put_incoming();
> > + return;
>
> Pleaes use 'goto put_incoming'
SGTM.
>
> > + }
> > +
> > + pci_info(dev, "Device was preserved by previous kernel across Live Update\n");
> > + dev->liveupdate.incoming = dev_ser;
> > +
> > + /*
> > + * Hold the ref on the incoming FLB until pci_liveupdate_finish() so
> > + * that dev->liveupdate.incoming does not get freed while it is in use.
> > + */
>
> How would that work? If finish is not called FLB stays around until the
> next reboot.
True... I think if the PCI core trusts drivers to call
pci_liveupdate_finish() then we don't need to hold onto the incoming
reference here.
>
> --
> Pasha Tatashin <pasha.tatashin@soleen.com>
^ permalink raw reply
* htmldocs: Warning: arch/arm/xen/enlighten.c references a file that doesn't exist: Documentation/devicetree/bindings/arm/xen.txt
From: kernel test robot @ 2026-06-15 20:28 UTC (permalink / raw)
To: Tejas; +Cc: oe-kbuild-all, 0day robot, linux-doc
tree: https://github.com/intel-lab-lkp/linux/commits/Tejas/dt-bindings-arm-xen-Convert-xen-txt-to-YAML-schema/20260615-192753
head: bf21bdc2f6582e22a01abfd47458d687bad86743
commit: bf21bdc2f6582e22a01abfd47458d687bad86743 dt-bindings: arm: xen: Convert xen.txt to YAML schema
date: 9 hours ago
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260615/202606152212.PIzfdQ9f-lkp@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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606152212.PIzfdQ9f-lkp@intel.com/
All warnings (new ones prefixed by >>):
Warning: Documentation/translations/zh_CN/how-to.rst references a file that doesn't exist: Documentation/xxx/xxx.rst
Warning: Documentation/translations/zh_CN/networking/xfrm_proc.rst references a file that doesn't exist: Documentation/networking/xfrm_proc.rst
Warning: Documentation/translations/zh_CN/scsi/scsi_mid_low_api.rst references a file that doesn't exist: Documentation/Configure.help
Warning: MAINTAINERS references a file that doesn't exist: Documentation/ABI/testing/sysfs-platform-ayaneo
Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/display/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
>> Warning: arch/arm/xen/enlighten.c references a file that doesn't exist: Documentation/devicetree/bindings/arm/xen.txt
Warning: arch/powerpc/sysdev/mpic.c references a file that doesn't exist: Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
Warning: drivers/net/ethernet/smsc/Kconfig references a file that doesn't exist: file:Documentation/networking/device_drivers/ethernet/smsc/smc9.rst
Warning: rust/kernel/sync/atomic/ordering.rs references a file that doesn't exist: srctree/tools/memory-model/Documentation/explanation.txt
Warning: tools/docs/documentation-file-ref-check references a file that doesn't exist: Documentation/virtual/lguest/lguest.c
Warning: tools/docs/documentation-file-ref-check references a file that doesn't exist: m,\b(\S*)(Documentation/[A-Za-z0-9
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v6 05/12] PCI: liveupdate: Keep bus numbers constant during Live Update
From: David Matlack @ 2026-06-15 20:20 UTC (permalink / raw)
To: Pasha Tatashin
Cc: kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Leon Romanovsky,
Lukas Wunner, Mike Rapoport, Parav Pandit, Pranjal Shrivastava,
Pratyush Yadav, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <178144546090.1266136.8524338598480624580.b4-review@b4>
On 2026-06-14 01:57 PM, Pasha Tatashin wrote:
> On Fri, 22 May 2026 20:24:03 +0000, David Matlack <dmatlack@google.com> wrote:
> > diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> > index 4f2ec6ffdd16..2421bc218916 100644
> > --- a/drivers/pci/liveupdate.c
> > +++ b/drivers/pci/liveupdate.c
> > @@ -103,7 +118,7 @@
> > /**
> > * struct pci_liveupdate_global - Global state for PCI Live Update support
> > * @rwsem: Reader/writer semaphore used to protect the incoming and outgoing
> > - * FLBs, and the references to them in struct pci_dev.
> > + * FLBs and references to them in struct pci_dev.
>
> This change does not belong to this patch.
Yes, will fix.
>
> > @@ -396,6 +411,72 @@ static void pci_liveupdate_flb_put_incoming(void)
> > liveupdate_flb_put_incoming(&pci_liveupdate_flb);
> > }
> >
> > +bool pci_liveupdate_scan_bridge_begin(struct pci_bus *bus, struct pci_dev *dev,
> > + int pass)
>
> This function requires a header comment; it is public and not self-descriptive.
It is private to the PCI core, but I can still add a comment in v7.
>
> --
> Pasha Tatashin <pasha.tatashin@soleen.com>
^ permalink raw reply
* [PATCH v4 3/5] rpmsg: virtio_rpmsg_bus: get buffer size from config space
From: Tanmay Shah @ 2026-06-15 20:20 UTC (permalink / raw)
To: andersson, mathieu.poirier, corbet, skhan, arnaud.pouliquen
Cc: linux-remoteproc, linux-doc, linux-kernel, Tanmay Shah
In-Reply-To: <20260615202007.3484668-1-tanmay.shah@amd.com>
512 bytes isn't always suitable for all case, let firmware
maker decide the best value from resource table.
enable by VIRTIO_RPMSG_F_BUFSZ feature bit.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
Changes in v4: squash to virtio rpmsg config patch
- Introduce new patch to modify rpmsg.rst documentation
- check version is always 1.
- check size field is same as size of struct virtio_rpmsg_config
- introduce alignment field
- check alignment field is power of 2
- check tx and rx buf size is aligned with alignment passed in the
structure
Changes in v3:
- change version field from u16 to u8
- introduce size field in the rpmsg_virtio_config structure
- check version field is set to any non-zero value.
- check size field is not 0.
- Remove field for private config, as not needed for now.
- add documentation of rpmsg_virtio_config structure
drivers/rpmsg/virtio_rpmsg_bus.c | 129 ++++++++++++++++++++++++-----
include/linux/rpmsg/virtio_rpmsg.h | 50 +++++++++++
2 files changed, 160 insertions(+), 19 deletions(-)
create mode 100644 include/linux/rpmsg/virtio_rpmsg.h
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 99df1ae07055..a59925f870a4 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -15,11 +15,13 @@
#include <linux/idr.h>
#include <linux/jiffies.h>
#include <linux/kernel.h>
+#include <linux/log2.h>
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/rpmsg.h>
#include <linux/rpmsg/byteorder.h>
#include <linux/rpmsg/ns.h>
+#include <linux/rpmsg/virtio_rpmsg.h>
#include <linux/scatterlist.h>
#include <linux/slab.h>
#include <linux/sched.h>
@@ -39,7 +41,8 @@
* @tx_bufs: kernel address of tx buffers
* @num_rx_buf: total number of rx buffers
* @num_tx_buf: total number of tx buffers
- * @buf_size: size of one rx or tx buffer
+ * @rx_buf_size: size of one rx buffer
+ * @tx_buf_size: size of one tx buffer
* @last_tx_buf: index of last tx buffer used
* @bufs_dma: dma base addr of the buffers
* @tx_lock: protects svq and tx_bufs, to allow concurrent senders.
@@ -59,7 +62,8 @@ struct virtproc_info {
void *rx_bufs, *tx_bufs;
unsigned int num_rx_buf;
unsigned int num_tx_buf;
- unsigned int buf_size;
+ unsigned int rx_buf_size;
+ unsigned int tx_buf_size;
int last_tx_buf;
dma_addr_t bufs_dma;
struct mutex tx_lock;
@@ -68,9 +72,6 @@ struct virtproc_info {
wait_queue_head_t sendq;
};
-/* The feature bitmap for virtio rpmsg */
-#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
-
/**
* struct rpmsg_hdr - common header for all rpmsg messages
* @src: source address
@@ -128,7 +129,7 @@ struct virtio_rpmsg_channel {
* processor.
*/
#define MAX_RPMSG_NUM_BUFS (256)
-#define MAX_RPMSG_BUF_SIZE (512)
+#define DEFAULT_RPMSG_BUF_SIZE (512)
/*
* Local addresses are dynamically allocated on-demand.
@@ -444,7 +445,7 @@ static void *get_a_tx_buf(struct virtproc_info *vrp)
/* either pick the next unused tx buffer */
if (vrp->last_tx_buf < vrp->num_tx_buf)
- ret = vrp->tx_bufs + vrp->buf_size * vrp->last_tx_buf++;
+ ret = vrp->tx_bufs + vrp->tx_buf_size * vrp->last_tx_buf++;
/* or recycle a used one */
else
ret = virtqueue_get_buf(vrp->svq, &len);
@@ -514,7 +515,7 @@ static int rpmsg_send_offchannel_raw(struct rpmsg_device *rpdev,
* messaging), or to improve the buffer allocator, to support
* variable-length buffer sizes.
*/
- if (len > vrp->buf_size - sizeof(struct rpmsg_hdr)) {
+ if (len > vrp->tx_buf_size - sizeof(struct rpmsg_hdr)) {
dev_err(dev, "message is too big (%d)\n", len);
return -EMSGSIZE;
}
@@ -647,7 +648,7 @@ static ssize_t virtio_rpmsg_get_mtu(struct rpmsg_endpoint *ept)
struct rpmsg_device *rpdev = ept->rpdev;
struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
- return vch->vrp->buf_size - sizeof(struct rpmsg_hdr);
+ return vch->vrp->tx_buf_size - sizeof(struct rpmsg_hdr);
}
static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
@@ -673,7 +674,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
* We currently use fixed-sized buffers, so trivially sanitize
* the reported payload length.
*/
- if (len > vrp->buf_size ||
+ if (len > vrp->rx_buf_size ||
msg_len > (len - sizeof(struct rpmsg_hdr))) {
dev_warn(dev, "inbound msg too big: (%d, %d)\n", len, msg_len);
return -EINVAL;
@@ -706,7 +707,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
dev_warn_ratelimited(dev, "msg received with no recipient\n");
/* publish the real size of the buffer */
- rpmsg_sg_init(&sg, msg, vrp->buf_size);
+ rpmsg_sg_init(&sg, msg, vrp->rx_buf_size);
/* add the buffer back to the remote processor's virtqueue */
err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, msg, GFP_KERNEL);
@@ -820,10 +821,13 @@ static int rpmsg_probe(struct virtio_device *vdev)
struct virtproc_info *vrp;
struct virtio_rpmsg_channel *vch = NULL;
struct rpmsg_device *rpdev_ns, *rpdev_ctrl;
+ u16 rpmsg_buf_align = 0;
void *bufs_va;
int err = 0, i;
size_t total_buf_space;
bool notify;
+ u8 version;
+ u16 size;
vrp = kzalloc_obj(*vrp);
if (!vrp)
@@ -855,9 +859,90 @@ static int rpmsg_probe(struct virtio_device *vdev)
else
vrp->num_tx_buf = MAX_RPMSG_NUM_BUFS;
- vrp->buf_size = MAX_RPMSG_BUF_SIZE;
+ /*
+ * If VIRTIO_RPMSG_F_BUFSZ feature is supported, then configure buf
+ * size from virtio device config space from the resource table.
+ * If the feature is not supported, then assign default buf size.
+ */
+ if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_BUFSZ)) {
+ virtio_cread(vdev, struct virtio_rpmsg_config,
+ version, &version);
+
+ /* for now we support only v1 */
+ if (version != RPMSG_VDEV_CONFIG_V1) {
+ dev_err(&vdev->dev,
+ "unsupported vdev config version %u\n", version);
+ err = -EINVAL;
+ goto vqs_del;
+ }
+
+ /* size of the config space must match */
+ virtio_cread(vdev, struct virtio_rpmsg_config,
+ size, &size);
+ if (size != sizeof(struct virtio_rpmsg_config)) {
+ dev_err(&vdev->dev, "invalid size of vdev config %u\n",
+ size);
+ err = -EINVAL;
+ goto vqs_del;
+ }
- total_buf_space = (vrp->num_rx_buf + vrp->num_tx_buf) * vrp->buf_size;
+ /*
+ * Optional alignment applied to each buffer size and to the TX
+ * buffer base address (e.g. to align buffers on a cache line).
+ * It must be a power of two; zero means no extra alignment.
+ */
+ virtio_cread(vdev, struct virtio_rpmsg_config,
+ rpmsg_buf_align, &rpmsg_buf_align);
+ if (rpmsg_buf_align && !is_power_of_2(rpmsg_buf_align)) {
+ dev_err(&vdev->dev,
+ "bad vdev config: rpmsg_buf_align %u is not a power of two\n",
+ rpmsg_buf_align);
+ err = -EINVAL;
+ goto vqs_del;
+ }
+
+ /* note: tx and rx are defined from remote view */
+ virtio_cread(vdev, struct virtio_rpmsg_config,
+ txbuf_size, &vrp->rx_buf_size);
+ virtio_cread(vdev, struct virtio_rpmsg_config,
+ rxbuf_size, &vrp->tx_buf_size);
+
+ /* The buffers must hold at least the rpmsg header */
+ if (vrp->rx_buf_size < sizeof(struct rpmsg_hdr) ||
+ vrp->tx_buf_size < sizeof(struct rpmsg_hdr)) {
+ dev_err(&vdev->dev,
+ "bad vdev config: rx buf sz = %u, tx buf sz = %u\n",
+ vrp->rx_buf_size, vrp->tx_buf_size);
+ err = -EINVAL;
+ goto vqs_del;
+ }
+
+ /*
+ * The buffer size must be aligned to the provided alignment for
+ * so that the start address of tx bufs can be aligned.
+ */
+ if (rpmsg_buf_align &&
+ (!IS_ALIGNED(vrp->rx_buf_size, rpmsg_buf_align) ||
+ !IS_ALIGNED(vrp->tx_buf_size, rpmsg_buf_align))) {
+ dev_err(&vdev->dev,
+ "bad vdev config: buf sizes (rx %u, tx %u) not aligned to %u\n",
+ vrp->rx_buf_size, vrp->tx_buf_size,
+ rpmsg_buf_align);
+ err = -EINVAL;
+ goto vqs_del;
+ }
+
+ dev_dbg(&vdev->dev,
+ "vdev config: ver=%u, align=0x%x, rx sz = 0x%x, tx sz = 0x%x\n",
+ version, rpmsg_buf_align, vrp->rx_buf_size,
+ vrp->tx_buf_size);
+ } else {
+ vrp->rx_buf_size = DEFAULT_RPMSG_BUF_SIZE;
+ vrp->tx_buf_size = DEFAULT_RPMSG_BUF_SIZE;
+ }
+
+ total_buf_space = (vrp->num_rx_buf * vrp->rx_buf_size) +
+ (vrp->num_tx_buf * vrp->tx_buf_size);
/* allocate coherent memory for the buffers */
bufs_va = dma_alloc_coherent(vdev->dev.parent,
@@ -874,15 +959,20 @@ static int rpmsg_probe(struct virtio_device *vdev)
/* first part of the buffers is dedicated for RX */
vrp->rx_bufs = bufs_va;
- /* and second part is dedicated for TX */
- vrp->tx_bufs = bufs_va + vrp->num_rx_buf * vrp->buf_size;
+ /*
+ * Here buf_va is aligned to a page. Also rx buf size is aligned with
+ * cache line alignment provided by the firmware, so tx buf's start
+ * address is guranteed to be aligned with the alignment provided by
+ * the firmware.
+ */
+ vrp->tx_bufs = bufs_va + (vrp->num_rx_buf * vrp->rx_buf_size);
/* set up the receive buffers */
for (i = 0; i < vrp->num_rx_buf; i++) {
struct scatterlist sg;
- void *cpu_addr = vrp->rx_bufs + i * vrp->buf_size;
+ void *cpu_addr = vrp->rx_bufs + i * vrp->rx_buf_size;
- rpmsg_sg_init(&sg, cpu_addr, vrp->buf_size);
+ rpmsg_sg_init(&sg, cpu_addr, vrp->rx_buf_size);
err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, cpu_addr,
GFP_KERNEL);
@@ -965,8 +1055,8 @@ static int rpmsg_remove_device(struct device *dev, void *data)
static void rpmsg_remove(struct virtio_device *vdev)
{
struct virtproc_info *vrp = vdev->priv;
- unsigned int num_bufs = vrp->num_rx_buf + vrp->num_tx_buf;
- size_t total_buf_space = num_bufs * vrp->buf_size;
+ size_t total_buf_space = (vrp->num_rx_buf * vrp->rx_buf_size) +
+ (vrp->num_tx_buf * vrp->tx_buf_size);
int ret;
virtio_reset_device(vdev);
@@ -992,6 +1082,7 @@ static struct virtio_device_id id_table[] = {
static unsigned int features[] = {
VIRTIO_RPMSG_F_NS,
+ VIRTIO_RPMSG_F_BUFSZ,
};
static struct virtio_driver virtio_ipc_driver = {
diff --git a/include/linux/rpmsg/virtio_rpmsg.h b/include/linux/rpmsg/virtio_rpmsg.h
new file mode 100644
index 000000000000..7e14da68fd17
--- /dev/null
+++ b/include/linux/rpmsg/virtio_rpmsg.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) Pinecone Inc. 2019
+ * Copyright (C) Xiang Xiao <xiaoxiang@pinecone.net>
+ * Copyright (C) Advanced Micro Devices, Inc. 2026
+ */
+
+#ifndef _LINUX_VIRTIO_RPMSG_H
+#define _LINUX_VIRTIO_RPMSG_H
+
+#include <linux/types.h>
+#include <linux/virtio_types.h>
+
+/* The feature bitmap for virtio rpmsg */
+#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
+#define VIRTIO_RPMSG_F_BUFSZ 1 /* RP get buffer size from config space */
+
+/* Version of struct virtio_rpmsg_config understood by this driver */
+#define RPMSG_VDEV_CONFIG_V1 1
+
+/**
+ * struct virtio_rpmsg_config - config space for rpmsg virtio device
+ *
+ * @version: version of this structure, currently %RPMSG_VDEV_CONFIG_V1.
+ * @reserved: reserved for padding, must be zero.
+ * @size: size of this structure in bytes.
+ * @rpmsg_buf_align: required alignment in bytes for each buffer. Must be a
+ * power of two so that both the buffer sizes and the TX buffer
+ * base address can be aligned (e.g. to a cache line).
+ * @reserved1: reserved for padding, must be zero. Keeps the following 32-bit
+ * fields naturally aligned.
+ * @txbuf_size: Tx buf size from remote's view. For Linux this is rx buf size.
+ * @rxbuf_size: Rx buf size from remote's view. For Linux this is tx buf size.
+ *
+ * This is the configuration structure shared by the device and the driver,
+ * read when %VIRTIO_RPMSG_F_BUFSZ is negotiated. The fields are laid out so
+ * the structure is naturally 32-bit aligned.
+ */
+struct virtio_rpmsg_config {
+ u8 version;
+ u8 reserved;
+ __virtio16 size;
+ __virtio16 rpmsg_buf_align;
+ __virtio16 reserved1;
+ /* The tx/rx individual buffer size (if VIRTIO_RPMSG_F_BUFSZ) */
+ __virtio32 txbuf_size;
+ __virtio32 rxbuf_size;
+} __packed;
+
+#endif /* _LINUX_VIRTIO_RPMSG_H */
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/5] samples: rpmsg: add MTU size info
From: Tanmay Shah @ 2026-06-15 20:20 UTC (permalink / raw)
To: andersson, mathieu.poirier, corbet, skhan, arnaud.pouliquen
Cc: linux-remoteproc, linux-doc, linux-kernel, Tanmay Shah
In-Reply-To: <20260615202007.3484668-1-tanmay.shah@amd.com>
RPMsg MTU size can be variable now and no longer hardcoded to 512 bytes.
Add log to the sample driver that prints current MTU size of the rpmsg
buffer.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
Changes in v4:
- check msg size is < MTU size
Changes in v3:
- Check for error when retrieving MTU size
- %s/mtu/MTU/
samples/rpmsg/rpmsg_client_sample.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/samples/rpmsg/rpmsg_client_sample.c b/samples/rpmsg/rpmsg_client_sample.c
index ae5081662283..4c43436aadb6 100644
--- a/samples/rpmsg/rpmsg_client_sample.c
+++ b/samples/rpmsg/rpmsg_client_sample.c
@@ -52,6 +52,7 @@ static int rpmsg_sample_probe(struct rpmsg_device *rpdev)
{
int ret;
struct instance_data *idata;
+ ssize_t mtu, msg_len;
dev_info(&rpdev->dev, "new channel: 0x%x -> 0x%x!\n",
rpdev->src, rpdev->dst);
@@ -62,8 +63,25 @@ static int rpmsg_sample_probe(struct rpmsg_device *rpdev)
dev_set_drvdata(&rpdev->dev, idata);
+ mtu = rpmsg_get_mtu(rpdev->ept);
+ if (mtu < 0) {
+ dev_warn(&rpdev->dev, "invalid rpmsg MTU size = %ld\n", mtu);
+ return mtu;
+ }
+
+ dev_info(&rpdev->dev, "rpmsg MTU size = %ld\n", mtu);
+
+ msg_len = strlen(MSG);
+ /* make sure our message fits in a single rpmsg buffer */
+ if (msg_len > mtu) {
+ dev_err(&rpdev->dev,
+ "message size %zu exceeds rpmsg MTU size %ld\n",
+ strlen(MSG), mtu);
+ return -EMSGSIZE;
+ }
+
/* send a message to our remote processor */
- ret = rpmsg_send(rpdev->ept, MSG, strlen(MSG));
+ ret = rpmsg_send(rpdev->ept, MSG, msg_len);
if (ret) {
dev_err(&rpdev->dev, "rpmsg_send failed: %d\n", ret);
return ret;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/5] Enhance RPMsg buffer management
From: Tanmay Shah @ 2026-06-15 20:20 UTC (permalink / raw)
To: andersson, mathieu.poirier, corbet, skhan, arnaud.pouliquen
Cc: linux-remoteproc, linux-doc, linux-kernel, Tanmay Shah
Current design uses fixed (512 bytes) rpmsg buffer size in both rx and
tx directions. This design is not suitable if the payload is larger than
512 bytes or the payload is very small and doesn't need that much
memory. Instead introduce new virtio feature to retrieve rpmsg tx buf
size and rx buf size from the virtio config space in the resource table.
Changes in v4:
- Introduce new patch to modify rpmsg.rst documentation
- check version is always 1.
- check size field is same as size of struct virtio_rpmsg_config
- introduce alignment field
- check alignment field is power of 2
- check tx and rx buf size is aligned with alignment passed in the
structure
- check msg size is < MTU size
Changes in v3:
- new patch [1/4] that renames variables with clear names.
- %s/rbufs/rx_bufs/
- %s/sbufs/tx_bufs/
- %s/last_sbuf/last_tx_buf/
- add num_rx_buf and num_tx_buf in the documentation
- change version field from u16 to u8
- introduce size field in the rpmsg_virtio_config structure
- check version field is set to any non-zero value.
- check size field is not 0.
- Remove field for private config, as not needed for now.
- add documentation of rpmsg_virtio_config structure
- Check for error when retrieving MTU size in the sample driver
- %s/mtu/MTU/
Changes in v2:
- Change author
- fix commit message with better explanation
- %s/sbuf/tx_buf
- %s/rbuf/rx_buf
- %s/num_rbuf/num_rx_buf/
- %s/num_sbuf/num_tx_buf/
- %s/sbuf_size/tx_buf_size/
- %s/rbuf_size/rx_buf_size/
- fix typo
- do not use ALIGN on buf size, rely on allocator
- make err msg more explicit, %s/vdev config:/bad vdev config/
- fix license and add AMD copyrights in the header virtio_rpmsg.h
- Assign bit 1 to VIRTIO_RPMSG_F_BUFSZ feature
- use __virtio32 over __u32
- add version field to virtio rpmsg config structure
- Introduce new patch to print rpmsg mtu size in the sample rpmsg driver
- move linux/virtio_rpmsg.h to linux/rpmsg/virtio_rpmsg.h
Tanmay Shah (5):
rpmsg: virtio_rpmsg_bus: rename rbufs and sbufs
rpmsg: virtio_rpmsg_bus: allow different size of tx and rx bufs
rpmsg: virtio_rpmsg_bus: get buffer size from config space
docs: rpmsg: add virtio config space details
samples: rpmsg: add MTU size info
Documentation/staging/rpmsg.rst | 19 +++
drivers/rpmsg/virtio_rpmsg_bus.c | 185 +++++++++++++++++++++-------
include/linux/rpmsg/virtio_rpmsg.h | 50 ++++++++
samples/rpmsg/rpmsg_client_sample.c | 20 ++-
4 files changed, 226 insertions(+), 48 deletions(-)
create mode 100644 include/linux/rpmsg/virtio_rpmsg.h
base-commit: 85842b61f64cac93d28e129d35193e329d463fd1
--
2.34.1
^ permalink raw reply
* [PATCH v4 2/5] rpmsg: virtio_rpmsg_bus: allow different size of tx and rx bufs
From: Tanmay Shah @ 2026-06-15 20:20 UTC (permalink / raw)
To: andersson, mathieu.poirier, corbet, skhan, arnaud.pouliquen
Cc: linux-remoteproc, linux-doc, linux-kernel, Tanmay Shah
In-Reply-To: <20260615202007.3484668-1-tanmay.shah@amd.com>
Current design allocates memory for tx and rx buffers equally. The
throughput can be increased if the user is allowed to configure number
of tx and rx buffers as required. Hence, do not split number of tx & rx
buffers into half, but decide based on respective vring size.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
drivers/rpmsg/virtio_rpmsg_bus.c | 50 ++++++++++++++++----------------
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 773547479d15..99df1ae07055 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -37,7 +37,8 @@
* @svq: tx virtqueue
* @rx_bufs: kernel address of rx buffers
* @tx_bufs: kernel address of tx buffers
- * @num_bufs: total number of buffers for rx and tx
+ * @num_rx_buf: total number of rx buffers
+ * @num_tx_buf: total number of tx buffers
* @buf_size: size of one rx or tx buffer
* @last_tx_buf: index of last tx buffer used
* @bufs_dma: dma base addr of the buffers
@@ -56,7 +57,8 @@ struct virtproc_info {
struct virtio_device *vdev;
struct virtqueue *rvq, *svq;
void *rx_bufs, *tx_bufs;
- unsigned int num_bufs;
+ unsigned int num_rx_buf;
+ unsigned int num_tx_buf;
unsigned int buf_size;
int last_tx_buf;
dma_addr_t bufs_dma;
@@ -110,7 +112,7 @@ struct virtio_rpmsg_channel {
/*
* We're allocating buffers of 512 bytes each for communications. The
* number of buffers will be computed from the number of buffers supported
- * by the vring, upto a maximum of 512 buffers (256 in each direction).
+ * by the vring, up to a maximum of 256 in each direction.
*
* Each buffer will have 16 bytes for the msg header and 496 bytes for
* the payload.
@@ -125,7 +127,7 @@ struct virtio_rpmsg_channel {
* can change this without changing anything in the firmware of the remote
* processor.
*/
-#define MAX_RPMSG_NUM_BUFS (512)
+#define MAX_RPMSG_NUM_BUFS (256)
#define MAX_RPMSG_BUF_SIZE (512)
/*
@@ -440,11 +442,8 @@ static void *get_a_tx_buf(struct virtproc_info *vrp)
mutex_lock(&vrp->tx_lock);
- /*
- * either pick the next unused tx buffer
- * (half of our buffers are used for sending messages)
- */
- if (vrp->last_tx_buf < vrp->num_bufs / 2)
+ /* either pick the next unused tx buffer */
+ if (vrp->last_tx_buf < vrp->num_tx_buf)
ret = vrp->tx_bufs + vrp->buf_size * vrp->last_tx_buf++;
/* or recycle a used one */
else
@@ -631,11 +630,10 @@ static __poll_t virtio_rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
/*
* check for a free buffer, either:
- * - we haven't used all of the available transmit buffers (half of the
- * allocated buffers are used for transmit, hence num_bufs / 2), or,
+ * - we haven't used all of the available transmit buffers or,
* - we ask the virtqueue if there's a buffer available
*/
- if (vrp->last_tx_buf < vrp->num_bufs / 2 ||
+ if (vrp->last_tx_buf < vrp->num_tx_buf ||
!virtqueue_enable_cb(vrp->svq))
mask |= EPOLLOUT;
@@ -846,19 +844,20 @@ static int rpmsg_probe(struct virtio_device *vdev)
vrp->rvq = vqs[0];
vrp->svq = vqs[1];
- /* we expect symmetric tx/rx vrings */
- WARN_ON(virtqueue_get_vring_size(vrp->rvq) !=
- virtqueue_get_vring_size(vrp->svq));
-
/* we need less buffers if vrings are small */
- if (virtqueue_get_vring_size(vrp->rvq) < MAX_RPMSG_NUM_BUFS / 2)
- vrp->num_bufs = virtqueue_get_vring_size(vrp->rvq) * 2;
+ if (virtqueue_get_vring_size(vrp->rvq) < MAX_RPMSG_NUM_BUFS)
+ vrp->num_rx_buf = virtqueue_get_vring_size(vrp->rvq);
+ else
+ vrp->num_rx_buf = MAX_RPMSG_NUM_BUFS;
+
+ if (virtqueue_get_vring_size(vrp->svq) < MAX_RPMSG_NUM_BUFS)
+ vrp->num_tx_buf = virtqueue_get_vring_size(vrp->svq);
else
- vrp->num_bufs = MAX_RPMSG_NUM_BUFS;
+ vrp->num_tx_buf = MAX_RPMSG_NUM_BUFS;
vrp->buf_size = MAX_RPMSG_BUF_SIZE;
- total_buf_space = vrp->num_bufs * vrp->buf_size;
+ total_buf_space = (vrp->num_rx_buf + vrp->num_tx_buf) * vrp->buf_size;
/* allocate coherent memory for the buffers */
bufs_va = dma_alloc_coherent(vdev->dev.parent,
@@ -872,14 +871,14 @@ static int rpmsg_probe(struct virtio_device *vdev)
dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
bufs_va, &vrp->bufs_dma);
- /* half of the buffers is dedicated for RX */
+ /* first part of the buffers is dedicated for RX */
vrp->rx_bufs = bufs_va;
- /* and half is dedicated for TX */
- vrp->tx_bufs = bufs_va + total_buf_space / 2;
+ /* and second part is dedicated for TX */
+ vrp->tx_bufs = bufs_va + vrp->num_rx_buf * vrp->buf_size;
/* set up the receive buffers */
- for (i = 0; i < vrp->num_bufs / 2; i++) {
+ for (i = 0; i < vrp->num_rx_buf; i++) {
struct scatterlist sg;
void *cpu_addr = vrp->rx_bufs + i * vrp->buf_size;
@@ -966,7 +965,8 @@ static int rpmsg_remove_device(struct device *dev, void *data)
static void rpmsg_remove(struct virtio_device *vdev)
{
struct virtproc_info *vrp = vdev->priv;
- size_t total_buf_space = vrp->num_bufs * vrp->buf_size;
+ unsigned int num_bufs = vrp->num_rx_buf + vrp->num_tx_buf;
+ size_t total_buf_space = num_bufs * vrp->buf_size;
int ret;
virtio_reset_device(vdev);
--
2.34.1
^ permalink raw reply related
* [PATCH v4 4/5] docs: rpmsg: add virtio config space details
From: Tanmay Shah @ 2026-06-15 20:20 UTC (permalink / raw)
To: andersson, mathieu.poirier, corbet, skhan, arnaud.pouliquen
Cc: linux-remoteproc, linux-doc, linux-kernel, Tanmay Shah
In-Reply-To: <20260615202007.3484668-1-tanmay.shah@amd.com>
The virtio config space can provide single rpmsg buffer size in each
direction. Document details of the configurable buffer size via virtio
config space.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
Documentation/staging/rpmsg.rst | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/Documentation/staging/rpmsg.rst b/Documentation/staging/rpmsg.rst
index 42bac1149d9d..c06602e169a9 100644
--- a/Documentation/staging/rpmsg.rst
+++ b/Documentation/staging/rpmsg.rst
@@ -300,3 +300,22 @@ by the bus, and can then start sending messages to the remote service.
The plan is also to add static creation of rpmsg channels via the virtio
config space, but it's not implemented yet.
+
+Configurable buffer sizes
+=========================
+
+By default each rpmsg buffer is 512 bytes, and the same size is used for both
+the receive and transmit directions. Remote processors that need a different
+size (for example a larger MTU, or different RX and TX sizes) can advertise it
+through the virtio device config space by setting the VIRTIO_RPMSG_F_BUFSZ
+feature bit.
+
+When this feature is negotiated, the driver reads struct virtio_rpmsg_config
+from the config space. This structure provides the size of a single buffer for
+each direction (TX and RX), and the driver splits the total buffer space into
+TX and RX buffers accordingly. Both buffer sizes must be aligned to the
+rpmsg_buf_align field provided in the config space; a value of 0 means the
+sizes are assumed to be already aligned.
+
+If the feature is not negotiated, the default 512-byte buffers are used for
+both directions.
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/5] rpmsg: virtio_rpmsg_bus: rename rbufs and sbufs
From: Tanmay Shah @ 2026-06-15 20:20 UTC (permalink / raw)
To: andersson, mathieu.poirier, corbet, skhan, arnaud.pouliquen
Cc: linux-remoteproc, linux-doc, linux-kernel, Tanmay Shah
In-Reply-To: <20260615202007.3484668-1-tanmay.shah@amd.com>
rename variables with clear names.
%s/rbufs/rx_bufs/
%s/sbufs/tx_bufs/
%s/last_sbuf/last_tx_buf/
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
drivers/rpmsg/virtio_rpmsg_bus.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 5ae15111fb4f..773547479d15 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -35,13 +35,13 @@
* @vdev: the virtio device
* @rvq: rx virtqueue
* @svq: tx virtqueue
- * @rbufs: kernel address of rx buffers
- * @sbufs: kernel address of tx buffers
- * @num_bufs: total number of buffers for rx and tx
+ * @rx_bufs: kernel address of rx buffers
+ * @tx_bufs: kernel address of tx buffers
+ * @num_bufs: total number of buffers for rx and tx
* @buf_size: size of one rx or tx buffer
- * @last_sbuf: index of last tx buffer used
+ * @last_tx_buf: index of last tx buffer used
* @bufs_dma: dma base addr of the buffers
- * @tx_lock: protects svq and sbufs, to allow concurrent senders.
+ * @tx_lock: protects svq and tx_bufs, to allow concurrent senders.
* sending a message might require waking up a dozing remote
* processor, which involves sleeping, hence the mutex.
* @endpoints: idr of local endpoints, allows fast retrieval
@@ -55,10 +55,10 @@
struct virtproc_info {
struct virtio_device *vdev;
struct virtqueue *rvq, *svq;
- void *rbufs, *sbufs;
+ void *rx_bufs, *tx_bufs;
unsigned int num_bufs;
unsigned int buf_size;
- int last_sbuf;
+ int last_tx_buf;
dma_addr_t bufs_dma;
struct mutex tx_lock;
struct idr endpoints;
@@ -444,8 +444,8 @@ static void *get_a_tx_buf(struct virtproc_info *vrp)
* either pick the next unused tx buffer
* (half of our buffers are used for sending messages)
*/
- if (vrp->last_sbuf < vrp->num_bufs / 2)
- ret = vrp->sbufs + vrp->buf_size * vrp->last_sbuf++;
+ if (vrp->last_tx_buf < vrp->num_bufs / 2)
+ ret = vrp->tx_bufs + vrp->buf_size * vrp->last_tx_buf++;
/* or recycle a used one */
else
ret = virtqueue_get_buf(vrp->svq, &len);
@@ -635,7 +635,7 @@ static __poll_t virtio_rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
* allocated buffers are used for transmit, hence num_bufs / 2), or,
* - we ask the virtqueue if there's a buffer available
*/
- if (vrp->last_sbuf < vrp->num_bufs / 2 ||
+ if (vrp->last_tx_buf < vrp->num_bufs / 2 ||
!virtqueue_enable_cb(vrp->svq))
mask |= EPOLLOUT;
@@ -873,15 +873,15 @@ static int rpmsg_probe(struct virtio_device *vdev)
bufs_va, &vrp->bufs_dma);
/* half of the buffers is dedicated for RX */
- vrp->rbufs = bufs_va;
+ vrp->rx_bufs = bufs_va;
/* and half is dedicated for TX */
- vrp->sbufs = bufs_va + total_buf_space / 2;
+ vrp->tx_bufs = bufs_va + total_buf_space / 2;
/* set up the receive buffers */
for (i = 0; i < vrp->num_bufs / 2; i++) {
struct scatterlist sg;
- void *cpu_addr = vrp->rbufs + i * vrp->buf_size;
+ void *cpu_addr = vrp->rx_bufs + i * vrp->buf_size;
rpmsg_sg_init(&sg, cpu_addr, vrp->buf_size);
@@ -980,7 +980,7 @@ static void rpmsg_remove(struct virtio_device *vdev)
vdev->config->del_vqs(vrp->vdev);
dma_free_coherent(vdev->dev.parent, total_buf_space,
- vrp->rbufs, vrp->bufs_dma);
+ vrp->rx_bufs, vrp->bufs_dma);
kfree(vrp);
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/3] usb: gadget: f_fs: Initialize epfile->in early to fix endpoint direction checks
From: Neill Kapron @ 2026-06-15 20:19 UTC (permalink / raw)
To: Greg KH
Cc: corbet, skhan, Paul Cercueil, Christian König, Simona Vetter,
linux-usb, linux-doc, linux-kernel, kernel-team
In-Reply-To: <2026061533-oval-buckle-b90e@gregkh>
On Mon, Jun 15, 2026 at 04:30:49AM +0200, Greg KH wrote:
> On Sun, Jun 14, 2026 at 06:10:00PM +0000, Neill Kapron wrote:
> >
> > Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface")
> > Assisted-by: Antigravity:gemini-3.1-pro
> > Signed-off-by: Neill Kapron <nkapron@google.com>
> > ---
> > drivers/usb/gadget/function/f_fs.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> This should also go to stable, right?
Yes, I will update v2 with the Cc: stable@vger.kernel.org tag.
Thanks,
Neill
^ permalink raw reply
* Re: [swap tier discussion] Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback
From: Yosry Ahmed @ 2026-06-15 19:55 UTC (permalink / raw)
To: YoungJun Park
Cc: Shakeel Butt, Hao Jia, Johannes Weiner, mhocko, tj, mkoutny,
roman.gushchin, Nhat Pham, akpm, chengming.zhou, muchun.song,
cgroups, linux-mm, linux-kernel, linux-doc, Hao Jia, chrisl,
kasong, baoquan.he, joshua.hahnjy
In-Reply-To: <ai5y923elCSZp41j@yjaykim-PowerEdge-T330>
> In that case, the internal logic could stay roughly the same rather
> than counting via a page counter. Something like:
>
> 1. Change the interface shell: tier.*.max — allow only 0 ~ max.
What about a single interface as I suggested to remain consistent with
memory tiering?
> 2. Keep the internal logic as is: 0 disables the mask (child memcgs
> off too), max enables it (child memcgs on too).
I think a child should be able to disable a swap tier enabled by the
parent, but not vice versa.
> 3. memory.zswap.max integrates naturally (it's memory."tier_name".max).
Not really. memory.zswap.max is in terms of memory usage (compressed
size), not swap usage (uncompressed size).
[..]
> Let me clarify a part I wrote confusingly. Handling
> memory.zswap.writeback via tiers is possible, but I don't think the
> interface itself would be replaced even if memory.swap.tiers is adopted.
>
> Selecting only zswap in memory.swap.tiers would not just disable
> writeback.it would also block regular swap entirely, which differs
> slightly from the current semantic. (... "Per the cgroup v2 docs: a
> zswap-only tier setting is subtly different from setting
> memory.swap.max to 0, since it still allows pages to be written to the
> zswap pool; this has no effect if zswap is disabled, and swapping is
> allowed unless memory.swap.max is set to 0.")
I don't understand. How is disabling zswap writeback not equivalent to
only enabling zswap as a tier?
Do you just mean the fact that disabling zswap writeback is a noop of
zswap is disabled? It's a different interface so I think a small
semantic difference is okay. In practice, I doubt that zswap is being
disabled at runtime.
>
> So the interface itself needs to be retained, and it could be extended
> toward selective writeback — e.g., passing a desired tier into
> memory.zswap.writeback so writeback targets only that tier. Currently
> it only controls on/off. Other tiers probably don't need this. demotion
> based on the selected tier should be enough.
>
> Thanks,
> Youngjun Park
>
On Sun, Jun 14, 2026 at 2:23 AM YoungJun Park <youngjun.park@lge.com> wrote:
>
> ....
> > >Based on the memcg interface currently proposed in swap_tier
> > > (memory.swap.tiers, memory.swap.tiers.effective), I think it aligns well
> > > with the current direction. It provides a foundation for selectively
> > > targeting devices in tier order.
> >
> > Here instead of cpuset like interface, we may want more zswap like interface
> > where you can put limit on the usage i.e. memory.swap.tier*.max. We can start
> > with allowing only two values i.e. 0 and max which effectively will be the
> > same as what you need.
> >
>
> Good idea, and it's certainly feasible. When I considered this a while
> ago, the reasons I didn't take this direction were:
>
> 1. There's no real-world usage for adjusting the swap tier amount (it's
> either 0 or MAX). That said, your suggestion to initially allow only
> 0 and max is the killing point, and it's making me reconsider.
>
> 2. The implementation cost seems high. The current implementation
> handles this at runtime via simple masking.
>
> 3. Relationship with swap.max:
> - If we tie it to the current interface, wouldn't limiting the swap
> amount within a selected tier already be possible? I wonder if
> that alone is enough.
> - If we add tier.max, it would need to be a subset of swap.max.
> (Any other complexities here?)
>
> 4. vswap enable/disable: vswap doesn't seem to have an amount-control
> aspect, so an on/off semantic would be clearer.
> https://lore.kernel.org/linux-mm/ai5kOOmR1LPTWs1J@yjaykim-PowerEdge-T330/T/#m8831ec057bf9387978d3bd698f51920600e09a04
>
> In that case, the internal logic could stay roughly the same rather
> than counting via a page counter. Something like:
>
> 1. Change the interface shell: tier.*.max — allow only 0 ~ max.
> 2. Keep the internal logic as is: 0 disables the mask (child memcgs
> off too), max enables it (child memcgs on too).
> 3. memory.zswap.max integrates naturally (it's memory."tier_name".max).
> 4. Extend later if use cases arise.
>
> On balance I still lean toward the current interface, but if a per-tier
> max is the better fit for memcg's direction and others feel the same,
> I'm happy to switch. I'd like to hear Shakeel's thoughts again, and I'm
> curious about others' opinions too.
>
> A few more perspectives on the points below.
>
> > I will respond to your other points later when I have time.
>
> > >
> > > To summarize the discussions so far, the following points align well.
> > >
> > > - Per-cgroup swap control, as I suggested.
> > > - Proactive zswap writeback (Hao's usecase)
> > > - Swap device target demotion(if it wants selective, then it is more better), as you mentioned:
> > > https://lore.kernel.org/linux-mm/aicZ-5GX9De3MAU7@linux.dev/
> > > - Virtual Swap on/off in the future, as Nhat mentioned:
> > > https://lore.kernel.org/linux-mm/20260528212955.1912856-1-nphamcs@gmail.com/
> > > - The memory.zswap.writeback alternative (no hierarchy model conflict)
> > > - zswap is first swap tier.
> > > - Promotion. (Also better for selectve usage)
> > > - tier based swap policy (e.g round-robin...)
> > >
> > > To accelerate this work, I believe we should reach a consensus and
> > > merge the currently proposed swap_tier interface :)
> > >
> > > If the above approach is difficult, I would like to suggest an
> > > alternative for progress with the memcg interfaces removed:
> > >
> > > 1) We could make zswap the first tier and create
> > > a use case where memory.zswap.writeback internally is handled by tier logic.
> > >
> > > 2) Or simply merge the swap_tier infrastructure itself first.
> > >
> > > This would allow the swap_tier infrastructure to be merged and discussed
> > > more easily.
> > >
> > > If it takes longer to adopt swap_tier anyway, by doing so we progress next step
> > > as a experimental feature.
> > >
> > > - Apply per-cgroup swap as an experimental (debugfs) feature.
> > > - Apply Hao's use case experimentally or as it is as Yosry suggested.
> > > (future migration to swap tier)
> > >
> > > How do you think?
> > >
> > > (FYI: My emails to kernel.org are failing due to internal server issues.)
> > >
> > > Thank you
> > > Youngjun Park
>
> Let me clarify a part I wrote confusingly. Handling
> memory.zswap.writeback via tiers is possible, but I don't think the
> interface itself would be replaced even if memory.swap.tiers is adopted.
>
> Selecting only zswap in memory.swap.tiers would not just disable
> writeback.it would also block regular swap entirely, which differs
> slightly from the current semantic. (... "Per the cgroup v2 docs: a
> zswap-only tier setting is subtly different from setting
> memory.swap.max to 0, since it still allows pages to be written to the
> zswap pool; this has no effect if zswap is disabled, and swapping is
> allowed unless memory.swap.max is set to 0.")
>
> So the interface itself needs to be retained, and it could be extended
> toward selective writeback — e.g., passing a desired tier into
> memory.zswap.writeback so writeback targets only that tier. Currently
> it only controls on/off. Other tiers probably don't need this. demotion
> based on the selected tier should be enough.
>
> Thanks,
> Youngjun Park
>
^ permalink raw reply
* Re: [PATCH v3 0/3] f2fs: support encrypted inline data
From: Eric Biggers @ 2026-06-15 19:37 UTC (permalink / raw)
To: LiaoYuanhong-vivo
Cc: Jaegeuk Kim, Chao Yu, Jonathan Corbet, Shuah Khan,
Theodore Y. Ts'o, open list:F2FS FILE SYSTEM, open list,
open list:DOCUMENTATION,
open list:FSCRYPT: FILE SYSTEM LEVEL ENCRYPTION SUPPORT,
linux-ext4
In-Reply-To: <20260615125517.362294-1-liaoyuanhong@vivo.com>
[+Cc linux-ext4@vger.kernel.org]
On Mon, Jun 15, 2026 at 08:55:12PM +0800, LiaoYuanhong-vivo wrote:
> F2FS currently disables inline data for encrypted regular files because the
> inline payload is stored in the inode block and does not go through the
> regular bio-based fscrypt path. This wastes space for small encrypted
> files on Android devices using F2FS inlinecrypt.
>
> This series adds an encrypted_inline_data on-disk feature for F2FS.
> With this feature enabled, encrypted regular files may keep small contents
> in the inode block. The inline payload is encrypted before being stored in
> the inode and decrypted back into page-cache plaintext on read.
>
> The fscrypt changes are scoped to filesystem-managed data-unit crypto.
> F2FS first asks fscrypt whether the inode's key/policy supports this path.
> It prepares the software transform only when encrypted inline payloads are
> read or written. Inlinecrypt support is limited to v2 IV_INO_LBLK_64 and
> IV_INO_LBLK_32 policies, including the hardware-wrapped key configurations
> supported by fscrypt. Per-file inlinecrypt keys and DIRECT_KEY policies
> are not supported for encrypted inline data.
I still think we should hold off on this, for the reasons I gave at
https://lore.kernel.org/r/20260515184124.GA4903@quark/
As soon as you start using hardware-wrapped keys this will become
irrelevant, as it can't be used in that case. I see you added "support"
for that case anyway by deriving contents encryption keys from the
sw_secret. But that bypasses the security model, which isn't okay.
I'm also working to simplify ext4 and f2fs's file contents encryption
implementation by standardizing on blk-crypto. That aligns well with
what btrfs encryption is going to do as well. So this isn't a great
time to be making f2fs's file contents encryption implementation even
more complex by going in a different direction.
If there was demand for this feature from the ext4 side for
general-purpose Linux distros as well, that would make it a bit more
appealing, as it would show broader demand. But with the proposal being
f2fs-specific and effectively just for Android devices that *don't* use
wrapped keys, that feels too narrow for the added complexity.
This proposal also lacks test cases in xfstests and/or Android's
vts_kernel_encryption_test that verify that the inline data is actually
being encrypted correctly. Those tests are essential, and we *must not*
add new file contents encryption implementations without such tests.
- Eric
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v12] ice: add support for unmanaged DPLL on E830 NIC
From: Mekala, SunithaX D @ 2026-06-15 18:14 UTC (permalink / raw)
To: Kubalewski, Arkadiusz, intel-wired-lan@lists.osuosl.org
Cc: pmenzel@molgen.mpg.de, linux-doc@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Kubalewski, Arkadiusz, Loktionov, Aleksandr, Nguyen, Anthony L,
Fodor, Zoltan, horms@kernel.org, Kitszel, Przemyslaw,
Grinberg, Vitaly
In-Reply-To: <20260508110856.550999-1-arkadiusz.kubalewski@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Arkadiusz Kubalewski
> Sent: Friday, May 8, 2026 4:09 AM
> To: intel-wired-lan@lists.osuosl.org
> Cc: pmenzel@molgen.mpg.de; linux-doc@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Fodor, Zoltan <zoltan.fodor@intel.com>; horms@kernel.org; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Grinberg, Vitaly <vgrinber@redhat.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v12] ice: add support for unmanaged DPLL on E830 NIC
>
> Hardware variants of E830 may support an unmanaged DPLL where the
> configuration is hardcoded within the hardware and firmware, meaning
> users cannot modify settings. However, users are able to check the DPLL
> lock status and obtain configuration information through the Linux DPLL
> and devlink health subsystem.
>
> Availability of 'loss of lock' health status code determines if such
> support is available, if true, register single DPLL device with 1 input
> and 1 output and provide hardcoded/read only properties of a pin and
> DPLL device. User is only allowed to check DPLL device status and receive
> notifications on DPLL lock status change.
>
> When present, the DPLL device locks to an external signal provided
> through the PCIe/OCP pin. The expected input signal is 1PPS
> (1 Pulse Per Second) embedded on a 10MHz reference clock.
> The DPLL produces output:
> - for MAC (Media Access Control) & PHY (Physical Layer) clocks,
> - 1PPS for synchronization of onboard PHC (Precision Hardware Clock) timer.
>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
> ---
> v12:
> - remove HAVE_DPLL_ESYNC ifdef
> - guard ice_dpll_lock_state_set_unmanaged() call in health event handler
> with test_bit(ICE_FLAG_DPLL, pf->flags) and pf->dplls.unmanaged
> - add NULL guards for first/second dpll in ice_dpll_deinit_direct_pins()
> - add comments explaining intentional continue in
> ice_dpll_init_info_direct_pins() for unmanaged pins
> v11:
> - rebase and fix conflicts
> ---
> .../device_drivers/ethernet/intel/ice.rst | 83 +++++
> .../net/ethernet/intel/ice/devlink/health.c | 6 +
> .../net/ethernet/intel/ice/ice_adminq_cmd.h | 12 +
> drivers/net/ethernet/intel/ice/ice_common.c | 136 ++++++++
> drivers/net/ethernet/intel/ice/ice_common.h | 8 +
> drivers/net/ethernet/intel/ice/ice_dpll.c | 314 ++++++++++++++++--
> drivers/net/ethernet/intel/ice/ice_dpll.h | 10 +
> drivers/net/ethernet/intel/ice/ice_main.c | 11 +-
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 46 +++
> drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 1 +
> 10 files changed, 604 insertions(+), 23 deletions(-)
Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* Re: [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option
From: Al Viro @ 2026-06-15 17:04 UTC (permalink / raw)
To: Vincent Mailhol
Cc: Jens Axboe, Davidlohr Bueso, Christian Brauner, Jan Kara,
linux-kernel, linux-block, linux-efi, linux-fsdevel,
Richard Henderson, Matt Turner, Magnus Lindholm, linux-alpha,
Vineet Gupta, linux-snps-arc, Russell King, linux-arm-kernel,
Catalin Marinas, Will Deacon, Huacai Chen, WANG Xuerui, loongarch,
Thomas Bogendoerfer, linux-mips, James E.J. Bottomley,
Helge Deller, linux-parisc, Madhavan Srinivasan, Michael Ellerman,
linuxppc-dev, Paul Walmsley, Palmer Dabbelt, Albert Ou,
linux-riscv, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
linux-s390, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
On Mon, Jun 15, 2026 at 06:08:56PM +0200, Vincent Mailhol wrote:
> Tested with GRUB, which implements the LoaderDevicePartUUID EFI variable
> in its bli module [3]. With this, I was able to boot a kernel with a
> completely empty cmdline and no initrd.
>
> [1] The Discoverable Partitions Specification (DPS)
> Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
>
> [2] systemd-gpt-auto-generator
> Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
>
> [3] GRUB -- §16.2 bli
> Link: https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html
So what does that thing, tied to EFI as it is, have to do with architectures where
* firmware is rather unlike EFI
* firmware wouldn't know what to do with GPT
* GRUB is *not* ported to, let alone used
such as, say it, the very first one mentioned at your [1]?
Or is that conditional upon "if anyone wants to design replacement firmware
for those, and if they agree to follow our wishlist"?
^ permalink raw reply
* Re: [PATCH net-next v7 11/12] net: pcs: airoha: add PCS driver for Airoha AN7581 SoC
From: Benjamin Larsson @ 2026-06-15 16:31 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-12-ansuelsmth@gmail.com>
Hi.
On 15/06/2026 14:29, Christian Marangi wrote:
> Add PCS driver for Airoha AN7581 SoC for Ethernet/PON/PCIe/USB SERDES
> and permit usage of external PHY or connected SFP cage. Supported modes
> are USXGMII, 10G-BASER, 2500BASE-X, 1000BASE-X and SGMII.
>
> The driver probe and register the various needed registers and register as
> a PCS provider for fwnode usage.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/pcs/Kconfig | 2 +
> drivers/net/pcs/Makefile | 2 +
> drivers/net/pcs/airoha/Kconfig | 12 +
> drivers/net/pcs/airoha/Makefile | 7 +
> drivers/net/pcs/airoha/pcs-airoha-common.c | 1318 ++++++++++++
> drivers/net/pcs/airoha/pcs-airoha.h | 1309 ++++++++++++
> drivers/net/pcs/airoha/pcs-an7581.c | 2093 ++++++++++++++++++++
> 7 files changed, 4743 insertions(+)
> create mode 100644 drivers/net/pcs/airoha/Kconfig
> create mode 100644 drivers/net/pcs/airoha/Makefile
> create mode 100644 drivers/net/pcs/airoha/pcs-airoha-common.c
> create mode 100644 drivers/net/pcs/airoha/pcs-airoha.h
> create mode 100644 drivers/net/pcs/airoha/pcs-an7581.c
Most likely there will be pcs drivers for the EN7523 platform also. Can
the common code for an7581 have an7581 in the name instead of airoha?
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [PATCH net-next] docs: exclude driver and netdevsim bugs
From: Jakub Kicinski @ 2026-06-15 16:19 UTC (permalink / raw)
To: Leon Romanovsky
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, johannes,
corbet, skhan, workflows, linux-doc
In-Reply-To: <20260615091436.GP327369@unreal>
On Mon, 15 Jun 2026 12:14:36 +0300 Leon Romanovsky wrote:
> > +Unless explicitly excluded all bug fixes should be targeting the ``net``
> > +tree and contain an appropriate Fixes tag.
> > +
> > +Obvious exclusions:
> > +
> > + - fixes for bugs which only exist in ``net-next`` should target ``net-next``
> > + (please still include the Fixes tag in the commit message)
> > + - bugs which cannot be reached, e.g. in code paths not executed given
> > + current in-tree callers
> > + - fixes for compiler warnings and typos
>
> If you decide to resubmit this patch, could you please remove "fixes for
> compiler warnings" from the exclusion list?
>
> It is quite frustrating to receive a compiler warning originating from a
> different subsystem after the merge window, knowing it will not be
> addressed until the next merge window (around eight weeks later).
Agreed, FWIW, but not planning to resubmit.
I think people misunderstood that I'm __documenting what I already do__
rather than trying to have a discussion :/
^ permalink raw reply
* [PATCH 19/19] docs: document discoverable root partitions
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
Document the automatic root block device discovery feature.
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
Documentation/admin-guide/discoverable-root.rst | 33 +++++++++++++++++++++++++
Documentation/admin-guide/index.rst | 1 +
Documentation/admin-guide/kernel-parameters.txt | 5 ++++
3 files changed, 39 insertions(+)
diff --git a/Documentation/admin-guide/discoverable-root.rst b/Documentation/admin-guide/discoverable-root.rst
new file mode 100644
index 000000000000..9645bf39e405
--- /dev/null
+++ b/Documentation/admin-guide/discoverable-root.rst
@@ -0,0 +1,33 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _discoverable_root:
+
+Discoverable root partitions
+============================
+
+On EFI systems using a supported architecture, the kernel can discover the root
+block device from GPT partition type UUID metadata on the disk containing the
+active EFI System Partition.
+
+This follows the `Discoverable Partitions Specification`_ which defines a list
+of architecture-specific root partition type UUIDs.
+
+Specifying ``root=`` on the kernel command line takes precedence and entirely
+disables this automatic root partition discovery.
+
+The disk to search is identified by the Boot Loader Interface
+``LoaderDevicePartUUID`` EFI variable. If multiple partitions on that disk match
+the architecture root partition type UUID, the kernel selects the first match in
+block device enumeration order. Systems should not expose multiple eligible root
+partitions unless that ordering is intended.
+
+Partitions marked with the DPS ``no-auto`` GPT attribute are skipped. This
+allows a partition with an otherwise discoverable type UUID to opt out from
+automatic discovery.
+
+The DPS read-only attribute is not enforced by kernel root discovery. The
+root filesystem is mounted read-only by default unless ``rw`` is specified,
+and user space remains responsible for later remount policy.
+
+.. _Discoverable Partitions Specification:
+ https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index cd28dfe91b06..0d9c2796ae09 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -50,6 +50,7 @@ Booting the kernel
bootconfig
kernel-parameters
+ discoverable-root
efi-stub
initrd
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f68bf1cdb53b..c9bfa010883c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6696,6 +6696,11 @@ Kernel parameters
ramdisk, "nfs" and "cifs" for root on a network file
system, or "mtd" and "ubi" for mounting from raw flash.
+ If this option is omitted, the kernel may try to
+ discover the root block device from the GPT partition
+ type UUID metadata when additional requirements are met.
+ See Documentation/admin-guide/discoverable-root.rst.
+
rootdelay= [KNL] Delay (in seconds) to pause before attempting to
mount the root filesystem
--
2.53.0
^ permalink raw reply related
* [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option
From: Vincent Mailhol @ 2026-06-15 16:08 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Richard Henderson, Matt Turner, Magnus Lindholm,
linux-alpha, Vineet Gupta, linux-snps-arc, Russell King,
linux-arm-kernel, Catalin Marinas, Will Deacon, Huacai Chen,
WANG Xuerui, loongarch, Thomas Bogendoerfer, linux-mips,
James E.J. Bottomley, Helge Deller, linux-parisc,
Madhavan Srinivasan, Michael Ellerman, linuxppc-dev,
Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev, linux-s390,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Jonathan Corbet, Shuah Khan, linux-doc
DPS [1] defines GPT partition type UUIDs for OS partitions and
attributes that control whether such partitions should be
automatically discovered. The specification states that:
The OS can discover and mount the necessary file systems with a
non-existent or incomplete /etc/fstab file and without the root=
kernel command line option.
DPS is already implemented in systemd-gpt-auto-generator [2], which,
when embedded in an initrd, indeed allows automatic detection of the
root filesystem through its partition type UUID.
This series adds this discovery feature directly into the kernel so
that people who are not using systemd or not using an initrd can still
benefit from it. The implementation follows the same model as
systemd-gpt-auto-generator:
- GPT partition type UUIDs are used for automatic discovery policy
only. No root=PARTTYPEUUID=xxx cmdline option or similar syntax is
added.
- The root= cmdline option takes precedence. This prevents unexpected
behaviour.
- Only the disk with the active EFI System Partition is scanned, as
required by DPS. The disk is identified through the Boot Loader
Interface LoaderDevicePartUUID EFI variable.
The DPS no-auto attribute is also implemented, giving another option for
the user to disable this auto discovery. However, the DPS read-only
attribute is intentionally not enforced. The kernel already mounts the
root filesystem read-only by default unless the command line requests
rw, and user space remains responsible for deciding whether a discovered
root should later be remounted read-write based on DPS metadata and
local policy. The other partition type UUIDs (home, swap, var...) are
also out of scope for the same reason: user space remains responsible
for mounting anything other than the root partition.
Patch 1 adds the ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID capability and
the hidden CONFIG_DPS_ROOT_AUTO_DISCOVERY Kconfig symbol used to signal
whether the feature is available. Patches 2 to 12 declare the
ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID capability for the supported
architectures and define their architecture-specific root partition type
UUID values in asm/dps_root.h.
Patches 13 to 16 make the GPT partition type UUID and the no-auto
attribute available during early block lookup.
Patch 17 is a small code refactor that prepares for patch 18, which
updates the root mount path so that, when root= is omitted, the kernel
reads LoaderDevicePartUUID and uses the early block lookup
infrastructure to discover the DPS root partition on that disk.
Finally, patch 19 documents this automatic root discovery feature.
Tested with GRUB, which implements the LoaderDevicePartUUID EFI variable
in its bli module [3]. With this, I was able to boot a kernel with a
completely empty cmdline and no initrd.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
[2] systemd-gpt-auto-generator
Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
[3] GRUB -- §16.2 bli
Link: https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
Vincent Mailhol (19):
init: add DPS root partition type UUID capability
alpha: define DPS root partition type UUID
arc: define DPS root partition type UUID
arm: define DPS root partition type UUID
arm64: define DPS root partition type UUID
loongarch: define DPS root partition type UUID
mips: define DPS root partition type UUIDs
parisc: define DPS root partition type UUID
powerpc: define DPS root partition type UUIDs
riscv: define DPS root partition type UUIDs
s390: define DPS root partition type UUIDs
x86: define DPS root partition type UUIDs
block: store GPT partition type UUID
block: add early_lookup_bdev_by_type_uuid()
block: store GPT attributes as a raw value
block: don't discover partition with DPS no-auto GPT attribute
init: factor out root device lookup into lookup_root_device()
init: discover root by DPS partition type UUID
docs: document discoverable root partitions
Documentation/admin-guide/discoverable-root.rst | 33 +++++++++
Documentation/admin-guide/index.rst | 1 +
Documentation/admin-guide/kernel-parameters.txt | 5 ++
arch/alpha/Kconfig | 1 +
arch/alpha/include/asm/dps_root.h | 8 +++
arch/arc/Kconfig | 1 +
arch/arc/include/asm/dps_root.h | 8 +++
arch/arm/Kconfig | 1 +
arch/arm/include/asm/dps_root.h | 8 +++
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dps_root.h | 8 +++
arch/loongarch/Kconfig | 1 +
arch/loongarch/include/asm/dps_root.h | 8 +++
arch/mips/Kconfig | 1 +
arch/mips/include/asm/dps_root.h | 20 ++++++
arch/parisc/Kconfig | 1 +
arch/parisc/include/asm/dps_root.h | 8 +++
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/dps_root.h | 16 +++++
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/dps_root.h | 12 ++++
arch/s390/Kconfig | 1 +
arch/s390/include/asm/dps_root.h | 12 ++++
arch/x86/Kconfig | 1 +
arch/x86/include/asm/dps_root.h | 12 ++++
block/blk.h | 1 +
block/early-lookup.c | 68 +++++++++++++++++-
block/partitions/core.c | 2 +
block/partitions/efi.c | 3 +
block/partitions/efi.h | 11 ++-
include/linux/blk_types.h | 1 +
include/linux/blkdev.h | 5 ++
include/linux/root_dev.h | 6 ++
init/Kconfig | 6 ++
init/do_mounts.c | 94 ++++++++++++++++++++++++-
35 files changed, 355 insertions(+), 12 deletions(-)
---
base-commit: 36808d5e983985bbda87e01059cccc071fe3ec8d
change-id: 20260611-discoverable-root_partitions-bdacbada570d
Best regards,
--
Vincent Mailhol <mailhol@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next v7 12/12] net: airoha: add phylink support
From: Benjamin Larsson @ 2026-06-15 16:07 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-13-ansuelsmth@gmail.com>
Hi.
On 15/06/2026 14:29, Christian Marangi wrote:
> Add phylink support for each GDM port. For GDM1 add the internal interface
> mode as the only supported mode. For GDM2/3/4 add the required
> configuration of the PCS to make the external PHY or attached SFP cage
> work.
>
> These needs to be defined in the GDM port node using the pcs-handle
> property.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/ethernet/airoha/Kconfig | 1 +
> drivers/net/ethernet/airoha/airoha_eth.c | 161 +++++++++++++++++++++-
> drivers/net/ethernet/airoha/airoha_eth.h | 3 +
> drivers/net/ethernet/airoha/airoha_regs.h | 12 ++
> 4 files changed, 176 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/Kconfig b/drivers/net/ethernet/airoha/Kconfig
> index ad3ce501e7a5..38dcc76e5998 100644
> --- a/drivers/net/ethernet/airoha/Kconfig
> +++ b/drivers/net/ethernet/airoha/Kconfig
> @@ -20,6 +20,7 @@ config NET_AIROHA
> depends on NET_DSA || !NET_DSA
> select NET_AIROHA_NPU
> select PAGE_POOL
> + select PHYLINK
> help
> This driver supports the gigabit ethernet MACs in the
> Airoha SoC family.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 5f1a118875fb..9a42fb991bd7 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -8,6 +8,7 @@
> #include <linux/of_reserved_mem.h>
> #include <linux/platform_device.h>
> #include <linux/tcp.h>
> +#include <linux/pcs/pcs.h>
> #include <linux/u64_stats_sync.h>
> #include <net/dst_metadata.h>
> #include <net/page_pool/helpers.h>
> @@ -1810,6 +1811,14 @@ static int airoha_dev_open(struct net_device *netdev)
> u32 cur_len, pse_port = FE_PSE_PORT_PPE1;
> struct airoha_qdma *qdma = dev->qdma;
>
> + err = phylink_of_phy_connect(dev->phylink, netdev->dev.of_node, 0);
> + if (err) {
> + netdev_err(netdev, "could not attach PHY: %d\n", err);
> + return err;
> + }
> +
> + phylink_start(dev->phylink);
> +
> netif_tx_start_all_queues(netdev);
> err = airoha_set_vip_for_gdm_port(dev, true);
> if (err)
> @@ -1907,6 +1916,9 @@ static int airoha_dev_stop(struct net_device *netdev)
> }
> }
>
> + phylink_stop(dev->phylink);
> + phylink_disconnect_phy(dev->phylink);
> +
> return 0;
> }
>
> @@ -3168,6 +3180,151 @@ bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> return false;
> }
>
> +/* Nothing to do in MAC, everything is handled in PCS */
> +static void airoha_mac_config(struct phylink_config *config, unsigned int mode,
> + const struct phylink_link_state *state)
> +{
> +}
> +
> +static void airoha_mac_link_up(struct phylink_config *config, struct phy_device *phy,
> + unsigned int mode, phy_interface_t interface,
> + int speed, int duplex, bool tx_pause, bool rx_pause)
> +{
> + struct airoha_gdm_dev *dev = container_of(config, struct airoha_gdm_dev,
> + phylink_config);
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> + u32 frag_size_tx, frag_size_rx;
> + u32 mask, val;
> +
> + /* TX/RX frag is configured only for GDM4 */
> + if (port->id != AIROHA_GDM4_IDX)
> + return;
> +
> + switch (speed) {
> + case SPEED_10000:
> + case SPEED_5000:
> + frag_size_tx = 8;
> + frag_size_rx = 8;
> + break;
> + case SPEED_2500:
> + frag_size_tx = 2;
> + frag_size_rx = 1;
> + break;
> + default:
> + frag_size_tx = 1;
> + frag_size_rx = 0;
> + }
> +
> + /* Configure TX/RX frag based on speed */
> + if (dev->nbq == 1) {
> + mask = GDMA4_SGMII1_TX_FRAG_SIZE_MASK;
Can the naming be consistently GDM4 without the A?
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [RFC V2 3/3] mm: Replace pgtable entry prints with new format
From: David Hildenbrand (Arm) @ 2026-06-15 16:01 UTC (permalink / raw)
To: Hugh Dickins
Cc: Anshuman Khandual, linux-mm, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Petr Mladek, Steven Rostedt, Jonathan Corbet,
Andrew Morton, linux-kernel, linux-doc, Lorenzo Stoakes
In-Reply-To: <4a416383-62f5-1716-8e04-a2ee1f89a864@google.com>
On 6/12/26 23:26, Hugh Dickins wrote:
> On Fri, 12 Jun 2026, David Hildenbrand (Arm) wrote:
> ...
>>
>> After some off-list discussion, I wonder if we can make our life easier.
>>
>> I think, even with your patch, there is still the case:
>>
>> pr_alert("BUG: Bad page map in process %s %s:%08llx", current->comm,
>> pgtable_level_to_str(level), entry);
>>
>> Where we cast all entries to an "unsigned long" in the callers. We'd have to rework all
>> that for 128bit entries either way (passing them in some struct instead).
>>
>> I really just extended what we used to do here in print_bad_pte() before commit ec63a44011d.
>>
>> Maybe we should just drop the "print the involved page table entries" thing?
>>
>> I mean, we do have the actual page, and we do have the address in the address space, which
>> we all print.
>>
>> Not sure if the actual page table entries are that relevant?
>
> The page table entry is BUGgily Bad: we want to see what it looks like
> (sometimes, a sequence of bad page map entries may even show up as ASCII).
But is printing raw page table entries really what we want? I guess to detect
"random corruption" it might help sometimes.
And do we really need information about the full page table walk, or is the last
level good enough?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Fix regex for kdoc
From: Randy Dunlap @ 2026-06-15 15:56 UTC (permalink / raw)
To: Matthew Wilcox (Oracle), Jonathan Corbet
Cc: Mauro Carvalho Chehab, Shuah Khan, linux-doc
In-Reply-To: <20260615154057.2156589-1-willy@infradead.org>
On 6/15/26 8:40 AM, Matthew Wilcox (Oracle) wrote:
> The trailing '*' means "all files in this directory, but not
> subdirectories" which excluded tools/lib/python/kdoc/. This is surely
> not intended.
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0d94420eae3d..999957a3e0ca 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7653,7 +7653,7 @@ S: Maintained
> P: Documentation/doc-guide/maintainer-profile.rst
> T: git git://git.lwn.net/linux.git docs-next
> F: Documentation/
> -F: tools/lib/python/*
> +F: tools/lib/python/
> F: tools/docs/
> F: tools/net/ynl/pyynl/lib/doc_generator.py
> X: Documentation/ABI/
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
--
~Randy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox