All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Matt Fleming
	<matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>,
	Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Heyi Guo <heyi.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linux-pci <linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer
Date: Tue, 11 Apr 2017 14:16:39 +0100	[thread overview]
Message-ID: <20170411131639.GA6652@red-moon> (raw)
In-Reply-To: <CAKv+Gu9dS4OhLbBw59yKYQmoJ8SpFexzk9yH=XfXnzn8NJ4mcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:

[...]

> >>> So before starting the next round of hacking to work around this, I
> >>> would like rekindle the discussion regarding the way we blindly
> >>> reassign all resources on ACPI/arm64 systems, and whether there is a
> >>> way imaginable to avoid doing that.
> >>
> >> There is a way if the whole ARM ecosystem work together to sort this
> >> out and we think that's the right way to do; I am personally not
> >> entirely convinced about that.
> >>
> >
> > So what are the pros and cons here? EFI fb is not a hugely important
> > use case, but it is one that relies on BARs staying where they are.
> > Are there others like that?

Not that I am aware of, which means that pros are thin on the ground.

> >>> I suppose the state of the BARs as we inherit it from the firmware
> >>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
> >>> with it). So should there be some side channel (UEFI config table
> >>> perhaps?) to describe this?
> >>
> >> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
> >> Boot Configurations".
> >>
> >> Do we want to enforce it on ARM ? I do not know to be honest (and it
> >> still would not solve the DT firmware case).
> >>
> >
> > No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
> > the pros outweigh the cons.

No one is screaming for that to happen, I can implement resource
claiming but at the moment I do not see the benefit.

[...]

> > The reason is to eliminate another unknown from the discussion whether
> > UEFI can be expected to leave the entire PCI hierarchy in a sane
> > state.
> >
> >> If we want to try to claim the whole resource tree on boot (in ACPI)
> >> I can send a patch for that but there will be regressions.
> >>
> >
> > I would like to see it, yes.
> 
> FWIW, the following minimal [naive] patch
> 
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 4f0e3ebfea4b..37c4d2f116a4 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -27,7 +27,7 @@
>   */
>  void pcibios_fixup_bus(struct pci_bus *bus)
>  {
> -       /* nothing to do, expected to be removed in the future */
> +       pci_read_bridge_bases(bus);
>  }
> 
>  /*
> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
> acpi_pci_root *root)
>         if (!bus)
>                 return NULL;
> 
> -       pci_bus_size_bridges(bus);
> -       pci_bus_assign_resources(bus);
> +       pci_assign_unassigned_root_bus_resources(bus);
> +       pci_bus_claim_resources(bus);

I do not understand this code. If you reassign the whole thing
before claiming it I am not sure what's the point of claiming
the resources later, that's basically a nop. pci_bus_claim_resources()
should suffice (if FW set-up is sane - which also reads bridge bases,
BTW).

Lorenzo

>         list_for_each_entry(child, &bus->children, node)
>                 pcie_bus_configure_settings(child);
> 
> running under QEMU+UEFI with the following PCI topology
> 
> -[0000:00]-+-00.0  Red Hat, Inc. Device 0008
>            +-01.0-[01]----01.0  Device 1234:1111
>            +-02.0-[02]--+-02.0  Red Hat, Inc Virtio RNG
>            |            \-03.0  Red Hat, Inc Virtio block device
>            \-03.0-[03]----04.0  Red Hat, Inc Virtio network device
> 
> results in the log below, preserving the configuration created by UEFI
> 
> pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
> pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:00: root bus resource [bus 00-0f]
> pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> pci 0000:00:01.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:01.0: reg 0x10: [mem 0x8000202000-0x80002020ff 64bit]
> pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:02.0: reg 0x10: [mem 0x8000201000-0x80002010ff 64bit]
> pci 0000:00:03.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:03.0: reg 0x10: [mem 0x8000200000-0x80002000ff 64bit]
> pci 0000:01:01.0: [1234:1111] type 00 class 0x030000
> pci 0000:01:01.0: reg 0x10: [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: reg 0x18: [mem 0x11200000-0x11200fff]
> pci 0000:01:01.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
> no compatible bridge window
> pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x11200000-0x112fffff]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x10ffffff 64bit pref]
> pci 0000:02:02.0: [1af4:1005] type 00 class 0x00ff00
> pci 0000:02:02.0: reg 0x10: [io  0x1040-0x105f]
> pci 0000:02:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> pci 0000:02:03.0: [1af4:1001] type 00 class 0x010000
> pci 0000:02:03.0: reg 0x10: [io  0x1000-0x103f]
> pci 0000:02:03.0: reg 0x14: [mem 0x11100000-0x11100fff]
> pci 0000:02:03.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11100000-0x111fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8000000000-0x80000fffff 64bit pref]
> pci 0000:03:04.0: [1af4:1000] type 00 class 0x020000
> pci 0000:03:04.0: reg 0x10: [io  0x0000-0x001f]
> pci 0000:03:04.0: reg 0x14: [mem 0x11000000-0x11000fff]
> pci 0000:03:04.0: reg 0x20: [mem 0x8000100000-0x8000103fff 64bit pref]
> pci 0000:03:04.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:03.0:   bridge window [mem 0x11000000-0x110fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8000100000-0x80001fffff 64bit pref]
> pci 0000:00:01.0: BAR 14: assigned [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0: BAR 15: assigned [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: BAR 14: assigned [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0: BAR 15: assigned [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: BAR 14: assigned [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0: BAR 15: assigned [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:02.0: BAR 13: assigned [io  0x1000-0x1fff]
> pci 0000:00:03.0: BAR 13: assigned [io  0x2000-0x2fff]
> pci 0000:00:01.0: BAR 0: assigned [mem 0x8001200000-0x80012000ff 64bit]
> pci 0000:00:02.0: BAR 0: assigned [mem 0x8001200100-0x80012001ff 64bit]
> pci 0000:00:03.0: BAR 0: assigned [mem 0x8001200200-0x80012002ff 64bit]
> pci 0000:01:01.0: BAR 0: assigned [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: BAR 6: assigned [mem 0x11000000-0x1100ffff pref]
> pci 0000:01:01.0: BAR 2: assigned [mem 0x11010000-0x11010fff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:02:02.0: BAR 4: assigned [mem 0x8001000000-0x8001003fff 64bit pref]
> pci 0000:02:03.0: BAR 4: assigned [mem 0x8001004000-0x8001007fff 64bit pref]
> pci 0000:02:03.0: BAR 1: assigned [mem 0x11800000-0x11800fff]
> pci 0000:02:03.0: BAR 0: assigned [io  0x1000-0x103f]
> pci 0000:02:02.0: BAR 0: assigned [io  0x1040-0x105f]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:03:04.0: BAR 6: assigned [mem 0x11900000-0x1193ffff pref]
> pci 0000:03:04.0: BAR 4: assigned [mem 0x8001100000-0x8001103fff 64bit pref]
> pci 0000:03:04.0: BAR 1: assigned [mem 0x11940000-0x11940fff]
> pci 0000:03:04.0: BAR 0: assigned [io  0x2000-0x201f]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]
> pci_bus 0000:00: resource 4 [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: resource 5 [io  0x0000-0xffff window]
> pci_bus 0000:00: resource 6 [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:01: resource 1 [mem 0x10000000-0x117fffff]
> pci_bus 0000:01: resource 2 [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
> pci_bus 0000:02: resource 1 [mem 0x11800000-0x118fffff]
> pci_bus 0000:02: resource 2 [mem 0x8001000000-0x80010fffff 64bit pref]
> pci_bus 0000:03: resource 0 [io  0x2000-0x2fff]
> pci_bus 0000:03: resource 1 [mem 0x11900000-0x119fffff]
> pci_bus 0000:03: resource 2 [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]

WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	linux-pci <linux-pci@vger.kernel.org>,
	Peter Jones <pjones@redhat.com>,
	Sinan Kaya <okaya@codeaurora.org>, Heyi Guo <heyi.guo@linaro.org>,
	Lukas Wunner <lukas@wunner.de>,
	Hanjun Guo <hanjun.guo@linaro.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Yinghai Lu <yinghai@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer
Date: Tue, 11 Apr 2017 14:16:39 +0100	[thread overview]
Message-ID: <20170411131639.GA6652@red-moon> (raw)
In-Reply-To: <CAKv+Gu9dS4OhLbBw59yKYQmoJ8SpFexzk9yH=XfXnzn8NJ4mcg@mail.gmail.com>

On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:

[...]

> >>> So before starting the next round of hacking to work around this, I
> >>> would like rekindle the discussion regarding the way we blindly
> >>> reassign all resources on ACPI/arm64 systems, and whether there is a
> >>> way imaginable to avoid doing that.
> >>
> >> There is a way if the whole ARM ecosystem work together to sort this
> >> out and we think that's the right way to do; I am personally not
> >> entirely convinced about that.
> >>
> >
> > So what are the pros and cons here? EFI fb is not a hugely important
> > use case, but it is one that relies on BARs staying where they are.
> > Are there others like that?

Not that I am aware of, which means that pros are thin on the ground.

> >>> I suppose the state of the BARs as we inherit it from the firmware
> >>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
> >>> with it). So should there be some side channel (UEFI config table
> >>> perhaps?) to describe this?
> >>
> >> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
> >> Boot Configurations".
> >>
> >> Do we want to enforce it on ARM ? I do not know to be honest (and it
> >> still would not solve the DT firmware case).
> >>
> >
> > No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
> > the pros outweigh the cons.

No one is screaming for that to happen, I can implement resource
claiming but at the moment I do not see the benefit.

[...]

> > The reason is to eliminate another unknown from the discussion whether
> > UEFI can be expected to leave the entire PCI hierarchy in a sane
> > state.
> >
> >> If we want to try to claim the whole resource tree on boot (in ACPI)
> >> I can send a patch for that but there will be regressions.
> >>
> >
> > I would like to see it, yes.
> 
> FWIW, the following minimal [naive] patch
> 
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 4f0e3ebfea4b..37c4d2f116a4 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -27,7 +27,7 @@
>   */
>  void pcibios_fixup_bus(struct pci_bus *bus)
>  {
> -       /* nothing to do, expected to be removed in the future */
> +       pci_read_bridge_bases(bus);
>  }
> 
>  /*
> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
> acpi_pci_root *root)
>         if (!bus)
>                 return NULL;
> 
> -       pci_bus_size_bridges(bus);
> -       pci_bus_assign_resources(bus);
> +       pci_assign_unassigned_root_bus_resources(bus);
> +       pci_bus_claim_resources(bus);

I do not understand this code. If you reassign the whole thing
before claiming it I am not sure what's the point of claiming
the resources later, that's basically a nop. pci_bus_claim_resources()
should suffice (if FW set-up is sane - which also reads bridge bases,
BTW).

Lorenzo

>         list_for_each_entry(child, &bus->children, node)
>                 pcie_bus_configure_settings(child);
> 
> running under QEMU+UEFI with the following PCI topology
> 
> -[0000:00]-+-00.0  Red Hat, Inc. Device 0008
>            +-01.0-[01]----01.0  Device 1234:1111
>            +-02.0-[02]--+-02.0  Red Hat, Inc Virtio RNG
>            |            \-03.0  Red Hat, Inc Virtio block device
>            \-03.0-[03]----04.0  Red Hat, Inc Virtio network device
> 
> results in the log below, preserving the configuration created by UEFI
> 
> pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
> pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:00: root bus resource [bus 00-0f]
> pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> pci 0000:00:01.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:01.0: reg 0x10: [mem 0x8000202000-0x80002020ff 64bit]
> pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:02.0: reg 0x10: [mem 0x8000201000-0x80002010ff 64bit]
> pci 0000:00:03.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:03.0: reg 0x10: [mem 0x8000200000-0x80002000ff 64bit]
> pci 0000:01:01.0: [1234:1111] type 00 class 0x030000
> pci 0000:01:01.0: reg 0x10: [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: reg 0x18: [mem 0x11200000-0x11200fff]
> pci 0000:01:01.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
> no compatible bridge window
> pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x11200000-0x112fffff]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x10ffffff 64bit pref]
> pci 0000:02:02.0: [1af4:1005] type 00 class 0x00ff00
> pci 0000:02:02.0: reg 0x10: [io  0x1040-0x105f]
> pci 0000:02:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> pci 0000:02:03.0: [1af4:1001] type 00 class 0x010000
> pci 0000:02:03.0: reg 0x10: [io  0x1000-0x103f]
> pci 0000:02:03.0: reg 0x14: [mem 0x11100000-0x11100fff]
> pci 0000:02:03.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11100000-0x111fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8000000000-0x80000fffff 64bit pref]
> pci 0000:03:04.0: [1af4:1000] type 00 class 0x020000
> pci 0000:03:04.0: reg 0x10: [io  0x0000-0x001f]
> pci 0000:03:04.0: reg 0x14: [mem 0x11000000-0x11000fff]
> pci 0000:03:04.0: reg 0x20: [mem 0x8000100000-0x8000103fff 64bit pref]
> pci 0000:03:04.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:03.0:   bridge window [mem 0x11000000-0x110fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8000100000-0x80001fffff 64bit pref]
> pci 0000:00:01.0: BAR 14: assigned [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0: BAR 15: assigned [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: BAR 14: assigned [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0: BAR 15: assigned [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: BAR 14: assigned [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0: BAR 15: assigned [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:02.0: BAR 13: assigned [io  0x1000-0x1fff]
> pci 0000:00:03.0: BAR 13: assigned [io  0x2000-0x2fff]
> pci 0000:00:01.0: BAR 0: assigned [mem 0x8001200000-0x80012000ff 64bit]
> pci 0000:00:02.0: BAR 0: assigned [mem 0x8001200100-0x80012001ff 64bit]
> pci 0000:00:03.0: BAR 0: assigned [mem 0x8001200200-0x80012002ff 64bit]
> pci 0000:01:01.0: BAR 0: assigned [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: BAR 6: assigned [mem 0x11000000-0x1100ffff pref]
> pci 0000:01:01.0: BAR 2: assigned [mem 0x11010000-0x11010fff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:02:02.0: BAR 4: assigned [mem 0x8001000000-0x8001003fff 64bit pref]
> pci 0000:02:03.0: BAR 4: assigned [mem 0x8001004000-0x8001007fff 64bit pref]
> pci 0000:02:03.0: BAR 1: assigned [mem 0x11800000-0x11800fff]
> pci 0000:02:03.0: BAR 0: assigned [io  0x1000-0x103f]
> pci 0000:02:02.0: BAR 0: assigned [io  0x1040-0x105f]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:03:04.0: BAR 6: assigned [mem 0x11900000-0x1193ffff pref]
> pci 0000:03:04.0: BAR 4: assigned [mem 0x8001100000-0x8001103fff 64bit pref]
> pci 0000:03:04.0: BAR 1: assigned [mem 0x11940000-0x11940fff]
> pci 0000:03:04.0: BAR 0: assigned [io  0x2000-0x201f]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]
> pci_bus 0000:00: resource 4 [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: resource 5 [io  0x0000-0xffff window]
> pci_bus 0000:00: resource 6 [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:01: resource 1 [mem 0x10000000-0x117fffff]
> pci_bus 0000:01: resource 2 [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
> pci_bus 0000:02: resource 1 [mem 0x11800000-0x118fffff]
> pci_bus 0000:02: resource 2 [mem 0x8001000000-0x80010fffff 64bit pref]
> pci_bus 0000:03: resource 0 [io  0x2000-0x2fff]
> pci_bus 0000:03: resource 1 [mem 0x11900000-0x119fffff]
> pci_bus 0000:03: resource 2 [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer
Date: Tue, 11 Apr 2017 14:16:39 +0100	[thread overview]
Message-ID: <20170411131639.GA6652@red-moon> (raw)
In-Reply-To: <CAKv+Gu9dS4OhLbBw59yKYQmoJ8SpFexzk9yH=XfXnzn8NJ4mcg@mail.gmail.com>

On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:

[...]

> >>> So before starting the next round of hacking to work around this, I
> >>> would like rekindle the discussion regarding the way we blindly
> >>> reassign all resources on ACPI/arm64 systems, and whether there is a
> >>> way imaginable to avoid doing that.
> >>
> >> There is a way if the whole ARM ecosystem work together to sort this
> >> out and we think that's the right way to do; I am personally not
> >> entirely convinced about that.
> >>
> >
> > So what are the pros and cons here? EFI fb is not a hugely important
> > use case, but it is one that relies on BARs staying where they are.
> > Are there others like that?

Not that I am aware of, which means that pros are thin on the ground.

> >>> I suppose the state of the BARs as we inherit it from the firmware
> >>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
> >>> with it). So should there be some side channel (UEFI config table
> >>> perhaps?) to describe this?
> >>
> >> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
> >> Boot Configurations".
> >>
> >> Do we want to enforce it on ARM ? I do not know to be honest (and it
> >> still would not solve the DT firmware case).
> >>
> >
> > No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
> > the pros outweigh the cons.

No one is screaming for that to happen, I can implement resource
claiming but at the moment I do not see the benefit.

[...]

> > The reason is to eliminate another unknown from the discussion whether
> > UEFI can be expected to leave the entire PCI hierarchy in a sane
> > state.
> >
> >> If we want to try to claim the whole resource tree on boot (in ACPI)
> >> I can send a patch for that but there will be regressions.
> >>
> >
> > I would like to see it, yes.
> 
> FWIW, the following minimal [naive] patch
> 
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 4f0e3ebfea4b..37c4d2f116a4 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -27,7 +27,7 @@
>   */
>  void pcibios_fixup_bus(struct pci_bus *bus)
>  {
> -       /* nothing to do, expected to be removed in the future */
> +       pci_read_bridge_bases(bus);
>  }
> 
>  /*
> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
> acpi_pci_root *root)
>         if (!bus)
>                 return NULL;
> 
> -       pci_bus_size_bridges(bus);
> -       pci_bus_assign_resources(bus);
> +       pci_assign_unassigned_root_bus_resources(bus);
> +       pci_bus_claim_resources(bus);

I do not understand this code. If you reassign the whole thing
before claiming it I am not sure what's the point of claiming
the resources later, that's basically a nop. pci_bus_claim_resources()
should suffice (if FW set-up is sane - which also reads bridge bases,
BTW).

Lorenzo

>         list_for_each_entry(child, &bus->children, node)
>                 pcie_bus_configure_settings(child);
> 
> running under QEMU+UEFI with the following PCI topology
> 
> -[0000:00]-+-00.0  Red Hat, Inc. Device 0008
>            +-01.0-[01]----01.0  Device 1234:1111
>            +-02.0-[02]--+-02.0  Red Hat, Inc Virtio RNG
>            |            \-03.0  Red Hat, Inc Virtio block device
>            \-03.0-[03]----04.0  Red Hat, Inc Virtio network device
> 
> results in the log below, preserving the configuration created by UEFI
> 
> pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
> pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:00: root bus resource [bus 00-0f]
> pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> pci 0000:00:01.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:01.0: reg 0x10: [mem 0x8000202000-0x80002020ff 64bit]
> pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:02.0: reg 0x10: [mem 0x8000201000-0x80002010ff 64bit]
> pci 0000:00:03.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:03.0: reg 0x10: [mem 0x8000200000-0x80002000ff 64bit]
> pci 0000:01:01.0: [1234:1111] type 00 class 0x030000
> pci 0000:01:01.0: reg 0x10: [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: reg 0x18: [mem 0x11200000-0x11200fff]
> pci 0000:01:01.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
> no compatible bridge window
> pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x11200000-0x112fffff]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x10ffffff 64bit pref]
> pci 0000:02:02.0: [1af4:1005] type 00 class 0x00ff00
> pci 0000:02:02.0: reg 0x10: [io  0x1040-0x105f]
> pci 0000:02:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> pci 0000:02:03.0: [1af4:1001] type 00 class 0x010000
> pci 0000:02:03.0: reg 0x10: [io  0x1000-0x103f]
> pci 0000:02:03.0: reg 0x14: [mem 0x11100000-0x11100fff]
> pci 0000:02:03.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11100000-0x111fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8000000000-0x80000fffff 64bit pref]
> pci 0000:03:04.0: [1af4:1000] type 00 class 0x020000
> pci 0000:03:04.0: reg 0x10: [io  0x0000-0x001f]
> pci 0000:03:04.0: reg 0x14: [mem 0x11000000-0x11000fff]
> pci 0000:03:04.0: reg 0x20: [mem 0x8000100000-0x8000103fff 64bit pref]
> pci 0000:03:04.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:03.0:   bridge window [mem 0x11000000-0x110fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8000100000-0x80001fffff 64bit pref]
> pci 0000:00:01.0: BAR 14: assigned [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0: BAR 15: assigned [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: BAR 14: assigned [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0: BAR 15: assigned [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: BAR 14: assigned [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0: BAR 15: assigned [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:02.0: BAR 13: assigned [io  0x1000-0x1fff]
> pci 0000:00:03.0: BAR 13: assigned [io  0x2000-0x2fff]
> pci 0000:00:01.0: BAR 0: assigned [mem 0x8001200000-0x80012000ff 64bit]
> pci 0000:00:02.0: BAR 0: assigned [mem 0x8001200100-0x80012001ff 64bit]
> pci 0000:00:03.0: BAR 0: assigned [mem 0x8001200200-0x80012002ff 64bit]
> pci 0000:01:01.0: BAR 0: assigned [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: BAR 6: assigned [mem 0x11000000-0x1100ffff pref]
> pci 0000:01:01.0: BAR 2: assigned [mem 0x11010000-0x11010fff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:02:02.0: BAR 4: assigned [mem 0x8001000000-0x8001003fff 64bit pref]
> pci 0000:02:03.0: BAR 4: assigned [mem 0x8001004000-0x8001007fff 64bit pref]
> pci 0000:02:03.0: BAR 1: assigned [mem 0x11800000-0x11800fff]
> pci 0000:02:03.0: BAR 0: assigned [io  0x1000-0x103f]
> pci 0000:02:02.0: BAR 0: assigned [io  0x1040-0x105f]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:03:04.0: BAR 6: assigned [mem 0x11900000-0x1193ffff pref]
> pci 0000:03:04.0: BAR 4: assigned [mem 0x8001100000-0x8001103fff 64bit pref]
> pci 0000:03:04.0: BAR 1: assigned [mem 0x11940000-0x11940fff]
> pci 0000:03:04.0: BAR 0: assigned [io  0x2000-0x201f]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]
> pci_bus 0000:00: resource 4 [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: resource 5 [io  0x0000-0xffff window]
> pci_bus 0000:00: resource 6 [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:01: resource 1 [mem 0x10000000-0x117fffff]
> pci_bus 0000:01: resource 2 [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
> pci_bus 0000:02: resource 1 [mem 0x11800000-0x118fffff]
> pci_bus 0000:02: resource 2 [mem 0x8001000000-0x80010fffff 64bit pref]
> pci_bus 0000:03: resource 0 [io  0x2000-0x2fff]
> pci_bus 0000:03: resource 1 [mem 0x11900000-0x119fffff]
> pci_bus 0000:03: resource 2 [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]

  parent reply	other threads:[~2017-04-11 13:16 UTC|newest]

Thread overview: 117+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-22 15:30 [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer Ard Biesheuvel
2017-03-22 15:30 ` Ard Biesheuvel
2017-03-22 15:30 ` Ard Biesheuvel
     [not found] ` <1490196629-28088-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-03-22 19:31   ` Lukas Wunner
2017-03-22 19:31     ` Lukas Wunner
2017-03-22 19:31     ` Lukas Wunner
2017-03-22 19:32     ` Ard Biesheuvel
2017-03-22 19:32       ` Ard Biesheuvel
2017-03-22 19:32       ` Ard Biesheuvel
     [not found]       ` <CAKv+Gu_X-SEnz7h9J8boqqjOQGHQawwdSAq4haH-OGu8zdfNfA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-03-23  8:48         ` Lukas Wunner
2017-03-23  8:48           ` Lukas Wunner
2017-03-23  8:48           ` Lukas Wunner
2017-03-23  9:04           ` Ard Biesheuvel
2017-03-23  9:04             ` Ard Biesheuvel
2017-03-23  9:04             ` Ard Biesheuvel
     [not found]             ` <CAKv+Gu93eJ-js3g7M6Jdm6XGMaWMswFmzBG2qNT4rn+3=1+EyA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-03-23 10:57               ` Lorenzo Pieralisi
2017-03-23 10:57                 ` Lorenzo Pieralisi
2017-03-23 10:57                 ` Lorenzo Pieralisi
2017-03-23 12:25                 ` Ard Biesheuvel
2017-03-23 12:25                   ` Ard Biesheuvel
2017-03-23 12:25                   ` Ard Biesheuvel
2017-03-23 14:31                   ` Lorenzo Pieralisi
2017-03-23 14:31                     ` Lorenzo Pieralisi
2017-03-23 14:31                     ` Lorenzo Pieralisi
2017-03-23 15:15                     ` Ard Biesheuvel
2017-03-23 15:15                       ` Ard Biesheuvel
2017-03-23 15:15                       ` Ard Biesheuvel
2017-03-27 15:37                       ` Ard Biesheuvel
2017-03-27 15:37                         ` Ard Biesheuvel
2017-03-27 15:37                         ` Ard Biesheuvel
2017-03-28 21:27                 ` Sinan Kaya
2017-03-28 21:27                   ` Sinan Kaya
2017-03-28 21:27                   ` Sinan Kaya
2017-03-28 21:39                   ` Ard Biesheuvel
2017-03-28 21:39                     ` Ard Biesheuvel
2017-03-28 21:39                     ` Ard Biesheuvel
     [not found]                     ` <CAKv+Gu9LbwpnJNi1OL25MWvYPxEOfKRHcs2jA2121BPaQWPzow-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-03-28 21:49                       ` Sinan Kaya
2017-03-28 21:49                         ` Sinan Kaya
2017-03-28 21:49                         ` Sinan Kaya
     [not found]                         ` <27f50de3-721e-e8ec-00c8-b7a9d3cff0d6-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-03-30  8:46                           ` Ard Biesheuvel
2017-03-30  8:46                             ` Ard Biesheuvel
2017-03-30  8:46                             ` Ard Biesheuvel
     [not found]                             ` <CAKv+Gu-qRg8-YRCairppKrEfeLcW+OwVF8qZHp7vxXJA_AwPOw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-03-30 10:05                               ` Lorenzo Pieralisi
2017-03-30 10:05                                 ` Lorenzo Pieralisi
2017-03-30 10:05                                 ` Lorenzo Pieralisi
2017-03-30 10:09                                 ` Ard Biesheuvel
2017-03-30 10:09                                   ` Ard Biesheuvel
2017-03-30 10:09                                   ` Ard Biesheuvel
2017-03-30 11:42                                   ` okaya
2017-03-30 11:42                                     ` okaya at codeaurora.org
2017-03-30 11:42                                     ` okaya
2017-03-30 13:38                                   ` Ard Biesheuvel
2017-03-30 13:38                                     ` Ard Biesheuvel
2017-03-30 13:38                                     ` Ard Biesheuvel
2017-03-30 13:50                                     ` Sinan Kaya
2017-03-30 13:50                                       ` Sinan Kaya
2017-03-30 13:50                                       ` Sinan Kaya
     [not found]                                       ` <ae87ae28-f50d-095f-576e-f3fd7f96dea2-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-04-02 15:16                                         ` Ard Biesheuvel
2017-04-02 15:16                                           ` Ard Biesheuvel
2017-04-02 15:16                                           ` Ard Biesheuvel
     [not found]                                           ` <CAKv+Gu8x0rQUnTUorknW-mW9LFgrxFYsXyy4LU_w9JbA-m_sjA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-10 15:28                                             ` Ard Biesheuvel
2017-04-10 15:28                                               ` Ard Biesheuvel
2017-04-10 15:28                                               ` Ard Biesheuvel
2017-04-10 16:53                                               ` Lorenzo Pieralisi
2017-04-10 16:53                                                 ` Lorenzo Pieralisi
2017-04-10 16:53                                                 ` Lorenzo Pieralisi
2017-04-10 17:06                                                 ` Sinan Kaya
2017-04-10 17:06                                                   ` Sinan Kaya
2017-04-10 17:06                                                   ` Sinan Kaya
2017-04-10 17:13                                                 ` Ard Biesheuvel
2017-04-10 17:13                                                   ` Ard Biesheuvel
2017-04-10 17:13                                                   ` Ard Biesheuvel
     [not found]                                                   ` <CAKv+Gu-AN-OwnAJG5dt0Qg4GU8HxZBowTSA0H3LhNA3nHfrsQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-10 17:29                                                     ` Ard Biesheuvel
2017-04-10 17:29                                                       ` Ard Biesheuvel
2017-04-10 17:29                                                       ` Ard Biesheuvel
     [not found]                                                       ` <CAKv+Gu9dS4OhLbBw59yKYQmoJ8SpFexzk9yH=XfXnzn8NJ4mcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-11 13:16                                                         ` Lorenzo Pieralisi [this message]
2017-04-11 13:16                                                           ` Lorenzo Pieralisi
2017-04-11 13:16                                                           ` Lorenzo Pieralisi
2017-04-11 16:06                                                           ` Ard Biesheuvel
2017-04-11 16:06                                                             ` Ard Biesheuvel
2017-04-11 16:06                                                             ` Ard Biesheuvel
2017-04-23  1:45                                                       ` Yinghai Lu
2017-04-23  1:45                                                         ` Yinghai Lu
2017-04-23  1:45                                                         ` Yinghai Lu
     [not found]                                                         ` <20170423014546.GA2704-HmG2f/OLMhfd32I7TRUmRQWg3BAJk+jzdezBB/11ZoCIZ3GwZIjcak9v6f1uFnsJ2SarAXORi/o@public.gmane.org>
2017-04-27 13:55                                                           ` Ard Biesheuvel
2017-04-27 13:55                                                             ` Ard Biesheuvel
2017-04-27 13:55                                                             ` Ard Biesheuvel
     [not found]                                                             ` <CAKv+Gu_n7xP-2RtF44GVzwyoMXDOeF-bR43yStwp2y+oBNs4jg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-28 20:51                                                               ` Yinghai Lu
2017-04-28 20:51                                                                 ` Yinghai Lu
2017-04-28 20:51                                                                 ` Yinghai Lu
2017-03-22 19:36     ` Sinan Kaya
2017-03-22 19:36       ` Sinan Kaya
2017-03-22 19:36       ` Sinan Kaya
2017-03-22 19:41       ` Ard Biesheuvel
2017-03-22 19:41         ` Ard Biesheuvel
2017-03-22 19:41         ` Ard Biesheuvel
2017-03-22 19:49         ` Sinan Kaya
2017-03-22 19:49           ` Sinan Kaya
2017-03-22 19:49           ` Sinan Kaya
2017-03-22 19:52           ` Ard Biesheuvel
2017-03-22 19:52             ` Ard Biesheuvel
2017-03-22 19:52             ` Ard Biesheuvel
2017-03-22 19:57             ` Sinan Kaya
2017-03-22 19:57               ` Sinan Kaya
2017-03-22 19:57               ` Sinan Kaya
     [not found]               ` <4ccb4d92-3830-3980-38c3-7085a3d97734-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-03-22 20:00                 ` Ard Biesheuvel
2017-03-22 20:00                   ` Ard Biesheuvel
2017-03-22 20:00                   ` Ard Biesheuvel
2017-05-03  3:09   ` Heyi Guo
2017-05-03  3:09     ` Heyi Guo
2017-05-03  3:09     ` Heyi Guo
2017-05-18 14:01     ` Bjorn Helgaas
2017-05-18 14:01       ` Bjorn Helgaas
2017-05-18 14:01       ` Bjorn Helgaas
     [not found]       ` <20170518140154.GA24324-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2017-05-20  8:19         ` Heyi Guo
2017-05-20  8:19           ` Heyi Guo
2017-05-20  8:19           ` Heyi Guo

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=20170411131639.GA6652@red-moon \
    --to=lorenzo.pieralisi-5wv7dgnigg8@public.gmane.org \
    --cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=heyi.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org \
    --cc=matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org \
    --cc=okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.