History log of /linux-6.15/include/linux/mmc/host.h (Results 1 – 25 of 260)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3
# 08a7ead3 13-Dec-2024 Eric Biggers <[email protected]>

mmc: crypto: add mmc_from_crypto_profile()

Add a helper function that encapsulates a container_of expression. For
now there is just one user but soon there will be more.

Signed-off-by: Eric Bigger

mmc: crypto: add mmc_from_crypto_profile()

Add a helper function that encapsulates a container_of expression. For
now there is just one user but soon there will be more.

Signed-off-by: Eric Biggers <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4
# 9a9f7e13 18-Oct-2024 Victor Shih <[email protected]>

mmc: core: Support UHS-II card control and access

Embed UHS-II access/control functionality into the MMC request
processing flow.

Signed-off-by: Jason Lai <[email protected]>
Signed-off

mmc: core: Support UHS-II card control and access

Embed UHS-II access/control functionality into the MMC request
processing flow.

Signed-off-by: Jason Lai <[email protected]>
Signed-off-by: Victor Shih <[email protected]>
Message-ID: <[email protected]>
[Ulf: A couple of cleanups and fixed sd_uhs2_power_off()]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11
# a9a75f9d 13-Sep-2024 Victor Shih <[email protected]>

mmc: core: Add definitions for SD UHS-II cards

Add UHS-II specific data structures for commands and defines for
registers, as described in Part 1 UHS-II Addendum Version 1.01.

UHS-II related defini

mmc: core: Add definitions for SD UHS-II cards

Add UHS-II specific data structures for commands and defines for
registers, as described in Part 1 UHS-II Addendum Version 1.01.

UHS-II related definitions are listed below:
1. UHS-II card capability: sd_uhs2_caps{}
2. UHS-II configuration: sd_uhs2_config{}
3. UHS-II register I/O address and register field definitions: sd_uhs2.h

Signed-off-by: Jason Lai <[email protected]>
Signed-off-by: Victor Shih <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


# a56ffd3a 13-Sep-2024 Ulf Hansson <[email protected]>

mmc: core: Extend support for mmc regulators with a vqmmc2

To allow an additional external regulator to be controlled by an mmc host
driver, let's add support for a vqmmc2 regulator to the mmc core.

mmc: core: Extend support for mmc regulators with a vqmmc2

To allow an additional external regulator to be controlled by an mmc host
driver, let's add support for a vqmmc2 regulator to the mmc core.

For an SD UHS-II interface the vqmmc2 regulator may correspond to the so
called vdd2 supply, as described by the SD spec. Initially, only 1.8V is
needed, hence limit the new helper function, mmc_regulator_set_vqmmc2() to
this too.

Note that, to allow for flexibility mmc host drivers need to manage the
enable/disable of the vqmmc2 regulator themselves, while the regulator is
looked up through the common mmc_regulator_get_supply().

Signed-off-by: Ulf Hansson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...


# 153196d5 13-Sep-2024 Ulf Hansson <[email protected]>

mmc: core: Announce successful insertion of an SD UHS-II card

To inform the users about SD UHS-II cards, let's extend the print at card
insertion with a "UHS-II" substring. Within this change, it se

mmc: core: Announce successful insertion of an SD UHS-II card

To inform the users about SD UHS-II cards, let's extend the print at card
insertion with a "UHS-II" substring. Within this change, it seems
reasonable to convert from using "ultra high speed" into "UHS-I speed", for
the UHS-I type, as it should makes it more clear.

Note that, the new print for UHS-II cards doesn't include the actual
selected speed mode. Instead, this is going to be added from subsequent
change.

Signed-off-by: Ulf Hansson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...


# 79daeb24 13-Sep-2024 Ulf Hansson <[email protected]>

mmc: core: Prepare to support SD UHS-II cards

The SD UHS-II interface was introduced to the SD spec v4.00 several years
ago. The interface is fundamentally different from an electrical and a
protoco

mmc: core: Prepare to support SD UHS-II cards

The SD UHS-II interface was introduced to the SD spec v4.00 several years
ago. The interface is fundamentally different from an electrical and a
protocol point of view, comparing to the legacy SD interface.

However, the legacy SD protocol is supported through a specific transport
layer (SD-TRAN) defined in the UHS-II addendum of the spec. This allows the
SD card to be managed in a very similar way as a legacy SD card, hence a
lot of code can be re-used to support these new types of cards through the
mmc subsystem.

Moreover, an SD card that supports the UHS-II interface shall also be
backwards compatible with the legacy SD interface, which allows a UHS-II
card to be inserted into a legacy slot. As a matter of fact, this is
already supported by mmc subsystem as of today.

To prepare to add support for UHS-II, this change puts the basic foundation
in the mmc core in place, allowing it to be more easily reviewed before
subsequent changes implements the actual support.

Basically, the approach here adds a new UHS-II bus_ops type and adds a
separate initialization path for the UHS-II card. The intent is to avoid us
from sprinkling the legacy initialization path, but also to simplify
implementation of the UHS-II specific bits.

At this point, there is only one new host ops added to manage the various
ios settings needed for UHS-II. Additional host ops that are needed, are
being added from subsequent changes.

Signed-off-by: Ulf Hansson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...


Revision tags: v6.11-rc7, v6.11-rc6
# 4c0a6a0a 29-Aug-2024 Chanwoo Lee <[email protected]>

mmc: core: Replace the argument of mmc_sd_switch() with defines

Replace with already defined values for readability. While at it, let's
also change the mode-parameter from an int to bool, as the onl

mmc: core: Replace the argument of mmc_sd_switch() with defines

Replace with already defined values for readability. While at it, let's
also change the mode-parameter from an int to bool, as the only used values
are 0 or 1.

Signed-off-by: Chanwoo Lee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v6.11-rc5, v6.11-rc4
# 6ce2082f 13-Aug-2024 Jani Nikula <[email protected]>

fault-inject: improve build for CONFIG_FAULT_INJECTION=n

The fault-inject.h users across the kernel need to add a lot of #ifdef
CONFIG_FAULT_INJECTION to cater for shortcomings in the header. Make

fault-inject: improve build for CONFIG_FAULT_INJECTION=n

The fault-inject.h users across the kernel need to add a lot of #ifdef
CONFIG_FAULT_INJECTION to cater for shortcomings in the header. Make
fault-inject.h self-contained for CONFIG_FAULT_INJECTION=n, and add stubs
for DECLARE_FAULT_ATTR(), setup_fault_attr(), should_fail_ex(), and
should_fail() to allow removal of conditional compilation.

[[email protected]: repair fallout from no longer including debugfs.h into fault-inject.h]
[[email protected]: fix drivers/misc/xilinx_tmr_inject.c]
[[email protected]: Add debugfs.h inclusion to more files, per Stephen]
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 6ff1cb355e62 ("[PATCH] fault-injection capabilities infrastructure")
Signed-off-by: Jani Nikula <[email protected]>
Cc: Akinobu Mita <[email protected]>
Cc: Abhinav Kumar <[email protected]>
Cc: Dmitry Baryshkov <[email protected]>
Cc: Himal Prasad Ghimiray <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Thomas Hellström <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...


# f5e1638b 23-Aug-2024 Vladimir Zapolskiy <[email protected]>

mmc: core: remove left-over data structure declarations

The last users of 'enum mmc_blk_status' and 'struct mmc_async_req'
were removed by commit 126b62700386 ("mmc: core: Remove code no longer
need

mmc: core: remove left-over data structure declarations

The last users of 'enum mmc_blk_status' and 'struct mmc_async_req'
were removed by commit 126b62700386 ("mmc: core: Remove code no longer
needed after the switch to blk-mq") in 2017, remove these two left-over
data structures.

Signed-off-by: Vladimir Zapolskiy <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


# d3596c73 21-Aug-2024 Christophe JAILLET <[email protected]>

mmc: core: Remove struct mmc_context_info

The 'mmc_context_info' structure is unused.

It has been introduced in:

- commit 2220eedfd7ae ("mmc: fix async request mechanism for sequential
read

mmc: core: Remove struct mmc_context_info

The 'mmc_context_info' structure is unused.

It has been introduced in:

- commit 2220eedfd7ae ("mmc: fix async request mechanism for sequential
read scenarios")

in 2013-02 and its usages have been removed in:

- commit 126b62700386 ("mmc: core: Remove code no longer needed after the
switch to blk-mq")
- commit 0fbfd1251830 ("mmc: block: Remove code no longer needed after
the switch to blk-mq")

in 2017-12.

Now remove this unused structure.

Signed-off-by: Christophe JAILLET <[email protected]>
Reviewed-by: Vladimir Zapolskiy <[email protected]>
Link: https://lore.kernel.org/r/232106a8a6a374dee25feea9b94498361568c10b.1724246389.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4
# ec84ca40 09-Apr-2024 Christoph Hellwig <[email protected]>

scsi: block: Remove now unused queue limits helpers

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bart Van Assche <bv

scsi: block: Remove now unused queue limits helpers

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bart Van Assche <[email protected]>
Reviewed-by: John Garry <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>

show more ...


Revision tags: v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7
# 88803989 29-Feb-2024 Yang Xiwen <[email protected]>

mmc: core: Use a struct device* as in-param to mmc_of_parse_clk_phase()

Parsing dt usually happens very early, sometimes even before the struct
mmc_host has been allocated (e.g. dw_mci_probe() and d

mmc: core: Use a struct device* as in-param to mmc_of_parse_clk_phase()

Parsing dt usually happens very early, sometimes even before the struct
mmc_host has been allocated (e.g. dw_mci_probe() and dw_mci_parse_dt() in
dw_mmc.c). Looking at the source of mmc_of_parse_clk_phase(), it's actually
not needed to have an initialized mmc_host, let's therefore pass a struct
device* to it instead.

Also update the only current user, sdhci-of-aspeed.

Reviewed-by: Paul Menzel <[email protected]>
Acked-by: Andrew Jeffery <[email protected]>
Signed-off-by: Yang Xiwen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3
# 2e2b5479 19-Sep-2023 Wenchao Chen <[email protected]>

mmc: core: Allow dynamical updates of the number of requests for hsq

To allow dynamical updates of the current number of used in-flight
requests, let's move away from using a hard-coded value to a u

mmc: core: Allow dynamical updates of the number of requests for hsq

To allow dynamical updates of the current number of used in-flight
requests, let's move away from using a hard-coded value to a use a
corresponding variable in the struct mmc_host.

This can be valuable when optimizing for certain I/O request sequences, as
shown by subsequent changes.

Signed-off-by: Wenchao Chen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[Ulf: Re-wrote the commitmsg to clarify the change]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v6.6-rc2, v6.6-rc1, v6.5
# bac80683 25-Aug-2023 Wenchao Chen <[email protected]>

mmc: core: Add host specific tuning support for SD HS mode

To support the need for host specific tuning for SD high-speed mode, let's
add two new optional callbacks, ->prepare|execute_sd_hs_tuning()

mmc: core: Add host specific tuning support for SD HS mode

To support the need for host specific tuning for SD high-speed mode, let's
add two new optional callbacks, ->prepare|execute_sd_hs_tuning() and let's
call them when switching into the SD high-speed mode.

Note that, during the tuning process it's also needed for host drivers to
send commands to the SD card to verify that the tuning process succeeds.
Therefore, let's also share the corresponding functions from the core to
allow this.

Signed-off-by: Wenchao Chen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[Ulf: Dropped unnecessary function declarations and updated the commit msg]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2
# 8d91f3f8 11-Mar-2023 Heiner Kallweit <[email protected]>

mmc: core: add helpers mmc_regulator_enable/disable_vqmmc

There's a number of drivers (e.g. dw_mmc, meson-gx, mmci, sunxi) using
the same mechanism and a private flag vqmmc_enabled to deal with
enab

mmc: core: add helpers mmc_regulator_enable/disable_vqmmc

There's a number of drivers (e.g. dw_mmc, meson-gx, mmci, sunxi) using
the same mechanism and a private flag vqmmc_enabled to deal with
enabling/disabling the vqmmc regulator.

Move this to the core and create new helpers mmc_regulator_enable_vqmmc
and mmc_regulator_disable_vqmmc.

Signed-off-by: Heiner Kallweit <[email protected]>
Acked-by: Martin Blumenstingl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7
# 80df83c2 03-Feb-2023 Heiner Kallweit <[email protected]>

mmc: core: add devm_mmc_alloc_host

Add a device-managed version of mmc_alloc_host().

The argument order is reversed compared to mmc_alloc_host() because
device-managed functions typically have the

mmc: core: add devm_mmc_alloc_host

Add a device-managed version of mmc_alloc_host().

The argument order is reversed compared to mmc_alloc_host() because
device-managed functions typically have the device argument first.

Signed-off-by: Heiner Kallweit <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2
# 1dd611a9 19-Aug-2022 Heiner Kallweit <[email protected]>

mmc: core: Switch to basic workqueue API for sdio_irq_work

The delay parameter isn't set by any user, therefore simplify the code
and switch to the basic workqueue API w/o delay support. This also
r

mmc: core: Switch to basic workqueue API for sdio_irq_work

The delay parameter isn't set by any user, therefore simplify the code
and switch to the basic workqueue API w/o delay support. This also
reduces the size of struct mmc_host.

Signed-off-by: Heiner Kallweit <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1
# 91f059c9 27-May-2022 Shaik Sajida Bhanu <[email protected]>

mmc: core: Capture eMMC and SD card errors

Add changes to capture eMMC and SD card errors.
This is useful for debug and testing.

Signed-off-by: Liangliang Lu <[email protected]>
Signed-off-b

mmc: core: Capture eMMC and SD card errors

Add changes to capture eMMC and SD card errors.
This is useful for debug and testing.

Signed-off-by: Liangliang Lu <[email protected]>
Signed-off-by: Sayali Lokhande <[email protected]>
Signed-off-by: Bao D. Nguyen <[email protected]>
Signed-off-by: Ram Prakash Gupta <[email protected]>
Signed-off-by: Shaik Sajida Bhanu <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2
# 32f18e59 08-Apr-2022 Wolfram Sang <[email protected]>

mmc: improve API to make clear hw_reset callback is for cards

To make it unambiguous that the hw_reset callback is for cards and not
for controllers, we add 'card' to the callback name and convert a

mmc: improve API to make clear hw_reset callback is for cards

To make it unambiguous that the hw_reset callback is for cards and not
for controllers, we add 'card' to the callback name and convert all
users in one go. We keep the argument as mmc_host, though, because the
callback is used very early when mmc_card is not yet populated.

Signed-off-by: Wolfram Sang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7
# cb77cb5a 18-Oct-2021 Eric Biggers <[email protected]>

blk-crypto: rename blk_keyslot_manager to blk_crypto_profile

blk_keyslot_manager is misnamed because it doesn't necessarily manage
keyslots. It actually does several different things:

- Contains

blk-crypto: rename blk_keyslot_manager to blk_crypto_profile

blk_keyslot_manager is misnamed because it doesn't necessarily manage
keyslots. It actually does several different things:

- Contains the crypto capabilities of the device.

- Provides functions to control the inline encryption hardware.
Originally these were just for programming/evicting keyslots;
however, new functionality (hardware-wrapped keys) will require new
functions here which are unrelated to keyslots. Moreover,
device-mapper devices already (ab)use "keyslot_evict" to pass key
eviction requests to their underlying devices even though
device-mapper devices don't have any keyslots themselves (so it
really should be "evict_key", not "keyslot_evict").

- Sometimes (but not always!) it manages keyslots. Originally it
always did, but device-mapper devices don't have keyslots
themselves, so they use a "passthrough keyslot manager" which
doesn't actually manage keyslots. This hack works, but the
terminology is unnatural. Also, some hardware doesn't have keyslots
and thus also uses a "passthrough keyslot manager" (support for such
hardware is yet to be upstreamed, but it will happen eventually).

Let's stop having keyslot managers which don't actually manage keyslots.
Instead, rename blk_keyslot_manager to blk_crypto_profile.

This is a fairly big change, since for consistency it also has to update
keyslot manager-related function names, variable names, and comments --
not just the actual struct name. However it's still a fairly
straightforward change, as it doesn't change any actual functionality.

Acked-by: Ulf Hansson <[email protected]> # For MMC
Reviewed-by: Mike Snitzer <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>

show more ...


# 1e8d44bd 18-Oct-2021 Eric Biggers <[email protected]>

blk-crypto: rename keyslot-manager files to blk-crypto-profile

In preparation for renaming struct blk_keyslot_manager to struct
blk_crypto_profile, rename the keyslot-manager.h and keyslot-manager.c

blk-crypto: rename keyslot-manager files to blk-crypto-profile

In preparation for renaming struct blk_keyslot_manager to struct
blk_crypto_profile, rename the keyslot-manager.h and keyslot-manager.c
source files. Renaming these files separately before making a lot of
changes to their contents makes it easier for git to understand that
they were renamed.

Acked-by: Ulf Hansson <[email protected]> # For MMC
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Mike Snitzer <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>

show more ...


Revision tags: v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2
# f614fb60 17-Sep-2021 Wenbin Mei <[email protected]>

mmc: core: Add host specific tuning support for eMMC HS400 mode

This adds a ->execute_hs400_tuning() host callback to enable optional
support for host specific tuning for eMMC HS400 mode. Additional

mmc: core: Add host specific tuning support for eMMC HS400 mode

This adds a ->execute_hs400_tuning() host callback to enable optional
support for host specific tuning for eMMC HS400 mode. Additionally, share
mmc_get_ext_csd() through the public host headerfile, to allow it to be
used by the host drivers, which is needed to support the HS400 tuning.

Signed-off-by: Wenbin Mei <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v5.15-rc1, v5.14, v5.14-rc7
# dc913385 20-Aug-2021 Dmitry Osipenko <[email protected]>

mmc: block: Support alternative_gpt_sector() operation

Support generic alternative_gpt_sector() block device operation.
It calculates location of GPT entry for eMMC of NVIDIA Tegra Android
devices.

mmc: block: Support alternative_gpt_sector() operation

Support generic alternative_gpt_sector() block device operation.
It calculates location of GPT entry for eMMC of NVIDIA Tegra Android
devices. Add new MMC_CAP2_ALT_GPT_TEGRA flag that enables scanning of
alternative GPT sector and add raw_boot_mult field to mmc_ext_csd
which allows to get size of the boot partitions that is needed for
the calculation.

Signed-off-by: Dmitry Osipenko <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>

show more ...


# 291ee9d5 16-Aug-2021 Mårten Lindahl <[email protected]>

mmc: core: Update ->card_busy() callback comment

According to SD specification checking state of DAT0 only, is enough while
polling for card busy completion. Let's update the comment in the header
f

mmc: core: Update ->card_busy() callback comment

According to SD specification checking state of DAT0 only, is enough while
polling for card busy completion. Let's update the comment in the header
file to correct this, as the comment says DAT[0:3].

Signed-off-by: Mårten Lindahl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


Revision tags: v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6
# 21adc2e4 08-Jun-2021 Wolfram Sang <[email protected]>

mmc: Improve function name when aborting a tuning cmd

'mmc_abort_tuning()' made me think tuning gets completely aborted.
However, it sends only a STOP cmd to cancel the current tuning cmd.
Tuning pr

mmc: Improve function name when aborting a tuning cmd

'mmc_abort_tuning()' made me think tuning gets completely aborted.
However, it sends only a STOP cmd to cancel the current tuning cmd.
Tuning process may still continue after that. So, rename the function to
'mmc_send_abort_tuning()' to better reflect all this.

Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Niklas Söderlund <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...


1234567891011