Device/vendor ids from Common CIS (Card Information Structure) may be different as device/vendor ids from CIS on particular SDIO function. Kernel currently exports only device/vendor ids from SDIO functions and not "main" device/vendor ids from Common CIS. This patch exports "main" device/vendor ids for SDIO and SD combo cards at top level mmc device in sysfs hierarchy. Userspace can use e.g. udev rules to correctly match whole SDIO card based on Common CIS device/vendor id and not only one particular SDIO function. Having this information in userspace also helps developers to debug whole SDIO card as e.g. kernel mmc quirks use device/vendor ids from Common CIS and not from particular SDIO function. Also it allows to write userspace applications which list all connected SDIO cards based on CIS ids. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Link: https://lore.kernel.org/r/20200527110858.17504-2-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
SDIO non-combo cards are not handled by mmc_block driver and do not have accessible CID register which is used for MMC_NAME= construction. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Link: https://lore.kernel.org/r/20200527110858.17504-1-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Marvell SDIO device ID 0x9134 is used in SDIO Common CIS (Card Information Structure) and not in SDIO wlan function (with ID 1). SDIO Common CIS is accessed by function ID 0. So change this misleading macro name to SDIO_DEVICE_ID_MARVELL_8887_F0 as it does not refer to wlan function. It refers to function 0. Wlan module on this SDIO card is available at function ID 1 and is identified by different SDIO device ID 0x9135. Kernel quirks for SDIO devices are matched against device ID from SDIO Common CIS. Therefore device ID used in quirk is correct, just has misleading name. Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20200522144412.19712-2-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Step by step, mmc host drivers and the mmc core have been improved in regards to support erase/discard/trim operations. We have now reached a point when it no longer seems reasonable to use an opt-in approach to enable the functionality. Therefore, let's switch to make the operations always supported. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200508112853.23525-1-ulf.hansson@linaro.org Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
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 <kkonda@codeaurora.org> Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Link: https://lore.kernel.org/r/1588341189-4371-1-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
According to the comment in mmc_sdio_reinit_card(), some SDIO cards may require a "[CMD5,5,3,7] init sequence", which isn't always obeyed in mmc_sdio_init_card(). Especially, when we end up retrying the UHS-I specific initialization, there is a missing CMD5. Let's update the code to make the behaviour consistent and let's also take the opportunity to clean up the code a bit, to avoid open coding. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-5-ulf.hansson@linaro.org
While initializing an SDIO card in mmc_sdio_init_card(), we may need to retry the UHS-I specific initialization, in case the first attempt fails. This leads to resending a CMD8, but also to restart from scratch with the so called OCR mask negotiations. This is unnecessary as we already have a negotiated OCR mask, so let's use that instead. In this way, the behaviour also becomes more consistent with other similar paths. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-4-ulf.hansson@linaro.org
Over the years, the code in mmc_sdio_init_card() has grown to become quite messy. Unfortunate this has also lead to that several paths are leaking memory in form of an allocated struct mmc_card, which includes additional data, such as initialized struct device for example. Unfortunate, it's a too complex task find each offending commit. Therefore, this change fixes all memory leaks at once. Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-3-ulf.hansson@linaro.org
During some scenarios mmc_sdio_init_card() runs a retry path for the UHS-I
specific initialization, which leads to removal of the previously allocated
card. A new card is then re-allocated while retrying.
However, in one of the corresponding error paths we may end up to remove an
already removed card, which likely leads to a NULL pointer exception. So,
let's fix this.
Fixes: 5fc3d80ef496 ("mmc: sdio: don't use rocr to check if the card could support UHS mode")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20200430091640.455-2-ulf.hansson@linaro.org