summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-07-14soundwire: stream: Fix test for DP prepare completeRichard Fitzgerald1-7/+6
[ 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>
2021-07-14scsi: mpt3sas: Fix error return value in _scsih_expander_add()Zhen Lei1-1/+3
[ 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>
2021-07-14habanalabs: Fix an error handling path in 'hl_pci_probe()'Christophe JAILLET1-0/+1
[ 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>
2021-07-14mtd: rawnand: marvell: add missing clk_disable_unprepare() on error in ↵Yang Yingliang1-1/+3
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>
2021-07-14of: Fix truncation of memory sizes on 32-bit platformsGeert Uytterhoeven2-8/+8
[ 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>
2021-07-14ASoC: cs42l42: Correct definition of CS42L42_ADC_PDN_MASKRichard Fitzgerald1-1/+1
[ 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>
2021-07-14iio: prox: isl29501: Fix buffer alignment in ↵Jonathan Cameron1-1/+1
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>
2021-07-14iio: light: vcnl4035: Fix buffer alignment in ↵Jonathan Cameron1-1/+2
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>
2021-07-14serial: 8250: Actually allow UPF_MAGIC_MULTIPLIER baud ratesMaciej W. Rozycki1-3/+16
[ 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>
2021-07-14usb: phy: tegra: Correct definition of B_SESS_VLD_WAKEUP_EN bitDmitry Osipenko1-3/+2
[ 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>
2021-07-14usb: phy: tegra: Wait for VBUS wakeup status deassertion on suspendDmitry Osipenko1-0/+10
[ 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>
2021-07-14staging: mt7621-dts: fix pci address for PCI memory rangeSergio Paracuellos1-1/+1
[ 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>
2021-07-14coresight: core: Fix use of uninitialized pointerJunhao He1-1/+1
[ 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>
2021-07-14staging: rtl8712: fix memory leak in rtl871x_load_fw_cbPavel Skripkin1-0/+3
[ 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>
2021-07-14staging: rtl8712: fix error handling in r871xu_drv_initPavel Skripkin2-14/+14
[ 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>
2021-07-14staging: gdm724x: check for overflow in gdm_lte_netif_rx()Dan Carpenter1-4/+6
[ 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>
2021-07-14staging: gdm724x: check for buffer overflow in gdm_lte_multi_sdu_pkt()Dan Carpenter1-1/+9
[ 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>
2021-07-14ASoC: fsl_spdif: Fix error handler with pm_runtime_enableShengjiu Wang1-3/+17
[ 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>
2021-07-14iio: light: vcnl4000: Fix buffer alignment in ↵Jonathan Cameron1-1/+1
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>
2021-07-14iio: magn: rm3100: Fix alignment of buffer in ↵Jonathan Cameron1-1/+2
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>
2021-07-14iio: adc: ti-ads8688: Fix alignment of buffer in ↵Jonathan Cameron1-1/+2
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>
2021-07-14iio: adc: mxs-lradc: Fix buffer alignment in ↵Jonathan Cameron1-1/+2
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>
2021-07-14iio: adc: hx711: Fix buffer alignment in iio_push_to_buffers_with_timestamp()Jonathan Cameron1-2/+2
[ 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>
2021-07-14iio: adc: at91-sama5d2: Fix buffer alignment in ↵Jonathan Cameron1-1/+2
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>
2021-07-14iio: dummy: Fix build error when CONFIG_IIO_TRIGGERED_BUFFER is not setWei Yongjun1-0/+1
[ 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>
2021-07-14kunit: Fix result propagation for parameterised testsDavid Gow1-4/+3
[ 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>
2021-07-14mtd: spinand: Fix double counting of ECC statsMiquel Raynal1-6/+11
[ 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>
2021-07-14thunderbolt: Bond lanes only when dual_link_port != NULL in alloc_dev_default()Mika Westerberg1-7/+7
[ 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>
2021-07-14mtd: spi-nor: otp: return -EROFS if region is read-onlyMichael Walle1-3/+38
[ 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>
2021-07-14mtd: spi-nor: otp: fix access to security registers in 4 byte modeMichael Walle1-2/+0
[ 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>
2021-07-14eeprom: idt_89hpesx: Restore printing the unsupported fwnode nameAndy Shevchenko1-4/+3
[ 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>
2021-07-14eeprom: idt_89hpesx: Put fwnode in matching case during ->probe()Andy Shevchenko1-0/+1
[ 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>
2021-07-14usb: dwc2: Don't reset the core after setting turnaround timeClément Lassieur1-9/+21
[ 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>
2021-07-14usb: gadget: f_fs: Fix setting of device and driver data cross-referencesAndrew Gabbasov1-33/+32
[ 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>
2021-07-14ASoC: mediatek: mtk-btcvsd: Fix an error handling path in ↵Christophe JAILLET1-6/+18
'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>
2021-07-14ASoC: rt711-sdca: handle mbq_regmap in rt711_sdca_io_initBard Liao1-0/+4
[ 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>
2021-07-14ASoC: rt711-sdca-sdw: add readable for SDW_SDCA_CTL() registersBard Liao1-0/+10
[ 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>
2021-07-14ASoC: rt5682-sdw: set regcache_cache_only false before reading RT5682_DEVICE_IDBard Liao1-5/+5
[ 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>
2021-07-14ASoC: rt5682: Fix a problem with error handling in the io init function of ↵Oder Chiou1-2/+5
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>
2021-07-14ASoC: rt715-sdca: fix clock stop prepare timeout issueJack Yu4-0/+6
[ 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>
2021-07-14ASoC: rt715-sdw: use first_hw_init flag on resumePierre-Louis Bossart1-1/+1
[ 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>
2021-07-14ASoC: rt715-sdca-sdw: use first_hw_init flag on resumePierre-Louis Bossart3-5/+5
[ 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>
2021-07-14ASoC: rt711-sdw: use first_hw_init flag on resumePierre-Louis Bossart1-1/+1
[ 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>
2021-07-14ASoC: rt711-sdca-sdw: use first_hw_init flag on resumePierre-Louis Bossart1-1/+1
[ 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>
2021-07-14ASoC: rt700-sdw: use first_hw_init flag on resumePierre-Louis Bossart1-1/+1
[ 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>
2021-07-14ASoC: rt5682-sdw: use first_hw_init flag on resumePierre-Louis Bossart1-1/+1
[ 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>
2021-07-14ASoC: rt1316-sdw: use first_hw_init flag on resumePierre-Louis Bossart1-1/+1
[ 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>
2021-07-14ASoC: rt1308-sdw: use first_hw_init flag on resumePierre-Louis Bossart1-1/+1
[ 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>
2021-07-14ASoC: max98373-sdw: use first_hw_init flag on resumePierre-Louis Bossart2-7/+7
[ 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>
2021-07-14ASoC: max98373-sdw: add missing memory allocation checkPierre-Louis Bossart1-0/+2
[ 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>