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

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

mmc: core: Rename __mmc_set_signal_voltage() to mmc_set_signal_voltage()

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

Earlier the mmc_set_signal_voltage() existed, but since it has been renamed
to mmc_set_uhs_voltage(), we can now use that name instead.

Signed-off-by: Ulf Hansson 
Reviewed-by: Shawn Lin 
Tested-by: Jan Glauber 
Tested-by: Stefan Wahren

mmc: core: Clarify usage of mmc_set_signal_voltage()

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

The mmc_set_signal_voltage() function is used for SD/SDIO when switching to
1.8V for UHS mode. To clarify this let's do the following changes.

- We are always providing MMC_SIGNAL_VOLTAGE_180 as the signal_voltage
  parameter to the function. Then, let's just remove the parameter as it
  serves no purpose.
- Rename the function to mmc_set_uhs_voltage().

Signed-off-by: Ulf Hansson 
Reviewed-by: Shawn Lin 
Tested-by: Jan Glauber 
Tested-by: Stefan Wahren

mmc: core: Remove redundant code in mmc_set_signal_voltage()

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

The mmc_set_signal_voltage() function is used for SD/SDIO when switching to
1.8V for UHS mode. Therefore let's remove the redundant code dealing with
MMC_SIGNAL_VOLTAGE_330.

Signed-off-by: Ulf Hansson 
Reviewed-by: Shawn Lin 
Tested-by: Jan Glauber 
Tested-by: Stefan Wahren

mmc: core: Move public functions from card.h to private headers

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

A significant amount of functions and other definitions are available
through the public mmc card.h header file. Let's slim down this public mmc
interface, as to prevent users from abusing it, by moving some of the
functions/definitions to private mmc header files.

This change concentrates on moving the functions into private mmc headers,
following changes may continue with additional clean-ups.

Signed-off-by: Ulf Hansson 
Reviewed-by: Linus Walleij 
Reviewed-by: Shawn Lin

mmc: use empty initializer list to zero-clear structures

2017-02-13T12:19:54+00:00

In the MMC subsystem, we see such initializers that only clears the
first member explicitly.

For example,

  struct mmc_request mrq = {NULL};

sets the first member (.sbc) to NULL explicitly.  However, this is
an unstable form because we may insert a non-pointer member at the
top of the struct mmc_request in the future. (if we do so, the
compiler will spit warnings.)

So, using a designated initializer is preferred coding style.  The
expression above is equivalent to:

  struct mmc_request mrq = { .sbc = NULL };

Of course, this does not express our intention.  We want to fill
all struct members with zeros.  Please note struct members are
implicitly zero-cleared unless otherwise specified in the initializer.

After all, the most reasonable (and stable) form is:

  struct mmc_request mrq = {};

Do likewise for mmc_command, mmc_data as well.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Linus Walleij 
Signed-off-by: Ulf Hansson

mmc: core: Further fix thread wake-up

2016-12-20T10:55:04+00:00

Commit e0097cf5f2f1 ("mmc: queue: Fix queue thread wake-up") did not go far
enough. mmc_wait_for_data_req_done() still contains some problems and can
be further simplified.  First it should not touch
context_info->is_waiting_last_req because that is a wake-up control used by
the owner of the context. Secondly, it should always return when one of its
wake-up conditions is met because, again, that is contolled by the owner of
the context.

While the current block driver does not have an issue, these problems were
exposed during testing of the Software Command Queue patches.

Fixes: e0097cf5f2f1 ("mmc: queue: Fix queue thread wake-up")
Signed-off-by: Adrian Hunter 
Tested-by: Harjani Ritesh 
Signed-off-by: Ulf Hansson

mmc: core: remove BUG_ONs from core.c

2016-12-05T09:31:11+00:00

BUG_ONs doesn't help anything except for stop the system from
running. If it occurs, it implies we should deploy proper error
handling for that. So this patch is gonna discard these meaningless
BUG_ONs and deploy error handling if needed.

Signed-off-by: Shawn Lin 
Signed-off-by: Ulf Hansson