From: Leon Romanovsky <leon@kernel.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Alex Williamson <alex@shazbot.org>,
Keith Busch <kbusch@kernel.org>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvme@lists.infradead.org,
Chaitanya Kulkarni <kch@nvidia.com>
Subject: Re: [PATCH v3 0/2] block: Generalize physical entry definition
Date: Sun, 18 Jan 2026 10:01:09 +0200 [thread overview]
Message-ID: <20260118080109.GA14182@unreal> (raw)
In-Reply-To: <20260114133241.5b876b40@shazbot.org>
On Wed, Jan 14, 2026 at 01:32:41PM -0700, Alex Williamson wrote:
> On Tue, 06 Jan 2026 19:10:46 -0700
> Jens Axboe <axboe@kernel.dk> wrote:
>
> > On Wed, 17 Dec 2025 11:41:22 +0200, Leon Romanovsky wrote:
> > > Jens,
> > >
> > > I would like to ask you to put these patches on some shared branch based
> > > on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
> > > and DMABUF code.
> > >
> > > --------------------------------------------------------------------------------
> > > Changelog:
> > > v3:
> > > * Rebased on top v6.19-rc1
> > > * Added note that memory size is not changed despite change in the
> > > variable type.
> > > v2: https://lore.kernel.org/linux-nvme/20251117-nvme-phys-types-v2-0-c75a60a2c468@nvidia.com/
> > > * Added Chaitanya's Reviewed-by tags.
> > > * Removed explicit casting from size_t to unsigned int.
> > > v1: https://patch.msgid.link/20251115-nvme-phys-types-v1-0-c0f2e5e9163d@kernel.org
> > >
> > > [...]
> >
> > Applied, thanks!
> >
> > [1/2] nvme-pci: Use size_t for length fields to handle larger sizes
> > commit: 073b9bf9af463d32555c5ebaf7e28c3a44c715d0
> > [2/2] types: move phys_vec definition to common header
> > commit: fcf463b92a08686d1aeb1e66674a72eb7a8bfb9b
>
> Hi Jens,
>
> I see this is currently on your for-7.0/blk-pvec branch, thanks for
> splitting it out. I haven't seen this merged into your for-next branch
> though, which gives me some pause merging it for a dependent series
> from Leon. Is there anything blocking that merge? Thanks,
Jens,
Could you please merge the for-7.0/blk-pvec branch into your block/for-next
tree? The VFIO changes depend on the blk-pvec branch, and the RDMA changes
are based on the VFIO updates.
Thanks
>
> Alex
next prev parent reply other threads:[~2026-01-18 8:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-17 9:41 [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
2025-12-17 9:41 ` [PATCH v3 1/2] nvme-pci: Use size_t for length fields to handle larger sizes Leon Romanovsky
2025-12-17 9:41 ` [PATCH v3 2/2] types: move phys_vec definition to common header Leon Romanovsky
2026-01-04 15:15 ` [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
2026-01-06 12:46 ` Jens Axboe
2026-01-07 2:13 ` Jens Axboe
2026-01-07 7:54 ` Leon Romanovsky
2026-01-07 8:29 ` Keith Busch
2026-01-07 15:14 ` Jens Axboe
2026-01-07 15:36 ` Christoph Hellwig
2026-01-07 2:10 ` Jens Axboe
2026-01-14 20:32 ` Alex Williamson
2026-01-18 8:01 ` Leon Romanovsky [this message]
2026-01-18 13:28 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260118080109.GA14182@unreal \
--to=leon@kernel.org \
--cc=alex@shazbot.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox