JIRA: https://issues.redhat.com/browse/RHEL-78837
commit ea79df10331218b04d90f028a605f33c879c518d
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date: Mon, 25 Nov 2024 14:23:11 +0100
The MMC_RSP_R1_NO_CRC type of response is not being used by the mmc core
for any commands. Let's therefore drop it, together with the corresponding
code in the host drivers.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # for TMIO
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Message-ID: <20241125132311.23939-1-ulf.hansson@linaro.org>
Signed-off-by: Desnes Nunes <desnesn@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-53569
Upstream Status: v6.12-rc1
Conflicts:
DRM-backport will backport changes to the below
files, but since they are merged seperately, the
conflict is resolved here to keep this commit
building.
drivers/gpu/drm/msm/msm_drv.c
drivers/iommu/iommufd/selftest.c
drivers/misc/xilinx_tmr_inject.c
No functional changes are intended for these files
but since the codebase in v5.17 has diverged substantially
from upstream this commit does not apply cleanly.
include/ufs/ufshcd.h
kernel/futex/core.c
mm/fail_page_alloc.c
mm/failslab.c
commit 6ce2082fd3a25d5a8c756120959237cace0379f1
Author: Jani Nikula <jani.nikula@intel.com>
AuthorDate: Tue Aug 13 15:12:35 2024 +0300
Commit: Andrew Morton <akpm@linux-foundation.org>
CommitDate: Sun Sep 1 20:43:33 2024 -0700
The fault-inject.h users across the kernel need to add a lot of #ifdef
CONFIG_FAULT_INJECTION to cater for shortcomings in the header. Make
fault-inject.h self-contained for CONFIG_FAULT_INJECTION=n, and add stubs
for DECLARE_FAULT_ATTR(), setup_fault_attr(), should_fail_ex(), and
should_fail() to allow removal of conditional compilation.
[akpm@linux-foundation.org: repair fallout from no longer including debugfs.h into fault-inject.h]
[akpm@linux-foundation.org: fix drivers/misc/xilinx_tmr_inject.c]
[akpm@linux-foundation.org: Add debugfs.h inclusion to more files, per Stephen]
Link: https://lkml.kernel.org/r/20240813121237.2382534-1-jani.nikula@intel.com
Fixes: 6ff1cb355e ("[PATCH] fault-injection capabilities infrastructure")
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Robert Foss <rfoss@redhat.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/5415
JIRA: https://issues.redhat.com/browse/RHEL-50013
Tested: basic testing with several supported WiFi cards (Intel, Qualcomm, Mediatek and Realtek).
Wireless core and drivers update to v6.11.
Upstream status: linux.git
Later fixes to be included in next rebases:
Omitted-fix: 0129e5ff2842 wifi: rtw88: 8703b: Fix reported RX band width
Omitted-fix: 177b49dbf9c1 wifi: ath11k: use work queue to process beacon tx event
Omitted-fix: 9b8d932053b8 wifi: mt76: mt7603: fix mixed declarations and code
Omitted-fix: ded1a6d9e13a wifi: mt76: mt7996: fix handling mbss enable/disable
Omitted-fix: 56310ddb50b1 wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading
Omitted-fix: d9dd3ac77cf7 wifi: rtw89: wow: fix wait condition for AOAC report request
Omitted-fix: 76364f3edfde wifi: iwlwifi: mvm: allow ESR when we the ROC expires
Omitted-fix: a949075d4bbf wifi: iwlwifi: mvm: set the cipher for secured NDP ranging
Omitted-fix: a7bc66fe8093 bus: mhi: host: pci_generic: Update EDL firmware path for Foxconn modems
Omitted-fix: bd9813d13be4 wifi: cfg80211: check radio iface combination for multi radio per wiphy
Omitted-fix: 7c24c5bdf489 wifi: mac80211_hwsim: correct MODULE_PARM_DESC of multi_radio
Omitted-fix: 45ae0e8cf8c7 wifi: rtw89: 8852c: support firmware format up to v1
Omitted-fix: f403fed7f98e wifi: mac80211: remove label usage in ieee80211_start_radar_detection()
Omitted-fix: f4bb650cfab4 wifi: trace: unlink rdev_end_cac trace event from wiphy_netdev_evt class
Omitted-fix: 62c16f219a73 wifi: cfg80211: move DFS related members to links[] in wireless_dev
Omitted-fix: 81f67d60ebf2 wifi: cfg80211: handle DFS per link
Omitted-fix: d74380ee99b5 wifi: mac80211: handle DFS per link
Omitted-fix: 0b7798232eee wifi: cfg80211/mac80211: use proper link ID for DFS
Omitted-fix: bca8bc0399ac wifi: mac80211: handle ieee80211_radar_detected() for MLO
Omitted-fix: 53d7c99719e2 wifi: ath11k: fix RCU documentation in ath11k_mac_op_ipv6_changed()
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Approved-by: Herton R. Krzesinski <herton@redhat.com>
Approved-by: Desnes Nunes <desnesn@redhat.com>
Approved-by: Kamal Heib <kheib@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: Rado Vrbovsky <rvrbovsk@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-56837
commit ec84ca4025c0b90c6b7173a230f78ec00cad44f5
Author: Christoph Hellwig <hch@lst.de>
Date: Tue Apr 9 16:37:48 2024 +0200
scsi: block: Remove now unused queue limits helpers
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20240409143748.980206-24-hch@lst.de
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit bac806830fde94ccf41482535fc442c02656febc
Author: Wenchao Chen <wenchao.chen@unisoc.com>
Date: Fri Aug 25 17:17:42 2023 +0800
mmc: core: Add host specific tuning support for SD HS mode
To support the need for host specific tuning for SD high-speed mode, let's
add two new optional callbacks, ->prepare|execute_sd_hs_tuning() and let's
call them when switching into the SD high-speed mode.
Note that, during the tuning process it's also needed for host drivers to
send commands to the SD card to verify that the tuning process succeeds.
Therefore, let's also share the corresponding functions from the core to
allow this.
Signed-off-by: Wenchao Chen <wenchao.chen@unisoc.com>
Link: https://lore.kernel.org/r/20230825091743.15613-2-wenchao.chen@unisoc.com
[Ulf: Dropped unnecessary function declarations and updated the commit msg]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 09fcdbd28404b7e02cc9fc4862ae5b43b76867c0
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date: Mon May 22 22:24:24 2023 +0200
mmc: sdio: Add/rename SDIO ID of the RTL8723DS SDIO wifi cards
RTL8723DS comes in two variant and each of them has their own SDIO ID:
- 0xd723 can connect two antennas. The WiFi part is still 1x1 so the
second antenna can be dedicated to Bluetooth
- 0xd724 can only connect one antenna so it's shared between WiFi and
Bluetooth
Add a new entry for the single antenna RTL8723DS (0xd724) which can be
found on the MangoPi MQ-Quad. Also rename the existing RTL8723DS entry
(0xd723) so it's name reflects that it's the variant with support for
two antennas.
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230522202425.1827005-4-martin.blumenstingl@googlemail.com
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 7d6d2dd326a8a8d32091e9748f3428dd3be68367
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date: Wed Apr 5 22:07:26 2023 +0200
mmc: sdio: add Realtek SDIO vendor ID and various wifi device IDs
Add the SDIO vendor ID for Realtek and some device IDs extracted from
their GPL vendor driver. This will be useful in the future when the
rtw88 driver gains support for these chips.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-7-martin.blumenstingl@googlemail.com
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 8d91f3f8ae57e6292142ca89f322e90fa0d6ac02
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat Mar 11 23:39:55 2023 +0100
mmc: core: add helpers mmc_regulator_enable/disable_vqmmc
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 <hkallweit1@gmail.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/71586432-360f-9b92-17f6-b05a8a971bc2@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 88f94c782b0ee2297685764f942e7c176d6b89aa
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue Feb 14 22:41:19 2023 +0100
mmc: core: support setting card detect interrupt from drivers
On certain platforms like Amlogic Meson gpiod_to_irq() isn't supported
due to the design of gpio / interrupt controller. Therefore provide an
option for drivers to pass the card detect interrupt number
(retrieved e.g. from device tree) to mmc core.
Suggested-by refers to the mechanism to pass and store the interrupt.
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/5777f38b-465f-ce48-a87f-5eb8b3c57b0a@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 80df83c2c57e75cb482ccf0c639ce84703ab41a2
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat Feb 4 00:53:35 2023 +0100
mmc: core: add devm_mmc_alloc_host
Add a device-managed version of mmc_alloc_host().
The argument order is reversed compared to mmc_alloc_host() because
device-managed functions typically have the device argument first.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/6d8f9fdc-7c9e-8e4f-e6ef-5470b971c74e@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 489d144563f23911262a652234b80c70c89c978b
Author: Christian Löhle <CLoehle@hyperstone.com>
Date: Thu Nov 17 14:42:09 2022 +0000
mmc: core: Fix ambiguous TRIM and DISCARD arg
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: b3bf915308 ("mmc: core: new discard feature support at eMMC v4.5")
Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/11376b5714964345908f3990f17e0701@hyperstone.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 1dd611a9c55f6657328429b988e302323691c3dc
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri Aug 19 23:26:17 2022 +0200
mmc: core: Switch to basic workqueue API for sdio_irq_work
The delay parameter isn't set by any user, therefore simplify the code
and switch to the basic workqueue API w/o delay support. This also
reduces the size of struct mmc_host.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/13d8200a-e2a8-d907-38ce-a16fc5ce14aa@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 019e442bb0d5e7f25ada8eb4252e22e62d17a95e
Author: Axe Yang <axe.yang@mediatek.com>
Date: Tue Jul 26 14:28:41 2022 +0800
mmc: core: Add support for SDIO wakeup interrupt
If wakeup-source flag is set in host dts node, parse EAI information
from SDIO CCCR interrupt externsion segment for in-band wakeup. If
async interrupt is supported by SDIO card then enable it and set
enable_async_irq flag in sdio_cccr structure to 1. The parse flow is
implemented in sdio_read_cccr().
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Axe Yang <axe.yang@mediatek.com>
Link: https://lore.kernel.org/r/20220726062842.18846-3-axe.yang@mediatek.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 3beb0ab5bffba625007ea5c9e5e0ee5eef05c1ea
Author: Seunghui Lee <sh043.lee@samsung.com>
Date: Wed Jul 13 12:36:34 2022 +0900
mmc: core: Use mmc_card_* macro and add a new for the sd_combo type
Add mmc_card_sd_combo() macro for sd combo type card and use the mmc_card_*
macro to simplify code instead of comparing card->type.
Signed-off-by: Seunghui Lee <sh043.lee@samsung.com>
Link: https://lore.kernel.org/r/20220713033635.28432-2-sh043.lee@samsung.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit c467c8f081859d4f4ca4eee4fba54bb5d85d6c97
Author: Marek Vasut <marex@denx.de>
Date: Tue Jun 20 12:27:13 2023 +0200
mmc: Add MMC_QUIRK_BROKEN_SD_CACHE for Kingston Canvas Go Plus from 11/2019
This microSD card never clears Flush Cache bit after cache flush has
been started in sd_flush_cache(). This leads e.g. to failure to mount
file system. Add a quirk which disables the SD cache for this specific
card from specific manufacturing date of 11/2019, since on newer dated
cards from 05/2023 the cache flush works correctly.
Fixes: 08ebf903af57 ("mmc: core: Fixup support for writeback-cache for eMMC and SD")
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20230620102713.7701-1-marex@denx.de
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 07d2872bf4c864eb83d034263c155746a2fb7a3b
Author: Avri Altman <avri.altman@wdc.com>
Date: Wed Sep 28 12:57:44 2022 +0300
mmc: core: Add SD card quirk for broken discard
Some SD-cards from Sandisk that are SDA-6.0 compliant reports they supports
discard, while they actually don't. This might cause mk2fs to fail while
trying to format the card and revert it to a read-only mode.
To fix this problem, let's add a card quirk (MMC_QUIRK_BROKEN_SD_DISCARD)
to indicate that we shall fall-back to use the legacy erase command
instead.
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220928095744.16455-1-avri.altman@wdc.com
[Ulf: Updated the commit message]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 32f18e596141f40dbc5d8700b2730371ffd3055f
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date: Fri Apr 8 10:00:44 2022 +0200
mmc: improve API to make clear hw_reset callback is for cards
To make it unambiguous that the hw_reset callback is for cards and not
for controllers, we add 'card' to the callback name and convert all
users in one go. We keep the argument as mmc_host, though, because the
callback is used very early when mmc_card is not yet populated.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20220408080045.6497-4-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 9723f69d1de37ca25474372ad1753ea39bb0dce1
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date: Fri Apr 8 10:00:43 2022 +0200
mmc: core: improve API to make clear that mmc_sw_reset is for cards
To make it unambiguous that mmc_sw_reset() is for cards and not for
controllers, we make the function argument mmc_card instead of mmc_host.
There are no users to convert currently.
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20220408080045.6497-3-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-41085
commit 1705643faecde95bdeb11bea5ab5baed084e9f91
Author: Sean Wang <sean.wang@mediatek.com>
Date: Tue Oct 19 05:30:20 2021 +0800
mmc: add MT7921 SDIO identifiers for MediaTek Bluetooth devices
The MT7961 SDIO identifier for MediaTek Bluetooth devices were being
referred in the MediaTek Bluetooth driver.
Co-developed-by: Mark-yw Chen <mark-yw.chen@mediatek.com>
Signed-off-by: Mark-yw Chen <mark-yw.chen@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2196821
commit cc4cffc3c142d57df48c07851862444e1d33bdaa
Author: Marek Vasut <marex@denx.de>
Date: Fri Apr 7 22:37:52 2023 +0200
wifi: brcmfmac: add Cypress 43439 SDIO ids
Add SDIO ids for use with the muRata 1YN (Cypress CYW43439).
The odd thing about this is that the previous 1YN populated
on M.2 card for evaluation purposes had BRCM SDIO vendor ID,
while the chip populated on real hardware has a Cypress one.
The device ID also differs between the two devices. But they
are both 43439 otherwise, so add the IDs for both.
On-device 1YN (43439), the new one, chip label reads "1YN":
```
/sys/.../mmc_host/mmc2/mmc2:0001 # cat vendor device
0x04b4
0xbd3d
```
EA M.2 evaluation board 1YN (43439), the old one, chip label reads "1YN ES1.4":
```
/sys/.../mmc_host/mmc0/mmc0:0001/# cat vendor device
0x02d0
0xa9a6
```
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230407203752.128539-1-marex@denx.de
Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2178526
commit bba047f15851c8b053221f1b276eb7682d59f755
Author: Lukas Wunner <lukas@wunner.de>
Date: Fri Jan 27 15:02:00 2023 +0100
wifi: mwifiex: Support SD8978 chipset
The Marvell SD8978 (aka NXP IW416) uses identical registers as SD8987,
so reuse the existing mwifiex_reg_sd8987 definition.
Note that mwifiex_reg_sd8977 and mwifiex_reg_sd8997 are likewise
identical, save for the fw_dump_ctrl register: They define it as 0xf0
whereas mwifiex_reg_sd8987 defines it as 0xf9. I've verified that
0xf9 is the correct value on SD8978. NXP's out-of-tree driver uses
0xf9 for all of them, so there's a chance that 0xf0 is not correct
in the mwifiex_reg_sd8977 and mwifiex_reg_sd8997 definitions. I cannot
test that for lack of hardware, hence am leaving it as is.
NXP has only released a firmware which runs Bluetooth over UART.
Perhaps Bluetooth over SDIO is unsupported by this chipset.
Consequently, only an "sdiouart" firmware image is referenced, not an
alternative "sdsd" image.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/536b4f17a72ca460ad1b07045757043fb0778988.1674827105.git.lukas@wunner.de
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2136124
commit be376df724aa3b7abdf79390eaab60c58a92f4f0
Author: Marek Vasut <marex@denx.de>
Date: Sat Aug 27 04:49:03 2022 +0200
wifi: brcmfmac: add 43439 SDIO ids and initialization
Add HW and SDIO ids for use with the muRata 1YN (Cypress CYW43439).
Add the firmware mapping structures for the CYW43439 chipset.
The 43439 needs some things setup similar to the 43430 chipset.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220827024903.617294-1-marex@denx.de
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2120352
commit b71597edfaade119157ded98991bac7160be80c2
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date: Fri Apr 8 10:00:42 2022 +0200
mmc: core: improve API to make clear mmc_hw_reset is for cards
To make it unambiguous that mmc_hw_reset() is for cards and not for
controllers, we make the function argument mmc_card instead of mmc_host.
Also, all users are converted.
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220408080045.6497-2-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris von Recklinghausen <crecklin@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2120352
commit 5c67aa59bd8f99d70c81b5e71bd02083056a8486
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Thu Oct 14 16:26:11 2021 +0300
mmc: sdhci-pci: Remove dead code (struct sdhci_pci_data et al)
The last user of this struct gone a couple of releases ago.
Besides that there were not so many users of this API for
more than 10 years:
1/ The one is Intel Merrifield, that had been added 2016-08-31
by the commit 3976b0380b ("x86/platform/intel-mid: Enable
SD card detection on Merrifield") and removed 2021-02-11 by
the commit 4590d98f5a ("sfi: Remove framework for deprecated
firmware").
2/ The other is Intel Sunrisepoint related, that had been added
2015-02-06 by the commit e1bfad6d93 ("mmc: sdhci-pci: Add
support for drive strength selection for SPT") and removed
2017-03-20 by the commit 51ced59cc0 ("mmc: sdhci-pci: Use
ACPI DSM to get driver strength for some Intel devices").
Effectively this is a revert of the commit 52c506f0bc ("mmc:
sdhci-pci: add platform data").
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20211014132613.27861-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris von Recklinghausen <crecklin@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2120352
commit f614fb60a1983819e83796198de2b607fba75e99
Author: Wenbin Mei <wenbin.mei@mediatek.com>
Date: Fri Sep 17 20:48:02 2021 +0800
mmc: core: Add host specific tuning support for eMMC HS400 mode
This adds a ->execute_hs400_tuning() host callback to enable optional
support for host specific tuning for eMMC HS400 mode. Additionally, share
mmc_get_ext_csd() through the public host headerfile, to allow it to be
used by the host drivers, which is needed to support the HS400 tuning.
Signed-off-by: Wenbin Mei <wenbin.mei@mediatek.com>
Link: https://lore.kernel.org/r/20210917124803.22871-3-wenbin.mei@mediatek.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris von Recklinghausen <crecklin@redhat.com>
Bugzilla: https://bugzilla.redhat.com/2120352
commit 291ee9d5da535f8c72408850a413074c4719c8d3
Author: Mårten Lindahl <marten.lindahl@axis.com>
Date: Mon Aug 16 17:30:54 2021 +0200
mmc: core: Update ->card_busy() callback comment
According to SD specification checking state of DAT0 only, is enough while
polling for card busy completion. Let's update the comment in the header
file to correct this, as the comment says DAT[0:3].
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20210816153054.24082-1-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris von Recklinghausen <crecklin@redhat.com>
Bugzilla: http://bugzilla.redhat.com/2033354
commit d2587c57ffd8dcad04171dfd203dcc4ff98e4782
Author: Angus Ainslie <angus@akkea.ca>
Date: Thu Aug 12 09:52:17 2021 -0700
brcmfmac: add 43752 SDIO ids and initialization
Add HW and SDIO ids for use with the SparkLan AP6275S
Add the firmware mapping structures for the BRCM43752 chipset.
The 43752 needs some things setup similar to the 43012 chipset.
The WATERMARK shows better performance when initialized to the 4373 value.
Signed-off-by: Angus Ainslie <angus@akkea.ca>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210812165218.2508258-2-angus@akkea.ca
Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2018403
commit cb77cb5abe1f4fae4a33b735606aae22f9eaa1c7
Author: Eric Biggers <ebiggers@google.com>
Date: Mon Oct 18 11:04:52 2021 -0700
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
blk_keyslot_manager is misnamed because it doesn't necessarily manage
keyslots. It actually does several different things:
- Contains the crypto capabilities of the device.
- Provides functions to control the inline encryption hardware.
Originally these were just for programming/evicting keyslots;
however, new functionality (hardware-wrapped keys) will require new
functions here which are unrelated to keyslots. Moreover,
device-mapper devices already (ab)use "keyslot_evict" to pass key
eviction requests to their underlying devices even though
device-mapper devices don't have any keyslots themselves (so it
really should be "evict_key", not "keyslot_evict").
- Sometimes (but not always!) it manages keyslots. Originally it
always did, but device-mapper devices don't have keyslots
themselves, so they use a "passthrough keyslot manager" which
doesn't actually manage keyslots. This hack works, but the
terminology is unnatural. Also, some hardware doesn't have keyslots
and thus also uses a "passthrough keyslot manager" (support for such
hardware is yet to be upstreamed, but it will happen eventually).
Let's stop having keyslot managers which don't actually manage keyslots.
Instead, rename blk_keyslot_manager to blk_crypto_profile.
This is a fairly big change, since for consistency it also has to update
keyslot manager-related function names, variable names, and comments --
not just the actual struct name. However it's still a fairly
straightforward change, as it doesn't change any actual functionality.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2018403
commit 1e8d44bddf57f6d878e083f281a34d5c88feb7db
Author: Eric Biggers <ebiggers@google.com>
Date: Mon Oct 18 11:04:51 2021 -0700
blk-crypto: rename keyslot-manager files to blk-crypto-profile
In preparation for renaming struct blk_keyslot_manager to struct
blk_crypto_profile, rename the keyslot-manager.h and keyslot-manager.c
source files. Renaming these files separately before making a lot of
changes to their contents makes it easier for git to understand that
they were renamed.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-3-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2018403
commit 86c639ce08266ed521974038f0592739fec1c11a
Author: Eric Biggers <ebiggers@google.com>
Date: Wed Jul 21 08:47:38 2021 -0700
mmc: core: Store pointer to bio_crypt_ctx in mmc_request
Make 'struct mmc_request' contain a pointer to the request's
'struct bio_crypt_ctx' directly, instead of extracting a 32-bit DUN from
it which is a cqhci-crypto specific detail.
This keeps the cqhci crypto specific details in the cqhci module, and it
makes mmc_core and mmc_block ready for MMC crypto hardware that accepts
the DUN and/or key in a way that is more flexible than that which will
be specified by the eMMC v5.2 standard. Exynos SoCs are an example of
such hardware, as their inline encryption hardware takes keys directly
(it has no concept of keyslots) and supports 128-bit DUNs.
Note that the 32-bit DUN length specified by the standard is very
restrictive, so it is likely that more hardware will support longer DUNs
despite it not following the standard. Thus, limiting the scope of the
32-bit DUN assumption to the place that actually needs it is warranted.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20210721154738.3966463-1-ebiggers@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2018403
commit dc913385dd74e625271482c30aefedd1e5af7b8c
Author: Dmitry Osipenko <digetx@gmail.com>
Date: Fri Aug 20 03:45:35 2021 +0300
mmc: block: Support alternative_gpt_sector() operation
Support generic alternative_gpt_sector() block device operation.
It calculates location of GPT entry for eMMC of NVIDIA Tegra Android
devices. Add new MMC_CAP2_ALT_GPT_TEGRA flag that enables scanning of
alternative GPT sector and add raw_boot_mult field to mmc_ext_csd
which allows to get size of the boot partitions that is needed for
the calculation.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20210820004536.15791-4-digetx@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
'mmc_abort_tuning()' made me think tuning gets completely aborted.
However, it sends only a STOP cmd to cancel the current tuning cmd.
Tuning process may still continue after that. So, rename the function to
'mmc_send_abort_tuning()' to better reflect all this.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Link: https://lore.kernel.org/r/20210608180620.40059-1-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In SD spec v6.x the SD function extension registers for performance
enhancements were introduced. As a part of this an optional internal cache
on the SD card, can be used to improve performance.
The let the SD card use the cache, the host needs to enable it and manage
flushing of the cache, so let's add support for this.
Note that for an SD card supporting the cache it's mandatory for it, to
also support the poweroff notification feature. According to the SD spec,
if the cache has been enabled and a poweroff notification is sent to the
card, that implicitly also means that the card should flush its internal
cache. Therefore, dealing with cache flushing for REQ_OP_FLUSH block
requests is sufficient.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Link: https://lore.kernel.org/r/20210511101359.83521-1-ulf.hansson@linaro.org
Rather than only deselecting the SD card via a CMD7, before we cut power to
it at system suspend, at runtime suspend or at shutdown, let's add support
for a graceful power off sequence via enabling the SD Power Off
Notification feature.
Note that, the Power Off Notification feature was added in the SD spec
v4.x, which is several years ago. However, it's still a bit unclear how
often the SD card vendors decides to implement support for it. To validate
these changes a Sandisk Extreme PRO A2 64GB has been used, which seems to
work nicely.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://lore.kernel.org/r/20210504161222.101536-12-ulf.hansson@linaro.org
In SD spec v6.x the SD function extension registers for performance
enhancements were introduced. These registers let the SD card announce
supports for various performance related features, like "self-maintenance",
"cache" and "command queuing".
Let's extend the parsing of SD function extension registers and store the
information in the struct mmc_card. This prepares for subsequent changes to
implement the complete support for new the performance enhancement
features.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://lore.kernel.org/r/20210504161222.101536-11-ulf.hansson@linaro.org
In the SD spec v4.0 the CMD48/49 and CMD58/59 were introduced as optional
commands. In the SD spec v4.1 the SD function extension registers were
introduced, which requires support for CMD48/49/58/59 to be read/written
from/to.
Moreover, a specific function extension register were added to let the card
announce support for optional features in regards to power management. The
features that were added are "Power Off Notification", "Power Down Mode"
and "Power Sustenance".
As a first step to support this, let's read and parse the register for
power management during the SD card initialization and store the
information about the supported features in the struct mmc_card. In this
way, we prepare for subsequent changes to implement the complete support
for the new features.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Avri Altman <avri.altman@wdc.com>
Link: https://lore.kernel.org/r/20210504161222.101536-10-ulf.hansson@linaro.org
In SD spec v4.x the support for CMD48/49 and CMD58/59 were introduced as
optional features. To let the card announce whether it supports the
commands, the SCR register has been extended with corresponding support
bits. Let's parse and store this information for later use.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Avri Altman <avri.altman@wdc.com>
Link: https://lore.kernel.org/r/20210504161222.101536-9-ulf.hansson@linaro.org
mmc_of_parse() for a few years has been using device property API.
Convert mmc_of_parse_voltage() as well.
At the same time switch users to new API.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210419112459.25241-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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 ->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 <kwmad.kim@samsung.com>
Cc: stable@vger.kernel.org # v4.5+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210310152900.149380-1-ulf.hansson@linaro.org
Reviewed-by: Kiwoong Kim <kwmad.kim@samsung.com>
When the mmc_rescan work is enabled for execution (host->rescan_disable),
it's the only instance per mmc host that is allowed to set/clear the
host->bus_ops pointer.
Besides the mmc_rescan work, there are a couple of scenarios when the
host->bus_ops pointer may be accessed. Typically, those can be described as
as below:
*)
Upper mmc driver layers (like the mmc block device driver or an SDIO
functional driver) needs to execute a host->bus_ops callback. This can be
considered as safe without having to use some special locking mechanism,
because they operate on top of the struct mmc_card. As long as there is a
card to operate upon, the mmc core guarantees that there is a host->bus_ops
assigned as well. Note that, upper layer mmc drivers are of course
responsible to clean up from themselves from their ->remove() callbacks,
otherwise things would fall apart anyways.
**)
Via the mmc host instance, we may need to force a removal of an inserted
mmc card. This happens when a mmc host driver gets unbind, for example. In
this case, we protect the host->bus_ops pointer from concurrent accesses,
by disabling the mmc_rescan work upfront (host->rescan_disable). See
mmc_stop_host() for example.
This said, it seems like the reference counting of the host->bus_ops
pointer at some point have become superfluous. As this is an old mechanism
of the mmc core, it a bit difficult to digest the history of when that
could have happened. However, let's drop the reference counting to avoid
unnecessary code-paths and lockings.
Cc: Pierre Ossman <pierre@ossman.eu>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20210212131610.236843-1-ulf.hansson@linaro.org
The commit de3ee99b09 ("mmc: Delete bounce buffer handling") removed the
bounce buffer handling from the mmc core, but forgot to remove the bouncesz
member from the struct mmc_card, let's fix it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20210202101626.64503-1-ulf.hansson@linaro.org
The Kconfig option to use the blk-mq support was removed in commit
1bec43a3b1 ("mmc: core: Remove option not to use blk-mq"), but forgot to
remove the use_blk_mq member in the struct mmc_host, let's fix it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20210202101924.69970-1-ulf.hansson@linaro.org
In preparation for adding CQHCI crypto engine (inline encryption)
support, add the code required to make mmc_core and mmc_block aware of
inline 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 <satyat@google.com>
Signed-off-by: Satya Tangirala <satyat@google.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Satya Tangirala <satyat@google.com>
Reviewed-and-tested-by: Peng Zhou <peng.zhou@mediatek.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20210126001456.382989-2-ebiggers@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Drivers for MMC hosts that accept phase corrections can take advantage
of the helper by embedding an instance of struct mmc_clk_phase_map in
their private data and invoking mmc_of_parse_clk_phase() to extract
phase parameters. It is the responsibility of the host driver to
translate and apply the extracted values to hardware as required.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20210114031433.2388532-2-andrew@aj.id.au
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In the SD specification v7.10 the SD express card has been added. This new
type of removable SD card, can be managed via a PCIe/NVMe based interface,
while also allowing backwards compatibility towards the legacy SD
interface.
To keep the backwards compatibility, it's required to start the
initialization through the legacy SD interface. If it turns out that the
mmc host and the SD card, both supports the PCIe/NVMe interface, then a
switch should be allowed.
Therefore, let's introduce some basic support for this type of SD cards to
the mmc core. The mmc host, should set MMC_CAP2_SD_EXP if it supports this
interface and MMC_CAP2_SD_EXP_1_2V, if also 1.2V is supported, as to inform
the core about it.
To deal with the switch to the PCIe/NVMe interface, the mmc host is
required to implement a new host ops, ->init_sd_express(). Based on the
initial communication between the host and the card, host->ios.timing is
set to either MMC_TIMING_SD_EXP or MMC_TIMING_SD_EXP_1_2V, depending on if
1.2V is supported or not. In this way, the mmc host can check these values
in its ->init_sd_express() ops, to know how to proceed with the handover.
Note that, to manage card insert/removal, the mmc core sticks with using
the ->get_cd() callback, which means it's the host's responsibility to make
sure it provides valid data, even if the card may be managed by PCIe/NVMe
at the moment. As long as the card seems to be present, the mmc core keeps
the card powered on.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Rui Feng <rui_feng@realsil.com.cn>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1603936636-3126-1-git-send-email-rui_feng@realsil.com.cn
Desnes Nunes
Robert Foss
Rado Vrbovsky
Jose Ignacio Tornos Martinez
Ming Lei
Lucas Karpinski
Íñigo Huguet
Chris von Recklinghausen
Wolfram Sang
Ulf Hansson
Andy Shevchenko
Jisheng Zhang
Eric Biggers
Andrew Jeffery