user/sven/linux.git/include/linux/mmc/card.h, branch v5.15.2

mmc: block: Support alternative_gpt_sector() operation

2021-08-24T16:09:06Z

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 Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/20210820004536.15791-4-digetx@gmail.com Signed-off-by: Jens Axboe

mmc: core: Add support for cache ctrl for SD cards

2021-06-14T11:57:38Z

In SD spec v6.x the SD function extension registers for performance enhancements were introduced. As a part of this an optional internal cache on the SD card, can be used to improve performance. The let the SD card use the cache, the host needs to enable it and manage flushing of the cache, so let's add support for this. Note that for an SD card supporting the cache it's mandatory for it, to also support the poweroff notification feature. According to the SD spec, if the cache has been enabled and a poweroff notification is sent to the card, that implicitly also means that the card should flush its internal cache. Therefore, dealing with cache flushing for REQ_OP_FLUSH block requests is sufficient. Reviewed-by: Linus Walleij Signed-off-by: Ulf Hansson Reviewed-by: Avri Altman Link: https://lore.kernel.org/r/20210511101359.83521-1-ulf.hansson@linaro.org

mmc: core: Read performance enhancements registers for SD cards

2021-06-14T11:57:36Z

In SD spec v6.x the SD function extension registers for performance enhancements were introduced. These registers let the SD card announce supports for various performance related features, like "self-maintenance", "cache" and "command queuing". Let's extend the parsing of SD function extension registers and store the information in the struct mmc_card. This prepares for subsequent changes to implement the complete support for new the performance enhancement features. Signed-off-by: Ulf Hansson Acked-by: Avri Altman Reviewed-by: Linus Walleij Reviewed-by: Shawn Lin Link: https://lore.kernel.org/r/20210504161222.101536-11-ulf.hansson@linaro.org

mmc: core: Read the SD function extension registers for power management

2021-06-14T11:57:36Z

In the SD spec v4.0 the CMD48/49 and CMD58/59 were introduced as optional commands. In the SD spec v4.1 the SD function extension registers were introduced, which requires support for CMD48/49/58/59 to be read/written from/to. Moreover, a specific function extension register were added to let the card announce support for optional features in regards to power management. The features that were added are "Power Off Notification", "Power Down Mode" and "Power Sustenance". As a first step to support this, let's read and parse the register for power management during the SD card initialization and store the information about the supported features in the struct mmc_card. In this way, we prepare for subsequent changes to implement the complete support for the new features. Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij Reviewed-by: Shawn Lin Acked-by: Avri Altman Link: https://lore.kernel.org/r/20210504161222.101536-10-ulf.hansson@linaro.org

mmc: core: Parse the SD SCR register for support of CMD48/49 and CMD58/59

2021-06-14T11:57:36Z

In SD spec v4.x the support for CMD48/49 and CMD58/59 were introduced as optional features. To let the card announce whether it supports the commands, the SCR register has been extended with corresponding support bits. Let's parse and store this information for later use. Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij Reviewed-by: Shawn Lin Acked-by: Avri Altman Link: https://lore.kernel.org/r/20210504161222.101536-9-ulf.hansson@linaro.org

mmc: core: Drop redundant bouncesz from struct mmc_card

2021-02-08T11:53:34Z

The commit de3ee99b097d ("mmc: Delete bounce buffer handling") removed the bounce buffer handling from the mmc core, but forgot to remove the bouncesz member from the struct mmc_card, let's fix it. Signed-off-by: Ulf Hansson Link: https://lore.kernel.org/r/20210202101626.64503-1-ulf.hansson@linaro.org

mmc: sdio: Parse CISTPL_VERS_1 major and minor revision numbers

2020-09-07T07:11:28Z

They should indicate compliance of standard. Signed-off-by: Pali Rohár Link: https://lore.kernel.org/r/20200727133837.19086-3-pali@kernel.org Signed-off-by: Ulf Hansson

mmc: core: expose info about enhanced rpmb support

2020-05-28T09:21:03Z

Following eMMC JEDEC JESD84-B51 standard, an enhanced form of rpmb is supported. What this enhanced mode supports is in addition to be able to write one rpmb or two rpmb frames at a time, 32 frames can be written at a time. Expose this information present in ext csd field so that the user space application that wants to make use of this can do so. Signed-off-by: Krishna Konda Signed-off-by: Veerabhadrarao Badiganti Link: https://lore.kernel.org/r/1588341189-4371-1-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson

mmc: core: Fix size overflow for mmc partitions

2019-11-18T09:05:38Z

With large eMMC cards, it is possible to create general purpose partitions that are bigger than 4GB. The size member of the mmc_part struct is only an unsigned int which overflows for gp partitions larger than 4GB. Change this to a u64 to handle the overflow. Signed-off-by: Bradley Bolen Signed-off-by: Ulf Hansson

mmc: core: Re-work HW reset for SDIO cards

2019-11-14T15:28:56Z

It have turned out that it's not a good idea to unconditionally do a power cycle and then to re-initialize the SDIO card, as currently done through mmc_hw_reset() -> mmc_sdio_hw_reset(). This because there may be multiple SDIO func drivers probed, who also shares the same SDIO card. To address these scenarios, one may be tempted to use a notification mechanism, as to allow the core to inform each of the probed func drivers, about an ongoing HW reset. However, supporting such an operation from the func driver point of view, may not be entirely trivial. Therefore, let's use a more simplistic approach to solve the problem, by instead forcing the card to be removed and re-detected, via scheduling a rescan-work. In this way, we can rely on existing infrastructure, as the func driver's ->remove() and ->probe() callbacks, becomes invoked to deal with the cleanup and the re-initialization. This solution may be considered as rather heavy, especially if a func driver doesn't share its card with other func drivers. To address this, let's keep the current immediate HW reset option as well, but run it only when there is one func driver probed for the card. Finally, to allow the caller of mmc_hw_reset(), to understand if the reset is being asynchronously managed from a scheduled work, it returns 1 (propagated from mmc_sdio_hw_reset()). If the HW reset is executed successfully and synchronously it returns 0, which maintains the existing behaviour. Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Ulf Hansson