- 26 Apr, 2024 9 commits
-
-
Krzysztof Kozlowski authored
The local struct sdhci_ops can be made const for code safety. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20240414-mmc-const-sdhci-ops-v2-2-262f81faadac@kernel.orgSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Krzysztof Kozlowski authored
The local struct sdhci_ops can be made const for code safety. Signed-off-by:
-
Andy Shevchenko authored
The irq_handler_t is already defined globally, let's use it in slot-gpio code. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20240410195618.1632778-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Hans de Goede authored
The card-detect GPIO for the microSD slot on Asus T100TA / T100TAM models stopped working under Linux after commit 6fd03f02 ("gpiolib: acpi: support bias pull disable"). The GPIO in question is connected to a mechanical switch in the slot which shorts the pin to GND when a card is inserted. The GPIO pin correctly gets configured with a 20K pull-up by the BIOS, but there is a bug in the DSDT where the GpioInt for the card-detect is configured with a PullNone setting: GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x2710, "\\_SB.GPO0", 0x00, ResourceConsumer, , ) { // Pin list 0x0026 } Linux now actually honors the PullNone setting and disables the 20K pull-up configured by the BIOS. Add a new DMI_QUIRK_SD_CD_ENABLE_PULL_UP quirk which when set calls mmc_gpiod_set_cd_config() to re-enable the pull-up and set this for the Asus T100TA models to fix this. Fixes: 6fd03f02 ("gpiolib: acpi: support bias pull disable") Reviewed-by:
Andy Shevchenko <andy@kernel.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Hans de Goede authored
On the Toshiba WT10-A the microSD slot always reports the card being write-protected, just like on the Toshiba WT8-B. Add a DMI quirk to work around this. Reviewed-by:
-
Hans de Goede authored
The Lenovo Yoga Tablet 2 Pro 1380 sdcard slot has an active high cd pin and a broken wp pin which always reports the card being write-protected. Add a DMI quirk to address both issues. Reviewed-by:
-
Hans de Goede authored
Sort the DMI quirks alphabetically. Reviewed-by:
-
Adrian Hunter authored
Most Bay Trail devices do not enable UHS modes for the external sdcard slot the Lenovo Yoga Tablet 2 830 / 1050 and Lenovo Yoga Tablet 2 Pro 1380 (8", 10" and 13") models however do enable this. Using a UHS cards in these tablets results in errors like this one: [ 225.272001] mmc2: Unexpected interrupt 0x04000000. [ 225.272024] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== [ 225.272034] mmc2: sdhci: Sys addr: 0x0712c400 | Version: 0x0000b502 [ 225.272044] mmc2: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000007 [ 225.272054] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000023 [ 225.272064] mmc2: sdhci: Present: 0x01e20002 | Host ctl: 0x00000016 [ 225.272073] mmc2: sdhci: Power: 0x0000000f | Blk gap: 0x00000000 [ 225.272082] mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x00000107 [ 225.272092] mmc2: sdhci: Timeout: 0x0000000e | Int stat: 0x00000001 [ 225.272101] mmc2: sdhci: Int enab: 0x03ff000b | Sig enab: 0x03ff000b [ 225.272110] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001 [ 225.272119] mmc2: sdhci: Caps: 0x076864b2 | Caps_1: 0x00000004 [ 225.272129] mmc2: sdhci: Cmd: 0x00000c1b | Max curr: 0x00000000 [ 225.272138] mmc2: sdhci: Resp[0]: 0x00000c00 | Resp[1]: 0x00000000 [ 225.272147] mmc2: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000900 [ 225.272155] mmc2: sdhci: Host ctl2: 0x0000000c [ 225.272164] mmc2: sdhci: ADMA Err: 0x00000003 | ADMA Ptr: 0x0712c200 [ 225.272172] mmc2: sdhci: ============================================ which results in IO errors leading to issues accessing the sdcard. 0x04000000 is a so-called "Tuning Error" which sofar the SDHCI driver does not support / enable. Modify the IRQ handler to process these. This fixes UHS microsd cards not working with these tablets. Link: https://lore.kernel.org/r/199bb4aa-c6b5-453e-be37-58bbf468800c@intel.comSigned-off-by:
-
Hans de Goede authored
Some mmc host drivers may need to fixup a card-detection GPIO's config to e.g. enable the GPIO controllers builtin pull-up resistor on devices where the firmware description of the GPIO is broken (e.g. GpioInt with PullNone instead of PullUp in ACPI DSDT). Since this is the exception rather then the rule adding a config parameter to mmc_gpiod_request_cd() seems undesirable, so instead add a new mmc_gpiod_set_cd_config() function. This is simply a wrapper to call gpiod_set_config() on the card-detect GPIO acquired through mmc_gpiod_request_cd(). Reviewed-by:
-
- 25 Apr, 2024 3 commits
-
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/80969cc7c08c613753bdf2270304983ed0dcc2a0.1712757795.git.u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
rtsx_pci_ms_drv_remove() is only called after rtsx_pci_ms_drv_probe() completed successfully. In this case platform_set_drvdata() was called with a non-NULL argument and so platform_get_drvdata() won't return NULL. Simplify by removing the if block with the always false condition. Signed-off-by:
-
- 04 Apr, 2024 9 commits
-
-
Ulf Hansson authored
Merge the mmc fixes for v6.9-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.10. Signed-off-by: -
Krzysztof Kozlowski authored
Core in sdio_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20240403-module-owner-sdio-v2-7-ae46d6b955eb@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
Core in sdio_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20240403-module-owner-sdio-v2-6-ae46d6b955eb@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
Core in sdio_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://lore.kernel.org/r/20240403-module-owner-sdio-v2-5-ae46d6b955eb@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
Core in sdio_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240403-module-owner-sdio-v2-4-ae46d6b955eb@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
This driver's initialization functions do not perform any custom code, except printing messages. Printing messages on modules loading/unloading is discouraged because it pollutes the dmesg regardless whether user actually has this device. Core kernel code already gives tools to investigate whether module was loaded or not. Drop the printing messages which allows to replace open-coded module_sdio_driver(). Acked-by:
-
Krzysztof Kozlowski authored
Core in sdio_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
-
Krzysztof Kozlowski authored
Core in sdio_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
-
Maksim Kiselev authored
Fix SD card tuning error by increasing tuning loop count from 40(MAX_TUNING_LOOP) to 128. For some reason the tuning algorithm requires to move through all the taps of delay line even if the THRESHOLD_MODE (bit 2 in AT_CTRL_R) is used instead of the LARGEST_WIN_MODE. Tested-by:
Drew Fustini <drew@pdp7.com> Tested-by:
Xi Ruoyao <xry111@xry111.site> Signed-off-by:
Maksim Kiselev <bigunclemax@gmail.com> Acked-by:
-
- 02 Apr, 2024 19 commits
-
-
Ulf Hansson authored
Merge the mmc fixes for v6.9-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.10. Signed-off-by: -
Krzysztof Kozlowski authored
Modules registering driver with sdio_register_driver() might forget to set .owner field. The field is used by some of other kernel parts for reference counting (try_module_get()), so it is expected that drivers will set it. Solve the problem by moving this task away from the drivers to the core code, just like we did for platform_driver in commit 9447057e ("platform_device: use a macro instead of platform_driver_register"). Since many drivers forget to set the .owner, this effectively will fix them. Examples of fixed drivers are: ath6kl, b43, btsdio.c, ks7010, libertas, MediaTek WiFi drivers, Realtek WiFi drivers, rsi, siano, wilc1000, wl1251 and more. Signed-off-by:
-
Bjorn Helgaas authored
d7133797 ("mmc: sdhci-pci-gli: A workaround to allow GL9750 to enter ASPM L1.2") and 36ed2fd3 ("mmc: sdhci-pci-gli: A workaround to allow GL9755 to enter ASPM L1.2") added writes to the Control register in the Power Management Capability to put the device in D3hot and back to D0. Use the pci_set_power_state() interface instead because these are generic operations that don't need to be driver-specific. Also, the PCI spec requires some delays after these power transitions, and pci_set_power_state() takes care of those, while d7133797 and 36ed2fd3 did not. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Ben Chuang <ben.chuang@genesyslogic.com.tw> Link: https://lore.kernel.org/r/20240327214831.1544595-3-helgaas@kernel.orgSigned-off-by:
-
Bjorn Helgaas authored
015c9cbc ("mmc: sdhci-pci-gli: GL9750: Mask the replay timer timeout of AER") added PCI_GLI_9750_CORRERR_MASK, the offset of the AER Capability in config space, and PCI_GLI_9750_CORRERR_MASK_REPLAY_TIMER_TIMEOUT, the Replay Timer Timeout bit in the AER Correctable Error Status register. Use pci_find_ext_capability() to locate the AER Capability and use the existing PCI_ERR_COR_REP_TIMER definition to mask the bit. This removes a little bit of unnecessarily device-specific code and makes AER-related things more greppable. Signed-off-by:
-
Angelo Dureghello authored
Update my e-mail address to adureghello@baylibre.com. Signed-off-by:
Angelo Dureghello <adureghello@baylibre.com> Link: https://lore.kernel.org/r/20240326164733.15271-1-adureghello@baylibre.comSigned-off-by:
-
Rouven Czerwinski authored
This is useful to check if a quirk has been applied for the connected mmc card. Signed-off-by:
Rouven Czerwinski <r.czerwinski@pengutronix.de> Link: https://lore.kernel.org/r/20240326094215.212930-2-r.czerwinski@pengutronix.deSigned-off-by:
-
Rouven Czerwinski authored
Convert the existing symbolic permissions to the octal presentation as this is the preferred representation for debugfs permissions. Signed-off-by:
-
Mantas Pucka authored
Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly. Cc: stable@vger.kernel.org Fixes: 67e6db11 ("mmc: sdhci-msm: Add pm_runtime and system PM support") Signed-off-by:
Mantas Pucka <mantas@8devices.com> Acked-by:
-
Wadim Mueller authored
Add a compatible string for the SDHC binding of NXP S32G3 platforms. Here we use "nxp,s32g2-usdhc" as fallback since the s32g2-usdhc driver works also on S32G3 platforms. Signed-off-by:
Wadim Mueller <wafgo01@gmail.com> Acked-by:
-
Uwe Kleine-König authored
Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text) Fixes: b4cff454 ("DaVinci: MMC: MMC/SD controller driver for DaVinci family") Signed-off-by:
-
Sergey Khimich authored
For enabling CQE support just set 'supports-cqe' in your DevTree file for appropriate mmc node. Signed-off-by:
Sergey Khimich <serghox@gmail.com> Acked-by:
-
Sergey Khimich authored
There are could be specific limitations for some mmc controllers for setting cqhci transfer descriptors. So add callback to allow implement driver specific function. Signed-off-by:
-
Judith Mendez authored
The sdhci_am654_set_clock function is also used to enable delay chain, therefore fix comments to be more generic in case we are not enabling DLL. Signed-off-by:
Judith Mendez <jm@ti.com> Acked-by:
-
Judith Mendez authored
While integer type works, the otap_del_sel and itap_del_sel arrays are manipulated as u32, so change array types to u32. Signed-off-by:
-
Judith Mendez authored
While STRB is currently used for DATA and CRC responses, the CMD responses from the device to the host still require ITAPDLY for HS400 timing. Currently what is stored for HS400 is the ITAPDLY from High Speed mode which is incorrect. The ITAPDLY for HS400 speed mode should be the same as ITAPDLY as HS200 timing after tuning is executed. Add the functionality to save ITAPDLY from HS200 tuning and save as HS400 ITAPDLY. Fixes: a161c45f ("mmc: sdhci_am654: Enable DLL only for some speed modes") Signed-off-by:
-
Judith Mendez authored
Add ITAPDLYSEL to sdhci_j721e_4bit_set_clock function. This allows to set the correct ITAPDLY for timings that do not carry out tuning. Fixes: 1accbced ("mmc: sdhci_am654: Add Support for 4 bit IP on J721E") Signed-off-by:
-
Judith Mendez authored
Currently the OTAP/ITAP delay enable functionality is incorrect in the am654_set_clock function. The OTAP delay is not enabled when timing < SDR25 bus speed mode. The ITAP delay is not enabled for timings that do not carry out tuning. Add this OTAP/ITAP delay functionality according to the datasheet [1] OTAPDLYENA and ITAPDLYENA for MMC0. [1] https://www.ti.com/lit/ds/symlink/am62p.pdf Fixes: 8ee5fc0e ("mmc: sdhci_am654: Update OTAPDLY writes") Signed-off-by:
-
Judith Mendez authored
For DDR52 timing, DLL is enabled but tuning is not carried out, therefore the ITAPDLY value in PHY CTRL 4 register is not correct. Fix this by writing ITAPDLY after enabling DLL. Fixes: a161c45f ("mmc: sdhci_am654: Enable DLL only for some speed modes") Signed-off-by:
Andrew Davis <afd@ti.com> Acked-by:
-
Judith Mendez authored
Currently the sdhci_am654 driver only supports one tuning algorithm which should be used only when DLL is enabled. The ITAPDLY is selected from the largest passing window and the buffer is viewed as a circular buffer. The new algorithm should be used when the delay chain is enabled. The ITAPDLY is selected from the largest passing window and the buffer is not viewed as a circular buffer. This implementation is based off of the following paper: [1]. Also add support for multiple failing windows. [1] https://www.ti.com/lit/an/spract9/spract9.pdf Fixes: 13ebeae6 ("mmc: sdhci_am654: Add support for software tuning") Signed-off-by:
-
