[PATCH AUTOSEL 6.6 48/59] usb: typec: fusb302: fix scheduling while atomic when using virtio-gpio

[Sasha Levin <sashal@kernel.org>]

From: Yongbo Zhang <giraffesnn123@gmail.com>

[ Upstream commit 1c2d81bded1993bb2c7125a911db63612cdc8d40 ]

When the gpio irqchip connected to a slow bus(e.g., i2c bus or virtio
bus), calling disable_irq_nosync() in top-half ISR handler will trigger
the following kernel BUG:

BUG: scheduling while atomic: RenderEngine/253/0x00010002
...
Call trace:
 dump_backtrace+0x0/0x1c8
 show_stack+0x1c/0x2c
 dump_stack_lvl+0xdc/0x12c
 dump_stack+0x1c/0x64
 __schedule_bug+0x64/0x80
 schedule_debug+0x98/0x118
 __schedule+0x68/0x704
 schedule+0xa0/0xe8
 schedule_timeout+0x38/0x124
 wait_for_common+0xa4/0x134
 wait_for_completion+0x1c/0x2c
 _virtio_gpio_req+0xf8/0x198
 virtio_gpio_irq_bus_sync_unlock+0x94/0xf0
 __irq_put_desc_unlock+0x50/0x54
 disable_irq_nosync+0x64/0x94
 fusb302_irq_intn+0x24/0x84
 __handle_irq_event_percpu+0x84/0x278
 handle_irq_event+0x64/0x14c
 handle_level_irq+0x134/0x1d4
 generic_handle_domain_irq+0x40/0x68
 virtio_gpio_event_vq+0xb0/0x130
 vring_interrupt+0x7c/0x90
 vm_interrupt+0x88/0xd8
 __handle_irq_event_percpu+0x84/0x278
 handle_irq_event+0x64/0x14c
 handle_fasteoi_irq+0x110/0x210
 __handle_domain_irq+0x80/0xd0
 gic_handle_irq+0x78/0x154
 el0_irq_naked+0x60/0x6c

This patch replaces request_irq() with devm_request_threaded_irq() to
avoid the use of disable_irq_nosync().

Signed-off-by: Yongbo Zhang <giraffesnn123@gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250526043433.673097-1-giraffesnn123@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees. Here's my
extensive analysis:

## Bug Analysis

The commit fixes a critical "scheduling while atomic" bug that occurs
when the fusb302 USB Type-C controller uses GPIO interrupts connected
through slow buses (like I2C or virtio). The bug manifests as a kernel
BUG with the following call trace showing `__schedule_bug` being
triggered from within an atomic context.

## Technical Details of the Bug

1. **Root Cause**: The fusb302 driver's interrupt handler
   (`fusb302_irq_intn`) calls `disable_irq_nosync()` from the top-half
   ISR context (lines 1480-1481 in the original code). When the GPIO
   controller is connected via a slow bus like virtio-gpio, the
   `disable_irq_nosync()` operation requires bus transactions that can
   sleep, which is forbidden in atomic/interrupt context.

2. **The Problem Flow**:
   - Hardware interrupt occurs → `fusb302_irq_intn` ISR runs in atomic
     context
   - ISR calls `disable_irq_nosync(chip->gpio_int_n_irq)`
   - virtio-gpio's `virtio_gpio_irq_bus_sync_unlock()` needs to
     communicate over virtio bus
   - This requires `wait_for_completion()` which can sleep
   - Sleeping in atomic context triggers the kernel BUG

## The Fix

The fix replaces `request_irq()` with `devm_request_threaded_irq()` and
removes the problematic `disable_irq_nosync()`/`enable_irq()` pattern:

1. **Before**: Used regular IRQ handler that disabled the interrupt in
   top-half, scheduled work, then re-enabled in bottom-half
2. **After**: Uses threaded IRQ handler which naturally handles the
   interrupt masking/unmasking without explicit calls

Key changes:
- Line 1751-1754: Changed from `request_irq()` to
  `devm_request_threaded_irq()` with NULL top-half handler
- Line 1481: Removed `disable_irq_nosync()` call from ISR
- Line 1625: Removed corresponding `enable_irq()` call from work
  function
- Line 1750: Removed `free_irq()` call (handled by devm_*)

## Stable Backport Criteria Evaluation

1. **Fixes a bug affecting users**: YES - This fixes a kernel BUG that
   causes system instability
2. **Relatively small and contained**: YES - Only 7 lines changed,
   confined to one driver file
3. **Clear side effects**: NO - The fix is straightforward with no
   architectural changes
4. **Major architectural changes**: NO - Simply changes IRQ registration
   method
5. **Critical kernel subsystems**: NO - Limited to USB Type-C controller
   driver
6. **Stable tree mention**: NO - But follows stable tree rules perfectly
7. **Follows stable rules**: YES - Important bugfix with minimal risk

## Additional Considerations

- The bug only manifests with specific hardware configurations (virtio-
  gpio or slow I2C GPIO expanders)
- The fix is a standard pattern used throughout the kernel for similar
  issues
- Using `devm_request_threaded_irq()` is actually cleaner and provides
  automatic cleanup
- No functional changes to the driver's behavior, only fixes the atomic
  scheduling violation
- Similar fixes have been applied to other drivers facing the same issue
  pattern

This is an ideal stable backport candidate: it fixes a real bug that
causes kernel panics, the fix is minimal and well-understood, and
there's virtually no risk of regression.

 drivers/usb/typec/tcpm/fusb302.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c
index bc21006e979c..111c46df4a1f 100644
--- a/drivers/usb/typec/tcpm/fusb302.c
+++ b/drivers/usb/typec/tcpm/fusb302.c
@@ -1477,9 +1477,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id)
 	struct fusb302_chip *chip = dev_id;
 	unsigned long flags;
 
-	/* Disable our level triggered IRQ until our irq_work has cleared it */
-	disable_irq_nosync(chip->gpio_int_n_irq);
-
 	spin_lock_irqsave(&chip->irq_lock, flags);
 	if (chip->irq_suspended)
 		chip->irq_while_suspended = true;
@@ -1622,7 +1619,6 @@ static void fusb302_irq_work(struct work_struct *work)
 	}
 done:
 	mutex_unlock(&chip->lock);
-	enable_irq(chip->gpio_int_n_irq);
 }
 
 static int init_gpio(struct fusb302_chip *chip)
@@ -1747,9 +1743,10 @@ static int fusb302_probe(struct i2c_client *client)
 		goto destroy_workqueue;
 	}
 
-	ret = request_irq(chip->gpio_int_n_irq, fusb302_irq_intn,
-			  IRQF_ONESHOT | IRQF_TRIGGER_LOW,
-			  "fsc_interrupt_int_n", chip);
+	ret = devm_request_threaded_irq(dev, chip->gpio_int_n_irq,
+					NULL, fusb302_irq_intn,
+					IRQF_ONESHOT | IRQF_TRIGGER_LOW,
+					"fsc_interrupt_int_n", chip);
 	if (ret < 0) {
 		dev_err(dev, "cannot request IRQ for GPIO Int_N, ret=%d", ret);
 		goto tcpm_unregister_port;
@@ -1774,7 +1771,6 @@ static void fusb302_remove(struct i2c_client *client)
 	struct fusb302_chip *chip = i2c_get_clientdata(client);
 
 	disable_irq_wake(chip->gpio_int_n_irq);
-	free_irq(chip->gpio_int_n_irq, chip);
 	cancel_work_sync(&chip->irq_work);
 	cancel_delayed_work_sync(&chip->bc_lvl_handler);
 	tcpm_unregister_port(chip->tcpm_port);
-- 
2.39.5