| Message ID | 20210121082155.111333-1-ebiggers@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Resource-managed blk_ksm_init() | expand |
+ Jens, Martin, James On Thu, 21 Jan 2021 at 09:23, Eric Biggers <ebiggers@kernel.org> wrote: > > This patchset adds a resource-managed variant of blk_ksm_init() so that > drivers don't have to worry about calling blk_ksm_destroy(). > > This was suggested during review of my patchset which adds eMMC inline > encryption support > (https://lkml.kernel.org/linux-mmc/20210104184542.4616-1-ebiggers@kernel.org/T/#u). > That patchset proposes a second caller of blk_ksm_init(). But it can > instead use the resource-managed variant, as can the UFS driver. > > My preference is that patch #1 be taken through the MMC tree together > with my MMC patchset, so that we don't have to wait an extra cycle for > the MMC changes. Patch #2 can then go in later. Sure, I can pick patch #1 through my mmc tree, but need an ack from Jens to do it. Or whatever he prefers. Another solution is to host immutable branches (if needed), so they can be shared between our tree's, that works for me as well. > > Eric Biggers (2): > block/keyslot-manager: introduce devm_blk_ksm_init() > scsi: ufs: use devm_blk_ksm_init() > > Documentation/block/inline-encryption.rst | 12 +++++----- > block/keyslot-manager.c | 29 +++++++++++++++++++++++ > drivers/scsi/ufs/ufshcd-crypto.c | 9 ++----- > drivers/scsi/ufs/ufshcd-crypto.h | 5 ---- > drivers/scsi/ufs/ufshcd.c | 1 - > include/linux/keyslot-manager.h | 3 +++ > 6 files changed, 40 insertions(+), 19 deletions(-) > > -- > 2.30.0 > Kind regards Uffe
On 1/21/21 5:50 AM, Ulf Hansson wrote: > + Jens, Martin, James > > > On Thu, 21 Jan 2021 at 09:23, Eric Biggers <ebiggers@kernel.org> wrote: >> >> This patchset adds a resource-managed variant of blk_ksm_init() so that >> drivers don't have to worry about calling blk_ksm_destroy(). >> >> This was suggested during review of my patchset which adds eMMC inline >> encryption support >> (https://lkml.kernel.org/linux-mmc/20210104184542.4616-1-ebiggers@kernel.org/T/#u). >> That patchset proposes a second caller of blk_ksm_init(). But it can >> instead use the resource-managed variant, as can the UFS driver. >> >> My preference is that patch #1 be taken through the MMC tree together >> with my MMC patchset, so that we don't have to wait an extra cycle for >> the MMC changes. Patch #2 can then go in later. > > Sure, I can pick patch #1 through my mmc tree, but need an ack from > Jens to do it. Or whatever he prefers. Or we can take it through the block tree, usually the easiest as it's the most likely source of potential conflicts. And that's true for both of them, as long as the SCSI side signs off on patch 2/2.
On Mon, Jan 25, 2021 at 02:14:32PM -0700, Jens Axboe wrote: > On 1/21/21 5:50 AM, Ulf Hansson wrote: > > + Jens, Martin, James > > > > > > On Thu, 21 Jan 2021 at 09:23, Eric Biggers <ebiggers@kernel.org> wrote: > >> > >> This patchset adds a resource-managed variant of blk_ksm_init() so that > >> drivers don't have to worry about calling blk_ksm_destroy(). > >> > >> This was suggested during review of my patchset which adds eMMC inline > >> encryption support > >> (https://lkml.kernel.org/linux-mmc/20210104184542.4616-1-ebiggers@kernel.org/T/#u). > >> That patchset proposes a second caller of blk_ksm_init(). But it can > >> instead use the resource-managed variant, as can the UFS driver. > >> > >> My preference is that patch #1 be taken through the MMC tree together > >> with my MMC patchset, so that we don't have to wait an extra cycle for > >> the MMC changes. Patch #2 can then go in later. > > > > Sure, I can pick patch #1 through my mmc tree, but need an ack from > > Jens to do it. Or whatever he prefers. > > Or we can take it through the block tree, usually the easiest as > it's the most likely source of potential conflicts. And that's true > for both of them, as long as the SCSI side signs off on patch 2/2. > As I mentioned, the issue is that my patchset to add eMMC inline encryption support (https://lkml.kernel.org/r/20210121090140.326380-1-ebiggers@kernel.org) depends on devm_blk_ksm_init(), as it was requested during review. So if devm_blk_ksm_init() goes in through the block tree, Ulf won't be able to take the eMMC patchset for 5.12. - Eric
On 1/25/21 2:21 PM, Eric Biggers wrote: > On Mon, Jan 25, 2021 at 02:14:32PM -0700, Jens Axboe wrote: >> On 1/21/21 5:50 AM, Ulf Hansson wrote: >>> + Jens, Martin, James >>> >>> >>> On Thu, 21 Jan 2021 at 09:23, Eric Biggers <ebiggers@kernel.org> wrote: >>>> >>>> This patchset adds a resource-managed variant of blk_ksm_init() so that >>>> drivers don't have to worry about calling blk_ksm_destroy(). >>>> >>>> This was suggested during review of my patchset which adds eMMC inline >>>> encryption support >>>> (https://lkml.kernel.org/linux-mmc/20210104184542.4616-1-ebiggers@kernel.org/T/#u). >>>> That patchset proposes a second caller of blk_ksm_init(). But it can >>>> instead use the resource-managed variant, as can the UFS driver. >>>> >>>> My preference is that patch #1 be taken through the MMC tree together >>>> with my MMC patchset, so that we don't have to wait an extra cycle for >>>> the MMC changes. Patch #2 can then go in later. >>> >>> Sure, I can pick patch #1 through my mmc tree, but need an ack from >>> Jens to do it. Or whatever he prefers. >> >> Or we can take it through the block tree, usually the easiest as >> it's the most likely source of potential conflicts. And that's true >> for both of them, as long as the SCSI side signs off on patch 2/2. >> > > As I mentioned, the issue is that my patchset to add eMMC inline encryption > support (https://lkml.kernel.org/r/20210121090140.326380-1-ebiggers@kernel.org) > depends on devm_blk_ksm_init(), as it was requested during review. > > So if devm_blk_ksm_init() goes in through the block tree, Ulf won't be able to > take the eMMC patchset for 5.12. Well he could, such cross tree dependencies are not hard to solve. But as mentioned in the other email, for this one, just queued it up yourself. You can add my acked-by to it.