linux-next: manual merge of the mmc tree with the block tree

linux-next: manual merge of the mmc tree with the block tree

[Stephen Rothwell]

Hi Ulf,

Today's linux-next merge of the mmc tree got a conflict in:

  drivers/mmc/card/block.c

between commit:

  e806402130c9 ("block: split out request-only flags into a new namespace")

from the block tree and commit:

  95105fc9ffbb ("mmc: block: delete packed command support")

from the mmc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/mmc/card/block.c
index ae9cbe6101be,86ff28f84698..000000000000
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@@ -2114,28 -1728,18 +1728,18 @@@ static int mmc_blk_issue_rw_rq(struct m
  	return 1;
  
   cmd_abort:
- 	if (mmc_packed_cmd(mq_rq->cmd_type)) {
- 		mmc_blk_abort_packed_req(mq_rq);
- 	} else {
- 		if (mmc_card_removed(card))
- 			req->rq_flags |= RQF_QUIET;
- 		while (ret)
- 			ret = blk_end_request(req, -EIO,
- 					blk_rq_cur_bytes(req));
- 	}
+ 	if (mmc_card_removed(card))
 -		req->cmd_flags |= REQ_QUIET;
++		req->rq_flags |= RQF_QUIET;
+ 	while (ret)
+ 		ret = blk_end_request(req, -EIO,
+ 				blk_rq_cur_bytes(req));
  
   start_new_req:
  	if (rqc) {
  		if (mmc_card_removed(card)) {
 -			rqc->cmd_flags |= REQ_QUIET;
 +			rqc->rq_flags |= RQF_QUIET;
  			blk_end_request_all(rqc, -EIO);
  		} else {
- 			/*
- 			 * If current request is packed, it needs to put back.
- 			 */
- 			if (mmc_packed_cmd(mq->mqrq_cur->cmd_type))
- 				mmc_blk_revert_packed_req(mq, mq->mqrq_cur);
- 
  			mmc_blk_rw_rq_prep(mq->mqrq_cur, card, 0, mq);
  			mmc_start_req(card->host,
  				      &mq->mqrq_cur->mmc_active, NULL);

Re: linux-next: manual merge of the mmc tree with the block tree

[Ulf Hansson]

+Jens

On 28 November 2016 at 03:12, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ulf,
>
> Today's linux-next merge of the mmc tree got a conflict in:
>
>   drivers/mmc/card/block.c
>
> between commit:
>
>   e806402130c9 ("block: split out request-only flags into a new namespace")
>
> from the block tree and commit:
>
>   95105fc9ffbb ("mmc: block: delete packed command support")
>
> from the mmc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Stephen, thanks for reporting! Just to let you know, I have today
re-based my next branch, which makes ("mmc: block: delete packed
command support") get a new commit id. Perhaps that causes you to
re-resolve the conflict, then apologize for the inconvenience.

Jens, Christoph, I believe I said this before; could you please make
sure patches for mmc also becomes cc:ed to me?
Don't get me wrong, I have no problem you carrying changes for mmc,
especially clean-ups like this one, but it just be nice to be aware of
what goes on.

Kind regards
Uffe

>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/mmc/card/block.c
> index ae9cbe6101be,86ff28f84698..000000000000
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@@ -2114,28 -1728,18 +1728,18 @@@ static int mmc_blk_issue_rw_rq(struct m
>         return 1;
>
>    cmd_abort:
> -       if (mmc_packed_cmd(mq_rq->cmd_type)) {
> -               mmc_blk_abort_packed_req(mq_rq);
> -       } else {
> -               if (mmc_card_removed(card))
> -                       req->rq_flags |= RQF_QUIET;
> -               while (ret)
> -                       ret = blk_end_request(req, -EIO,
> -                                       blk_rq_cur_bytes(req));
> -       }
> +       if (mmc_card_removed(card))
>  -              req->cmd_flags |= REQ_QUIET;
> ++              req->rq_flags |= RQF_QUIET;
> +       while (ret)
> +               ret = blk_end_request(req, -EIO,
> +                               blk_rq_cur_bytes(req));
>
>    start_new_req:
>         if (rqc) {
>                 if (mmc_card_removed(card)) {
>  -                      rqc->cmd_flags |= REQ_QUIET;
>  +                      rqc->rq_flags |= RQF_QUIET;
>                         blk_end_request_all(rqc, -EIO);
>                 } else {
> -                       /*
> -                        * If current request is packed, it needs to put back.
> -                        */
> -                       if (mmc_packed_cmd(mq->mqrq_cur->cmd_type))
> -                               mmc_blk_revert_packed_req(mq, mq->mqrq_cur);
> -
>                         mmc_blk_rw_rq_prep(mq->mqrq_cur, card, 0, mq);
>                         mmc_start_req(card->host,
>                                       &mq->mqrq_cur->mmc_active, NULL);

Re: linux-next: manual merge of the mmc tree with the block tree

[Christoph Hellwig]

On Tue, Nov 29, 2016 at 10:13:59AM +0100, Ulf Hansson wrote:
> Jens, Christoph, I believe I said this before; could you please make
> sure patches for mmc also becomes cc:ed to me?
> Don't get me wrong, I have no problem you carrying changes for mmc,
> especially clean-ups like this one, but it just be nice to be aware of
> what goes on.

I'm not going to Cc every driver maintainer on trivial tree-wide
cleanups.  As the maintainer of a block driver you should be subscribed
to the linux-block mailing list where every block patch is discussed.

Re: linux-next: manual merge of the mmc tree with the block tree

[Ulf Hansson]

On 29 November 2016 at 10:16, Christoph Hellwig <hch@lst.de> wrote:
> On Tue, Nov 29, 2016 at 10:13:59AM +0100, Ulf Hansson wrote:
>> Jens, Christoph, I believe I said this before; could you please make
>> sure patches for mmc also becomes cc:ed to me?
>> Don't get me wrong, I have no problem you carrying changes for mmc,
>> especially clean-ups like this one, but it just be nice to be aware of
>> what goes on.
>
> I'm not going to Cc every driver maintainer on trivial tree-wide
> cleanups.  As the maintainer of a block driver you should be subscribed
> to the linux-block mailing list where every block patch is discussed.

Okay!

Kind regards
Uffe

Re: linux-next: manual merge of the mmc tree with the block tree

[Christoph Hellwig]

Thanks, the merge looks good to me.

linux-next: manual merge of the mmc tree with the block tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2657 bytes --]

Hi all,

Today's linux-next merge of the mmc tree got a conflict in:

  drivers/mmc/core/queue.c

between commit:

  616f87661792 ("mmc: pass queue_limits to blk_mq_alloc_disk")

from the block tree and commit:

  069279d6fef5 ("mmc: core Drop BLK_BOUNCE_HIGH")

from the mmc tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/mmc/core/queue.c
index 2ae60d208cdf,316415588a77..000000000000
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@@ -343,50 -341,10 +343,47 @@@ static const struct blk_mq_ops mmc_mq_o
  	.timeout	= mmc_mq_timed_out,
  };
  
 -static void mmc_setup_queue(struct mmc_queue *mq, struct mmc_card *card)
 +static struct gendisk *mmc_alloc_disk(struct mmc_queue *mq,
 +		struct mmc_card *card)
  {
  	struct mmc_host *host = card->host;
 -	unsigned block_size = 512;
 +	struct queue_limits lim = { };
 +	struct gendisk *disk;
 +
 +	if (mmc_can_erase(card))
 +		mmc_queue_setup_discard(card, &lim);
 +
- 	if (!mmc_dev(host)->dma_mask || !*mmc_dev(host)->dma_mask)
- 		lim.bounce = BLK_BOUNCE_HIGH;
- 
 +	lim.max_hw_sectors = min(host->max_blk_count, host->max_req_size / 512);
 +
 +	if (mmc_card_mmc(card) && card->ext_csd.data_sector_size)
 +		lim.logical_block_size = card->ext_csd.data_sector_size;
 +	else
 +		lim.logical_block_size = 512;
 +
 +	WARN_ON_ONCE(lim.logical_block_size != 512 &&
 +		     lim.logical_block_size != 4096);
 +
 +	/*
 +	 * Setting a virt_boundary implicity sets a max_segment_size, so try
 +	 * to set the hardware one here.
 +	 */
 +	if (host->can_dma_map_merge) {
 +		lim.virt_boundary_mask = dma_get_merge_boundary(mmc_dev(host));
 +		lim.max_segments = MMC_DMA_MAP_MERGE_SEGMENTS;
 +	} else {
 +		lim.max_segment_size =
 +			round_down(host->max_seg_size, lim.logical_block_size);
 +		lim.max_segments = host->max_segs;
 +	}
 +
 +	disk = blk_mq_alloc_disk(&mq->tag_set, &lim, mq);
 +	if (IS_ERR(disk))
 +		return disk;
 +	mq->queue = disk->queue;
 +
 +	if (mmc_host_is_spi(host) && host->use_spi_crc)
 +		blk_queue_flag_set(QUEUE_FLAG_STABLE_WRITES, mq->queue);
 +	blk_queue_rq_timeout(mq->queue, 60 * HZ);
  
  	blk_queue_flag_set(QUEUE_FLAG_NONROT, mq->queue);
  	blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, mq->queue);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the mmc tree with the block tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

Hi all,

Today's linux-next merge of the mmc tree got a conflict in:

  drivers/mmc/core/queue.c

between commit:

  44abff2c0b97 ("block: decouple REQ_OP_SECURE_ERASE from REQ_OP_DISCARD")

from the block tree and commit:

  f7b6fc327327 ("mmc: core: Support zeroout using TRIM for eMMC")

from the mmc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/mmc/core/queue.c
index a3d446005571,bbe2ea829ea7..000000000000
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@@ -189,7 -190,9 +189,9 @@@ static void mmc_queue_setup_discard(str
  	if (card->pref_erase > max_discard)
  		q->limits.discard_granularity = SECTOR_SIZE;
  	if (mmc_can_secure_erase_trim(card))
 -		blk_queue_flag_set(QUEUE_FLAG_SECERASE, q);
 +		blk_queue_max_secure_erase_sectors(q, max_discard);
+ 	if (mmc_can_trim(card) && card->erased_byte == 0)
+ 		blk_queue_max_write_zeroes_sectors(q, max_discard);
  }
  
  static unsigned short mmc_get_max_segments(struct mmc_host *host)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the mmc tree with the block tree

[Stephen Rothwell]

Hi Ulf,

Today's linux-next merge of the mmc tree got a conflict in:

  drivers/mmc/core/block.c

between commit:

  2a842acab109 ("block: introduce new block status code type")

from the block tree and commit:

  b016f2c50d78 ("mmc: core: Allocate per-request data using the block layer core")

from the mmc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/mmc/core/block.c
index 6ff94a948a4b,3c7efbdc8591..000000000000
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@@ -1646,8 -1686,8 +1691,8 @@@ static void mmc_blk_rw_cmd_abort(struc
  {
  	if (mmc_card_removed(card))
  		req->rq_flags |= RQF_QUIET;
 -	while (blk_end_request(req, -EIO, blk_rq_cur_bytes(req)));
 +	while (blk_end_request(req, BLK_STS_IOERR, blk_rq_cur_bytes(req)));
- 	mmc_queue_req_free(mq, mqrq);
+ 	mq->qcnt--;
  }
  
  /**
@@@ -1666,8 -1706,8 +1711,8 @@@ static void mmc_blk_rw_try_restart(stru
  	 */
  	if (mmc_card_removed(mq->card)) {
  		req->rq_flags |= RQF_QUIET;
 -		blk_end_request_all(req, -EIO);
 +		blk_end_request_all(req, BLK_STS_IOERR);
- 		mmc_queue_req_free(mq, mqrq);
+ 		mq->qcnt--; /* FIXME: just set to 0? */
  		return;
  	}
  	/* Else proceed and try to restart the current async request */
@@@ -1816,10 -1852,10 +1857,10 @@@ static void mmc_blk_issue_rw_rq(struct 
  			 * time, so we only reach here after trying to
  			 * read a single sector.
  			 */
 -			req_pending = blk_end_request(old_req, -EIO,
 +			req_pending = blk_end_request(old_req, BLK_STS_IOERR,
  						      brq->data.blksz);
  			if (!req_pending) {
- 				mmc_queue_req_free(mq, mq_rq);
+ 				mq->qcnt--;
  				mmc_blk_rw_try_restart(mq, new_req, mqrq_cur);
  				return;
  			}