Re: ucom console again [PATCH]

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

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.