From: Christian Marangi <ansuelsmth@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 1/1] PCI: Use resource_set_range() that correctly sets ->end
Date: Wed, 10 Dec 2025 18:17:01 +0100 [thread overview]
Message-ID: <6939ab12.050a0220.29891a.9a37@mx.google.com> (raw)
In-Reply-To: <20251210171319.GA3530931@bhelgaas>
On Wed, Dec 10, 2025 at 11:13:19AM -0600, Bjorn Helgaas wrote:
> On Mon, Dec 08, 2025 at 04:56:54PM +0200, Ilpo Järvinen wrote:
> > __pci_read_base() sets resource start and end addresses when resource
> > is larger than 4G but pci_bus_addr_t or resource_size_t are not capable
> > of representing 64-bit PCI addresses. This creates a problematic
> > resource that has non-zero flags but the start and end addresses do not
> > yield to resource size of 0 but 1.
> >
> > Replace custom resource addresses setup with resource_set_range()
> > that correctly sets end address as -1 which results in resource_size()
> > returning 0.
> >
> > For consistency, also use resource_set_range() in the other branch that
> > does size based resource setup.
>
> IIUC this fixes an ath11k regression (and probably others). And
> typically when booting a 32-bit kernel with a device with a BAR larger
> than 4GB?
>
> Christian, is there any dmesg snippet we could include here to help
> users diagnose the problem? I guess the "can't handle BAR larger than
> 4GB" message is probably one clue.
>
> Are you able to test this and verify that it fixes the regression you
> saw?
>
No my regression was on a different section and for AHB cards, no PCI.
(I sent a fix for my regression on the net mailing list)
Could be hard to find a device with 4+ gb of ram that is not x86 or on
an ipq SoC.
> > Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB")
> > Link: https://lore.kernel.org/all/20251207215359.28895-1-ansuelsmth@gmail.com/T/#m990492684913c5a158ff0e5fc90697d8ad95351b
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > Cc: stable@vger.kernel.org
> > Cc: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> > drivers/pci/probe.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 124d2d309c58..b8294a2f11f9 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -287,8 +287,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
> > if ((sizeof(pci_bus_addr_t) < 8 || sizeof(resource_size_t) < 8)
> > && sz64 > 0x100000000ULL) {
> > res->flags |= IORESOURCE_UNSET | IORESOURCE_DISABLED;
> > - res->start = 0;
> > - res->end = 0;
> > + resource_set_range(res, 0, 0);
> > pci_err(dev, "%s: can't handle BAR larger than 4GB (size %#010llx)\n",
> > res_name, (unsigned long long)sz64);
> > goto out;
> > @@ -297,8 +296,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
> > if ((sizeof(pci_bus_addr_t) < 8) && l) {
> > /* Above 32-bit boundary; try to reallocate */
> > res->flags |= IORESOURCE_UNSET;
> > - res->start = 0;
> > - res->end = sz64 - 1;
> > + resource_set_range(res, 0, sz64);
> > pci_info(dev, "%s: can't handle BAR above 4GB (bus address %#010llx)\n",
> > res_name, (unsigned long long)l64);
> > goto out;
> >
> > base-commit: 43dfc13ca972988e620a6edb72956981b75ab6b0
> > --
> > 2.39.5
> >
--
Ansuel
next prev parent reply other threads:[~2025-12-10 17:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-08 14:56 [PATCH 1/1] PCI: Use resource_set_range() that correctly sets ->end Ilpo Järvinen
2025-12-08 15:15 ` Andy Shevchenko
2025-12-10 17:13 ` Bjorn Helgaas
2025-12-10 17:17 ` Christian Marangi [this message]
2025-12-10 21:30 ` Bjorn Helgaas
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=6939ab12.050a0220.29891a.9a37@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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.