[PATCH i-g-t 0/7] lsgpu: Report upstream port link bandwidth

[PATCH i-g-t 0/7] lsgpu: Report upstream port link bandwidth

[Janusz Krzysztofik]

Users of Intel discrete graphics adapters are confused with fake
information on PCIe link bandwidth (speed and size) of their GPU devices
reported by tools like lspci or lsgpu.  That fake information is
unfortunately provided by hardware, Linux PCI subsystem just exposes it
untouched to upper layers, including userspace via sysfs, and userspace
tools just report those fake values.

While we can't do much about the kernel side or general purpose userspace
tools like lspci, we can try to address the issue with our lsgpu utility.

Correct link bandwidth attributes of a discrete GPU card can be obtained
from the kernel by looking not at the PCI device of the GPU itself, only
at a PCIe upstream port of the card's PCI bridge.  For integrity with
content of the sysfs and with output from the other tools, we are not
going to replace the fake information with that from the bridge upstream
port, only show that port and its attributes themselves while listing
devices.

Since the tool uses our udev based igt_device_scan library for identifying
GPU devices and printing their properties and attributes, modifications
that we need apply to that library.

Janusz Krzysztofik (7):
  lib/igt_device_scan: Don't print fake link bandwidth attributes
  lib/igt_device_scan: Split out reusable part of update_or_add_parent
  lib/igt_device_scan: Include PCIe bridge upstream port if available
  lib/igt_device_scan: List PCIe bridge ports after their children
  lib/igt_device_scan: Omit AER statistics data from attributes
  lib/igt_device_scan: Don't print bridge not applicable attributes
  lib/igt_device_scan: Print GPU upstream port parent/child relations

 lib/igt_device_scan.c | 179 +++++++++++++++++++++++++++++++++++-------
 lib/meson.build       |   2 +
 meson.build           |   1 +
 3 files changed, 153 insertions(+), 29 deletions(-)

-- 
2.52.0

[PATCH i-g-t 1/7] lib/igt_device_scan: Don't print fake link bandwidth attributes

[Janusz Krzysztofik]

Users of Intel discrete graphics adapters are confused with fake
information on PCIe link bandwidth (speed and size) of their GPU devices
reported by tools like lspci or lsgpu.  That fake information is
unfortunately provided by hardware, Linux PCI subsystem just exposes it
untouched to upper layers, including userspace via sysfs, and userspace
tools just report those fake values.

While we can't do much about the kernel side or general purpose userspace
tools like lspci, we can try to address the issue with our lsgpu utility.

Correct link bandwidth attributes of a discrete GPU card can be obtained
from the kernel by looking not at the PCI device of the GPU itself, only
at a PCIe upstream port of the card's PCI bridge.  For integrity with
content of the sysfs and with output from the other tools, we are not
going to replace the fake information with that from the bridge upstream
port, only show that port and its attributes themselves while listing
devices.

Since the tool uses our udev based igt_device_scan library for identifying
GPU devices and printing their properties and attributes, modifications
that we need apply to that library.

As a first step, exclude the fake data from being printed.

Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 lib/igt_device_scan.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index abd8ca209e..7753262a53 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -613,6 +613,14 @@ static void dump_props_and_attrs(const struct igt_device *dev)
 
 	printf("\n[attributes]\n");
 	igt_map_foreach(dev->attrs_map, entry) {
+		/* omit fake link bandwidth attributes */
+		if (dev->dev_type == DEVTYPE_DISCRETE &&
+		    (!strcmp(entry->key, "max_link_speed") ||
+		     !strcmp(entry->key, "max_link_width") ||
+		     !strcmp(entry->key, "current_link_speed") ||
+		     !strcmp(entry->key, "current_link_width")))
+			continue;
+
 		_print_key_value((char *)entry->key, (char *)entry->data);
 	}
 	printf("\n");
-- 
2.52.0

Re: [PATCH i-g-t 1/7] lib/igt_device_scan: Don't print fake link bandwidth attributes

[Sebastian Brzezinka]

On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> Users of Intel discrete graphics adapters are confused with fake
> information on PCIe link bandwidth (speed and size) of their GPU devices
> reported by tools like lspci or lsgpu.  That fake information is
> unfortunately provided by hardware, Linux PCI subsystem just exposes it
> untouched to upper layers, including userspace via sysfs, and userspace
> tools just report those fake values.
>
> While we can't do much about the kernel side or general purpose userspace
> tools like lspci, we can try to address the issue with our lsgpu utility.
>
> Correct link bandwidth attributes of a discrete GPU card can be obtained
> from the kernel by looking not at the PCI device of the GPU itself, only
> at a PCIe upstream port of the card's PCI bridge.  For integrity with
> content of the sysfs and with output from the other tools, we are not
> going to replace the fake information with that from the bridge upstream
> port, only show that port and its attributes themselves while listing
> devices.
>
> Since the tool uses our udev based igt_device_scan library for identifying
> GPU devices and printing their properties and attributes, modifications
> that we need apply to that library.
>
> As a first step, exclude the fake data from being printed.
>
> Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---
>  lib/igt_device_scan.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> index abd8ca209e..7753262a53 100644
> --- a/lib/igt_device_scan.c
> +++ b/lib/igt_device_scan.c
> @@ -613,6 +613,14 @@ static void dump_props_and_attrs(const struct igt_device *dev)
>  
>  	printf("\n[attributes]\n");
>  	igt_map_foreach(dev->attrs_map, entry) {
> +		/* omit fake link bandwidth attributes */
> +		if (dev->dev_type == DEVTYPE_DISCRETE &&
> +		    (!strcmp(entry->key, "max_link_speed") ||
> +		     !strcmp(entry->key, "max_link_width") ||
> +		     !strcmp(entry->key, "current_link_speed") ||
> +		     !strcmp(entry->key, "current_link_width")))
> +			continue;
> +
Nit: This might be a bit confusing now that the return value depends on DEVTYPE_DISCRETE,
especially for a library. I know it’s extra work to keep it generic, but maybe we could
move the check to its own function just to clean things up a bit?

-- 
Best regards,
Sebastian

Re: [PATCH i-g-t 1/7] lib/igt_device_scan: Don't print fake link bandwidth attributes

[Janusz Krzysztofik]

Hi Sebastian,

Thanks for looking at this.

On Friday, 23 January 2026 12:01:54 CET Sebastian Brzezinka wrote:
> On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> > Users of Intel discrete graphics adapters are confused with fake
> > information on PCIe link bandwidth (speed and size) of their GPU devices
> > reported by tools like lspci or lsgpu.  That fake information is
> > unfortunately provided by hardware, Linux PCI subsystem just exposes it
> > untouched to upper layers, including userspace via sysfs, and userspace
> > tools just report those fake values.
> >
> > While we can't do much about the kernel side or general purpose userspace
> > tools like lspci, we can try to address the issue with our lsgpu utility.
> >
> > Correct link bandwidth attributes of a discrete GPU card can be obtained
> > from the kernel by looking not at the PCI device of the GPU itself, only
> > at a PCIe upstream port of the card's PCI bridge.  For integrity with
> > content of the sysfs and with output from the other tools, we are not
> > going to replace the fake information with that from the bridge upstream
> > port, only show that port and its attributes themselves while listing
> > devices.
> >
> > Since the tool uses our udev based igt_device_scan library for identifying
> > GPU devices and printing their properties and attributes, modifications
> > that we need apply to that library.
> >
> > As a first step, exclude the fake data from being printed.
> >
> > Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > ---
> >  lib/igt_device_scan.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> > index abd8ca209e..7753262a53 100644
> > --- a/lib/igt_device_scan.c
> > +++ b/lib/igt_device_scan.c
> > @@ -613,6 +613,14 @@ static void dump_props_and_attrs(const struct igt_device *dev)
> >  
> >  	printf("\n[attributes]\n");
> >  	igt_map_foreach(dev->attrs_map, entry) {
> > +		/* omit fake link bandwidth attributes */
> > +		if (dev->dev_type == DEVTYPE_DISCRETE &&
> > +		    (!strcmp(entry->key, "max_link_speed") ||
> > +		     !strcmp(entry->key, "max_link_width") ||
> > +		     !strcmp(entry->key, "current_link_speed") ||
> > +		     !strcmp(entry->key, "current_link_width")))
> > +			continue;
> > +
> Nit: This might be a bit confusing now that the return value depends on DEVTYPE_DISCRETE,
> especially for a library. I know it’s extra work to keep it generic, but maybe we could
> move the check to its own function just to clean things up a bit?
> 
> 

OK, so you say it's not clear for someone reading this why the exclusion of 
the fake data from print output is limited to discrete graphics adapter.  
Simply because integrated graphics devices don't provide any fake values, they 
respond with "unknown" which I see no reason to also remove from the output.

Since I don't understand how moving that piece of code to a separate function 
could make things more clear, I think I'll better provide the missing details 
about acceptable behavior of integrated devices to my commit description and, 
still better, extend the in-line comment above that piece of code with that 
information.  What do you think?

Thanks,
Janusz

Re: [PATCH i-g-t 1/7] lib/igt_device_scan: Don't print fake link bandwidth attributes

[Sebastian Brzezinka]

On Fri Jan 23, 2026 at 3:10 PM CET, Janusz Krzysztofik wrote:
> Hi Sebastian,
>
> Thanks for looking at this.
>
> On Friday, 23 January 2026 12:01:54 CET Sebastian Brzezinka wrote:
>> On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
>> > Users of Intel discrete graphics adapters are confused with fake
>> > information on PCIe link bandwidth (speed and size) of their GPU devices
>> > reported by tools like lspci or lsgpu.  That fake information is
>> > unfortunately provided by hardware, Linux PCI subsystem just exposes it
>> > untouched to upper layers, including userspace via sysfs, and userspace
>> > tools just report those fake values.
>> >
>> > While we can't do much about the kernel side or general purpose userspace
>> > tools like lspci, we can try to address the issue with our lsgpu utility.
>> >
>> > Correct link bandwidth attributes of a discrete GPU card can be obtained
>> > from the kernel by looking not at the PCI device of the GPU itself, only
>> > at a PCIe upstream port of the card's PCI bridge.  For integrity with
>> > content of the sysfs and with output from the other tools, we are not
>> > going to replace the fake information with that from the bridge upstream
>> > port, only show that port and its attributes themselves while listing
>> > devices.
>> >
>> > Since the tool uses our udev based igt_device_scan library for identifying
>> > GPU devices and printing their properties and attributes, modifications
>> > that we need apply to that library.
>> >
>> > As a first step, exclude the fake data from being printed.
>> >
>> > Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
>> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
>> > ---
>> >  lib/igt_device_scan.c | 8 ++++++++
>> >  1 file changed, 8 insertions(+)
>> >
>> > diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
>> > index abd8ca209e..7753262a53 100644
>> > --- a/lib/igt_device_scan.c
>> > +++ b/lib/igt_device_scan.c
>> > @@ -613,6 +613,14 @@ static void dump_props_and_attrs(const struct igt_device *dev)
>> >  
>> >  	printf("\n[attributes]\n");
>> >  	igt_map_foreach(dev->attrs_map, entry) {
>> > +		/* omit fake link bandwidth attributes */
>> > +		if (dev->dev_type == DEVTYPE_DISCRETE &&
>> > +		    (!strcmp(entry->key, "max_link_speed") ||
>> > +		     !strcmp(entry->key, "max_link_width") ||
>> > +		     !strcmp(entry->key, "current_link_speed") ||
>> > +		     !strcmp(entry->key, "current_link_width")))
>> > +			continue;
>> > +
>> Nit: This might be a bit confusing now that the return value depends on DEVTYPE_DISCRETE,
>> especially for a library. I know it’s extra work to keep it generic, but maybe we could
>> move the check to its own function just to clean things up a bit?
>> 
>> 
>
> OK, so you say it's not clear for someone reading this why the exclusion of 
> the fake data from print output is limited to discrete graphics adapter.  
> Simply because integrated graphics devices don't provide any fake values, they 
> respond with "unknown" which I see no reason to also remove from the output.
>
> Since I don't understand how moving that piece of code to a separate function 
> could make things more clear, I think I'll better provide the missing details 
> about acceptable behavior of integrated devices to my commit description and, 
> still better, extend the in-line comment above that piece of code with that 
> information.  What do you think?
Thanks for the clarification. I left it as a nit since I’m fine with
the change overall. My concern is that this is a library function, and
the update makes it a bit less generic. Changes like this can accumulate
over time, but in this case I might be overthinking it.

-- 
Best regards,
Sebastian

Re: [PATCH i-g-t 1/7] lib/igt_device_scan: Don't print fake link bandwidth attributes

[Janusz Krzysztofik]

On Friday, 23 January 2026 15:20:16 CET Sebastian Brzezinka wrote:
> On Fri Jan 23, 2026 at 3:10 PM CET, Janusz Krzysztofik wrote:
> > Hi Sebastian,
> >
> > Thanks for looking at this.
> >
> > On Friday, 23 January 2026 12:01:54 CET Sebastian Brzezinka wrote:
> >> On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> >> > Users of Intel discrete graphics adapters are confused with fake
> >> > information on PCIe link bandwidth (speed and size) of their GPU devices
> >> > reported by tools like lspci or lsgpu.  That fake information is
> >> > unfortunately provided by hardware, Linux PCI subsystem just exposes it
> >> > untouched to upper layers, including userspace via sysfs, and userspace
> >> > tools just report those fake values.
> >> >
> >> > While we can't do much about the kernel side or general purpose userspace
> >> > tools like lspci, we can try to address the issue with our lsgpu utility.
> >> >
> >> > Correct link bandwidth attributes of a discrete GPU card can be obtained
> >> > from the kernel by looking not at the PCI device of the GPU itself, only
> >> > at a PCIe upstream port of the card's PCI bridge.  For integrity with
> >> > content of the sysfs and with output from the other tools, we are not
> >> > going to replace the fake information with that from the bridge upstream
> >> > port, only show that port and its attributes themselves while listing
> >> > devices.
> >> >
> >> > Since the tool uses our udev based igt_device_scan library for identifying
> >> > GPU devices and printing their properties and attributes, modifications
> >> > that we need apply to that library.
> >> >
> >> > As a first step, exclude the fake data from being printed.
> >> >
> >> > Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
> >> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> >> > ---
> >> >  lib/igt_device_scan.c | 8 ++++++++
> >> >  1 file changed, 8 insertions(+)
> >> >
> >> > diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> >> > index abd8ca209e..7753262a53 100644
> >> > --- a/lib/igt_device_scan.c
> >> > +++ b/lib/igt_device_scan.c
> >> > @@ -613,6 +613,14 @@ static void dump_props_and_attrs(const struct igt_device *dev)
> >> >  
> >> >  	printf("\n[attributes]\n");
> >> >  	igt_map_foreach(dev->attrs_map, entry) {
> >> > +		/* omit fake link bandwidth attributes */
> >> > +		if (dev->dev_type == DEVTYPE_DISCRETE &&
> >> > +		    (!strcmp(entry->key, "max_link_speed") ||
> >> > +		     !strcmp(entry->key, "max_link_width") ||
> >> > +		     !strcmp(entry->key, "current_link_speed") ||
> >> > +		     !strcmp(entry->key, "current_link_width")))
> >> > +			continue;
> >> > +
> >> Nit: This might be a bit confusing now that the return value depends on DEVTYPE_DISCRETE,
> >> especially for a library. I know it’s extra work to keep it generic, but maybe we could
> >> move the check to its own function just to clean things up a bit?
> >> 
> >> 
> >
> > OK, so you say it's not clear for someone reading this why the exclusion of 
> > the fake data from print output is limited to discrete graphics adapter.  
> > Simply because integrated graphics devices don't provide any fake values, they 
> > respond with "unknown" which I see no reason to also remove from the output.
> >
> > Since I don't understand how moving that piece of code to a separate function 
> > could make things more clear, I think I'll better provide the missing details 
> > about acceptable behavior of integrated devices to my commit description and, 
> > still better, extend the in-line comment above that piece of code with that 
> > information.  What do you think?
> Thanks for the clarification. I left it as a nit since I’m fine with
> the change overall. My concern is that this is a library function, and
> the update makes it a bit less generic. Changes like this can accumulate
> over time, but in this case I might be overthinking it.

OK, now I understand better what you could mean by "move the check to its own 
function".  To keep dumps_props_and_attrs() as generic as possible, I can pass 
a flag to it which says "skip link bandwitdh attributes", and hand over the 
decision whether to print them or not to the caller, OK?

Thanks,
Janusz

Re: [PATCH i-g-t 1/7] lib/igt_device_scan: Don't print fake link bandwidth attributes

[Sebastian Brzezinka]

On Fri Jan 23, 2026 at 3:42 PM CET, Janusz Krzysztofik wrote:
> On Friday, 23 January 2026 15:20:16 CET Sebastian Brzezinka wrote:
>> On Fri Jan 23, 2026 at 3:10 PM CET, Janusz Krzysztofik wrote:
>> > Hi Sebastian,
>> >
>> > Thanks for looking at this.
>> >
>> > On Friday, 23 January 2026 12:01:54 CET Sebastian Brzezinka wrote:
>> >> On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
>> >> > Users of Intel discrete graphics adapters are confused with fake
>> >> > information on PCIe link bandwidth (speed and size) of their GPU devices
>> >> > reported by tools like lspci or lsgpu.  That fake information is
>> >> > unfortunately provided by hardware, Linux PCI subsystem just exposes it
>> >> > untouched to upper layers, including userspace via sysfs, and userspace
>> >> > tools just report those fake values.
>> >> >
>> >> > While we can't do much about the kernel side or general purpose userspace
>> >> > tools like lspci, we can try to address the issue with our lsgpu utility.
>> >> >
>> >> > Correct link bandwidth attributes of a discrete GPU card can be obtained
>> >> > from the kernel by looking not at the PCI device of the GPU itself, only
>> >> > at a PCIe upstream port of the card's PCI bridge.  For integrity with
>> >> > content of the sysfs and with output from the other tools, we are not
>> >> > going to replace the fake information with that from the bridge upstream
>> >> > port, only show that port and its attributes themselves while listing
>> >> > devices.
>> >> >
>> >> > Since the tool uses our udev based igt_device_scan library for identifying
>> >> > GPU devices and printing their properties and attributes, modifications
>> >> > that we need apply to that library.
>> >> >
>> >> > As a first step, exclude the fake data from being printed.
>> >> >
>> >> > Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
>> >> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
>> >> > ---
>> >> >  lib/igt_device_scan.c | 8 ++++++++
>> >> >  1 file changed, 8 insertions(+)
>> >> >
>> >> > diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
>> >> > index abd8ca209e..7753262a53 100644
>> >> > --- a/lib/igt_device_scan.c
>> >> > +++ b/lib/igt_device_scan.c
>> >> > @@ -613,6 +613,14 @@ static void dump_props_and_attrs(const struct igt_device *dev)
>> >> >  
>> >> >  	printf("\n[attributes]\n");
>> >> >  	igt_map_foreach(dev->attrs_map, entry) {
>> >> > +		/* omit fake link bandwidth attributes */
>> >> > +		if (dev->dev_type == DEVTYPE_DISCRETE &&
>> >> > +		    (!strcmp(entry->key, "max_link_speed") ||
>> >> > +		     !strcmp(entry->key, "max_link_width") ||
>> >> > +		     !strcmp(entry->key, "current_link_speed") ||
>> >> > +		     !strcmp(entry->key, "current_link_width")))
>> >> > +			continue;
>> >> > +
>> >> Nit: This might be a bit confusing now that the return value depends on DEVTYPE_DISCRETE,
>> >> especially for a library. I know it’s extra work to keep it generic, but maybe we could
>> >> move the check to its own function just to clean things up a bit?
>> >> 
>> >> 
>> >
>> > OK, so you say it's not clear for someone reading this why the exclusion of 
>> > the fake data from print output is limited to discrete graphics adapter.  
>> > Simply because integrated graphics devices don't provide any fake values, they 
>> > respond with "unknown" which I see no reason to also remove from the output.
>> >
>> > Since I don't understand how moving that piece of code to a separate function 
>> > could make things more clear, I think I'll better provide the missing details 
>> > about acceptable behavior of integrated devices to my commit description and, 
>> > still better, extend the in-line comment above that piece of code with that 
>> > information.  What do you think?
>> Thanks for the clarification. I left it as a nit since I’m fine with
>> the change overall. My concern is that this is a library function, and
>> the update makes it a bit less generic. Changes like this can accumulate
>> over time, but in this case I might be overthinking it.
>
> OK, now I understand better what you could mean by "move the check to its own 
> function".  To keep dumps_props_and_attrs() as generic as possible, I can pass 
> a flag to it which says "skip link bandwitdh attributes", and hand over the 
> decision whether to print them or not to the caller, OK?
I’m okay with it. Looking at the rest of the library, I may have been
overthinking it. This library was never meant to be fully generic, so
if no one else has an issue with this approach, neither do I. Sorry for
the confusion.

-- 
Best regards,
Sebastian

[PATCH i-g-t 2/7] lib/igt_device_scan: Split out reusable part of update_or_add_parent

[Janusz Krzysztofik]

Users of Intel discrete graphics adapters are confused with fake
information on PCIe link bandwidth (speed and size) of their GPU devices
reported by sysfs and userspace tools, including our lsgpu utility.  In
order for the lsgpu to show correct link bandwidth information, we need to
identify an upstream port of a PCIe bridge that sits on the GPU card and
get that information from that port.

Since the tool uses our udev based igt_device_scan library for identifying
GPU devices and printing their properties and attributes, modifications
that we need apply to that library.

Refactor the library so a part of it can be reused for processing the
bridge port.

There are no functional changes introduced with this patch.

Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 lib/igt_device_scan.c | 68 ++++++++++++++++++++++++++-----------------
 1 file changed, 41 insertions(+), 27 deletions(-)

diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index 7753262a53..d3a2ebe8d2 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -910,32 +910,20 @@ static struct igt_device *igt_device_from_syspath(const char *syspath)
 }
 
 #define RETRIES_GET_PARENT 5
-/* For each drm igt_device add or update its parent igt_device to the array.
- * As card/render drm devices mostly have same parent (vkms is an exception)
- * link to it and update corresponding drm_card / drm_render fields.
- */
-static void update_or_add_parent(struct udev *udev,
-				 struct udev_device *dev,
-				 struct igt_device *idev,
-				 bool limit_attrs)
+
+static struct igt_device *find_or_add_igt_device(struct udev *udev,
+						 struct udev_device *dev,
+						 bool limit_attrs)
 {
-	struct udev_device *parent_dev;
-	struct igt_device *parent_idev;
-	const char *subsystem, *syspath, *devname;
 	int retries = RETRIES_GET_PARENT;
+	const char *subsystem, *syspath;
+	struct igt_device *idev;
 
-	/*
-	 * Get parent for drm node. It caches parent in udev device
-	 * and will be destroyed along with the node.
-	 */
-	parent_dev = udev_device_get_parent(dev);
-	igt_assert(parent_dev);
-
-	subsystem = udev_device_get_subsystem(parent_dev);
-	syspath = udev_device_get_syspath(parent_dev);
+	subsystem = udev_device_get_subsystem(dev);
+	syspath = udev_device_get_syspath(dev);
 
-	parent_idev = igt_device_find(subsystem, syspath);
-	while (!parent_idev && retries--) {
+	idev = igt_device_find(subsystem, syspath);
+	while (!idev && retries--) {
 		/*
 		 * Don't care about previous parent_dev, it is tracked
 		 * by the child node. There's very rare race when driver module
@@ -947,15 +935,41 @@ static void update_or_add_parent(struct udev *udev,
 		 * only udev_device_new*() will scan sys directory and
 		 * return fresh udev device.
 		 */
-		parent_dev = udev_device_new_from_syspath(udev, syspath);
-		parent_idev = igt_device_new_from_udev(parent_dev, limit_attrs);
-		udev_device_unref(parent_dev);
+		dev = udev_device_new_from_syspath(udev, syspath);
+		idev = igt_device_new_from_udev(dev, limit_attrs);
+		udev_device_unref(dev);
 
-		if (parent_idev)
-			igt_list_add_tail(&parent_idev->link, &igt_devs.all);
+		if (idev)
+			igt_list_add_tail(&idev->link, &igt_devs.all);
 		else
 			usleep(100000); /* arbitrary, 100ms should be enough */
 	}
+
+	return idev;
+}
+
+/*
+ * For each drm igt_device add or update its parent igt_device to the array.
+ * As card/render drm devices mostly have same parent (vkms is an exception)
+ * link to it and update corresponding drm_card / drm_render fields.
+ */
+static void update_or_add_parent(struct udev *udev,
+				 struct udev_device *dev,
+				 struct igt_device *idev,
+				 bool limit_attrs)
+{
+	struct udev_device *parent_dev;
+	struct igt_device *parent_idev;
+	const char *devname;
+
+	/*
+	 * Get parent for drm node. It caches parent in udev device
+	 * and will be destroyed along with the node.
+	 */
+	parent_dev = udev_device_get_parent(dev);
+	igt_assert(parent_dev);
+
+	parent_idev = find_or_add_igt_device(udev, parent_dev, limit_attrs);
 	igt_assert(parent_idev);
 
 	devname = udev_device_get_devnode(dev);
-- 
2.52.0

Re: [PATCH i-g-t 2/7] lib/igt_device_scan: Split out reusable part of update_or_add_parent

[Sebastian Brzezinka]

Hi Janusz,

On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> Users of Intel discrete graphics adapters are confused with fake
> information on PCIe link bandwidth (speed and size) of their GPU devices
> reported by sysfs and userspace tools, including our lsgpu utility.  In
> order for the lsgpu to show correct link bandwidth information, we need to
> identify an upstream port of a PCIe bridge that sits on the GPU card and
> get that information from that port.
>
> Since the tool uses our udev based igt_device_scan library for identifying
> GPU devices and printing their properties and attributes, modifications
> that we need apply to that library.
>
> Refactor the library so a part of it can be reused for processing the
> bridge port.
>
> There are no functional changes introduced with this patch.
>
> Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---
Straightforward refactor. Looks good!
Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>

-- 
Best regards,
Sebastian

[PATCH i-g-t 3/7] lib/igt_device_scan: Include PCIe bridge upstream port if available

[Janusz Krzysztofik]

Users of Intel discrete graphics adapters are confused with fake
information on PCIe link bandwidth (speed and size) of their GPU devices
reported by sysfs and userspace tools, including our lsgpu utility.  In
order for the lsgpu to show correct link bandwidth information, we need to
identify an upstream port of a PCIe bridge that sits on the GPU card and
get that information from that port.

Since the tool uses our udev based igt_device_scan library for identifying
GPU devices and printing their properties and attributes, modifications
that we need apply to that library.

When scanning for DRM devices and their PCI parents, the lsgpu utility
requests collection of all their attributes.  When running in this mode,
also try to collect information about upstream ports of PCIe bridges of
discrete GPU devices.  Once collected, the lsgpu utility will show that
information automatically while listing the devices.

While IGT tests are using pciaccess library for processing PCI devices,
that library requires careful handling in order to avoid collisions among
multiple processes or threads potentially using it.  That protection is
implemented in igt_device with help of IGT exit handlers. That requires
linking with full igt_core library code, while the lsgpu tool now depends
neither on igt_device nor on igt_core.  To keep that independence,
implement the new code around libpci.  With that approach, refactoring of
IGT use of pciaccess is avoided.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 lib/igt_device_scan.c | 73 +++++++++++++++++++++++++++++++++++++++++--
 lib/meson.build       |  2 ++
 meson.build           |  1 +
 3 files changed, 74 insertions(+), 2 deletions(-)

diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index d3a2ebe8d2..34c7a8131b 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -36,6 +36,7 @@
 #ifdef __linux__
 #include <linux/limits.h>
 #endif
+#include <pci/pci.h>
 #include <sys/stat.h>
 #include <sys/time.h>
 #include <sys/types.h>
@@ -909,6 +910,27 @@ static struct igt_device *igt_device_from_syspath(const char *syspath)
 	return NULL;
 }
 
+static bool is_pcie_upstream_bridge(struct pci_dev *dev)
+{
+	struct pci_cap *pcie;
+	uint8_t type, dir;
+
+	type = pci_read_byte(dev, PCI_HEADER_TYPE) & 0x7f;
+	if (type != PCI_HEADER_TYPE_BRIDGE)
+		return false;
+
+	pcie = pci_find_cap(dev, PCI_CAP_ID_EXP, PCI_CAP_NORMAL);
+	if (!pcie)
+		return false;
+
+	/* GET_REG_MASK macro borrowed from pciutils' internal bitops.h */
+#define GET_REG_MASK(reg, mask) (((reg) & (mask)) / ((mask) & ~((mask) << 1)))
+	dir = GET_REG_MASK(pci_read_word(dev, pcie->addr + PCI_EXP_FLAGS), PCI_EXP_FLAGS_TYPE);
+#undef GET_REG_MASK
+
+	return dir == PCI_EXP_TYPE_UPSTREAM;
+}
+
 #define RETRIES_GET_PARENT 5
 
 static struct igt_device *find_or_add_igt_device(struct udev *udev,
@@ -948,18 +970,55 @@ static struct igt_device *find_or_add_igt_device(struct udev *udev,
 	return idev;
 }
 
+static struct udev_device *get_pcie_upstream_bridge(struct udev *udev,
+						    struct udev_device *dev)
+{
+	struct pci_access *pacc;
+
+	pacc = pci_alloc();
+	pci_init(pacc);
+
+	for (dev = udev_device_get_parent(dev); dev; dev = udev_device_get_parent(dev)) {
+		struct pci_filter filter;
+		struct pci_dev *pci_dev;
+		const char *slot;
+
+		slot = udev_device_get_property_value(dev, "PCI_SLOT_NAME");
+		if (igt_debug_on(!slot))
+			continue;
+
+		pci_filter_init(pacc, &filter);
+		if (igt_debug_on(pci_filter_parse_slot(&filter, (char *)slot)))
+			continue;
+
+		pci_dev = pci_get_dev(pacc, filter.domain, filter.bus, filter.slot, filter.func);
+		if (igt_debug_on(!pci_dev))
+			continue;
+
+		if (is_pcie_upstream_bridge(pci_dev))
+			break;
+	}
+
+	pci_cleanup(pacc);
+
+	return dev;
+}
+
 /*
  * For each drm igt_device add or update its parent igt_device to the array.
  * As card/render drm devices mostly have same parent (vkms is an exception)
  * link to it and update corresponding drm_card / drm_render fields.
+ *
+ * If collecting all attributes and the parent is a discrete GPU then also
+ * add or update its bridge's upstream port.
  */
 static void update_or_add_parent(struct udev *udev,
 				 struct udev_device *dev,
 				 struct igt_device *idev,
 				 bool limit_attrs)
 {
-	struct udev_device *parent_dev;
-	struct igt_device *parent_idev;
+	struct igt_device *parent_idev, *bridge_idev;
+	struct udev_device *parent_dev, *bridge_dev;
 	const char *devname;
 
 	/*
@@ -979,6 +1038,16 @@ static void update_or_add_parent(struct udev *udev,
 		parent_idev->drm_render = strdup(devname);
 
 	idev->parent = parent_idev;
+
+	if (limit_attrs || parent_idev->dev_type != DEVTYPE_DISCRETE)
+		return;
+
+	bridge_dev = get_pcie_upstream_bridge(udev, parent_dev);
+	if (!bridge_dev)
+		return;
+
+	bridge_idev = find_or_add_igt_device(udev, bridge_dev, limit_attrs);
+	igt_assert(bridge_idev);
 }
 
 static struct igt_device *duplicate_device(struct igt_device *dev) {
diff --git a/lib/meson.build b/lib/meson.build
index 1a569ba52a..d10e1405ac 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -139,6 +139,7 @@ lib_deps = [
 	libdrm,
 	libdw,
 	libkmod,
+	libpci,
 	libudev,
 	math,
 	pciaccess,
@@ -332,6 +333,7 @@ lib_igt_perf = declare_dependency(link_with : lib_igt_perf_build,
 
 scan_dep = [
 	glib,
+	libpci,
 	libudev,
 ]
 
diff --git a/meson.build b/meson.build
index 4b2496c016..57849648a3 100644
--- a/meson.build
+++ b/meson.build
@@ -162,6 +162,7 @@ endif
 build_info += 'Valgrind annotations: @0@'.format(valgrind.found())
 
 cairo = dependency('cairo', version : '>1.12.0', required : true)
+libpci = dependency('libpci', required : true)
 libudev = dependency('libudev', required : true)
 glib = dependency('glib-2.0', required : true)
 
-- 
2.52.0

Re: [PATCH i-g-t 3/7] lib/igt_device_scan: Include PCIe bridge upstream port if available

[Sebastian Brzezinka]

Hi Janusz,

On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> Users of Intel discrete graphics adapters are confused with fake
> information on PCIe link bandwidth (speed and size) of their GPU devices
> reported by sysfs and userspace tools, including our lsgpu utility.  In
> order for the lsgpu to show correct link bandwidth information, we need to
> identify an upstream port of a PCIe bridge that sits on the GPU card and
> get that information from that port.
>
> Since the tool uses our udev based igt_device_scan library for identifying
> GPU devices and printing their properties and attributes, modifications
> that we need apply to that library.
>
> When scanning for DRM devices and their PCI parents, the lsgpu utility
> requests collection of all their attributes.  When running in this mode,
> also try to collect information about upstream ports of PCIe bridges of
> discrete GPU devices.  Once collected, the lsgpu utility will show that
> information automatically while listing the devices.
>
> While IGT tests are using pciaccess library for processing PCI devices,
> that library requires careful handling in order to avoid collisions among
> multiple processes or threads potentially using it.  That protection is
> implemented in igt_device with help of IGT exit handlers. That requires
> linking with full igt_core library code, while the lsgpu tool now depends
> neither on igt_device nor on igt_core.  To keep that independence,
> implement the new code around libpci.  With that approach, refactoring of
> IGT use of pciaccess is avoided.
>
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---
>  lib/igt_device_scan.c | 73 +++++++++++++++++++++++++++++++++++++++++--
>  lib/meson.build       |  2 ++
>  meson.build           |  1 +
>  3 files changed, 74 insertions(+), 2 deletions(-)
>
> diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> index d3a2ebe8d2..34c7a8131b 100644
> --- a/lib/igt_device_scan.c
> +++ b/lib/igt_device_scan.c
> @@ -36,6 +36,7 @@
>  #ifdef __linux__
>  #include <linux/limits.h>
>  #endif
> +#include <pci/pci.h>
>  #include <sys/stat.h>
>  #include <sys/time.h>
>  #include <sys/types.h>
> @@ -909,6 +910,27 @@ static struct igt_device *igt_device_from_syspath(const char *syspath)
>  	return NULL;
>  }
>  
> +static bool is_pcie_upstream_bridge(struct pci_dev *dev)
> +{
> +	struct pci_cap *pcie;
> +	uint8_t type, dir;
> +
> +	type = pci_read_byte(dev, PCI_HEADER_TYPE) & 0x7f;
> +	if (type != PCI_HEADER_TYPE_BRIDGE)
> +		return false;
> +
> +	pcie = pci_find_cap(dev, PCI_CAP_ID_EXP, PCI_CAP_NORMAL);
> +	if (!pcie)
> +		return false;
> +
> +	/* GET_REG_MASK macro borrowed from pciutils' internal bitops.h */
> +#define GET_REG_MASK(reg, mask) (((reg) & (mask)) / ((mask) & ~((mask) << 1)))
> +	dir = GET_REG_MASK(pci_read_word(dev, pcie->addr + PCI_EXP_FLAGS), PCI_EXP_FLAGS_TYPE);
> +#undef GET_REG_MASK
Instead of copying the macro, we could just use: 
	type = ( pci_read_word... & PCI_EXP_FLAGS_TYPE) >> 4. This seems cleaner.

> +
> +	return dir == PCI_EXP_TYPE_UPSTREAM;
> +}
> +
>  #define RETRIES_GET_PARENT 5
>  
>  static struct igt_device *find_or_add_igt_device(struct udev *udev,
> @@ -948,18 +970,55 @@ static struct igt_device *find_or_add_igt_device(struct udev *udev,
>  	return idev;
>  }
>  
> +static struct udev_device *get_pcie_upstream_bridge(struct udev *udev,
> +						    struct udev_device *dev)
> +{
> +	struct pci_access *pacc;
> +
> +	pacc = pci_alloc();
> +	pci_init(pacc);
> +
I'm not entirely familiar with this pci library, but is it necessary to initialize it
for every device? It might be more efficient to do it once in scan_drm_devices.

-- 
Best regards,
Sebastian

Re: [PATCH i-g-t 3/7] lib/igt_device_scan: Include PCIe bridge upstream port if available

[Janusz Krzysztofik]

Hi Sebastian,

On Friday, 23 January 2026 12:02:30 CET Sebastian Brzezinka wrote:
> Hi Janusz,
> 
> On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> > Users of Intel discrete graphics adapters are confused with fake
> > information on PCIe link bandwidth (speed and size) of their GPU devices
> > reported by sysfs and userspace tools, including our lsgpu utility.  In
> > order for the lsgpu to show correct link bandwidth information, we need to
> > identify an upstream port of a PCIe bridge that sits on the GPU card and
> > get that information from that port.
> >
> > Since the tool uses our udev based igt_device_scan library for identifying
> > GPU devices and printing their properties and attributes, modifications
> > that we need apply to that library.
> >
> > When scanning for DRM devices and their PCI parents, the lsgpu utility
> > requests collection of all their attributes.  When running in this mode,
> > also try to collect information about upstream ports of PCIe bridges of
> > discrete GPU devices.  Once collected, the lsgpu utility will show that
> > information automatically while listing the devices.
> >
> > While IGT tests are using pciaccess library for processing PCI devices,
> > that library requires careful handling in order to avoid collisions among
> > multiple processes or threads potentially using it.  That protection is
> > implemented in igt_device with help of IGT exit handlers. That requires
> > linking with full igt_core library code, while the lsgpu tool now depends
> > neither on igt_device nor on igt_core.  To keep that independence,
> > implement the new code around libpci.  With that approach, refactoring of
> > IGT use of pciaccess is avoided.
> >
> > Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > ---
> >  lib/igt_device_scan.c | 73 +++++++++++++++++++++++++++++++++++++++++--
> >  lib/meson.build       |  2 ++
> >  meson.build           |  1 +
> >  3 files changed, 74 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> > index d3a2ebe8d2..34c7a8131b 100644
> > --- a/lib/igt_device_scan.c
> > +++ b/lib/igt_device_scan.c
> > @@ -36,6 +36,7 @@
> >  #ifdef __linux__
> >  #include <linux/limits.h>
> >  #endif
> > +#include <pci/pci.h>
> >  #include <sys/stat.h>
> >  #include <sys/time.h>
> >  #include <sys/types.h>
> > @@ -909,6 +910,27 @@ static struct igt_device *igt_device_from_syspath(const char *syspath)
> >  	return NULL;
> >  }
> >  
> > +static bool is_pcie_upstream_bridge(struct pci_dev *dev)
> > +{
> > +	struct pci_cap *pcie;
> > +	uint8_t type, dir;
> > +
> > +	type = pci_read_byte(dev, PCI_HEADER_TYPE) & 0x7f;
> > +	if (type != PCI_HEADER_TYPE_BRIDGE)
> > +		return false;
> > +
> > +	pcie = pci_find_cap(dev, PCI_CAP_ID_EXP, PCI_CAP_NORMAL);
> > +	if (!pcie)
> > +		return false;
> > +
> > +	/* GET_REG_MASK macro borrowed from pciutils' internal bitops.h */
> > +#define GET_REG_MASK(reg, mask) (((reg) & (mask)) / ((mask) & ~((mask) << 1)))
> > +	dir = GET_REG_MASK(pci_read_word(dev, pcie->addr + PCI_EXP_FLAGS), PCI_EXP_FLAGS_TYPE);
> > +#undef GET_REG_MASK
> Instead of copying the macro, we could just use: 
> 	type = ( pci_read_word... & PCI_EXP_FLAGS_TYPE) >> 4. This seems cleaner.

I guess it took you a bit of time to understand how that macro works, so it 
did to me :-).  Then OK, let's use the more clear but correct looking version 
you propose, even if it's not clear to me why they did it that way, less 
clear, more complicated.

> 
> > +
> > +	return dir == PCI_EXP_TYPE_UPSTREAM;
> > +}
> > +
> >  #define RETRIES_GET_PARENT 5
> >  
> >  static struct igt_device *find_or_add_igt_device(struct udev *udev,
> > @@ -948,18 +970,55 @@ static struct igt_device *find_or_add_igt_device(struct udev *udev,
> >  	return idev;
> >  }
> >  
> > +static struct udev_device *get_pcie_upstream_bridge(struct udev *udev,
> > +						    struct udev_device *dev)
> > +{
> > +	struct pci_access *pacc;
> > +
> > +	pacc = pci_alloc();
> > +	pci_init(pacc);
> > +
> I'm not entirely familiar with this pci library, but is it necessary to initialize it
> for every device? It might be more efficient to do it once in scan_drm_devices.

OK, you've got it.

Thanks,
Janusz

[PATCH i-g-t 4/7] lib/igt_device_scan: List PCIe bridge ports after their children

[Janusz Krzysztofik]

Current device sorting algorithm positions PCIe bridge upstream ports
between DRM and PCI devices of their GPU children.  Listing those two not
interleaved with bridge ports, and the ports following their PCI GPU
devices, seems more clear.  Go for it.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 lib/igt_device_scan.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index 34c7a8131b..61f507a06d 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -23,6 +23,7 @@
  */
 
 #include "drmtest.h"
+#include "igt_aux.h"
 #include "igt_core.h"
 #include "igt_device_scan.h"
 #include "igt_list.h"
@@ -1061,6 +1062,7 @@ static struct igt_device *duplicate_device(struct igt_device *dev) {
 static int devs_compare(const void *a, const void *b)
 {
 	struct igt_device *dev1, *dev2;
+	unsigned int len1, len2;
 	int ret;
 
 	dev1 = *(struct igt_device **) a;
@@ -1069,6 +1071,12 @@ static int devs_compare(const void *a, const void *b)
 	if (ret)
 		return ret;
 
+	len1 = strlen(dev1->syspath);
+	len2 = strlen(dev2->syspath);
+
+	if (len1 != len2 && !strncmp(dev1->syspath, dev2->syspath, min(len1, len2)))
+		return len2 - len1;
+
 	return strcmp(dev1->syspath, dev2->syspath);
 }
 
-- 
2.52.0

Re: [PATCH i-g-t 4/7] lib/igt_device_scan: List PCIe bridge ports after their children

[Sebastian Brzezinka]

On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> Current device sorting algorithm positions PCIe bridge upstream ports
> between DRM and PCI devices of their GPU children.  Listing those two not
> interleaved with bridge ports, and the ports following their PCI GPU
> devices, seems more clear.  Go for it.
>
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---
>  lib/igt_device_scan.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> index 34c7a8131b..61f507a06d 100644
> --- a/lib/igt_device_scan.c
> +++ b/lib/igt_device_scan.c
> @@ -23,6 +23,7 @@
>   */
>  
>  #include "drmtest.h"
> +#include "igt_aux.h"
>  #include "igt_core.h"
>  #include "igt_device_scan.h"
>  #include "igt_list.h"
> @@ -1061,6 +1062,7 @@ static struct igt_device *duplicate_device(struct igt_device *dev) {
>  static int devs_compare(const void *a, const void *b)
>  {
>  	struct igt_device *dev1, *dev2;
> +	unsigned int len1, len2;
>  	int ret;
>  
>  	dev1 = *(struct igt_device **) a;
> @@ -1069,6 +1071,12 @@ static int devs_compare(const void *a, const void *b)
>  	if (ret)
>  		return ret;
>  
> +	len1 = strlen(dev1->syspath);
> +	len2 = strlen(dev2->syspath);
> +
> +	if (len1 != len2 && !strncmp(dev1->syspath, dev2->syspath, min(len1, len2)))
> +		return len2 - len1;
> +
>  	return strcmp(dev1->syspath, dev2->syspath);
>  }
>  
Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
-- 
Best regards,
Sebastian

[PATCH i-g-t 5/7] lib/igt_device_scan: Omit AER statistics data from attributes

[Janusz Krzysztofik]

Among attributes of a PCIe bridge upstream port of a discrete graphics
card, there are three AER statistics attributes: aer_dev_correctable,
aer_dev_nonfatal and aer_dev_fatal.  Each consists of a number of key-
value pairs, while the library now expects only single value attributes.
That affects formatting of lsgpu -p output.  In order to print that data
correctly in a human readable form, extra formatting effort would be
needed.  However, users of lsgpu, the only call site of that printing
function of the igt_device_scan library, are not necessarily interested in
that data.  Just drop those attributes from the printout.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 lib/igt_device_scan.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index 61f507a06d..7c58ab84e8 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -623,6 +623,12 @@ static void dump_props_and_attrs(const struct igt_device *dev)
 		     !strcmp(entry->key, "current_link_width")))
 			continue;
 
+		/* omit multi-line AER statistics data */
+		if (!strcmp(entry->key, "aer_dev_correctable") ||
+		    !strcmp(entry->key, "aer_dev_nonfatal") ||
+		    !strcmp(entry->key, "aer_dev_fatal"))
+			continue;
+
 		_print_key_value((char *)entry->key, (char *)entry->data);
 	}
 	printf("\n");
-- 
2.52.0

[PATCH i-g-t 6/7] lib/igt_device_scan: Don't print bridge not applicable attributes

[Janusz Krzysztofik]

In addition to properties and attributes obtained from udev, print
functions also list some library specific attributes: drm_card,
drm_render and codename.  Those not necessarily make sense for PCIe
bridge upstream ports that follow their PCI GPU devices on the listing.
Skip them.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 lib/igt_device_scan.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index 7c58ab84e8..e86da001a9 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -204,6 +204,7 @@ enum dev_type {
 	DEVTYPE_ALL,
 	DEVTYPE_INTEGRATED,
 	DEVTYPE_DISCRETE,
+	DEVTYPE_BRIDGE,
 };
 
 #define STR_INTEGRATED "integrated"
@@ -1055,6 +1056,8 @@ static void update_or_add_parent(struct udev *udev,
 
 	bridge_idev = find_or_add_igt_device(udev, bridge_dev, limit_attrs);
 	igt_assert(bridge_idev);
+
+	bridge_idev->dev_type = DEVTYPE_BRIDGE;
 }
 
 static struct igt_device *duplicate_device(struct igt_device *dev) {
@@ -1313,7 +1316,8 @@ igt_devs_print_simple(struct igt_list_head *view,
 			if (is_pci_subsystem(dev)) {
 				_pr_simple("vendor", dev->vendor);
 				_pr_simple("device", dev->device);
-				_pr_simple("codename", dev->codename);
+				if (dev->dev_type != DEVTYPE_BRIDGE)
+					_pr_simple("codename", dev->codename);
 			}
 		}
 		printf("\n");
@@ -1465,7 +1469,7 @@ igt_devs_print_detail(struct igt_list_head *view,
 	igt_list_for_each_entry(dev, view, link) {
 		printf("========== %s:%s ==========\n",
 		       dev->subsystem, dev->syspath);
-		if (!is_drm_subsystem(dev)) {
+		if (!is_drm_subsystem(dev) && dev->dev_type != DEVTYPE_BRIDGE) {
 			_print_key_value("card device", dev->drm_card);
 			_print_key_value("render device", dev->drm_render);
 			_print_key_value("codename", dev->codename);
-- 
2.52.0

Re: [PATCH i-g-t 6/7] lib/igt_device_scan: Don't print bridge not applicable attributes

[Sebastian Brzezinka]

Hi Janusz,

On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> In addition to properties and attributes obtained from udev, print
> functions also list some library specific attributes: drm_card,
> drm_render and codename.  Those not necessarily make sense for PCIe
> bridge upstream ports that follow their PCI GPU devices on the listing.
> Skip them.
>
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---
>  lib/igt_device_scan.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> index 7c58ab84e8..e86da001a9 100644
> --- a/lib/igt_device_scan.c
> +++ b/lib/igt_device_scan.c
> @@ -204,6 +204,7 @@ enum dev_type {
>  	DEVTYPE_ALL,
>  	DEVTYPE_INTEGRATED,
>  	DEVTYPE_DISCRETE,
> +	DEVTYPE_BRIDGE,
>  };
>  
>  #define STR_INTEGRATED "integrated"
> @@ -1055,6 +1056,8 @@ static void update_or_add_parent(struct udev *udev,
>  
>  	bridge_idev = find_or_add_igt_device(udev, bridge_dev, limit_attrs);
>  	igt_assert(bridge_idev);
> +
> +	bridge_idev->dev_type = DEVTYPE_BRIDGE;
>  }
>  
>  static struct igt_device *duplicate_device(struct igt_device *dev) {
> @@ -1313,7 +1316,8 @@ igt_devs_print_simple(struct igt_list_head *view,
>  			if (is_pci_subsystem(dev)) {
>  				_pr_simple("vendor", dev->vendor);
>  				_pr_simple("device", dev->device);
> -				_pr_simple("codename", dev->codename);
> +				if (dev->dev_type != DEVTYPE_BRIDGE)
> +					_pr_simple("codename", dev->codename);
>  			}
>  		}
>  		printf("\n");
> @@ -1465,7 +1469,7 @@ igt_devs_print_detail(struct igt_list_head *view,
>  	igt_list_for_each_entry(dev, view, link) {
>  		printf("========== %s:%s ==========\n",
>  		       dev->subsystem, dev->syspath);
> -		if (!is_drm_subsystem(dev)) {
> +		if (!is_drm_subsystem(dev) && dev->dev_type != DEVTYPE_BRIDGE) {
>  			_print_key_value("card device", dev->drm_card);
>  			_print_key_value("render device", dev->drm_render);
>  			_print_key_value("codename", dev->codename);

Could this be merged with patch 7? Most of this will be removed in the next patch anyway.

-- 
Best regards,
Sebastian

Re: [PATCH i-g-t 6/7] lib/igt_device_scan: Don't print bridge not applicable attributes

[Janusz Krzysztofik]

Hi Sebastian,

On Friday, 23 January 2026 12:03:09 CET Sebastian Brzezinka wrote:
> Hi Janusz,
> 
> On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> > In addition to properties and attributes obtained from udev, print
> > functions also list some library specific attributes: drm_card,
> > drm_render and codename.  Those not necessarily make sense for PCIe
> > bridge upstream ports that follow their PCI GPU devices on the listing.
> > Skip them.
> >
> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > ---
> >  lib/igt_device_scan.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> > index 7c58ab84e8..e86da001a9 100644
> > --- a/lib/igt_device_scan.c
> > +++ b/lib/igt_device_scan.c
> > @@ -204,6 +204,7 @@ enum dev_type {
> >  	DEVTYPE_ALL,
> >  	DEVTYPE_INTEGRATED,
> >  	DEVTYPE_DISCRETE,
> > +	DEVTYPE_BRIDGE,
> >  };
> >  
> >  #define STR_INTEGRATED "integrated"
> > @@ -1055,6 +1056,8 @@ static void update_or_add_parent(struct udev *udev,
> >  
> >  	bridge_idev = find_or_add_igt_device(udev, bridge_dev, limit_attrs);
> >  	igt_assert(bridge_idev);
> > +
> > +	bridge_idev->dev_type = DEVTYPE_BRIDGE;
> >  }
> >  
> >  static struct igt_device *duplicate_device(struct igt_device *dev) {
> > @@ -1313,7 +1316,8 @@ igt_devs_print_simple(struct igt_list_head *view,
> >  			if (is_pci_subsystem(dev)) {
> >  				_pr_simple("vendor", dev->vendor);
> >  				_pr_simple("device", dev->device);
> > -				_pr_simple("codename", dev->codename);
> > +				if (dev->dev_type != DEVTYPE_BRIDGE)
> > +					_pr_simple("codename", dev->codename);
> >  			}
> >  		}
> >  		printf("\n");
> > @@ -1465,7 +1469,7 @@ igt_devs_print_detail(struct igt_list_head *view,
> >  	igt_list_for_each_entry(dev, view, link) {
> >  		printf("========== %s:%s ==========\n",
> >  		       dev->subsystem, dev->syspath);
> > -		if (!is_drm_subsystem(dev)) {
> > +		if (!is_drm_subsystem(dev) && dev->dev_type != DEVTYPE_BRIDGE) {
> >  			_print_key_value("card device", dev->drm_card);
> >  			_print_key_value("render device", dev->drm_render);
> >  			_print_key_value("codename", dev->codename);
> 
> Could this be merged with patch 7? Most of this will be removed in the next patch anyway.

If there are no cons from other reviewers for whom that split into two 
patches, intended to improve their readability, should be better preserved, 
then yes, I can merge them.

Thanks,
Janusz

> 
> 

[PATCH i-g-t 7/7] lib/igt_device_scan: Print GPU upstream port parent/child relations

[Janusz Krzysztofik]

In a short listing, information about PCI parents of DRM devices, as well
as about DRM children of PCI GPU devices is now printed.  In a long
listing in turn, the latter is also printed.  Apply a similar approach to
PCIe bridge upstream ports: print information about their PCI GPU children
and also their codenames in both formats, and inform about upstream ports
of PCIe bridges found on PCI discrete GPU cards in the short format.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 lib/igt_device_scan.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index e86da001a9..69ea8d2eaf 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -250,6 +250,8 @@ struct igt_device {
 	char *codename; /* For grouping by codename */
 	enum dev_type dev_type; /* For grouping by integrated/discrete */
 
+	char *pci_gpu; /* Filled for upstream bridge ports */
+
 	struct igt_list_head link;
 };
 
@@ -1058,6 +1060,9 @@ static void update_or_add_parent(struct udev *udev,
 	igt_assert(bridge_idev);
 
 	bridge_idev->dev_type = DEVTYPE_BRIDGE;
+	bridge_idev->pci_gpu = parent_idev->pci_slot_name;
+	bridge_idev->codename = parent_idev->codename;
+	parent_idev->parent = bridge_idev;
 }
 
 static struct igt_device *duplicate_device(struct igt_device *dev) {
@@ -1316,8 +1321,11 @@ igt_devs_print_simple(struct igt_list_head *view,
 			if (is_pci_subsystem(dev)) {
 				_pr_simple("vendor", dev->vendor);
 				_pr_simple("device", dev->device);
-				if (dev->dev_type != DEVTYPE_BRIDGE)
-					_pr_simple("codename", dev->codename);
+				if (dev->pci_gpu)
+					_pr_simple("GPU device", dev->pci_gpu);
+				_pr_simple("codename", dev->codename);
+				if (dev->parent && dev->parent->pci_slot_name)
+					_pr_simple("upstream port", dev->parent->pci_slot_name);
 			}
 		}
 		printf("\n");
@@ -1469,9 +1477,13 @@ igt_devs_print_detail(struct igt_list_head *view,
 	igt_list_for_each_entry(dev, view, link) {
 		printf("========== %s:%s ==========\n",
 		       dev->subsystem, dev->syspath);
-		if (!is_drm_subsystem(dev) && dev->dev_type != DEVTYPE_BRIDGE) {
-			_print_key_value("card device", dev->drm_card);
-			_print_key_value("render device", dev->drm_render);
+		if (!is_drm_subsystem(dev)) {
+			if (dev->dev_type != DEVTYPE_BRIDGE) {
+				_print_key_value("card device", dev->drm_card);
+				_print_key_value("render device", dev->drm_render);
+			} else {
+				_print_key_value("GPU device", dev->pci_gpu);
+			}
 			_print_key_value("codename", dev->codename);
 		}
 
-- 
2.52.0

Re: [PATCH i-g-t 7/7] lib/igt_device_scan: Print GPU upstream port parent/child relations

[Sebastian Brzezinka]

Hi Janusz,

On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> In a short listing, information about PCI parents of DRM devices, as well
> as about DRM children of PCI GPU devices is now printed.  In a long
> listing in turn, the latter is also printed.  Apply a similar approach to
> PCIe bridge upstream ports: print information about their PCI GPU children
> and also their codenames in both formats, and inform about upstream ports
> of PCIe bridges found on PCI discrete GPU cards in the short format.
>
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---
>  lib/igt_device_scan.c | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> index e86da001a9..69ea8d2eaf 100644
> --- a/lib/igt_device_scan.c
> +++ b/lib/igt_device_scan.c
> @@ -250,6 +250,8 @@ struct igt_device {
>  	char *codename; /* For grouping by codename */
>  	enum dev_type dev_type; /* For grouping by integrated/discrete */
>  
> +	char *pci_gpu; /* Filled for upstream bridge ports */
> +
>  	struct igt_list_head link;
>  };
>  
> @@ -1058,6 +1060,9 @@ static void update_or_add_parent(struct udev *udev,
>  	igt_assert(bridge_idev);
>  
>  	bridge_idev->dev_type = DEVTYPE_BRIDGE;
> +	bridge_idev->pci_gpu = parent_idev->pci_slot_name;
> +	bridge_idev->codename = parent_idev->codename;
> +	parent_idev->parent = bridge_idev;
I haven’t checked the release process myself. Have you verified that freeing this
memory won’t lead to any problems?
 (Maybe use strdup??)

-- 
Best regards,
Sebastian

Re: [PATCH i-g-t 7/7] lib/igt_device_scan: Print GPU upstream port parent/child relations

[Janusz Krzysztofik]

Hi Sebastian,

On Friday, 23 January 2026 12:03:45 CET Sebastian Brzezinka wrote:
> Hi Janusz,
> 
> On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> > In a short listing, information about PCI parents of DRM devices, as well
> > as about DRM children of PCI GPU devices is now printed.  In a long
> > listing in turn, the latter is also printed.  Apply a similar approach to
> > PCIe bridge upstream ports: print information about their PCI GPU children
> > and also their codenames in both formats, and inform about upstream ports
> > of PCIe bridges found on PCI discrete GPU cards in the short format.
> >
> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > ---
> >  lib/igt_device_scan.c | 22 +++++++++++++++++-----
> >  1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> > index e86da001a9..69ea8d2eaf 100644
> > --- a/lib/igt_device_scan.c
> > +++ b/lib/igt_device_scan.c
> > @@ -250,6 +250,8 @@ struct igt_device {
> >  	char *codename; /* For grouping by codename */
> >  	enum dev_type dev_type; /* For grouping by integrated/discrete */
> >  
> > +	char *pci_gpu; /* Filled for upstream bridge ports */
> > +
> >  	struct igt_list_head link;
> >  };
> >  
> > @@ -1058,6 +1060,9 @@ static void update_or_add_parent(struct udev *udev,
> >  	igt_assert(bridge_idev);
> >  
> >  	bridge_idev->dev_type = DEVTYPE_BRIDGE;
> > +	bridge_idev->pci_gpu = parent_idev->pci_slot_name;
> > +	bridge_idev->codename = parent_idev->codename;
> > +	parent_idev->parent = bridge_idev;
> I haven’t checked the release process myself. Have you verified that freeing this
> memory won’t lead to any problems?
>  (Maybe use strdup??)

Indeed, I might have missed something here.  While pci_gpu and parent seem 
safe for me at a first glance, I'm not sure about codename.  Let me have 
another, closer look at all of them.

Thanks,
Janusz

Re: [PATCH i-g-t 7/7] lib/igt_device_scan: Print GPU upstream port parent/child relations

[Janusz Krzysztofik]

Hi,

Here are my conclusion from a closer look.

On Friday, 23 January 2026 15:34:23 CET Janusz Krzysztofik wrote:
> Hi Sebastian,
> 
> On Friday, 23 January 2026 12:03:45 CET Sebastian Brzezinka wrote:
> > Hi Janusz,
> > 
> > On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> > > In a short listing, information about PCI parents of DRM devices, as well
> > > as about DRM children of PCI GPU devices is now printed.  In a long
> > > listing in turn, the latter is also printed.  Apply a similar approach to
> > > PCIe bridge upstream ports: print information about their PCI GPU children
> > > and also their codenames in both formats, and inform about upstream ports
> > > of PCIe bridges found on PCI discrete GPU cards in the short format.
> > >
> > > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > > ---
> > >  lib/igt_device_scan.c | 22 +++++++++++++++++-----
> > >  1 file changed, 17 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> > > index e86da001a9..69ea8d2eaf 100644
> > > --- a/lib/igt_device_scan.c
> > > +++ b/lib/igt_device_scan.c
> > > @@ -250,6 +250,8 @@ struct igt_device {
> > >  	char *codename; /* For grouping by codename */
> > >  	enum dev_type dev_type; /* For grouping by integrated/discrete */
> > >  
> > > +	char *pci_gpu; /* Filled for upstream bridge ports */
> > > +
> > >  	struct igt_list_head link;
> > >  };
> > >  
> > > @@ -1058,6 +1060,9 @@ static void update_or_add_parent(struct udev *udev,
> > >  	igt_assert(bridge_idev);
> > >  
> > >  	bridge_idev->dev_type = DEVTYPE_BRIDGE;
> > > +	bridge_idev->pci_gpu = parent_idev->pci_slot_name;
> > > +	bridge_idev->codename = parent_idev->codename;
> > > +	parent_idev->parent = bridge_idev;
> > I haven’t checked the release process myself. Have you verified that freeing this
> > memory won’t lead to any problems?
> >  (Maybe use strdup??)
> 
> Indeed, I might have missed something here.  While pci_gpu and parent seem 
> safe for me at a first glance, I'm not sure about codename.  Let me have 
> another, closer look at all of them.

I think parent_idev->parent is safe, it follows the pattern used before:
	idev->parent = parent_idev;

However, bridge_idev->codename evidently requires strdup() to avoid double 
free() on destroy.

As long as printing to stdout likely captures content of bridge_idev->pci_gpu 
before parent_idev and its attributes are destroyed, that one seems safe, but 
let's use strdup() as well to be on the safe side.

Thanks for catching this.

Thanks,
Janusz


> 
> Thanks,
> Janusz
>