From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Yao Zi <me@ziyao.cc>
Cc: alison.wang@nxp.com, angelo@kernel-space.org, trini@konsulko.com,
jserv@ccns.ncku.edu.tw, eleanor15x@gmail.com,
u-boot@lists.denx.de
Subject: Re: [PATCH 1/3] serial: Add Goldfish TTY driver
Date: Sun, 21 Dec 2025 00:28:49 +0800 [thread overview]
Message-ID: <aUbOwayeH6nAYmMi@google.com> (raw)
In-Reply-To: <aUTC-8hYsPDVFOly@pie>
Hi Yao,
On Fri, Dec 19, 2025 at 03:14:03AM +0000, Yao Zi wrote:
> On Thu, Dec 18, 2025 at 06:52:50PM +0000, Kuan-Wei Chiu wrote:
> > Add support for the Google Goldfish TTY serial device. This virtual
> > device is commonly used in QEMU virtual machines (such as the m68k
> > virt machine) and Android emulators.
> >
> > The driver implements basic console output and input polling using the
> > Goldfish MMIO interface.
> >
> > Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> > ---
> > MAINTAINERS | 6 ++
> > drivers/serial/Kconfig | 8 +++
> > drivers/serial/Makefile | 1 +
> > drivers/serial/serial_goldfish.c | 112 +++++++++++++++++++++++++++++++
> > include/goldfish_tty.h | 18 +++++
> > 5 files changed, 145 insertions(+)
> > create mode 100644 drivers/serial/serial_goldfish.c
> > create mode 100644 include/goldfish_tty.h
>
> ...
>
> > diff --git a/drivers/serial/serial_goldfish.c b/drivers/serial/serial_goldfish.c
> > new file mode 100644
> > index 00000000000..85d2a93b6ff
> > --- /dev/null
> > +++ b/drivers/serial/serial_goldfish.c
> > @@ -0,0 +1,112 @@
> > +// SPDX-License-Identifier: GPL-2.0+
>
> GPL-2.0+ has been deprecated as a SPDX license identifier.
> GPL-2.0-or-later should probably be used instead[1].
Thanks for the pointer. I wasn't aware of that.
I will update it in all the other files as well in v2.
>
> > +/*
> > + * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
> > + * Goldfish TTY driver for U-Boot
> > + */
> > +
> > +#include <dm.h>
> > +#include <serial.h>
> > +#include <goldfish_tty.h>
> > +#include <asm/io.h>
> > +#include <linux/types.h>
>
> It looks better if you sort the headers :)
Sure. Will do. :)
>
> ...
>
> > +static int goldfish_serial_getc(struct udevice *dev)
> > +{
> > + static u8 rx_buf[4];
> > + struct goldfish_tty_priv *priv = dev_get_priv(dev);
> > + unsigned long base = (unsigned long)priv->base;
> > + unsigned long paddr;
> > + u32 count;
> > +
> > + count = __raw_readl((void *)(base + GOLDFISH_TTY_BYTES_READY));
> > + if (count == 0)
> > + return -EAGAIN;
> > +
> > + if (count > sizeof(rx_buf))
> > + count = sizeof(rx_buf);
> > +
> > + paddr = virt_to_phys((void *)rx_buf);
> > +
> > + rx_buf[0] = 0xAA;
> > +
> > + __raw_writel(0, (void *)(base + GOLDFISH_TTY_DATA_PTR_HIGH));
> > + __raw_writel(paddr, (void *)(base + GOLDFISH_TTY_DATA_PTR));
> > + __raw_writel(count, (void *)(base + GOLDFISH_TTY_DATA_LEN));
>
> You send a command that reads count bytes, where count represents the
> maximum of bytes available in the buffer and sizeof(rx_buf), so it's
> possible to read more than one character...
>
> > + __raw_writel(CMD_READ_BUFFER, (void *)(base + GOLDFISH_TTY_CMD));
> > +
> > + if (rx_buf[0] == 0xAA)
> > + return -EAGAIN;
> > +
> > + return rx_buf[0];
>
> But only the first character in the buffer is finally returned. Isn't
> the following characters (if present) are incorrectly discarded?
You're right. Requesting multiple bytes causes the hardware to drop
subsequent characters since getc only consumes one.
I will set the read length to 1 in v2.
>
> rx_buf is declared as static in this case. Are you originally intended
> to do some type of buffering here?
Originally, I used static to avoid performing DMA on the stack.
However, I realize that this introduces re-entrancy issues, which
prevents supporting multiple device instances properly.
In v2, I will move the buffer into struct goldfish_tty_priv.
>
> Additionally, I don't get the point of setting rx_buf[0] to 0xaa then
> checks whether it changes after sending CMD_READ_BUFFER. Is there a case
> that CMD_READ_BUFFER would fail even when reading TTY_BYTES_READY
> returns non-zero? I had a brief look at qemu's goldfish tty
> implementation, but didn't find such situation.
TBH, this is debug code used during development that I should have
removed before submitting. I will remove it in v2.
For reference, here is the planned update for v2:
struct goldfish_tty_priv {
void __iomem *base;
u8 rx_buf;
};
static int goldfish_serial_getc(struct udevice *dev)
{
struct goldfish_tty_priv *priv = dev_get_priv(dev);
unsigned long base = (unsigned long)priv->base;
unsigned long paddr;
u32 count;
count = __raw_readl((void *)(base + GOLDFISH_TTY_BYTES_READY));
if (count == 0)
return -EAGAIN;
paddr = virt_to_phys((void *)&priv->rx_buf);
__raw_writel(0, (void *)(base + GOLDFISH_TTY_DATA_PTR_HIGH));
__raw_writel(paddr, (void *)(base + GOLDFISH_TTY_DATA_PTR));
__raw_writel(1, (void *)(base + GOLDFISH_TTY_DATA_LEN));
__raw_writel(CMD_READ_BUFFER, (void *)(base + GOLDFISH_TTY_CMD));
return priv->rx_buf;
}
Regards,
Kuan-Wei
>
> > +}
>
> Best regards,
> Yao Zi
>
> [1]: https://lore.kernel.org/u-boot/20251212142859.GQ303283@bill-the-cat
next prev parent reply other threads:[~2025-12-20 23:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-18 18:52 [PATCH 0/3] m68k: Add support for QEMU virt machine Kuan-Wei Chiu
2025-12-18 18:52 ` [PATCH 1/3] serial: Add Goldfish TTY driver Kuan-Wei Chiu
2025-12-19 3:14 ` Yao Zi
2025-12-20 16:28 ` Kuan-Wei Chiu [this message]
2025-12-21 2:58 ` Yao Zi
2025-12-18 18:52 ` [PATCH 2/3] m68k: Add support for M68040 CPU Kuan-Wei Chiu
2025-12-18 19:00 ` Tom Rini
2025-12-20 16:43 ` Kuan-Wei Chiu
2025-12-22 16:20 ` Tom Rini
2025-12-21 4:53 ` Daniel Palmer
2025-12-21 7:25 ` Angelo Dureghello
2025-12-22 9:21 ` Kuan-Wei Chiu
2025-12-18 18:52 ` [PATCH 3/3] board: Add QEMU m68k virt board support Kuan-Wei Chiu
2025-12-18 19:04 ` Tom Rini
2025-12-20 16:48 ` Kuan-Wei Chiu
2025-12-21 4:37 ` Daniel Palmer
2025-12-22 9:03 ` Kuan-Wei Chiu
2025-12-18 19:00 ` [PATCH 0/3] m68k: Add support for QEMU virt machine Tom Rini
2025-12-20 16:39 ` Kuan-Wei Chiu
2025-12-21 4:15 ` Daniel Palmer
2025-12-22 8:44 ` Kuan-Wei Chiu
2025-12-22 9:20 ` Daniel Palmer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aUbOwayeH6nAYmMi@google.com \
--to=visitorckw@gmail.com \
--cc=alison.wang@nxp.com \
--cc=angelo@kernel-space.org \
--cc=eleanor15x@gmail.com \
--cc=jserv@ccns.ncku.edu.tw \
--cc=me@ziyao.cc \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.