Linux v4.14-rc5

This commit is contained in:
Justin M. Forbes 2017-10-16 15:31:37 -05:00
parent bd9b022f13
commit bb0af23d9a
4 changed files with 6 additions and 105 deletions

View File

@ -41,56 +41,3 @@ index 373e33f22be4..020e7668dfab 100644
size);
ret = -ENOMEM;
goto error;
From patchwork Wed Oct 4 12:54:47 2017
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: cma: Take __GFP_NOWARN into account in cma_alloc()
From: Boris Brezillon <boris.brezillon@free-electrons.com>
X-Patchwork-Id: 180554
Message-Id: <20171004125447.15195-1-boris.brezillon@free-electrons.com>
To: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Laura Abbott <labbott@redhat.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
Jaewon Kim <jaewon31.kim@samsung.com>, dri-devel@lists.freedesktop.org
Date: Wed, 4 Oct 2017 14:54:47 +0200
cma_alloc() unconditionally prints an INFO message when the CMA
allocation fails. Make this message conditional on the non-presence of
__GFP_NOWARN in gfp_mask.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Laura Abbott <labbott@redhat.com>
---
Hello,
This patch aims at removing INFO messages that are displayed when the
VC4 driver tries to allocate buffer objects. From the driver perspective
an allocation failure is acceptable, and the driver can possibly do
something to make following allocation succeed (like flushing the VC4
internal cache).
Also, I don't understand why this message is only an INFO message, and
not a WARN (pr_warn()). Please let me know if you have good reasons to
keep it as an unconditional pr_info().
Thanks,
Boris
---
mm/cma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/cma.c b/mm/cma.c
index c0da318c020e..022e52bd8370 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -460,7 +460,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
trace_cma_alloc(pfn, page, count, align);
- if (ret) {
+ if (ret && !(gfp_mask & __GFP_NOWARN)) {
pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
__func__, count, ret);
cma_debug_show_areas(cma);

View File

@ -67,9 +67,9 @@ Summary: The Linux kernel
# The next upstream release sublevel (base_sublevel+1)
%define upstream_sublevel %(echo $((%{base_sublevel} + 1)))
# The rc snapshot level
%global rcrev 4
%global rcrev 5
# The git snapshot level
%define gitrev 4
%define gitrev 0
# Set rpm version accordingly
%define rpmversion 4.%{upstream_sublevel}.0
%endif
@ -599,7 +599,6 @@ Patch305: arm-imx6-hummingboard2.patch
Patch306: arm64-Add-option-of-13-for-FORCE_MAX_ZONEORDER.patch
# https://patchwork.kernel.org/patch/9967397/
Patch307: tegra-Use-different-MSI-target-address-for-Tegra20.patch
# https://patchwork.kernel.org/patch/9815555/
# https://patchwork.kernel.org/patch/9815651/
@ -2214,6 +2213,9 @@ fi
#
#
%changelog
* Mon Oct 16 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.14.0-0.rc5.git0.1
- Linux v4.14-rc5
* Mon Oct 16 2017 Justin M. Forbes <jforbes@fedoraproject.org>
- Disable debugging options.

View File

@ -1,4 +1,3 @@
SHA512 (linux-4.13.tar.xz) = a557c2f0303ae618910b7106ff63d9978afddf470f03cb72aa748213e099a0ecd5f3119aea6cbd7b61df30ca6ef3ec57044d524b7babbaabddf8b08b8bafa7d2
SHA512 (perf-man-4.13.tar.gz) = 9bcc2cd8e56ec583ed2d8e0b0c88e7a94035a1915e40b3177bb02d6c0f10ddd4df9b097b1f5af59efc624226b613e240ddba8ddc2156f3682f992d5455fc5c03
SHA512 (patch-4.14-rc4.xz) = 11edc0714c9b7ff34986d1534c490987f5977940afc5b176a424a23e437d572d83f8d689b4505128371bf6d4c5956a2042c9c4d222eb72363b977b69c819b3e3
SHA512 (patch-4.14-rc4-git4.xz) = 2f68128482824575c94e0282be64dd1490fa251b8806758c0d6ac2a7b3da8d9e0f098c0cd4ad07eaac280c4eb8331b898224acef641eea8fb3c2314b42114c0a
SHA512 (patch-4.14-rc5.xz) = 1b09fa9e2fae3b6ac172b2f130a84c9a1ea7c6ea89e0b799013814216dd0c5ba7eeae5b0abcd7dad289fd695abc5663b5fdd92cb7993729c52c08c538b73ace2

View File

@ -1,47 +0,0 @@
From patchwork Sat Sep 23 06:17:40 2017
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: PCI: tegra: Use different MSI target address for Tegra20
From: Thierry Reding <thierry.reding@gmail.com>
X-Patchwork-Id: 9967397
Message-Id: <20170923061740.6012-1-treding@nvidia.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org
Date: Fri, 22 Sep 2017 23:17:40 -0700
The Tegra20 PCIe controller has a different address range for MSI, so
select a different target address.
Fixes: d7bd554f27c9 ("PCI: tegra: Do not allocate MSI target memory")
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/pci/host/pci-tegra.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index e8e1ddbaabc9..5b02ea59524b 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1563,8 +1563,18 @@ static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
* none of the Tegra SoCs that contain this PCI host bridge can
* address more than 16 GiB of system memory, the last 4 KiB of
* these 1012 GiB is a good candidate.
+ *
+ * Unfortunately, Tegra20 is slightly different in that the physical
+ * address for this MSI region is limited to the lower 32 bits of the
+ * address map, so the address that we pick is going to have to be
+ * located somewhere within the region addressable by the CPU and
+ * on-SoC controllers. To be on the safe side, we select an address
+ * from a region that is marked unused (0xf0010000 - 0xfffeffff).
*/
- msi->phys = 0xfcfffff000;
+ if (soc->msi_base_shift > 0)
+ msi->phys = 0xfcfffff000;
+ else
+ msi->phys = 0x00f0010000;
afi_writel(pcie, msi->phys >> soc->msi_base_shift, AFI_MSI_FPCI_BAR_ST);
afi_writel(pcie, msi->phys, AFI_MSI_AXI_BAR_ST);