summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-10-20mlxsw: thermal: Fix out-of-bounds memory accessesIdo Schimmel1-47/+5
commit 332fdf951df8b870e3da86b122ae304e2aabe88c upstream. Currently, mlxsw allows cooling states to be set above the maximum cooling state supported by the driver: # cat /sys/class/thermal/thermal_zone2/cdev0/type mlxsw_fan # cat /sys/class/thermal/thermal_zone2/cdev0/max_state 10 # echo 18 > /sys/class/thermal/thermal_zone2/cdev0/cur_state # echo $? 0 This results in out-of-bounds memory accesses when thermal state transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the transition table is accessed with a too large index (state) [1]. According to the thermal maintainer, it is the responsibility of the driver to reject such operations [2]. Therefore, return an error when the state to be set exceeds the maximum cooling state supported by the driver. To avoid dead code, as suggested by the thermal maintainer [3], partially revert commit a421ce088ac8 ("mlxsw: core: Extend cooling device with cooling levels") that tried to interpret these invalid cooling states (above the maximum) in a special way. The cooling levels array is not removed in order to prevent the fans going below 20% PWM, which would cause them to get stuck at 0% PWM. [1] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290 Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5 CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122 Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016 Workqueue: events_freezable_power_ thermal_zone_device_check Call Trace: dump_stack_lvl+0x8b/0xb3 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b thermal_cooling_device_stats_update+0x271/0x290 __thermal_cdev_update+0x15e/0x4e0 thermal_cdev_update+0x9f/0xe0 step_wise_throttle+0x770/0xee0 thermal_zone_device_update+0x3f6/0xdf0 process_one_work+0xa42/0x1770 worker_thread+0x62f/0x13e0 kthread+0x3ee/0x4e0 ret_from_fork+0x1f/0x30 Allocated by task 1: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 thermal_cooling_device_setup_sysfs+0x153/0x2c0 __thermal_cooling_device_register.part.0+0x25b/0x9c0 thermal_cooling_device_register+0xb3/0x100 mlxsw_thermal_init+0x5c5/0x7e0 __mlxsw_core_bus_device_register+0xcb3/0x19c0 mlxsw_core_bus_device_register+0x56/0xb0 mlxsw_pci_probe+0x54f/0x710 local_pci_probe+0xc6/0x170 pci_device_probe+0x2b2/0x4d0 really_probe+0x293/0xd10 __driver_probe_device+0x2af/0x440 driver_probe_device+0x51/0x1e0 __driver_attach+0x21b/0x530 bus_for_each_dev+0x14c/0x1d0 bus_add_driver+0x3ac/0x650 driver_register+0x241/0x3d0 mlxsw_sp_module_init+0xa2/0x174 do_one_initcall+0xee/0x5f0 kernel_init_freeable+0x45a/0x4de kernel_init+0x1f/0x210 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff8881052f7800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 1016 bytes inside of 1024-byte region [ffff8881052f7800, ffff8881052f7c00) The buggy address belongs to the page: page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0 head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x200000000010200(slab|head|node=0|zone=2) raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67-1895-1fdc45c0244e@linaro.org/ [3] https://lore.kernel.org/linux-pm/af9857f2-578e-de3a-e62b-6baff7e69fd4@linaro.org/ CC: Daniel Lezcano <daniel.lezcano@linaro.org> Fixes: a50c1e35650b ("mlxsw: core: Implement thermal zone") Fixes: a421ce088ac8 ("mlxsw: core: Extend cooling device with cooling levels") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Tested-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20211012174955.472928-1-idosch@idosch.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20ata: ahci_platform: fix null-ptr-deref in ahci_platform_enable_regulators()Wang Hai1-4/+1
commit 776c75010803849c1cc4f11031a2b3960ab05202 upstream. I got a null-ptr-deref report: KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] ... RIP: 0010:regulator_enable+0x84/0x260 ... Call Trace: ahci_platform_enable_regulators+0xae/0x320 ahci_platform_enable_resources+0x1a/0x120 ahci_probe+0x4f/0x1b9 platform_probe+0x10b/0x280 ... entry_SYSCALL_64_after_hwframe+0x44/0xae If devm_regulator_get() in ahci_platform_get_resources() fails, hpriv->phy_regulator will point to NULL, when enabling or disabling it, null-ptr-deref will occur. ahci_probe() ahci_platform_get_resources() devm_regulator_get(, "phy") // failed, let phy_regulator = NULL ahci_platform_enable_resources() ahci_platform_enable_regulators() regulator_enable(hpriv->phy_regulator) // null-ptr-deref commit 962399bb7fbf ("ata: libahci_platform: Fix regulator_get_optional() misuse") replaces devm_regulator_get_optional() with devm_regulator_get(), but PHY regulator omits to delete "hpriv->phy_regulator = NULL;" like AHCI. Delete it like AHCI regulator to fix this bug. Fixes: commit 962399bb7fbf ("ata: libahci_platform: Fix regulator_get_optional() misuse") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20pata_legacy: fix a couple uninitialized variable bugsDan Carpenter1-2/+4
commit 013923477cb311293df9079332cf8b806ed0e6f2 upstream. The last byte of "pad" is used without being initialized. Fixes: 55dba3120fbc ("libata: update ->data_xfer hook for ATAPI") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20vhost-vdpa: Fix the wrong input in config_cbCindy Lu1-1/+1
commit bcef9356fc2e1302daf373c83c826aa27954d128 upstream. Fix the wrong input in for config_cb. In function vhost_vdpa_config_cb, the input cb.private was used as struct vhost_vdpa, so the input was wrong here, fix this issue Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa") Signed-off-by: Cindy Lu <lulu@redhat.com> Link: https://lore.kernel.org/r/20210929090933.20465-1-lulu@redhat.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20ethernet: s2io: fix setting mac address during resumeArnd Bergmann1-1/+1
commit 40507e7aada8422c38aafa0c8a1a09e4623c712a upstream. After recent cleanups, gcc started warning about a suspicious memcpy() call during the s2io_io_resume() function: In function '__dev_addr_set', inlined from 'eth_hw_addr_set' at include/linux/etherdevice.h:318:2, inlined from 's2io_set_mac_addr' at drivers/net/ethernet/neterion/s2io.c:5205:2, inlined from 's2io_io_resume' at drivers/net/ethernet/neterion/s2io.c:8569:7: arch/x86/include/asm/string_32.h:182:25: error: '__builtin_memcpy' accessing 6 bytes at offsets 0 and 2 overlaps 4 bytes at offset 2 [-Werror=restrict] 182 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/netdevice.h:4648:9: note: in expansion of macro 'memcpy' 4648 | memcpy(dev->dev_addr, addr, len); | ^~~~~~ What apparently happened is that an old cleanup changed the calling conventions for s2io_set_mac_addr() from taking an ethernet address as a character array to taking a struct sockaddr, but one of the callers was not changed at the same time. Change it to instead call the low-level do_s2io_prog_unicast() function that still takes the old argument type. Fixes: 2fd376884558 ("S2io: Added support set_mac_address driver entry point") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20211013143613.2049096-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20net: encx24j600: check error in devm_regmap_init_encx24j600Nanyong Sun3-5/+14
commit f03dca0c9e2297c84a018e306f8a9cd534ee4287 upstream. devm_regmap_init may return error which caused by like out of memory, this will results in null pointer dereference later when reading or writing register: general protection fault in encx24j600_spi_probe KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540 Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00 RSP: 0018:ffffc900010476b8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000 RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094 RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001 R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08 FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459 spi_probe drivers/spi/spi.c:397 really_probe drivers/base/dd.c:517 __driver_probe_device drivers/base/dd.c:751 driver_probe_device drivers/base/dd.c:782 __device_attach_driver drivers/base/dd.c:899 bus_for_each_drv drivers/base/bus.c:427 __device_attach drivers/base/dd.c:971 bus_probe_device drivers/base/bus.c:487 device_add drivers/base/core.c:3364 __spi_add_device drivers/spi/spi.c:599 spi_add_device drivers/spi/spi.c:641 spi_new_device drivers/spi/spi.c:717 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e] dev_attr_store drivers/base/core.c:2074 sysfs_kf_write fs/sysfs/file.c:139 kernfs_fop_write_iter fs/kernfs/file.c:300 new_sync_write fs/read_write.c:508 (discriminator 4) vfs_write fs/read_write.c:594 ksys_write fs/read_write.c:648 do_syscall_64 arch/x86/entry/common.c:50 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113 Add error check in devm_regmap_init_encx24j600 to avoid this situation. Fixes: 04fbfce7a222 ("net: Microchip encx24j600 driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Nanyong Sun <sunnanyong@huawei.com> Link: https://lore.kernel.org/r/20211012125901.3623144-1-sunnanyong@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20net: dsa: microchip: Added the condition for scheduling ksz_mib_read_workArun Ramadoss1-1/+3
commit ef1100ef20f29aec4e62abeccdb5bdbebba1e378 upstream. When the ksz module is installed and removed using rmmod, kernel crashes with null pointer dereferrence error. During rmmod, ksz_switch_remove function tries to cancel the mib_read_workqueue using cancel_delayed_work_sync routine and unregister switch from dsa. During dsa_unregister_switch it calls ksz_mac_link_down, which in turn reschedules the workqueue since mib_interval is non-zero. Due to which queue executed after mib_interval and it tries to access dp->slave. But the slave is unregistered in the ksz_switch_remove function. Hence kernel crashes. To avoid this crash, before canceling the workqueue, resetted the mib_interval to 0. v1 -> v2: -Removed the if condition in ksz_mib_read_work Fixes: 469b390e1ba3 ("net: dsa: microchip: use delayed_work instead of timer + work") Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20net: stmmac: fix get_hw_feature() on old hardwareHerve Codina4-9/+22
commit 075da584bae2da6a37428d59a477b6bdad430ac3 upstream. Some old IPs do not provide the hardware feature register. On these IPs, this register is read 0x00000000. In old driver version, this feature was handled but a regression came with the commit f10a6a3541b4 ("stmmac: rework get_hw_feature function"). Indeed, this commit removes the return value in dma->get_hw_feature(). This return value was used to indicate the validity of retrieved information and used later on in stmmac_hw_init() to override priv->plat data if this hardware feature were valid. This patch restores the return code in ->get_hw_feature() in order to indicate the hardware feature validity and override priv->plat data only if this hardware feature is valid. Fixes: f10a6a3541b4 ("stmmac: rework get_hw_feature function") Signed-off-by: Herve Codina <herve.codina@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20net/mlx5e: Mutually exclude RX-FCS and RX-port-timestampAya Levin1-5/+52
commit 0bc73ad46a76ed6ece4dcacb28858e7b38561e1c upstream. Due to current HW arch limitations, RX-FCS (scattering FCS frame field to software) and RX-port-timestamp (improved timestamp accuracy on the receive side) can't work together. RX-port-timestamp is not controlled by the user and it is enabled by default when supported by the HW/FW. This patch sets RX-port-timestamp opposite to RX-FCS configuration. Fixes: 102722fc6832 ("net/mlx5e: Add support for RXFCS feature flag") Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error pathValentine Fatiev1-4/+3
commit 94b960b9deffc02fc0747afc01f72cc62ab099e3 upstream. Prior to this patch in case mlx5_core_destroy_cq() failed it returns without completing all destroy operations and that leads to memory leak. Instead, complete the destroy flow before return error. Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq() to be symmetrical with mlx5_core_create_cq(). kmemleak complains on: unreferenced object 0xc000000038625100 (size 64): comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s) hex dump (first 32 bytes): 60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4..... 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}..... backtrace: [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core] [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core] [<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core] [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core] [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core] [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core] [<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core] [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230 [mlx5_core] [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300 [mlx5_core] [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core] [<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core] [<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0 [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0 [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0 [<00000000646c5c2c>] genl_rcv_msg+0x78/0x120 [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0 Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Valentine Fatiev <valentinef@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20net: korina: select CRC32Vegard Nossum1-0/+1
commit 427f974d9727ca681085ddcd0530c97ab5811ae0 upstream. Fix the following build/link error by adding a dependency on the CRC32 routines: ld: drivers/net/ethernet/korina.o: in function `korina_multicast_list': korina.c:(.text+0x1af): undefined reference to `crc32_le' Fixes: ef11291bcd5f9 ("Add support the Korina (IDT RC32434) Ethernet MAC") Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Acked-by: Florian fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20211012152509.21771-1-vegard.nossum@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20net: arc: select CRC32Vegard Nossum1-0/+1
commit e599ee234ad4fdfe241d937bbabd96e0d8f9d868 upstream. Fix the following build/link error by adding a dependency on the CRC32 routines: ld: drivers/net/ethernet/arc/emac_main.o: in function `arc_emac_set_rx_mode': emac_main.c:(.text+0xb11): undefined reference to `crc32_le' The crc32_le() call comes through the ether_crc_le() call in arc_emac_set_rx_mode(). [v2: moved the select to ARC_EMAC_CORE; the Makefile is a bit confusing, but the error comes from emac_main.o, which is part of the arc_emac module, which in turn is enabled by CONFIG_ARC_EMAC_CORE. Note that arc_emac is different from emac_arc...] Fixes: 775dd682e2b0ec ("arc_emac: implement promiscuous mode and multicast filtering") Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Link: https://lore.kernel.org/r/20211012093446.1575-1-vegard.nossum@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20gpio: pca953x: Improve bias settingAndy Shevchenko1-7/+9
commit 55a9968c7e139209a9e93d4ca4321731bea5fc95 upstream. The commit 15add06841a3 ("gpio: pca953x: add ->set_config implementation") introduced support for bias setting. However this, due to being half-baked, brought potential issues: - the turning bias via disabling makes the pin floating for a while; - once enabled, bias can't be disabled. Fix all these by adding support for bias disabling and move the disabling part under the corresponding conditional. While at it, add support for default setting, since it's cheap to add. Fixes: 15add06841a3 ("gpio: pca953x: add ->set_config implementation") Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20nvme-pci: Fix abort command idKeith Busch1-1/+1
commit 85f74acf097a63a07f5a7c215db6883e5c35e3ff upstream. The request tag is no longer the only component of the command id. Fixes: e7006de6c2380 ("nvme: code command_id with a genctr for use-after-free validation") Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20tee: optee: Fix missing devices unregister during optee_removeSumit Garg3-0/+26
commit 7f565d0ead264329749c0da488de9c8dfa2f18ce upstream. When OP-TEE driver is built as a module, OP-TEE client devices registered on TEE bus during probe should be unregistered during optee_remove. So implement optee_unregister_devices() accordingly. Fixes: c3fa24af9244 ("tee: optee: add TEE bus device enumeration support") Reported-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: dac: ti-dac5571: fix an error code in probe()Dan Carpenter1-0/+1
commit f7a28df7db84eb3410e9eca37832efa5aed93338 upstream. If we have an unexpected number of channels then return -EINVAL instead of returning success. Fixes: df38a4a72a3b ("iio: dac: add TI DAC5571 family support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210816183954.GB2068@kili Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: ssp_sensors: fix error code in ssp_print_mcu_debug()Dan Carpenter1-1/+1
commit 4170d3dd1467e9d78cb9af374b19357dc324b328 upstream. The ssp_print_mcu_debug() function should return negative error codes on error. Returning "length" is meaningless. This change does not affect runtime because the callers only care about zero/non-zero. Reported-by: Jonathan Cameron <jic23@kernel.org> Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210914105333.GA11657@kili Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: ssp_sensors: add more range checking in ssp_parse_dataframe()Dan Carpenter1-1/+8
commit 8167c9a375ccceed19048ad9d68cb2d02ed276e0 upstream. The "idx" is validated at the start of the loop but it gets incremented during the iteration so it needs to be checked again. Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210909091336.GA26312@kili Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: adc: max1027: Fix the number of max1X31 channelsMiquel Raynal1-1/+0
commit f0cb5fed37ab37f6a6c5463c5fd39b58a45670c8 upstream. The macro MAX1X29_CHANNELS() already calls MAX1X27_CHANNELS(). Calling MAX1X27_CHANNELS() before MAX1X29_CHANNELS() in the definition of MAX1X31_CHANNELS() declares the first 8 channels twice. So drop this extra call from the MAX1X31 channels list definition. Fixes: 7af5257d8427 ("iio: adc: max1027: Prepare the introduction of different resolutions") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210818111139.330636-3-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: light: opt3001: Fixed timeout error when 0 luxJiri Valek - 2N1-3/+3
commit 26d90b5590579def54382a2fc34cfbe8518a9851 upstream. Reading from sensor returned timeout error under zero light conditions. Signed-off-by: Jiri Valek - 2N <valek@2n.cz> Fixes: ac663db3678a ("iio: light: opt3001: enable operation w/o IRQ") Link: https://lore.kernel.org/r/20210920125351.6569-1-valek@2n.cz Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSEDHui Liu1-0/+8
commit c2980c64c7fd4585d684574c92d1624d44961edd upstream. The previous driver does't apply the necessary scaling to take the voltage range into account. We change readback value from raw data to input voltage to fix case IIO_CHAN_INFO_PROCESSED. Fixes: ace4cdfe67be ("iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.") Signed-off-by: Hui Liu <hui.liu@mediatek.com> Link: https://lore.kernel.org/r/20210926073028.11045-2-hui.liu@mediatek.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: adc: max1027: Fix wrong shift with 12-bit devicesMiquel Raynal1-1/+1
commit 732ae19ee8f58ecaf30cbc1bbbda5cbee6a45043 upstream. 10-bit devices must shift the value twice. This is not needed anymore on 12-bit devices. Fixes: ae47d009b508 ("iio: adc: max1027: Introduce 12-bit devices support") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210818111139.330636-2-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: adc128s052: Fix the error handling path of 'adc128_probe()'Christophe JAILLET1-0/+6
commit bbcf40816b547b3c37af49168950491d20d81ce1 upstream. A successful 'regulator_enable()' call should be balanced by a corresponding 'regulator_disable()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: 913b86468674 ("iio: adc: Add TI ADC128S052") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/85189f1cfcf6f5f7b42d8730966f2a074b07b5f5.1629542160.git.christophe.jaillet@wanadoo.fr Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: adc: ad7793: Fix IRQ flagAlexandru Tachici1-1/+1
commit 1a913270e57a8e7f1e3789802f1f64e6d0654626 upstream. In Sigma-Delta devices the SDO line is also used as an interrupt. Leaving IRQ on level instead of falling might trigger a sample read when the IRQ is enabled, as the SDO line is already low. Not sure if SDO line will always immediately go high in ad_sd_buffer_postenable before the IRQ is enabled. Also the datasheet seem to explicitly say the falling edge of the SDO should be used as an interrupt: >From the AD7793 datasheet: " The DOUT/RDY falling edge can be used as an interrupt to a processor" Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags") Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210906065630.16325-4-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: adc: ad7780: Fix IRQ flagAlexandru Tachici1-1/+1
commit e081102f3077aa716974ccebec97003c890d5641 upstream. Correct IRQ flag here is falling. In Sigma-Delta devices the SDO line is also used as an interrupt. Leaving IRQ on level instead of falling might trigger a sample read when the IRQ is enabled, as the SDO line is already low. Not sure if SDO line will always immediately go high in ad_sd_buffer_postenable before the IRQ is enabled. Also the datasheet seem to explicitly say the falling edge of the SDO should be used as an interrupt: >From the AD7780 datasheet: " The DOUT/Figure 22 RDY falling edge can be used as an interrupt to a processor" Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags") Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210906065630.16325-3-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: adc: ad7192: Add IRQ flagAlexandru Tachici1-0/+1
commit 89a86da5cb8e0ee153111fb68a719d31582c206b upstream. IRQ type in ad_sigma_delta_info struct was missing. In Sigma-Delta devices the SDO line is also used as an interrupt. Leaving IRQ on level instead of falling might trigger a sample read when the IRQ is enabled, as the SDO line is already low. Not sure if SDO line will always immediately go high in ad_sd_buffer_postenable before the IRQ is enabled. Also the datasheet seem to explicitly say the falling edge of the SDO should be used as an interrupt: >From the AD7192 datasheet: "The DOUT/RDY falling edge can be used as an interrupt to a processor," Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags") Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210906065630.16325-2-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20driver core: Reject pointless SYNC_STATE_ONLY device linksSaravana Kannan1-1/+2
commit f729a592adb6760013c3e48622a5bf256b992452 upstream. SYNC_STATE_ONLY device links intentionally allow cycles because cyclic sync_state() dependencies are valid and necessary. However a SYNC_STATE_ONLY device link where the consumer and the supplier are the same device is pointless because the device link would be deleted as soon as the device probes (because it's also the consumer) and won't affect when the sync_state() callback is called. It's a waste of CPU cycles and memory to create this device link. So reject any attempts to create such a device link. Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag") Cc: stable <stable@vger.kernel.org> Reported-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210929190549.860541-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20drivers: bus: simple-pm-bus: Add support for probing simple bus only devicesSaravana Kannan1-1/+38
commit 98e96cf80045a383fcc47c58dd4e87b3ae587b3e upstream. fw_devlink could end up creating device links for bus only devices. However, bus only devices don't get probed and can block probe() or sync_state() [1] call backs of other devices. To avoid this, probe these devices using the simple-pm-bus driver. However, there are instances of devices that are not simple buses (they get probed by their specific drivers) that also list the "simple-bus" (or other bus only compatible strings) in their compatible property to automatically populate their child devices. We still want these devices to get probed by their specific drivers. So, we make sure this driver only probes devices that are only buses. [1] - https://lore.kernel.org/lkml/CAPDyKFo9Bxremkb1dDrr4OcXSpE0keVze94Cm=zrkOVxHHxBmQ@mail.gmail.com/ Fixes: c442a0d18744 ("driver core: Set fw_devlink to "permissive" behavior by default") Cc: stable <stable@vger.kernel.org> Cc: Rob Herring <robh+dt@kernel.org> Tested-by: Saravana Kannan <saravanak@google.com> Tested-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210929000735.585237-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20iio: adc: aspeed: set driver data when adc probe.Billy Tsai1-0/+1
commit eb795cd97365a3d3d9da3926d234a7bc32a3bb15 upstream. Fix the issue when adc remove will get the null driver data. Fixed: commit 573803234e72 ("iio: Aspeed ADC") Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20210831071458.2334-2-billy_tsai@aspeedtech.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20nvmem: Fix shift-out-of-bound (UBSAN) with byte size cellsStephen Boyd1-1/+2
commit 5d388fa01fa6eb310ac023a363a6cb216d9d8fe9 upstream. If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0); will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long. UBSAN reports this problem: UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Fix it by making sure there are any bits to mask out. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Cc: Douglas Anderson <dianders@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013124511.18726-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20EDAC/armada-xp: Fix output of uncorrectable error counterHans Potsch1-1/+1
commit d9b7748ffc45250b4d7bcf22404383229bc495f5 upstream. The number of correctable errors is displayed as uncorrectable errors because the "SBE" error count is passed to both calls of edac_mc_handle_error(). Pass the correct uncorrectable error count to the second edac_mc_handle_error() call when logging uncorrectable errors. [ bp: Massage commit message. ] Fixes: 7f6998a41257 ("ARM: 8888/1: EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC") Signed-off-by: Hans Potsch <hans.potsch@nokia.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20211006121332.58788-1-hans.potsch@nokia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20virtio: write back F_VERSION_1 before validateHalil Pasic1-0/+11
commit 2f9a174f918e29608564c7a4e8329893ab604fb4 upstream. The virtio specification virtio-v1.1-cs01 states: "Transitional devices MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not been acknowledged by the driver." This is exactly what QEMU as of 6.1 has done relying solely on VIRTIO_F_VERSION_1 for detecting that. However, the specification also says: "... the driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device ..." before setting FEATURES_OK. In that case, any transitional device relying solely on VIRTIO_F_VERSION_1 for detecting legacy drivers will return data in legacy format. In particular, this implies that it is in big endian format for big endian guests. This naturally confuses the driver which expects little endian in the modern mode. It is probably a good idea to amend the spec to clarify that VIRTIO_F_VERSION_1 can only be relied on after the feature negotiation is complete. Before validate callback existed, config space was only read after FEATURES_OK. However, we already have two regressions, so let's address this here as well. The regressions affect the VIRTIO_NET_F_MTU feature of virtio-net and the VIRTIO_BLK_F_BLK_SIZE feature of virtio-blk for BE guests when virtio 1.0 is used on both sides. The latter renders virtio-blk unusable with DASD backing, because things simply don't work with the default. See Fixes tags for relevant commits. For QEMU, we can work around the issue by writing out the feature bits with VIRTIO_F_VERSION_1 bit set. We (ab)use the finalize_features config op for this. This isn't enough to address all vhost devices since these do not get the features until FEATURES_OK, however it looks like the affected devices actually never handled the endianness for legacy mode correctly, so at least that's not a regression. No devices except virtio net and virtio blk seem to be affected. Long term the right thing to do is to fix the hypervisors. Cc: <stable@vger.kernel.org> #v4.11 Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config space") Fixes: fe36cbe0671e ("virtio_net: clear MTU when out of range") Reported-by: markver@us.ibm.com Reviewed-by: Cornelia Huck <cohuck@redhat.com> Link: https://lore.kernel.org/r/20211011053921.1198936-1-pasic@linux.ibm.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20misc: fastrpc: Add missing lock before accessing find_vma()Srinivas Kandagatla1-0/+2
commit f9a470db2736b01538ad193c316eb3f26be37d58 upstream. fastrpc driver is using find_vma() without any protection, as a result we see below warning due to recent patch 5b78ed24e8ec ("mm/pagemap: add mmap_assert_locked() annotations to find_vma*()") which added mmap_assert_locked() in find_vma() function. This bug went un-noticed in previous versions. Fix this issue by adding required protection while calling find_vma(). CPU: 0 PID: 209746 Comm: benchmark_model Not tainted 5.15.0-rc2-00445-ge14fe2bf817a-dirty #969 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : find_vma+0x64/0xd0 lr : find_vma+0x60/0xd0 sp : ffff8000158ebc40 ... Call trace: find_vma+0x64/0xd0 fastrpc_internal_invoke+0x570/0xda8 fastrpc_device_ioctl+0x3e0/0x928 __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.3+0x70/0xf8 do_el0_svc+0x24/0x88 el0_svc+0x3c/0x138 el0t_64_sync_handler+0x90/0xb8 el0t_64_sync+0x180/0x184 Fixes: 80f3afd72bd4 ("misc: fastrpc: consider address offset before sending to DSP") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210922154326.8927-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20USB: serial: option: add prod. id for Quectel EG91Tomaz Solc1-0/+4
commit c184accc4a42c7872dc8e8d0fc97a740dc61fe24 upstream. Adding support for Quectel EG91 LTE module. The interface layout is same as for EG95. usb-devices output: T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0191 Rev=03.18 S: Manufacturer=Android S: Product=Android C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan Interfaces: 0: Diag 1: GNSS 2: AT-command interface/modem 3: Modem 4: QMI Signed-off-by: Tomaz Solc <tomaz.solc@tablix.org> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20USB: serial: option: add Telit LE910Cx composition 0x1204Daniele Palmas1-0/+2
commit f5a8a07edafed8bede17a95ef8940fe3a57a77d5 upstream. Add the following Telit LE910Cx composition: 0x1204: tty, adb, mbim, tty, tty, tty, tty Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20211004105655.8515-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20USB: serial: option: add Quectel EC200S-CN module supportYu-Tung Chang1-0/+2
commit 2263eb7370060bdb0013bc14e1a7c9bf33617a55 upstream. Add usb product id of the Quectel EC200S-CN module. usb-devices output for 0x6002: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=6002 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber=0000 C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Signed-off-by: Yu-Tung Chang <mtwget@gmail.com> Link: https://lore.kernel.org/r/20210930021112.330396-1-mtwget@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20USB: serial: qcserial: add EM9191 QDL supportAleksander Morgado1-0/+1
commit 11c52d250b34a0862edc29db03fbec23b30db6da upstream. When the module boots into QDL download mode it exposes the 1199:90d2 ids, which can be mapped to the qcserial driver, and used to run firmware upgrades (e.g. with the qmi-firmware-update program). T: Bus=01 Lev=03 Prnt=08 Port=03 Cnt=01 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1199 ProdID=90d2 Rev=00.00 S: Manufacturer=Sierra Wireless, Incorporated S: Product=Sierra Wireless EM9191 S: SerialNumber=8W0382004102A109 C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=2mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=qcserial Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20Input: xpad - add support for another USB ID of Nacon GC-100Michael Cullen1-0/+2
commit 3378a07daa6cdd11e042797454c706d1c69f9ca6 upstream. The Nacon GX100XF is already mapped, but it seems there is a Nacon GC-100 (identified as NC5136Wht PCGC-100WHITE though I believe other colours exist) with a different USB ID when in XInput mode. Signed-off-by: Michael Cullen <michael@michaelcullen.name> Link: https://lore.kernel.org/r/20211015192051.5196-1-michael@michaelcullen.name Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20usb: musb: dsps: Fix the probe error pathMiquel Raynal1-1/+3
commit c2115b2b16421d93d4993f3fe4c520e91d6fe801 upstream. Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb") has inverted the calls to dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without updating correctly the error path. dsps_create_musb_pdev() allocates and registers a new platform device which must be unregistered and freed with platform_device_unregister(), and this is missing upon dsps_setup_optional_vbus_irq() error. While on the master branch it seems not to trigger any issue, I observed a kernel crash because of a NULL pointer dereference with a v5.10.70 stable kernel where the patch mentioned above was backported. With this kernel version, -EPROBE_DEFER is returned the first time dsps_setup_optional_vbus_irq() is called which triggers the probe to error out without unregistering the platform device. Unfortunately, on the Beagle Bone Black Wireless, the platform device still living in the system is being used by the USB Ethernet gadget driver, which during the boot phase triggers the crash. My limited knowledge of the musb world prevents me to revert this commit which was sent to silence a robot warning which, as far as I understand, does not make sense. The goal of this patch was to prevent an IRQ to fire before the platform device being registered. I think this cannot ever happen due to the fact that enabling the interrupts is done by the ->enable() callback of the platform musb device, and this platform device must be already registered in order for the core or any other user to use this callback. Hence, I decided to fix the error path, which might prevent future errors on mainline kernels while also fixing older ones. Fixes: 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@boot