<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/linux/mmc, branch v5.4.114</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.114</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.114'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-10-01T11:17:20Z</updated>
<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>
<entry>
<title>mmc: core: Add helper function to indicate if SDIO IRQs is enabled</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:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bd880b00697befb73eff7220ee20bdae4fdd487b'/>
<id>urn:sha1:bd880b00697befb73eff7220ee20bdae4fdd487b</id>
<content type='text'>
To avoid each host driver supporting SDIO IRQs, from keeping track
internally about if SDIO IRQs has been claimed, let's introduce a common
helper function, sdio_irq_claimed().

The function returns true if SDIO IRQs are claimed, via using the
information about the number of claimed irqs. This is safe, even without
any locks, as long as the helper function is called only from
runtime/system suspend callbacks of the host driver.

Tested-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>
<entry>
<title>mmc: queue: use bigger segments if DMA MAP layer can merge the segments</title>
<updated>2019-09-03T06:32:58Z</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2019-08-28T12:35:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=38c38cb73223218f6eedf485280917af1f8a0af2'/>
<id>urn:sha1:38c38cb73223218f6eedf485280917af1f8a0af2</id>
<content type='text'>
When the max_segs of a mmc host is smaller than 512, the mmc
subsystem tries to use 512 segments if DMA MAP layer can merge
the segments, and then the mmc subsystem exposes such information
to the block layer by using blk_queue_can_use_dma_map_merging().

Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Reviewed-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Simon Horman &lt;horms+renesas@verge.net.au&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>Merge tag 'mmc-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc</title>
<updated>2019-07-12T01:11:21Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-07-12T01:11:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8931084c0d017314ad025f19353f7c5c1d3782d8'/>
<id>urn:sha1:8931084c0d017314ad025f19353f7c5c1d3782d8</id>
<content type='text'>
Pull MMC updates from Ulf Hansson:
 "MMC core:
   - Let the dma map ops deal with bouncing and drop dma_max_pfn() from
     the dma-mapping interface for ARM
   - Convert the generic MMC DT doc to YAML schemas
   - Drop questionable support for powered-on re-init of SDIO cards at
     runtime resume and for SDIO HW reset
   - Prevent questionable re-init of powered-on removable SDIO cards at
     system resume
   - Cleanup and clarify some SDIO core code

  MMC host:
   - tmio: Make runtime PM enablement more flexible for variants
   - tmio/renesas_sdhi: Rename DT doc tmio_mmc.txt to renesas,sdhi.txt
     to clarify
   - sdhci-pci: Add support for Intel EHL
   - sdhci-pci-o2micro: Enable support for 8-bit bus
   - sdhci-msm: Prevent acquiring a mutex while holding a spin_lock
   - sdhci-of-esdhc: Improve clock management and tuning
   - sdhci_am654: Enable support for 4 and 8-bit bus on J721E
   - sdhci-sprd: Use pinctrl for a proper signal voltage switch
   - sdhci-sprd: Add support for HS400 enhanced strobe mode
   - sdhci-sprd: Enable PHY DLL and allow delay config to stabilize the
     clock
   - sdhci-sprd: Add support for optional gate clock
   - sunxi-mmc: Convert DT doc to YAML schemas
   - meson-gx: Add support for broken DRAM access for DMA

  MEMSTICK core:
   - Fixup error path of memstick_init()"

* tag 'mmc-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (52 commits)
  mmc: sdhci_am654: Add dependency on MMC_SDHCI_AM654
  mmc: alcor: remove a redundant greater or equal to zero comparison
  mmc: sdhci-msm: fix mutex while in spinlock
  mmc: sdhci_am654: Make some symbols static
  dma-mapping: remove dma_max_pfn
  mmc: core: let the dma map ops handle bouncing
  dt-binding: mmc: rename tmio_mmc.txt to renesas,sdhi.txt
  mmc: sdhci-sprd: Add pin control support for voltage switch
  dt-bindings: mmc: sprd: Add pinctrl support
  mmc: sdhci-sprd: Add start_signal_voltage_switch ops
  mmc: sdhci-pci: Add support for Intel EHL
  mmc: tmio: Use dma_max_mapping_size() instead of a workaround
  mmc: sdio: Drop unused in-parameter from mmc_sdio_init_card()
  mmc: sdio: Drop unused in-parameter to mmc_sdio_reinit_card()
  mmc: sdio: Don't re-initialize powered-on removable SDIO cards at resume
  mmc: sdio: Drop powered-on re-init at runtime resume and HW reset
  mmc: sdio: Move comment about re-initialization to mmc_sdio_reinit_card()
  mmc: sdio: Drop mmc_claim|release_host() in mmc_sdio_power_restore()
  mmc: sdio: Turn sdio_run_irqs() into static
  mmc: sdhci: Fix indenting on SDHCI_CTRL_8BITBUS
  ...
</content>
</entry>
</feed>
