Mixing SPI slave/target handlers and SPI slave/target controllers using
legacy and modern naming does not work well: there are now two different
callbacks for aborting a slave/target operation, of which only one is
populated, while spi_{slave,target}_abort() check and use only one,
which may be the unpopulated one.

Fix this by merging the slave/target abort callbacks into a single
callback using a union, like is already done for the slave/target flags.

Fixes: b8d3b056 ("spi: introduce new helpers with using modern naming")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/809c82d54b85dd87ef7ee69fc93016085be85cec.1667555967.git.geert+renesas@glider.beSigned-off-by: NMark Brown <broonie@kernel.org>

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>

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>

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>

The commit 5e0531f6 ("spi: Add capability to perform some transfer
with chipselect off") added a new flag but squeezed it into a wrong
group of struct spi_transfer members (note that SPI_NBITS_* are macros
for easier interpretation of the tx_nbits and rx_nbits bitfields).

Group cs_change and cs_off flags together and their doc strings.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220908130518.32186-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

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>

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>

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>

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>

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>

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>

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>

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>

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>

Fixes these "make htmldocs" warnings:

include/linux/spi/spi.h:82: warning: Function parameter or member 'syncp' not described in 'spi_statistics'
include/linux/spi/spi.h:213: warning: Function parameter or member 'pcpu_statistics' not described in 'spi_device'
include/linux/spi/spi.h:676: warning: Function parameter or member 'pcpu_statistics' not described in 'spi_controller'

Fixes: 6598b91b ("spi: spi.c: Convert statistics to per-cpu u64_stats_t")
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NDavid Jander <david@protonic.nl>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220608153309.2899565-1-david@protonic.nlSigned-off-by: NMark Brown <broonie@kernel.org>

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>

Spelling mistake (triple letters) in comment.
Detected with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@inria.fr>
Link: https://lore.kernel.org/r/20220521111145.81697-13-Julia.Lawall@inria.frSigned-off-by: NMark Brown <broonie@kernel.org>

This fixes the corresponding warnings during building the docs.
Signed-off-by: NSiddh Raman Pant <siddhpant.gh@gmail.com>
Link: https://lore.kernel.org/r/4e6187a4-d0f8-4750-e407-e09cc1c91789@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

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>

Commit d40f0b6f instroduced last_cs_enable to avoid setting
chipselect if it's not necessary, but it also introduces a bug. The
chipselect may not be set correctly on multi-device SPI busses. The
reason is that we can't judge the chipselect by bool last_cs_enable,
since chipselect may be modified after other devices were accessed.

So we should record the specific state of chipselect in case of
confusion.
Signed-off-by: NYun Zhou <yun.zhou@windriver.com>
Link: https://lore.kernel.org/r/20220217141234.72737-1-yun.zhou@windriver.comSigned-off-by: NMark Brown <broonie@kernel.org>

All drivers using GPIOs as chip select have been rewritten to use
GPIO descriptors passing the ->use_gpio_descriptors flag. Retire
the code and fields used by the legacy GPIO API.

Do not drop the ->use_gpio_descriptors flag: it now only indicates
that we want to use GPIOs in addition to native chip selects.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220210231954.807904-1-linus.walleij@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Create a spi_controller_mem_caps structure and put it within the
spi_controller structure close to the spi_controller_mem_ops
strucure. So far the only field in this structure is the support for dtr
operations, but soon we will add another parameter.

Also create a helper to parse the capabilities and check if the
requested capability has been set or not.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NPratyush Yadav <p.yadav@ti.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NTudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: NMark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/linux-mtd/20220127091808.1043392-2-miquel.raynal@bootlin.com

The value returned by an spi driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)

So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accordingly.
There is no intended change of behaviour, all callbacks were prepared to
return 0 before.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NJérôme Pouiller <jerome.pouiller@silabs.com>
Acked-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: NClaudius Heine <ch@denx.de>
Acked-by: NStefan Schmidt <stefan@datenfreihafen.org>
Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Acked-by: NMarcus Folkesson <marcus.folkesson@gmail.com>
Acked-by: NŁukasz Stelmach <l.stelmach@samsung.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20220123175201.34839-6-u.kleine-koenig@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

Some ACPI nodes may have more than one Spi Resource.
To be able to handle these case, its necessary to have
a way of counting these resources.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-5-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

If a node contains more than one SPI resource it may be necessary to
use an index to select which one you want to allocate a spi device for.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-4-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

This can then be used to find a spi resource inside an
ACPI node, and allocate a spi device.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-3-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

This functions were previously made private since they
were not used. However, these functions will be needed
again.

Partial revert of commit da21fde0
("spi: Make several public functions private to spi.c")
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-2-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some ACPI nodes may have more than one Spi Resource.
To be able to handle these case, its necessary to have
a way of counting these resources.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-5-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

If a node contains more than one SPI resource it may be necessary to
use an index to select which one you want to allocate a spi device for.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-4-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

This can then be used to find a spi resource inside an
ACPI node, and allocate a spi device.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-3-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

This functions were previously made private since they
were not used. However, these functions will be needed
again.

Partial revert of commit da21fde0
("spi: Make several public functions private to spi.c")
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-2-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

Commit b42faeee ("spi: Add a PTP system timestamp
to the transfer structure") added an include of ptp_clock_kernel.h
to spi.h for struct ptp_system_timestamp but a forward declaration
is enough. Let's use that to limit the number of objects we have
to rebuild every time we touch networking headers.
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Tested-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210904013140.2377609-1-kuba@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Currently we have a global spi_add_lock which we take when adding new
devices so that we can check that we're not trying to reuse a chip
select that's already controlled.  This means that if the SPI device is
itself a SPI controller and triggers the instantiation of further SPI
devices we trigger a deadlock as we try to register and instantiate
those devices while in the process of doing so for the parent controller
and hence already holding the global spi_add_lock.  Since we only care
about concurrency within a single SPI bus move the lock to be per
controller, avoiding the deadlock.

This can be easily triggered in the case of spi-mux.
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

All these functions have no callers apart from drivers/spi/spi.c. So
drop their declarations in include/linux/spi/spi.h and don't export
them.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211007121415.2401638-5-u.kleine-koenig@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

The last user is gone since commit

	2962db71 ("staging/fbtft: Remove fbtft_device")

in 2019.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211007121415.2401638-3-u.kleine-koenig@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

This patch modified set_cs_timing parameter, no need pass in spi_delay
to set_cs_timing callback.
By the way, we modified the mediatek and tegra114 spi driver to fix build err.
In mediatek spi driver, We have support set absolute time not clk_count,
and call this function in prepare_message not user's API.
Signed-off-by: NMason Zhang <Mason.Zhang@mediatek.com>
Link: https://lore.kernel.org/r/20210804133746.6742-1-Mason.Zhang@mediatek.comSigned-off-by: NMark Brown <broonie@kernel.org>

As we know, spi core layer has removed spi_set_cs_timing() API.
So this patch moved spi_delay for cs_timing from spi_controller
to spi_device, because cs timing should be set by spi_device but
not controller.
Signed-off-by: NMason Zhang <Mason.Zhang@mediatek.com>
Link: https://lore.kernel.org/r/20210804133716.32040-1-Mason.Zhang@mediatek.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix kernel-doc warning in spi.h by adding the missing kernel-doc entry
and also correct the original comment so that they both indicate the
correct polarity of the flag.

../include/linux/spi/spi.h:673: warning: Function parameter or member 'devm_allocated' not described in 'spi_controller'

Fixes: 794aaf01 ("spi: Fix use-after-free with devm_spi_alloc_*")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: William A. Kennington III <wak@google.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Cc: Lukas Wunner <lukas@wunner.de>
Reviewed-by: NLukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/20210628210520.5712-1-rdunlap@infradead.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Some controllers like qcom geni need the parent device to be used for
dma mapping, so add a dma_map_dev field and let drivers fill this to be
used as mapping device
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20210625052213.32260-4-vkoul@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Introduce support for ancillary devices, similar to existing
implementation for I2C. This is useful for devices having
multiple chip-selects, for example some microcontrollers
provide a normal SPI interface and a flashing SPI interface.
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20210621175359.126729-2-sebastian.reichel@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>