Re: [PATCH v2 0/2] usb: gadget: Fix g_ncm regression and atomic sleep in f_ncm

[Kuen-Han Tsai]

On Tue, Mar 3, 2026 at 1:22 AM David Heidelberg <david@xxxxxxx> wrote:
>
> On 02/03/2026 16:41, David Heidelberg wrote:
> > On 02/03/2026 11:15, Kuen-Han Tsai wrote:
> > [...]>
> >> David, could you share exactly what OS you are using (e.g.,
> >> postmarketOS with an sdm845/6.18-dev tree)? Also, could you provide
> >> some instructions on how to build the code and reproduce this problem
> >> on a Pixel 3? If you have the time, it would be incredibly helpful if
> >> you could dive into this a bit deeper on your device to see exactly
> >> how the DHCP daemon is failing.
> >
> > Hello Kuen-Han,
> >
> > it's pmOS initrd, but generally I got reported same behaviour on Mobian (Mobile
> > Debian) too.
> >
> > The Pixel 3 support was merged, so it can be reproduced with:
> > 1. 7.0-rc1 tag
> > 2. -next tree (latest tested is next-20260227)
> > 3. our sdm845-next tree [1] (some WIP patches, working touchscreen on Pixel 3,
> > etc.), the tree currently contains the reverts
>
> I forgot to mention, the build is just (considering option 3., which includes
> sdm845.config fragment):
>
> make defconfig sdm845.config
> make
> mkbootimg (with params seen below)
>
> deviceinfo_flash_offset_base="0x00000000"
> deviceinfo_flash_offset_kernel="0x00008000"
> deviceinfo_flash_offset_ramdisk="0x01000000"
> deviceinfo_flash_offset_second="0x00000000"
> deviceinfo_flash_offset_tags="0x00000100"
>
> You can use Luca's [1] scripts for the processing kernel to be suitable for
> fastboot (appends initrd to boot.img) and uploading kernel modules to pmOS rootfs.
>
> Options 1. and 2. won't work directly with fastboot, as chainloaded u-boot is
> needed due to fastboot requiring some ancient kernel offset to be in place (we
> keep patch to workaround it in sdm845-next).
>
> David
>
> [1] https://github.com/z3ntu/linux-mainline-scripts/
>
> >
> > I can provide log with the patch [2], without the patch [3] (well, it's more
> > like nothing is in the log)
> >
> > I'm very lightly familiar with usb subsystem, so if you give me hints what to
> > look for (or what to debug), I'll try find a moment to check to move this forward.
> >
> > Thank you for working on improving usb gadgets!
> > David
> >
> > [1] https://codeberg.org/sdm845/linux/
> > [2] https://paste.sr.ht/~okias/35982d7e284ee0f767e57923ced591beb4d3b238#L589
> > [3] https://paste.sr.ht/~okias/4e9172a34e4093445536b51e935dbd229edad7b2#L613
>
> [...]

Hi David,

Thanks for providing the detailed reproduction steps and logs; they
were incredibly helpful. I was able to reproduce the issue locally.

Looking at the failure logs, the regression's cause is the kernel
returning the name pattern "usb%d" via configfs instead of the
interface name "usb0". The pmOS DHCP daemon [1] relies on this string
to bind to the interface. I confirmed that providing the actual
interface name resolves the DHCP server startup failure.

However, investigating a fix revealed a deeper architectural flaw in
my patch. By deferring the net_device allocation to the bind() phase,
a single function instance will spawn multiple network devices if it
is symlinked to multiple USB configurations. Since configfs only
exposes a single ifname attribute per instance, it is fundamentally
impossible to accurately report the interface name when multiple
underlying network devices exist for that single instance.

All configurations tied to the same function instance are meant to
share a single network device, which is why the original design
correctly allocated it at the instance level. Because my approach
breaks this 1:1 mapping, I will send out a revert series in the next
few days.

Thanks again for catching this and helping track it down!

Regards,
Kuen-Han

[1] https://gitlab.com/postmarketOS/pmaports/-/blob/master/main/postmarketos-initramfs/init_functions.sh?ref_type=heads#L771