From: sashiko-bot@kernel.org
To: "Greg Ungerer" <gerg@linux-m68k.org>, linux-serial@vger.kernel.org
Subject: Re: [PATCH 2/5] serial: mcf: convert to use proper platform resources
Date: Tue, 13 Oct 2026 12:24:06 +0000 [thread overview]
Message-ID: <sashiko-outbox-169702@kernel.org> (raw)
In-Reply-To: <20261013120831.1046590-3-gerg@linux-m68k.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] tty: mcf: unconditional removal of all UART ports in mcf_remove()
- [High] tty: mcf: ERR_PTR stored in membase bypasses uninitialized check
- [Medium] tty: mcf: tautological error check on platform_get_irq()
--
commit c5cb7916e270b19e0758d11e193eb23c71763eca
Author: Greg Ungerer <gerg@linux-m68k.org>
serial: mcf: convert to use proper platform resources
The ColdFire SoC device setup code supplies a non-standard array of
hardware address information (memory address and IRQ) for initializing
the UARTS - which it does as a single blob. The mcf serial probe
function processes the whole set in one go from a single platform entry.
[ ... ]
> diff --git a/drivers/tty/serial/mcf.c b/drivers/tty/serial/mcf.c
> index 2b862dfe39ab3..3651910dff99e 100644
> --- a/drivers/tty/serial/mcf.c
> +++ b/drivers/tty/serial/mcf.c
[ ... ]
> @@ -570,31 +570,34 @@ static struct uart_driver mcf_driver = {
>
> static int mcf_probe(struct platform_device *pdev)
> {
> - struct mcf_platform_uart *platp = dev_get_platdata(&pdev->dev);
> struct uart_port *port;
> - int i;
> + struct resource *res;
>
> - for (i = 0; ((i < MCF_MAXPORTS) && (platp[i].mapbase)); i++) {
> - port = &mcf_ports[i].port;
> + if (pdev->id >= MCF_MAXPORTS)
> + return -ENODEV;
> + port = &mcf_ports[pdev->id].port;
>
> - port->line = i;
> - port->type = PORT_MCF;
> - port->mapbase = platp[i].mapbase;
> - port->membase = (platp[i].membase) ? platp[i].membase :
> - (unsigned char __iomem *) platp[i].mapbase;
> - port->dev = &pdev->dev;
> - port->iotype = SERIAL_IO_MEM;
> - port->irq = platp[i].irq;
> - port->uartclk = MCF_BUSCLK;
> - port->ops = &mcf_uart_ops;
> - port->flags = UPF_BOOT_AUTOCONF;
> - port->rs485_config = mcf_config_rs485;
> - port->rs485_supported = mcf_rs485_supported;
> - port->has_sysrq = IS_ENABLED(CONFIG_SERIAL_MCF_CONSOLE);
> -
> - uart_add_one_port(&mcf_driver, port);
> - }
> + port->membase = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> + if (IS_ERR(port->membase))
> + return PTR_ERR(port->membase);
[Severity: High]
Since port is a pointer to the global mcf_ports array, assigning an ERR_PTR
to port->membase leaves the error pointer in the global state if
devm_platform_get_and_ioremap_resource() fails.
Later, when the early console is initialized, mcf_console_setup() checks if
membase is valid using:
if (port->membase == 0)
return -ENODEV;
Since an ERR_PTR is not zero, this check will pass, which could cause a
kernel panic when mcf_console_write() dereferences the ERR_PTR during a
printk.
Could we store the mapped address in a local variable and only assign it to
port->membase on success?
> + port->mapbase = res->start;
> +
> + port->irq = platform_get_irq(pdev, 0);
> + if (port->irq < 0)
> + return port->irq;
[Severity: Medium]
In struct uart_port, irq is defined as an unsigned int. Does the check
(port->irq < 0) undergo unsigned comparison and become tautologically false?
If platform_get_irq() fails and returns a negative error code like -ENXIO,
it seems this error would be swallowed, and the port would be registered
with a bogus, very large IRQ number.
> + port->line = pdev->id;
> + port->type = PORT_MCF;
> + port->dev = &pdev->dev;
> + port->iotype = SERIAL_IO_MEM;
> + port->uartclk = MCF_BUSCLK;
> + port->ops = &mcf_uart_ops;
> + port->flags = UPF_BOOT_AUTOCONF;
> + port->rs485_config = mcf_config_rs485;
> + port->rs485_supported = mcf_rs485_supported;
> + port->has_sysrq = IS_ENABLED(CONFIG_SERIAL_MCF_CONSOLE);
> +
> + uart_add_one_port(&mcf_driver, port);
> return 0;
> }
[Severity: High]
With the conversion of mcf_probe() to process a single platform device per
call instead of a single blob, does mcf_remove() also need to be updated?
Looking at mcf_remove() in drivers/tty/serial/mcf.c:
static void mcf_remove(struct platform_device *pdev)
{
struct uart_port *port;
int i;
for (i = 0; (i < MCF_MAXPORTS); i++) {
port = &mcf_ports[i].port;
if (port)
uart_remove_one_port(&mcf_driver, port);
}
}
It appears this loop still unconditionally unregisters all 10 ports,
regardless of which pdev is being removed. If a single device is unbound
via sysfs, will this disrupt other devices or lead to list corruption by
calling uart_remove_one_port() on uninitialized structs or multiple times
on the same port?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013120831.1046590-1-gerg@linux-m68k.org?part=2
next prev parent reply other threads:[~2026-10-13 12:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 12:06 [PATCH 0/5] serial: mcf: add devicetree support Greg Ungerer
2026-10-13 12:06 ` [PATCH 1/5] serial: mcf: update author email address Greg Ungerer
2026-10-13 12:14 ` sashiko-bot
2026-10-13 12:07 ` [PATCH 2/5] serial: mcf: convert to use proper platform resources Greg Ungerer
2026-10-13 12:24 ` sashiko-bot [this message]
2026-10-13 12:07 ` [PATCH 3/5] serial: mcf: dynamically allocate memory Greg Ungerer
2026-10-13 12:38 ` sashiko-bot
2026-10-13 12:07 ` [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart Greg Ungerer
2026-10-13 12:40 ` sashiko-bot
2026-10-13 12:07 ` [PATCH 5/5] serial: mcf: add devicetree support Greg Ungerer
2026-10-13 12:49 ` sashiko-bot
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=sashiko-outbox-169702@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=gerg@linux-m68k.org \
--cc=linux-serial@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.