[PATCH] mmc: Add config_host callback to set a mmc queue

[PATCH] mmc: Add config_host callback to set a mmc queue

[Jangsub Yi]

From: "jangsub.yi" <jangsub.yi@samsung.com>

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 <jangsub.yi@samsung.com>
---
 drivers/mmc/core/block.c | 3 +++
 include/linux/mmc/host.h | 5 +++++
 2 files changed, 8 insertions(+)

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 {
-- 
2.17.1

Re: [PATCH] mmc: Add config_host callback to set a mmc queue

[Christoph Hellwig]

On Wed, Nov 06, 2024 at 02:13:47PM +0900, Jangsub Yi wrote:
> From: "jangsub.yi" <jangsub.yi@samsung.com>
> 
> 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.

RE: [PATCH] mmc: Add config_host callback to set a mmc queue

[???]

> On Wed, Nov 06, 2024 at 02:13:47PM +0900, Jangsub Yi wrote:
> > From: "jangsub.yi" <jangsub.yi@samsung.com>
> >
> > 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.

Re: [PATCH] mmc: Add config_host callback to set a mmc queue

['Christoph Hellwig']

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.

RE: [PATCH] mmc: Add config_host callback to set a mmc queue

[Jangsub Yi]

> 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.

RE: [PATCH] mmc: Add config_host callback to set a mmc queue

[Jangsub Yi]

> > 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.
> 
This is necessary to have separate policies for each device.
I will also implement the host modifications related to this content 
and try to upstream it. Please review the core modifications.

Re: [PATCH] mmc: Add config_host callback to set a mmc queue

['Christoph Hellwig']

On Tue, Dec 10, 2024 at 02:23:55PM +0900, Jangsub Yi wrote:
> This is necessary to have separate policies for each device.
> I will also implement the host modifications related to this content 
> and try to upstream it. Please review the core modifications.

It is not reviewable without a user and your insistance to waste
everyones time for a patch that as is adds dead code is highly
offensive.  Stop it.

RE: [PATCH] mmc: Add config_host callback to set a mmc queue

[Jangsub Yi]

> On Tue, Dec 10, 2024 at 02:23:55PM +0900, Jangsub Yi wrote:
> > This is necessary to have separate policies for each device.
> > I will also implement the host modifications related to this content
> > and try to upstream it. Please review the core modifications.
> 
> It is not reviewable without a user and your insistance to waste everyones
> time for a patch that as is adds dead code is highly offensive.  Stop it.
> 
 I'm sorry but I couldn't understand your intention clearly because 
it's my first time reflecting on the mainline. I will include the
modifications 
made to the host (user) and upload the review again.