[pull] master from torvalds:master#1352
Merged
pull[bot] merged 51 commits intoMu-L:masterfrom Oct 14, 2023
Merged
Conversation
Add HyperX controller support to xpad_device and xpad_table. Suggested-by: Chris Toledanes <chris.toledanes@hp.com> Reviewed-by: Carl Ng <carl.ng@hp.com> Signed-off-by: Max Nguyen <maxwell.nguyen@hp.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Link: https://lore.kernel.org/r/20230906231514.4291-1-hphyperxdev@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Like various other ASUS ExpertBook-s, the ASUS ExpertBook B1402CBA has an ACPI DSDT table that describes IRQ 1 as ActiveLow while the kernel overrides it to EdgeHigh. This prevents the keyboard from working. To fix this issue, add this laptop to the skip_override_table so that the kernel does not override IRQ 1. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217901 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
kselftests fails to build because the mm/testcases subdirectory is not created and then the compiler fails to output the binary there. So fix this by simply removing this subdirectory which is not very useful. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20230915100113.13131-1-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
RISC-V software breakpoint trap handlers are used for {k,u}probes.
When trapping from kernelmode, only the kernelmode handlers should be
considered. Vice versa, only usermode handlers for usermode
traps. This is not the case on RISC-V, which can trigger a bug if a
userspace process uses uprobes, and a WARN() is triggered from
kernelmode (which is implemented via {c.,}ebreak).
The kernel will trap on the kernelmode {c.,}ebreak, look for uprobes
handlers, realize incorrectly that uprobes need to be handled, and
exit the trap handler early. The trap returns to re-executing the
{c.,}ebreak, and enter an infinite trap-loop.
The issue was found running the BPF selftest [1].
Fix this issue by only considering the swbp/ss handlers for
kernel/usermode respectively. Also, move CONFIG ifdeffery from traps.c
to the asm/{k,u}probes.h headers.
Note that linux/uprobes.h only include asm/uprobes.h if CONFIG_UPROBES
is defined, which is why asm/uprobes.h needs to be unconditionally
included in traps.c
Link: https://lore.kernel.org/linux-riscv/87v8d19aun.fsf@all.your.base.are.belong.to.us/ # [1]
Fixes: 7478408 ("riscv: Add uprobes supported")
Reviewed-by: Guo Ren <guoren@kernel.org>
Reviewed-by: Nam Cao <namcaov@gmail.com>
Tested-by: Puranjay Mohan <puranjay12@gmail.com>
Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://lore.kernel.org/r/20230912065619.62020-1-bjorn@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
SoundWire has provisions for a simple callback for the IRQ handling so has no hard dependency on IRQ_DOMAIN, but the recent addition of IRQ handling was causing builds without IRQ_DOMAIN to fail. Resolve this by moving the IRQ handling into its own file and only add it to the build when IRQ_DOMAIN is included in the kernel. Fixes: 12a9512 ("soundwire: bus: Allow SoundWire peripherals to register IRQ handlers") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309150522.MoKeF4jx-lkp@intel.com/ Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230920160401.854052-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Added GPE quirk entry for the HP Pavilion Gaming 15-dk1xxx. There is a quirk entry for 2 15-c..... laptops, this is for a new version which has 15-dk1xxx as identifier. This fixes the LID switch and rfkill and brightness hotkeys not working. Closes: systemd/systemd#28942 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Compile the andes errata with cflags set to " -mcmodel=medany" when CONFIG_RISCV_ALTERNATIVE_EARLY is enabled. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309111311.8tcq3KVc-lkp@intel.com/ Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20230925153844.26820-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
In eDMAv3, clearing 'DONE' bit (bit 30) of CHn_CSR is required when enabling scatter-gather (SG). eDMAv4 does not require this change. Cc: stable@vger.kernel.org Fixes: 72f5801 ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20230921144652.3259813-1-Frank.Li@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
xlnx,bus-width is a required property. In yaml conversion somehow it got missed out. Bring it back and mention it in required list. Also add Harini and myself to the maintainer list. Fixes: 5a04982 ("dt-bindings: dmaengine: zynqmp_dma: convert to yaml") Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Michael Tretter <m.tretter@pengutronix.de> Reviewed-by: Peter Korsgaard <peter@korsgaard.com> Link: https://lore.kernel.org/r/1695216326-3841352-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
When attempting to start DMA for the second time using fsl_edma3_enable_request(), channel never start. CHn_MUX must have a unique value when selecting a peripheral slot in the channel mux configuration. The only value that may overlap is source 0. If there is an attempt to write a mux configuration value that is already consumed by another channel, a mux configuration of 0 (SRC = 0) will be written. Check CHn_MUX before writing in fsl_edma3_enable_request(). Fixes: 72f5801 ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20230823182635.2618118-1-Frank.Li@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
In idxd_cmd_exec(), wait_event_lock_irq() explicitly calls
spin_unlock_irq()/spin_lock_irq(). If the interrupt is on before entering
wait_event_lock_irq(), it will become off status after
wait_event_lock_irq() is called. Later, wait_for_completion() may go to
sleep but irq is disabled. The scenario is warned in might_sleep().
Fix it by using spin_lock_irqsave() instead of the primitive spin_lock()
to save the irq status before entering wait_event_lock_irq() and using
spin_unlock_irqrestore() instead of the primitive spin_unlock() to restore
the irq status before entering wait_for_completion().
Before the change:
idxd_cmd_exec() {
interrupt is on
spin_lock() // interrupt is on
wait_event_lock_irq()
spin_unlock_irq() // interrupt is enabled
...
spin_lock_irq() // interrupt is disabled
spin_unlock() // interrupt is still disabled
wait_for_completion() // report "BUG: sleeping function
// called from invalid context...
// in_atomic() irqs_disabled()"
}
After applying spin_lock_irqsave():
idxd_cmd_exec() {
interrupt is on
spin_lock_irqsave() // save the on state
// interrupt is disabled
wait_event_lock_irq()
spin_unlock_irq() // interrupt is enabled
...
spin_lock_irq() // interrupt is disabled
spin_unlock_irqrestore() // interrupt is restored to on
wait_for_completion() // No Call trace
}
Fixes: f9f4082 ("dmaengine: idxd: remove interrupt disable for cmd_lock")
Signed-off-by: Rex Zhang <rex.zhang@intel.com>
Signed-off-by: Lijun Pan <lijun.pan@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Fenghua Yu <fenghua.yu@intel.com>
Link: https://lore.kernel.org/r/20230916060619.3744220-1-rex.zhang@intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The synchronize_irq(c->irq) will not return until the IRQ handler
mtk_uart_apdma_irq_handler() is completed. If the synchronize_irq()
holds a spin_lock and waits the IRQ handler to complete, but the
IRQ handler also needs the same spin_lock. The deadlock will happen.
The process is shown below:
cpu0 cpu1
mtk_uart_apdma_device_pause() | mtk_uart_apdma_irq_handler()
spin_lock_irqsave() |
| spin_lock_irqsave()
//hold the lock to wait |
synchronize_irq() |
This patch reorders the synchronize_irq(c->irq) outside the spin_lock
in order to mitigate the bug.
Fixes: 9135408 ("dmaengine: mediatek: Add MediaTek UART APDMA support")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Reviewed-by: Eugen Hristev <eugen.hristev@collabora.com>
Link: https://lore.kernel.org/r/20230806032511.45263-1-duoming@zju.edu.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org>
In the initial boot stage the integrated keyboard of Fujitsu Lifebook E5411 refuses to work and it's not possible to type for example a dm-crypt passphrase without the help of an external keyboard. i8042.nomux kernel parameter resolves this issue but using that a PS/2 mouse is detected. This input device is unused even when the i2c-hid-acpi kernel module is blacklisted making the integrated ELAN touchpad (04F3:308A) not working at all. Since the integrated touchpad is managed by the i2c_designware input driver in the Linux kernel and you can't find a PS/2 mouse port on the computer I think it's safe to not use the PS/2 mouse port at all. Signed-off-by: Szilard Fabian <szfabian@bluemarch.art> Link: https://lore.kernel.org/r/20231004011749.101789-1-szfabian@bluemarch.art Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
…io_int_idx == 0 case Add a special case for gpio_count == 1 && gpio_int_idx == 0 to goodix_add_acpi_gpio_mappings(). It seems that on newer x86/ACPI devices the reset and irq GPIOs are no longer listed as GPIO resources instead there is only 1 GpioInt resource and _PS0 does the whole reset sequence for us. This means that we must call acpi_device_fix_up_power() on these devices to ensure that the chip is reset before we try to use it. This part was already fixed in commit 3de93e6 ("Input: goodix - call acpi_device_fix_up_power() in some cases") by adding a call to acpi_device_fix_up_power() to the generic "Unexpected ACPI resources" catch all. But it turns out that this case on some hw needs some more special handling. Specifically the firmware may bootup with the IRQ pin in output mode. The reset sequence from ACPI _PS0 (executed by acpi_device_fix_up_power()) should put the pin in input mode, but the GPIO subsystem has cached the direction at bootup, causing request_irq() to fail due to gpiochip_lock_as_irq() failure: [ 9.119864] Goodix-TS i2c-GDIX1002:00: Unexpected ACPI resources: gpio_count 1, gpio_int_idx 0 [ 9.317443] Goodix-TS i2c-GDIX1002:00: ID 911, version: 1060 [ 9.321902] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-5/i2c-GDIX1002:00/input/input8 [ 9.327840] gpio gpiochip0: (INT3453:00): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ [ 9.327856] gpio gpiochip0: (INT3453:00): unable to lock HW IRQ 26 for IRQ [ 9.327861] genirq: Failed to request resources for GDIX1002:00 (irq 131) on irqchip intel-gpio [ 9.327912] Goodix-TS i2c-GDIX1002:00: request IRQ failed: -5 Fix this by adding a special case for gpio_count == 1 && gpio_int_idx == 0 which adds an ACPI GPIO lookup table for the int GPIO even though we cannot use it for reset purposes (as there is no reset GPIO). Adding the lookup will make the gpiod_int = gpiod_get(..., GPIOD_IN) call succeed, which will explicitly set the direction to input fixing the issue. Note this re-uses the acpi_goodix_int_first_gpios[] lookup table, since there is only 1 GPIO in the ACPI resources the reset entry in that lookup table will amount to a no-op. Reported-and-tested-by: Michael Smith <1973.mjsmith@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231003215144.69527-1-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. We fix it by calling pm_runtime_disable when error returns. Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/tencent_DD2D371DB5925B4B602B1E1D0A5FA88F1208@qq.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
chan->desc can be null, if transfer is terminated when resume is called, leading to a NULL pointer when retrieving the hwdesc. To avoid this case, check that chan->desc is not null and channel is disabled (transfer previously paused or terminated). Fixes: a4ffb13 ("dmaengine: Add STM32 MDMA driver") Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231004163531.2864160-1-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Current implementation relies on curr_hwdesc index. But to keep this index up to date, Block Transfer interrupt (BTIE) has to be enabled. If it is not, curr_hwdesc is not updated, and then residue is not reliable. Rely on Link Address Register instead. And disable BTIE interrupt in stm32_mdma_setup_xfer() because it is no more needed in case of _prep_slave_sg() to maintain curr_hwdesc up to date. It avoids extra interrupts and also ensures a reliable residue. These improvements are required for STM32 DCMI camera capture use case, which need STM32 DMA and MDMA chaining for good performance. Fixes: 6968743 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA") Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231004163531.2864160-2-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
CRQA flag is set by hardware when the channel request become active and the channel is enabled. It is cleared by hardware, when the channel request is completed. So when it is set, it means MDMA is transferring bytes. This information is useful in case of STM32 DMA and MDMA chaining, especially when the user pauses DMA before stopping it, to trig one last MDMA transfer to get the latest bytes of the SRAM buffer to the destination buffer. STM32 DCMI driver can then use this to know if the last MDMA transfer in case of chaining is done. Fixes: 6968743 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA") Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231004163531.2864160-3-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
…ining Current Target (CT) have to be reset when starting an MDMA chaining use case, as Double Buffer mode is activated. It ensures the DMA will start processing the first memory target (pointed with SxM0AR). Fixes: 7237951 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA") Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231004155024.2609531-1-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
In case of MDMA chaining, DMA is configured in Double-Buffer Mode (DBM) with two periods, but if transfer has been prepared with _prep_slave_sg(), the transfer is not marked cyclic (=!chan->desc->cyclic). However, as DBM is activated for MDMA chaining, residue computation must take into account cyclic constraints. With only two periods in MDMA chaining, and no update due to Transfer Complete interrupt masked, n_sg is always 0. If DMA current memory address (depending on SxCR.CT and SxM0AR/SxM1AR) does not correspond, it means n_sg should be increased. Then, the residue of the current period is the one read from SxNDTR and should not be overwritten with the full period length. Fixes: 7237951 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA") Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231004155024.2609531-2-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
…late() dma_get_slave_channel() increases client_count for all channels. It should only be called when a matched channel is found in fsl_edma3_xlate(). Move dma_get_slave_channel() after checking for a matched channel. Cc: stable@vger.kernel.org Fixes: 72f5801 ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20231004142911.838916-1-Frank.Li@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
When truncating the inode the MDS will acquire the xlock for the ifile Locker, which will revoke the 'Frwsxl' caps from the clients. But when the client just releases and flushes the 'Fw' caps to MDS, for exmaple, and once the MDS receives the caps flushing msg it just thought the revocation has finished. Then the MDS will continue truncating the inode and then issued the truncate notification to all the clients. While just before the clients receives the cap flushing ack they receive the truncation notification, the clients will detecte that the 'issued | dirty' is still holding the 'Fw' caps. Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/56693 Fixes: b0d7c22 ("ceph: introduce i_truncate_mutex") Signed-off-by: Xiubo Li <xiubli@redhat.com> Reviewed-by: Milind Changire <mchangir@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Before returning, function ceph_fname_to_usr() does a final IS_ERR() check
in 'dir':
if ((dir != fname->dir) && !IS_ERR(dir)) {...}
This check is unnecessary because, if the 'dir' variable has changed to
something other than 'fname->dir' (it's initial value), that error check has
been performed already and, if there was indeed an error, it would have
been returned immediately.
Besides, this useless IS_ERR() is also confusing static analysis tools.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202309282202.xZxGdvS3-lkp@intel.com/
Signed-off-by: Luis Henriques <lhenriques@suse.de>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Direct calls to ops->connect() can overwrite the address parameter when used in conjunction with BPF SOCK_ADDR hooks. Recent changes to kernel_connect() ensure that callers are insulated from such side effects. This patch wraps the direct call to ops->connect() with kernel_connect() to prevent unexpected changes to the address passed to ceph_tcp_connect(). This change was originally part of a larger patch targeting the net tree addressing all instances of unprotected calls to ops->connect() throughout the kernel, but this change was split up into several patches targeting various trees. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/20230821100007.559638-1-jrife@google.com/ Link: https://lore.kernel.org/netdev/9944248dba1bce861375fcce9de663934d933ba9.camel@redhat.com/ Fixes: d74bad4 ("bpf: Hooks for sys_connect") Signed-off-by: Jordan Rife <jrife@google.com> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
In this code "ret" is type long and "src_objlen" is unsigned int. The problem is that on 32bit systems, when we do the comparison signed longs are type promoted to unsigned int. So negative error codes from do_splice_direct() are treated as success instead of failure. Cc: stable@vger.kernel.org Fixes: 1b0c3b9 ("ceph: re-org copy_file_range and fix some error paths") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
…e_low_force_override[] The TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q are 3 GPU variants of a TongFang barebone design which is sold under various brand names. The ACPI IRQ override for the keyboard IRQ must be used on these AMD Zen laptops in order for the IRQ to work. Adjust the pcspecialist_laptop[] DMI match table for this: 1. Drop the sys-vendor match from the existing PCSpecialist Elimina Pro 16 entry for the GM6BGEQ (RTX3050 GPU) model so that it will also match the laptop when sold by other vendors such as hyperbook.pl. 2. Add board-name matches for the GM6BG5Q (RTX4050) and GM6B0Q (RTX4060) models. Note the .ident values of the dmi_system_id structs are left unset since these are not used. Suggested-by: August Wikerfors <git@augustwikerfors.se> Reported-by: Francesco <f.littarru@outlook.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217394 Link: https://laptopparts4less.frl/index.php?route=product/search&filter_name=GM6BG Link: https://hyperbook.pl/en/content/14-hyperbook-drivers Link: https://linux-hardware.org/?probe=bfa70344e3 Link: https://bbs.archlinuxcn.org/viewtopic.php?id=13313 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The clear TM function error log status was inverted. Fixes: 4693fad ("scsi: ufs: core: Log error handler activity") Signed-off-by: Peter Wang <peter.wang@mediatek.com> Link: https://lore.kernel.org/r/20231003022002.25578-1-peter.wang@mediatek.com Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Stanley Chu <stanley.chu@mediatek.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
…API is disabled Since the stream API is still experimental it is currently locked away behind the internal, default disabled, v4l2_subdev_enable_streams_api flag. Advertising V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled confuses userspace. E.g. it causes the following libcamera error: ERROR SimplePipeline simple.cpp:1497 Failed to reset routes for /dev/v4l-subdev1: Inappropriate ioctl for device Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled to avoid problems like this. Reported-by: Dennis Bonke <admin@dennisbonke.com> Fixes: 9a6b5bf ("media: add V4L2_SUBDEV_CAP_STREAMS") Cc: stable@vger.kernel.org # for >= 6.3 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The big V4L2 async framework overhaul simplified linked lists used by the V4L2 async framework. This affected a few drivers and it turns out a few of those drivers rely on searching for entities in both async notifier's waiting and done lists. Do that by separately traversing both. Fixes: 9bf19fb ("media: v4l: async: Rework internal lists") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
…acpi_dev() In ipu_bridge_get_ivsc_acpi_dev(), the "ivsc_adev" acpi_device pointer from the outer loop is handed over to the caller, which takes proper care of its reference count. However, the "consumer" acpi_device pointer from the inner loop is lost, without decrementing its reference count. Fix this by adding the missing call to acpi_dev_put(). Fixes: c66821f ("media: pci: intel: Add IVSC support for IPU bridge driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
This makes the driver work with the new check in v4l2_async_register_subdev() that was introduced recently in 6.6-rc1. Without this change, probe fails with: ov8858 1-0036: Detected OV8858 sensor, revision 0xb2 ov8858 1-0036: sub-device fwnode is an endpoint! ov8858 1-0036: v4l2 async register subdev failed ov8858: probe of 1-0036 failed with error -22 This also simplifies the driver a bit. Signed-off-by: Ondrej Jirman <megi@xff.cz> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The alternative stack checking in get_sigframe introduced by the Vector support is not needed and has a problem. It is not needed as we have already validate it at the beginning of the function if we are already on an altstack. If not, the size of an altstack is always validated at its allocation stage with sigaltstack_size_valid(). Besides, we must only regard the size of an altstack if the handler of a signal is registered with SA_ONSTACK. So, blindly checking overflow of an altstack if sas_ss_size not equals to zero will check against wrong signal handlers if only a subset of signals are registered with SA_ONSTACK. Fixes: 8ee0b41 ("riscv: signal: Add sigcontext save/restore for vector") Reported-by: Prashanth Swaminathan <prashanthsw@google.com> Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Link: https://lore.kernel.org/r/20230822164904.21660-1-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
There are two duplicate `-O binary` flags when objcopying from vmlinux to Image/xipImage. RISC-V set `-O binary` flag in both OBJCOPYFLAGS in the top-level riscv Makefile and OBJCOPYFLAGS_* in the boot/Makefile, and the objcopy cmd in Kbuild would join them together. The `-O binary` flag is only needed for objcopying Image, so remove the OBJCOPYFLAGS in the top-level riscv Makefile. Fixes: c0fbcd9 ("RISC-V: Build flat and compressed kernel images") Signed-off-by: Song Shuai <songshuaishuai@tinylab.org> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20230914091334.1458542-1-songshuaishuai@tinylab.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
When testing on risc-v QEMU environment with "crashkernel="
parameter enabled, a problem occurred with the following
message:
[ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB)
[ 0.000000] crashkernel reserved: 0x0000000177e00000 - 0x0000000277e00000 (4096 MB)
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/resource.c:779 __insert_resource+0x8e/0xd0
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc2-next-20230920 #1
[ 0.000000] Hardware name: riscv-virtio,qemu (DT)
[ 0.000000] epc : __insert_resource+0x8e/0xd0
[ 0.000000] ra : insert_resource+0x28/0x4e
[ 0.000000] epc : ffffffff80017344 ra : ffffffff8001742e sp : ffffffff81203db0
[ 0.000000] gp : ffffffff812ece98 tp : ffffffff8120dac0 t0 : ff600001f7ff2b00
[ 0.000000] t1 : 0000000000000000 t2 : 3428203030303030 s0 : ffffffff81203dc0
[ 0.000000] s1 : ffffffff81211e18 a0 : ffffffff81211e18 a1 : ffffffff81289380
[ 0.000000] a2 : 0000000277dfffff a3 : 0000000177e00000 a4 : 0000000177e00000
[ 0.000000] a5 : ffffffff81289380 a6 : 0000000277dfffff a7 : 0000000000000078
[ 0.000000] s2 : ffffffff81289380 s3 : ffffffff80a0bac8 s4 : ff600001f7ff2880
[ 0.000000] s5 : 0000000000000280 s6 : 8000000a00006800 s7 : 000000000000007f
[ 0.000000] s8 : 0000000080017038 s9 : 0000000080038ea0 s10: 0000000000000000
[ 0.000000] s11: 0000000000000000 t3 : ffffffff80a0bc00 t4 : ffffffff80a0bc00
[ 0.000000] t5 : ffffffff80a0bbd0 t6 : ffffffff80a0bc00
[ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003
[ 0.000000] [<ffffffff80017344>] __insert_resource+0x8e/0xd0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Failed to add a Crash kernel resource at 177e00000
The crashkernel memory has been allocated successfully, whereas
it failed to insert into iomem_resource. This is due to the
unique reserving logic in risc-v arch specific code, i.e.
crashk_res/crashk_low_res will be added into iomem_resource
later in init_resources(), which is not aligned with current
unified reserving logic in reserve_crashkernel_{generic,low}()
and therefore leads to the failure of crashkernel reservation.
Removing the arch specific code within #ifdef CONFIG_KEXEC_CORE
in init_resources() to fix above problem.
Fixes: 3154915 ("riscv: kdump: use generic interface to simplify crashkernel reservation")
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Link: https://lore.kernel.org/r/20230925024333.730964-1-chenjiahao16@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
If configuration options SOFTIRQ_ON_OWN_STACK and PREEMPT_RT
are enabled simultaneously under RISC-V architecture,
it will result in a compilation failure:
arch/riscv/kernel/irq.c:64:6: error: redefinition of 'do_softirq_own_stack'
64 | void do_softirq_own_stack(void)
| ^~~~~~~~~~~~~~~~~~~~
In file included from ./arch/riscv/include/generated/asm/softirq_stack.h:1,
from arch/riscv/kernel/irq.c:15:
./include/asm-generic/softirq_stack.h:8:20: note: previous definition of 'do_softirq_own_stack' was here
8 | static inline void do_softirq_own_stack(void)
| ^~~~~~~~~~~~~~~~~~~~
After changing CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK to CONFIG_SOFTIRQ_ON_OWN_STACK,
compilation can be successful.
Fixes: dd69d07 ("riscv: stack: Support HAVE_SOFTIRQ_ON_OWN_STACK")
Reviewed-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Jiexun Wang <wangjiexun@tinylab.org>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20230913052940.374686-1-wangjiexun@tinylab.org
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
ftrace creates entries for each syscall in the tracefs but has failed since commit 08d0ce3 ("riscv: Implement syscall wrappers") which prefixes all riscv syscalls with __riscv_. So fix this by implementing arch_syscall_match_sym_name() which allows us to ignore this prefix. And also ignore compat syscalls like x86/arm64 by implementing arch_trace_is_compat_syscall(). Fixes: 08d0ce3 ("riscv: Implement syscall wrappers") Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Tested-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20231003182407.32198-1-alexghiti@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
The following panic can happen when mmap is called before the pmu add callback which sets the hardware counter index: this happens for example with the following command `perf record --no-bpf-event -n kill`. [ 99.461486] CPU: 1 PID: 1259 Comm: perf Tainted: G E 6.6.0-rc4ubuntu-defconfig #2 [ 99.461669] Hardware name: riscv-virtio,qemu (DT) [ 99.461748] epc : pmu_sbi_set_scounteren+0x42/0x44 [ 99.462337] ra : smp_call_function_many_cond+0x126/0x5b0 [ 99.462369] epc : ffffffff809f9d24 ra : ffffffff800f93e0 sp : ff60000082153aa0 [ 99.462407] gp : ffffffff82395c98 tp : ff6000009a218040 t0 : ff6000009ab3a4f0 [ 99.462425] t1 : 0000000000000004 t2 : 0000000000000100 s0 : ff60000082153ab0 [ 99.462459] s1 : 0000000000000000 a0 : ff60000098869528 a1 : 0000000000000000 [ 99.462473] a2 : 000000000000001f a3 : 0000000000f00000 a4 : fffffffffffffff8 [ 99.462488] a5 : 00000000000000cc a6 : 0000000000000000 a7 : 0000000000735049 [ 99.462502] s2 : 0000000000000001 s3 : ffffffff809f9ce2 s4 : ff60000098869528 [ 99.462516] s5 : 0000000000000002 s6 : 0000000000000004 s7 : 0000000000000001 [ 99.462530] s8 : ff600003fec98bc0 s9 : ffffffff826c5890 s10: ff600003fecfcde0 [ 99.462544] s11: ff600003fec98bc0 t3 : ffffffff819e2558 t4 : ff1c000004623840 [ 99.462557] t5 : 0000000000000901 t6 : ff6000008feeb890 [ 99.462570] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 99.462658] [<ffffffff809f9d24>] pmu_sbi_set_scounteren+0x42/0x44 [ 99.462979] Code: 1060 4785 97bb 00d7 8fd9 9073 1067 6422 0141 8082 (9002) 0013 [ 99.463335] Kernel BUG [#2] To circumvent this, try to enable userspace access to the hardware counter when it is selected in addition to when the event is mapped. And vice-versa when the event is stopped/unmapped. Fixes: cc4c07c ("drivers: perf: Implement perf event mmap support in the SBI backend") Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20231006082010.11963-1-alexghiti@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
This reverts commit 92e24e0. While the patch itself is correct, it uncovered an issue with fallback to PS/2 mode, where we were leaving psmouse->fast_reconnect handler set to psmouse_smbus_reconnect(), which caused crashes. While discussing various approaches to fix the issue it was noted that this patch ass undesired delay in the "fast" resume path of PS/2 device, and it would be better to actually use "reset_delay" option defined in struct rmi_device_platform_data and have RMI code handle it for SMBus transport as well. So this patch is being reverted to deal with crashes and a better solution will be merged shortly. Reported-by: Thorsten Leemhuis <linux@leemhuis.info> Closes: https://lore.kernel.org/all/ca0109fa-c64b-43c1-a651-75b294d750a1@leemhuis.info/ Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Merge ACPI EC driver and ACPI resources handlig changes for 6.6-rc6: - Add EC GPE fixup quirk for HP Pavilion Gaming 15-dk1xxx (Hans de Goede). - Add ACPI IRQ override quirks for TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q, and for ASUS ExpertBook B1402CBA (ans de Goede). * acpi-ec: ACPI: EC: Add quirk for the HP Pavilion Gaming 15-dk1xxx * acpi-resource: ACPI: resource: Add TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q to irq1_edge_low_force_override[] ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA
…/git/mchehab/linux-media Pull media fixes from Mauro Carvalho Chehab: - a core fix: Don't report V4L2_SUBDEV_CAP_STREAMS when API is disabled - ipu-bridge: Add a missing acpi_dev_put() - ov8858: fix driver for probe to work after 6.6-rc1 - xilinx-vipp: fix async notifier logic * tag 'media/v6.6-5' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: i2c: ov8858: Don't set fwnode in the driver media: ipu-bridge: Add missing acpi_dev_put() in ipu_bridge_get_ivsc_acpi_dev() media: xilinx-vipp: Look for entities also in waiting_list media: subdev: Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled
…ernel/git/vkoul/dmaengine
Pull dmaengine fixes from Vinod Koul:
"Driver fixes for:
- stm32 dma residue calculation and chaining
- stm32 mdma for setting inflight bytes, residue calculation and
resume abort
- channel request, channel enable and dma error in fsl_edma
- runtime pm imbalance in ste_dma40 driver
- deadlock fix in mediatek driver"
* tag 'dmaengine-fix-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine:
dmaengine: fsl-edma: fix all channels requested when call fsl_edma3_xlate()
dmaengine: stm32-dma: fix residue in case of MDMA chaining
dmaengine: stm32-dma: fix stm32_dma_prep_slave_sg in case of MDMA chaining
dmaengine: stm32-mdma: set in_flight_bytes in case CRQA flag is set
dmaengine: stm32-mdma: use Link Address Register to compute residue
dmaengine: stm32-mdma: abort resume if no ongoing transfer
dmaengine: ste_dma40: Fix PM disable depth imbalance in d40_probe
dmaengine: mediatek: Fix deadlock caused by synchronize_irq()
dmaengine: idxd: use spin_lock_irqsave before wait_event_lock_irq
dmaengine: fsl-edma: fix edma4 channel enable failure on second attempt
dt-bindings: dmaengine: zynqmp_dma: add xlnx,bus-width required property
dmaengine: fsl-dma: fix DMA error when enabling sg if 'DONE' bit is set
…/kernel/git/vkoul/soundwire Pull soundwire fix from Vinod Koul: "A single fix for making sdw bus irq conditionally built" * tag 'soundwire-6.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: soundwire: bus: Make IRQ handling conditionally built
…inux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - A handful of build fixes - A fix to avoid mixing up user/kernel-mode breakpoints, which can manifest as a hang when mixing k/uprobes with other breakpoint sources - A fix to avoid double-allocting crash kernel memory - A fix for tracefs syscall name mangling, which was causing syscalls not to show up in tracefs - A fix to the perf driver to enable the hw events when selected, which can trigger a BUG on some userspace access patterns * tag 'riscv-for-linus-6.6-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: drivers: perf: Fix panic in riscv SBI mmap support riscv: Fix ftrace syscall handling which are now prefixed with __riscv_ RISC-V: Fix wrong use of CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK riscv: kdump: fix crashkernel reserving problem on RISC-V riscv: Remove duplicate objcopy flag riscv: signal: fix sigaltstack frame size checking riscv: errata: andes: Makefile: Fix randconfig build issue riscv: Only consider swbp/ss handlers for correct privileged mode riscv: kselftests: Fix mm build by removing testcases subdirectory
…/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "Add an ACPI EC GPE detection quirk for HP Pavilion Gaming 15-dk1xxx and ACPI IRQ override quirks for TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q, and for ASUS ExpertBook B1402CBA (Hans de Goede). * tag 'acpi-6.6-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: resource: Add TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q to irq1_edge_low_force_override[] ACPI: EC: Add quirk for the HP Pavilion Gaming 15-dk1xxx ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA
Pull ceph fixes from Ilya Dryomov: "Fixes for an overreaching WARN_ON, two error paths and a switch to kernel_connect() which recently grown protection against someone using BPF to rewrite the address. All but one marked for stable" * tag 'ceph-for-6.6-rc6' of https://github.com/ceph/ceph-client: ceph: fix type promotion bug on 32bit systems libceph: use kernel_connect() ceph: remove unnecessary IS_ERR() check in ceph_fname_to_usr() ceph: fix incorrect revoked caps assert in ceph_fill_file_size()
…it/jejb/scsi Pull SCSI fix from James Bottomley: "A single tiny fix in the ufs driver core correcting the reversed logic in an error message" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: core: Correct clear TM error log
When the SMBus connection is attempted psmouse_smbus_init() sets the fast_reconnect pointer to psmouse_smbus_reconnecti(). If SMBus initialization fails, elantech_setup_ps2() and synaptics_init_ps2() will fallback to PS/2 mode, replacing the psmouse private data. This can cause issues on resume, since psmouse_smbus_reconnect() expects to find an instance of struct psmouse_smbus_dev in psmouse->private. The issue was uncovered when in 92e24e0 ("Input: psmouse - add delay when deactivating for SMBus mode") psmouse_smbus_reconnect() started attempting to use more of the data structure. The commit was since reverted, not because it was at fault, but because there was found a better way of doing what it was attempting to do. Fix the problem by resetting the fast_reconnect pointer in psmouse structure in elantech_setup_ps2() and synaptics_init_ps2() when the PS/2 mode is used. Reported-by: Thorsten Leemhuis <linux@leemhuis.info> Tested-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Jeffery Miller <jefferymiller@google.com> Fixes: bf232e4 ("Input: psmouse-smbus - allow to control psmouse_deactivate") Link: https://lore.kernel.org/r/20231005002249.554877-1-jefferymiller@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Touch controllers need some time after receiving reset command for the firmware to finish re-initializing and be ready to respond to commands from the host. The driver already had handling for the post-reset delay for I2C and SPI transports, this change adds the handling to SMBus-connected devices. SMBus devices are peculiar because they implement legacy PS/2 compatibility mode, so reset is actually issued by psmouse driver on the associated serio port, after which the control is passed to the RMI4 driver with SMBus companion device. Note that originally the delay was added to psmouse driver in 92e24e0 ("Input: psmouse - add delay when deactivating for SMBus mode"), but that resulted in an unwanted delay in "fast" reconnect handler for the serio port, so it was decided to revert the patch and have the delay being handled in the RMI4 driver, similar to the other transports. Tested-by: Jeffery Miller <jefferymiller@google.com> Link: https://lore.kernel.org/r/ZR1yUFJ8a9Zt606N@penguin Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Add VID and PID to the xpad_device table to allow driver to use the PXN V900 steering wheel, which is XTYPE_XBOX360 compatible in xinput mode. Signed-off-by: Matthias Berndt <matthias_berndt@gmx.de> Link: https://lore.kernel.org/r/4932699.31r3eYUQgx@fedora Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reported-by: syzbot+0434ac83f907a1dbdd1e@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20230916-topic-powermate_use_after_free-v3-1-64412b81a7a2@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
…kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - a reworked way for handling reset delay on SMBus-connected Synaptics touchpads (the original one, while being correct, uncovered an old bug in fallback to PS/2 code that was fixed separately; the new one however avoids having delay in serio port "fast" resume, and instead has the wait in the RMI4 code) - a fix for potential crashes when devices with Elan controllers (and Synaptics) fall back to PS/2 code. Can't be hit without the original patch above, but still good to have it fixed - a couple new device IDs in xpad Xbox driver - another quirk for Goodix driver to deal with stuff vendors put in ACPI tables - a fix for use-after-free on disconnect for powermate driver - a quirk to not initialize PS/2 mouse port on Fujitsu Lifebook E5411 laptop as it makes keyboard not usable and the device uses hid-over-i2c touchpad anyways * tag 'input-for-v6.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: powermate - fix use-after-free in powermate_config_complete Input: xpad - add PXN V900 support Input: synaptics-rmi4 - handle reset delay when using SMBus trsnsport Input: psmouse - fix fast_reconnect function for PS/2 mode Revert "Input: psmouse - add delay when deactivating for SMBus mode" Input: goodix - ensure int GPIO is in input for gpio_count == 1 && gpio_int_idx == 0 case Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table Input: xpad - add HyperX Clutch Gladiate Support
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )