[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPDyKFo+05WHAVQqbrL4L-ugDjyCosTSY6yensE0J8SMQ1xGAw@mail.gmail.com>
Date: Mon, 15 May 2023 15:29:01 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Christian Löhle <CLoehle@...erstone.com>
Cc: Adrian Hunter <adrian.hunter@...el.com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Avri Altman <avri.altman@....com>
Subject: Re: [PATCH 1/3] mmc: block: ioctl: define rpmb reliable flag
On Wed, 5 Apr 2023 at 13:57, Christian Löhle <CLoehle@...erstone.com> wrote:
>
> Give a proper name to BIT 31 which is used as reliable write
> for RPMB.
>
> Signed-off-by: Christian Loehle <cloehle@...erstone.com>
> ---
> drivers/mmc/core/block.c | 5 ++++-
> include/uapi/linux/mmc/ioctl.h | 1 +
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index 672ab90c4b2d..16e262ddc954 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -49,6 +49,8 @@
>
> #include <linux/uaccess.h>
>
> +#include <uapi/linux/mmc/ioctl.h>
> +
> #include "queue.h"
> #include "block.h"
> #include "core.h"
> @@ -538,7 +540,8 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md,
> * may be increased by a future standard. We just copy the
> * 'Reliable Write' bit here.
> */
> - sbc.arg = data.blocks | (idata->ic.write_flag & BIT(31));
> + sbc.arg = data.blocks |
> + (idata->ic.write_flag & MMC_RPMB_RELIABLE_WRITE);
> sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
> mrq.sbc = &sbc;
> }
> diff --git a/include/uapi/linux/mmc/ioctl.h b/include/uapi/linux/mmc/ioctl.h
> index e7401ade6822..b2ff7f5be87b 100644
> --- a/include/uapi/linux/mmc/ioctl.h
> +++ b/include/uapi/linux/mmc/ioctl.h
> @@ -11,6 +11,7 @@ struct mmc_ioc_cmd {
> * Bit 31 selects 'Reliable Write' for RPMB.
> */
> int write_flag;
> +#define MMC_RPMB_RELIABLE_WRITE (1 << 31)
I am not sure this is really worth it. Keeping kernel headers for user
space in sync is a bit messy.
The define as such seems reasonable, but isn't it better to have the
define at two places then? One that's part of the MMC subsystem in the
kernel and another that's specific to the mmc-utils userspace tool?
[...]
Kind regards
Uffe
Powered by blists - more mailing lists