mmc: Add config_host callback to set a mmc queue

Commit Message

Jangsub Yi Nov. 6, 2024, 5:13 a.m. UTC

From: "jangsub.yi" <[e-mail]>

Currently, there is no way to set up a host-dependent MMC queue.
In UFS driver, it is possible to configure the request queue in
ufshcd_slave_configure.

There are cases where we need to configure and check the current
state of the request queue on the host operation. For example,
mmc_queue->in_recovery, in_flight, mmc_queue->queue->queue_flag, etc.

Additionally, since the timeout setting may be longer depending
on the device, block layer settings such as timeout are also required.

To add the configuration for the MMC queue, I will add the corresponding
code and initially try to add it during initialization in block.c.
The detailed implementation will be done on the host side.

Signed-off-by: jangsub.yi <[e-mail]>
---
 drivers/mmc/core/block.c | 3 +++
 include/linux/mmc/host.h | 5 +++++
 2 files changed, 8 insertions(+)

Comments

Christoph Hellwig Nov. 7, 2024, 6:30 a.m. UTC | #1

On Wed, Nov 06, 2024 at 02:13:47PM +0900, Jangsub Yi wrote:
> From: "jangsub.yi" <[e-mail]>
> 
> Currently, there is no way to set up a host-dependent MMC queue.
> In UFS driver, it is possible to configure the request queue in
> ufshcd_slave_configure.
> 
> There are cases where we need to configure and check the current
> state of the request queue on the host operation. For example,
> mmc_queue->in_recovery, in_flight, mmc_queue->queue->queue_flag, etc.
> 
> Additionally, since the timeout setting may be longer depending
> on the device, block layer settings such as timeout are also required.
> 
> To add the configuration for the MMC queue, I will add the corresponding
> code and initially try to add it during initialization in block.c.
> The detailed implementation will be done on the host side.

This seems to lack an actual user and thus just creates dead code.

Jangsub Yi Nov. 7, 2024, 9:06 a.m. UTC | #2

> On Wed, Nov 06, 2024 at 02:13:47PM +0900, Jangsub Yi wrote:
> > From: "jangsub.yi" <[e-mail]>
> >
> > Currently, there is no way to set up a host-dependent MMC queue.
> > In UFS driver, it is possible to configure the request queue in
> > ufshcd_slave_configure.
> >
> > There are cases where we need to configure and check the current state
> > of the request queue on the host operation. For example,
> > mmc_queue->in_recovery, in_flight, mmc_queue->queue->queue_flag, etc.
> >
> > Additionally, since the timeout setting may be longer depending on the
> > device, block layer settings such as timeout are also required.
> >
> > To add the configuration for the MMC queue, I will add the
> > corresponding code and initially try to add it during initialization in
> block.c.
> > The detailed implementation will be done on the host side.
> 
> This seems to lack an actual user and thus just creates dead code.
> 
Currently, there is no way to configure a request queue on the host side.
Although there are various exported symbols in kernel/block/blk-settings.c
that can be used to configure a request queue, users cannot utilize them
as needed.
 For example, I want to change the timeout setting by calling 
blk_queue_rq_timeout(). Because 60 seconds is too long depending
on the device. Therefore, we need a method for independent configuration
for each host.

Christoph Hellwig Nov. 7, 2024, 3:11 p.m. UTC | #3

On Thu, Nov 07, 2024 at 06:06:11PM +0900, ??? wrote:
> Currently, there is no way to configure a request queue on the host side.
> Although there are various exported symbols in kernel/block/blk-settings.c
> that can be used to configure a request queue, users cannot utilize them
> as needed.

If you actually provided a user and didn't just try to offend the kernel
maintainers by submitting dead code I could explain you in detail why
youre idea is flawed.

Jangsub Yi Nov. 11, 2024, 8:06 a.m. UTC | #4

> On Thu, Nov 07, 2024 at 06:06:11PM +0900, ??? wrote:
> > Currently, there is no way to configure a request queue on the host
side.
> > Although there are various exported symbols in
> > kernel/block/blk-settings.c that can be used to configure a request
> > queue, users cannot utilize them as needed.
> 
> If you actually provided a user and didn't just try to offend the kernel
> maintainers by submitting dead code I could explain you in detail why
> youre idea is flawed.
> 
If a machine uses both SD and MMC simultaneously, how should timeouts be set

for each? And if different timeout values need to be used depending on the
manufacturer of the SD card, how can this be implemented? I believe it is
not appropriate to make such changes in the core code. There needs to be
a way to configure these settings per host.

Patch

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index ef06a4d5d65b..d292f93ca732 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -3261,6 +3261,9 @@  static int mmc_blk_probe(struct mmc_card *card)
 		goto out_free;
 	}
 
+	if (card->host->ops->config_host)
+		card->host->ops->config_host(card, &md->queue);
+
 	ret = mmc_blk_alloc_parts(card, md);
 	if (ret)
 		goto out;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 8fc2b328ec4d..81e21553030b 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -113,6 +113,8 @@  enum mmc_err_stat {
 	MMC_ERR_MAX,
 };
 
+struct mmc_queue;
+
 struct mmc_host_ops {
 	/*
 	 * It is optional for the host to implement pre_req and post_req in
@@ -219,6 +221,9 @@  struct mmc_host_ops {
 
 	/* Initialize an SD express card, mandatory for MMC_CAP2_SD_EXP. */
 	int	(*init_sd_express)(struct mmc_host *host, struct mmc_ios *ios);
+
+	/* Configure block layer setting related on MMC queue */
+	void	(*config_host)(struct mmc_card *card, struct mmc_queue *mq);
 };
 
 struct mmc_cqe_ops {