* [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
@ 2025-09-30 7:27 Florian Eckert
2025-09-30 7:34 ` Jiri Slaby
2025-10-13 20:35 ` Andy Shevchenko
0 siblings, 2 replies; 11+ messages in thread
From: Florian Eckert @ 2025-09-30 7:27 UTC (permalink / raw)
To: gregkh, jirislaby, kumaravel.thiagarajan, andriy.shevchenko,
pnewman, angelogioacchino.delregno, peterz, yujiaoliang, arnd,
cang1, macro, schnelle, Eckert.Florian
Cc: linux-kernel, linux-serial, Florian Eckert
When the '8250_exar' module is loaded into 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 replace the outdated/legacy iomap_table processing 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
io mapping again.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
v2:
* The function 'pcim_iomap()' returns a NULL pointer in the event of an
error, so error handling has been adjusted.
drivers/tty/serial/8250/8250_exar.c | 4 ++--
drivers/tty/serial/8250/8250_pci.c | 10 +++++++++-
drivers/tty/serial/8250/8250_pci1xxxx.c | 10 +++++-----
drivers/tty/serial/8250/8250_pcilib.c | 7 ++-----
drivers/tty/serial/8250/8250_pcilib.h | 2 +-
5 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 04a0cbab02c2..3c16a849b474 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -503,7 +503,7 @@ static int default_setup(struct exar8250 *priv, struct pci_dev *pcidev,
unsigned char status;
int err;
- err = serial8250_pci_setup_port(pcidev, port, 0, offset, board->reg_shift);
+ err = serial8250_pci_setup_port(pcidev, port, 0, offset, board->reg_shift, priv->virt);
if (err)
return err;
@@ -831,7 +831,7 @@ static int cti_port_setup_common(struct exar8250 *priv,
port->port.port_id = idx;
port->port.uartclk = priv->osc_freq;
- ret = serial8250_pci_setup_port(pcidev, port, 0, offset, 0);
+ ret = serial8250_pci_setup_port(pcidev, port, 0, offset, 0, priv->virt);
if (ret)
return ret;
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 152f914c599d..f0f13fdda2df 100644
--- 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 (!iomem)
+ return -ENOMEM;
+ }
+
+ return serial8250_pci_setup_port(priv->dev, port, bar, offset, regshift, iomem);
}
/*
diff --git a/drivers/tty/serial/8250/8250_pci1xxxx.c b/drivers/tty/serial/8250/8250_pci1xxxx.c
index 4c149db84692..feeede164886 100644
--- a/drivers/tty/serial/8250/8250_pci1xxxx.c
+++ b/drivers/tty/serial/8250/8250_pci1xxxx.c
@@ -671,7 +671,7 @@ static int pci1xxxx_resume(struct device *dev)
}
static int pci1xxxx_setup(struct pci_dev *pdev,
- struct uart_8250_port *port, int port_idx, int rev)
+ struct uart_8250_port *port, int port_idx, struct pci1xxxx_8250 *priv)
{
int ret;
@@ -698,12 +698,12 @@ static int pci1xxxx_setup(struct pci_dev *pdev,
* C0 and later revisions support Burst operation.
* RTS workaround in mctrl is applicable only to B0.
*/
- if (rev >= 0xC0)
+ if (priv->dev_rev >= 0xC0)
port->port.handle_irq = pci1xxxx_handle_irq;
- else if (rev == 0xB0)
+ else if (priv->dev_rev == 0xB0)
port->port.set_mctrl = pci1xxxx_set_mctrl;
- ret = serial8250_pci_setup_port(pdev, port, 0, PORT_OFFSET * port_idx, 0);
+ ret = serial8250_pci_setup_port(pdev, port, 0, PORT_OFFSET * port_idx, 0, priv->membase);
if (ret < 0)
return ret;
@@ -821,7 +821,7 @@ static int pci1xxxx_serial_probe(struct pci_dev *pdev,
else
uart.port.irq = pci_irq_vector(pdev, 0);
- rc = pci1xxxx_setup(pdev, &uart, port_idx, priv->dev_rev);
+ rc = pci1xxxx_setup(pdev, &uart, port_idx, priv);
if (rc) {
dev_warn(dev, "Failed to setup port %u\n", i);
continue;
diff --git a/drivers/tty/serial/8250/8250_pcilib.c b/drivers/tty/serial/8250/8250_pcilib.c
index d8d0ae0d7238..9d5d2531a33b 100644
--- a/drivers/tty/serial/8250/8250_pcilib.c
+++ b/drivers/tty/serial/8250/8250_pcilib.c
@@ -22,19 +22,16 @@ int serial_8250_warn_need_ioport(struct pci_dev *dev)
EXPORT_SYMBOL_NS_GPL(serial_8250_warn_need_ioport, "SERIAL_8250_PCI");
int serial8250_pci_setup_port(struct pci_dev *dev, struct uart_8250_port *port,
- u8 bar, unsigned int offset, int regshift)
+ u8 bar, unsigned int offset, int regshift, void __iomem *iomem)
{
if (bar >= PCI_STD_NUM_BARS)
return -EINVAL;
if (pci_resource_flags(dev, bar) & IORESOURCE_MEM) {
- if (!pcim_iomap(dev, bar, 0) && !pcim_iomap_table(dev))
- return -ENOMEM;
-
port->port.iotype = UPIO_MEM;
port->port.iobase = 0;
port->port.mapbase = pci_resource_start(dev, bar) + offset;
- port->port.membase = pcim_iomap_table(dev)[bar] + offset;
+ port->port.membase = iomem + offset;
port->port.regshift = regshift;
} else if (IS_ENABLED(CONFIG_HAS_IOPORT)) {
port->port.iotype = UPIO_PORT;
diff --git a/drivers/tty/serial/8250/8250_pcilib.h b/drivers/tty/serial/8250/8250_pcilib.h
index 16a274574cde..ab18de8d1355 100644
--- a/drivers/tty/serial/8250/8250_pcilib.h
+++ b/drivers/tty/serial/8250/8250_pcilib.h
@@ -12,6 +12,6 @@ struct pci_dev;
struct uart_8250_port;
int serial8250_pci_setup_port(struct pci_dev *dev, struct uart_8250_port *port, u8 bar,
- unsigned int offset, int regshift);
+ unsigned int offset, int regshift, void __iomem *iomem);
int serial_8250_warn_need_ioport(struct pci_dev *dev);
--
2.39.5
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
2025-09-30 7:27 [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions Florian Eckert
@ 2025-09-30 7:34 ` Jiri Slaby
2025-10-01 14:45 ` Florian Eckert
2025-10-13 20:35 ` Andy Shevchenko
1 sibling, 1 reply; 11+ messages in thread
From: Jiri Slaby @ 2025-09-30 7:34 UTC (permalink / raw)
To: Florian Eckert, gregkh, kumaravel.thiagarajan, andriy.shevchenko,
pnewman, angelogioacchino.delregno, peterz, yujiaoliang, arnd,
cang1, macro, schnelle, Eckert.Florian
Cc: linux-kernel, linux-serial
On 30. 09. 25, 9:27, Florian Eckert wrote:
> When the '8250_exar' module is loaded into 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 replace the outdated/legacy iomap_table processing 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
> io mapping again.
>
> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
> ---
>
> v2:
> * The function 'pcim_iomap()' returns a NULL pointer in the event of an
> error, so error handling has been adjusted.
LGTM now.
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
--
js
suse labs
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
2025-09-30 7:34 ` Jiri Slaby
@ 2025-10-01 14:45 ` Florian Eckert
2025-10-02 5:25 ` Greg KH
0 siblings, 1 reply; 11+ messages in thread
From: Florian Eckert @ 2025-10-01 14:45 UTC (permalink / raw)
To: Jiri Slaby
Cc: gregkh, kumaravel.thiagarajan, andriy.shevchenko, pnewman,
angelogioacchino.delregno, peterz, yujiaoliang, arnd, cang1,
macro, schnelle, Eckert.Florian, linux-kernel, linux-serial
On 2025-09-30 09:34, Jiri Slaby wrote:
> On 30. 09. 25, 9:27, Florian Eckert wrote:
>> When the '8250_exar' module is loaded into 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 replace the outdated/legacy iomap_table processing 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
>> io mapping again.
>>
>> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
>> ---
>>
>> v2:
>> * The function 'pcim_iomap()' returns a NULL pointer in the event of
>> an
>> error, so error handling has been adjusted.
>
> LGTM now.
>
> Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Thanks for the review tag. Will this be included in linux next?
Or do I need to do something? I also think that this should be
backportet
to the latest LTS kernel “6.12.*”. This is where I noticed the problem.
--
Florian
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
2025-10-01 14:45 ` Florian Eckert
@ 2025-10-02 5:25 ` Greg KH
2025-10-07 14:31 ` Florian Eckert
0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2025-10-02 5:25 UTC (permalink / raw)
To: Florian Eckert
Cc: Jiri Slaby, kumaravel.thiagarajan, andriy.shevchenko, pnewman,
angelogioacchino.delregno, peterz, yujiaoliang, arnd, cang1,
macro, schnelle, Eckert.Florian, linux-kernel, linux-serial
On Wed, Oct 01, 2025 at 04:45:44PM +0200, Florian Eckert wrote:
>
>
> On 2025-09-30 09:34, Jiri Slaby wrote:
> > On 30. 09. 25, 9:27, Florian Eckert wrote:
> > > When the '8250_exar' module is loaded into 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 replace the outdated/legacy iomap_table processing 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
> > > io mapping again.
> > >
> > > Signed-off-by: Florian Eckert <fe@dev.tdt.de>
> > > ---
> > >
> > > v2:
> > > * The function 'pcim_iomap()' returns a NULL pointer in the event of
> > > an
> > > error, so error handling has been adjusted.
> >
> > LGTM now.
> >
> > Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
>
> Thanks for the review tag. Will this be included in linux next?
> Or do I need to do something? I also think that this should be backportet
> to the latest LTS kernel “6.12.*”. This is where I noticed the problem.
The merge window is currently happening, I can't add any changes to my
tree until after that closes in 1 1/2 weeks. And if you need/want it
backported to stable kernels, can you provide a "Fixes:" tag and a cc:
stable tag as well?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
2025-10-02 5:25 ` Greg KH
@ 2025-10-07 14:31 ` Florian Eckert
0 siblings, 0 replies; 11+ messages in thread
From: Florian Eckert @ 2025-10-07 14:31 UTC (permalink / raw)
To: Greg KH
Cc: Jiri Slaby, kumaravel.thiagarajan, andriy.shevchenko, pnewman,
angelogioacchino.delregno, peterz, yujiaoliang, arnd, cang1,
macro, schnelle, Eckert.Florian, linux-kernel, linux-serial
On 2025-10-02 07:25, Greg KH wrote:
> On Wed, Oct 01, 2025 at 04:45:44PM +0200, Florian Eckert wrote:
>>
>>
>> On 2025-09-30 09:34, Jiri Slaby wrote:
>> > On 30. 09. 25, 9:27, Florian Eckert wrote:
>> > > When the '8250_exar' module is loaded into 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 replace the outdated/legacy iomap_table processing 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
>> > > io mapping again.
>> > >
>> > > Signed-off-by: Florian Eckert <fe@dev.tdt.de>
>> > > ---
>> > >
>> > > v2:
>> > > * The function 'pcim_iomap()' returns a NULL pointer in the event of
>> > > an
>> > > error, so error handling has been adjusted.
>> >
>> > LGTM now.
>> >
>> > Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
>>
>> Thanks for the review tag. Will this be included in linux next?
>> Or do I need to do something? I also think that this should be
>> backportet
>> to the latest LTS kernel “6.12.*”. This is where I noticed the
>> problem.
>
> The merge window is currently happening, I can't add any changes to my
> tree until after that closes in 1 1/2 weeks. And if you need/want it
> backported to stable kernels, can you provide a "Fixes:" tag and a cc:
> stable tag as well?
Thanks for the info. I'll wait until the change has been applied to your
master branch. After that I will send a backport patch for LTS 6.12.
Thanks
--
Florian
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
2025-09-30 7:27 [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions Florian Eckert
2025-09-30 7:34 ` Jiri Slaby
@ 2025-10-13 20:35 ` Andy Shevchenko
1 sibling, 0 replies; 11+ messages in thread
From: Andy Shevchenko @ 2025-10-13 20:35 UTC (permalink / raw)
To: Florian Eckert
Cc: gregkh, jirislaby, kumaravel.thiagarajan, pnewman,
angelogioacchino.delregno, peterz, yujiaoliang, arnd, cang1,
macro, schnelle, Eckert.Florian, linux-kernel, linux-serial
On Tue, Sep 30, 2025 at 09:27:43AM +0200, Florian Eckert wrote:
> When the '8250_exar' module is loaded into 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 replace the outdated/legacy iomap_table processing 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
> io mapping again.
...
> + if (pci_resource_flags(priv->dev, bar) & IORESOURCE_MEM) {
Dunno if this is included already in Linux Next, but here is room for
improvement.
The problem with the above code is it (wrongly?) checks for bit and not
for the resource type. OTOH I don't remember if 64-bit version requires
the IORESOURCE_MEM to be set along with that.
> + iomem = pcim_iomap(priv->dev, bar, 0);
> + if (!iomem)
> + return -ENOMEM;
> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
@ 2025-10-18 19:33 Andy Shevchenko
2025-10-20 6:47 ` Florian Eckert
0 siblings, 1 reply; 11+ messages in thread
From: Andy Shevchenko @ 2025-10-18 19:33 UTC (permalink / raw)
To: Florian Eckert
Cc: gregkh, jirislaby, kumaravel.thiagarajan, pnewman,
angelogioacchino.delregno, peterz, yujiaoliang, arnd, cang1,
macro, schnelle, Eckert.Florian, linux-kernel, linux-serial
On Tue, Sep 30, 2025 at 09:27:43AM +0200, Florian Eckert wrote:
> When the '8250_exar' module is loaded into 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 replace the outdated/legacy iomap_table processing 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
> io mapping again.
...
> + if (pci_resource_flags(priv->dev, bar) & IORESOURCE_MEM) {
Dunno if this is included already in Linux Next, but here is room for
improvement.
The problem with the above code is it (wrongly?) checks for bit and not
for the resource type. OTOH I don't remember if 64-bit version requires
the IORESOURCE_MEM to be set along with that.
> + iomem = pcim_iomap(priv->dev, bar, 0);
> + if (!iomem)
> + return -ENOMEM;
> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
2025-10-18 19:33 Andy Shevchenko
@ 2025-10-20 6:47 ` Florian Eckert
2025-10-20 8:42 ` Andy Shevchenko
0 siblings, 1 reply; 11+ messages in thread
From: Florian Eckert @ 2025-10-20 6:47 UTC (permalink / raw)
To: Andy Shevchenko
Cc: gregkh, jirislaby, kumaravel.thiagarajan, pnewman,
angelogioacchino.delregno, peterz, yujiaoliang, arnd, cang1,
macro, schnelle, Eckert.Florian, linux-kernel, linux-serial
On 2025-10-18 21:33, Andy Shevchenko wrote:
> On Tue, Sep 30, 2025 at 09:27:43AM +0200, Florian Eckert wrote:
>> When the '8250_exar' module is loaded into 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 replace the outdated/legacy iomap_table processing 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
>> io mapping again.
>
> ...
>
>> + if (pci_resource_flags(priv->dev, bar) & IORESOURCE_MEM) {
>
> Dunno if this is included already in Linux Next, but here is room for
> improvement.
>
I followed the code in the 'serial8250_pci_setup_port()' [1] function.
The same pattern is used there [2].
>
> The problem with the above code is it (wrongly?) checks for bit and not
> for the resource type. OTOH I don't remember if 64-bit version requires
> the IORESOURCE_MEM to be set along with that.
>
Do you mean the function 'platform_get_resource()' [3]? This is a
platform
device function?
[1]
https://elixir.bootlin.com/linux/v6.18-rc1/source/drivers/tty/serial/8250/8250_pcilib.c#L24
[2]
https://elixir.bootlin.com/linux/v6.18-rc1/source/drivers/tty/serial/8250/8250_pcilib.c#L30
[3]
https://elixir.bootlin.com/linux/v6.17.3/source/drivers/base/platform.c#L55
---
Florian
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
2025-10-20 6:47 ` Florian Eckert
@ 2025-10-20 8:42 ` Andy Shevchenko
2025-10-20 16:18 ` Florian Eckert
0 siblings, 1 reply; 11+ messages in thread
From: Andy Shevchenko @ 2025-10-20 8:42 UTC (permalink / raw)
To: Florian Eckert
Cc: gregkh, jirislaby, kumaravel.thiagarajan, pnewman,
angelogioacchino.delregno, peterz, yujiaoliang, arnd, cang1,
macro, schnelle, Eckert.Florian, linux-kernel, linux-serial
On Mon, Oct 20, 2025 at 08:47:16AM +0200, Florian Eckert wrote:
> On 2025-10-18 21:33, Andy Shevchenko wrote:
> > On Tue, Sep 30, 2025 at 09:27:43AM +0200, Florian Eckert wrote:
...
> > > + if (pci_resource_flags(priv->dev, bar) & IORESOURCE_MEM) {
> >
> > Dunno if this is included already in Linux Next, but here is room for
> > improvement.
>
> I followed the code in the 'serial8250_pci_setup_port()' [1] function.
> The same pattern is used there [2].
I see. So if we want to amend that, it should be done separately.
> > The problem with the above code is it (wrongly?) checks for bit and not
> > for the resource type. OTOH I don't remember if 64-bit version requires
> > the IORESOURCE_MEM to be set along with that.
>
> Do you mean the function 'platform_get_resource()' [3]? This is a platform
> device function?
I mean that the IORESOURCE_MEM and IORESOURCE_MEM_64 are separate bit flags in
struct resource::flags. Checking on one might not imply the other be set,
however brief look at the sources shows that _MEM_64 is supposed to be set on
top of _MEM.
> [1] https://elixir.bootlin.com/linux/v6.18-rc1/source/drivers/tty/serial/8250/8250_pcilib.c#L24
> [2] https://elixir.bootlin.com/linux/v6.18-rc1/source/drivers/tty/serial/8250/8250_pcilib.c#L30
> [3]
> https://elixir.bootlin.com/linux/v6.17.3/source/drivers/base/platform.c#L55
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
2025-10-20 8:42 ` Andy Shevchenko
@ 2025-10-20 16:18 ` Florian Eckert
2025-10-20 17:32 ` Andy Shevchenko
0 siblings, 1 reply; 11+ messages in thread
From: Florian Eckert @ 2025-10-20 16:18 UTC (permalink / raw)
To: Andy Shevchenko
Cc: gregkh, jirislaby, kumaravel.thiagarajan, pnewman,
angelogioacchino.delregno, peterz, yujiaoliang, arnd, cang1,
macro, schnelle, Eckert.Florian, linux-kernel, linux-serial
On 2025-10-20 10:42, Andy Shevchenko wrote:
> On Mon, Oct 20, 2025 at 08:47:16AM +0200, Florian Eckert wrote:
>> On 2025-10-18 21:33, Andy Shevchenko wrote:
>> > On Tue, Sep 30, 2025 at 09:27:43AM +0200, Florian Eckert wrote:
>
> ...
>
>> > > + if (pci_resource_flags(priv->dev, bar) & IORESOURCE_MEM) {
>> >
>> > Dunno if this is included already in Linux Next, but here is room for
>> > improvement.
>>
>> I followed the code in the 'serial8250_pci_setup_port()' [1] function.
>> The same pattern is used there [2].
>
> I see. So if we want to amend that, it should be done separately.
If that's the case, then I'm done with this patchset, right?
I do not have to send a v3?
>
>> > The problem with the above code is it (wrongly?) checks for bit and not
>> > for the resource type. OTOH I don't remember if 64-bit version requires
>> > the IORESOURCE_MEM to be set along with that.
>>
>> Do you mean the function 'platform_get_resource()' [3]? This is a
>> platform
>> device function?
>
> I mean that the IORESOURCE_MEM and IORESOURCE_MEM_64 are separate bit
> flags in
> struct resource::flags. Checking on one might not imply the other be
> set,
> however brief look at the sources shows that _MEM_64 is supposed to be
> set on
> top of _MEM.
Okay, I understand.
---
Best regards
Florian
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
2025-10-20 16:18 ` Florian Eckert
@ 2025-10-20 17:32 ` Andy Shevchenko
0 siblings, 0 replies; 11+ messages in thread
From: Andy Shevchenko @ 2025-10-20 17:32 UTC (permalink / raw)
To: Florian Eckert
Cc: gregkh, jirislaby, kumaravel.thiagarajan, pnewman,
angelogioacchino.delregno, peterz, yujiaoliang, arnd, cang1,
macro, schnelle, Eckert.Florian, linux-kernel, linux-serial
On Mon, Oct 20, 2025 at 06:18:42PM +0200, Florian Eckert wrote:
> On 2025-10-20 10:42, Andy Shevchenko wrote:
> > On Mon, Oct 20, 2025 at 08:47:16AM +0200, Florian Eckert wrote:
> > > On 2025-10-18 21:33, Andy Shevchenko wrote:
> > > > On Tue, Sep 30, 2025 at 09:27:43AM +0200, Florian Eckert wrote:
...
> > > > > + if (pci_resource_flags(priv->dev, bar) & IORESOURCE_MEM) {
> > > >
> > > > Dunno if this is included already in Linux Next, but here is room for
> > > > improvement.
> > >
> > > I followed the code in the 'serial8250_pci_setup_port()' [1] function.
> > > The same pattern is used there [2].
> >
> > I see. So if we want to amend that, it should be done separately.
>
> If that's the case, then I'm done with this patchset, right?
> I do not have to send a v3?
Yeah, that proposal is not directly related to this change anyway.
> > > > The problem with the above code is it (wrongly?) checks for bit and not
> > > > for the resource type. OTOH I don't remember if 64-bit version requires
> > > > the IORESOURCE_MEM to be set along with that.
> > >
> > > Do you mean the function 'platform_get_resource()' [3]? This is a
> > > platform
> > > device function?
> >
> > I mean that the IORESOURCE_MEM and IORESOURCE_MEM_64 are separate bit flags
> > in struct resource::flags. Checking on one might not imply the other be
> > set, however brief look at the sources shows that _MEM_64 is supposed to be
> > set on top of _MEM.
>
> Okay, I understand.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-10-20 17:32 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-30 7:27 [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions Florian Eckert
2025-09-30 7:34 ` Jiri Slaby
2025-10-01 14:45 ` Florian Eckert
2025-10-02 5:25 ` Greg KH
2025-10-07 14:31 ` Florian Eckert
2025-10-13 20:35 ` Andy Shevchenko
-- strict thread matches above, loose matches on Subject: below --
2025-10-18 19:33 Andy Shevchenko
2025-10-20 6:47 ` Florian Eckert
2025-10-20 8:42 ` Andy Shevchenko
2025-10-20 16:18 ` Florian Eckert
2025-10-20 17:32 ` Andy Shevchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox