Age | Commit message (Collapse) | Author | Files | Lines |
|
[ Upstream commit 3d3e88e336338834086278236d42039f3cde50e1 ]
In sdw_prep_deprep_slave_ports(), after the wait_for_completion()
the DP prepare status register is read. If this indicates that the
port is now prepared, the code should continue with the port setup.
It is irrelevant whether the wait_for_completion() timed out if the
port is now ready.
The previous implementation would always fail if the
wait_for_completion() timed out, even if the port was reporting
successful prepare.
This patch also fixes a minor bug where the return from sdw_read()
was not checked for error - any error code with LSBits clear could
be misinterpreted as a successful port prepare.
Fixes: 79df15b7d37c ("soundwire: Add helpers for ports operations")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210618144745.30629-1-rf@opensource.cirrus.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d6c2ce435ffe23ef7f395ae76ec747414589db46 ]
When an expander does not contain any 'phys', an appropriate error code -1
should be returned, as done elsewhere in this function. However, we
currently do not explicitly assign this error code to 'rc'. As a result, 0
was incorrectly returned.
Link: https://lore.kernel.org/r/20210514081300.6650-1-thunder.leizhen@huawei.com
Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 3002f467a0b0a70aec01d9f446da4ac8c6fda10b ]
If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
call, as already done in the remove function.
Fixes: 2e5eda4681f9 ("habanalabs: PCIe Advanced Error Reporting support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
marvell_nfc_resume()
[ Upstream commit ae94c49527aa9bd3b563349adc4b5617747ca6bd ]
Add clk_disable_unprepare() on error path in marvell_nfc_resume().
Fixes: bd9c3f9b3c00 ("mtd: rawnand: marvell: add suspend and resume hooks")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210601125814.3260364-1-yangyingliang@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2892d8a00d23d511a0591ac4b2ff3f050ae1f004 ]
Variable "size" has type "phys_addr_t", which can be either 32-bit or
64-bit on 32-bit systems, while "unsigned long" is always 32-bit on
32-bit systems. Hence the cast in
(unsigned long)size / SZ_1M
may truncate a 64-bit size to 32-bit, as casts have a higher operator
precedence than divisions.
Fix this by inverting the order of the cast and division, which should
be safe for memory blocks smaller than 4 PiB. Note that the division is
actually a shift, as SZ_1M is a power-of-two constant, hence there is no
need to use div_u64().
While at it, use "%lu" to format "unsigned long".
Fixes: e8d9d1f5485b52ec ("drivers: of: add initialization code for static reserved memory")
Fixes: 3f0c8206644836e4 ("drivers: of: add initialization code for dynamic reserved memory")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/4a1117e72d13d26126f57be034c20dac02f1e915.1623835273.git.geert+renesas@glider.be
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit fac165f22ac947b55407cd3a60a2a9824f905235 ]
The definition of CS42L42_ADC_PDN_MASK was incorrectly defined
as the HP_PDN bit.
Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210616135604.19363-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
iio_push_to_buffers_with_timestamp()
[ Upstream commit 92babc9938ebbf4050f2fba774836f7edc16a570 ]
Add __aligned(8) to ensure the buffer passed to
iio_push_to_buffers_with_timestamp() is suitable for the naturally
aligned timestamp that will be inserted.
Here an explicit structure is not used, because the holes would
necessitate the addition of an explict memset(), to avoid a kernel
data leak, making for a less minimal fix.
Fixes: 1c28799257bc ("iio: light: isl29501: Add support for the ISL29501 ToF sensor.")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Mathieu Othacehe <m.othacehe@gmail.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-9-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
iio_push_to_buffers_with_timestamp()
[ Upstream commit ec90b52c07c0403a6db60d752484ec08d605ead0 ]
Add __aligned(8) to ensure the buffer passed to
iio_push_to_buffers_with_timestamp() is suitable for the naturally
aligned timestamp that will be inserted.
Here an explicit structure is not used, because the holes would
necessitate the addition of an explict memset(), to avoid a potential
kernel data leak, making for a less minimal fix.
Fixes: 55707294c4eb ("iio: light: Add support for vishay vcnl4035")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Parthiban Nallathambi <pn@denx.de>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-8-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 78bcae8616ac277d6cb7f38e211493948ed73e30 ]
Support for magic baud rate divisors of 32770 and 32769 used with SMSC
Super I/O chips for extra baud rates of 230400 and 460800 respectively
where base rate is 115200[1] has been added around Linux 2.5.64, which
predates our repo history, but the origin could be identified as commit
2a717aad772f ("Merge with Linux 2.5.64.") with the old MIPS/Linux repo
also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git>.
Code that is now in `serial8250_do_get_divisor' was added back then to
`serial8250_get_divisor', but that code would only ever trigger if one
of the higher baud rates was actually requested, and that cannot ever
happen, because the earlier call to `serial8250_get_baud_rate' never
returns them. This is because it calls `uart_get_baud_rate' with the
maximum requested being the base rate, that is clk/16 or 115200 for SMSC
chips at their nominal clock rate.
Fix it then and allow UPF_MAGIC_MULTIPLIER baud rates to be selected, by
requesting the maximum baud rate of clk/4 rather than clk/16 if the flag
has been set. Also correct the minimum baud rate, observing that these
ports only support actual (non-magic) divisors of up to 32767 only.
References:
[1] "FDC37M81x, PC98/99 Compliant Enhanced Super I/O Controller with
Keyboard/Mouse Wake-Up", Standard Microsystems Corporation, Rev.
03/27/2000, Table 31 - "Baud Rates", p. 77
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2105190412280.29169@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 7917e90667bc8dce02daa3c2e6df47f6fc9481f7 ]
The B_SESS_VLD_WAKEUP_EN bit 6 was added by a mistake in a previous
commit. This bit corresponds to B_SESS_END_WAKEUP_EN, which we don't use.
The B_VBUS_VLD_WAKEUP_EN doesn't exist at all and B_SESS_VLD_WAKEUP_EN
needs to be in place of it. We don't utilize B-sensors in the driver,
so it never was a problem, nevertheless let's correct the definition of
the bits.
Fixes: 35192007d28d ("usb: phy: tegra: Support waking up from a low power mode")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20210613145936.9902-2-digetx@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6f8d39a8ef55efde414b6e574384acbce70c3119 ]
Some devices need an extra delay after losing VBUS, otherwise VBUS may
be detected as active at suspend time, preventing the PHY's suspension
by the VBUS detection sensor. This problem was found on Asus Transformer
TF700T (Tegra30) tablet device, where the USB PHY wakes up immediately
from suspend because VBUS sensor continues to detect VBUS as active after
disconnection. We need to poll the PHY's VBUS wakeup status until it's
deasserted before suspending PHY in order to fix this minor trouble.
Fixes: 35192007d28d ("usb: phy: tegra: Support waking up from a low power mode")
Reported-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
Reviewed-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20210613145936.9902-1-digetx@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 5b4f167ef3555ec4c334a8dc89c1b44bb2c6bff5 ]
Driver code call 'devm_of_pci_get_host_bridge_resources'
to get resources and properly fill 'bridge->windows' and
'bridge->dma_ranges'. After parsing the ranges and store
as resources, at the end it makes a call to pci function
'pci_add_resource_offset' to set the offset for the
memory resource. To calculate offset, resource start address
subtracts pci address of the range. MT7621 does not need
any offset for the memory resource. Moreover, setting an
offset got into 'WARN_ON' calls from pci devices driver code.
Until now memory range pci_addr was being '0x00000000' and
res->start is '0x60000000' but becase pci controller driver
was manually setting resources and adding them using pci function
'pci_add_resource' where a zero is passed as offset, things
was properly working. Since PCI_IOBASE is defined now for
ralink we don't set nothing manually anymore so we have to
properly fix PCI address for this range to make things work
and the new pci address must be set to '0x60000000'. Doing
in this way the subtract result obtain zero as offset
and pci device driver code properly works.
Fixes: d59578da2bb8 ("staging: mt7621-dts: add dts files")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210614100617.28753-4-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d777a8991847729ec4e2a13fcad58c2b00bb19dc ]
Currently the pointer "sink" might be checked before initialized. Fix
this by initializing this pointer.
Link: https://lore.kernel.org/r/1620912469-52222-2-git-send-email-liuqi115@huawei.com
Fixes: 6d578258b955 ("coresight: Make sysfs functional on topologies with per core sink")
Signed-off-by: Junhao He <hejunhao2@hisilicon.com>
Signed-off-by: Qi Liu <liuqi115@huawei.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20210614175901.532683-3-mathieu.poirier@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e02a3b945816a77702a2769a70ef5f9b06e49d54 ]
There is a leak in rtl8712 driver.
The problem was in non-freed adapter data if
firmware load failed.
This leak can be reproduced with this code:
https://syzkaller.appspot.com/text?tag=ReproC&x=16612f02d00000,
Autoload must fail (to not hit memory leak reported by syzkaller)
There are 2 possible ways how rtl871x_load_fw_cb() and
r871xu_dev_remove() can be called (in case of fw load error).
1st case:
r871xu_dev_remove() then rtl871x_load_fw_cb()
In this case r871xu_dev_remove() will wait for
completion and then will jump to the end, because
rtl871x_load_fw_cb() set intfdata to NULL:
if (pnetdev) {
struct _adapter *padapter = netdev_priv(pnetdev);
/* never exit with a firmware callback pending */
wait_for_completion(&padapter->rtl8712_fw_ready);
pnetdev = usb_get_intfdata(pusb_intf);
usb_set_intfdata(pusb_intf, NULL);
if (!pnetdev)
goto firmware_load_fail;
... clean up code here ...
}
2nd case:
rtl871x_load_fw_cb() then r871xu_dev_remove()
In this case pnetdev (from code snippet above) will
be zero (because rtl871x_load_fw_cb() set it to NULL)
And clean up code won't be executed again.
So, in all cases we need to free adapted data in rtl871x_load_fw_cb(),
because disconnect function cannot take care of it. And there won't be
any race conditions, because complete() call happens after setting
intfdata to NULL.
In previous patch I moved out free_netdev() from r8712_free_drv_sw()
and that's why now it's possible to free adapter data and then call
complete.
Fixes: 8c213fa59199 ("staging: r8712u: Use asynchronous firmware loading")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Link: https://lore.kernel.org/r/81e68fe0194499cc2e7692d35bc4dcf167827d8f.1623620630.git.paskripkin@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d1d3e3cdfda8eb91f0e24be7ec8be1e6e01b3a1c ]
Previous error handling path was unique for all
possible errors and there was unnecessary branching.
Also, one step for freeing drv_sw was missing. All
these problems was fixed by restructuring error
handling path.
Also, moved out free_netdev() from r8712_free_drv_sw() for
correct error handling.
Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Link: https://lore.kernel.org/r/febb00f72354449bb4d305f373d6d2f47e539ab4.1623620630.git.paskripkin@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 7002b526f4ff1f6da34356e67085caafa6be383a ]
This code assumes that "len" is at least 62 bytes, but we need a check
to prevent a read overflow.
Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YMcoTPsCYlhh2TQo@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 4a36e160856db8a8ddd6a3d2e5db5a850ab87f82 ]
There needs to be a check to verify that we don't read beyond the end
of "buf". This function is called from do_rx(). The "buf" is the USB
transfer_buffer and "len" is "urb->actual_length".
Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YMcnl4zCwGWGDVMG@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 28108d71ee11a7232e1102effab3361049dcd3b8 ]
There is error message when defer probe happens:
fsl-spdif-dai 2dab0000.spdif: Unbalanced pm_runtime_enable!
Fix the error handler with pm_runtime_enable and add
fsl_spdif_remove() for pm_runtime_disable.
Fixes: 9cb2b3796e08 ("ASoC: fsl_spdif: Add pm runtime function")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1623392318-26304-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
iio_push_to_buffers_with_timestamp()
[ Upstream commit dce793c0ab00c35039028fdcd5ce123805a01361 ]
Add __aligned(8) to ensure the buffer passed to
iio_push_to_buffers_with_timestamp() is suitable for the naturally
aligned timestamp that will be inserted.
Here an explicit structure is not used, because the holes would
necessitate the addition of an explict memset(), to avoid a kernel
data leak, making for a less minimal fix.
Found during an audit of all callers of iio_push_to_buffers_with_timestamp()
Fixes: 8fe78d5261e7 ("iio: vcnl4000: Add buffer support for VCNL4010/20.")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Mathieu Othacehe <m.othacehe@gmail.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-7-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
iio_push_to_buffers_with_timestamp()
[ Upstream commit b8f939fd20690623cb24845a563e7bc1e4a21482 ]
Add __aligned(8) to ensure the buffer passed to
iio_push_to_buffers_with_timestamp() is suitable for the naturally
aligned timestamp that will be inserted.
Here an explicit structure is not used, because this buffer is used in
a non-trivial way for data repacking.
Fixes: 121354b2eceb ("iio: magnetometer: Add driver support for PNI RM3100")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Song Qiang <songqiang1304521@gmail.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-6-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
iio_push_to_buffers_with_timestamp()
[ Upstream commit 61fa5dfa5f52806f5ce37a0ba5712c271eb22f98 ]
Add __aligned(8) to ensure the buffer passed to
iio_push_to_buffers_with_timestamp() is suitable for the naturally
aligned timestamp that will be inserted.
Fixes: f214ff521fb1 ("iio: ti-ads8688: Update buffer allocation for timestamps")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-5-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
iio_push_to_buffers_with_timestamp()
[ Upstream commit 6a6be221b8bd561b053f0701ec752a5ed9007f69 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Add a comment on why the buffer is the size it is as not immediately
obvious.
Found during an audit of all calls of this function.
Fixes: 6dd112b9f85e ("iio: adc: mxs-lradc: Add support for ADC driver")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Andreas Klinger <ak@it-klinger.de>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-4-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit afe2a789fbf7acd1a05407fc7839cc08d23825e3 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of this function.
Fixes: d3bf60450d47 ("iio: hx711: add triggered buffer support")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Andreas Klinger <ak@it-klinger.de>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-3-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
iio_push_to_buffers_with_timestamp()
[ Upstream commit 8f884758966259fa8c50c137ac6d4ce9bb7859db ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of this function.
Fixes: 5e1a1da0f8c9 ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-2-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 94588c1bf1c8701392e1dc105c670d0d2fc7676a ]
Gcc reports build error when CONFIG_IIO_TRIGGERED_BUFFER is not set:
riscv64-linux-gnu-ld: drivers/iio/dummy/iio_simple_dummy_buffer.o: in function `iio_simple_dummy_configure_buffer':
iio_simple_dummy_buffer.c:(.text+0x2b0): undefined reference to `iio_triggered_buffer_setup_ext'
riscv64-linux-gnu-ld: drivers/iio/dummy/iio_simple_dummy_buffer.o: in function `.L0 ':
iio_simple_dummy_buffer.c:(.text+0x2fc): undefined reference to `iio_triggered_buffer_cleanup'
Fix it by select IIO_TRIGGERED_BUFFER for config IIO_SIMPLE_DUMMY_BUFFER.
Fixes: 738f6ba11800 ("iio: dummy: iio_simple_dummy_buffer: use triggered buffer core calls")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 384426bd101cb3cd580b18de19d4891ec5ca5bf9 ]
When one parameter of a parameterised test failed, its failure would be
propagated to the overall test, but not to the suite result (unless it
was the last parameter).
This is because test_case->success was being reset to the test->success
result after each parameter was used, so a failing test's result would
be overwritten by a non-failing result. The overall test result was
handled in a third variable, test_result, but this was discarded after
the status line was printed.
Instead, just propagate the result after each parameter run.
Signed-off-by: David Gow <davidgow@google.com>
Fixes: fadb08e7c750 ("kunit: Support for Parameterized Testing")
Reviewed-by: Marco Elver <elver@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c93081b265735db2417f0964718516044d06b1a2 ]
In the raw NAND world, ECC engines increment ecc_stats and the final
caller is responsible for returning -EBADMSG if the verification
failed.
In the SPI-NAND world it was a bit different until now because there was
only one possible ECC engine: the on-die one. Indeed, the
spinand_mtd_read() call was incrementing the ecc_stats counters
depending on the outcome of spinand_check_ecc_status() directly.
So now let's split the logic like this:
- spinand_check_ecc_status() is specific to the SPI-NAND on-die engine
and is kept very simple: it just returns the ECC status (bonus point:
the content of this helper can be overloaded).
- spinand_ondie_ecc_finish_io_req() is the caller of
spinand_check_ecc_status() and will increment the counters and
eventually return -EBADMSG.
- spinand_mtd_read() is not tied to the on-die ECC implementation and
should be able to handle results coming from other ECC engines: it has
the responsibility of returning the maximum number of bitflips which
happened during the entire operation as this is the only helper that
is aware that several pages may be read in a row.
Fixes: 945845b54c9c ("mtd: spinand: Instantiate a SPI-NAND on-die ECC engine")
Reported-by: YouChing Lin <ycllin@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: YouChing Lin <ycllin@mxic.com.tw>
Link: https://lore.kernel.org/linux-mtd/20210527084345.208215-1-miquel.raynal@bootlin.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a0d36fa1065901f939b04587a09c65303a64ac88 ]
We should not dereference ->dual_link_port if it is NULL and lane bonding
is requested. For this reason move lane bonding configuration happen
inside the block where ->dual_link_port != NULL.
Fixes: 54509f5005ca ("thunderbolt: Add KUnit tests for path walking")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 388161ca45c911f566b71716bce5ff0119fb5522 ]
SPI NOR flashes will just ignore program commands if the OTP region is
locked. Thus, a user might not notice that the intended write didn't end
up in the flash. Return -EROFS to the user in this case. From what I can
tell, chips/cfi_cmdset_0001.c also return this error code.
One could optimize spi_nor_mtd_otp_range_is_locked() to read the status
register only once and not for every OTP region, but for that we would
need some more invasive changes. Given that this is
one-time-programmable memory and the normal access mode is reading, we
just live with the small overhead.
By moving the code around a bit, we can just check the length before
calling spi_nor_mtd_otp_range_is_locked() and avoid an underflow there
if a len is 0. This way we don't need to take the lock either. We also
skip the "*retlen = 0" assignment, mtdcore already takes care of that
for us.
Fixes: 069089acf88b ("mtd: spi-nor: add OTP support")
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit b97b1a769849beb6b40b740817b06f1a50e1c589 ]
The security registers either take a 3 byte or a 4 byte address offset,
depending on the address mode of the flash. Thus just leave the
nor->addr_width as is.
Fixes: cad3193fe9d1 ("mtd: spi-nor: implement OTP support for Winbond and similar flashes")
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Acked-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e0db3deea73ba418bf5dc21f5a4e32ca87d16dde ]
When iterating over child firmware nodes restore printing the name of ones
that are not supported.
While at it, refactor loop body to clearly show that we stop at the first match.
Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing")
Cc: Huy Duong <qhuyduong@hotmail.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210607221757.81465-2-andy.shevchenko@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 3f6ee1c095156a74ab2df605af13020f1ce3e600 ]
device_get_next_child_node() bumps a reference counting of a returned variable.
We have to balance it whenever we return to the caller.
Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing")
Cc: Huy Duong <qhuyduong@hotmail.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210607221757.81465-1-andy.shevchenko@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit aafe93516b8567ab5864e1f4cd3eeabc54fb0e5a ]
Every time the hub signals a reset while we (device) are hsotg->connected,
dwc2_hsotg_core_init_disconnected() is called, which in turn calls
dwc2_hs_phy_init().
GUSBCFG.USBTrdTim is cleared upon Core Soft Reset, so if
hsotg->params.phy_utmi_width is 8-bit, the value of GUSBCFG.USBTrdTim (the
default one: 0x5, corresponding to 16-bit) is always different from
hsotg->params.phy_utmi_width, thus dwc2_core_reset() is called every
time (usbcfg != usbcfg_old), which causes 2 issues:
1) The call to dwc2_core_reset() does another reset 300us after the initial
Chirp K of the first reset (which should last at least Tuch = 1ms), and
messes up the High-speed Detection Handshake: both hub and device drive
current into the D+ and D- lines at the same time.
2) GUSBCFG.USBTrdTim is cleared by the second reset, so its value is always
the default one (0x5).
Setting GUSBCFG.USBTrdTim after the potential call to dwc2_core_reset()
fixes both issues. It is now set even when select_phy is false because the
cost of the Core Soft Reset is removed.
Fixes: 1e868545f2bb ("usb: dwc2: gadget: Move gadget phy init into core phy init")
Signed-off-by: Clément Lassieur <clement@lassieur.org>
Link: https://lore.kernel.org/r/20210603155921.940651-1-clement@lassieur.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ecfbd7b9054bddb12cea07fda41bb3a79a7b0149 ]
FunctionFS device structure 'struct ffs_dev' and driver data structure
'struct ffs_data' are bound to each other with cross-reference pointers
'ffs_data->private_data' and 'ffs_dev->ffs_data'. While the first one
is supposed to be valid through the whole life of 'struct ffs_data'
(and while 'struct ffs_dev' exists non-freed), the second one is cleared
in 'ffs_closed()' (called from 'ffs_data_reset()' or the last
'ffs_data_put()'). This can be called several times, alternating in
different order with 'ffs_free_inst()', that, if possible, clears
the other cross-reference.
As a result, different cases of these calls order may leave stale
cross-reference pointers, used when the pointed structure is already
freed. Even if it occasionally doesn't cause kernel crash, this error
is reported by KASAN-enabled kernel configuration.
For example, the case [last 'ffs_data_put()' - 'ffs_free_inst()'] was
fixed by commit cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in
ffs_free_inst").
The other case ['ffs_data_reset()' - 'ffs_free_inst()' - 'ffs_data_put()']
now causes KASAN reported error [1], when 'ffs_data_reset()' clears
'ffs_dev->ffs_data', then 'ffs_free_inst()' frees the 'struct ffs_dev',
but can't clear 'ffs_data->private_data', which is then accessed
in 'ffs_closed()' called from 'ffs_data_put()'. This happens since
'ffs_dev->ffs_data' reference is cleared too early.
Moreover, one more use case, when 'ffs_free_inst()' is called immediately
after mounting FunctionFS device (that is before the descriptors are
written and 'ffs_ready()' is called), and then 'ffs_data_reset()'
or 'ffs_data_put()' is called from accessing "ep0" file or unmounting
the device. This causes KASAN error report like [2], since
'ffs_dev->ffs_data' is not yet set when 'ffs_free_inst()' can't properly
clear 'ffs_data->private_data', that is later accessed to freed structure.
Fix these (and may be other) cases of stale pointers access by moving
setting and clearing of the mentioned cross-references to the single
places, setting both of them when 'struct ffs_data' is created and
bound to 'struct ffs_dev', and clearing both of them when one of the
structures is destroyed. It seems convenient to make this pointer
initialization and structures binding in 'ffs_acquire_dev()' and
make pointers clearing in 'ffs_release_dev()'. This required some
changes in these functions parameters and return types.
Also, 'ffs_release_dev()' calling requires some cleanup, fixing minor
issues, like (1) 'ffs_release_dev()' is not called if 'ffs_free_inst()'
is called without unmounting the device, and "release_dev" callback
is not called at all, or (2) "release_dev" callback is called before
"ffs_closed" callback on unmounting, which seems to be not correctly
nested with "acquire_dev" and "ffs_ready" callbacks.
Make this cleanup togther with other mentioned 'ffs_release_dev()' changes.
[1]
==================================================================
root@rcar-gen3:~# mkdir /dev/cfs
root@rcar-gen3:~# mkdir /dev/ffs
root@rcar-gen3:~# modprobe libcomposite
root@rcar-gen3:~# mount -t configfs none /dev/cfs
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[ 64.340664] file system registered
root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs
root@rcar-gen3:~# cd /dev/ffs
root@rcar-gen3:/dev/ffs# /home/root/ffs-test
ffs-test: info: ep0: writing descriptors (in v2 format)
[ 83.181442] read descriptors
[ 83.186085] read strings
ffs-test: info: ep0: writing strings
ffs-test: dbg: ep1: starting
ffs-test: dbg: ep2: starting
ffs-test: info: ep1: starts
ffs-test: info: ep2: starts
ffs-test: info: ep0: starts
^C
root@rcar-gen3:/dev/ffs# cd /home/root/
root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[ 98.935061] unloading
root@rcar-gen3:~# umount /dev/ffs
[ 102.734301] ==================================================================
[ 102.742059] BUG: KASAN: use-after-free in ffs_release_dev+0x64/0xa8 [usb_f_fs]
[ 102.749683] Write of size 1 at addr ffff0004d46ff549 by task umount/2997
[ 102.756709]
[ 102.758311] CPU: 0 PID: 2997 Comm: umount Not tainted 5.13.0-rc4+ #8
[ 102.764971] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[ 102.772179] Call trace:
[ 102.774779] dump_backtrace+0x0/0x330
[ 102.778653] show_stack+0x20/0x2c
[ 102.782152] dump_stack+0x11c/0x1ac
[ 102.785833] print_address_description.constprop.0+0x30/0x274
[ 102.791862] kasan_report+0x14c/0x1c8
[ 102.795719] __asan_report_store1_noabort+0x34/0x58
[ 102.800840] ffs_release_dev+0x64/0xa8 [usb_f_fs]
[ 102.805801] ffs_fs_kill_sb+0x50/0x84 [usb_f_fs]
[ 102.810663] deactivate_locked_super+0xa0/0xf0
[ 102.815339] deactivate_super+0x98/0xac
[ 102.819378] cleanup_mnt+0xd0/0x1b0
[ 102.823057] __cleanup_mnt+0x1c/0x28
[ 102.826823] task_work_run+0x104/0x180
[ 102.830774] do_notify_resume+0x458/0x14e0
[ 102.835083] work_pending+0xc/0x5f8
[ 102.838762]
[ 102.840357] Allocated by task 2988:
[ 102.844032] kasan_save_stack+0x28/0x58
[ 102.848071] kasan_set_track+0x28/0x3c
[ 102.852016] ____kasan_kmalloc+0x84/0x9c
[ 102.856142] __kasan_kmalloc+0x10/0x1c
[ 102.860088] __kmalloc+0x214/0x2f8
[ 102.863678] kzalloc.constprop.0+0x14/0x20 [usb_f_fs]
[ 102.868990] ffs_alloc_inst+0x8c/0x208 [usb_f_fs]
[ 102.873942] try_get_usb_function_instance+0xf0/0x164 [libcomposite]
[ 102.880629] usb_get_function_instance+0x64/0x68 [libcomposite]
[ 102.886858] function_make+0x128/0x1ec [libcomposite]
[ 102.892185] configfs_mkdir+0x330/0x590 [configfs]
[ 102.897245] vfs_mkdir+0x12c/0x1bc
[ 102.900835] do_mkdirat+0x180/0x1d0
[ 102.904513] __arm64_sys_mkdirat+0x80/0x94
[ 102.908822] invoke_syscall+0xf8/0x25c
[ 102.912772] el0_svc_common.constprop.0+0x150/0x1a0
[ 102.917891] do_el0_svc+0xa0/0xd4
[ 102.921386] el0_svc+0x24/0x34
[ 102.924613] el0_sync_handler+0xcc/0x154
[ 102.928743] el0_sync+0x198/0x1c0
[ 102.932238]
[ 102.933832] Freed by task 2996:
[ 102.937144] kasan_save_stack+0x28/0x58
[ 102.941181] kasan_set_track+0x28/0x3c
[ 102.945128] kasan_set_free_info+0x28/0x4c
[ 102.949435] ____kasan_slab_free+0x104/0x118
[ 102.953921] __kasan_slab_free+0x18/0x24
[ 102.958047] slab_free_freelist_hook+0x148/0x1f0
[ 102.962897] kfree+0x318/0x440
[ 102.966123] ffs_free_inst+0x164/0x2d8 [usb_f_fs]
[ 102.971075] usb_put_function_instance+0x84/0xa4 [libcomposite]
[ 102.977302] ffs_attr_release+0x18/0x24 [usb_f_fs]
[ 102.982344] config_item_put+0x140/0x1a4 [configfs]
[ 102.987486] configfs_rmdir+0x3fc/0x518 [configfs]
[ 102.992535] vfs_rmdir+0x114/0x234
[ 102.996122] do_rmdir+0x274/0x2b0
[ 102.999617] __arm64_sys_unlinkat+0x94/0xc8
[ 103.004015] invoke_syscall+0xf8/0x25c
[ 103.007961] el0_svc_common.constprop.0+0x150/0x1a0
[ 103.013080] do_el0_svc+0xa0/0xd4
[ 103.016575] el0_svc+0x24/0x34
[ 103.019801] el0_sync_handler+0xcc/0x154
[ 103.023930] el0_sync+0x198/0x1c0
[ 103.027426]
[ 103.029020] The buggy address belongs to the object at ffff0004d46ff500
[ 103.029020] which belongs to the cache kmalloc-128 of size 128
[ 103.042079] The buggy address is located 73 bytes inside of
[ 103.042079] 128-byte region [ffff0004d46ff500, ffff0004d46ff580)
[ 103.054236] The buggy address belongs to the page:
[ 103.059262] page:0000000021aa849b refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff0004d46fee00 pfn:0x5146fe
[ 103.070437] head:0000000021aa849b order:1 compound_mapcount:0
[ 103.076456] flags: 0x8000000000010200(slab|head|zone=2)
[ 103.081948] raw: 8000000000010200 fffffc0013521a80 0000000d0000000d ffff0004c0002300
[ 103.090052] raw: ffff0004d46fee00 000000008020001e 00000001ffffffff 0000000000000000
[ 103.098150] page dumped because: kasan: bad access detected
[ 103.103985]
[ 103.105578] Memory state around the buggy address:
[ 103.110602] ffff0004d46ff400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 103.118161] ffff0004d46ff480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 103.125726] >ffff0004d46ff500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 103.133284] ^
[ 103.139120] ffff0004d46ff580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 103.146679] ffff0004d46ff600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 103.154238] ==================================================================
[ 103.161792] Disabling lock debugging due to kernel taint
[ 103.167319] Unable to handle kernel paging request at virtual address 0037801d6000018e
[ 103.175406] Mem abort info:
[ 103.178457] ESR = 0x96000004
[ 103.181609] EC = 0x25: DABT (current EL), IL = 32 bits
[ 103.187020] SET = 0, FnV = 0
[ 103.190185] EA = 0, S1PTW = 0
[ 103.193417] Data abort info:
[ 103.196385] ISV = 0, ISS = 0x00000004
[ 103.200315] CM = 0, WnR = 0
[ 103.203366] [0037801d6000018e] address between user and kernel address ranges
[ 103.210611] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 103.216231] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk sata_rc4
[ 103.259233] CPU: 0 PID: 2997 Comm: umount Tainted: G B 5.13.0-rc4+ #8
[ 103.267031] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[ 103.273951] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
[ 103.280001] pc : ffs_data_clear+0x138/0x370 [usb_f_fs]
[ 103.285197] lr : ffs_data_clear+0x124/0x370 [usb_f_fs]
[ 103.290385] sp : ffff800014777a80
[ 103.293725] x29: ffff800014777a80 x28: ffff0004d7649c80 x27: 0000000000000000
[ 103.300931] x26: ffff800014777fb0 x25: ffff60009aec9394 x24: ffff0004d7649ca4
[ 103.308136] x23: 1fffe0009a3d063a x22: dfff800000000000 x21: ffff0004d1e831d0
[ 103.315340] x20: e1c000eb00000bb4 x19: ffff0004d1e83000 x18: 0000000000000000
[ 103.322545] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 103.329748] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000012ef658
[ 103.336952] x11: ffff7000012ef658 x10: 0720072007200720 x9 : ffff800011322648
[ 103.344157] x8 : ffff800014777818 x7 : ffff80000977b2c7 x6 : 0000000000000000
[ 103.351359] x5 : 0000000000000001 x4 : ffff7000012ef659 x3 : 0000000000000001
[ 103.358562] x2 : 0000000000000000 x1 : 1c38001d6000018e x0 : e1c000eb00000c70
[ 103.365766] Call trace:
[ 103.368235] ffs_data_clear+0x138/0x370 [usb_f_fs]
[ 103.373076] ffs_data_reset+0x20/0x304 [usb_f_fs]
[ 103.377829] ffs_data_closed+0x1ec/0x244 [usb_f_fs]
[ 103.382755] ffs_fs_kill_sb+0x70/0x84 [usb_f_fs]
[ 103.387420] deactivate_locked_super+0xa0/0xf0
[ 103.391905] deactivate_super+0x98/0xac
[ 103.395776] cleanup_mnt+0xd0/0x1b0
[ 103.399299] __cleanup_mnt+0x1c/0x28
[ 103.402906] task_work_run+0x104/0x180
[ 103.406691] do_notify_resume+0x458/0x14e0
[ 103.410823] work_pending+0xc/0x5f8
[ 103.414351] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821)
[ 103.420490] ---[ end trace 57b43a50e8244f57 ]---
Segmentation fault
root@rcar-gen3:~#
==================================================================
[2]
==================================================================
root@rcar-gen3:~# mkdir /dev/ffs
root@rcar-gen3:~# modprobe libcomposite
root@rcar-gen3:~#
root@rcar-gen3:~# mount -t configfs none /dev/cfs
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[ 54.766480] file system registered
root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs
root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[ 63.197597] unloading
root@rcar-gen3:~# cat /dev/ffs/ep0
cat: read error:[ 67.213506] ==================================================================
[ 67.222095] BUG: KASAN: use-after-free in ffs_data_clear+0x70/0x370 [usb_f_fs]
[ 67.229699] Write of size 1 at addr ffff0004c26e974a by task cat/2994
[ 67.236446]
[ 67.238045] CPU: 0 PID: 2994 Comm: cat Not tainted 5.13.0-rc4+ #8
[ 67.244431] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[ 67.251624] Call trace:
[ 67.254212] dump_backtrace+0x0/0x330
[ 67.258081] show_stack+0x20/0x2c
[ 67.261579] dump_stack+0x11c/0x1ac
[ 67.265260] print_address_description.constprop.0+0x30/0x274
[ 67.271286] kasan_report+0x14c/0x1c8
[ 67.275143] __asan_report_store1_noabort+0x34/0x58
[ 67.280265] ffs_data_clear+0x70/0x370 [usb_f_fs]
[ 67.285220] ffs_data_reset+0x20/0x304 [usb_f_fs]
[ 67.290172] ffs_data_closed+0x240/0x244 [usb_f_fs]
[ 67.295305] ffs_ep0_release+0x40/0x54 [usb_f_fs]
[ 67.300256] __fput+0x304/0x580
[ 67.303576] ____fput+0x18/0x24
[ 67.306893] task_work_run+0x104/0x180
[ 67.310846] do_notify_resume+0x458/0x14e0
[ 67.315154] work_pending+0xc/0x5f8
[ 67.318834]
[ 67.320429] Allocated by task 2988:
[ 67.324105] kasan_save_stack+0x28/0x58
[ 67.328144] kasan_set_track+0x28/0x3c
[ 67.332090] ____kasan_kmalloc+0x84/0x9c
[ 67.336217] __kasan_kmalloc+0x10/0x1c
[ 67.340163] __kmalloc+0x214/0x2f8
[ 67.343754] kzalloc.constprop.0+0x14/0x20 [usb_f_fs]
[ 67.349066] ffs_alloc_inst+0x8c/0x208 [usb_f_fs]
[ 67.354017] try_get_usb_function_instance+0xf0/0x164 [libcomposite]
[ 67.360705] usb_get_function_instance+0x64/0x68 [libcomposite]
[ 67.366934] function_make+0x128/0x1ec [libcomposite]
[ 67.372260] configfs_mkdir+0x330/0x590 [configfs]
[ 67.377320] vfs_mkdir+0x12c/0x1bc
[ 67.380911] do_mkdirat+0x180/0x1d0
[ 67.384589] __arm64_sys_mkdirat+0x80/0x94
[ 67.388899] invoke_syscall+0xf8/0x25c
[ 67.392850] el0_svc_common.constprop.0+0x150/0x1a0
[ 67.397969] do_el0_svc+0xa0/0xd4
[ 67.401464] el0_svc+0x24/0x34
[ 67.404691] el0_sync_handler+0xcc/0x154
[ 67.408819] el0_sync+0x198/0x1c0
[ 67.412315]
[ 67.413909] Freed by task 2993:
[ 67.417220] kasan_save_stack+0x28/0x58
[ 67.421257] kasan_set_track+0x28/0x3c
[ 67.425204] kasan_set_free_info+0x28/0x4c
[ 67.429513] ____kasan_slab_free+0x104/0x118
[ 67.434001] __kasan_slab_free+0x18/0x24
[ 67.438128] slab_free_freelist_hook+0x148/0x1f0
[ 67.442978] kfree+0x318/0x440
[ 67.446205] ffs_free_inst+0x164/0x2d8 [usb_f_fs]
[ 67.451156] usb_put_function_instance+0x84/0xa4 [libcomposite]
[ 67.457385] ffs_attr_release+0x18/0x24 [usb_f_fs]
[ 67.462428] config_item_put+0x140/0x1a4 [configfs]
[ 67.467570] configfs_rmdir+0x3fc/0x518 [configfs]
[ 67.472626] vfs_rmdir+0x114/0x234
[ 67.476215] do_rmdir+0x274/0x2b0
[ 67.479710] __arm64_sys_unlinkat+0x94/0xc8
[ 67.484108] invoke_syscall+0xf8/0x25c
[ 67.488055] el0_svc_common.constprop.0+0x150/0x1a0
[ 67.493175] do_el0_svc+0xa0/0xd4
[ 67.496671] el0_svc+0x24/0x34
[ 67.499896] el0_sync_handler+0xcc/0x154
[ 67.504024] el0_sync+0x198/0x1c0
[ 67.507520]
[ 67.509114] The buggy address belongs to the object at ffff0004c26e9700
[ 67.509114] which belongs to the cache kmalloc-128 of size 128
[ 67.522171] The buggy address is located 74 bytes inside of
[ 67.522171] 128-byte region [ffff0004c26e9700, ffff0004c26e9780)
[ 67.534328] The buggy address belongs to the page:
[ 67.539355] page:000000003177a217 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5026e8
[ 67.549175] head:000000003177a217 order:1 compound_mapcount:0
[ 67.555195] flags: 0x8000000000010200(slab|head|zone=2)
[ 67.560687] raw: 8000000000010200 fffffc0013037100 0000000c00000002 ffff0004c0002300
[ 67.568791] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
[ 67.576890] page dumped because: kasan: bad access detected
[ 67.582725]
[ 67.584318] Memory state around the buggy address:
[ 67.589343] ffff0004c26e9600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 67.596903] ffff0004c26e9680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 67.604463] >ffff0004c26e9700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 67.612022] ^
[ 67.617860] ffff0004c26e9780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 67.625421] ffff0004c26e9800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 67.632981] ==================================================================
[ 67.640535] Disabling lock debugging due to kernel taint
File descriptor[ 67.646100] Unable to handle kernel paging request at virtual address fabb801d4000018d
in bad state
[ 67.655456] Mem abort info:
[ 67.659619] ESR = 0x96000004
[ 67.662801] EC = 0x25: DABT (current EL), IL = 32 bits
[ 67.668225] SET = 0, FnV = 0
[ 67.671375] EA = 0, S1PTW = 0
[ 67.674613] Data abort info:
[ 67.677587] ISV = 0, ISS = 0x00000004
[ 67.681522] CM = 0, WnR = 0
[ 67.684588] [fabb801d4000018d] address between user and kernel address ranges
[ 67.691849] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 67.697470] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul sha2_ce sha1_ce evdev sata_rcar libata xhci_plat_hcd scsi_mod xhci_hcd rene4
[ 67.740467] CPU: 0 PID: 2994 Comm: cat Tainted: G B 5.13.0-rc4+ #8
[ 67.748005] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[ 67.754924] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
[ 67.760974] pc : ffs_data_clear+0x138/0x370 [usb_f_fs]
[ 67.766178] lr : ffs_data_clear+0x124/0x370 [usb_f_fs]
[ 67.771365] sp : ffff800014767ad0
[ 67.774706] x29: ffff800014767ad0 x28: ffff800009cf91c0 x27: ffff0004c54861a0
[ 67.781913] x26: ffff0004dc90b288 x25: 1fffe00099ec10f5 x24: 00000000000a801d
[ 67.789118] x23: 1fffe00099f6953a x22: dfff800000000000 x21: ffff0004cfb4a9d0
[ 67.796322] x20: d5e000ea00000bb1 x19: ffff0004cfb4a800 x18: 0000000000000000
[ 67.803526] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 67.810730] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000028ecefa
[ 67.817934] x11: ffff7000028ecefa x10: 0720072007200720 x9 : ffff80001132c014
[ 67.825137] x8 : ffff8000147677d8 x7 : ffff8000147677d7 x6 : 0000000000000000
[ 67.832341] x5 : 0000000000000001 x4 : ffff7000028ecefb x3 : 0000000000000001
[ 67.839544] x2 : 0000000000000005 x1 : 1abc001d4000018d x0 : d5e000ea00000c6d
[ 67.846748] Call trace:
[ 67.849218] ffs_data_clear+0x138/0x370 [usb_f_fs]
[ 67.854058] ffs_data_reset+0x20/0x304 [usb_f_fs]
[ 67.858810] ffs_data_closed+0x240/0x244 [usb_f_fs]
[ 67.863736] ffs_ep0_release+0x40/0x54 [usb_f_fs]
[ 67.868488] __fput+0x304/0x580
[ 67.871665] ____fput+0x18/0x24
[ 67.874837] task_work_run+0x104/0x180
[ 67.878622] do_notify_resume+0x458/0x14e0
[ 67.882754] work_pending+0xc/0x5f8
[ 67.886282] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821)
[ 67.892422] ---[ end trace 6d7cedf53d7abbea ]---
Segmentation fault
root@rcar-gen3:~#
==================================================================
Fixes: 4b187fceec3c ("usb: gadget: FunctionFS: add devices management code")
Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference")
Fixes: cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in ffs_free_inst")
Reported-by: Bhuvanesh Surachari <bhuvanesh_surachari@mentor.com>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Link: https://lore.kernel.org/r/20210603171507.22514-1-andrew_gabbasov@mentor.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
'mtk_btcvsd_snd_probe()'
[ Upstream commit b6052c3c7a78f5e2b9756c92ef77c0b56435f107 ]
If an error occurs after a successful 'of_iomap()' call, it must be undone
by a corresponding 'iounmap()' call, as already done in the remove
function.
While at it, remove the useless initialization of 'ret' at the beginning of
the function.
Fixes: 4bd8597dc36c ("ASoC: mediatek: add btcvsd driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/0c2ba562c3364e61bfbd5b3013a99dfa0d9045d7.1622989685.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit bcc0f0c078771e983a7e602eb14efa02f811445f ]
We currently only hangle rt711->regmap in rt711_sdca_io_init(), and
rt711->mbq_regmap is missing.
Fixes: 7ad4d237e7c4a ('ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver')
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-16-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 5ad1ba99e4784929588c79e9810f5610825f0411 ]
SDW_SDCA_CTL() registers are used but are not set to readable.
Fixes: 7ad4d237e7c4a ('ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver')
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-15-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c0372bc873dd29f325ee908351e0bd5b08d4d608 ]
RT5682_DEVICE_ID is a volatile register, we can not read it in cache
only mode.
Fixes: 03f6fc6de919 ("ASoC: rt5682: Add the soundwire support")
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-14-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
the soundwire
[ Upstream commit 9266d95405ae0c078f188ec8bca3a004631be429 ]
The device checking error should be a jump to pm_runtime_put_autosuspend()
as done before returning value.
Fixes: 867f8d18df4f ('ASoC: rt5682: fix getting the wrong device id when the suspend_stress_test')
Reviewed-by: Bard Liao <bard.liao@intel.com>
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-13-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e343d34a9c912fc5c321e2a9fbc02e9dc9534ade ]
Fix clock stop prepare timeout issue (#2853).
The trigger of internal circuit which belong to
“SDCA preset stuffs” was not set correctly in previous driver,
which could block clock_stop_preparation state.
Add the correct register setting to fix it.
Fixes: 20d17057f0a8c ('ASoC: rt715-sdca: Add RT715 sdca vendor-specific driver')
Signed-off-by: Jack Yu <jack.yu@realtek.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-12-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit dbc07517ab173688ef11234d1099bc1e24e4f14b ]
The intent of the status check on resume was to verify if a SoundWire
peripheral reported ATTACHED before waiting for the initialization to
complete. This is required to avoid timeouts that will happen with
'ghost' devices that are exposed in the platform firmware but are not
populated in hardware.
Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to
another error, the resume operation never timed out, but the volume
settings were not properly restored.
BugLink: https://github.com/thesofproject/linux/issues/2908
BugLink: https://github.com/thesofproject/linux/issues/2637
Fixes: d1ede0641b05e ('ASoC: rt715: add RT715 codec driver')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-11-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d34d0897a753f42c8a7a6af3866781dd57344a45 ]
The intent of the status check on resume was to verify if a SoundWire
peripheral reported ATTACHED before waiting for the initialization to
complete. This is required to avoid timeouts that will happen with
'ghost' devices that are exposed in the platform firmware but are not
populated in hardware.
Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to
another error, the resume operation never timed out, but the volume
settings were not properly restored.
This patch renames the status flag to 'first_hw_init' for consistency
with other drivers (was 'first_init')
BugLink: https://github.com/thesofproject/linux/issues/2908
BugLink: https://github.com/thesofproject/linux/issues/2637
Fixes: 20d17057f0a8c ('ASoC: rt715-sdca: Add RT715 sdca vendor-specific driver')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-10-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a0897ebca669f09a2e02206a9c48a738af655329 ]
The intent of the status check on resume was to verify if a SoundWire
peripheral reported ATTACHED before waiting for the initialization to
complete. This is required to avoid timeouts that will happen with
'ghost' devices that are exposed in the platform firmware but are not
populated in hardware.
Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to
another error, the resume operation never timed out, but the volume
settings were not properly restored.
BugLink: https://github.com/thesofproject/linux/issues/2908
BugLink: https://github.com/thesofproject/linux/issues/2637
Fixes: 320b8b0d13b81 ('ASoC: rt711: add rt711 codec driver')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-9-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit b32cab09707bb7fd851128633157c92716df6781 ]
The intent of the status check on resume was to verify if a SoundWire
peripheral reported ATTACHED before waiting for the initialization to
complete. This is required to avoid timeouts that will happen with
'ghost' devices that are exposed in the platform firmware but are not
populated in hardware.
Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to
another error, the resume operation never timed out, but the volume
settings were not properly restored.
BugLink: https://github.com/thesofproject/linux/issues/2908
BugLink: https://github.com/thesofproject/linux/issues/2637
Fixes: 7ad4d237e7c4a ('ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a9e54e5fbe396b546771cf77b43ce7c75e212278 ]
The intent of the status check on resume was to verify if a SoundWire
peripheral reported ATTACHED before waiting for the initialization to
complete. This is required to avoid timeouts that will happen with
'ghost' devices that are exposed in the platform firmware but are not
populated in hardware.
Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to
another error, the resume operation never timed out, but the volume
settings were not properly restored.
BugLink: https://github.com/thesofproject/linux/issues/2908
BugLink: https://github.com/thesofproject/linux/issues/2637
Fixes: 7d2a5f9ae41e3 ('ASoC: rt700: add rt700 codec driver')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 5361a42114689f875a9748299cadb4b1adbee6f4 ]
The intent of the status check on resume was to verify if a SoundWire
peripheral reported ATTACHED before waiting for the initialization to
complete. This is required to avoid timeouts that will happen with
'ghost' devices that are exposed in the platform firmware but are not
populated in hardware.
Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to
another error, the resume operation never timed out, but the volume
settings were not properly restored.
BugLink: https://github.com/thesofproject/linux/issues/2908
BugLink: https://github.com/thesofproject/linux/issues/2637
Fixes: 03f6fc6de9192 ('ASoC: rt5682: Add the soundwire support')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ebe2ef60ed76c1afd8ec84e1bfd1868e3456e96b ]
The intent of the status check on resume was to verify if a SoundWire
peripheral reported ATTACHED before waiting for the initialization to
complete. This is required to avoid timeouts that will happen with
'ghost' devices that are exposed in the platform firmware but are not
populated in hardware.
Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to
another error, the resume operation never timed out, but the volume
settings were not properly restored.
BugLink: https://github.com/thesofproject/linux/issues/2908
BugLink: https://github.com/thesofproject/linux/issues/2637
Fixes: 2b719fd20f327 ('ASoC: rt1316: Add RT1316 SDCA vendor-specific driver')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 30e102dab5fad1db71684f8ac5e1ac74e49da06d ]
The intent of the status check on resume was to verify if a SoundWire
peripheral reported ATTACHED before waiting for the initialization to
complete. This is required to avoid timeouts that will happen with
'ghost' devices that are exposed in the platform firmware but are not
populated in hardware.
Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to
another error, the resume operation never timed out, but the volume
settings were not properly restored.
BugLink: https://github.com/thesofproject/linux/issues/2908
BugLink: https://github.com/thesofproject/linux/issues/2637
Fixes: a87a6653a28c0 ('ASoC: rt1308-sdw: add rt1308 SdW amplifier driver')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit bf881170311ea74ff30c3be0be8fb097132ce696 ]
The intent of the status check on resume was to verify if a SoundWire
peripheral reported ATTACHED before waiting for the initialization to
complete. This is required to avoid timeouts that will happen with
'ghost' devices that are exposed in the platform firmware but are not
populated in hardware.
Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to
another error, the resume operation never timed out, but the volume
settings were not properly restored.
This patch renames the status flag to 'first_hw_init' for consistency
with other drivers.
BugLink: https://github.com/thesofproject/linux/issues/2637
Fixes: 56a5b7910e96 ('ASoC: codecs: max98373: add SoundWire support')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 468a272ca49cc4e2f58f3c360643c3f6d313c146 ]
We forgot to test that devm_kcalloc doesn't return NULL.
Fixes: 349dd23931d1 ('ASoC: max98373: don't access volatile registers in bias level off')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20210607222239.582139-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|