- 18 11月, 2022 1 次提交
-
-
由 Tudor Ambarus 提交于
SPI NOR flashes have specific cs-setup time requirements without which they can't work at frequencies close to their maximum supported frequency, as they miss the first bits of the instruction command. Unrecognized commands are ignored, thus the flash will be unresponsive. Introduce the spi-cs-setup-ns property to allow spi devices to specify their cs setup time. Signed-off-by: NTudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20221117105249.115649-3-tudor.ambarus@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 02 11月, 2022 1 次提交
-
-
由 Yang Yingliang 提交于
For using modern names host/target to instead of all the legacy names, I think it takes 3 steps: - step1: introduce new helpers with modern naming. - step2: switch to use these new helpers in all drivers. - step3: remove all legacy helpers and update all legacy names. This patch is for step1, it introduces new helpers with host/target naming for drivers using. Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221011092204.950288-1-yangyingliang@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 26 10月, 2022 1 次提交
-
-
由 Thomas Gleixner 提交于
Now that the 32bit UP oddity is gone and 32bit uses always a sequence count, there is no need for the fetch_irq() variants anymore. Convert to the regular interface. Cc: Mark Brown <broonie@kernel.org> Cc: linux-spi@vger.kernel.org Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20221026122951.331638-1-bigeasy@linutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 21 10月, 2022 1 次提交
-
-
由 Andy Shevchenko 提交于
The proposed spi_get_device_match_data() helper is for retrieving a driver data associated with the ID in an ID table. First, it tries to get driver data of the device enumerated by firmware interface (usually Device Tree or ACPI). If none is found it falls back to the SPI ID table matching. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221020195421.10482-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 30 9月, 2022 1 次提交
-
-
由 Marek Szyprowski 提交于
SPI code checks for non-zero sgt->orig_nents to determine if the buffer has been DMA-mapped. Ensure that sg_table is really zeroed after free to avoid potential NULL pointer dereference if the given SPI xfer object is reused again without being DMA-mapped. Fixes: 0c17ba73 ("spi: Fix cache corruption due to DMA/PIO overlap") Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20220930113408.19720-1-m.szyprowski@samsung.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 28 9月, 2022 3 次提交
-
-
由 Vincent Whitchurch 提交于
A couple of drivers call spi_split_transfers_maxsize() from their ->prepare_message() callbacks to split transfers which are too big for them to handle. Add support in the core to do this based on ->max_transfer_size() to avoid code duplication. Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20220927112117.77599-4-vincent.whitchurch@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Vincent Whitchurch 提交于
The SPI core DMA mapping support performs cache management once for the entire message and not between transfers, and this leads to cache corruption if a message has two or more RX transfers with both transfers targeting the same cache line, and the controller driver decides to handle one using DMA and the other using PIO (for example, because one is much larger than the other). Fix it by syncing before/after the actual transfers. This also means that we can skip the sync during the map/unmap of the message. Fixes: 99adef31 ("spi: Provide core support for DMA mapping transfers") Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20220927112117.77599-3-vincent.whitchurch@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Vincent Whitchurch 提交于
Save the current RX and TX DMA devices to avoid having to duplicate the logic to pick them, since we'll need access to them in some more functions to fix a bug in the cache handling. Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20220927112117.77599-2-vincent.whitchurch@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 07 9月, 2022 1 次提交
-
-
由 Christophe Leroy 提交于
Some components require a few clock cycles with chipselect off before or/and after the data transfer done with CS on. Typically IDT 801034 QUAD PCM CODEC datasheet states "Note *: CCLK should have one cycle before CS goes low, and two cycles after CS goes high". The cycles "before" are implicitely provided by all previous activity on the SPI bus. But the cycles "after" must be provided in order to terminate the SPI transfer. In order to use that kind of component, add a cs_off flag to spi_transfer struct. When this flag is set, the transfer is performed with chipselect off. This allows consummer to add a dummy transfer at the end of the transfer list which is performed with chipselect OFF, providing the required additional clock cycles. Signed-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/434165c46f06d802690208a11e7ea2500e8da4c7.1662558898.git.christophe.leroy@csgroup.euSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 02 9月, 2022 2 次提交
-
-
由 David Jander 提交于
The queue worker always needs to be kicked one final time after a transfer is done in order to transition to idle (ctlr->busy = false). Commit 69fa9590 ("spi: Ensure the io_mutex is held until spi_finalize_current_message()") moved this code into __spi_pump_messages(), but it was executed only if the transfer was successful. This condition check causes ctlr-busy to stay true in case of a failed transfer. This in turn causes that no new work is ever scheduled to the work queue. Fixes: 69fa9590 ("spi: Ensure the io_mutex is held until spi_finalize_current_message()") Reported-by: NVincent Whitchurch <vincent.whitchurch@axis.com> Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220901123630.1098433-1-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Mark Brown 提交于
The spi-mux driver is rather too clever and attempts to resubmit any message that is submitted to it to the parent controller with some adjusted callbacks. This does not play at all nicely with the fast path which now sets flags on the message indicating that it's being handled through the fast path, we see async messages flagged as being on the fast path. Ideally the spi-mux code would duplicate the message but that's rather invasive and a bit fragile in that it relies on the mux knowing which fields in the message to copy. Instead teach the core that there are controllers which can't cope with the fast path and have the mux flag itself as being such a controller, ensuring that messages going via the mux don't get partially handled via the fast path. This will reduce the performance of any spi-mux connected device since we'll now always use the thread for both the actual controller and the mux controller instead of just the actual controller but given that we were always hitting the slow path anyway it's hopefully not too much of an additional cost and it allows us to keep the fast path. Fixes: ae7d2346 ("spi: Don't use the message queue if possible in spi_sync") Reported-by: NCasper Andersson <casper.casan@gmail.com> Tested-by: NCasper Andersson <casper.casan@gmail.com> Signed-off-by: NMark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220901120732.49245-1-broonie@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 25 8月, 2022 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The parent field in struct acpi_device is, in fact, redundant, because the dev.parent field in it effectively points to the same object and it is used by the driver core. Accordingly, the parent field can be dropped from struct acpi_device and for this purpose define acpi_dev_parent() to retrieve a parent struct acpi_device pointer from the dev.parent field in struct acpi_device. Next, update all of the users of the parent field in struct acpi_device to use acpi_dev_parent() instead of it and drop it. While at it, drop the ACPI_IS_ROOT_DEVICE() macro that is only used in one place in a confusing way. No intentional functional impact. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NMark Brown <broonie@kernel.org> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NWei Liu <wei.liu@kernel.org> Reviewed-by: NPunit Agrawal <punit.agrawal@bytedance.com>
-
- 19 8月, 2022 1 次提交
-
-
由 Wolfram Sang 提交于
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20220818210107.7373-1-wsa+renesas@sang-engineering.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 05 8月, 2022 1 次提交
-
-
由 David Jander 提交于
Fixes sparse warnings of this kind: drivers/spi/spi.c:117:16: sparse: expected struct spi_statistics * drivers/spi/spi.c:117:16: sparse: got struct spi_statistics [noderef] __percpu *[assigned] pcpu_stats Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220805084458.1602277-1-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 13 7月, 2022 1 次提交
-
-
由 Yang Yingliang 提交于
This reverts commit 59ebbe40 ("spi: simplify devm_spi_register_controller"). If devm_add_action() fails in devm_add_action_or_reset(), devm_spi_unregister() will be called, it decreases the refcount of 'ctlr->dev' to 0, then it will cause uaf in the drivers that calling spi_put_controller() in error path. Fixes: 59ebbe40 ("spi: simplify devm_spi_register_controller") Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NConor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20220712135504.1055688-1-yangyingliang@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 11 7月, 2022 3 次提交
-
-
由 Andy Shevchenko 提交于
The acpi_spi_add_resource() is never called with ctrl == NULL and index == -1. The only caller already performs the check. Hence remove the duplication from the acpi_spi_add_resource(). Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220709000709.35622-2-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Andy Shevchenko 提交于
Since acpi_spi_device_alloc() has been designed to return an error pointer we may now properly propagate error codes to the caller of it. It helps debugging a lot. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220709000709.35622-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Andy Shevchenko 提交于
If the controller is not available, it might be in the future and we would like to re-probe the peripheral again. For that purpose return deferred probe. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215993 Fixes: 87e59b36 ("spi: Support selection of the index of the ACPI Spi Resource before alloc") Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220709212956.25530-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 30 6月, 2022 3 次提交
-
-
由 David Jander 提交于
Reported-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220629142519.3985486-4-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
Capitalize first word in comment where appropriate and add parentheses to function names. Reported-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220629142519.3985486-3-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
Reported-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220629142519.3985486-2-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 27 6月, 2022 11 次提交
-
-
由 David Jander 提交于
There are only a few drivers that do not call spi_finalize_current_message() in the context of transfer_one_message(), and even for those cases the completion ctlr->cur_msg_completion is not needed always. The calls to complete() and wait_for_completion() each take a spin-lock, which is costly. This patch makes it possible to avoid those calls in the big majority of cases, by introducing two flags that with the help of ordering via barriers can avoid using the completion safely. In case of a race with the context calling spi_finalize_current_message(), the scheme errs on the safe side and takes the completion. The impact of this patch is worth the effort: On a i.MX8MM SoC, the time the SPI bus is idle between two consecutive calls to spi_sync(), is reduced from 19.6us to 16.8us... roughly 15%. Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-12-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
This patch introduces a completion that is completed in spi_finalize_current_message() and waited for in __spi_pump_transfer_message(). This way all manipulation of ctlr->cur_msg is done with the io_mutex held and strictly ordered: __spi_pump_transfer_message() will not return until spi_finalize_current_message() is done using ctlr->cur_msg, and its calling context is only touching ctlr->cur_msg after returning. Due to this, we can safely drop the spin-locks around ctlr->cur_msg. Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-11-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
Some drivers rely on this to point to the currently processed message, so set this here also. Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-10-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
Now this flag is written entirely in the mutex, so no need for READ_ONCE Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-9-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
The ctlr->idling flag is never checked now, so we don't need to set it either. Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-8-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
Since the whole idling transition is locked by the io_mutex now, there is no need to check this flag anymore. Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-7-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
Now that the idling flag is wholly behind the io_mutex, this broken piece of code can be safely removed. Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-6-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-5-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
This way, the spi sync path does not need to deal with the idling transition. Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-4-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
The interaction with the controller message queue and its corresponding auxiliary flags and variables requires the use of the queue_lock which is costly. Since spi_sync will transfer the complete message anyway, and not return until it is finished, there is no need to put the message into the queue if the queue is empty. This can save a lot of overhead. As an example of how significant this is, when using the MCP2518FD SPI CAN controller on a i.MX8MM SoC, the time during which the interrupt line stays active (during 3 relatively short spi_sync messages), is reduced from 98us to 72us by this patch. Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-3-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 David Jander 提交于
This enables the possibility to transfer a message that is not at the current tip of the async message queue. This is in preparation of the next patch(es) which enable spi_sync messages to skip the queue altogether. Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220621061234.3626638-2-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 14 6月, 2022 1 次提交
-
-
由 Dan Carpenter 提交于
Return -ENOMEM if the allocation fails. Don't return success. Fixes: 6598b91b ("spi: spi.c: Convert statistics to per-cpu u64_stats_t") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/Yqh6bdNYO2XNhPBa@kiliSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 10 6月, 2022 2 次提交
-
-
由 Andy Shevchenko 提交于
We have already a helper to get the first child device, use it and drop custom approach. Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NMark Brown <broonie@kernel.org> Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220610120219.18988-2-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 David Jander 提交于
On 32 bit systems, the following kernel BUG is hit: BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 caller is debug_smp_processor_id+0x18/0x24 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc1-00001-g6ae0aec8a366 #181 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: dump_backtrace from show_stack+0x20/0x24 r7:81024ffd r6:00000000 r5:81024ffd r4:60000013 show_stack from dump_stack_lvl+0x60/0x78 dump_stack_lvl from dump_stack+0x14/0x1c r7:81024ffd r6:80f652de r5:80bec180 r4:819a2500 dump_stack from check_preemption_disabled+0xc8/0xf0 check_preemption_disabled from debug_smp_processor_id+0x18/0x24 r8:8119b7e0 r7:81205534 r6:819f5c00 r5:819f4c00 r4:c083d724 debug_smp_processor_id from __spi_sync+0x78/0x220 __spi_sync from spi_sync+0x34/0x4c r10:bb7bf4e0 r9:c083d724 r8:00000007 r7:81a068c0 r6:822a83c0 r5:c083d724 r4:819f4c00 spi_sync from spi_mem_exec_op+0x338/0x370 r5:000000b4 r4:c083d910 spi_mem_exec_op from spi_nor_read_id+0x98/0xdc r10:bb7bf4e0 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:82358040 r4:819f7c40 spi_nor_read_id from spi_nor_detect+0x38/0x114 r7:82358040 r6:00000000 r5:819f7c40 r4:819f7c40 spi_nor_detect from spi_nor_scan+0x11c/0xbec r10:bb7bf4e0 r9:00000000 r8:00000000 r7:c083da4c r6:00000000 r5:00010101 r4:819f7c40 spi_nor_scan from spi_nor_probe+0x10c/0x2d0 r10:bb7bf4e0 r9:bb7bf4d0 r8:00000000 r7:819f4c00 r6:00000000 r5:00000000 r4:819f7c40 per-cpu access needs to be guarded against preemption. Fixes: 6598b91b ("spi: spi.c: Convert statistics to per-cpu u64_stats_t") Reported-by: NMarc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: NDavid Jander <david@protonic.nl> Tested-by: NNícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20220609121334.2984808-1-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 06 6月, 2022 1 次提交
-
-
由 David Jander 提交于
This change gives a dramatic performance improvement in the hot path, since many costly spin_lock_irqsave() calls can be avoided. On an i.MX8MM system with a MCP2518FD CAN controller connected via SPI, the time the driver takes to handle interrupts, or in other words the time the IRQ line of the CAN controller stays low is mainly dominated by the time it takes to do 3 relatively short sync SPI transfers. The effect of this patch is a reduction of this time from 136us down to only 98us. Suggested-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220524091808.2269898-1-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 26 5月, 2022 1 次提交
-
-
由 Eddie James 提交于
All the other calls to the controller driver display the error return code. The return code is helpful to understand what went wrong, so include it when failing to transfer one message. Signed-off-by: NEddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20220525165852.33167-3-eajames@linux.ibm.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 22 4月, 2022 1 次提交
-
-
由 Krzysztof Kozlowski 提交于
Use a helper to set driver_override to the reduce amount of duplicated code. Reviewed-by: NMark Brown <broonie@kernel.org> Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220419113435.246203-8-krzysztof.kozlowski@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 4月, 2022 1 次提交
-
-
由 Minghao Chi 提交于
Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by: NZeal Robot <zealci@zte.com.cn> Signed-off-by: NMinghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220418110226.2559081-1-chi.minghao@zte.com.cnSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 14 4月, 2022 1 次提交
-
-
由 Paul Kocialkowski 提交于
The previous commit that made bits-per-word validation conditional results in leaving no unconditional affectation of the status variable. Since the variable is returned at the end of the function, initialize it to avoid returning an undefined value. Signed-off-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com> Fixes: b3fe2e51 ("spi: core: Only check bits_per_word validity when explicitly provided") Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220414084040.975520-1-paul.kocialkowski@bootlin.comSigned-off-by: NMark Brown <broonie@kernel.org>
-