- 29 Sep, 2018 12 commits
-
-
Takashi Sakamoto authored
commit 498fe23a upstream. Although private data of sound card instance is usually allocated in the tail of the instance, drivers in ALSA firewire stack allocate the private data before allocating the instance. In this case, the private data should be released explicitly at .private_free callback of the instance. This commit fixes memory leak following to the above design. Fixes: 6c29230e ('ALSA: oxfw: delayed registration of sound card') Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Takashi Sakamoto authored
commit 1064bc68 upstream. After finishing discover of stream formats, ALSA OXFW driver has memory leak of allocated memory object at error path. This commit releases the memory object at the error path. Fixes: 6c29230e ('ALSA: oxfw: delayed registration of sound card') Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by:
-
Takashi Sakamoto authored
commit ce925f08 upstream. After allocating model-dependent data, ALSA OXFW driver has memory leak of the data at error path. This commit releases the data at the error path. Fixes: 6c29230e ('ALSA: oxfw: delayed registration of sound card') Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by:
-
Takashi Sakamoto authored
commit c3b55e2e upstream. After allocating memory object for response buffer, ALSA fireworks driver has leak of the memory object at error path. This commit releases the object at the error path. Fixes: 7d3c1d59('ALSA: fireworks: delayed registration of sound card') Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by:
-
Takashi Sakamoto authored
commit 8d28277c upstream. Although private data of sound card instance is usually allocated in the tail of the instance, drivers in ALSA firewire stack allocate the private data before allocating the instance. In this case, the private data should be released explicitly at .private_free callback of the instance. This commit fixes memory leak following to the above design. Fixes: b610386c ('ALSA: firewire-tascam: deleyed registration of sound card') Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by:
-
Takashi Sakamoto authored
commit a49a83ab upstream. Although private data of sound card instance is usually allocated in the tail of the instance, drivers in ALSA firewire stack allocate the private data before allocating the instance. In this case, the private data should be released explicitly at .private_free callback of the instance. This commit fixes memory leak following to the above design. Fixes: 86c8dd7f ('ALSA: firewire-digi00x: delayed registration of sound card') Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by:
-
Willy Tarreau authored
commit 49434c6c upstream. snd_emu10k1_fx8010_ioctl(SNDRV_EMU10K1_IOCTL_INFO) allocates memory using kmalloc() and partially fills it by calling snd_emu10k1_fx8010_info() before returning the resulting structure to userspace, leaving uninitialized holes. Let's just use kzalloc() here. BugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.htmlSigned-off-by:
Willy Tarreau <w@1wt.eu> Cc: Jann Horn <jannh@google.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Sakamoto authored
commit 493626f2 upstream. When executing 'fw_run_transaction()' with 'TCODE_WRITE_BLOCK_REQUEST', an address of 'payload' argument is used for streaming DMA mapping by 'firewire_ohci' module if 'size' argument is larger than 8 byte. Although in this case the address should not be on kernel stack, current implementation of ALSA bebob driver uses data in kernel stack for a cue to boot M-Audio devices. This often brings unexpected result, especially for a case of CONFIG_VMAP_STACK=y. This commit fixes the bug. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=201021 Reference: https://forum.manjaro.org/t/firewire-m-audio-410-driver-wont-load-firmware/51165 Fixes: a2b2a779('ALSA: bebob: Send a cue to load firmware for M-Audio Firewire series') Cc: <stable@vger.kernel.org> # v3.16+ Signed-off-by:
-
Takashi Sakamoto authored
commit b1fbebd4 upstream. After allocating model-dependent data for M-Audio FW1814 and ProjectMix I/O, ALSA bebob driver has memory leak at error path. This commit releases the allocated data at the error path. Fixes: 04a2c73c('ALSA: bebob: delayed registration of sound card') Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by:
-
Sébastien Szymanski authored
commit 90a3b7f8 upstream. The MMTLR bit is in the CS4265_SPDIF_CTL2 register at address 0x12 bit 0 and not at address 0x0 bit 1. Fix this. Signed-off-by:
Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Suren Baghdasaryan authored
commit e285d5bf upstream. According to ETSI TS 102 622 specification chapter 4.4 pipe identifier is 7 bits long which allows for 128 unique pipe IDs. Because NFC_HCI_MAX_PIPES is used as the number of pipes supported and not as the max pipe ID, its value should be 128 instead of 127. nfc_hci_recv_from_llc extracts pipe ID from packet header using NFC_HCI_FRAGMENT(0x7F) mask which allows for pipe ID value of 127. Same happens when NCI_HCP_MSG_GET_PIPE() is being used. With pipes array having only 127 elements and pipe ID of 127 the OOB memory access will result. Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Allen Pais <allen.pais@oracle.com> Cc: "David S. Miller" <davem@davemloft.net> Suggested-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Suren Baghdasaryan <surenb@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Suren Baghdasaryan authored
commit 674d9de0 upstream. When handling SHDLC I-Frame commands "pipe" field used for indexing into an array should be checked before usage. If left unchecked it might access memory outside of the array of size NFC_HCI_MAX_PIPES(127). Malformed NFC HCI frames could be injected by a malicious NFC device communicating with the device being attacked (remote attack vector), or even by an attacker with physical access to the I2C bus such that they could influence the data transfers on that bus (local attack vector). skb->data is controlled by the attacker and has only been sanitized in the most trivial ways (CRC check), therefore we can consider the create_info struct and all of its members to tainted. 'create_info->pipe' with max value of 255 (uint8) is used to take an offset of the hdev->pipes array of 127 elements which can lead to OOB write. Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Allen Pais <allen.pais@oracle.com> Cc: "David S. Miller" <davem@davemloft.net> Suggested-by:
Kevin Deus <kdeus@google.com> Signed-off-by:
-
- 26 Sep, 2018 28 commits
-
-
Greg Kroah-Hartman authored
-
Benjamin Poirier authored
commit e2710dbf upstream. Alex reported the following race condition: /* link goes up... interrupt... schedule watchdog */ \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link \ e1000e_phy_has_link_generic(..., &link) link = true /* link goes down... interrupt */ \ e1000_msix_other hw->mac.get_link_status = true /* link is up */ mac->get_link_status = false link_active = true /* link_active is true, wrongly, and stays so because * get_link_status is false */ Avoid this problem by making sure that we don't set get_link_status = false after having checked the link. It seems this problem has been present since the introduction of e1000e. Link: https://lkml.org/lkml/2018/1/29/338Reported-by:
Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by:
Benjamin Poirier <bpoirier@suse.com> Acked-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Yanhui He <yanhuih@vmware.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Benjamin Poirier authored
commit 3016e0a0 upstream. This reverts commit 19110cfb. This reverts commit 4110e02e. This reverts commit d3604515c9eda464a92e8e67aae82dfe07fe3c98. Commit 19110cfb ("e1000e: Separate signaling for link check/link up") changed what happens to the link status when there is an error which happens after "get_link_status = false" in the copper check_for_link callbacks. Previously, such an error would be ignored and the link considered up. After that commit, any error implies that the link is down. Revert commit 19110cfb ("e1000e: Separate signaling for link check/link up") and its followups. After reverting, the race condition described in the log of commit 19110cfb is reintroduced. It may still be triggered by LSC events but this should keep the link down in case the link is electrically unstable, as discussed. The race may no longer be triggered by RXO events because commit 4aea7a5c ("e1000e: Avoid receiver overrun interrupt bursts") restored reading icr in the Other handler. Link: https://lkml.org/lkml/2018/3/1/789Signed-off-by:
-
Benjamin Poirier authored
commit 116f4a64 upstream. The 82574 specification update errata 12 states that interrupts may be missed if ICR is read while INT_ASSERTED is not set. Avoid that problem by setting all bits related to events that can trigger the Other interrupt in IMS. The Other interrupt is raised for such events regardless of whether or not they are set in IMS. However, only when they are set is the INT_ASSERTED bit also set in ICR. By doing this, we ensure that INT_ASSERTED is always set when we read ICR in e1000_msix_other() and steer clear of the errata. This also ensures that ICR will automatically be cleared on read, therefore we no longer need to clear bits explicitly. Signed-off-by:
-
Benjamin Poirier authored
commit 361a954e upstream. Restores the ICS write for Rx/Tx queue interrupts which was present before commit 16ecba59 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1) but was not restored in commit 4aea7a5c ("e1000e: Avoid receiver overrun interrupt bursts", v4.15-rc1). This re-raises the queue interrupts in case the txq or rxq bits were set in ICR and the Other interrupt handler read and cleared ICR before the queue interrupt was raised. Fixes: 4aea7a5c ("e1000e: Avoid receiver overrun interrupt bursts") Signed-off-by:
-
Benjamin Poirier authored
commit 1f0ea197 upstream. This partially reverts commit 4aea7a5c. We keep the fix for the first part of the problem (1) described in the log of that commit, that is to read ICR in the other interrupt handler. We remove the fix for the second part of the problem (2), Other interrupt throttling. Bursts of "Other" interrupts may once again occur during rxo (receive overflow) traffic conditions. This is deemed acceptable in the interest of avoiding unforeseen fallout from changes that are not strictly necessary. As discussed, the e1000e driver should be in "maintenance mode". Link: https://www.spinics.net/lists/netdev/msg480675.htmlSigned-off-by:
-
Benjamin Poirier authored
commit 745d0bd3 upstream. It was reported that emulated e1000e devices in vmware esxi 6.5 Build 7526125 do not link up after commit 4aea7a5c ("e1000e: Avoid receiver overrun interrupt bursts", v4.15-rc1). Some tracing shows that after e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other() on emulated e1000e devices. In comparison, on real e1000e 82574 hardware, icr=0x80000004 (_INT_ASSERTED | _LSC) in the same situation. Some experimentation showed that this flaw in vmware e1000e emulation can be worked around by not setting Other in EIAC. This is how it was before 16ecba59 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1). Fixes: 4aea7a5c ("e1000e: Avoid receiver overrun interrupt bursts") Signed-off-by:
-
Paul Burton authored
commit 0f02cfbc upstream. When a system suffers from dcache aliasing a user program may observe stale VDSO data from an aliased cache line. Notably this can break the expectation that clock_gettime(CLOCK_MONOTONIC, ...) is, as its name suggests, monotonic. In order to ensure that users observe updates to the VDSO data page as intended, align the user mappings of the VDSO data page such that their cache colouring matches that of the virtual address range which the kernel will use to update the data page - typically its unmapped address within kseg0. This ensures that we don't introduce aliasing cache lines for the VDSO data page, and therefore that userland will observe updates without requiring cache invalidation. Signed-off-by:
Paul Burton <paul.burton@mips.com> Reported-by:
Hauke Mehrtens <hauke@hauke-m.de> Reported-by:
Rene Nielsen <rene.nielsen@microsemi.com> Reported-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO") Patchwork: https://patchwork.linux-mips.org/patch/20344/Tested-by:
-
Dan Carpenter authored
commit b40b3e93 upstream. We accidentally removed the check for negative returns without considering the issue of type promotion. The "if_version_length" variable is type size_t so if __mei_cl_recv() returns a negative then "bytes_recv" is type promoted to a high positive value and treated as success. Cc: <stable@vger.kernel.org> Fixes: 582ab27a ("mei: bus: fix received data size check in NFC fixup") Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Douglas Anderson authored
[ Upstream commit 1cf86bc2 ] If you do this on an sdm845 board: grep "" /sys/kernel/debug/pinctrl/*spmi:pmic*/pinconf-groups ...it looks like nonsense. For every pin you see listed: input bias disabled, input bias high impedance, input bias pull down, input bias pull up, ... That's because pmic_gpio_config_get() isn't complying with the rules that pinconf_generic_dump_one() expects. Specifically for boolean parameters (anything with a "struct pin_config_item" where has_arg is false) the function expects that the function should return its value not through the "config" parameter but should return "0" if the value is set and "-EINVAL" if the value isn't set. Let's fix this. >From a quick sample of other pinctrl drivers, it appears to be tradition to also return 1 through the config parameter for these boolean parameters when they exist. I'm not one to knock tradition, so I'll follow tradition and return 1 in these cases. While I'm at it, I'll also continue searching for four leaf clovers, kocking on wood three times, and trying not to break mirrors. NOTE: This also fixes an apparent typo for reading PIN_CONFIG_BIAS_DISABLE where the old driver was accidentally using "=" instead of "==" and thus was setting some internal state when you tried to query PIN_CONFIG_BIAS_DISABLE. Oops. Fixes: eadff302 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit cd0e0ca6 ] The ARRAY_SIZE() macro is type size_t. If s6e8aa0_dcs_read() returns a negative error code, then "ret < ARRAY_SIZE(id)" is false because the negative error code is type promoted to a high positive value. Fixes: 02051ca0 ("drm/panel: add S6E8AA0 driver") Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180704093807.s3lqsb2v6dg2k43d@kili.mountainSigned-off-by:
-
John Stultz authored
[ Upstream commit 1416270f ] In the past we've warned when ADJ_OFFSET was in progress, usually caused by ntpd or some other time adjusting daemon running in non steady sate, which can cause the skew calculations to be incorrect. Thus, this patch checks to see if the clock was being adjusted when we fail so that we don't cause false negatives. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Miroslav Lichvar <mlichvar@redhat.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: linux-kselftest@vger.kernel.org Suggested-by:
Miroslav Lichvar <mlichvar@redhat.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Timo Wischer authored
[ Upstream commit ff2d6acd ] Without this commit the following intervals [x y), (x y) were be replaced to (y-1 y) by snd_interval_refine_last(). This was also done if y-1 is part of the previous interval. With this changes it will be replaced with [y-1 y) in case of y-1 is part of the previous interval. A similar behavior will be used for snd_interval_refine_first(). This commit adapts the changes for alsa-lib of commit 9bb985c ("pcm: snd_interval_refine_first/last: exclude value only if also excluded before") Signed-off-by:
Timo Wischer <twischer@de.adit-jv.com> Signed-off-by:
-
Zhouyang Jia authored
[ Upstream commit 7874b919 ] When devm_ioremap fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling devm_ioremap. Signed-off-by:
Zhouyang Jia <jiazhouyang09@gmail.com> Signed-off-by:
-
Wei Lu authored
[ Upstream commit e47cb828 ] Return ERR_PTR(-EINVAL) if kfd_get_process fails to find the process. This fixes kernel oopses when a child process calls KFD ioctls with a file descriptor inherited from the parent process. Signed-off-by:
Wei Lu <wei.lu2@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
-
Peter Rosin authored
[ Upstream commit 193c2a07 ] Locking the root adapter for __i2c_transfer will deadlock if the device sits behind a mux-locked I2C mux. Switch to the finer-grained i2c_lock_bus with the I2C_LOCK_SEGMENT flag. If the device does not sit behind a mux-locked mux, the two locking variants are equivalent. Signed-off-by:
Peter Rosin <peda@axentia.se> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Peter Rosin authored
[ Upstream commit 8c8f74f3 ] Locking the root adapter for __i2c_transfer will deadlock if the device sits behind a mux-locked I2C mux. Switch to the finer-grained i2c_lock_bus with the I2C_LOCK_SEGMENT flag. If the device does not sit behind a mux-locked mux, the two locking variants are equivalent. Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit b23ec599 ] Since we put static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it. Mark gpio_suffixes array with __maybe_unused to hide a compiler warning: In file included from drivers/gpio/gpiolib-legacy.c:6:0: drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=] static const char * const gpio_suffixes[] = { "gpios", "gpio" }; ^~~~~~~~~~~~~ In file included from drivers/gpio/gpiolib-devprop.c:17:0: drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=] static const char * const gpio_suffixes[] = { "gpios", "gpio" }; ^~~~~~~~~~~~~ Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Wei Yongjun authored
[ Upstream commit 95067556 ] platform_get_resource() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference a bit later in the code. This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = platform_get_resource(pdev, t, n); + if (!res) + return -EINVAL; ... when != res == NULL e = devm_ioremap(e1, res->start, e2); Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Robin Murphy authored
[ Upstream commit ccff2dfa ] Probing the TPIU driver under UBSan triggers an out-of-bounds shift warning in coresight_timeout(): ... [ 5.677530] UBSAN: Undefined behaviour in drivers/hwtracing/coresight/coresight.c:929:16 [ 5.685542] shift exponent 64 is too large for 64-bit type 'long unsigned int' ... On closer inspection things are exponentially out of whack because we're passing a bitmask where a bit number should be. Amusingly, it seems that both calls will find their expected values by sheer luck and appear to succeed: 1 << FFCR_FON_MAN ends up at bit 64 which whilst undefined evaluates as zero in practice, while 1 << FFSR_FT_STOPPED finds bit 2 (TCPresent) which apparently is usually tied high. Following the examples of other drivers, define separate FOO and FOO_BIT macros for masks vs. indices, and put things right. CC: Robert Walker <robert.walker@arm.com> CC: Mike Leach <mike.leach@linaro.org> CC: Mathieu Poirier <mathieu.poirier@linaro.org> Fixes: 11595db8 ("coresight: Fix disabling of CoreSight TPIU") Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
[ Upstream commit fe470f5f ] If we fail to find the input / output port for a LINK component while enabling a path, we should fail gracefully rather than assuming port "0". Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
-
Julia Lawall authored
[ Upstream commit faa1a473 ] Return an error code on failure. Change leading spaces to tab on the first if. Problem found using Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
-
Thierry Reding authored
[ Upstream commit b59fb482 ] Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the memory controller). Transparently backing DMA memory with an IOMMU prevents Nouveau from properly handling such memory accesses and causes memory access faults. As a side-note: buffers other than those allocated in instance memory don't need to be physically contiguous from the GPU's perspective since the GPU can map them into contiguous buffers using its own MMU. Mapping these buffers through the IOMMU is unnecessary and will even lead to performance degradation because of the additional translation. One exception to this are compressible buffers which need large pages. In order to enable these large pages, multiple small pages will have to be combined into one large (I/O virtually contiguous) mapping via the IOMMU. However, that is a topic outside the scope of this fix and isn't currently supported. An implementation will want to explicitly create these large pages in the Nouveau driver, so detaching from a DMA/IOMMU mapping would still be required. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Nicolas Chauvet <kwizart@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Stefan Agner authored
[ Upstream commit 1b5190c2 ] For eMMC devices it is valid to only support 1.8V signaling. When vqmmc is set to a fixed 1.8V regulator the stack tries to set 3.3V initially and prints the following warning: mmc1: Switching to 3.3V signalling voltage failed Clear the MMC_SIGNAL_VOLTAGE_330 flag in case 3.3V is signaling is not available. This prevents the stack from even trying to use 3.3V signaling and avoids the above warning. Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Stefan Agner authored
[ Upstream commit 127407e3 ] The stack assumes that SDHC controller which support SD3.0 (SDR104) do support HS200. This is not the case for Tegra 3, which does support SD 3.0 but only supports eMMC spec 4.41. Use SDHCI_QUIRK2_BROKEN_HS200 to indicate that the controller does not support HS200. Note that commit 156e14b1 ("mmc: sdhci: fix caps2 for HS200") added the tie between SD3.0 (SDR104) and HS200. I don't think that this is necessarly true. It is fully legitimate to support SD3.0 and not support HS200. The quirk naming suggests something is broken in the controller, but this is not the case: The controller simply does not support HS200. Fixes: 7ad2ed1d ("mmc: tegra: enable UHS-I modes") Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by:
-
Enrico Scholz authored
[ Upstream commit d36d0e63 ] mbus_code_to_bus_cfg() can fail on unknown mbus codes; pass back the error to the caller. Signed-off-by:
Enrico Scholz <enrico.scholz@sigma-chemnitz.de> Signed-off-by:
Jan Luebbe <jlu@pengutronix.de> [p.zabel@pengutronix.de - renamed rc to ret for consistency] Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Nicholas Mc Guire authored
[ Upstream commit 81646a3d ] of_find_compatible_node() returns a device node with refcount incremented and thus needs an explicit of_node_put(). Further relying on an unchecked of_iomap() which can return NULL is problematic here, after all ctrl_base is critical enough for hix5hd2_set_cpu() to call BUG() if not available so a check seems mandated here. Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> 0002 Fixes: commit 06cc5c1d ("ARM: hisi: enable hix5hd2 SoC") Signed-off-by:
Wei Xu <xuwei5@hisilicon.com> Signed-off-by:
-
Nicholas Mc Guire authored
[ Upstream commit 9f30b5ae ] of_iomap() can return NULL which seems critical here and thus should be explicitly flagged so that the cause of system halting can be understood. As of_find_compatible_node() is returning a device node with refcount incremented it must be explicitly decremented here. Signed-off-by:
-
