linux.git/drivers/mmc/core/core.c, branch v4.12

mmc: core: Export API to allow hosts to get the card address

2017-04-24T19:49:15+00:00

Some hosts controllers, like Cavium, needs to know whether the card
operates in byte- or block-address mode. Therefore export a new API,
mmc_card_is_blockaddr(), which provides this information.

Signed-off-by: Ulf Hansson 
Signed-off-by: Steven J. Hill 
Acked-by: David Daney

mmc: sdio: Fix sdio wait busy implement limitation

2017-04-24T19:45:09+00:00

The host may issue an I/O abort by writing to the CCCR at any time
during I/O read operation via CMD52. And host may need suspend
transcation during write busy stage in SDIO suspend/resume scenario.
>From other side, a card may accept CMD52 during data transfer phase.

Previous implement would block issuing above command in busy stage.
It cause function driver can't implement as proper way and has no
opportunity to do some coverage in error case via I/O abort etc.

We need bypass some necessary operation during busy check stage.

Signed-off-by: Jiajie Hao 
Signed-off-by: Ulf Hansson

mmc: core: refactor mmc_request_done()

2017-04-24T19:42:08+00:00

We have this construction:

if (a && b && !c)
   finalize;
else
   block;
   finalize;

Which is equivalent by boolean logic to:

if (!a || !b || c)
   block;
finalize;

Which is simpler code.

Reviewed-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Linus Walleij 
Signed-off-by: Ulf Hansson

mmc: core: refactor asynchronous request finalization

2017-04-24T19:42:07+00:00

mmc_wait_for_data_req_done() is called in exactly one place,
and having it spread out is making things hard to oversee.
Factor this function into mmc_finalize_areq().

Reviewed-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Linus Walleij 
Signed-off-by: Ulf Hansson

mmc: core: move some code in mmc_start_areq()

2017-04-24T19:42:06+00:00

"previous" is a better name for the variable storing the previous
asynchronous request, better than the opaque name "data" atleast.
We see that we assign the return status to the returned variable
on all code paths, so we might as well just do that immediately
after calling mmc_finalize_areq().

Reviewed-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Linus Walleij 
Signed-off-by: Ulf Hansson

mmc: core: Factor out mrq preparation from mmc_start_request()

2017-04-24T19:42:06+00:00

In preparation to reuse the code for CQE support.

Signed-off-by: Adrian Hunter 
Reviewed-by: Linus Walleij 
Signed-off-by: Ulf Hansson

mmc: core: Factor out debug prints from mmc_start_request()

2017-04-24T19:42:05+00:00

In preparation to reuse the code for CQE support.

Signed-off-by: Adrian Hunter 
Reviewed-by: Linus Walleij 
Signed-off-by: Ulf Hansson

mmc: core: start to break apart mmc_start_areq()

2017-02-14T08:10:53+00:00

This function is doing to many clever things at the same time under
too many various conditions.

Start to make things clearer by refactoring: break out the
finalization of the previous asynchronous request to its own
function mmc_finalize_areq(). We can get rid of the default
assignment of status and let the call deal with this.

Signed-off-by: Linus Walleij 
Signed-off-by: Ulf Hansson

mmc: core: rename mmc_start_req() to *areq()

2017-02-13T12:20:58+00:00

With the coexisting __mmc_start_request(), mmc_start_request()
and __mmc_start_req() it is a bit confusing that mmc_start_req()
actually does not start a normal request, but an asynchronous
request.

Rename it to mmc_start_areq() to make it explicit what the
function is doing, also fix the kerneldoc for this function
while we're at it.

Signed-off-by: Linus Walleij 
Signed-off-by: Ulf Hansson

mmc: core/mmci: restore pre/post_req behaviour

2017-02-13T12:20:52+00:00

commit 64b12a68a9f74bb32d8efd7af1ad8a2ba02fc884
"mmc: core: fix prepared requests while doing bkops"
is fixing a bug in the wrong way. A bug in the MMCI
device driver is fixed by amending the MMC core.

Thinking about it: what the pre- and post-callbacks
are doing is to essentially map and unmap SG lists
for DMA transfers. Why would we not be able to do that
just because a BKOPS command is sent inbetween?
Having to unprepare/prepare the next asynchronous
request for DMA seems wrong.

Looking the backtrace in that commit we can see what
the real problem actually is:

mmci_data_irq() is calling mmci_dma_unmap() twice
which is goung to call arm_dma_unmap_sg() twice
and v7_dma_inv_range() twice for the same sglist
and that will crash.

This happens because a request is prepared, then
a BKOPS is sent. The IRQ completing the BKOPS command
goes through mmci_data_irq() and thinks that a DMA
operation has just been completed because
dma_inprogress() reports true. It then proceeds to
unmap the sglist.

But that was wrong! dma_inprogress() should NOT be
true because no DMA was actually in progress! We had
just prepared the sglist, and the DMA channel
dma_current has been configured, but NOT started!

Because of this, the sglist is already unmapped when
we get our actual data completion IRQ, and we are
unmapping the sglist once more, and we get this crash.

Therefore, we need to revert this solution pushing
the problem to the core and causing problems, and
instead augment the implementation such that
dma_inprogress() only reports true if some DMA has
actually been started.

After this we can keep the request prepared during the
BKOPS and we need not unprepare/reprepare it.

Fixes: 64b12a68a9f7 ("mmc: core: fix prepared requests while doing bkops")
Cc: Srinivas Kandagatla 
Signed-off-by: Linus Walleij 
Tested-by: Srinivas Kandagatla 
Signed-off-by: Ulf Hansson