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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox