From: Bjorn Helgaas <helgaas@kernel.org>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Martin Mareš" <mj@ucw.cz>, "Krzysztof Wilczyński" <kw@linux.com>,
"Matthew Wilcox" <willy@infradead.org>,
linux-pci@vger.kernel.org
Subject: Re: IORESOURCE_WINDOW for PCI-to-PCI bridges
Date: Tue, 15 Nov 2022 16:15:02 -0600 [thread overview]
Message-ID: <20221115221502.GA755872@bhelgaas> (raw)
In-Reply-To: <20221111214816.65fi63ffgvr6nbj2@pali>
On Fri, Nov 11, 2022 at 10:48:16PM +0100, Pali Rohár wrote:
> On Friday 11 November 2022 15:05:55 Bjorn Helgaas wrote:
> > On Fri, Nov 11, 2022 at 09:09:45PM +0100, Pali Rohár wrote:
> > > On Thursday 20 January 2022 15:02:12 Bjorn Helgaas wrote:
> > > > On Thu, Jan 20, 2022 at 09:45:05PM +0100, Pali Rohár wrote:
> >
> > [trimmed material; beginning of thread is at
> > https://lore.kernel.org/r/20211220155448.1233-3-pali@kernel.org]
> >
> > > > > Meanwhile I found out that in linux/ioport.h file is IORESOURCE_WINDOW
> > > > > constant with comment /* forwarded by bridge */
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/ioport.h?h=v5.15#n56
> > > > >
> > > > > But apparently it is not set for resources behind PCI bridges and
> > > > > therefore it is not available in column of "resources" sysfs file.
> > > > >
> > > > > So maybe instead of adding new sysfs files, it would be better way to
> > > > > implement this flag and export it in flags column of "resources" file
> > > > > for every row which belongs to resources behind bridges?
> > > >
> > > > I looked at that, too. Today we only set IORESOURCE_WINDOW for host
> > > > bridge windows. Maybe it could be set for PCI-to-PCI bridge windows,
> > > > too. Would have to audit users to make sure it wouldn't break
> > > > anything.
> > >
> > > Hello Bjorn, I would like to remind this older issue. Did you have a time
> > > to audit usage of IORESOURCE_WINDOW? Some flag for resource forwarding
> > > windows in PCI-to-PCI bridges would really help userspace application to
> > > distinguish between IO/MEM BARs an IO/MEM forwarding windows.
> >
> > I had forgotten all about this issue. IIUC, the ultimate goal here
> > is to help lspci distinguish between an I/O window that's disabled and
> > one that's enabled at [io 0x0000-0x0fff].
> >
> > I have not done the research to see whether it would be safe to set
> > IORESOURCE_WINDOW for PCI-to-PCI bridge windows. I'm sorry if I left
> > the impression that I intended to do that. I would welcome your help
> > to do that.
>
> Ok, do you have some resources or other information at which I should
> look? I just do not know where to start or what to check for that
> research.
>
> I looked into kernel sources and the only places where is code checking
> for IORESOURCE_WINDOW is ACPI related: arch/arm64/kernel/pci.c and
> drivers/pnp/resource.c. And I do not fully understand how is ACPI
> connected with PCI resources at this level. Other places which check
> (lib/vsprintf.c and drivers/pnp/interface.c) just use it for
> printf-formats.
Yeah, that's the kind of thing I have in mind. I can't remember if I
had any specific concern.
Bjorn
next prev parent reply other threads:[~2022-11-15 22:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-20 15:54 [PATCH pciutils 1/4] lspci: Show 16/32/64 bit width for address ranges behind bridge Pali Rohár
2021-12-20 15:54 ` [PATCH pciutils 2/4] lspci: Simplify printing range in show_range() Pali Rohár
2021-12-20 15:54 ` [PATCH pciutils 3/4] libpci: Add support for filling bridge resources Pali Rohár
2021-12-26 22:13 ` Martin Mareš
2021-12-26 22:20 ` Pali Rohár
2021-12-31 22:27 ` Pali Rohár
2022-01-20 20:33 ` Bjorn Helgaas
2022-01-20 20:45 ` Pali Rohár
2022-01-20 21:02 ` Bjorn Helgaas
2022-01-20 21:19 ` Pali Rohár
2022-11-11 20:09 ` IORESOURCE_WINDOW for PCI-to-PCI bridges Pali Rohár
2022-11-11 21:05 ` Bjorn Helgaas
2022-11-11 21:48 ` Pali Rohár
2022-11-15 22:15 ` Bjorn Helgaas [this message]
2021-12-20 15:54 ` [PATCH pciutils 4/4] lspci: Use PCI_FILL_BRIDGE_BASES to detect if range behind bridge is disabled or unsupported Pali Rohár
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=20221115221502.GA755872@bhelgaas \
--to=helgaas@kernel.org \
--cc=kw@linux.com \
--cc=linux-pci@vger.kernel.org \
--cc=mj@ucw.cz \
--cc=pali@kernel.org \
--cc=willy@infradead.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.