On Sat, Jan 31, 2026 at 6:58 AM Krishna Kurapati PSSNV <[email protected]> wrote: > > On Fri, Jan 30, 2026 at 6:46 AM Samuel Wu <[email protected]> wrote: > > > > On Thu, Jan 29, 2026 at 2:52 PM Al Viro <[email protected]> wrote: > > > > [...] > > > I'm exploring a few other paths, but not having USB access makes > > traditional tools a bit difficult. One thing I'm rechecking and is > > worth mentioning is the lockdep below: it's been present for quite > > some time now, but I'm not sure if it would have some undesired > > interaction with your patch. > > > > [ BUG: Invalid wait context ] > > 6.18.0-rc5-mainline-maybe-dirty-4k > > ----------------------------- > > irq/360-dwc3/352 is trying to lock: > > ffffff800792deb8 (&psy->extensions_sem){.+.+}-{3:3}, at: > > __power_supply_set_property+0x40/0x180 > > other info that might help us debug this: > > context-{4:4} > > 1 lock held by irq/360-dwc3/352: > > #0: ffffff8017bb98f0 (&gi->spinlock){....}-{2:2}, at: > > configfs_composite_suspend+0x28/0x68 > > Call trace: > > show_stack+0x18/0x28 (C) > > __dump_stack+0x28/0x3c > > dump_stack_lvl+0xac/0xf0 > > dump_stack+0x18/0x3c > > __lock_acquire+0x794/0x2bec > > lock_acquire+0x148/0x2cc > > down_read+0x3c/0x194 > > __power_supply_set_property+0x40/0x180 > > power_supply_set_property+0x14/0x20 > > dwc3_gadget_vbus_draw+0x8c/0xcc > > usb_gadget_vbus_draw+0x48/0x130 > > composite_suspend+0xcc/0xe4 > > configfs_composite_suspend+0x44/0x68 > > dwc3_thread_interrupt+0x8f8/0xc88 > > irq_thread_fn+0x48/0xa8 > > irq_thread+0x150/0x31c > > kthread+0x150/0x280 > > ret_from_fork+0x10/0x20 > > > > Hi Samuel, > > Not sure if it helps, but Prashanth recently pushed a patch to > address this vbus_draw kernel panic: > > https://lore.kernel.org/all/[email protected]/ > > Can you check if it fixes the above crash in vbus_draw. > > Regards, > Krishna,
Tested above patch, and it didn't fix the device enumerating on lsusb/ADB issue. Seems like usb dwc3 lockdep was a red herring. I'll respond on that thread with what I'm observing.
