All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh+dt@kernel.org>
To: Leonardo Bras <leobras.c@gmail.com>
Cc: Frank Rowand <frowand.list@gmail.com>,
	Alexey Kardashevskiy <aik@ozlabs.ru>,
	devicetree@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	PCI <linux-pci@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 1/1] of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses
Date: Mon, 19 Apr 2021 10:44:31 -0500	[thread overview]
Message-ID: <CAL_Jsq+m6CkGj_NYGvwxoKwoQ4PkEu6hfGdMTT3i4APoHSkNeg@mail.gmail.com> (raw)
In-Reply-To: <7b089cd48b90f2445c7cb80da1ce8638607c46fc.camel@gmail.com>

On Fri, Apr 16, 2021 at 3:58 PM Leonardo Bras <leobras.c@gmail.com> wrote:
>
> Hello Rob, thanks for this feedback!
>
> On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote:
> > +PPC and PCI lists
> >
> > On Thu, Apr 15, 2021 at 1:01 PM Leonardo Bras <leobras.c@gmail.com> wrote:
> > >
> > > Many other resource flag parsers already add this flag when the input
> > > has bits 24 & 25 set, so update this one to do the same.
> >
> > Many others? Looks like sparc and powerpc to me.
> >
>
> s390 also does that, but it look like it comes from a device-tree.

I'm only looking at DT based platforms, and s390 doesn't use DT.

> > Those would be the
> > ones I worry about breaking. Sparc doesn't use of/address.c so it's
> > fine. Powerpc version of the flags code was only fixed in 2019, so I
> > don't think powerpc will care either.
>
> In powerpc I reach this function with this stack, while configuring a
> virtio-net device for a qemu/KVM pseries guest:
>
> pci_process_bridge_OF_ranges+0xac/0x2d4
> pSeries_discover_phbs+0xc4/0x158
> discover_phbs+0x40/0x60
> do_one_initcall+0x60/0x2d0
> kernel_init_freeable+0x308/0x3a8
> kernel_init+0x2c/0x168
> ret_from_kernel_thread+0x5c/0x70
>
> For this, both MMIO32 and MMIO64 resources will have flags 0x200.

Oh good, powerpc has 2 possible flags parsing functions. So in the
above path, do we need to set PCI_BASE_ADDRESS_MEM_TYPE_64?

Does pci_parse_of_flags() get called in your case?

> > I noticed both sparc and powerpc set PCI_BASE_ADDRESS_MEM_TYPE_64 in
> > the flags. AFAICT, that's not set anywhere outside of arch code. So
> > never for riscv, arm and arm64 at least. That leads me to
> > pci_std_update_resource() which is where the PCI code sets BARs and
> > just copies the flags in PCI_BASE_ADDRESS_MEM_MASK ignoring
> > IORESOURCE_* flags. So it seems like 64-bit is still not handled and
> > neither is prefetch.
> >
>
> I am not sure if you mean here:
> a) it's ok to add IORESOURCE_MEM_64 here, because it does not affect
> anything else, or
> b) it should be using PCI_BASE_ADDRESS_MEM_TYPE_64
> (or IORESOURCE_MEM_64 | PCI_BASE_ADDRESS_MEM_TYPE_64) instead, since
> it's how it's added in powerpc/sparc, and else there is no point.

I'm wondering if a) is incomplete and PCI_BASE_ADDRESS_MEM_TYPE_64
also needs to be set. The question is ultimately are BARs getting set
correctly for 64-bit? It looks to me like they aren't.

Rob

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt@kernel.org>
To: Leonardo Bras <leobras.c@gmail.com>
Cc: devicetree@vger.kernel.org, Alexey Kardashevskiy <aik@ozlabs.ru>,
	Frank Rowand <frowand.list@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	PCI <linux-pci@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 1/1] of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses
Date: Mon, 19 Apr 2021 10:44:31 -0500	[thread overview]
Message-ID: <CAL_Jsq+m6CkGj_NYGvwxoKwoQ4PkEu6hfGdMTT3i4APoHSkNeg@mail.gmail.com> (raw)
In-Reply-To: <7b089cd48b90f2445c7cb80da1ce8638607c46fc.camel@gmail.com>

On Fri, Apr 16, 2021 at 3:58 PM Leonardo Bras <leobras.c@gmail.com> wrote:
>
> Hello Rob, thanks for this feedback!
>
> On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote:
> > +PPC and PCI lists
> >
> > On Thu, Apr 15, 2021 at 1:01 PM Leonardo Bras <leobras.c@gmail.com> wrote:
> > >
> > > Many other resource flag parsers already add this flag when the input
> > > has bits 24 & 25 set, so update this one to do the same.
> >
> > Many others? Looks like sparc and powerpc to me.
> >
>
> s390 also does that, but it look like it comes from a device-tree.

I'm only looking at DT based platforms, and s390 doesn't use DT.

> > Those would be the
> > ones I worry about breaking. Sparc doesn't use of/address.c so it's
> > fine. Powerpc version of the flags code was only fixed in 2019, so I
> > don't think powerpc will care either.
>
> In powerpc I reach this function with this stack, while configuring a
> virtio-net device for a qemu/KVM pseries guest:
>
> pci_process_bridge_OF_ranges+0xac/0x2d4
> pSeries_discover_phbs+0xc4/0x158
> discover_phbs+0x40/0x60
> do_one_initcall+0x60/0x2d0
> kernel_init_freeable+0x308/0x3a8
> kernel_init+0x2c/0x168
> ret_from_kernel_thread+0x5c/0x70
>
> For this, both MMIO32 and MMIO64 resources will have flags 0x200.

Oh good, powerpc has 2 possible flags parsing functions. So in the
above path, do we need to set PCI_BASE_ADDRESS_MEM_TYPE_64?

Does pci_parse_of_flags() get called in your case?

> > I noticed both sparc and powerpc set PCI_BASE_ADDRESS_MEM_TYPE_64 in
> > the flags. AFAICT, that's not set anywhere outside of arch code. So
> > never for riscv, arm and arm64 at least. That leads me to
> > pci_std_update_resource() which is where the PCI code sets BARs and
> > just copies the flags in PCI_BASE_ADDRESS_MEM_MASK ignoring
> > IORESOURCE_* flags. So it seems like 64-bit is still not handled and
> > neither is prefetch.
> >
>
> I am not sure if you mean here:
> a) it's ok to add IORESOURCE_MEM_64 here, because it does not affect
> anything else, or
> b) it should be using PCI_BASE_ADDRESS_MEM_TYPE_64
> (or IORESOURCE_MEM_64 | PCI_BASE_ADDRESS_MEM_TYPE_64) instead, since
> it's how it's added in powerpc/sparc, and else there is no point.

I'm wondering if a) is incomplete and PCI_BASE_ADDRESS_MEM_TYPE_64
also needs to be set. The question is ultimately are BARs getting set
correctly for 64-bit? It looks to me like they aren't.

Rob

  reply	other threads:[~2021-04-19 15:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15 18:00 [PATCH 1/1] of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses Leonardo Bras
2021-04-15 18:59 ` Rob Herring
2021-04-15 18:59   ` Rob Herring
2021-04-16 20:57   ` Leonardo Bras
2021-04-16 20:57     ` Leonardo Bras
2021-04-19 15:44     ` Rob Herring [this message]
2021-04-19 15:44       ` Rob Herring
2021-04-20  0:35       ` Leonardo Bras
2021-04-20  0:35         ` Leonardo Bras
2021-04-20  1:39         ` Rob Herring
2021-04-20  1:39           ` Rob Herring
2021-04-20  2:02           ` Leonardo Bras
2021-04-20  2:02             ` Leonardo Bras
2021-04-20 22:34             ` Rob Herring
2021-04-20 22:34               ` Rob Herring
2021-04-21 14:14               ` Leonardo Bras
2021-04-21 14:14                 ` Leonardo Bras
2021-04-16 21:27   ` Leonardo Bras
2021-04-16 21:27     ` Leonardo Bras
2021-06-09 18:50   ` Bjorn Helgaas
2021-06-09 18:50     ` Bjorn Helgaas
2021-04-21 12:51 ` Rob Herring

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=CAL_Jsq+m6CkGj_NYGvwxoKwoQ4PkEu6hfGdMTT3i4APoHSkNeg@mail.gmail.com \
    --to=robh+dt@kernel.org \
    --cc=aik@ozlabs.ru \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=leobras.c@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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.