Re: ucom console again [PATCH]
Nick Hudson <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.kernel |
|---|---|
| Message-ID | <[email protected]> |
On 19/11/2025 02:54, Emmanuel Dreyfus wrote: > Hello > > I worked a lot with Nick Hudson on ucom console support. It is nice to > have a public review from time to time, so here is the latest patch. > https://dl.espci.fr/ticket/8941ff7b7888a716cebc9b2f3bc3ddf4 /* * Under DDB rule, just return, ucom_cnput_bytes() should * poll for completion. * Without DDB, schedule ucom_cnput_bytes() throught soft * interrupt. We cannot just call it right now, because it * calls usbd_transfer() while we are in a callback, leading * lock-against-myself panic. */ This doesn't make sense. it's perfectly acceptable to call usbd_transfer from a callback. > On Qemu: > - boot -a sometime hang on a prompt. There is a race somewhere, > I suspect it does not happen on real hardware because Qemu > serial emulation is much faster than a real serial port. > - getty fails to start because uftdi.c fails ioctl TIOCSETA with > USBD_STALLED. It seems so unrelated to my changes that I wonder > it I am not hitting an unrelated bug. both these should be easy to debug with qemu trace / attaching gdb. > Update just for Nick: I finaly implemented console input without > cn_xfer_in. When console is attached, we always schedule input > transfers, regardless of the device being open or not. That makes > polling transitions simplier because there is no need to switch > between console and standard device input xfer. yes, I think this is best.