[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5fed7e09-b59f-46b0-be49-881c0c1b61c1@kernel.org>
Date: Fri, 26 Sep 2025 10:29:52 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: Florian Eckert <fe@....tdt.de>, gregkh@...uxfoundation.org,
kumaravel.thiagarajan@...rochip.com, tharunkumar.pasumarthi@...rochip.com,
andriy.shevchenko@...ux.intel.com, pnewman@...necttech.com,
angelogioacchino.delregno@...labora.com, peterz@...radead.org,
yujiaoliang@...o.com, arnd@...nel.org, cang1@...e.co.uk, macro@...am.me.uk,
schnelle@...ux.ibm.com, Eckert.Florian@...glemail.com
Cc: linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH] serial: 8250_pcilib: Replace deprecated PCI functions
On 24. 09. 25, 15:35, Florian Eckert wrote:
> When the '8250_exar' module is loaded in to the kernel, a kernel trace
> with 'WARN_ON(legacy_iomap_table[bar])' is dumped to the console,
> because the old pci table mapping is still used in '8250_pcilib'.
>
> The old function have been deprecated in commit e354bb84a4c1 ("PCI:
> Deprecate pcim_iomap_table(), pcim_iomap_regions_request_all()").
>
> The remapping already takes or must take place in the driver that calls
> the function 'serial8250_pci_setup_port()'. The remapping should only be
> called once via 'pcim_iomap()'. Therefore the remapping moved to the
> caller of 'serial8250_pci_setup_port()'.
>
> To use the new functions in '8250_pcilib' the function signature of
> 'serial8250_pci_setup_port()' has been extended with an already iomapped
> address value. So this can be used directly without mapping again.
>
> Signed-off-by: Florian Eckert <fe@....tdt.de>
...
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -165,7 +165,15 @@ static int
> setup_port(struct serial_private *priv, struct uart_8250_port *port,
> u8 bar, unsigned int offset, int regshift)
> {
> - return serial8250_pci_setup_port(priv->dev, port, bar, offset, regshift);
> + void __iomem *iomem = NULL;
> +
> + if (pci_resource_flags(priv->dev, bar) & IORESOURCE_MEM) {
> + iomem = pcim_iomap(priv->dev, bar, 0);
> + if (IS_ERR(iomem))
> + return -ENOMEM;
Why not to propagate the error?
Other than that, LGTM.
--
js
suse labs
Powered by blists - more mailing lists