<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/mmc/core/sd_ops.h, branch v5.16</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.16</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.16'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-11-16T10:59:28+00:00</updated>
<entry>
<title>mmc: core: Initial support for SD express card/host</title>
<updated>2020-11-16T10:59:28+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2020-10-29T01:57:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ead49373d2916080509f51fc6a4ee8f9bc021b9b'/>
<id>urn:sha1:ead49373d2916080509f51fc6a4ee8f9bc021b9b</id>
<content type='text'>
In the SD specification v7.10 the SD express card has been added. This new
type of removable SD card, can be managed via a PCIe/NVMe based interface,
while also allowing backwards compatibility towards the legacy SD
interface.

To keep the backwards compatibility, it's required to start the
initialization through the legacy SD interface. If it turns out that the
mmc host and the SD card, both supports the PCIe/NVMe interface, then a
switch should be allowed.

Therefore, let's introduce some basic support for this type of SD cards to
the mmc core. The mmc host, should set MMC_CAP2_SD_EXP if it supports this
interface and MMC_CAP2_SD_EXP_1_2V, if also 1.2V is supported, as to inform
the core about it.

To deal with the switch to the PCIe/NVMe interface, the mmc host is
required to implement a new host ops, -&gt;init_sd_express(). Based on the
initial communication between the host and the card, host-&gt;ios.timing is
set to either MMC_TIMING_SD_EXP or MMC_TIMING_SD_EXP_1_2V, depending on if
1.2V is supported or not. In this way, the mmc host can check these values
in its -&gt;init_sd_express() ops, to know how to proceed with the handover.

Note that, to manage card insert/removal, the mmc core sticks with using
the -&gt;get_cd() callback, which means it's the host's responsibility to make
sure it provides valid data, even if the card may be managed by PCIe/NVMe
at the moment. As long as the card seems to be present, the mmc core keeps
the card powered on.

Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Rui Feng &lt;rui_feng@realsil.com.cn&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Link: https://lore.kernel.org/r/1603936636-3126-1-git-send-email-rui_feng@realsil.com.cn
</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152</title>
<updated>2019-05-30T18:26:32+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2019-05-27T06:55:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2874c5fd284268364ece81a7bd936f3c8168e567'/>
<id>urn:sha1:2874c5fd284268364ece81a7bd936f3c8168e567</id>
<content type='text'>
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Convert mmc_wait_for_app_cmd() to static</title>
<updated>2019-02-25T14:20:58+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2019-02-13T13:49:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9a4b869b0ca9a9e4d8497ecf20a1e3d6557b5426'/>
<id>urn:sha1:9a4b869b0ca9a9e4d8497ecf20a1e3d6557b5426</id>
<content type='text'>
mmc_wait_for_app_cmd() is an internal function for sd_ops.c, thus let's
drop the unnecessary export and turn it into static function.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: add proper be32 annotation</title>
<updated>2017-04-24T19:42:19+00:00</updated>
<author>
<name>Winkler, Tomas</name>
<email>tomas.winkler@intel.com</email>
</author>
<published>2017-04-02T20:56:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=06c9ccb78e68e2e9b69e736fc0a39fb13be49b74'/>
<id>urn:sha1:06c9ccb78e68e2e9b69e736fc0a39fb13be49b74</id>
<content type='text'>
Annotate big endian values correctly and make sparse happy.
In mmc_app_send_scr remove scr function parameter as it was
updating card-&gt;raw_scr anyway.

Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Move public functions from core.h to private headers</title>
<updated>2017-02-13T12:20:21+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2017-01-13T13:14:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=55244c5659b5e73a969b285a2e763223d8aab979'/>
<id>urn:sha1:55244c5659b5e73a969b285a2e763223d8aab979</id>
<content type='text'>
A significant amount of functions are available through the public mmc
core.h header file. Let's slim down this public mmc interface, as to
prevent users from abusing it, by moving some of the functions to private
mmc header files.

This change concentrates on moving the functions into private mmc headers,
following changes may continue with additional clean-ups, as an example
some functions can be turned into static.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
</content>
</entry>
<entry>
<title>mmc: core: First step in cleaning up private mmc header files</title>
<updated>2017-02-13T12:20:20+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2017-01-13T13:14:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=066185d690631478b16045d152b163a51a5e4847'/>
<id>urn:sha1:066185d690631478b16045d152b163a51a5e4847</id>
<content type='text'>
This is the first step in cleaning up the private mmc header files. In this
change we makes sure each header file builds standalone, as that helps to
resolve dependencies.

While changing this, it also seems reasonable to stop including other
headers from inside a header itself which it don't depend upon.
Additionally, in some cases such dependencies are better resolved by
forward declaring the needed struct.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
</content>
</entry>
<entry>
<title>mmc: add erase, secure erase, trim and secure trim operations</title>
<updated>2010-08-12T15:43:30+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@nokia.com</email>
</author>
<published>2010-08-11T21:17:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dfe86cba7676d58db8de7e623f5e72f1b0d3ca35'/>
<id>urn:sha1:dfe86cba7676d58db8de7e623f5e72f1b0d3ca35</id>
<content type='text'>
SD/MMC cards tend to support an erase operation.  In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.

SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.

"erase_size" is the minimum size, in bytes, of an erase operation.  For
MMC, "erase_size" is the erase group size reported by the card.  Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector.  For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.

SD/MMC cards can erase an arbitrarily large area up to and
including the whole card.  When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:

    1. A single erase command will make all other I/O on the card
       wait.  This is not a problem if the whole card is being erased, but
       erasing one partition will make I/O for another partition on the
       same card wait for the duration of the erase - which could be a
       several minutes.

    2. To be able to inform the user of erase progress.

    3. The erase timeout becomes too large to be very useful.
       Because the erase timeout contains a margin which is multiplied by
       the size of the erase area, the value can end up being several
       minutes for large areas.

"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.

For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.

For SD, "preferred_erase_size" is the allocation unit size specified by
the card.

"preferred_erase_size" is in bytes.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@nokia.com&gt;
Acked-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Kyungmin Park &lt;kmpark@infradead.org&gt;
Cc: Madhusudhan Chikkature &lt;madhu.cr@ti.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Ben Gardiner &lt;bengardiner@nanometrics.ca&gt;
Cc: &lt;linux-mmc@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>drivers/mmc/core/: make 3 functions static</title>
<updated>2007-07-26T00:05:57+00:00</updated>
<author>
<name>Adrian Bunk</name>
<email>bunk@stusta.de</email>
</author>
<published>2007-07-24T22:40:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=393618510d5349e07d71dc28fb6fc49baf0d96a0'/>
<id>urn:sha1:393618510d5349e07d71dc28fb6fc49baf0d96a0</id>
<content type='text'>
This patch makes the following needlessly global functions static:
- sd_ops.c: mmc_app_cmd()
- core.c: __mmc_release_bus()
- core.c: mmc_start_request()

Signed-off-by: Adrian Bunk &lt;bunk@stusta.de&gt;
Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;
</content>
</entry>
<entry>
<title>mmc: update header file paths</title>
<updated>2007-07-25T23:53:31+00:00</updated>
<author>
<name>Pierre Ossman</name>
<email>drzeus@drzeus.cx</email>
</author>
<published>2007-07-11T18:04:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=70f10482c668301c483acded13bf68780ad352b9'/>
<id>urn:sha1:70f10482c668301c483acded13bf68780ad352b9</id>
<content type='text'>
Make sure all headers in the files reflect their true position
in the tree.

Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;
</content>
</entry>
<entry>
<title>mmc: Separate out protocol ops</title>
<updated>2007-05-01T11:04:18+00:00</updated>
<author>
<name>Pierre Ossman</name>
<email>drzeus@drzeus.cx</email>
</author>
<published>2006-12-24T21:46:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=da7fbe58d2d347e95af699ddf04d885be6362bbe'/>
<id>urn:sha1:da7fbe58d2d347e95af699ddf04d885be6362bbe</id>
<content type='text'>
Move protocol operations and definitions into their own files
in an effort to separate protocol handling and bus
arbitration more clearly.

Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;
</content>
</entry>
</feed>
