aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-08-24mmc: pwrseq: sd8787: add support for wilc1000Claudiu Beznea1-2/+9
Add new compatible for wilc1000 devices and specify the delay in .data member of struct of_device_id. WILC1000, WILC3000 devices needs a minimum of 5ms delay b/w reset and power lines. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20210820092803.78523-3-claudiu.beznea@microchip.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24dt-bindings: mmc: Extend pwrseq-sd8787 binding for wilc1000Claudiu Beznea1-1/+3
Extend the DT bindings to support wilc1000 devices. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210820092803.78523-2-claudiu.beznea@microchip.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24dt-bindings: mmc: fsl-imx-esdhc: change the pinctrl-names ruleHaibo Chen1-6/+11
Change the pinctrl-names rule to cover all cases. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1629373938-9226-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24dt-bindings: mmc: fsl-imx-esdhc: add a new compatible stringHaibo Chen1-0/+1
Lack a compatible string "fsl,imx6sll-usdhc", so add it here. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1629278277-7313-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24dt-bindings: mmc: renesas,sdhi: Document RZ/G2L bindingsBiju Das1-21/+52
Document RZ/G2L SDHI controller bindings. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210817090313.31858-3-biju.das.jz@bp.renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24dt-bindings: mmc: renesas,sdhi: Fix dtbs-check warningBiju Das1-23/+37
Fix dtbs-check warning pinctrl-names:0:'default' was expected for r8a77470-iwg23s-sbc.dts file. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210817090313.31858-2-biju.das.jz@bp.renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: core: Update ->card_busy() callback commentMårten Lindahl1-1/+1
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>
2021-08-24mmc: usdhi6rol0: Implement card_busy functionMårten Lindahl1-0/+10
When switching card voltage to UHS voltage the mmc framework tries to check the card busy signal, meaning the card pulling DAT0 line low, before the switch is made. Drivers that does not implement the card_busy function will manage to do the switch anyway, but the framework will print a warning about not being able to verify the voltage signal. Implement card_busy function. Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20210816142314.1168-1-marten.lindahl@axis.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdhci: Correct the tuning command handle for PIO modeHaibo Chen1-2/+8
If sdhci use PIO mode, and use mmc_send_tuning() to send the tuning command, system will stuck because of the storm irq of sdhci. For PIO mode, use mmc_send_tuning(), it will trigger buffer_read_ready interrupt and data transfer complete interrupt. In current code logic, it will directly return in sdhci_data_irq, can not call the sdhci_transfer_pio(). So the buffer_read_ready interrupt storm happen. So for standard tuning method, need to exclude this case. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1628858041-1911-1-git-send-email-haibo.chen@nxp.com [Ulf: Dropped redundant parenthesis in an expression] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: renesas_sdhi: Refactor renesas_sdhi_probe()Yoshihiro Shimoda4-96/+141
Refactor renesas_sdhi_probe() to avoid increasing numbers of sdhi_quirks_match[] entry when we add other stable SoCs like r8a779m*. Note that the sdhi_quirks_match[] is only needed on renesas_sdhi_internal_dmac.c so that of_data of renesas_sdhi_sys_dmac.c keeps as-is. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210729103234.480743-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: moxart: Fix issue with uninitialized dma_slave_configTony Lindgren1-0/+1
Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures. For moxart, this is probably not currently an issue but is still good to fix though. Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver") Cc: Jonas Jensen <jonas.jensen@gmail.com> Cc: Vinod Koul <vkoul@kernel.org> Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20210810081644.19353-3-tony@atomide.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: dw_mmc: Fix issue with uninitialized dma_slave_configTony Lindgren1-0/+1
Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures. For dw_mmc, this is probably not currently an issue but is still good to fix though. Fixes: 3fc7eaef44db ("mmc: dw_mmc: Add external dma interface support") Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com> Cc: Vinod Koul <vkoul@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20210810081644.19353-2-tony@atomide.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdhci: Fix issue with uninitialized dma_slave_configTony Lindgren1-0/+1
Depending on the DMA driver being used, the struct dma_slave_config may need to be initialized to zero for the unused data. For example, we have three DMA drivers using src_port_window_size and dst_port_window_size. If these are left uninitialized, it can cause DMA failures at least if external TI SDMA is ever configured for sdhci. For other external DMA cases, this is probably not currently an issue but is still good to fix though. Fixes: 18e762e3b7a7 ("mmc: sdhci: add support for using external DMA devices") Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Chunyan Zhang <zhang.chunyan@linaro.org> Cc: Faiz Abbas <faiz_abbas@ti.com> Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com> Cc: Vinod Koul <vkoul@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20210810081644.19353-1-tony@atomide.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdhci-msm: Use maximum possible data timeout valueSahitya Tummala1-0/+3
The Qcom SD controller defines the usage of 0xF in data timeout counter register (0x2E) which is actually a reserved bit as per specification. This would result in maximum of 21.26 secs timeout value. Some SDcard taking more time than 2.67secs (timeout value corresponding to 0xE) and with that observed data timeout errors. So increasing the timeout value to max possible timeout. Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1628232901-30897-3-git-send-email-sartgarg@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdhci: Introduce max_timeout_count variable in sdhci_hostSarthak Garg2-7/+10
Introduce max_timeout_count variable in the sdhci_host structure and use in timeout calculation. By default its set to 0xE (max timeout register value as per SDHC spec). But at the same time vendors drivers can update it if they support different max timeout register value than 0xE. Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1628232901-30897-2-git-send-email-sartgarg@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: rtsx_pci: Fix long reads when clock is prescaledThomas Hebb1-13/+23
For unexplained reasons, the prescaler register for this device needs to be cleared (set to 1) while performing a data read or else the command will hang. This does not appear to affect the real clock rate sent out on the bus, so I assume it's purely to work around a hardware bug. During normal operation, the prescaler is already set to 1, so nothing needs to be done. However, in "initial mode" (which is used for sub-MHz clock speeds, like the core sets while enumerating cards), it's set to 128 and so we need to reset it during data reads. We currently fail to do this for long reads. This has no functional affect on the driver's operation currently written, as the MMC core always sets a clock above 1MHz before attempting any long reads. However, the core could conceivably set any clock speed at any time and the driver should still work, so I think this fix is worthwhile. I personally encountered this issue while performing data recovery on an external chip. My connections had poor signal integrity, so I modified the core code to reduce the clock speed. Without this change, I saw the card enumerate but was unable to actually read any data. Writes don't seem to work in the situation described above even with this change (and even if the workaround is extended to encompass data write commands). I was not able to find a way to get them working. Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Link: https://lore.kernel.org/r/2fef280d8409ab0100c26c6ac7050227defd098d.1627818365.git.tommyhebb@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdio: Print contents of unknown CIS tuplesSean Anderson1-3/+5
Print out the contents of the offending tuples when we do print them. This can make it easier to debug, since these tuples are not exposed to userspace anywhere else. We are limited to 64 bytes, so keep printing out the full length in case the tuple is truncated. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/20210726163654.1110969-2-sean.anderson@seco.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdio: Don't warn about vendor CIS tuplesSean Anderson1-5/+15
CIS tuples in the range 0x80-0x8F are reserved for vendors. Some devices have tuples in this range which get warned about every boot. Since this is normal behavior, don't print these tuples unless debug is enabled. Unfortunately, we cannot use a variable for the format string since it gets pasted by pr_*_ratelimited. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/20210726163654.1110969-1-sean.anderson@seco.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24memstick: ms_block: Fix spelling contraction "cant" -> "can't"Colin Ian King1-1/+1
There is a spelling mistake in a pr_err message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210728103254.171546-1-colin.king@canonical.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: core: Only print retune error when we don't check for card removalWolfram Sang1-5/+7
Skip printing a retune error when we scan for a removed card because we then expect a failed command. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20210630041658.7574-1-wsa+renesas@sang-engineering.com [Ulf: Rebased patch] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: core: Store pointer to bio_crypt_ctx in mmc_requestEric Biggers3-15/+10
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>
2021-08-24mmc: sdhci-esdhc-imx: Remove unneeded mmc-esdhc-imx.h headerFabio Estevam2-43/+32
After the i.MX conversion to a DT-only platform, the mmc-esdhc-imx.h header file is no longer used outside the driver, so move its content to the sdhci-esdhc-imx driver and remove the header. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20210719193413.3792615-1-festevam@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: core: Avoid hogging the CPU while polling for busy after I/O writesUlf Hansson2-40/+30
When mmc_blk_card_busy() calls card_busy_detect() to poll for the card's state with CMD13, this is done without any delays in between the commands being sent. Rather than fixing card_busy_detect() in this regards, let's instead convert into using the common __mmc_poll_for_busy(), which also helps us to avoid open-coding. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://lore.kernel.org/r/20210702134229.357717-4-ulf.hansson@linaro.org
2021-08-24mmc: core: Avoid hogging the CPU while polling for busy for mmc ioctlsUlf Hansson1-1/+2
When __mmc_blk_ioctl_cmd() calls card_busy_detect() to verify that the card's states moves back into transfer state, the polling with CMD13 is done without any delays in between the commands being sent. Rather than fixing card_busy_detect() in this regards, let's instead convert into using the common mmc_poll_for_busy(), which also helps us to avoid open-coding. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://lore.kernel.org/r/20210702134229.357717-3-ulf.hansson@linaro.org
2021-08-24mmc: core: Avoid hogging the CPU while polling for busy in the I/O err pathUlf Hansson3-2/+5
When mmc_blk_fix_state() sends a CMD12 to try to move the card into the transfer state, it calls card_busy_detect() to poll for the card's state with CMD13. This is done without any delays in between the commands being sent. Rather than fixing card_busy_detect() in this regards, let's instead convert into using the common mmc_poll_for_busy(), which also helps us to avoid open-coding. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://lore.kernel.org/r/20210702134229.357717-2-ulf.hansson@linaro.org
2021-08-24mmc: dw_mmc: Add data CRC error injectionVincent Whitchurch2-0/+80
This driver has had problems when handling data errors. Add fault injection support so that the abort handling can be easily triggered and regression-tested. A hrtimer is used to indicate a data CRC error at various points during the data transfer. Note that for the recent problem with hangs in the case of some data CRC errors, a udelay(10) inserted at the start of send_stop_abort() greatly helped in triggering the error, but I've not included this as part of the fault injection support since it seemed too specific. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Link: https://lore.kernel.org/r/20210701080534.23138-1-vincent.whitchurch@axis.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: mmc_spi: Simplify busy loop in mmc_spi_skip()Andy Shevchenko1-11/+4
Infinite loops are hard to read and understand because of hidden main loop condition. Simplify such one in mmc_spi_skip(). Using schedule() to schedule (and be friendly to others) is discouraged and cond_resched() should be used instead. Hence, replace schedule() with cond_resched() at the same time. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210623101731.87885-1-andriy.shevchenko@linux.intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: mmci: De-assert reset on probeLinus Walleij1-0/+3
If we find a reset handle when probing the MMCI block, make sure the reset is de-asserted. It could happen that a hardware has reset asserted at boot. Cc: Russell King <linux@armlinux.org.uk> Cc: Yann Gautier <yann.gautier@foss.st.com> Cc: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20210630102408.3543024-1-linus.walleij@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: usdhi6rol0: use proper DMAENGINE API for terminationWolfram Sang1-2/+2
dmaengine_terminate_all() is deprecated in favor of explicitly saying if it should be sync or async. Here, we want dmaengine_terminate_sync() because there is no other synchronization code in the driver to handle an async case. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210623095734.3046-4-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sh_mmcif: use proper DMAENGINE API for terminationWolfram Sang1-2/+2
dmaengine_terminate_all() is deprecated in favor of explicitly saying if it should be sync or async. Here, we want dmaengine_terminate_sync() because there is no other synchronization code in the driver to handle an async case. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210623095734.3046-3-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: renesas_sdhi_sys_dmac: use proper DMAENGINE API for terminationWolfram Sang1-2/+2
dmaengine_terminate_all() is deprecated in favor of explicitly saying if it should be sync or async. Here, we want dmaengine_terminate_sync() because there is no other synchronization code in the driver to handle an async case. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210623095734.3046-2-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24dt-bindings: mmc: sdhci-msm: Add compatible string for sc7280Shaik Sajida Bhanu1-0/+1
Add sc7280 SoC specific compatible strings for qcom-sdhci controller. Signed-off-by: Shaik Sajida Bhanu <sbhanu@codeaurora.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1623835207-29462-1-git-send-email-sbhanu@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: arasan: Fix the issue in reading tap values from DTSai Krishna Potthuri1-2/+4
'of_property_read_variable_u32_array' function returns number of elements read on success. This patch updates the condition check in the driver to overwrite the tap values from DT if exist. Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com> Signed-off-by: Manish Narani <manish.narani@xilinx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1623753837-21035-8-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdhci-of-arasan: Modify data type of the clk_phase arrayManish Narani1-1/+1
Modify the data type of the clk_phase array to u32 to make it compatible with the argument requirement of "of_property_read_variable_u32_array". Addresses-coverity: ("incompatible_param") Signed-off-by: Manish Narani <manish.narani@xilinx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1623753837-21035-7-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdhci-of-arasan: Use appropriate type of division macroManish Narani1-1/+1
The division macro DIV_ROUND_CLOSEST takes int values as the argument. However the code here uses unsigned int values for this, which is causing the values comparison with 0 as always true. We can use DIV_ROUND_CLOSEST_ULL instead for the same. Addresses-coverity: ("result_independent_of_operands") Signed-off-by: Manish Narani <manish.narani@xilinx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1623753837-21035-6-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdhci-of-arasan: Check return value of non-void funtionsManish Narani1-3/+15
At a couple of places, the return values of the non-void functions were not getting checked. This was reported by the coverity tool. Modify the code to check the return values of the same. Addresses-Coverity: ("check_return") Signed-off-by: Manish Narani <manish.narani@xilinx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1623753837-21035-5-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdhci-of-arasan: Skip Auto tuning for DDR50 mode in ZynqMP platformManish Narani1-0/+4
ZynqMP platform does not perform auto tuning in DDR50 mode. Skip the same while the card is operating in DDR50 mode. Signed-off-by: Manish Narani <manish.narani@xilinx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1623753837-21035-4-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdhci-of-arasan: Add "SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12" quirk.Manish Narani1-0/+1
Arasan controller supports AUTO CMD12, this patch adds "SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12" quirk to enable auto cmd12 feature. By using auto cmd12 we can also avoid following error message "Got data interrupt even though no data operation in progress" Signed-off-by: Manish Narani <manish.narani@xilinx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1623753837-21035-3-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: sdhci-of-arasan: Modified SD default speed to 19MHz for ZynqMPManish Narani1-0/+18
SD standard speed timing was met only at 19MHz and not 25 MHz, that's why changing driver to 19MHz. The reason for this is when a level shifter is used on the board, timing was met for standard speed only at 19MHz. Since this level shifter is commonly required for high speed modes, the driver is modified to use standard speed of 19Mhz. Signed-off-by: Manish Narani <manish.narani@xilinx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1623753837-21035-2-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: host: factor out clearing the retune stateWolfram Sang3-4/+8
We have this in two places, so let's have a dedicated function. It is also more readable. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20210624151616.38770-4-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-24mmc: host: add kdoc for mmc_retune_{en|dis}ableWolfram Sang1-0/+10
I wanted to use it in a wrong way, so document the intended way. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20210624151616.38770-3-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-08-22Linux 5.14-rc7Linus Torvalds1-1/+1
2021-08-21fs: warn about impending deprecation of mandatory locksJeff Layton1-1/+5
We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros have disabled it. Warn the stragglers that still use "-o mand" that we'll be dropping support for that mount option. Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton <jlayton@kernel.org>
2021-08-20io_uring: fix xa_alloc_cycle() error return value checkJens Axboe1-4/+5
We currently check for ret != 0 to indicate error, but '1' is a valid return and just indicates that the allocation succeeded with a wrap. Correct the check to be for < 0, like it was before the xarray conversion. Cc: stable@vger.kernel.org Fixes: 61cf93700fe6 ("io_uring: Convert personality_idr to XArray") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-20hugetlb: don't pass page cache pages to restore_reserve_on_errorMike Kravetz1-5/+14
syzbot hit kernel BUG at fs/hugetlbfs/inode.c:532 as described in [1]. This BUG triggers if the HPageRestoreReserve flag is set on a page in the page cache. It should never be set, as the routine huge_add_to_page_cache explicitly clears the flag after adding a page to the cache. The only code other than huge page allocation which sets the flag is restore_reserve_on_error. It will potentially set the flag in rare out of memory conditions. syzbot was injecting errors to cause memory allocation errors which exercised this specific path. The code in restore_reserve_on_error is doing the right thing. However, there are instances where pages in the page cache were being passed to restore_reserve_on_error. This is incorrect, as once a page goes into the cache reservation information will not be modified for the page until it is removed from the cache. Error paths do not remove pages from the cache, so even in the case of error, the page will remain in the cache and no reservation adjustment is needed. Modify routines that potentially call restore_reserve_on_error with a page cache page to no longer do so. Note on fixes tag: Prior to commit 846be08578ed ("mm/hugetlb: expand restore_reserve_on_error functionality") the routine would not process page cache pages because the HPageRestoreReserve flag is not set on such pages. Therefore, this issue could not be trigggered. The code added by commit 846be08578ed ("mm/hugetlb: expand restore_reserve_on_error functionality") is needed and correct. It exposed incorrect calls to restore_reserve_on_error which is the root cause addressed by this commit. [1] https://lore.kernel.org/linux-mm/00000000000050776d05c9b7c7f0@google.com/ Link: https://lkml.kernel.org/r/20210818213304.37038-1-mike.kravetz@oracle.com Fixes: 846be08578ed ("mm/hugetlb: expand restore_reserve_on_error functionality") Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Reported-by: <syzbot+67654e51e54455f1c585@syzkaller.appspotmail.com> Cc: Mina Almasry <almasrymina@google.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Peter Xu <peterx@redhat.com> Cc: Muchun Song <songmuchun@bytedance.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-08-20kfence: fix is_kfence_address() for addresses below KFENCE_POOL_SIZEMarco Elver1-3/+4
Originally the addr != NULL check was meant to take care of the case where __kfence_pool == NULL (KFENCE is disabled). However, this does not work for addresses where addr > 0 && addr < KFENCE_POOL_SIZE. This can be the case on NULL-deref where addr > 0 && addr < PAGE_SIZE or any other faulting access with addr < KFENCE_POOL_SIZE. While the kernel would likely crash, the stack traces and report might be confusing due to double faults upon KFENCE's attempt to unprotect such an address. Fix it by just checking that __kfence_pool != NULL instead. Link: https://lkml.kernel.org/r/20210818130300.2482437-1-elver@google.com Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure") Signed-off-by: Marco Elver <elver@google.com> Reported-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> Acked-by: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> [5.12+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-08-20mm: vmscan: fix missing psi annotation for node_reclaim()Johannes Weiner1-0/+3
In a debugging session the other day, Rik noticed that node_reclaim() was missing memstall annotations. This means we'll miss pressure and lost productivity resulting from reclaim on an overloaded local NUMA node when vm.zone_reclaim_mode is enabled. There haven't been any reports, but that's likely because vm.zone_reclaim_mode hasn't been a commonly used feature recently, and the intersection between such setups and psi users is probably nil. But secondary memory such as CXL-connected DIMMS, persistent memory etc, and the page demotion patches that handle them (https://lore.kernel.org/lkml/20210401183216.443C4443@viggo.jf.intel.com/) could soon make this a more common codepath again. Link: https://lkml.kernel.org/r/20210818152457.35846-1-hannes@cmpxchg.org Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reported-by: Rik van Riel <riel@surriel.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-08-20mm/hwpoison: retry with shake_page() for unhandlable pagesNaoya Horiguchi1-3/+9
HWPoisonHandlable() sometimes returns false for typical user pages due to races with average memory events like transfers over LRU lists. This causes failures in hwpoison handling. There's retry code for such a case but does not work because the retry loop reaches the retry limit too quickly before the page settles down to handlable state. Let get_any_page() call shake_page() to fix it. [naoya.horiguchi@nec.com: get_any_page(): return -EIO when retry limit reached] Link: https://lkml.kernel.org/r/20210819001958.2365157-1-naoya.horiguchi@linux.dev Link: https://lkml.kernel.org/r/20210817053703.2267588-1-naoya.horiguchi@linux.dev Fixes: 25182f05ffed ("mm,hwpoison: fix race with hugetlb page allocation") Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com> Reported-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Yang Shi <shy828301@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Muchun Song <songmuchun@bytedance.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Michal Hocko <mhocko@suse.com> Cc: <stable@vger.kernel.org> [5.13+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-08-20mm: memcontrol: fix occasional OOMs due to proportional memory.low reclaimJohannes Weiner2-22/+34
We've noticed occasional OOM killing when memory.low settings are in effect for cgroups. This is unexpected and undesirable as memory.low is supposed to express non-OOMing memory priorities between cgroups. The reason for this is proportional memory.low reclaim. When cgroups are below their memory.low threshold, reclaim passes them over in the first round, and then retries if it couldn't find pages anywhere else. But when cgroups are slightly above their memory.low setting, page scan force is scaled down and diminished in proportion to the overage, to the point where it can cause reclaim to fail as well - only in that case we currently don't retry, and instead trigger OOM. To fix this, hook proportional reclaim into the same retry logic we have in place for when cgroups are skipped entirely. This way if reclaim fails and some cgroups were scanned with diminished pressure, we'll try another full-force cycle before giving up and OOMing. [akpm@linux-foundation.org: coding-style fixes] Link: https://lkml.kernel.org/r/20210817180506.220056-1-hannes@cmpxchg.org Fixes: 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim") Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reported-by: Leon Yang <lnyng@fb.com> Reviewed-by: Rik van Riel <riel@surriel.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Acked-by: Roman Gushchin <guro@fb.com> Acked-by: Chris Down <chris@chrisdown.name> Acked-by: Michal Hocko <mhocko@suse.com> Cc: <stable@vger.kernel.org> [5.4+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-08-20MAINTAINERS: update ClangBuiltLinux IRC chatNathan Chancellor1-1/+1
Everyone has moved from Freenode to Libera so updated the channel entry for MAINTAINERS. Link: https://github.com/ClangBuiltLinux/linux/issues/1402 Link: https://lkml.kernel.org/r/20210818022339.3863058-1-nathan@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>