<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/linux/mmc, branch v5.4.300</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.300</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.300'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2023-12-13T17:18:15Z</updated>
<entry>
<title>mmc: core: add helpers mmc_regulator_enable/disable_vqmmc</title>
<updated>2023-12-13T17:18:15Z</updated>
<author>
<name>Heiner Kallweit</name>
<email>hkallweit1@gmail.com</email>
</author>
<published>2023-03-11T22:39:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a1f29e995fd7957c6fc1c898a6f22c24bf3524c8'/>
<id>urn:sha1:a1f29e995fd7957c6fc1c898a6f22c24bf3524c8</id>
<content type='text'>
[ Upstream commit 8d91f3f8ae57e6292142ca89f322e90fa0d6ac02 ]

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 &lt;hkallweit1@gmail.com&gt;
Acked-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Link: https://lore.kernel.org/r/71586432-360f-9b92-17f6-b05a8a971bc2@gmail.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Stable-dep-of: 477865af60b2 ("mmc: sdhci-sprd: Fix vqmmc not shutting down after the card was pulled")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Fix ambiguous TRIM and DISCARD arg</title>
<updated>2022-12-08T10:23:04Z</updated>
<author>
<name>Christian Löhle</name>
<email>CLoehle@hyperstone.com</email>
</author>
<published>2022-11-17T14:42:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bfdfe86d839fb539756c130411df4d84da222307'/>
<id>urn:sha1:bfdfe86d839fb539756c130411df4d84da222307</id>
<content type='text'>
commit 489d144563f23911262a652234b80c70c89c978b upstream.

Clean up the MMC_TRIM_ARGS define that became ambiguous with DISCARD
introduction.  While at it, let's fix one usage where MMC_TRIM_ARGS falsely
included DISCARD too.

Fixes: b3bf915308ca ("mmc: core: new discard feature support at eMMC v4.5")
Signed-off-by: Christian Loehle &lt;cloehle@hyperstone.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/11376b5714964345908f3990f17e0701@hyperstone.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Fix hanging on I/O during system suspend for removable cards</title>
<updated>2021-05-11T12:04:03Z</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2021-03-10T15:29:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=909a01b95120248b933b27474bb0d1b9b6fb1ffa'/>
<id>urn:sha1:909a01b95120248b933b27474bb0d1b9b6fb1ffa</id>
<content type='text'>
commit 17a17bf50612e6048a9975450cf1bd30f93815b5 upstream.

The mmc core uses a PM notifier to temporarily during system suspend, turn
off the card detection mechanism for removal/insertion of (e)MMC/SD/SDIO
cards. Additionally, the notifier may be used to remove an SDIO card
entirely, if a corresponding SDIO functional driver don't have the system
suspend/resume callbacks assigned. This behaviour has been around for a
very long time.

However, a recent bug report tells us there are problems with this
approach. More precisely, when receiving the PM_SUSPEND_PREPARE
notification, we may end up hanging on I/O to be completed, thus also
preventing the system from getting suspended.

In the end what happens, is that the cancel_delayed_work_sync() in
mmc_pm_notify() ends up waiting for mmc_rescan() to complete - and since
mmc_rescan() wants to claim the host, it needs to wait for the I/O to be
completed first.

Typically, this problem is triggered in Android, if there is ongoing I/O
while the user decides to suspend, resume and then suspend the system
again. This due to that after the resume, an mmc_rescan() work gets punted
to the workqueue, which job is to verify that the card remains inserted
after the system has resumed.

To fix this problem, userspace needs to become frozen to suspend the I/O,
prior to turning off the card detection mechanism. Therefore, let's drop
the PM notifiers for mmc subsystem altogether and rely on the card
detection to be turned off/on as a part of the system_freezable_wq, that we
are already using.

Moreover, to allow and SDIO card to be removed during system suspend, let's
manage this from a -&gt;prepare() callback, assigned at the mmc_host_class
level. In this way, we can use the parent device (the mmc_host_class
device), to remove the card device that is the child, in the
device_prepare() phase.

Reported-by: Kiwoong Kim &lt;kwmad.kim@samsung.com&gt;
Cc: stable@vger.kernel.org # v4.5+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Link: https://lore.kernel.org/r/20210310152900.149380-1-ulf.hansson@linaro.org
Reviewed-by: Kiwoong Kim &lt;kwmad.kim@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Fix size overflow for mmc partitions</title>
<updated>2020-10-01T11:17:20Z</updated>
<author>
<name>Bradley Bolen</name>
<email>bradleybolen@gmail.com</email>
</author>
<published>2019-11-17T01:00:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a21260928bd30bab09c7406b72e79415b2f34fcc'/>
<id>urn:sha1:a21260928bd30bab09c7406b72e79415b2f34fcc</id>
<content type='text'>
[ Upstream commit f3d7c2292d104519195fdb11192daec13229c219 ]

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 &lt;bradleybolen@gmail.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Allow host controllers to require R1B for CMD6</title>
<updated>2020-04-01T09:01:27Z</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2020-03-24T18:07:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d9c4f387e22a5795e32052dee978f801c14207bc'/>
<id>urn:sha1:d9c4f387e22a5795e32052dee978f801c14207bc</id>
<content type='text'>
[ Upstream commit 1292e3efb149ee21d8d33d725eeed4e6b1ade963 ]

It has turned out that some host controllers can't use R1B for CMD6 and
other commands that have R1B associated with them. Therefore invent a new
host cap, MMC_CAP_NEED_RSP_BUSY to let them specify this.

In __mmc_switch(), let's check the flag and use it to prevent R1B responses
from being converted into R1. Note that, this also means that the host are
on its own, when it comes to manage the busy timeout.

Suggested-by: Sowjanya Komatineni &lt;skomatineni@nvidia.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Tested-by: Anders Roxell &lt;anders.roxell@linaro.org&gt;
Tested-by: Sowjanya Komatineni &lt;skomatineni@nvidia.com&gt;
Tested-by: Faiz Abbas &lt;faiz_abbas@ti.com&gt;
Tested-By: Peter Geis &lt;pgwipeout@gmail.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdio: fix wl1251 vendor id</title>
<updated>2020-01-26T09:01:07Z</updated>
<author>
<name>H. Nikolaus Schaller</name>
<email>hns@goldelico.com</email>
</author>
<published>2019-11-07T10:30:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f8afdceb9f2b13f9f732f944db94f9df8a533559'/>
<id>urn:sha1:f8afdceb9f2b13f9f732f944db94f9df8a533559</id>
<content type='text'>
[ Upstream commit e5db673e7fe2f971ec82039a28dc0811c2100e87 ]

v4.11-rc1 did introduce a patch series that rearranged the
sdio quirks into a header file. Unfortunately this did forget
to handle SDIO_VENDOR_ID_TI differently between wl1251 and
wl1271 with the result that although the wl1251 was found on
the sdio bus, the firmware did not load any more and there was
no interface registration.

This patch defines separate constants to be used by sdio quirks
and drivers.

Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file")
Signed-off-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.11+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Re-work HW reset for SDIO cards</title>
<updated>2019-12-21T10:04:24Z</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2019-10-17T13:25:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1a35dfb2a1fd1e6d33fbc7a8a6011b7b7160605f'/>
<id>urn:sha1:1a35dfb2a1fd1e6d33fbc7a8a6011b7b7160605f</id>
<content type='text'>
commit 2ac55d5e5ec9ad0a07e194f0eaca865fe5aa3c40 upstream.

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() -&gt; 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 -&gt;remove() and -&gt;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 &lt;dianders@chromium.org&gt;
Tested-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge tag 'dma-mapping-5.4' of git://git.infradead.org/users/hch/dma-mapping</title>
<updated>2019-09-19T20:27:23Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-09-19T20:27:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=671df189537883f36cf9c7d4f9495bfac0f86627'/>
<id>urn:sha1:671df189537883f36cf9c7d4f9495bfac0f86627</id>
<content type='text'>
Pull dma-mapping updates from Christoph Hellwig:

 - add dma-mapping and block layer helpers to take care of IOMMU merging
   for mmc plus subsequent fixups (Yoshihiro Shimoda)

 - rework handling of the pgprot bits for remapping (me)

 - take care of the dma direct infrastructure for swiotlb-xen (me)

 - improve the dma noncoherent remapping infrastructure (me)

 - better defaults for -&gt;mmap, -&gt;get_sgtable and -&gt;get_required_mask
   (me)

 - cleanup mmaping of coherent DMA allocations (me)

 - various misc cleanups (Andy Shevchenko, me)

* tag 'dma-mapping-5.4' of git://git.infradead.org/users/hch/dma-mapping: (41 commits)
  mmc: renesas_sdhi_internal_dmac: Add MMC_CAP2_MERGE_CAPABLE
  mmc: queue: Fix bigger segments usage
  arm64: use asm-generic/dma-mapping.h
  swiotlb-xen: merge xen_unmap_single into xen_swiotlb_unmap_page
  swiotlb-xen: simplify cache maintainance
  swiotlb-xen: use the same foreign page check everywhere
  swiotlb-xen: remove xen_swiotlb_dma_mmap and xen_swiotlb_dma_get_sgtable
  xen: remove the exports for xen_{create,destroy}_contiguous_region
  xen/arm: remove xen_dma_ops
  xen/arm: simplify dma_cache_maint
  xen/arm: use dev_is_dma_coherent
  xen/arm: consolidate page-coherent.h
  xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance
  arm: remove wrappers for the generic dma remap helpers
  dma-mapping: introduce a dma_common_find_pages helper
  dma-mapping: always use VM_DMA_COHERENT for generic DMA remap
  vmalloc: lift the arm flag for coherent mappings to common code
  dma-mapping: provide a better default -&gt;get_required_mask
  dma-mapping: remove the dma_declare_coherent_memory export
  remoteproc: don't allow modular build
  ...
</content>
</entry>
<entry>
<title>mmc: queue: Fix bigger segments usage</title>
<updated>2019-09-12T12:14:09Z</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2019-09-12T04:13:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=427b00342c5a3ebcf31fac2ce3b21fb993952816'/>
<id>urn:sha1:427b00342c5a3ebcf31fac2ce3b21fb993952816</id>
<content type='text'>
The commit 38c38cb73223 ("mmc: queue: use bigger segments if DMA MAP
layer can merge the segments") always enables the bugger segments
if DMA MAP layer can merge the segments, but some controllers (SDHCI)
have strictly limitation about the segments size, and then the commit
breaks on the controllers.

To fix the issue, this patch adds a new flag MMC_CAP2_MERGE_CAPABLE
into the struct mmc_host and the bigger segments usage is disabled
as default.

Reported-by: Thierry Reding &lt;treding@nvidia.com&gt;
Fixes: 38c38cb73223 ("mmc: queue: use bigger segments if DMA MAP layer can merge the segments")
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>mmc: core: Clarify that the -&gt;ack_sdio_irq() callback is mandatory</title>
<updated>2019-09-11T14:10:18Z</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2019-09-08T10:12:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2c32dbbb5fc09a26e3a1c39bbf57537c54ed3e91'/>
<id>urn:sha1:2c32dbbb5fc09a26e3a1c39bbf57537c54ed3e91</id>
<content type='text'>
For the MMC_CAP2_SDIO_IRQ_NOTHREAD case and when using sdio_signal_irq(),
the -&gt;ack_sdio_irq() is already mandatory, which was not the case for those
host drivers that called sdio_run_irqs() directly.

As there are no longer any drivers calling sdio_run_irqs(), let's clarify
the code by dropping the unnecessary check and explicitly state that the
callback is mandatory in the header file.

Tested-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Reviewed-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
</feed>
