From: Christoph Hellwig <hch@infradead.org> To: Satya Tangirala <satyat@google.com> Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Barani Muthukumaran <bmuthuku@qti.qualcomm.com>, Kuohong Wang <kuohong.wang@mediatek.com>, Kim Boojin <boojin.kim@samsung.com> Subject: Re: [PATCH v5 6/9] scsi: ufs: Add inline encryption support to UFS Date: Thu, 31 Oct 2019 11:26:29 -0700 [thread overview] Message-ID: <20191031182629.GE23601@infradead.org> (raw) In-Reply-To: <20191028072032.6911-7-satyat@google.com> > /* Transfer request descriptor header fields */ > + if (lrbp->crypto_enable) { Maybe we want a little inline function so that we can use IS_ENABLED to make sure the compiler eliminates the dead code if crypt config option is not set. a) don't have to define the crypto_enable if the config options are not set > + dword_0 |= UTP_REQ_DESC_CRYPTO_ENABLE_CMD; > + dword_0 |= lrbp->crypto_key_slot; > + req_desc->header.dword_1 = > + cpu_to_le32((u32)lrbp->data_unit_num); > + req_desc->header.dword_3 = > + cpu_to_le32((u32)(lrbp->data_unit_num >> 32)); This should use ther upper_32_bits / lower_32_bits helpers. > +static inline int ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba, > + struct scsi_cmnd *cmd, > + struct ufshcd_lrb *lrbp) > +{ > + int key_slot; > + > + if (!cmd->request->bio || > + !bio_crypt_should_process(cmd->request->bio, cmd->request->q)) { > + lrbp->crypto_enable = false; > + return 0; > + } > + > + if (WARN_ON(!ufshcd_is_crypto_enabled(hba))) { > + /* > + * Upper layer asked us to do inline encryption > + * but that isn't enabled, so we fail this request. > + */ > + return -EINVAL; > + } > + key_slot = bio_crypt_get_keyslot(cmd->request->bio); > + if (!ufshcd_keyslot_valid(hba, key_slot)) > + return -EINVAL; > + > + lrbp->crypto_enable = true; > + lrbp->crypto_key_slot = key_slot; > + lrbp->data_unit_num = bio_crypt_data_unit_num(cmd->request->bio); > + > + return 0; I think this should go into ufshcd-crypto.c so that it can be stubbed out for non-crypto builds. That also means we can remove various stubs for the block layer helpers and just dereference the fields directly, helping with code readability.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org> To: Satya Tangirala <satyat@google.com> Cc: linux-scsi@vger.kernel.org, Kim Boojin <boojin.kim@samsung.com>, Kuohong Wang <kuohong.wang@mediatek.com>, Barani Muthukumaran <bmuthuku@qti.qualcomm.com>, linux-f2fs-devel@lists.sourceforge.net, linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [f2fs-dev] [PATCH v5 6/9] scsi: ufs: Add inline encryption support to UFS Date: Thu, 31 Oct 2019 11:26:29 -0700 [thread overview] Message-ID: <20191031182629.GE23601@infradead.org> (raw) In-Reply-To: <20191028072032.6911-7-satyat@google.com> > /* Transfer request descriptor header fields */ > + if (lrbp->crypto_enable) { Maybe we want a little inline function so that we can use IS_ENABLED to make sure the compiler eliminates the dead code if crypt config option is not set. a) don't have to define the crypto_enable if the config options are not set > + dword_0 |= UTP_REQ_DESC_CRYPTO_ENABLE_CMD; > + dword_0 |= lrbp->crypto_key_slot; > + req_desc->header.dword_1 = > + cpu_to_le32((u32)lrbp->data_unit_num); > + req_desc->header.dword_3 = > + cpu_to_le32((u32)(lrbp->data_unit_num >> 32)); This should use ther upper_32_bits / lower_32_bits helpers. > +static inline int ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba, > + struct scsi_cmnd *cmd, > + struct ufshcd_lrb *lrbp) > +{ > + int key_slot; > + > + if (!cmd->request->bio || > + !bio_crypt_should_process(cmd->request->bio, cmd->request->q)) { > + lrbp->crypto_enable = false; > + return 0; > + } > + > + if (WARN_ON(!ufshcd_is_crypto_enabled(hba))) { > + /* > + * Upper layer asked us to do inline encryption > + * but that isn't enabled, so we fail this request. > + */ > + return -EINVAL; > + } > + key_slot = bio_crypt_get_keyslot(cmd->request->bio); > + if (!ufshcd_keyslot_valid(hba, key_slot)) > + return -EINVAL; > + > + lrbp->crypto_enable = true; > + lrbp->crypto_key_slot = key_slot; > + lrbp->data_unit_num = bio_crypt_data_unit_num(cmd->request->bio); > + > + return 0; I think this should go into ufshcd-crypto.c so that it can be stubbed out for non-crypto builds. That also means we can remove various stubs for the block layer helpers and just dereference the fields directly, helping with code readability. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2019-10-31 18:26 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-28 7:20 [PATCH v5 0/9] Inline Encryption Support Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-28 7:20 ` [PATCH v5 1/9] block: Keyslot Manager for Inline Encryption Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 18:04 ` Christoph Hellwig 2019-10-31 18:04 ` [f2fs-dev] " Christoph Hellwig 2019-10-28 7:20 ` [PATCH v5 2/9] block: Add encryption context to struct bio Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 18:16 ` Christoph Hellwig 2019-10-31 18:16 ` [f2fs-dev] " Christoph Hellwig 2019-10-28 7:20 ` [PATCH v5 3/9] block: blk-crypto for Inline Encryption Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 17:57 ` Christoph Hellwig 2019-10-31 17:57 ` [f2fs-dev] " Christoph Hellwig 2019-10-31 20:50 ` Theodore Y. Ts'o 2019-10-31 20:50 ` [f2fs-dev] " Theodore Y. Ts'o 2019-10-31 21:22 ` Christoph Hellwig 2019-10-31 21:22 ` [f2fs-dev] " Christoph Hellwig 2019-11-05 2:01 ` Eric Biggers 2019-11-05 2:01 ` [f2fs-dev] " Eric Biggers 2019-11-05 15:39 ` Christoph Hellwig 2019-11-05 15:39 ` [f2fs-dev] " Christoph Hellwig 2019-10-28 7:20 ` [PATCH v5 4/9] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-28 7:20 ` [PATCH v5 5/9] scsi: ufs: UFS crypto API Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 18:23 ` Christoph Hellwig 2019-10-31 18:23 ` [f2fs-dev] " Christoph Hellwig 2019-10-28 7:20 ` [PATCH v5 6/9] scsi: ufs: Add inline encryption support to UFS Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 18:26 ` Christoph Hellwig [this message] 2019-10-31 18:26 ` Christoph Hellwig 2019-10-28 7:20 ` [PATCH v5 7/9] fscrypt: add inline encryption support Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 18:32 ` Christoph Hellwig 2019-10-31 18:32 ` [f2fs-dev] " Christoph Hellwig 2019-10-31 20:21 ` Eric Biggers 2019-10-31 20:21 ` [f2fs-dev] " Eric Biggers 2019-10-31 21:21 ` Christoph Hellwig 2019-10-31 21:21 ` [f2fs-dev] " Christoph Hellwig 2019-10-31 22:25 ` Eric Biggers 2019-10-31 22:25 ` [f2fs-dev] " Eric Biggers 2019-11-05 0:15 ` Christoph Hellwig 2019-11-05 0:15 ` [f2fs-dev] " Christoph Hellwig 2019-11-05 1:03 ` Eric Biggers 2019-11-05 1:03 ` [f2fs-dev] " Eric Biggers 2019-11-05 3:12 ` Eric Biggers 2019-11-05 3:12 ` [f2fs-dev] " Eric Biggers 2019-10-28 7:20 ` [PATCH v5 8/9] f2fs: " Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel 2019-10-31 17:14 ` Jaegeuk Kim 2019-10-31 17:14 ` [f2fs-dev] " Jaegeuk Kim 2019-10-28 7:20 ` [PATCH v5 9/9] ext4: " Satya Tangirala 2019-10-28 7:20 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
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=20191031182629.GE23601@infradead.org \ --to=hch@infradead.org \ --cc=bmuthuku@qti.qualcomm.com \ --cc=boojin.kim@samsung.com \ --cc=kuohong.wang@mediatek.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-f2fs-devel@lists.sourceforge.net \ --cc=linux-fscrypt@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=satyat@google.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.