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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.