summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
* dm btree remove: fix use after free in rebalance_children()Joe Thornber2021-12-221-1/+1
| | | | | | | | | | | commit 1b8d2789dad0005fd5e7d35dab26a8e1203fb6da upstream. Move dm_tm_unlock() after dm_tm_dec(). Cc: stable@vger.kernel.org Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* hwmon: (dell-smm) Fix warning on /proc/i8k creation errorArmin Wolf2021-12-221-2/+5
| | | | | | | | | | | | | | | | | | | commit dbd3e6eaf3d813939b28e8a66e29d81cdc836445 upstream. The removal function is called regardless of whether /proc/i8k was created successfully or not, the later causing a WARN() on module removal. Fix that by only registering the removal function if /proc/i8k was created successfully. Tested on a Inspiron 3505. Fixes: 039ae58503f3 ("hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Acked-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20211112171440.59006-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* i2c: rk3x: Handle a spurious start completion interrupt flagOndrej Jirman2021-12-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 02fe0fbd8a21e183687925c3a266ae27dda9840f ] In a typical read transfer, start completion flag is being set after read finishes (notice ipd bit 4 being set): trasnfer poll=0 i2c start rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10 i2c read rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b i2c stop rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 33 This causes I2C transfer being aborted in polled mode from a stop completion handler: trasnfer poll=1 i2c start rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10 i2c read rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 0 rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b i2c stop rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 13 i2c stop rk3x-i2c fdd40000.i2c: unexpected irq in STOP: 0x10 Clearing the START flag after read fixes the issue without any obvious side effects. This issue was dicovered on RK3566 when adding support for powering off the RK817 PMIC. Signed-off-by: Ondrej Jirman <megous@megous.com> Reviewed-by: John Keeping <john@metanate.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* parisc/agp: Annotate parisc agp init functions with __initHelge Deller2021-12-221-3/+3
| | | | | | | | [ Upstream commit 8d88382b7436551a9ebb78475c546b670790cbf6 ] Signed-off-by: Helge Deller <deller@gmx.de> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* net/mlx4_en: Update reported link modes for 1/10GErik Ekman2021-12-221-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 2191b1dfef7d45f44b5008d2148676d9f2c82874 ] When link modes were initially added in commit 2c762679435dc ("net/mlx4_en: Use PTYS register to query ethtool settings") and later updated for the new ethtool API in commit 3d8f7cc78d0eb ("net: mlx4: use new ETHTOOL_G/SSETTINGS API") the only 1/10G non-baseT link modes configured were 1000baseKX, 10000baseKX4 and 10000baseKR. It looks like these got picked to represent other modes since nothing better was available. Switch to using more specific link modes added in commit 5711a98221443 ("net: ethtool: add support for 1000BaseX and missing 10G link modes"). Tested with MCX311A-XCAT connected via DAC. Before: % sudo ethtool enp3s0 Settings for enp3s0: Supported ports: [ FIBRE ] Supported link modes: 1000baseKX/Full 10000baseKR/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 1000baseKX/Full 10000baseKR/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 10000Mb/s Duplex: Full Auto-negotiation: off Port: Direct Attach Copper PHYAD: 0 Transceiver: internal Supports Wake-on: d Wake-on: d Current message level: 0x00000014 (20) link ifdown Link detected: yes With this change: % sudo ethtool enp3s0 Settings for enp3s0: Supported ports: [ FIBRE ] Supported link modes: 1000baseX/Full 10000baseCR/Full 10000baseSR/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 1000baseX/Full 10000baseCR/Full 10000baseSR/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 10000Mb/s Duplex: Full Auto-negotiation: off Port: Direct Attach Copper PHYAD: 0 Transceiver: internal Supports Wake-on: d Wake-on: d Current message level: 0x00000014 (20) link ifdown Link detected: yes Tested-by: Michael Stapelberg <michael@stapelberg.ch> Signed-off-by: Erik Ekman <erik@kryo.se> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/msm/dsi: set default num_data_lanesPhilip Chen2021-12-221-0/+2
| | | | | | | | | | | | | | | | | | | | [ Upstream commit cd92cc187c053ab010a1570e2d61d68394a5c725 ] If "data_lanes" property of the dsi output endpoint is missing in the DT, num_data_lanes would be 0 by default, which could cause dsi_host_attach() to fail if dsi->lanes is set to a non-zero value by the bridge driver. According to the binding document of msm dsi controller, the input/output endpoint of the controller is expected to have 4 lanes. So let's set num_data_lanes to 4 by default. Signed-off-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20211030100812.1.I6cd9af36b723fed277d34539d3b2ba4ca233ad2d@changeid Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* irqchip: nvic: Fix offset for Interrupt Priority OffsetsVladimir Murzin2021-12-141-1/+1
| | | | | | | | | | | | | | commit c5e0cbe2858d278a27d5b3fe31890aea5be064c4 upstream. According to ARM(v7M) ARM Interrupt Priority Offsets located at 0xE000E400-0xE000E5EC, while 0xE000E300-0xE000E33C covers read-only Interrupt Active Bit Registers Fixes: 292ec080491d ("irqchip: Add support for ARMv7-M NVIC") Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211201110259.84857-1-vladimir.murzin@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* irqchip/irq-gic-v3-its.c: Force synchronisation when issuing INVALLWudi Wang2021-12-141-1/+1
| | | | | | | | | | | | | | | | | | | commit b383a42ca523ce54bcbd63f7c8f3cf974abc9b9a upstream. INVALL CMD specifies that the ITS must ensure any caching associated with the interrupt collection defined by ICID is consistent with the LPI configuration tables held in memory for all Redistributors. SYNC is required to ensure that INVALL is executed. Currently, LPI configuration data may be inconsistent with that in the memory within a short period of time after the INVALL command is executed. Signed-off-by: Wudi Wang <wangwudi@hisilicon.com> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Link: https://lore.kernel.org/r/20211208015429.5007-1-zhangshaokun@hisilicon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* irqchip/armada-370-xp: Fix support for Multi-MSI interruptsPali Rohár2021-12-141-9/+5
| | | | | | | | | | | | | | | | | | | commit d0a553502efd545c1ce3fd08fc4d423f8e4ac3d6 upstream. irq-armada-370-xp driver already sets MSI_FLAG_MULTI_PCI_MSI flag into msi_domain_info structure. But allocated interrupt numbers for Multi-MSI needs to be properly aligned otherwise devices send MSI interrupt with wrong number. Fix this issue by using function bitmap_find_free_region() instead of bitmap_find_next_zero_area() to allocate aligned interrupt numbers. Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: a71b9412c90c ("irqchip/armada-370-xp: Allow allocation of multiple MSIs") Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211125130057.26705-2-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* irqchip/armada-370-xp: Fix return value of armada_370_xp_msi_alloc()Pali Rohár2021-12-141-1/+1
| | | | | | | | | | | | | | commit ce20eff57361e72878a772ef08b5239d3ae102b6 upstream. IRQ domain alloc function should return zero on success. Non-zero value indicates failure. Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: fcc392d501bd ("irqchip/armada-370-xp: Use the generic MSI infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211125130057.26705-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: accel: kxcjk-1013: Fix possible memory leak in probe and removeYang Yingliang2021-12-141-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 70c9774e180d151abaab358108e3510a8e615215 upstream. When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the memory allocated by iio_triggered_buffer_setup() will not be freed, and cause memory leak as follows: unreferenced object 0xffff888009551400 (size 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s) hex dump (first 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ ....... backtrace: [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360 [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf] [<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer] [<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013] Fix it by remove data->dready_trig condition in probe and remove. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: a25691c1f967 ("iio: accel: kxcjk1013: allow using an external trigger") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Cc: <Stable@vger.kernel.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211025124159.2700301-1-yangyingliang@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: adc: axp20x_adc: fix charging current reporting on AXP22xEvgeny Boger2021-12-141-15/+3
| | | | | | | | | | | | | | | | | | | | | | | commit 92beafb76a31bdc02649eb44e93a8e4f4cfcdbe8 upstream. Both the charging and discharging currents on AXP22x are stored as 12-bit integers, in accordance with the datasheet. It's also confirmed by vendor BSP (axp20x_adc.c:axp22_icharge_to_mA). The scale factor of 0.5 is never mentioned in datasheet, nor in the vendor source code. I think it was here to compensate for erroneous addition bit in register width. Tested on custom A40i+AXP221s board with external ammeter as a reference. Fixes: 0e34d5de961d ("iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs") Signed-off-by: Evgeny Boger <boger@wirenboard.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20211116213746.264378-1-boger@wirenboard.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: dln2: Check return value of devm_iio_trigger_register()Lars-Peter Clausen2021-12-141-1/+5
| | | | | | | | | | | | | | | commit 90751fb9f224e0e1555b49a8aa9e68f6537e4cec upstream. Registering a trigger can fail and the return value of devm_iio_trigger_register() must be checked. Otherwise undefined behavior can occur when the trigger is used. Fixes: 7c0299e879dd ("iio: adc: Add support for DLN2 ADC") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211101133043.6974-1-lars@metafoo.de Cc: <stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: dln2-adc: Fix lockdep complaintNoralf Trønnes2021-12-141-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 59f92868176f191eefde70d284bdfc1ed76a84bc upstream. When reading the voltage: $ cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw Lockdep complains: [ 153.910616] ====================================================== [ 153.916918] WARNING: possible circular locking dependency detected [ 153.923221] 5.14.0+ #5 Not tainted [ 153.926692] ------------------------------------------------------ [ 153.932992] cat/717 is trying to acquire lock: [ 153.937525] c2585358 (&indio_dev->mlock){+.+.}-{3:3}, at: iio_device_claim_direct_mode+0x28/0x44 [ 153.946541] but task is already holding lock: [ 153.952487] c2585860 (&dln2->mutex){+.+.}-{3:3}, at: dln2_adc_read_raw+0x94/0x2bc [dln2_adc] [ 153.961152] which lock already depends on the new lock. Fix this by not calling into the iio core underneath the dln2->mutex lock. Fixes: 7c0299e879dd ("iio: adc: Add support for DLN2 ADC") Cc: Jack Andersen <jackoalan@gmail.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://lore.kernel.org/r/20211018113731.25723-1-noralf@tronnes.org Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: itg3200: Call iio_trigger_notify_done() on errorLars-Peter Clausen2021-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | commit 67fe29583e72b2103abb661bb58036e3c1f00277 upstream. IIO trigger handlers must call iio_trigger_notify_done() when done. This must be done even when an error occurred. Otherwise the trigger will be seen as busy indefinitely and the trigger handler will never be called again. The itg3200 driver neglects to call iio_trigger_notify_done() when there is an error reading the gyro data. Fix this by making sure that iio_trigger_notify_done() is included in the error exit path. Fixes: 9dbf091da080 ("iio: gyro: Add itg3200") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211101144055.13858-1-lars@metafoo.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: kxsd9: Don't return error code in trigger handlerLars-Peter Clausen2021-12-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 45febe0d63917ee908198c5be08511c64ee1790a upstream. IIO trigger handlers need to return one of the irqreturn_t values. Returning an error code is not supported. The kxsd9 interrupt handler returns an error code if reading the data registers fails. In addition when exiting due to an error the trigger handler does not call `iio_trigger_notify_done()`. Which when not done keeps the triggered disabled forever. Modify the code so that the function returns a valid irqreturn_t value as well as calling `iio_trigger_notify_done()` on all exit paths. Since we can't return the error code make sure to at least log it as part of the error message. Fixes: 0427a106a98a ("iio: accel: kxsd9: Add triggered buffer handling") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211024171251.22896-2-lars@metafoo.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: ltr501: Don't return error code in trigger handlerLars-Peter Clausen2021-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | commit ef9d67fa72c1b149a420587e435a3e888bdbf74f upstream. IIO trigger handlers need to return one of the irqreturn_t values. Returning an error code is not supported. The ltr501 interrupt handler gets this right for most error paths, but there is one case where it returns the error code. In addition for this particular case the trigger handler does not call `iio_trigger_notify_done()`. Which when not done keeps the triggered disabled forever. Modify the code so that the function returns a valid irqreturn_t value as well as calling `iio_trigger_notify_done()` on all exit paths. Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211024171251.22896-1-lars@metafoo.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: mma8452: Fix trigger reference coutingLars-Peter Clausen2021-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | commit cd0082235783f814241a1c9483fb89e405f4f892 upstream. The mma8452 driver directly assigns a trigger to the struct iio_dev. The IIO core when done using this trigger will call `iio_trigger_put()` to drop the reference count by 1. Without the matching `iio_trigger_get()` in the driver the reference count can reach 0 too early, the trigger gets freed while still in use and a use-after-free occurs. Fix this by getting a reference to the trigger before assigning it to the IIO device. Fixes: ae6d9ce05691 ("iio: mma8452: Add support for interrupt driven triggers.") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211024092700.6844-1-lars@metafoo.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: stk3310: Don't return error code in interrupt handlerLars-Peter Clausen2021-12-141-3/+3
| | | | | | | | | | | | | | | | | | | commit 8e1eeca5afa7ba84d885987165dbdc5decf15413 upstream. Interrupt handlers must return one of the irqreturn_t values. Returning a error code is not supported. The stk3310 event interrupt handler returns an error code when reading the flags register fails. Fix the implementation to always return an irqreturn_t value. Fixes: 3dd477acbdd1 ("iio: light: Add threshold interrupt support for STK3310") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211024171251.22896-3-lars@metafoo.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: trigger: stm32-timer: fix MODULE_ALIASAlyssa Ross2021-12-141-1/+1
| | | | | | | | | | | | | commit 893621e0606747c5bbefcaf2794d12c7aa6212b7 upstream. modprobe can't handle spaces in aliases. Fixes: 93fbe91b5521 ("iio: Add STM32 timer trigger driver") Signed-off-by: Alyssa Ross <hi@alyssa.is> Link: https://lore.kernel.org/r/20211125182850.2645424-1-hi@alyssa.is Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iio: trigger: Fix reference countingLars-Peter Clausen2021-12-141-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit a827a4984664308f13599a0b26c77018176d0c7c upstream. In viio_trigger_alloc() device_initialize() is used to set the initial reference count of the trigger to 1. Then another get_device() is called on trigger. This sets the reference count to 2 before the trigger is returned. iio_trigger_free(), which is the matching API to viio_trigger_alloc(), calls put_device() which decreases the reference count by 1. But the second reference count acquired in viio_trigger_alloc() is never dropped. As a result the iio_trigger_release() function is never called and the memory associated with the trigger is never freed. Since there is no reason for the trigger to start its lifetime with two reference counts just remove the extra get_device() in viio_trigger_alloc(). Fixes: 5f9c035cae18 ("staging:iio:triggers. Add a reference get to the core for triggers.") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20211024092700.6844-2-lars@metafoo.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: core: config: using bit mask instead of individual bitsPavel Hofman2021-12-141-2/+2
| | | | | | | | | | | | commit ca5737396927afd4d57b133fd2874bbcf3421cdb upstream. Using standard USB_EP_MAXP_MULT_MASK instead of individual bits for extracting multiple-transactions bits from wMaxPacketSize value. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com> Link: https://lore.kernel.org/r/20211210085219.16796-2-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Remove CONFIG_USB_DEFAULT_PERSIST to prevent xHCI from runtime suspendingKai-Heng Feng2021-12-141-4/+0
| | | | | | | | | | | | | | | | | | | | | commit 811ae81320da53a5670c36970cefacca8519f90e upstream. When the xHCI is quirked with XHCI_RESET_ON_RESUME, runtime resume routine also resets the controller. This is bad for USB drivers without reset_resume callback, because there's no subsequent call of usb_dev_complete() -> usb_resume_complete() to force rebinding the driver to the device. For instance, btusb device stops working after xHCI controller is runtime resumed, if the controlled is quirked with XHCI_RESET_ON_RESUME. So always take XHCI_RESET_ON_RESUME into account to solve the issue. Cc: <stable@vger.kernel.org> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211210141735.1384209-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: core: config: fix validation of wMaxPacketValue entriesPavel Hofman2021-12-141-1/+1
| | | | | | | | | | | | | | | | | | commit 1a3910c80966e4a76b25ce812f6bea0ef1b1d530 upstream. The checks performed by commit aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors") require that initial value of the maxp variable contains both maximum packet size bits (10..0) and multiple-transactions bits (12..11). However, the existing code assings only the maximum packet size bits. This patch assigns all bits of wMaxPacketSize to the variable. Fixes: aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors") Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com> Link: https://lore.kernel.org/r/20211210085219.16796-1-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: gadget: zero allocate endpoint 0 buffersGreg Kroah-Hartman2021-12-142-2/+2
| | | | | | | | | | | | commit 86ebbc11bb3f60908a51f3e41a17e3f477c2eaa3 upstream. Under some conditions, USB gadget devices can show allocated buffer contents to a host. Fix this up by zero-allocating them so that any extra data will all just be zeros. Reported-by: Szymon Heidrich <szymon.heidrich@gmail.com> Tested-by: Szymon Heidrich <szymon.heidrich@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: gadget: detect too-big endpoint 0 requestsGreg Kroah-Hartman2021-12-143-1/+40
| | | | | | | | | | | | commit 153a2d7e3350cc89d406ba2d35be8793a64c2038 upstream. Sometimes USB hosts can ask for buffers that are too large from endpoint 0, which should not be allowed. If this happens for OUT requests, stall the endpoint, but for IN requests, trim the request size to the endpoint buffer size. Co-developed-by: Szymon Heidrich <szymon.heidrich@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* net/qla3xxx: fix an error code in ql_adapter_up()Dan Carpenter2021-12-141-10/+9
| | | | | | | | | | | | | | | | | commit d17b9737c2bc09b4ac6caf469826e5a7ce3ffab7 upstream. The ql_wait_for_drvr_lock() fails and returns false, then this function should return an error code instead of returning success. The other problem is that the success path prints an error message netdev_err(ndev, "Releasing driver lock\n"); Delete that and re-order the code a little to make it more clear. Fixes: 5a4faa873782 ("[PATCH] qla3xxx NIC driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211207082416.GA16110@kili Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* net: fec: only clear interrupt of handling queue in fec_enet_rx_queue()Joakim Zhang2021-12-142-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b5bd95d17102b6719e3531d627875b9690371383 upstream. Background: We have a customer is running a Profinet stack on the 8MM which receives and responds PNIO packets every 4ms and PNIO-CM packets every 40ms. However, from time to time the received PNIO-CM package is "stock" and is only handled when receiving a new PNIO-CM or DCERPC-Ping packet (tcpdump shows the PNIO-CM and the DCERPC-Ping packet at the same time but the PNIO-CM HW timestamp is from the expected 40 ms and not the 2s delay of the DCERPC-Ping). After debugging, we noticed PNIO, PNIO-CM and DCERPC-Ping packets would be handled by different RX queues. The root cause should be driver ack all queues' interrupt when handle a specific queue in fec_enet_rx_queue(). The blamed patch is introduced to receive as much packets as possible once to avoid interrupt flooding. But it's unreasonable to clear other queues'interrupt when handling one queue, this patch tries to fix it. Fixes: ed63f1dcd578 (net: fec: clear receive interrupts before processing a packet) Cc: Russell King <rmk+kernel@arm.linux.org.uk> Reported-by: Nicolas Diaz <nicolas.diaz@nxp.com> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20211206135457.15946-1-qiangqing.zhang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* net: altera: set a couple error code in probe()Dan Carpenter2021-12-141-3/+6
| | | | | | | | | | | | commit badd7857f5c933a3dc34942a2c11d67fdbdc24de upstream. There are two error paths which accidentally return success instead of a negative error code. Fixes: bbd2190ce96d ("Altera TSE: Add main and header file for Altera Ethernet Driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zeroLee Jones2021-12-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 2be6d4d16a0849455a5c22490e3c5983495fed00 upstream. Currently, due to the sequential use of min_t() and clamp_t() macros, in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is not set, the logic sets tx_max to 0. This is then used to allocate the data area of the SKB requested later in cdc_ncm_fill_tx_frame(). This does not cause an issue presently because when memory is allocated during initialisation phase of SKB creation, more memory (512b) is allocated than is required for the SKB headers alone (320b), leaving some space (512b - 320b = 192b) for CDC data (172b). However, if more elements (for example 3 x u64 = [24b]) were added to one of the SKB header structs, say 'struct skb_shared_info', increasing its original size (320b [320b aligned]) to something larger (344b [384b aligned]), then suddenly the CDC data (172b) no longer fits in the spare SKB data area (512b - 384b = 128b). Consequently the SKB bounds checking semantics fails and panics: skbuff: skb_over_panic: text:ffffffff830a5b5f len:184 put:172 \ head:ffff888119227c00 data:ffff888119227c00 tail:0xb8 end:0x80 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:110! RIP: 0010:skb_panic+0x14f/0x160 net/core/skbuff.c:106 <snip> Call Trace: <IRQ> skb_over_panic+0x2c/0x30 net/core/skbuff.c:115 skb_put+0x205/0x210 net/core/skbuff.c:1877 skb_put_zero include/linux/skbuff.h:2270 [inline] cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1116 [inline] cdc_ncm_fill_tx_frame+0x127f/0x3d50 drivers/net/usb/cdc_ncm.c:1293 cdc_ncm_tx_fixup+0x98/0xf0 drivers/net/usb/cdc_ncm.c:1514 By overriding the max value with the default CDC_NCM_NTB_MAX_SIZE_TX when not offered through the system provided params, we ensure enough data space is allocated to handle the CDC data, meaning no crash will occur. Cc: Oliver Neukum <oliver@neukum.org> Fixes: 289507d3364f9 ("net: cdc_ncm: use sysfs for rx/tx aggregation tuning") Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Bjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20211202143437.1411410-1-lee.jones@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* qede: validate non LSO skb lengthManish Chopra2021-12-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 8e227b198a55859bf790dc7f4b1e30c0859c6756 upstream. Although it is unlikely that stack could transmit a non LSO skb with length > MTU, however in some cases or environment such occurrences actually resulted into firmware asserts due to packet length being greater than the max supported by the device (~9700B). This patch adds the safeguard for such odd cases to avoid firmware asserts. v2: Added "Fixes" tag with one of the initial driver commit which enabled the TX traffic actually (as this was probably day1 issue which was discovered recently by some customer environment) Fixes: a2ec6172d29c ("qede: Add support for link") Signed-off-by: Manish Chopra <manishc@marvell.com> Signed-off-by: Alok Prasad <palok@marvell.com> Signed-off-by: Prabhakar Kushwaha <pkushwaha@marvell.com> Signed-off-by: Ariel Elior <aelior@marvell.com> Link: https://lore.kernel.org/r/20211203174413.13090-1-manishc@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* binder: use wake_up_pollfree()Eric Biggers2021-12-141-12/+9
| | | | | | | | | | | | | | | | | | commit a880b28a71e39013e357fd3adccd1d8a31bc69a8 upstream. wake_up_poll() uses nr_exclusive=1, so it's not guaranteed to wake up all exclusive waiters. Yet, POLLFREE *must* wake up all waiters. epoll and aio poll are fortunately not affected by this, but it's very fragile. Thus, the new function wake_up_pollfree() has been introduced. Convert binder to use wake_up_pollfree(). Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Fixes: f5cb779ba163 ("ANDROID: binder: remove waitqueue when thread exits.") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211209010455.42744-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* libata: add horkage for ASMedia 1092Hannes Reinecke2021-12-141-0/+2
| | | | | | | | | | | | | | commit a66307d473077b7aeba74e9b09c841ab3d399c2d upstream. The ASMedia 1092 has a configuration mode which will present a dummy device; sadly the implementation falsely claims to provide a device with 100M which doesn't actually exist. So disable this device to avoid errors during boot. Cc: stable@vger.kernel.org Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* can: m_can: Disable and ignore ELO interruptBrian Silverman2021-12-141-8/+6
| | | | | | | | | | | | | | | | | | | | | | commit f58ac1adc76b5beda43c64ef359056077df4d93a upstream. With the design of this driver, this condition is often triggered. However, the counter that this interrupt indicates an overflow is never read either, so overflowing is harmless. On my system, when a CAN bus starts flapping up and down, this locks up the whole system with lots of interrupts and printks. Specifically, this interrupt indicates the CEL field of ECR has overflowed. All reads of ECR mask out CEL. Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support") Link: https://lore.kernel.org/all/20211129222628.7490-1-brian.silverman@bluerivertech.com Cc: stable@vger.kernel.org Signed-off-by: Brian Silverman <brian.silverman@bluerivertech.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* can: pch_can: pch_can_rx_normal: fix use after freeVincent Mailhol2021-12-141-1/+1
| | | | | | | | | | | | | | | | | | commit 94cddf1e9227a171b27292509d59691819c458db upstream. After calling netif_receive_skb(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is dereferenced just after the call netif_receive_skb(skb). Reordering the lines solves the issue. Fixes: b21d18b51b31 ("can: Topcliff: Add PCH_CAN driver.") Link: https://lore.kernel.org/all/20211123111654.621610-1-mailhol.vincent@wanadoo.fr Cc: stable@vger.kernel.org Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* IB/hfi1: Correct guard on eager buffer deallocationMike Marciniszyn2021-12-141-1/+1
| | | | | | | | | | | | | | | | commit 9292f8f9a2ac42eb320bced7153aa2e63d8cc13a upstream. The code tests the dma address which legitimately can be 0. The code should test the kernel logical address to avoid leaking eager buffer allocations that happen to map to a dma address of 0. Fixes: 60368186fd85 ("IB/hfi1: Fix user-space buffers mapping with IOMMU enabled") Link: https://lore.kernel.org/r/20211129191952.101968.17137.stgit@awfm-01.cornelisnetworks.com Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* nfp: Fix memory leak in nfp_cpp_area_cache_add()Jianglei Nie2021-12-141-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c56c96303e9289cc34716b1179597b6f470833de upstream. In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak. We can fix it by freeing the CPP area when the cache is allocated failed (#2). 792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size) 793 { 794 struct nfp_cpp_area_cache *cache; 795 struct nfp_cpp_area *area; 800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0), 801 0, size); // #1: allocates and initializes 802 if (!area) 803 return -ENOMEM; 805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free 817 return 0; 818 } Fixes: 4cb584e0ee7d ("nfp: add CPP access core") Signed-off-by: Jianglei Nie <niejianglei2021@163.com> Acked-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20211209061511.122535-1-niejianglei2021@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* can: sja1000: fix use after free in ems_pcmcia_add_card()Dan Carpenter2021-12-141-1/+6
| | | | | | | | | | | | | | | | | | commit 3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45 upstream. If the last channel is not available then "dev" is freed. Fortunately, we can just use "pdev->irq" instead. Also we should check if at least one channel was set up. Fixes: fd734c6f25ae ("can/sja1000: add driver for EMS PCMCIA card") Link: https://lore.kernel.org/all/20211124145041.GB13656@kili Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: check for valid USB device for many HID driversGreg Kroah-Hartman2021-12-1419-9/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 93020953d0fa7035fd036ad87a47ae2b7aa4ae33 upstream. Many HID drivers assume that the HID device assigned to them is a USB device as that was the only way HID devices used to be able to be created in Linux. However, with the additional ways that HID devices can be created for many different bus types, that is no longer true, so properly check that we have a USB device associated with the HID device before allowing a driver that makes this assumption to claim it. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Michael Zaidman <michael.zaidman@gmail.com> Cc: Stefan Achatz <erazor_de@users.sourceforge.net> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: linux-input@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> [bentiss: amended for thrustmater.c hunk to apply] Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211201183503.2373082-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: wacom: fix problems when device is not a valid USB deviceGreg Kroah-Hartman2021-12-141-5/+12
| | | | | | | | | | | | | | | | | | | | commit 720ac467204a70308bd687927ed475afb904e11b upstream. The wacom driver accepts devices of more than just USB types, but some code paths can cause problems if the device being controlled is not a USB device due to a lack of checking. Add the needed checks to ensure that the USB device accesses are only happening on a "real" USB device, and not one on some other bus. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Cc: stable@vger.kernel.org Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211201183503.2373082-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: add USB_HID dependancy on some USB HID driversGreg Kroah-Hartman2021-12-141-3/+3
| | | | | | | | | | | | | | | | | commit f237d9028f844a86955fc9da59d7ac4a5c55d7d5 upstream. Some HID drivers are only for USB drivers, yet did not depend on CONFIG_USB_HID. This was hidden by the fact that the USB functions were stubbed out in the past, but now that drivers are checking for USB devices properly, build errors can occur with some random configurations. Reported-by: kernel test robot <lkp@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211202114819.2511954-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: add USB_HID dependancy to hid-chiconyGreg Kroah-Hartman2021-12-141-1/+1
| | | | | | | | | | | | | | | | | commit d080811f27936f712f619f847389f403ac873b8f upstream. The chicony HID driver only controls USB devices, yet did not have a dependancy on USB_HID. This causes build errors on some configurations like sparc when building due to new changes to the chicony driver. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: stable@vger.kernel.org Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211203075927.2829218-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: add USB_HID dependancy to hid-prodikeysGreg Kroah-Hartman2021-12-141-1/+1
| | | | | | | | | | | | | | | | | commit 30cb3c2ad24b66fb7639a6d1f4390c74d6e68f94 upstream. The prodikeys HID driver only controls USB devices, yet did not have a dependancy on USB_HID. This causes build errors on some configurations like nios2 when building due to new changes to the prodikeys driver. Reported-by: kernel test robot <lkp@intel.com> Cc: stable@vger.kernel.org Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211203081231.2856936-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: add hid_is_usb() function to make it simpler for USB detectionGreg Kroah-Hartman2021-12-142-2/+2
| | | | | | | | | | | | | | | | | | | | | commit f83baa0cb6cfc92ebaf7f9d3a99d7e34f2e77a8a upstream. A number of HID drivers already call hid_is_using_ll_driver() but only for the detection of if this is a USB device or not. Make this more obvious by creating hid_is_usb() and calling the function that way. Also converts the existing hid_is_using_ll_driver() functions to use the new call. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Cc: stable@vger.kernel.org Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211201183503.2373082-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: core: fix transmit-buffer reset and memleakJohan Hovold2021-12-081-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 00de977f9e0aa9760d9a79d1e41ff780f74e3424 upstream. Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()"). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")). Link: https://lore.kernel.org/r/319321886d97c456203d5c6a576a5480d07c3478.1635781688.git.baruch@tkos.co.il Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") Cc: stable@vger.kernel.org # 4.9 Cc: Rob Herring <robh@kernel.org> Reported-by: Baruch Siach <baruch@tkos.co.il> Tested-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211108085431.12637-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: pl011: Add ACPI SBSA UART match idPierre Gondois2021-12-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | commit ac442a077acf9a6bf1db4320ec0c3f303be092b3 upstream. The document 'ACPI for Arm Components 1.0' defines the following _HID mappings: -'Prime cell UART (PL011)': ARMH0011 -'SBSA UART': ARMHB000 Use the sbsa-uart driver when a device is described with the 'ARMHB000' _HID. Note: PL011 devices currently use the sbsa-uart driver instead of the uart-pl011 driver. Indeed, PL011 devices are not bound to a clock in ACPI. It is not possible to change their baudrate. Cc: <stable@vger.kernel.org> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Link: https://lore.kernel.org/r/20211109172248.19061-1-Pierre.Gondois@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tty: serial: msm_serial: Deactivate RX DMA for polling supportSven Eckelmann2021-12-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 7492ffc90fa126afb67d4392d56cb4134780194a upstream. The CONSOLE_POLLING mode is used for tools like k(g)db. In this kind of setup, it is often sharing a serial device with the normal system console. This is usually no problem because the polling helpers can consume input values directly (when in kgdb context) and the normal Linux handlers can only consume new input values after kgdb switched back. This is not true anymore when RX DMA is enabled for UARTDM controllers. Single input values can no longer be received correctly. Instead following seems to happen: * on 1. input, some old input is read (continuously) * on 2. input, two old inputs are read (continuously) * on 3. input, three old input values are read (continuously) * on 4. input, 4 previous inputs are received This repeats then for each group of 4 input values. This behavior changes slightly depending on what state the controller was when the first input was received. But this makes working with kgdb basically impossible because control messages are always corrupted when kgdboc tries to parse them. RX DMA should therefore be off when CONSOLE_POLLING is enabled to avoid these kind of problems. No such problem was noticed for TX DMA. Fixes: 99693945013a ("tty: serial: msm: Add RX DMA support") Cc: stable@vger.kernel.org Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://lore.kernel.org/r/20211113121050.7266-1-sven@narfation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: typec: tcpm: Wait in SNK_DEBOUNCED until disconnectBadhri Jagan Sridharan2021-12-081-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit fbcd13df1e78eb2ba83a3c160eefe2d6f574beaf upstream. Stub from the spec: "4.5.2.2.4.2 Exiting from AttachWait.SNK State A Sink shall transition to Unattached.SNK when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce. A DRP shall transition to Unattached.SRC when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce." This change makes TCPM to wait in SNK_DEBOUNCED state until CC1 and CC2 pins is SNK.Open for at least tPDDebounce. Previously, TCPM resets the port if vbus is not present in PD_T_PS_SOURCE_ON. This causes TCPM to loop continuously when connected to a faulty power source that does not present vbus. Waiting in SNK_DEBOUNCED also ensures that TCPM is adherant to "4.5.2.2.4.2 Exiting from AttachWait.SNK State" requirements. [ 6169.280751] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 6169.280759] state change TOGGLING -> SNK_ATTACH_WAIT [rev2 NONE_AMS] [ 6169.280771] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev2 NONE_AMS] [ 6169.282427] CC1: 0 -> 0, CC2: 5 -> 5 [state SNK_ATTACH_WAIT, polarity 0, connected] [ 6169.450825] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [ 6169.450834] pending state change SNK_DEBOUNCED -> PORT_RESET @ 480 ms [rev2 NONE_AMS] [ 6169.930892] state change SNK_DEBOUNCED -> PORT_RESET [delayed 480 ms] [ 6169.931296] disable vbus discharge ret:0 [ 6169.931301] Setting usb_comm capable false [ 6169.932783] Setting voltage/current limit 0 mV 0 mA [ 6169.932802] polarity 0 [ 6169.933706] Requesting mux state 0, usb-role 0, orientation 0 [ 6169.936689] cc:=0 [ 6169.936812] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev2 NONE_AMS] [ 6169.937157] CC1: 0 -> 0, CC2: 5 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 6170.036880] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 6170.036890] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev2 NONE_AMS] [ 6170.036896] Start toggling [ 6170.041412] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [ 6170.042973] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 6170.042976] state change TOGGLING -> SNK_ATTACH_WAIT [rev2 NONE_AMS] [ 6170.042981] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev2 NONE_AMS] [ 6170.213014] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [ 6170.213019] pending state change SNK_DEBOUNCED -> PORT_RESET @ 480 ms [rev2 NONE_AMS] [ 6170.693068] state change SNK_DEBOUNCED -> PORT_RESET [delayed 480 ms] [ 6170.693304] disable vbus discharge ret:0 [ 6170.693308] Setting usb_comm capable false [ 6170.695193] Setting voltage/current limit 0 mV 0 mA [ 6170.695210] polarity 0 [ 6170.695990] Requesting mux state 0, usb-role 0, orientation 0 [ 6170.701896] cc:=0 [ 6170.702181] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev2 NONE_AMS] [ 6170.703343] CC1: 0 -> 0, CC2: 5 -> 0 [state PORT_RESET, polarity 0, disconnected] Fixes: f0690a25a140b8 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable@vger.kernel.org Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Link: https://lore.kernel.org/r/20211130001825.3142830-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Fix commad ring abort, write all 64 bits to CRCR register.Mathias Nyman2021-12-081-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | commit 09f736aa95476631227d2dc0e6b9aeee1ad7ed58 upstream. Turns out some xHC controllers require all 64 bits in the CRCR register to be written to execute a command abort. The lower 32 bits containing the command abort bit is written first. In case the command ring stops before we write the upper 32 bits then hardware may use these upper bits to set the commnd ring dequeue pointer. Solve this by making sure the upper 32 bits contain a valid command ring dequeue pointer. The original patch that only wrote the first 32 to stop the ring went to stable, so this fix should go there as well. Fixes: ff0e50d3564f ("xhci: Fix command ring pointer corruption while aborting a command") Cc: stable@vger.kernel.org Tested-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211126122340.1193239-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* vgacon: Propagate console boot parameters before calling `vc_resize'Maciej W. Rozycki2021-12-081-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 3dfac26e2ef29ff2abc2a75aa4cd48fce25a2c4b upstream. Fix a division by zero in `vgacon_resize' with a backtrace like: vgacon_resize vc_do_resize vgacon_init do_bind_con_driver do_unbind_con_driver fbcon_fb_unbind do_unregister_framebuffer do_register_framebuffer register_framebuffer __drm_fb_helper_initial_config_and_unlock drm_helper_hpd_irq_event dw_hdmi_irq irq_thread kthread caused by `c->vc_cell_height' not having been initialized. This has only started to trigger with commit 860dafa90259 ("vt: Fix character height handling with VT_RESIZEX"), however the ultimate offender is commit 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console"). Said commit has added a call to `vc_resize' whenever `vgacon_init' is called with the `init' argument set to 0, which did not happen before. And the call is made before a key vgacon boot parameter retrieved in `vgacon_startup' has been propagated in `vgacon_init' for `vc_resize' to use to the console structure being worked on. Previously the parameter was `c->vc_font.height' and now it is `c->vc_cell_height'. In this particular scenario the registration of fbcon has failed and vt resorts to vgacon. Now fbcon does have initialized `c->vc_font.height' somehow, unlike `c->vc_cell_height', which is why this code did not crash before, but either way the boot parameters should have been copied to the console structure ahead of the call to `vc_resize' rather than afterwards, so that first the call has a chance to use them and second they do not change the console structure to something possibly different from what was used by `vc_resize'. Move the propagation of the vgacon boot parameters ahead of the call to `vc_resize' then. Adjust the comment accordingly. Fixes: 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console") Cc: stable@vger.kernel.org # v2.6.18+ Reported-by: Wim Osterholt <wim@djo.tudelft.nl> Reported-by: Pavel V. Panteleev <panteleev_p@mcst.ru> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2110252317110.58149@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-03-20 18:54:12 +0000