aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-11-25RDMA/cxgb4: Use non-atomic bitmap functions when possibleChristophe JAILLET1-2/+2
The accesses to the 'alloc->table' bitmap are protected by the 'alloc->lock' spinlock, so no concurrent accesses can happen. So prefer the non-atomic '__[set|clear]_bit()' functions to save a few cycles. Link: https://lore.kernel.org/r/0c1c4505ca32f5ba4126e3e324041da191513ef2.1637789139.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25RDMA/cxgb4: Use bitmap_set() when applicableChristophe JAILLET1-4/+1
The 'alloc->table' bitmap has just been allocated, so this is safe to use the faster and non-atomic 'bitmap_set()' function. There is no need to hand-write it. Link: https://lore.kernel.org/r/fd978b837935ed04863ffecfd495c4601a986df6.1637789139.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25RDMA/cxgb4: Use bitmap_zalloc() when applicableChristophe JAILLET1-5/+3
Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Using the 'zalloc' version of the allocator also saves a now useless 'bitmap_zero()' call. Also change the corresponding 'kfree()' into 'bitmap_free()' to keep consistency. While at it, remove an extra space in a statement just a few lines above. Link: https://lore.kernel.org/r/e396c4aa16cd8945d43877570a8f6d926cea555a.1637789139.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25IB/mthca: Use non-atomic bitmap functions when possible in 'mthca_mr.c'Christophe JAILLET1-5/+5
In 'mthca_buddy_init()', the 'buddy->bits[n]' bitmap has just been allocated, so no concurrent accesses can occur. The other accesses to the 'buddy->bits[n]' bitmap are protected by the 'buddy->lock' spinlock, so no concurrent accesses can occur. So prefer the non-atomic '__[set|clear]_bit()' functions to save a few cycles. Link: https://lore.kernel.org/r/a19b88ccdbc03972fd97306b998731814283041f.1637785902.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25IB/mthca: Use non-atomic bitmap functions when possible in 'mthca_allocator.c'Christophe JAILLET1-2/+2
The accesses to the 'alloc->table' bitmap are protected by the 'alloc->lock' spinlock, so no concurrent accesses can happen. So prefer the non-atomic '__[set|clear]_bit()' functions to save a few cycles. Link: https://lore.kernel.org/r/5f909ca1284fa4d2cf13952b08b9e303b656c968.1637785902.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25IB/mthca: Use bitmap_set() when applicableChristophe JAILLET1-4/+1
The 'alloc->table' bitmap has just been allocated, so this is safe to use the faster and non-atomic 'bitmap_set()' function. There is no need to hand-write it. Link: https://lore.kernel.org/r/f1bd33f6ea6c8ad519a222db6e9aa17c55610557.1637785902.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25IB/mthca: Use bitmap_zalloc() when applicableChristophe JAILLET2-11/+7
Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Using the 'zalloc' version of the allocator also saves a now useless 'bitmap_zero()' call. Also change the corresponding 'kfree()' into 'bitmap_free()' to keep consistency. Link: https://lore.kernel.org/r/ea9031e28f453bc179033740f66f0c19293fcf0b.1637785902.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25serial: 8250: replace snprintf in show functions with sysfs_emitJing Yao1-1/+1
coccicheck complains about the use of snprintf() in sysfs show functions: WARNING use scnprintf or sprintf Use sysfs_emit instead of scnprintf or sprintf makes more sense. Reported-by: Zeal Robot <zealci@zte.com.cn> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Jing Yao <yao.jing2@zte.com.cn> Link: https://lore.kernel.org/r/20211104114754.30983-1-yao.jing2@zte.com.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25Revert "tty: serial: fsl_lpuart: drop earlycon entry for i.MX8QXP"Alexander Stein1-0/+1
Revert commit b4b844930f27 ("tty: serial: fsl_lpuart: drop earlycon entry for i.MX8QXP"), because this breaks earlycon support on imx8qm/imx8qxp. While it is true that for earlycon there is no difference between i.MX8QXP and i.MX7ULP (for now at least), there are differences regarding clocks and fixups for wakeup support. For that reason it was deemed unacceptable to add the imx7ulp compatible to device tree in order to get earlycon working again. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20211124073109.805088-1-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25serial: tegra: Change lower tolerance baud rate limit for tegra20 and tegra30Patrik John1-2/+2
The current implementation uses 0 as lower limit for the baud rate tolerance for tegra20 and tegra30 chips which causes isses on UART initialization as soon as baud rate clock is lower than required even when within the standard UART tolerance of +/- 4%. This fix aligns the implementation with the initial commit description of +/- 4% tolerance for tegra chips other than tegra186 and tegra194. Fixes: d781ec21bae6 ("serial: tegra: report clk rate errors") Cc: stable <stable@vger.kernel.org> Signed-off-by: Patrik John <patrik.john@u-blox.com> Link: https://lore.kernel.org/r/sig.19614244f8.20211123132737.88341-1-patrik.john@u-blox.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25serial: liteuart: relax compile-test dependenciesJohan Hovold1-1/+1
The LITEX symbol is neither a build or runtime dependency for the liteuart serial driver. LITEX is selected by the "LiteX SoC Controller" driver, which does a probe-time register-access sanity check and panics if the SoC has not been configured correctly. That driver's Kconfig entry asserts that any LiteX driver using the LiteX register accessors should depend on LITEX, but currently only the serial driver complies. Relax this LITEX "dependency" in order to make it easier to compile test the driver. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211117100512.5058-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25serial: liteuart: fix minor-number leak on probe errorsJohan Hovold1-3/+14
Make sure to release the allocated minor number before returning on probe errors. Fixes: 1da81e5562fa ("drivers/tty/serial: add LiteUART driver") Cc: stable@vger.kernel.org # 5.11 Cc: Filip Kokosinski <fkokosinski@antmicro.com> Cc: Mateusz Holenko <mholenko@antmicro.com> Reviewed-by: Stafford Horne <shorne@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211117100512.5058-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25serial: liteuart: fix use-after-free and memleak on unbindJohan Hovold1-0/+1
Deregister the port when unbinding the driver to prevent it from being used after releasing the driver data and leaking memory allocated by serial core. Fixes: 1da81e5562fa ("drivers/tty/serial: add LiteUART driver") Cc: stable@vger.kernel.org # 5.11 Cc: Filip Kokosinski <fkokosinski@antmicro.com> Cc: Mateusz Holenko <mholenko@antmicro.com> Reviewed-by: Stafford Horne <shorne@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211117100512.5058-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25serial: liteuart: Fix NULL pointer dereference in ->remove()Ilia Sergachev1-0/+2
drvdata has to be set in _probe() - otherwise platform_get_drvdata() causes null pointer dereference BUG in _remove(). Fixes: 1da81e5562fa ("drivers/tty/serial: add LiteUART driver") Cc: stable <stable@vger.kernel.org> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Ilia Sergachev <silia@ethz.ch> Link: https://lore.kernel.org/r/20211115224944.23f8c12b@dtkw Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25vgacon: Propagate console boot parameters before calling `vc_resize'Maciej W. Rozycki1-5/+9
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>
2021-11-25tty: serial: msm_serial: Deactivate RX DMA for polling supportSven Eckelmann1-0/+3
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>
2021-11-25serial: pl011: Add ACPI SBSA UART match idPierre Gondois1-0/+1
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>
2021-11-25serial: core: fix transmit-buffer reset and memleakJohan Hovold1-1/+12
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>
2021-11-25RDMA/hns: Do not destroy QP resources in the hw resetting phaseYangyang Li1-1/+11
When hns_roce_v2_destroy_qp() is called, the brief calling process of the driver is as follows: ...... hns_roce_v2_destroy_qp hns_roce_v2_qp_modify hns_roce_cmd_mbox hns_roce_qp_destroy If hns_roce_cmd_mbox() detects that the hardware is being reset during the execution of the hns_roce_cmd_mbox(), the driver will not be able to get the return value from the hardware (the firmware cannot respond to the driver's mailbox during the hardware reset phase). The driver needs to wait for the hardware reset to complete before continuing to execute hns_roce_qp_destroy(), otherwise it may happen that the driver releases the resources but the hardware is still accessing. In order to fix this problem, HNS RoCE needs to add a piece of code to wait for the hardware reset to complete. The original interface get_hw_reset_stat() is the instantaneous state of the hardware reset, which cannot accurately reflect whether the hardware reset is completed, so it needs to be replaced with the ae_dev_reset_cnt interface. The sign that the hardware reset is complete is that the return value of the ae_dev_reset_cnt interface is greater than the original value reset_cnt recorded by the driver. Fixes: 6a04aed6afae ("RDMA/hns: Fix the chip hanging caused by sending mailbox&CMQ during reset") Link: https://lore.kernel.org/r/20211123142402.26936-1-liangwenpeng@huawei.com Signed-off-by: Yangyang Li <liyangyang20@huawei.com> Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25RDMA/hns: Do not halt commands during reset until laterYangyang Li1-2/+0
is_reset is used to indicate whether the hardware starts to reset. When hns_roce_hw_v2_reset_notify_down() is called, the hardware has not yet started to reset. If is_reset is set at this time, all mailbox operations of resource destroy actions will be intercepted by driver. When the driver cleans up resources, but the hardware is still accessed, the following errors will appear: arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received: arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000350100000010 arm-smmu-v3 arm-smmu-v3.2.auto: 0x000002088000003f arm-smmu-v3 arm-smmu-v3.2.auto: 0x00000000a50e0800 arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received: arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000350100000010 arm-smmu-v3 arm-smmu-v3.2.auto: 0x000002088000043e arm-smmu-v3 arm-smmu-v3.2.auto: 0x00000000a50a0800 arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received: arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000350100000010 arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000020880000436 arm-smmu-v3 arm-smmu-v3.2.auto: 0x00000000a50a0880 arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received: arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000350100000010 arm-smmu-v3 arm-smmu-v3.2.auto: 0x000002088000043a arm-smmu-v3 arm-smmu-v3.2.auto: 0x00000000a50e0840 hns3 0000:35:00.0: INT status: CMDQ(0x0) HW errors(0x0) other(0x0) arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 hns3 0000:35:00.0: received unknown or unhandled event of vector0 arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received: arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000350100000010 {34}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 7 is_reset will be set correctly in check_aedev_reset_status(), so the setting in hns_roce_hw_v2_reset_notify_down() should be deleted. Fixes: 726be12f5ca0 ("RDMA/hns: Set reset flag when hw resetting") Link: https://lore.kernel.org/r/20211123084809.37318-1-liangwenpeng@huawei.com Signed-off-by: Yangyang Li <liyangyang20@huawei.com> Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25RDMA/mlx5: Fix releasing unallocated memory in dereg MR flowAlaa Hleihel2-17/+15
For the case of IB_MR_TYPE_DM the mr does doesn't have a umem, even though it is a user MR. This causes function mlx5_free_priv_descs() to think that it is a kernel MR, leading to wrongly accessing mr->descs that will get wrong values in the union which leads to attempt to release resources that were not allocated in the first place. For example: DMA-API: mlx5_core 0000:08:00.1: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=0 bytes] WARNING: CPU: 8 PID: 1021 at kernel/dma/debug.c:961 check_unmap+0x54f/0x8b0 RIP: 0010:check_unmap+0x54f/0x8b0 Call Trace: debug_dma_unmap_page+0x57/0x60 mlx5_free_priv_descs+0x57/0x70 [mlx5_ib] mlx5_ib_dereg_mr+0x1fb/0x3d0 [mlx5_ib] ib_dereg_mr_user+0x60/0x140 [ib_core] uverbs_destroy_uobject+0x59/0x210 [ib_uverbs] uobj_destroy+0x3f/0x80 [ib_uverbs] ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs] ? uverbs_finalize_object+0x50/0x50 [ib_uverbs] ? lock_acquire+0xc4/0x2e0 ? lock_acquired+0x12/0x380 ? lock_acquire+0xc4/0x2e0 ? lock_acquire+0xc4/0x2e0 ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs] ? lock_release+0x28a/0x400 ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs] ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs] __x64_sys_ioctl+0x7f/0xb0 do_syscall_64+0x38/0x90 Fix it by reorganizing the dereg flow and mlx5_ib_mr structure: - Move the ib_umem field into the user MRs structure in the union as it's applicable only there. - Function mlx5_ib_dereg_mr() will now call mlx5_free_priv_descs() only in case there isn't udata, which indicates that this isn't a user MR. Fixes: f18ec4223117 ("RDMA/mlx5: Use a union inside mlx5_ib_mr") Link: https://lore.kernel.org/r/66bb1dd253c1fd7ceaa9fc411061eefa457b86fb.1637581144.git.leonro@nvidia.com Signed-off-by: Alaa Hleihel <alaa@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25RDMA: Fix use-after-free in rxe_queue_cleanupPavel Skripkin1-0/+1
On error handling path in rxe_qp_from_init() qp->sq.queue is freed and then rxe_create_qp() will drop last reference to this object. qp clean up function will try to free this queue one time and it causes UAF bug. Fix it by zeroing queue pointer after freeing queue in rxe_qp_from_init(). Fixes: 514aee660df4 ("RDMA: Globally allocate and release QP memory") Link: https://lore.kernel.org/r/20211121202239.3129-1-paskripkin@gmail.com Reported-by: syzbot+aab53008a5adf26abe91@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Reviewed-by: Zhu Yanjun <zyjzyj2000@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-25irqchip/mips-gic: Use bitfield helpersGeert Uytterhoeven1-2/+2
Use the FIELD_GET() helper, instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/all/74f9d126961a90d3e311b92a54870eaac5b3ae57.1637593297.git.geert+renesas@glider.be
2021-11-25irqchip/aspeed-scu: Replace update_bits with write_bits.Billy Tsai1-2/+2
The interrupt status bits are cleared by writing 1, we should force a write to clear the interrupt without checking if the value has changed. Fixes: 04f605906ff0 ("irqchip: Add Aspeed SCU interrupt controller") Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211124094348.11621-1-billy_tsai@aspeedtech.com Cc: stable@vger.kernel.org
2021-11-25irqchip/armada-370-xp: Fix support for Multi-MSI interruptsPali Rohár1-9/+5
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
2021-11-25irqchip/armada-370-xp: Fix return value of armada_370_xp_msi_alloc()Pali Rohár1-1/+1
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
2021-11-25staging: r8188eu: remove the _cancel_workitem_sync wrapperMartin Kaiser3-6/+2
Remove the _cancel_workitem_sync wrapper and call cancel_work_sync directly. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20211125162513.25039-4-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: remove the _init_workitem wrapperMartin Kaiser3-7/+2
Remove the _init_workitem wrapper and call INIT_WORK directly. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20211125162513.25039-3-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: remove the _set_workitem wrapperMartin Kaiser2-6/+1
Remove the _set_workitem wrapper and call schedule_work directly. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20211125162513.25039-2-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: hal data's board type is unusedMartin Kaiser3-16/+0
BoardType in struct hal_data_8188e is not used. Remove the variable and the function to extract the board type from the efuses. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20211125151436.5895-7-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: remove unused eeprom definesMartin Kaiser1-48/+0
Remove a number of eeprom defines which are not used. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20211125151436.5895-6-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: do not extract eeprom version from the fusesMartin Kaiser4-18/+0
EEPROMVersion in struct hal_data_8188e is not used. There's no need to parse the fuses and extract the version. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20211125151436.5895-5-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: remove unused efuse definesMartin Kaiser2-25/+0
This patch removes some unused defines, macros and include statements related to efuses. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20211125151436.5895-4-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: efuse_WordEnableDataRead is not usedMartin Kaiser2-39/+0
The efuse_WordEnableDataRead function is not used and can be removed. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20211125151436.5895-3-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: Efuse_CalculateWordCnts is not usedMartin Kaiser2-17/+0
Remove the Efuse_CalculateWordCnts function, which is not used. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20211125151436.5895-2-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: use max() and min() macrosVihas Mak1-8/+4
use max() and min() macros to fix following cocci warnings: drivers/staging/r8188eu/core/rtw_wlan_util.c:719: WARNING opportunity for min() drivers/staging/r8188eu/core/rtw_wlan_util.c:724: WARNING opportunity for max() Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Vihas Mak <makvihas@gmail.com> Link: https://lore.kernel.org/r/20211124190436.251312-1-makvihas@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: vt6655: refactor camelcase byMaxPwrLevel to max_pwr_levelAlberto Merciai2-6/+6
Replace hungarian notated variable "byMaxPwrLevel" with "max_pwr_level" compliant with linux kernel coding style. Signed-off-by: Alberto Merciai <alb3rt0.m3rciai@gmail.com> Link: https://lore.kernel.org/r/20211119081656.GA12982@alb3rt0-VirtualBox Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: vt6655: rename variable bHWRadioOffAlberto Merciai2-4/+4
Replace camelcase hungarian notated variable "bHWRadioOff" into linux kernel coding style equivalent variable "hw_radio_off". Tested-by: Tommaso Merciai <tomm.merciai@gmail.com> Acked-by: Tommaso Merciai <tommaso.merciai@gmail.com> Acked-by: Tommaso Merciai <tomm.merciai@gmail.com> Signed-off-by: Alberto Merciai <alb3rt0.m3rciai@gmail.com> Link: https://lore.kernel.org/r/20211121112000.632456-1-alb3rt0.m3rciai@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: vchiq_core: remove superfluous static_assert statementGaston Gonzalez1-2/+0
After removing the BITSET_T typedef in commit d8a364820e01 ("staging: vchiq_core: get rid of typedef") the static_assert statement becomes superfluous as now we are checking if the size of the u32 type is 4 bytes. Hence, just remove the static_assert statement. Suggested-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Gaston Gonzalez <gascoar@gmail.com> Link: https://lore.kernel.org/r/20211122130926.342128-1-gascoar@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: remove rf_type from HT_caps_handler()Michael Straube1-9/+2
rf_type is always RF_1T1R. Remove it from HT_caps_handler() and remove related dead code. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20211119122635.28435-3-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: remove rf_type from add_RATid()Michael Straube1-6/+1
rf_type is always RF_1T1R. Remove it from add_RATid() and remove related dead code. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20211119122635.28435-2-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: remove rf_type from rtw_mcs_rate()Michael Straube3-66/+23
rf_type is always RF_1T1R. Remove it from rtw_mcs_rate() and remove related dead code. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20211118215052.5215-1-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: r8188eu: Remove support for devices with 8188FU chipset (0bda:f179)Candy Febriyanto1-1/+0
The new r8188eu driver doesn't actually support devices with vendor ID 0bda and product ID f179[0][1][2], remove the ID so owners of these devices don't have to blacklist the staging driver. [0] https://github.com/lwfinger/rtl8188eu/issues/366#issuecomment-888511731 [1] https://github.com/lwfinger/rtl8188eu/issues/385 [2] https://github.com/lwfinger/rtl8188eu/issues/385#issuecomment-973013539 Cc: Larry Finger <Larry.Finger@lwfinger.net> CC: Phillip Potter <phil@philpotter.co.uk> Signed-off-by: Candy Febriyanto <cfebriyanto@gmail.com> Link: https://lore.kernel.org/r/YZaBTq9vlMaJDFz2@mainframe.localdomain Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: unisys: visornic: removed a blank line at the end of functionLiu Junqi1-1/+0
Removed a blank line at the end of function to clear checkpatch warning and make it more like typical coding style. Signed-off-by: Liu Junqi <liujunqi@pku.edu.cn> Link: https://lore.kernel.org/r/20211125044729.594727-3-liujunqi@pku.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: unisys: visornic: reindent to avoid '(' at the end of lineLiu Junqi1-3/+2
A change to make the code more like typical coding style. Signed-off-by: Liu Junqi <liujunqi@pku.edu.cn> Link: https://lore.kernel.org/r/20211125044729.594727-2-liujunqi@pku.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: unisys: visornic: fixed a typo cant -> can'tLiu Junqi1-1/+1
Fixed a typo: cant -> can't in visornic_main.c. Signed-off-by: Liu Junqi <liujunqi@pku.edu.cn> Link: https://lore.kernel.org/r/20211125044729.594727-1-liujunqi@pku.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25staging: unisys: visorhba: use tab to indent instead of whitespaceLiu Junqi1-1/+1
changed the whitespace to tab to comply with kernel coding style. Signed-off-by: Liu Junqi <liujunqi@pku.edu.cn> Link: https://lore.kernel.org/r/20211118033737.576775-1-liujunqi@pku.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25mdio: aspeed: Fix "Link is Down" issueDylan Hung1-0/+7
The issue happened randomly in runtime. The message "Link is Down" is popped but soon it recovered to "Link is Up". The "Link is Down" results from the incorrect read data for reading the PHY register via MDIO bus. The correct sequence for reading the data shall be: 1. fire the command 2. wait for command done (this step was missing) 3. wait for data idle 4. read data from data register Cc: stable@vger.kernel.org Fixes: f160e99462c6 ("net: phy: Add mdio-aspeed") Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Dylan Hung <dylan_hung@aspeedtech.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20211125024432.15809-1-dylan_hung@aspeedtech.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-25igb: fix netpoll exit with trafficJesse Brandeburg1-1/+1
Oleksandr brought a bug report where netpoll causes trace messages in the log on igb. Danielle brought this back up as still occurring, so we'll try again. [22038.710800] ------------[ cut here ]------------ [22038.710801] igb_poll+0x0/0x1440 [igb] exceeded budget in poll [22038.710802] WARNING: CPU: 12 PID: 40362 at net/core/netpoll.c:155 netpoll_poll_dev+0x18a/0x1a0 As Alex suggested, change the driver to return work_done at the exit of napi_poll, which should be safe to do in this driver because it is not polling multiple queues in this single napi context (multiple queues attached to one MSI-X vector). Several other drivers contain the same simple sequence, so I hope this will not create new problems. Fixes: 16eb8815c235 ("igb: Refactor clean_rx_irq to reduce overhead and improve performance") Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name> Reported-by: Danielle Ratson <danieller@nvidia.com> Suggested-by: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Tested-by: Danielle Ratson <danieller@nvidia.com> Link: https://lore.kernel.org/r/20211123204000.1597971-1-jesse.brandeburg@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-25platform/x86: touchscreen_dmi: Add TrekStor SurfTab duo W1 touchscreen infoHans de Goede1-0/+18
The TrekStor SurfTab duo W1 (ST10432-10b) has a Goodix touchscreen which has its x-axis mirrored. Add a quirk to fix this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211124175125.250329-1-hdegoede@redhat.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.