- 14 Feb, 2023 8 commits
-
-
Vadim Fedorenko authored
Xilinx PG158 page 80 [1] states that master transaction inhibit bit must be set to properly setup the transaction in QSPI mode. Add the force_irq flag to follow this sequence. [1] https://docs.xilinx.com/r/en-US/pg153-axi-quad-spi/Dual/Quad-SPI-Mode-TransactionsSigned-off-by:
Vadim Fedorenko <vadfed@meta.com> Link: https://lore.kernel.org/r/20230214135928.1253205-1-vadfed@meta.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series from Dhruva Gole <d-gole@ti.com>: * Reset the CMD_CTRL Register, without which read/writes in STIG mode were failing in some cases. The issue came to light while using STIG Mode for small reads. * Also add a flag that can allow us to do direct reads but distinguish direct writes, thus enabling us to disable writes in DAC mode in some cases that require it. (Like to write to some connected Flash registers) * Fix register reads in STIG mode and also use STIG mode while reading flash registers. Currently if you try to read a register while in STIG mode there is no support for ADDR and thus naturally a register never gets read from the flash. This patch series has been tested on a TI AM625-SK-EVM with both a quad spi nor flash (s25hs) and OSPI NOR Flash (s28hs). Output of ltp-ddt test, "DD_RW_ERASESIZE_UBIFS" run with s25hs512t flash: ... [ 2.334068] spi-nor spi0.0: s25hs512t (65536 Kbytes) [ 2.339185] 7 fixed-partitions partitions found on MTD device fc40000.spi.0 [ 2.346158] Creating 7 MTD partitions on "fc40000.spi.0": [ 2.351555] 0x000000000000-0x000000080000 : "ospi.tiboot3" [ 2.358344] 0x000000080000-0x000000280000 : "ospi.tispl" [ 2.364788] 0x000000280000-0x000000680000 : "ospi.u-boot" [ 2.371311] 0x000000680000-0x0000006c0000 : "ospi.env" [ 2.377519] 0x0000006c0000-0x000000700000 : "ospi.env.backup" [ 2.384419] 0x000000800000-0x000003fc0000 : "ospi.rootfs" [ 2.390890] 0x000003fc0000-0x000004000000 : "ospi.phypattern" ..snip.. Test Start Time: Wed Jan 11 21:14:31 2023 ----------------------------------------- Testcase Result Exit Value -------- ------ ---------- OSPI_S_FUNC_DD_RW_ERASESIZE_UBIFS PASS 0 ----------------------------------------------- Total Tests: 1 Total Skipped Tests: 0 Total Failures: 0 Kernel Version: 6.2.0-rc1-00040-g700d796a94e0-dirty Machine Architecture: aarch64 Hostname: am62xx-evm
-
Alain Volmat authored
Convert spi-st-ssc.txt into st,ssc-spi.yaml for the ST Microelectronics SSC SPI driver. Signed-off-by:
Alain Volmat <avolmat@me.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230213192349.17101-1-avolmat@me.comSigned-off-by:
-
Christophe JAILLET authored
Group some variables based on their sizes to reduce hole and avoid padding. On x86_64, this shrinks the size from 144 to 128 bytes. Turn 'timestamped' into a bitfield so that it can be easily merged with some other bifields and move 'error'. This should have no real impact on memory allocation because 'struct spi_transfer' is mostly used on stack, but it can save a few cycles when the structure is initialized or copied. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/93a051da85a895bc6003aedfb00a13e1c2fc6338.1676370870.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Dhruva Gole authored
Fix the issue where some flash chips like cypress S25HS256T return the value of the same register over and over in DAC mode. For example in the TI K3-AM62x Processors refer [0] Technical Reference Manual there is a layer of digital logic in front of the QSPI/OSPI Drive when used in DAC mode. This is part of the Flash Subsystem (FSS) which provides access to external Flash devices. The FSS0_0_SYSCONFIG Register (Offset = 4h) has a BIT Field for OSPI_32B_DISABLE_MODE which has a Reset value = 0. This means, OSPI 32bit mode enabled by default. Thus, by default controller operates in 32 bit mode causing it to always align all data to 4 bytes from a 4byte aligned address. In some flash chips like cypress for example if we try to read some regs in DAC mode then it keeps sending the value of the first register that was requested and inorder to read the next reg, we have to stop and re-initiate a new transaction. This causes wrong register values to be read than what is desired when registers are read in DAC mode. Hence if the data.nbytes is very less then prefer STIG mode for such small reads. [0] https://www.ti.com/lit/ug/spruiv7a/spruiv7a.pdfSigned-off-by:
Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230125081023.1573712-5-d-gole@ti.comSigned-off-by:
-
Dhruva Gole authored
Setup the Addr bit field while issuing register reads in STIG mode. This is needed for example flashes like cypress define in their transaction table that to read any register there is 1 cmd byte and a few more address bytes trailing the cmd byte. Absence of addr bytes will obviously fail to read correct data from flash register that maybe requested by flash driver because the controller doesn't even specify which address of the flash register the read is being requested from. Signed-off-by:
-
Dhruva Gole authored
Create new flag inorder to avoid playing with use_direct_mode flag currently being used throughout the driver. Disable DAC write if auto polling is disabled or CQSPI_DISABLE_DAC_MODE is set. Signed-off-by:
-
Dhruva Gole authored
If one leaves the CQSPI_REG_CMDCTRL in an unclean state this may cause issues in future command reads. This issue came to light when some flash reads in STIG mode were coming back dirty. Signed-off-by:
-
- 13 Feb, 2023 2 commits
-
-
William Zhang authored
brcm,bcm63xx-hsspi-peripheral-props.yaml is not in use at least for now. Remove it from the maintainer entry. Fixes: 80323599 ("MAINTAINERS: Add entry for Broadcom Broadband SoC HS SPI drivers") Reported-by:
kernel test robot <lkp@intel.com> https://lore.kernel.org/oe-kbuild-all/202302121840.GtduUT37-lkp@intel.com/Signed-off-by:
William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20230212205054.26348-1-william.zhang@broadcom.comSigned-off-by:
-
William Zhang authored
sparse tool report warnings: drivers/spi/spi-bcm63xx-hsspi.c:197:31: sparse: sparse: cast from restricted __be16. The controller requires big endian 16 bit data. Define an intermediate u16 value and use __be16 piointer dereferncing for the data to avoid directly casting to u16 and sparse warning. Fixes: 85a84a61 ("spi: bcm63xx-hsspi: Endianness fix for ARM based SoC") Reported-by:
-
- 10 Feb, 2023 9 commits
-
-
William Zhang authored
The driver and device tree doc were originally authored by Jonas Gorski and it has been updated from Broadcom recently including the dts yaml file and a new driver for the updated controller. Add Jonas Gorski and Broadcom engineers William Zhang and Kursad Oney as the maintainers. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230209200246.141520-16-william.zhang@broadcom.comSigned-off-by:
-
William Zhang authored
The newer BCMBCA SoCs such as BCM6756, BCM4912 and BCM6855 include an updated SPI controller that add the capability to allow the driver to control chip select explicitly. Driver can control and keep cs low between the transfers natively. Hence the dummy cs workaround or prepend mode found in the bcm63xx-hsspi driver are no longer needed and this new driver is much cleaner. Signed-off-by:
-
William Zhang authored
In general the controller supports SPI dual mode operation but the particular SPI flash dual io read op switches from single mode in cmd phase to dual mode in address and data phase. This is not compatible with prepend operation where cmd and address are sent out through the prepend buffer and they must use same the number of io pins. This patch disables these SPI flash dual io read ops through the mem_ops supports_op interface. This makes sure the SPI flash driver selects the compatible read ops at run time. Signed-off-by:
-
William Zhang authored
Currently exec_op is always required if controller driver provides mem_ops. But some controller such as bcm63xx-hsspi may only need to implement other operation like supports_op and use the default execution operation. This patch removes this restriction. Signed-off-by:
-
William Zhang authored
Due to the controller limitation to keep the chip select low during the bus idle time between the transfer, a dummy cs workaround was used when this driver was first upstreamed to the kernel. It basically picks the dummy cs as !actual_cs so typically dummy cs is 1 when most of the case only cs 0 is used in the board design. Then invert the polarity of both cs and tell the controller to start the transfers using dummy cs. Assuming both cs are active low before the inversion, effectively this keeps dummy cs high and actual cs low during the transfer and workaround the issue. This workaround implies that dummy cs 1 pin has to be set to chip selection function in the pinmux when the transfer clock is above 25MHz. The old chips likely have default pinmux set to chip select on the dummy cs pin so it works but this is not case for the new Broadband BCA chips and this workaround stop working. This is specifically an issue to support SPI NAND and SPI NOR flash because these flash devices can typically run at or above 100MHz. This patch utilizes the prepend feature of the controller to combine the multiple transfers in the same message to a single transfer when possible. This way there is no need to keep clock low between transfers and solve the issue without any hardware requirement. Multiple transfers within a SPI message may be combined into one transfer if the following are all true: * One or more half duplex write transfer in single bit mode * Optional full duplex read/write at the end * No delay and cs_change between transfers Most of the SPI device meets this requirements such as SPI NOR, SPI NAND flash, Broadcom SPI voice card and etc. For any SPI message that does not meet the above requirement to combine the transfers, we switch to original dummy cs mode but limit the clock rate to the safe 25MHz. This is the default auto transfer mode and it makes sure all the SPI message can be supported automatically under the hood. This patch also adds the driver sysfs node xfer_mode to provide the option for overriding the default auto mode and force it to dummy cs or prepend mode. Signed-off-by:
-
William Zhang authored
Currently the driver always sets the controller to dual data bit mode for both tx and rx data in the profile mode control register even for single data bit transfer. Luckily the opcode is set correctly according to SPI transfer data bit width so it does not actually cause issues. This change fixes the problem by setting tx and rx data bit mode field correctly according to the actual SPI transfer tx and rx data bit width. Fixes: 142168eb ("spi: bcm63xx-hsspi: add bcm63xx HSSPI driver") Signed-off-by:
-
William Zhang authored
The kernel SPI interface includes the cs_change flag that alters how the CS behaves. If we're in the middle of transfers, it tells us to unselect the CS momentarily since the target device requires that. If we're at the end of a transfer, it tells us to keep the CS selected, perhaps because the next transfer is likely targeted to the same device. We implement this scheme in the HSSPI driver in this change. Prior to this change, the CS would toggle momentarily if cs_change was set for the last transfer. This can be ignored by some or most devices, but the Microchip TPM2 device does not ignore it. With the change, the behavior is corrected and the 'glitch' is eliminated. Signed-off-by:
Kursad Oney <kursad.oney@broadcom.com> Signed-off-by:
-
William Zhang authored
For SPI controller that implements transfer_one_message, it needs to insert the delay that required by cs change event between the transfers. Add a wrapper for the local function _spi_transfer_cs_change_delay_exec and export it for SPI controller driver to use. Signed-off-by:
-
Mauro Lima authored
Modern intel hardware uses controllers that work in hardware sequencing mode. In this mode, the controller exposes a subset of operations, like read, write and erase, making it easier and less error-prone for use. On the other hand, most of the controllers handled by the platform driver use software sequencing that exposes the entire set of operations i.e. exposes the low level SPI-NOR opcodes to the software for use. Update PCI and Platform help text with this information. Signed-off-by:
Mauro Lima <mauro.lima@eclypsium.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20230210164158.211065-1-mauro.lima@eclypsium.comSigned-off-by:
-
- 09 Feb, 2023 11 commits
-
-
Mark Brown authored
Merge series from Xiangsheng Hou <xiangsheng.hou@mediatek.com>: This patch series split from bellow series which pick-up spi relevant patches https://lore.kernel.org/all/20230130030656.12127-1-xiangsheng.hou@mediatek.com. This series add MediaTek MT7986 SPI NAND controller support, add read latch latency, smaple delay adjust and add optional nfi_hclk.
-
Xiangsheng Hou authored
Add mediatek,rx-latch-latency-ns property which adjust data read latch latency in the unit of nanoseconds. Signed-off-by:
Xiangsheng Hou <xiangsheng.hou@mediatek.com> Acked-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230201020921.26712-6-xiangsheng.hou@mediatek.comSigned-off-by:
-
Xiangsheng Hou authored
Add dt-bindings documentation of SPI NAND controller for MediaTek MT7986 SoC platform. And add optional nfi_hclk property which is needed for MT7986. Signed-off-by:
-
Xiangsheng Hou authored
Add snfi sample delay and read latency adjustment which can get from dts property. Signed-off-by:
-
Xiangsheng Hou authored
Add optional nfi_hclk which is needed for MT7986. Signed-off-by:
-
Xiangsheng Hou authored
Change default page format to setup default setting since the sector size 1024 on MT7986 will lead to probe fail. Signed-off-by:
-
William Zhang authored
Polling mode provides better throughput in general by avoiding the interrupt overhead as the maximum data size one interrupt can handle is only 512 bytes. So switch to polling mode as the default mode but add a driver sysfs option wait_mode to allow user manually changing the mode at run time between interrupt and polling. Also add driver banner message when the driver is loaded successfully. When test on a Broadcom BCM47622(ARM A7 dual core) reference board with WINBOND W25N01GV SPI NAND chip at 100MHz SPI clock using the MTD speed test suite, it shows about 15% improvement on the write and 30% on the read: ** Interrupt mode ** mtd_speedtest: MTD device: 0 count: 16 mtd_speedtest: MTD device size 134217728, eraseblock size 131072, page size 2048, count of eraseblocks 1024, pages per eraseblock 64, OOB size 64 mtd_test: scanning for bad eraseblocks mtd_test: scanned 16 eraseblocks, 0 are bad mtd_speedtest: testing eraseblock write speed mtd_speedtest: eraseblock write speed is 3072 KiB/s mtd_speedtest: testing eraseblock read speed mtd_speedtest: eraseblock read speed is 6690 KiB/s mtd_speedtest: testing page write speed mtd_speedtest: page write speed is 3066 KiB/s mtd_speedtest: testing page read speed mtd_speedtest: page read speed is 6762 KiB/s mtd_speedtest: testing 2 page write speed mtd_speedtest: 2 page write speed is 3071 KiB/s mtd_speedtest: testing 2 page read speed mtd_speedtest: 2 page read speed is 6772 KiB/s ** Polling mode ** mtd_speedtest: MTD device: 0 count: 16 mtd_speedtest: MTD device size 134217728, eraseblock size 131072, page size 2048, count of eraseblocks 1024, pages per eraseblock 64, OOB size 64 mtd_test: scanning for bad eraseblocks mtd_test: scanned 16 eraseblocks, 0 are bad mtd_speedtest: testing eraseblock write speed mtd_speedtest: eraseblock write speed is 3542 KiB/s mtd_speedtest: testing eraseblock read speed mtd_speedtest: eraseblock read speed is 8825 KiB/s mtd_speedtest: testing page write speed mtd_speedtest: page write speed is 3563 KiB/s mtd_speedtest: testing page read speed mtd_speedtest: page read speed is 8787 KiB/s mtd_speedtest: testing 2 page write speed mtd_speedtest: 2 page write speed is 3572 KiB/s mtd_speedtest: testing 2 page read speed mtd_speedtest: 2 page read speed is 8806 KiB/s Signed-off-by:
-
William Zhang authored
HSSPI controller uses big endian for the opcode in the message to the controller ping pong buffer. Use cpu_to_be16 to properly handle the endianness for both big and little endian host. Fixes: 142168eb ("spi: bcm63xx-hsspi: add bcm63xx HSSPI driver") Signed-off-by:
-
William Zhang authored
New compatible string brcm,bcmbca-hsspi-v1.0 is introduced based on dts document brcm,bcm63xx-hsspi.yaml. Add it to the driver to support this new binding. Signed-off-by:
-
William Zhang authored
The new Broadcom Broadband BCMBCA SoCs includes a updated HSSPI controller. Add new compatible strings to differentiate the old and new controller while keeping MIPS based chip with the old compatible. Update property requirements for these two revisions of the controller. Also add myself and Kursad as the maintainers. Signed-off-by:
-
William Zhang authored
This is the preparation for updates on the bcm63xx hsspi driver. Convert the text based bindings to json-schema per new dts requirement. Signed-off-by:
-
- 07 Feb, 2023 1 commit
-
-
Mauro Lima authored
Modern CPUs exposes this controller as PCI device that only uses hardware sequencing capabilities which is safer than software sequencing. Leave the platform driver as *DANGEROUS* and update help text since most of these controllers are using software sequencing. Signed-off-by:
-
- 06 Feb, 2023 2 commits
-
-
Dan Carpenter authored
This unlocks twice due to a merge issue. Fixes: 35bba23e ("Merge remote-tracking branch 'spi/for-6.2' into spi-6.2") Signed-off-by:
Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/Y+ETCk7XKfAy8yWQ@kiliSigned-off-by:
-
Mark Brown authored
The automated merge for the spidev locking fixes is going wrong and merging the unlock twice.
-
- 02 Feb, 2023 2 commits
-
-
Mauro Lima authored
Add Device IDs to the module table for the following controllers: - 9da4 Cannon Lake 300 Series On-Package - a2a4 200 Series/Z370 Chipset Family SPI Controller - 9d24 Intel
® 200 Series Chipset Family (Including Intel® X299), Intel® Z370 Intel® H310C,B365, also Intel® B460 and H410 Chipset Platform Controller Hub Signed-off-by: -
Mauro Lima authored
Some private data fields have to change from bxt_info to cnl_info. Here is the list of Device IDs with the respective documentation taken for validation: 0xa0a4 - Intel® 500 Series Chipset Family On-Package PCH 0x02a4 - Intel® 400 Series Chipset Family On-Package PCH 0x06a4 - Intel® 400 Series Chipset Family Platform Controller Hub 0x34a4 - Intel® 495 Chipset Family On-Package 0xa3a4 - Intel® B460 and H410 Chipset According to documentation Broxton controller type has five PR registers. Signed-off-by:
-
- 01 Feb, 2023 2 commits
-
-
Mark Brown authored
Merge series from Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>: In preparation for supporting devices with multiple chip selects add an interface for accessing the chip selects via a function.
-
Amit Kumar Mahapatra authored
Supporting multi-cs in spi core and spi controller drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select & spi->cs_gpiod and replaced all spi->chip_select and spi->cs_gpiod references in spi core with the API calls. While adding multi-cs support in further patches the chip_select & cs_gpiod members of the spi_device structure would be converted to arrays & the "idx" parameter of the APIs would be used as array index i.e., spi->chip_select[idx] & spi->cs_gpiod[idx] respectively. Suggested-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Reviewed-by:
Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20230119185342.2093323-2-amit.kumar-mahapatra@amd.comSigned-off-by:
-
- 30 Jan, 2023 2 commits
-
-
Arnd Bergmann authored
Selecting a symbol with additional dependencies requires adding the same dependency here: WARNING: unmet direct dependencies detected for MUX_MMIO Depends on [n]: MULTIPLEXER [=y] && OF [=n] Selected by [y]: - SPI_DW_BT1 [=y] && SPI [=y] && SPI_MASTER [=y] && SPI_DESIGNWARE [=y] && (MIPS_BAIKAL_T1 || COMPILE_TEST [=y]) Drop the 'select' here to avoid the problem. Anyone using the dw-bt1 SPI driver should make sure they include the mux driver as well now. Fixes: 72188381 ("spi: dw-bt1: Fix undefined devm_mux_control_get symbol") Fixes: abf00907 ("spi: dw: Add Baikal-T1 SPI Controller glue driver") Link: https://lore.kernel.org/all/20221218192523.c6vnfo26ua6xqf26@mobilestation/Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20230130140156.3620863-1-arnd@kernel.orgSigned-off-by:
-
Mark Brown authored
-
- 27 Jan, 2023 1 commit
-
-
Bartosz Golaszewski authored
When calling spidev_message() from the one of the ioctl() callbacks, the spi_lock is already taken. When we then end up calling spidev_sync(), we get the following splat: [ 214.047619] [ 214.049198] ============================================ [ 214.054533] WARNING: possible recursive locking detected [ 214.059858] 6.2.0-rc3-0.0.0-devel+git.97ec4d55 #1 Not tainted [ 214.065969] -------------------------------------------- [ 214.071290] spidev_test/1454 is trying to acquire lock: [ 214.076530] c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x8e0/0xab8 [ 214.084164] [ 214.084164] but task is already holding lock: [ 214.090007] c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x44/0xab8 [ 214.097537] [ 214.097537] other info that might help us debug this: [ 214.104075] Possible unsafe locking scenario: [ 214.104075] [ 214.110004] CPU0 [ 214.112461] ---- [ 214.114916] lock(&spidev->spi_lock); [ 214.118687] lock(&spidev->spi_lock); [ 214.122457] [ 214.122457] *** DEADLOCK *** [ 214.122457] [ 214.128386] May be due to missing lock nesting notation [ 214.128386] [ 214.135183] 2 locks held by spidev_test/1454: [ 214.139553] #0: c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x44/0xab8 [ 214.147524] #1: c4925e14 (&spidev->buf_lock){+.+.}-{3:3}, at: spidev_ioctl+0x70/0xab8 [ 214.155493] [ 214.155493] stack backtrace: [ 214.159861] CPU: 0 PID: 1454 Comm: spidev_test Not tainted 6.2.0-rc3-0.0.0-devel+git.97ec4d55 #1 [ 214.169012] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 214.175555] unwind_backtrace from show_stack+0x10/0x14 [ 214.180819] show_stack from dump_stack_lvl+0x60/0x90 [ 214.185900] dump_stack_lvl from __lock_acquire+0x874/0x2858 [ 214.191584] __lock_acquire from lock_acquire+0xfc/0x378 [ 214.196918] lock_acquire from __mutex_lock+0x9c/0x8a8 [ 214.202083] __mutex_lock from mutex_lock_nested+0x1c/0x24 [ 214.207597] mutex_lock_nested from spidev_ioctl+0x8e0/0xab8 [ 214.213284] spidev_ioctl from sys_ioctl+0x4d0/0xe2c [ 214.218277] sys_ioctl from ret_fast_syscall+0x0/0x1c [ 214.223351] Exception stack(0xe75cdfa8 to 0xe75cdff0) [ 214.228422] dfa0: 00000000 00001000 00000003 40206b00 bee266e8 bee266e0 [ 214.236617] dfc0: 00000000 00001000 006a71a0 00000036 004c0040 004bfd18 00000000 00000003 [ 214.244809] dfe0: 00000036 bee266c8 b6f16dc5 b6e8e5f6 Fix it by introducing an unlocked variant of spidev_sync() and calling it from spidev_message() while other users who don't check the spidev->spi's existence keep on using the locking flavor. Reported-by:
Francesco Dolcini <francesco@dolcini.it> Fixes: 1f4d2dd4 ("spi: spidev: fix a race condition when accessing spidev->spi") Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Tested-by:
Max Krummenacher <max.krummenacher@toradex.com> Link: https://lore.kernel.org/r/20230116144149.305560-1-brgl@bgdev.plSigned-off-by:
-
