summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* spi: microchip-core: add support for word sizes of 1 to 32 bitsSteve Wilkins2024-07-151-22/+31
| | | | | | | | | | | The current implementation only supports a word size of 8 bits, which limits the devices it can be used with. Add support for any word size between 1 and 32 bits, as supported by the hardware. Signed-off-by: Steve Wilkins <steve.wilkins@raymarine.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20240715-cogwheel-uniquely-0d4ef518b809@wendy Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: microchip-core: ensure TX and RX FIFOs are empty at start of a transferSteve Wilkins2024-07-151-0/+4
| | | | | | | | | | | | | | While transmitting with rx_len == 0, the RX FIFO is not going to be emptied in the interrupt handler. A subsequent transfer could then read crap from the previous transfer out of the RX FIFO into the start RX buffer. The core provides a register that will empty the RX and TX FIFOs, so do that before each transfer. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Steve Wilkins <steve.wilkins@raymarine.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20240715-flammable-provoke-459226d08e70@wendy Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: microchip-core: fix init function not setting the master and motorola modesSteve Wilkins2024-07-151-8/+9
| | | | | | | | | | | | | | | mchp_corespi_init() reads the CONTROL register, sets the master and motorola bits, but doesn't write the value back to the register. The function also doesn't ensure the controller is disabled at the start, which may present a problem if the controller was used by an earlier boot stage as some settings (including the mode) can only be modified while the controller is disabled. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Steve Wilkins <steve.wilkins@raymarine.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20240715-designing-thus-05f7c26e1da7@wendy Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: microchip-core: only disable SPI controller when register value change ↵Steve Wilkins2024-07-151-38/+41
| | | | | | | | | | | | | | | | | | | | | | requires it Setting up many of the registers for a new SPI transfer involves unconditionally disabling the SPI controller, writing the register value and re-enabling the controller. This is being done for registers even when the value is unchanged and is also done for registers that don't require the controller to be disabled for the change to take effect. Make an effort to detect changes to the register values, and only disables the controller if the new register value is different and disabling the controller is required. This stops the controller being repeated disabled and the bus going tristate before every transfer. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Steve Wilkins <steve.wilkins@raymarine.com> Co-developed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20240715-depict-twirl-7e592eeabaad@wendy Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: microchip-core: defer asserting chip select until just before write to ↵Steve Wilkins2024-07-151-2/+17
| | | | | | | | | | | | | | | | | | | TX FIFO Setting up many of the registers for a new SPI transfer requires the SPI controller to be disabled after set_cs() has been called to assert the chip select line. However, disabling the controller results in the SCLK and MOSI output pins being tristate, which can cause clock transitions to be seen by a slave device whilst SS is active. To fix this, the CS is only set to inactive inline, whilst setting it active is deferred until all registers are set up and the any controller disables have been completed. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Steve Wilkins <steve.wilkins@raymarine.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20240715-sanitizer-recant-dd96b7a97048@wendy Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: microchip-core: fix the issues in the isrNaga Sureshkumar Relli2024-07-151-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | It is possible for the TXDONE interrupt be raised if the tx FIFO becomes temporarily empty while transmitting, resulting in recursive calls to mchp_corespi_write_fifo() and therefore a garbage message might be transmitted depending on when the interrupt is triggered. Moving all of the tx FIFO writes out of the TXDONE portion of the interrupt handler avoids this problem. Most of rest of the TXDONE portion of the handler is problematic too. Only reading the rx FIFO (and finalising the transfer) when the TXDONE interrupt is raised can cause the transfer to stall, if the final bytes of rx data are not available in the rx FIFO when the final TXDONE interrupt is raised. The transfer should be finalised regardless of which interrupt is raised, provided that all tx data has been set and all rx data received. The first issue was encountered "in the wild", the second is theoretical. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Naga Sureshkumar Relli <nagasuresh.relli@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20240715-candied-deforest-585685ef3c8a@wendy Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: dt-bindings: at91: Add sama7d65 compatible stringNicolas Ferre2024-07-121-4/+4
| | | | | | | | | | | | Add compatible string for sama7d65. Like sam9x60 and sam9x7, it requires to bind to "atmel,at91rm9200-spi". Group these three under the same enum, sorted alphanumerically, and remove previously added item. Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20240711165402.373634-1-nicolas.ferre@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: add ch341a usb2spi driverJohannes Thumshirn2024-07-083-0/+248
| | | | | | | | | | Add a driver for the QiHeng Electronics ch341a USB-to-SPI adapter. This driver is loosely based on the ch341a module from the flashrom project. Signed-off-by: Johannes Thumshirn <jth@kernel.org> Link: https://patch.msgid.link/20240708-spi-ch341a-v3-1-cf7f9b2c1e31@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: dt-bindings: fsl-dspi: add compatible string 'fsl,lx2160a-dspi'Frank Li2024-07-081-0/+3
| | | | | | | | | | | | | Add compatible string 'fsl,lx2160a-dspi' and allow fall back to 'fsl,ls2085a-dspi'. Fix below CHECK_DTBS warning. arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dtb: spi@2100000: compatible: 'oneOf' conditional failed, one must be fixed: ['fsl,lx2160a-dspi', 'fsl,ls2085a-dspi'] is too long Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20240703165931.2325807-2-Frank.Li@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: dt-bindings: fsl-dspi: add dmas and dma-names propertiesFrank Li2024-07-081-0/+10
| | | | | | | | | | | | | Add dmas and dma-names properties because dspi support dma transfer. Fix below warnings: arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dtb: spi@2120000: Unevaluated properties are not allowed ('dma-names', 'dmas', 'little-endian' were unexpected) from schema $id: http://devicetree.org/schemas/spi/fsl,dspi.yaml# Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20240703165931.2325807-1-Frank.Li@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: spi: Remove unnecessary ‘0’ values from statusLi zeming2024-07-081-1/+1
| | | | | | | | status is assigned first, so it does not need to initialize the assignment. Signed-off-by: Li zeming <zeming@nfschina.com> Link: https://patch.msgid.link/20240708041411.14424-1-zeming@nfschina.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: spi: Remove unnecessary ‘0’ values from rcLi zeming2024-07-081-1/+1
| | | | | | | | rc is assigned first, so it does not need to initialize the assignment. Signed-off-by: Li zeming <zeming@nfschina.com> Link: https://patch.msgid.link/20240708035320.14241-1-zeming@nfschina.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: xcomm: fix coding styleNuno Sa2024-07-051-14/+14
| | | | | | | | | | Just cosmetics. No functional change intended. While at it, removed a couple of redundant else if() statements. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240705-dev-spi-xcomm-gpiochip-v2-4-b10842fc9636@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: xcomm: remove i2c_set_clientdata()Nuno Sa2024-07-051-1/+0
| | | | | | | | | i2c_get_clientdata() is not being called anywhere so that we do not need to set clientdata. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240705-dev-spi-xcomm-gpiochip-v2-3-b10842fc9636@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: xcomm: make use of devm_spi_alloc_host()Nuno Sa2024-07-051-2/+2
| | | | | | | | | Use devm_spi_alloc_host() so that there's no need to call spi_controller_put() in the error path. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240705-dev-spi-xcomm-gpiochip-v2-2-b10842fc9636@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: xcomm: add gpiochip supportMichael Hennerich2024-07-051-1/+41
| | | | | | | | | | | The hardware can expose one pin as a GPO. Hence, register a simple gpiochip to support it. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Co-developed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240705-dev-spi-xcomm-gpiochip-v2-1-b10842fc9636@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: dt-bindings: snps,dw-apb-ssi.yaml: update compatible propertyKanak Shilledar2024-07-011-0/+4
| | | | | | | | | | updated compatible property to include "thead,th1520-spi" for the TH1520 SoC SPI Controller. Signed-off-by: Kanak Shilledar <kanakshilledar@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20240701121355.262259-3-kanakshilledar@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: dt-bindings: fsl-dspi: Convert to yaml formatFrank Li2024-07-015-66/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert dt-binding spi-fsl-dspi.txt to yaml format. Use part Vladimir Oltean's work at of https://lore.kernel.org/linux-spi/20221111224651.577729-1-vladimir.oltean@nxp.com/ Additional changes during convert: - compatible string "fsl,ls1028a-dspi" can be followed by fsl,ls1021a-v1.0-dspi. - Change "dspi0@4002c000" to "spi@4002c000" in example. - Reorder properties in example. - Use GIC include in example. - Deprecated fsl,spi-cs-sck-delay and fsl,spi-sck-cs-delay by use common SPI property. - Use compatible string 'jedec,spi-nor' in example. - Split peripheral part to fsl,dspi-peripheral-props.yaml. - Remove 'interrupts' and 'pinctrl' from required list. - Update 'bus-num' description. - Update 'spi-num-chipselects' description by add "cs-gpios don't count against this number". - Remove 'big-endian' description. Co-developed-by: Kuldeep Singh <kuldeep.singh@nxp.com> Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com> Co-developed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20240624-ls_qspi-v4-2-3d1c6f5005bf@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: fsl-dspi: use common proptery 'spi-cs-setup(hold)-delay-ns'Frank Li2024-07-011-5/+14
| | | | | | | | | | | Use SPI common DT binding properties 'spi-cs-setup-delay-ns' and 'spi-cs-hold-delay-ns'. If these properties do not exist, fall back to legacy 'fsl,spi-cs-sck-delay' and 'fsl,spi-sck-cs-delay'. Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20240624-ls_qspi-v4-1-3d1c6f5005bf@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: axi-spi-engine: remove platform_set_drvdata()David Lechner2024-06-271-7/+1
| | | | | | | | | | | platform_get_drvdata() is never called in the AXI SPI Engine driver, so platform_set_drvdata() is not needed. Remove it. This also lets us avoid the final error check in the probe function. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240626-spi-axi-spi-engine-remove-drvdata-v1-1-1752e372dd5d@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: spi-fsl-lpspi: Pass pm_ptr()Fabio Estevam2024-06-251-1/+1
| | | | | | | | | | | | After coverting to SYSTEM_SLEEP_PM_OPS, it is necessary to pass pm_ptr() to the PM operations. Fix it accordingly. Fixes: 6765e859fac9 ("spi: spi-fsl-lpspi: Switch to SYSTEM_SLEEP_PM_OPS()") Signed-off-by: Fabio Estevam <festevam@denx.de> Link: https://patch.msgid.link/20240625183919.368770-2-festevam@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: spi-imx: Pass pm_ptr()Fabio Estevam2024-06-251-1/+1
| | | | | | | | | | | | After coverting to RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS, it is necessary to pass pm_ptr() to the PM operations. Fix it accordingly. Fixes: a93f089ccf82 ("spi: spi-imx: Switch to RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS()") Signed-off-by: Fabio Estevam <festevam@denx.de> Link: https://patch.msgid.link/20240625183919.368770-1-festevam@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: add devm_spi_optimize_message() helperMark Brown2024-06-251-0/+1
|\ | | | | | | | | | | | | | | | | Merge series from David Lechner <dlechner@baylibre.com>: In the IIO subsystem, we are finding that it is common to call spi_optimize_message() during driver probe since the SPI message doesn't change for the lifetime of the driver. This patch adds a devm_spi_optimize_message() helper to simplify this common pattern.
| * spi: add EXPORT_SYMBOL_GPL(devm_spi_optimize_message)David Lechner2024-06-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | devm_spi_optimize_message() is a public function and needs EXPORT_SYMBOL_GPL. Reported-by: Jonathan Cameron <jic23@kernel.org> Closes: https://lore.kernel.org/linux-iio/20240624204424.6a91a5e4@jic23-huawei/ Fixes: d4a0055fdc22 ("spi: add devm_spi_optimize_message() helper") Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20240624-devm_spi_optimize_message-v2-1-58155c0180c2@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | spi: spi-fsl-lpspi: Switch to SYSTEM_SLEEP_PM_OPS()Fabio Estevam2024-06-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace SET_SYSTEM_SLEEP_PM_OPS with its modern SYSTEM_SLEEP_PM_OPS() alternative. The combined usage of pm_ptr() and SYSTEM_SLEEP_PM_OPS() allows the compiler to evaluate if the runtime suspend/resume() functions are used at build time or are simply dead code. This allows removing the __maybe_unused notation from the runtime suspend/resume() functions. Signed-off-by: Fabio Estevam <festevam@denx.de> Link: https://patch.msgid.link/20240625002023.228235-2-festevam@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | spi: spi-imx: Switch to RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS()Fabio Estevam2024-06-251-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace SET_RUNTIME_PM_OPS()/SET SYSTEM_SLEEP_PM_OPS() with their modern RUNTIME_PM_OPS() and SYSTEM_SLEEP_PM_OPS() alternatives. The combined usage of pm_ptr() and RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS() allows the compiler to evaluate if the runtime suspend/resume() functions are used at build time or are simply dead code. This allows removing the __maybe_unused notation from the runtime suspend/resume() functions. Signed-off-by: Fabio Estevam <festevam@denx.de> Link: https://patch.msgid.link/20240625002023.228235-1-festevam@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | spi: add devm_spi_optimize_message() helperMark Brown2024-06-23575-3282/+5887
|\| | | | | | | | | | | | | | | | | Merge series from David Lechner <dlechner@baylibre.com>: In the IIO subsystem, we are finding that it is common to call spi_optimize_message() during driver probe since the SPI message doesn't change for the lifetime of the driver. This patch adds a devm_spi_optimize_message() helper to simplify this common pattern.
| * spi: add devm_spi_optimize_message() helperDavid Lechner2024-06-223-0/+30
| | | | | | | | | | | | | | | | | | | | This adds a new helper function devm_spi_optimize_message() that automatically registers spi_unoptimize_message() to be called when the device is removed. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20240621-devm_spi_optimize_message-v1-2-3f9dcba6e95e@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * Documentation: devres: add missing SPI helpersDavid Lechner2024-06-221-0/+2
| | | | | | | | | | | | | | | | | | A few SPI devm_* helpers were missing from the devres documentation. This patch adds them. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20240621-devm_spi_optimize_message-v1-1-3f9dcba6e95e@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * Linux 6.10-rc4v6.10-rc4Linus Torvalds2024-06-161-1/+1
| |
| * Merge tag 'parisc-for-6.10-rc4' of ↵Linus Torvalds2024-06-163-180/+275
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fix from Helge Deller: "On parisc we have suffered since years from random segfaults which seem to have been triggered due to cache inconsistencies. Those segfaults happened more often on machines with PA8800 and PA8900 CPUs, which have much bigger caches than the earlier machines. Dave Anglin has worked over the last few weeks to fix this bug. His patch has been successfully tested by various people on various machines and with various kernels (6.6, 6.8 and 6.9), and the debian buildd servers haven't shown a single random segfault with this patch. Since the cache handling has been reworked, the patch is slightly bigger than I would like in this stage, but the greatly improved stability IMHO justifies the inclusion now" * tag 'parisc-for-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Try to fix random segmentation faults in package builds
| | * parisc: Try to fix random segmentation faults in package buildsJohn David Anglin2024-06-123-180/+275
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PA-RISC systems with PA8800 and PA8900 processors have had problems with random segmentation faults for many years. Systems with earlier processors are much more stable. Systems with PA8800 and PA8900 processors have a large L2 cache which needs per page flushing for decent performance when a large range is flushed. The combined cache in these systems is also more sensitive to non-equivalent aliases than the caches in earlier systems. The majority of random segmentation faults that I have looked at appear to be memory corruption in memory allocated using mmap and malloc. My first attempt at fixing the random faults didn't work. On reviewing the cache code, I realized that there were two issues which the existing code didn't handle correctly. Both relate to cache move-in. Another issue is that the present bit in PTEs is racy. 1) PA-RISC caches have a mind of their own and they can speculatively load data and instructions for a page as long as there is a entry in the TLB for the page which allows move-in. TLBs are local to each CPU. Thus, the TLB entry for a page must be purged before flushing the page. This is particularly important on SMP systems. In some of the flush routines, the flush routine would be called and then the TLB entry would be purged. This was because the flush routine needed the TLB entry to do the flush. 2) My initial approach to trying the fix the random faults was to try and use flush_cache_page_if_present for all flush operations. This actually made things worse and led to a couple of hardware lockups. It finally dawned on me that some lines weren't being flushed because the pte check code was racy. This resulted in random inequivalent mappings to physical pages. The __flush_cache_page tmpalias flush sets up its own TLB entry and it doesn't need the existing TLB entry. As long as we can find the pte pointer for the vm page, we can get the pfn and physical address of the page. We can also purge the TLB entry for the page before doing the flush. Further, __flush_cache_page uses a special TLB entry that inhibits cache move-in. When switching page mappings, we need to ensure that lines are removed from the cache. It is not sufficient to just flush the lines to memory as they may come back. This made it clear that we needed to implement all the required flush operations using tmpalias routines. This includes flushes for user and kernel pages. After modifying the code to use tmpalias flushes, it became clear that the random segmentation faults were not fully resolved. The frequency of faults was worse on systems with a 64 MB L2 (PA8900) and systems with more CPUs (rp4440). The warning that I added to flush_cache_page_if_present to detect pages that couldn't be flushed triggered frequently on some systems. Helge and I looked at the pages that couldn't be flushed and found that the PTE was either cleared or for a swap page. Ignoring pages that were swapped out seemed okay but pages with cleared PTEs seemed problematic. I looked at routines related to pte_clear and noticed ptep_clear_flush. The default implementation just flushes the TLB entry. However, it was obvious that on parisc we need to flush the cache page as well. If we don't flush the cache page, stale lines will be left in the cache and cause random corruption. Once a PTE is cleared, there is no way to find the physical address associated with the PTE and flush the associated page at a later time. I implemented an updated change with a parisc specific version of ptep_clear_flush. It fixed the random data corruption on Helge's rp4440 and rp3440, as well as on my c8000. At this point, I realized that I could restore the code where we only flush in flush_cache_page_if_present if the page has been accessed. However, for this, we also need to flush the cache when the accessed bit is cleared in ptep_clear_flush_young to keep things synchronized. The default implementation only flushes the TLB entry. Other changes in this version are: 1) Implement parisc specific version of ptep_get. It's identical to default but needed in arch/parisc/include/asm/pgtable.h. 2) Revise parisc implementation of ptep_test_and_clear_young to use ptep_get (READ_ONCE). 3) Drop parisc implementation of ptep_get_and_clear. We can use default. 4) Revise flush_kernel_vmap_range and invalidate_kernel_vmap_range to use full data cache flush. 5) Move flush_cache_vmap and flush_cache_vunmap to cache.c. Handle VM_IOREMAP case in flush_cache_vmap. At this time, I don't know whether it is better to always flush when the PTE present bit is set or when both the accessed and present bits are set. The later saves flushing pages that haven't been accessed, but we need to flush in ptep_clear_flush_young. It also needs a page table lookup to find the PTE pointer. The lpa instruction only needs a page table lookup when the PTE entry isn't in the TLB. We don't atomically handle setting and clearing the _PAGE_ACCESSED bit. If we miss an update, we may miss a flush and the cache may get corrupted. Whether the current code is effectively atomic depends on process control. When CONFIG_FLUSH_PAGE_ACCESSED is set to zero, the page will eventually be flushed when the PTE is cleared or in flush_cache_page_if_present. The _PAGE_ACCESSED bit is not used, so the problem is avoided. The flush method can be selected using the CONFIG_FLUSH_PAGE_ACCESSED define in cache.c. The default is 0. I didn't see a large difference in performance. Signed-off-by: John David Anglin <dave.anglin@bell.net> Cc: <stable@vger.kernel.org> # v6.6+ Signed-off-by: Helge Deller <deller@gmx.de>
| * | Merge tag 'i2c-for-6.10-rc4' of ↵Linus Torvalds2024-06-162-3/+2
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Two fixes to correctly report i2c functionality, ensuring that I2C_FUNC_SLAVE is reported when a device operates solely as a slave interface" * tag 'i2c-for-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: designware: Fix the functionality flags of the slave-only interface i2c: at91: Fix the functionality flags of the slave-only interface
| | * \ Merge tag 'i2c-host-fixes-6.10-rc4' of ↵Wolfram Sang2024-06-162-3/+2
| | |\ \ | | | |/ | | |/| | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux into i2c/for-current Two fixes from Jean aim to correctly report i2c functionality, specifically ensuring that I2C_FUNC_SLAVE is reported when a device operates solely as a slave interface.
| | | * i2c: designware: Fix the functionality flags of the slave-only interfaceJean Delvare2024-06-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an I2C adapter acts only as a slave, it should not claim to support I2C master capabilities. Fixes: 5b6d721b266a ("i2c: designware: enable SLAVE in platform module") Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Luis Oliveira <lolivei@synopsys.com> Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Jan Dabros <jsd@semihalf.com> Cc: Andi Shyti <andi.shyti@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
| | | * i2c: at91: Fix the functionality flags of the slave-only interfaceJean Delvare2024-06-121-2/+1
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an I2C adapter acts only as a slave, it should not claim to support I2C master capabilities. Fixes: 9d3ca54b550c ("i2c: at91: added slave mode support") Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Juergen Fitschen <me@jue.yt> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Cc: Andi Shyti <andi.shyti@kernel.org> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
| * | Merge tag 'usb-6.10-rc4' of ↵Linus Torvalds2024-06-1615-42/+131
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB / Thunderbolt fixes from Greg KH: "Here are some small USB and Thunderbolt driver fixes for 6.10-rc4. Included in here are: - thunderbolt debugfs bugfix - USB typec bugfixes - kcov usb bugfix - xhci bugfixes - usb-storage bugfix - dt-bindings bugfix - cdc-wdm log message spam bugfix All of these, except for the last cdc-wdm log level change, have been in linux-next for a while with no reported problems. The cdc-wdm bugfix has been tested by syzbot and proved to fix the reported cpu lockup issues when the log is constantly spammed by a broken device" * tag 'usb-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages xhci: Handle TD clearing for multiple streams case xhci: Apply broken streams quirk to Etron EJ188 xHCI host xhci: Apply reset resume quirk to Etron EJ188 xHCI host xhci: Set correct transferred length for cancelled bulk transfers usb-storage: alauda: Check whether the media is initialized usb: typec: ucsi: Ack also failed Get Error commands kcov, usb: disable interrupts in kcov_remote_start_usb_softirq dt-bindings: usb: realtek,rts5411: Add missing "additionalProperties" on child nodes usb: typec: tcpm: Ignore received Hard Reset in TOGGLING state usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps USB: xen-hcd: Traverse host/ when CONFIG_USB_XEN_HCD is selected usb: typec: ucsi: glink: increase max ports for x1e80100 Revert "usb: chipidea: move ci_ulpi_init after the phy initialization" thunderbolt: debugfs: Fix margin debugfs node creation condition
| | * | USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messagesAlan Stern2024-06-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The syzbot fuzzer found that the interrupt-URB completion callback in the cdc-wdm driver was taking too long, and the driver's immediate resubmission of interrupt URBs with -EPROTO status combined with the dummy-hcd emulation to cause a CPU lockup: cdc_wdm 1-1:1.0: nonzero urb status received: -71 cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625] CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idle Modules linked in: irq event stamp: 73096 hardirqs last enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline] hardirqs last enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Testing showed that the problem did not occur if the two error messages -- the first two lines above -- were removed; apparently adding material to the kernel log takes a surprisingly large amount of time. In any case, the best approach for preventing these lockups and to avoid spamming the log with thousands of error messages per second is to ratelimit the two dev_err() calls. Therefore we replace them with dev_err_ratelimited(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Suggested-by: Greg KH <gregkh@linuxfoundation.org> Reported-and-tested-by: syzbot+5f996b83575ef4058638@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/00000000000073d54b061a6a1c65@google.com/ Reported-and-tested-by: syzbot+1b2abad17596ad03dcff@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000f45085061aa9b37e@google.com/ Fixes: 9908a32e94de ("USB: remove err() macro from usb class drivers") Link: https://lore.kernel.org/linux-usb/40dfa45b-5f21-4eef-a8c1-51a2f320e267@rowland.harvard.edu/ Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/29855215-52f5-4385-b058-91f42c2bee18@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | xhci: Handle TD clearing for multiple streams caseHector Martin2024-06-122-11/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again. [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. The choice of making the log type xhci_dbg() for what is, at this point, a completely unhandled and known broken condition is puzzling and unfortunate, as it guarantees that no actual users would see the log in production, thereby making it nigh undebuggable (indeed, even if you turn on DEBUG, the message doesn't really hint at there being a problem at all). It took me *months* of random xHC crashes to finally find a reliable repro and be able to do a deep dive debug session, which could all have been avoided had this unhandled, broken condition been actually reported with a warning, as it should have been as a bug intentionally left in unfixed (never mind that it shouldn't have been left in at all). > Another fix to solve clearing the caches of all stream rings with > cancelled TDs is needed, but not as urgent. 3 years after that statement and 14 years after the original bug was introduced, I think it's finally time to fix it. And maybe next time let's not leave bugs unfixed (that are actually worse than the original bug), and let's actually get people to review kernel commits please. Fixes xHC crashes and IOMMU faults with UAS devices when handling errors/faults. Easiest repro is to use `hdparm` to mark an early sector (e.g. 1024) on a disk as bad, then `cat /dev/sdX > /dev/null` in a loop. At least in the case of JMicron controllers, the read errors end up having to cancel two TDs (for two queued requests to different streams) and the one that didn't get cleared properly ends up faulting the xHC entirely when it tries to access DMA pages that have since been unmapped, referred to by the stale TDs. This normally happens quickly (after two or three loops). After this fix, I left the `cat` in a loop running overnight and experienced no xHC failures, with all read errors recovered properly. Repro'd and tested on an Apple M1 Mac Mini (dwc3 host). On systems without an IOMMU, this bug would instead silently corrupt freed memory, making this a security bug (even on systems with IOMMUs this could silently corrupt memory belonging to other USB devices on the same controller, so it's still a security bug). Given that the kernel autoprobes partition tables, I'm pretty sure a malicious USB device pretending to be a UAS device and reporting an error with the right timing could deliberately trigger a UAF and write to freed memory, with no user action. [Mathias: Commit message and code comment edit, original at:] https://lore.kernel.org/linux-usb/20240524-xhci-streams-v1-1-6b1f13819bea@marcan.st/ Fixes: e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") Fixes: 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") Fixes: 674f8438c121 ("xhci: split handling halted endpoints into two steps") Cc: stable@vger.kernel.org Cc: security@kernel.org Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240611120610.3264502-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | xhci: Apply broken streams quirk to Etron EJ188 xHCI hostKuangyi Chiang2024-06-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As described in commit 8f873c1ff4ca ("xhci: Blacklist using streams on the Etron EJ168 controller"), EJ188 have the same issue as EJ168, where Streams do not work reliable on EJ188. So apply XHCI_BROKEN_STREAMS quirk to EJ188 as well. Cc: stable@vger.kernel.org Signed-off-by: Kuangyi Chiang <ki.chiang65@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240611120610.3264502-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | xhci: Apply reset resume quirk to Etron EJ188 xHCI hostKuangyi Chiang2024-06-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As described in commit c877b3b2ad5c ("xhci: Add reset on resume quirk for asrock p67 host"), EJ188 have the same issue as EJ168, where completely dies on resume. So apply XHCI_RESET_ON_RESUME quirk to EJ188 as well. Cc: stable@vger.kernel.org Signed-off-by: Kuangyi Chiang <ki.chiang65@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240611120610.3264502-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | xhci: Set correct transferred length for cancelled bulk transfersMathias Nyman2024-06-121-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The transferred length is set incorrectly for cancelled bulk transfer TDs in case the bulk transfer ring stops on the last transfer block with a 'Stop - Length Invalid' completion code. length essentially ends up being set to the requested length: urb->actual_length = urb->transfer_buffer_length Length for 'Stop - Length Invalid' cases should be the sum of all TRB transfer block lengths up to the one the ring stopped on, _excluding_ the one stopped on. Fix this by always summing up TRB lengths for 'Stop - Length Invalid' bulk cases. This issue was discovered by Alan Stern while debugging https://bugzilla.kernel.org/show_bug.cgi?id=218890, but does not solve that bug. Issue is older than 4.10 kernel but fix won't apply to those due to major reworks in that area. Tested-by: Pierre Tomon <pierretom+12@ik.me> Cc: stable@vger.kernel.org # v4.10+ Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240611120610.3264502-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | Merge tag 'thunderbolt-for-v6.10-rc3' of ↵Greg Kroah-Hartman2024-06-071-2/+3
| | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next Mika writes: thunderbolt: Fix for v6.10-rc3 This includes one USB4/Thunderbolt fix for v6.10-rc3: - Fix lane margining debugfs node creation condition. This has been in linux-next with no reported issues.
| | | * | thunderbolt: debugfs: Fix margin debugfs node creation conditionAapo Vienamo2024-05-311-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The margin debugfs node controls the "Enable Margin Test" field of the lane margining operations. This field selects between either low or high voltage margin values for voltage margin test or left or right timing margin values for timing margin test. According to the USB4 specification, whether or not the "Enable Margin Test" control applies, depends on the values of the "Independent High/Low Voltage Margin" or "Independent Left/Right Timing Margin" capability fields for voltage and timing margin tests respectively. The pre-existing condition enabled the debugfs node also in the case where both low/high or left/right margins are returned, which is incorrect. This change only enables the debugfs node in question, if the specific required capability values are met. Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Fixes: d0f1e0c2a699 ("thunderbolt: Add support for receiver lane margining") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | usb-storage: alauda: Check whether the media is initializedShichao Lai2024-06-041-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media(). Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support") Reported-by: xingwei lee <xrivendell7@gmail.com> Reported-by: yue sun <samsun1006219@gmail.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Shichao Lai <shichaorai@gmail.com> Link: https://lore.kernel.org/r/20240526012745.2852061-1-shichaorai@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | usb: typec: ucsi: Ack also failed Get Error commandsHeikki Krogerus2024-06-041-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible that also the GET_ERROR command fails. If that happens, the command completion still needs to be acknowledged. Otherwise the interface will be stuck until it's reset. Reported-by: Ammy Yi <ammy.yi@intel.com> Fixes: bdc62f2bae8f ("usb: typec: ucsi: Simplified registration and I/O API") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240531104653.1303519-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | kcov, usb: disable interrupts in kcov_remote_start_usb_softirqAndrey Konovalov2024-06-042-14/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit 8fea0c8fda30 ("usb: core: hcd: Convert from tasklet to BH workqueue"), usb_giveback_urb_bh() runs in the BH workqueue with interrupts enabled. Thus, the remote coverage collection section in usb_giveback_urb_bh()-> __usb_hcd_giveback_urb() might be interrupted, and the interrupt handler might invoke __usb_hcd_giveback_urb() again. This breaks KCOV, as it does not support nested remote coverage collection sections within the same context (neither in task nor in softirq). Update kcov_remote_start/stop_usb_softirq() to disable interrupts for the duration of the coverage collection section to avoid nested sections in the softirq context (in addition to such in the task context, which are already handled). Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Closes: https://lore.kernel.org/linux-usb/0f4d1964-7397-485b-bc48-11c01e2fcbca@I-love.SAKURA.ne.jp/ Closes: https://syzkaller.appspot.com/bug?extid=0438378d6f157baae1a2 Suggested-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 8fea0c8fda30 ("usb: core: hcd: Convert from tasklet to BH workqueue") Cc: stable@vger.kernel.org Acked-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrey Konovalov <andreyknvl@gmail.com> Link: https://lore.kernel.org/r/20240527173538.4989-1-andrey.konovalov@linux.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | dt-bindings: usb: realtek,rts5411: Add missing "additionalProperties" on ↵Rob Herring (Arm)2024-06-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | child nodes All nodes need an explicit additionalProperties or unevaluatedProperties unless a $ref has one that's false. As that is not the case with usb-device.yaml, "additionalProperties" is needed here. Fixes: c44d9dab31d6 ("dt-bindings: usb: Add downstream facing ports to realtek binding") Signed-off-by: "Rob Herring (Arm)" <robh@kernel.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20240523194500.2958192-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | usb: typec: tcpm: Ignore received Hard Reset in TOGGLING stateKyle Tso2024-06-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to what fixed in Commit a6fe37f428c1 ("usb: typec: tcpm: Skip hard reset when in error recovery"), the handling of the received Hard Reset has to be skipped during TOGGLING state. [ 4086.021288] VBUS off [ 4086.021295] pending state change SNK_READY -> SNK_UNATTACHED @ 650 ms [rev2 NONE_AMS] [ 4086.022113] VBUS VSAFE0V [ 4086.022117] state change SNK_READY -> SNK_UNATTACHED [rev2 NONE_AMS] [ 4086.022447] VBUS off [ 4086.022450] state change SNK_UNATTACHED -> SNK_UNATTACHED [rev2 NONE_AMS] [ 4086.023060] VBUS VSAFE0V [ 4086.023064] state change SNK_UNATTACHED -> SNK_UNATTACHED [rev2 NONE_AMS] [ 4086.023070] disable BIST MODE TESTDATA [ 4086.023766] disable vbus discharge ret:0 [ 4086.023911] Setting usb_comm capable false [ 4086.028874] Setting voltage/current limit 0 mV 0 mA [ 4086.028888] polarity 0 [ 4086.030305] Requesting mux state 0, usb-role 0, orientation 0 [ 4086.033539] Start toggling [ 4086.038496] state change SNK_UNATTACHED -> TOGGLING [rev2 NONE_AMS] // This Hard Reset is unexpected [ 4086.038499] Received hard reset [ 4086.038501] state change TOGGLING -> HARD_RESET_START [rev2 HARD_RESET] Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable@vger.kernel.org Signed-off-by: Kyle Tso <kyletso@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240520154858.1072347-1-kyletso@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | usb: typec: tcpm: fix use-after-free case in tcpm_register_source_capsAmit Sunil Dhamne2024-06-041-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There could be a potential use-after-free case in tcpm_register_source_caps(). This could happen when: * new (say invalid) source caps are advertised * the existing source caps are unregistered * tcpm_register_source_caps() returns with an error as usb_power_delivery_register_capabilities() fails This causes port->partner_source_caps to hold on to the now freed source caps. Reset port->partner_source_caps value to NULL after unregistering existing source caps. Fixes: 230ecdf71a64 ("usb: typec: tcpm: unregister existing source caps before re-registration") Cc: stable@vger.kernel.org Signed-off-by: Amit Sunil Dhamne <amitsd@google.com> Reviewed-by: Ondrej Jirman <megi@xff.cz> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240514220134.2143181-1-amitsd@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-07 21:46:07 +0100