[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aPZyIdnDVNezI185@smile.fi.intel.com>
Date: Mon, 20 Oct 2025 20:32:17 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Florian Eckert <fe@....tdt.de>
Cc: gregkh@...uxfoundation.org, jirislaby@...nel.org,
kumaravel.thiagarajan@...rochip.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, linux-kernel@...r.kernel.org,
linux-serial@...r.kernel.org
Subject: Re: [PATCH v2] serial: 8250_pcilib: Replace deprecated PCI functions
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
Powered by blists - more mailing lists