mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: Martin Mares <mj@ucw.cz>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [pciutils PATCH v2] lspci: Determine bridge window address size from bridge_flags
Date: Sat, 22 Aug 2026 01:06:20 +0200	[thread overview]
Message-ID: <20260821230620.fcpmn7radmwnfnh2@pali> (raw)
In-Reply-To: <20260821221610.3570722-1-dmatlack@google.com>

Hello! Thank you for taking this issue. I briefly checked the change and
I think that this is the right way how to address that issue.

Anyway, it would be nice to provide some example of config space of PCI
Bridge (lspci -x) which is affected by this issue and have it in
pciutils/tests/ directory.

On Friday 21 August 2026 22:15:59 David Matlack wrote:
> Use bridge_flags to determine address size bits (16- vs 32-bit for I/O,
> 32- vs 64-bit for prefetchable memory) when displaying bridge ranges
> populated via PCI_FILL_BRIDGE_BASES.
> 
> Commit ccf68033a452 ("lspci: Use PCI_FILL_BRIDGE_BASES to detect if
> range behind bridge is disabled or unsupported") introduced code in
> show_htype1() that reads PCI_IO_RANGE_TYPE_MASK and
> PCI_MEMORY_RANGE_TYPE_MASK from bridge_base_addr[]. However,
> bridge_base_addr[] holds base addresses without flags, as documented in
> lib/pci.h and implemented across backends like sysfs.c and
> win32-cfgmgr32.c.
> 
> Because bridge_base_addr[] does not contain configuration register flag
> bits, masking the lower bits evaluates to zero. As a result, 32-bit I/O
> windows are mislabeled as "[16-bit]" and 64-bit prefetchable memory
> windows are mislabeled as "[32-bit]" when using PCI_FILL_BRIDGE_BASES.
> 
> Fixes: ccf68033a452 ("lspci: Use PCI_FILL_BRIDGE_BASES to detect if range behind bridge is disabled or unsupported")
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> v2:
>  - Fix lspci.c to use bridge_flags[], per lib/pci.h, rather than
>    changing the behavior of just the sysfs backend (Pali Rohár)
> 
> v1: https://lore.kernel.org/linux-pci/20260626213047.189951-1-bhelgaas@google.com/
> 
>  lspci.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/lspci.c b/lspci.c
> index 2a14303e74f6..52fd9247aefb 100644
> --- a/lspci.c
> +++ b/lspci.c
> @@ -571,10 +571,9 @@ show_htype1(struct device *d)
>  
>    if ((p->known_fields & PCI_FILL_BRIDGE_BASES) && !io_disabled)
>      {
> -      io_base = p->bridge_base_addr[0] & PCI_IO_RANGE_MASK;
> +      io_base = p->bridge_base_addr[0];
>        io_limit = io_base + p->bridge_size[0] - 1;
> -      io_type = p->bridge_base_addr[0] & PCI_IO_RANGE_TYPE_MASK;
> -      io_bits = (io_type == PCI_IO_RANGE_TYPE_32) ? 32 : 16;
> +      io_bits = (p->bridge_flags[0] & PCI_IORESOURCE_IO_16BIT_ADDR) ? 16 : 32;
>        show_range("\tI/O behind bridge", io_base, io_limit, io_bits, io_disabled);
>      }
>    else if (io_type != (io_limit & PCI_IO_RANGE_TYPE_MASK) ||
> @@ -600,7 +599,7 @@ show_htype1(struct device *d)
>  
>    if ((p->known_fields & PCI_FILL_BRIDGE_BASES) && !mem_disabled)
>      {
> -      mem_base = p->bridge_base_addr[1] & PCI_MEMORY_RANGE_MASK;
> +      mem_base = p->bridge_base_addr[1];
>        mem_limit = mem_base + p->bridge_size[1] - 1;
>        show_range("\tMemory behind bridge", mem_base, mem_limit, 32, mem_disabled);
>      }
> @@ -616,10 +615,9 @@ show_htype1(struct device *d)
>  
>    if ((p->known_fields & PCI_FILL_BRIDGE_BASES) && !pref_disabled)
>      {
> -      u64 pref_base_64 = p->bridge_base_addr[2] & PCI_MEMORY_RANGE_MASK;
> +      u64 pref_base_64 = p->bridge_base_addr[2];
>        u64 pref_limit_64 = pref_base_64 + p->bridge_size[2] - 1;
> -      pref_type = p->bridge_base_addr[2] & PCI_MEMORY_RANGE_TYPE_MASK;
> -      pref_bits = (pref_type == PCI_PREF_RANGE_TYPE_64) ? 64 : 32;
> +      pref_bits = (p->bridge_flags[2] & PCI_IORESOURCE_MEM_64) ? 64 : 32;
>        show_range("\tPrefetchable memory behind bridge", pref_base_64, pref_limit_64, pref_bits, pref_disabled);
>      }
>    else if (pref_type != (pref_limit & PCI_PREF_RANGE_TYPE_MASK) ||
> 
> base-commit: b41ce14da749fb44ca7940ba9797027bfa62c23e
> -- 
> 2.55.0.766.g2966f0265a-goog
> 

  reply	other threads:[~2026-08-21 23:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21 22:15 David Matlack
2026-08-21 23:06 ` Pali Rohár [this message]
2026-08-24 16:24   ` David Matlack
2026-08-24 17:36     ` Pali Rohár
2026-08-24 20:22       ` David Matlack
2026-08-24 20:34         ` Pali Rohár
2026-08-24 20:58           ` David Matlack
2026-08-24 20:37 ` Martin Mareš

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=20260821230620.fcpmn7radmwnfnh2@pali \
    --to=pali@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=dmatlack@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mj@ucw.cz \
    /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

all inboxes | Powered by JetHome®