Here are backports of the three patches that failed to apply to 5.15 due
to trivial context conflicts.
Hopefully they apply to the older stable trees as well as-is.
Note that the last patch depends on features that were not added until
5.9 as mentioned in the commit message. Note that the author of that
patch did not add a stable tag for this one, but backporting shouldn't
hurt.
Johan
Johan Hovold (3):
usb: dwc3: fix PHY disable sequence
usb: dwc3: qcom: fix use-after-free on runtime-PM wakeup
usb: dwc3: disable USB core PHY management
drivers/usb/dwc3/core.c | 19 ++++++++++---------
drivers/usb/dwc3/dwc3-qcom.c | 14 +++++++++++++-
drivers/usb/dwc3/host.c | 11 +++++++++++
3 files changed, 34 insertions(+), 10 deletions(-)
--
2.35.1
Hi
Here I'm submitting backport of patches
8238b4579866b7c1bb99883cfe102a43db5506ff and
d6ffe6067a54972564552ea45d320fb98db1ac5e to the stable branches.
Mikulas
This patch series backports a bunch of patches related IRQ handling
with respect to freeing the irq line while IRQ is in flight at CPU
or at the hardware level.
Recently we saw this issue in serial 8250 driver where the IRQ was being
freed while the irq was in flight or not yet delivered to the CPU. As a
result the irqchip was going into a wedged state and IRQ was not getting
delivered to the cpu. These patches helped fixed the issue in 4.14
kernel.
Let us know if more patches need backporting.
Lukas Wunner (2):
genirq: Update code comments wrt recycled thread_mask
genirq: Synchronize only with single thread on free_irq()
Thomas Gleixner (4):
genirq: Delay deactivation in free_irq()
genirq: Fix misleading synchronize_irq() documentation
genirq: Add optional hardware synchronization for shutdown
x86/ioapic: Implement irq_get_irqchip_state() callback
arch/x86/kernel/apic/io_apic.c | 46 ++++++++++++++
kernel/irq/autoprobe.c | 6 +-
kernel/irq/chip.c | 6 ++
kernel/irq/cpuhotplug.c | 2 +-
kernel/irq/internals.h | 5 ++
kernel/irq/manage.c | 106 ++++++++++++++++++++++-----------
6 files changed, 133 insertions(+), 38 deletions(-)
--
2.37.1
On 9/14/22 19:21, Jason Wittlin-Cohen wrote:
> 8d5c106fe216bf16080d7070c37adf56a9227e60 is the first bad commit
> commit 8d5c106fe216bf16080d7070c37adf56a9227e60
> Author: Kiwoong Kim <kwmad.kim(a)samsung.com <mailto:kwmad.kim@samsung.com>>
> Date: Tue Aug 2 10:42:31 2022 +0900
>
> scsi: ufs: core: Enable link lost interrupt
>
> commit 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269 upstream.
>
> Link lost is treated as fatal error with commit c99b9b230149 ("scsi: ufs:
> Treat link loss as fatal error"), but the event isn't registered as
> interrupt source. Enable it.
Hi Jason,
Something must have gone wrong during the bisection process. Commit
8d5c106fe216 ("scsi: ufs: core: Enable link lost interrupt") only
affects the UFS driver and hence cannot change the behavior of a SAS
controller. How about repeating the bisection process?
Thanks,
Bart.