<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Kconfig</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>b6c41df3 - mmc: block: add RPMB dependency</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#b6c41df3</link>
        <description>mmc: block: add RPMB dependencyPrevent build error when CONFIG_RPMB=m and CONFIG_MMC_BLOCK=y by addinga dependency to CONFIG_RPMB for CONFIG_MMC_BLOCK block so the RPMBsubsystem always is reachable if configured. This means thatCONFIG_MMC_BLOCK automatically becomes compiled as a module ifCONFIG_RPMB is compiled as a module. If CONFIG_RPMB isn&apos;t configured oris configured as built-in, CONFIG_MMC_BLOCK will remain unchanged.Reported-by: kernel test robot &lt;lkp@intel.com&gt;Closes: https://lore.kernel.org/oe-kbuild-all/202409021448.RSvcBPzt-lkp@intel.com/Fixes: 7852028a35f0 (&quot;mmc: block: register RPMB partition with the RPMB subsystem&quot;)Signed-off-by: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;Link: https://lore.kernel.org/r/20240902151231.3705204-1-jens.wiklander@linaro.orgSigned-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Mon, 02 Sep 2024 15:12:30 +0000</pubDate>
        <dc:creator>Jens Wiklander &lt;jens.wiklander@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>1444fed2 - mmc: core: Imply IOSCHED_BFQ</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#1444fed2</link>
        <description>mmc: core: Imply IOSCHED_BFQIf we enable the MMC/SD block layer, use Kconfig to imply the BFQI/O scheduler.As all MMC/SD devices are single-queue, this is the scheduler thatusers want so let&apos;s be helpful and make sure it getsdefault-selected into a manual kernel configuration. It will stillneed to be enabled at runtime (usually with udev scripts).Cc: linux-block@vger.kernel.orgCc: Paolo Valente &lt;paolo.valente@linaro.org&gt;Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;Link: https://lore.kernel.org/r/20230131084742.1038135-1-linus.walleij@linaro.orgSigned-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Tue, 31 Jan 2023 08:47:42 +0000</pubDate>
        <dc:creator>Linus Walleij &lt;linus.walleij@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>05f0430f - mmc: pwrseq_sd8787: Allow being built-in irrespective of dependencies</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#05f0430f</link>
        <description>mmc: pwrseq_sd8787: Allow being built-in irrespective of dependenciespwrseq_sd8787 is forced to be built as a module if its dependencies are.That&apos;s unnecessary, it&apos;s perfectly fine for it to be built-in eventhough the wireless drivers that need it are modules.Relax the depends definition in Kconfig accordingly.Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;Cc: Matt Ranostay &lt;matt@ranostay.consulting&gt;Cc: Lubomir Rintel &lt;lkundrak@v3.sk&gt;Cc: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;Link: https://lore.kernel.org/r/8bb3d7c3a36985e030ba40e853c57578de8fb303.1673866725.git.lukas@wunner.deSigned-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Mon, 16 Jan 2023 11:14:30 +0000</pubDate>
        <dc:creator>Lukas Wunner &lt;lukas@wunner.de&gt;</dc:creator>
    </item>
<item>
        <title>09cedbd8 - mmc: pwrseq: add wilc1000_sdio dependency for pwrseq_sd8787</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#09cedbd8</link>
        <description>mmc: pwrseq: add wilc1000_sdio dependency for pwrseq_sd8787pwseq_sd8787 could also be used with wilc1000_sdio driver. Adda dependency for this.Signed-off-by: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;Link: https://lore.kernel.org/r/20210820092803.78523-4-claudiu.beznea@microchip.comSigned-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Fri, 20 Aug 2021 09:28:02 +0000</pubDate>
        <dc:creator>Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;</dc:creator>
    </item>
<item>
        <title>93f1c150 - mmc: core: Add basic support for inline encryption</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#93f1c150</link>
        <description>mmc: core: Add basic support for inline encryptionIn preparation for adding CQHCI crypto engine (inline encryption)support, add the code required to make mmc_core and mmc_block aware ofinline encryption.  Specifically:- Add a capability flag MMC_CAP2_CRYPTO to struct mmc_host.  Drivers  will set this if the host and driver support inline encryption.- Embed a blk_keyslot_manager in struct mmc_host.  Drivers will  initialize this (as a device-managed resource) if the host and driver  support inline encryption.  mmc_block registers this keyslot manager  with the request_queue of any MMC card attached to the host.- Make mmc_block copy the crypto keyslot and crypto data unit number  from struct request to struct mmc_request, so that drivers will have  access to them.- If the MMC host is reset, reprogram all the keyslots to ensure that  the software state stays in sync with the hardware state.Co-developed-by: Satya Tangirala &lt;satyat@google.com&gt;Signed-off-by: Satya Tangirala &lt;satyat@google.com&gt;Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;Reviewed-by: Satya Tangirala &lt;satyat@google.com&gt;Reviewed-and-tested-by: Peng Zhou &lt;peng.zhou@mediatek.com&gt;Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;Link: https://lore.kernel.org/r/20210126001456.382989-2-ebiggers@kernel.orgSigned-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Tue, 26 Jan 2021 00:14:48 +0000</pubDate>
        <dc:creator>Eric Biggers &lt;ebiggers@google.com&gt;</dc:creator>
    </item>
<item>
        <title>ec8f24b7 - treewide: Add SPDX license identifier - Makefile/Kconfig</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#ec8f24b7</link>
        <description>treewide: Add SPDX license identifier - Makefile/KconfigAdd SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any formThese files fall under the project license, GPL v2 only. The resulting SPDXlicense identifier is:  GPL-2.0-onlySigned-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Sun, 19 May 2019 12:07:45 +0000</pubDate>
        <dc:creator>Thomas Gleixner &lt;tglx@linutronix.de&gt;</dc:creator>
    </item>
<item>
        <title>ac379b7c - mmc: core: Allow building PWRSEQ_SD8787 with LIBERTAS_SDIO</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#ac379b7c</link>
        <description>mmc: core: Allow building PWRSEQ_SD8787 with LIBERTAS_SDIOThe sd8686 &quot;libertas&quot; SDIO adapter&apos;s power is controlled with WLAN_RSTand WLAN_PD pins -- pretty much the same way as sd8787. Allow buildingthe power sequencing driver along with the libertas Wi-Fi driver.Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Mon, 24 Sep 2018 08:56:32 +0000</pubDate>
        <dc:creator>Lubomir Rintel &lt;lkundrak@v3.sk&gt;</dc:creator>
    </item>
<item>
        <title>c3dccb74 - mmc: core: Delete bounce buffer Kconfig option</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#c3dccb74</link>
        <description>mmc: core: Delete bounce buffer Kconfig optionThis option is activated by all multiplatform configs and whatnot so we almost always have it turned on, and the memory itsaves is negligible, even more so moving forward. The actualbounce buffer only gets allocated only when used, the onlything the ifdefs are saving is a little bit of code.It is highly improper to have this as a Kconfig option thatget turned on by Kconfig, make this a pure runtime-thing andlet the host decide whether we use bounce buffers. We add anew property &quot;disable_bounce&quot; to the host struct.Notice that mmc_queue_calc_bouncesz() already disables thebounce buffers if host-&gt;max_segs != 1, so any arch that has amaximum number of segments higher than 1 will have bouncebuffers disabled.The option CONFIG_MMC_BLOCK_BOUNCE is default y so themajority of platforms in the kernel already have it on, andit then gets turned off at runtime since most of these havea host-&gt;max_segs &gt; 1. The few exceptions that havehost-&gt;max_segs == 1 and still turn off the bounce bufferingare those that disable it in their defconfig.Those are the following:arch/arm/configs/colibri_pxa300_defconfigarch/arm/configs/zeus_defconfig- Uses MMC_PXA, drivers/mmc/host/pxamci.c- Sets host-&gt;max_segs = NR_SG, which is 1- This needs its bounce buffer deactivated so we set  host-&gt;disable_bounce to true in the host driverarch/arm/configs/davinci_all_defconfig- Uses MMC_DAVINCI, drivers/mmc/host/davinci_mmc.c- This driver sets host-&gt;max_segs to MAX_NR_SG, which is 16- That means this driver anyways disabled bounce buffers- No special action needed for this platformarch/arm/configs/lpc32xx_defconfigarch/arm/configs/nhk8815_defconfigarch/arm/configs/u300_defconfig- Uses MMC_ARMMMCI, drivers/mmc/host/mmci.[c|h]- This driver by default sets host-&gt;max_segs to NR_SG,  which is 128, unless a DMA engine is used, and in that case  the number of segments are also &gt; 1- That means this driver already disables bounce buffers- No special action needed for these platformsarch/arm/configs/sama5_defconfig- Uses MMC_SDHCI, MMC_SDHCI_PLTFM, MMC_SDHCI_OF_AT91, MMC_ATMELMCI- Uses drivers/mmc/host/sdhci.c- Normally sets host-&gt;max_segs to SDHCI_MAX_SEGS which is 128 and  thus disables bounce buffers- Sets host-&gt;max_segs to 1 if SDHCI_USE_SDMA is set- SDHCI_USE_SDMA is only set by SDHCI on PCI adapers- That means that for this platform bounce buffers are already  disabled at runtime- No special action needed for this platformarch/blackfin/configs/CM-BF533_defconfigarch/blackfin/configs/CM-BF537E_defconfig- Uses MMC_SPI (a simple MMC card connected on SPI pins)- Uses drivers/mmc/host/mmc_spi.c- Sets host-&gt;max_segs to MMC_SPI_BLOCKSATONCE which is 128- That means this platform already disables bounce buffers at  runtime- No special action needed for these platformsarch/mips/configs/cavium_octeon_defconfig- Uses MMC_CAVIUM_OCTEON, drivers/mmc/host/cavium.c- Sets host-&gt;max_segs to 16 or 1- Setting host-&gt;disable_bounce to be sure for the 1 casearch/mips/configs/qi_lb60_defconfig- Uses MMC_JZ4740, drivers/mmc/host/jz4740_mmc.c- This sets host-&gt;max_segs to 128 so bounce buffers are  already runtime disabled- No action needed for this platformIt would be interesting to come up with a list of the platformsthat actually end up using bounce buffers. I have not beenable to infer such a list, but it occurs whenhost-&gt;max_segs == 1 and the bounce buffering is not explicitlydisabled.Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Thu, 18 May 2017 09:29:31 +0000</pubDate>
        <dc:creator>Linus Walleij &lt;linus.walleij@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>de19b4c9 - mmc: pwrseq: add support for Marvell SD8787 chip</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#de19b4c9</link>
        <description>mmc: pwrseq: add support for Marvell SD8787 chipAllow power sequencing for the Marvell SD8787 Wifi/BT chip.This can be abstracted to other chipsets if needed in the future.Cc: Tony Lindgren &lt;tony@atomide.com&gt;Cc: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;Signed-off-by: Matt Ranostay &lt;matt@ranostay.consulting&gt;Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Tue, 24 Jan 2017 03:08:30 +0000</pubDate>
        <dc:creator>Matt Ranostay &lt;matt@ranostay.consulting&gt;</dc:creator>
    </item>
<item>
        <title>f397c8d8 - mmc: block: Move files to core</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#f397c8d8</link>
        <description>mmc: block: Move files to coreOnce upon a time it made sense to keep the mmc block device driver and itsrelated code, in its own directory called card. Over time, more an morefunctions/structures have become shared through generic mmc header files,between the core and the card directory. In other words, the relationshipbetween them has become closer.By sharing functions/structures via generic header files, it becomes easyfor outside users to abuse them. In a way to avoid that from happen, let&apos;smove the files from card directory into the core directory, as it enablesus to move definitions of functions/structures into mmc core specificheader files.Note, this is only the first step in providing a cleaner mmc interface foroutside users. Following changes will do the actual cleanup, as that is notpart of this change.Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Thu, 08 Dec 2016 10:23:49 +0000</pubDate>
        <dc:creator>Ulf Hansson &lt;ulf.hansson@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>d97a1e5d - mmc: pwrseq: convert to proper platform device</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#d97a1e5d</link>
        <description>mmc: pwrseq: convert to proper platform devicesimple-pwrseq and emmc-pwrseq drivers rely on platform_devicestructure from of_find_device_by_node(), this works mostly. But, as thereis no driver associated with this devices, cases like default/init pinctrlsetup would never be performed by pwrseq. This becomes problem when thegpios used in pwrseq require pinctrl setup.Currently most of the common pinctrl setup is done indrivers/base/pinctrl.c by pinctrl_bind_pins().There are two ways to solve this issue on either convert pwrseq driversto a proper platform drivers or copy the exact code frompcintrl_bind_pins(). I prefer converting pwrseq to proper drivers so thatother cases like setting up clks/parents from dt would also be possible.Signed-off-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Thu, 14 Apr 2016 13:02:16 +0000</pubDate>
        <dc:creator>Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>9eadcc05 - mmc: core: Remove MMC_CLKGATE</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#9eadcc05</link>
        <description>mmc: core: Remove MMC_CLKGATEMMC_CLKGATE was once invented to save power by gating the bus clock atrequest inactivity. At that time it served its purpose. The modern way todeal with power saving for these scenarios, is by using runtime PM.Nowadays, several host drivers have deployed runtime PM, but for thosethat haven&apos;t and which still cares power saving at request inactivity,it&apos;s certainly time to deploy runtime PM as it has been around for severalyears now.To simplify code to mmc core and thus decrease maintenance efforts, thispatch removes all code related to MMC_CLKGATE.Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Fri, 02 Oct 2015 08:56:11 +0000</pubDate>
        <dc:creator>Ulf Hansson &lt;ulf.hansson@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>2501c917 - mmc: core: Use MMC_UNSAFE_RESUME as default behavior</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#2501c917</link>
        <description>mmc: core: Use MMC_UNSAFE_RESUME as default behaviorInvoking system suspend or shutdown without using the Kconfig optionMMC_UNSAFE_RESUME, did trigger an ungraceful power cut of the card.To improve the situation, change the behavior to always make use of theavailable bus_ops callbacks that handles system suspend and shutdownproperly.By changing the behavior MMC_UNSAFE_RESUME becomes redundant, so lets&apos;sremove it.Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;Signed-off-by: Chris Ball &lt;chris@printf.net&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Wed, 30 Oct 2013 00:00:18 +0000</pubDate>
        <dc:creator>Ulf Hansson &lt;ulf.hansson@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>9c905faa - drivers/mmc/core: remove depends on CONFIG_EXPERIMENTAL</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#9c905faa</link>
        <description>drivers/mmc/core: remove depends on CONFIG_EXPERIMENTALThe CONFIG_EXPERIMENTAL config item has not carried much meaning for awhile now and is almost always enabled by default. As agreed during theLinux kernel summit, remove it from any &quot;depends on&quot; lines in Kconfigs.CC: Chris Ball &lt;cjb@laptop.org&gt;Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;Acked-by: Chris Ball &lt;cjb@laptop.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Tue, 02 Oct 2012 18:17:45 +0000</pubDate>
        <dc:creator>Kees Cook &lt;keescook@chromium.org&gt;</dc:creator>
    </item>
<item>
        <title>04566831 - mmc: Aggressive clock gating framework</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#04566831</link>
        <description>mmc: Aggressive clock gating frameworkThis patch modifies the MMC core code to optionally call the set_ios()operation on the driver with the clock frequency set to 0 (gate) aftera grace period of at least 8 MCLK cycles, then restore it (ungate)before any new request. This gives the driver the option to shut downthe MCI clock to the MMC/SD card when the clock frequency is 0, i.e.the core has stated that the MCI clock does not need to be generated.It is inspired by existing clock gating code found in the OMAP andAtmel drivers and brings this up to the host abstraction.  Gating isperformed before and after any MMC request.This patchset implements this for the MMCI/PL180 MMC/SD host controller,but it should be simple to switch OMAP/Atmel over to using this instead.mmc_set_{gated,ungated}() add variable protection to the state holdersfor the clock gating code.  This is particularly important when ordinary.set_ios() calls would race with the .set_ios() call resulting from adelayed gate operation.Signed-off-by: Linus Walleij &lt;linus.walleij@stericsson.com&gt;Reviewed-by: Chris Ball &lt;cjb@laptop.org&gt;Tested-by: Chris Ball &lt;cjb@laptop.org&gt;Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Tue, 09 Nov 2010 02:36:50 +0000</pubDate>
        <dc:creator>Linus Walleij &lt;linus.walleij@stericsson.com&gt;</dc:creator>
    </item>
<item>
        <title>bd68e083 - mmc: add module parameter to set whether cards are assumed removable</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#bd68e083</link>
        <description>mmc: add module parameter to set whether cards are assumed removableSome people run general-purpose distribution kernels on netbooks witha card that is physically non-removable or logically non-removable(e.g. used for /home) and cannot be cleanly unmounted during suspend.Add a module parameter to set whether cards are assumed removable ornon-removable, with the default set by CONFIG_MMC_UNSAFE_RESUME.In general, it is not possible to tell whether a card present in an MMCslot after resume is the same that was there before suspend.  So there aretwo possible behaviours, each of which will cause data loss in some cases:CONFIG_MMC_UNSAFE_RESUME=n (default): Cards are assumed to be removedduring suspend.  Any filesystem on them must be unmounted before suspend;otherwise, buffered writes will be lost.CONFIG_MMC_UNSAFE_RESUME=y: Cards are assumed to remain present duringsuspend.  They must not be swapped during suspend; otherwise, bufferedwrites will be flushed to the wrong card.Currently the choice is made at compile time and this allows that to beoverridden at module load time.Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;Cc: Wouter van Heyst &lt;larstiq@larstiq.dyndns.org&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;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Tue, 15 Dec 2009 02:01:29 +0000</pubDate>
        <dc:creator>Ben Hutchings &lt;ben@decadent.org.uk&gt;</dc:creator>
    </item>
<item>
        <title>790864dc - mmc: Use menuconfig objects</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#790864dc</link>
        <description>mmc: Use menuconfig objectsChange Kconfig objects from &quot;menu, config&quot; into &quot;menuconfig&quot; sothat the user can disable the whole feature without having toenter the menu first.Signed-off-by: Jan Engelhardt &lt;jengelh@gmx.de&gt;Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Tue, 08 May 2007 20:30:32 +0000</pubDate>
        <dc:creator>Jan Engelhardt &lt;jengelh@gmx.de&gt;</dc:creator>
    </item>
<item>
        <title>6abaa0c9 - mmc: support unsafe resume of cards</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/mmc/core/Kconfig#6abaa0c9</link>
        <description>mmc: support unsafe resume of cardsSince many have the system root on MMC/SD we must allow some footshooting when it comes to resume.We cannot detect if a card is removed and reinserted during suspend,so the safe approach would be to assume it was, avoiding potentialfilesystem corruption. This will of course not work if you cannotrelease the card before suspend.This commit adds a compile time option that makes the MMC layerassume the card wasn&apos;t touched if it is redetected upon resume.Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;

            List of files:
            /linux-6.15/drivers/mmc/core/Kconfig</description>
        <pubDate>Tue, 01 May 2007 14:00:02 +0000</pubDate>
        <dc:creator>Pierre Ossman &lt;drzeus@drzeus.cx&gt;</dc:creator>
    </item>
</channel>
</rss>
