- Aug 06, 2017
-
-
Jacob Chen authored
Add an mipi node, and also add mipi endpoints to vopb and vopl output port nodes. Signed-off-by:
Jacob Chen <jacob-chen@iotwrt.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Yakir Yang authored
Add an edp node, and also add edp endpoints to vopb and vopl output port nodes. Signed-off-by:
Yakir Yang <ykk@rock-chips.com> Signed-off-by:
Caesar Wang <wxt@rock-chips.com> Signed-off-by:
Jacob Chen <jacob-chen@iotwrt.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Elaine Zhang authored
1. add pd node for RK3399 Soc 2. create power domain tree 3. add qos node for domain Signed-off-by:
Elaine Zhang <zhangqing@rock-chips.com> Signed-off-by:
Caesar Wang <wxt@rock-chips.com> Signed-off-by:
Jacob Chen <jacob-chen@iotwrt.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Mark Yao authored
Add devicetree nodes for rk3399 VOP (Video Output Processors), and the top level display-subsystem root node. Later patches add endpoints (eDP, HDMI, MIPI, etc) that attach to the VOPs' output ports. Signed-off-by:
Mark Yao <mark.yao@rock-chips.com> Signed-off-by:
Yakir Yang <ykk@rock-chips.com> Signed-off-by:
Caesar Wang <wxt@rock-chips.com> Signed-off-by:
Jacob Chen <jacob-chen@iotwrt.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Jianqun Xu authored
Add opp tables for cpu cluster0 and cluster1 by including rk3399-opp.dtsi. Signed-off-by:
Jianqun Xu <jay.xu@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Finley Xiao authored
This patch adds basic OPP entries for RK3328 SoC. Signed-off-by:
Finley Xiao <finley.xiao@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Aug 01, 2017
-
-
Caesar Wang authored
This patch updates the dynamic-power-coefficient for big cluster on rk3399 SoCs. The dynamic power consumption of the CPU is proportional to the square of the Voltage (V) and the clock frequency (f). The coefficient is used to calculate the dynamic power as below - Pdyn = dynamic-power-coefficient * V^2 * f Where Voltage is in uV, frequency is in MHz. As the following is the tested data on rk3399's big cluster. frequency(MHz) Voltage(V) Current(mA) Dynamic-power-coefficient 24 0.8 15 48 0.8 23 ~417 96 0.8 40 ~443 216 0.8 82 ~438 312 0.8 115 ~430 408 0.8 150 ~455 So the dynamic-power-coefficient average value is about 436. Signed-off-by:
Caesar Wang <wxt@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Jul 30, 2017
-
-
Sugar Zhang authored
This patch add the spdif dt node for rk3328. Signed-off-by:
Sugar Zhang <sugar.zhang@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Sugar Zhang authored
This patch add the spdif dt node for rk3368 soc. Signed-off-by:
Sugar Zhang <sugar.zhang@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Jul 26, 2017
-
-
Shawn Lin authored
This allows basic support for SD highspeed cards but no UHS-I mode got ready due to the propagated defer-probe error from RK805. Cc: Kever Yang <kever.yang@rock-chips.com> Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
David Wu authored
Add the core grf subnode for the io-domain controller. Signed-off-by:
David Wu <david.wu@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Jul 23, 2017
-
-
Shawn Lin authored
Kill these two pinctrl reference totally from rk3399 as it never work indeed. Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Shawn Lin authored
pcie_clkreqn actually doesn't work at all, so replace it with pcie_clkreqn_cpm. Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Caesar Wang authored
This patch enables the gpu and adds the mali-supply power for RK3399-GRU devices. Signed-off-by:
Caesar Wang <wxt@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Caesar Wang authored
Add Mali GPU device tree node for the RK3399 SoCs, with devfreq opp table. RK3399 and RK3399-OP1 SoCs have a different recommendation table with gpu opp. Also, the ARM's mali driver found on https://developer.arm.com/products/software/mali-drivers/midgard-kernel . Signed-off-by:
Caesar Wang <wxt@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Shawn Lin authored
keep-power-in-suspend was invented for SDIO only, so it should not be used for eMMC node. Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Jul 16, 2017
-
-
Shawn Lin authored
We deprecated the "num-slots" property now and plan to get rid of it finally. Just move a step to cleanup it from DT. Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Shawn Lin authored
pcie_clkreqn actually doesn't work at all, so replace it with pcie_clkreqn_cpm. Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Caesar Wang authored
The SdioAudio power domain includes the i2s/spdif/spi5/sdio. So this patch adds the pd control for rk3399 i2s/spdif/spi5/sdio, in order to save more power consumption. Signed-off-by:
Caesar Wang <wxt@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
William Wu authored
Rockchip's RK3328 evaluation board has one usb2 otg controller and one usb2 host controller which consist of EHCI and OHCI. Each usb controller connects with one usb2 phy port through UTMI+ interface. Let's enable them to support usb2 on RK3328 evaluation board. Signed-off-by:
William Wu <william.wu@rock-chips.com> [restructured enablement of u2phy subnodes] Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
William Wu authored
This patch adds usb2 otg/host controllers and phys nodes for Rockchip RK3328 SoCs. Signed-off-by:
William Wu <william.wu@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Brian Norris authored
Provide the dynamic power coefficient of the big and little CPU clusters. These numbers are currently in use on the Samsung Chromebook Plus ("Kevin"). The power allocator thermal governor doesn't know how to do anything if it doesn't get power parameters from its cooling devices (in this case, CPUfreq). So this effectively enables the power-allocator governor. Signed-off-by:
Brian Norris <briannorris@chromium.org> [set the property in each core node] Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Matthias Kaehlcke authored
The Gru device tree currently contains entries for the regulators ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however, the regulators have not been enabled, due to the lack of binding and driver support for keeping the over-voltage protection (OVP) at bay and preventing unintended regulator shutdowns on voltage downshifts. Now, the vctrl regulator driver has been merged, along with new bindings for asymmetric settling time. The driver is OVP aware, it splits larger voltage decreases in multiple steps when necessary and adds required delays. This change renames each of the aforementioned regulators to <orig_name>_pwm and adds a new vctrl regulator named <orig_name>. The vctrl regulators use the voltage of their corresponding PWM regulator as control voltage. The OVP related values are empirical and stem from the Chrome OS kernel tree. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
Brian Norris <briannorris@chromium.org> [fixed node names and parent supplies of gpu and centerlogic] Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Matthias Kaehlcke authored
Gru derivatives besides Kevin have slightly different voltage ranges for their CPU regulators. Let's keep the base Gru file accurate and let Kevin override. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Klaus Goger authored
replace all occurrences of sdmcc with sdmmc in the arm64 rockchip devicetree files. Signed-off-by:
Klaus Goger <klaus.goger@theobroma-systems.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Jul 13, 2017
-
-
Rik van Riel authored
When RLIMIT_STACK is, for example, 256MB, the current code results in a gap between the top of the task and mmap_base of 256MB, failing to take into account the amount by which the stack address was randomized. In other words, the stack gets less than RLIMIT_STACK space. Ensure that the gap between the stack and mmap_base always takes stack randomization and the stack guard gap into account. Obtained from Daniel Micay's linux-hardened tree. Link: http://lkml.kernel.org/r/20170622200033.25714-3-riel@redhat.com Signed-off-by:
Daniel Micay <danielmicay@gmail.com> Signed-off-by:
Rik van Riel <riel@redhat.com> Reported-by:
Florian Weimer <fweimer@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Daniel Micay <danielmicay@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Hugh Dickins <hughd@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Rik van Riel authored
Use the ascii-armor canary to prevent unterminated C string overflows from being able to successfully overwrite the canary, even if they somehow obtain the canary value. Inspired by execshield ascii-armor and Daniel Micay's linux-hardened tree. Link: http://lkml.kernel.org/r/20170524155751.424-5-riel@redhat.com Signed-off-by:
Rik van Riel <riel@redhat.com> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Daniel Micay <danielmicay@gmail.com> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Ingo Molnar <mingo@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Daniel Micay authored
This adds support for compiling with a rough equivalent to the glibc _FORTIFY_SOURCE=1 feature, providing compile-time and runtime buffer overflow checks for string.h functions when the compiler determines the size of the source or destination buffer at compile-time. Unlike glibc, it covers buffer reads in addition to writes. GNU C __builtin_*_chk intrinsics are avoided because they would force a much more complex implementation. They aren't designed to detect read overflows and offer no real benefit when using an implementation based on inline checks. Inline checks don't add up to much code size and allow full use of the regular string intrinsics while avoiding the need for a bunch of _chk functions and per-arch assembly to avoid wrapper overhead. This detects various overflows at compile-time in various drivers and some non-x86 core kernel code. There will likely be issues caught in regular use at runtime too. Future improvements left out of initial implementation for simplicity, as it's all quite optional and can be done incrementally: * Some of the fortified string functions (strncpy, strcat), don't yet place a limit on reads from the source based on __builtin_object_size of the source buffer. * Extending coverage to more string functions like strlcat. * It should be possible to optionally use __builtin_object_size(x, 1) for some functions (C strings) to detect intra-object overflows (like glibc's _FORTIFY_SOURCE=2), but for now this takes the conservative approach to avoid likely compatibility issues. * The compile-time checks should be made available via a separate config option which can be enabled by default (or always enabled) once enough time has passed to get the issues it catches fixed. Kees said: "This is great to have. While it was out-of-tree code, it would have blocked at least CVE-2016-3858 from being exploitable (improper size argument to strlcpy()). I've sent a number of fixes for out-of-bounds-reads that this detected upstream already" [arnd@arndb.de: x86: fix fortified memcpy] Link: http://lkml.kernel.org/r/20170627150047.660360-1-arnd@arndb.de [keescook@chromium.org: avoid panic() in favor of BUG()] Link: http://lkml.kernel.org/r/20170626235122.GA25261@beast [keescook@chromium.org: move from -mm, add ARCH_HAS_FORTIFY_SOURCE, tweak Kconfig help] Link: http://lkml.kernel.org/r/20170526095404.20439-1-danielmicay@gmail.com Link: http://lkml.kernel.org/r/1497903987-21002-8-git-send-email-keescook@chromium.org Signed-off-by:
Daniel Micay <danielmicay@gmail.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Daniel Axtens <dja@axtens.net> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Chris Metcalf <cmetcalf@ezchip.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jul 11, 2017
-
-
Kees Cook authored
Now that explicitly executed loaders are loaded in the mmap region, we have more freedom to decide where we position PIE binaries in the address space to avoid possible collisions with mmap or stack regions. For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit address space for 32-bit pointers. On 32-bit use 4MB, to match ARM. This could be 0x8000, the standard ET_EXEC load address, but that is needlessly close to the NULL address, and anyone running arm compat PIE will have an MMU, so the tight mapping is not needed. Link: http://lkml.kernel.org/r/1498251600-132458-4-git-send-email-keescook@chromium.org Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andrey Ryabinin authored
We used to read several bytes of the shadow memory in advance. Therefore additional shadow memory mapped to prevent crash if speculative load would happen near the end of the mapped shadow memory. Now we don't have such speculative loads, so we no longer need to map additional shadow memory. Link: http://lkml.kernel.org/r/20170601162338.23540-3-aryabinin@virtuozzo.com Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Acked-by:
Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jul 10, 2017
-
-
Masahiro Yamada authored
Since commit fcc8487d ("uapi: export all headers under uapi directories"), all (and only) headers under uapi directories are exported, but asm-generic wrappers are still exceptions. To complete de-coupling the uapi from kernel headers, move generic-y of exported headers to uapi/asm/Kbuild. With this change, "make headers_install" will just need to parse uapi/asm/Kbuild to build up exported headers. For arm64, "generic-y += kvm_para.h" is doubled in asm/Kbuild and uapi/asm/Kbuild. So, the one in the former can be simply removed. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- Jul 07, 2017
-
-
Punit Agrawal authored
A poisoned or migrated hugepage is stored as a swap entry in the page tables. On architectures that support hugepages consisting of contiguous page table entries (such as on arm64) this leads to ambiguity in determining the page table entry to return in huge_pte_offset() when a poisoned entry is encountered. Let's remove the ambiguity by adding a size parameter to convey additional information about the requested address. Also fixup the definition/usage of huge_pte_offset() throughout the tree. Link: http://lkml.kernel.org/r/20170522133604.11392-4-punit.agrawal@arm.com Signed-off-by:
Punit Agrawal <punit.agrawal@arm.com> Acked-by:
Steve Capper <steve.capper@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: James Hogan <james.hogan@imgtec.com> (odd fixer:METAG ARCHITECTURE) Cc: Ralf Baechle <ralf@linux-mips.org> (supporter:MIPS) Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Helge Deller <deller@gmx.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Chris Metcalf <cmetcalf@mellanox.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Steve Capper authored
We don't need to call huge_ptep_offset as our accessors are already supplied with the pte_t *. This patch removes those spurious calls. [punit.agrawal@arm.com: resolve rebase conflicts due to patch re-ordering] Link: http://lkml.kernel.org/r/20170524115409.31309-3-punit.agrawal@arm.com Signed-off-by:
Steve Capper <steve.capper@arm.com> Signed-off-by:
Punit Agrawal <punit.agrawal@arm.com> Cc: David Woods <dwoods@mellanox.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Steve Capper authored
Patch series "Support for contiguous pte hugepages", v4. This patchset updates the hugetlb code to fix issues arising from contiguous pte hugepages (such as on arm64). Compared to v3, This version addresses a build failure on arm64 by including two cleanup patches. Other than the arm64 cleanups, the rest are generic code changes. The remaining arm64 support based on these patches will be posted separately. The patches are based on v4.12-rc2. Previous related postings can be found at [0], [1], [2], and [3]. The patches fall into three categories - * Patch 1-2 - arm64 cleanups required to greatly simplify changing huge_pte_offset() prototype in Patch 5. Catalin, Will - are you happy for these patches to go via mm? * Patches 3-4 address issues with gup * Patches 5-8 relate to passing a size argument to hugepage helpers to disambiguate the size of the referred page. These changes are required to enable arch code to properly handle swap entries for contiguous pte hugepages. The changes to huge_pte_offset() (patch 5) touch multiple architectures but I've managed to minimise these changes for the other affected functions - huge_pte_clear() and set_huge_pte_at(). These patches gate the enabling of contiguous hugepages support on arm64 which has been requested for systems using !4k page granule. The ARM64 architecture supports two flavours of hugepages - * Block mappings at the pud/pmd level These are regular hugepages where a pmd or a pud page table entry points to a block of memory. Depending on the PAGE_SIZE in use the following size of block mappings are supported - PMD PUD --- --- 4K: 2M 1G 16K: 32M 64K: 512M For certain applications/usecases such as HPC and large enterprise workloads, folks are using 64k page size but the minimum hugepage size of 512MB isn't very practical. To overcome this ... * Using the Contiguous bit The architecture provides a contiguous bit in the translation table entry which acts as a hint to the mmu to indicate that it is one of a contiguous set of entries that can be cached in a single TLB entry. We use the contiguous bit in Linux to increase the mapping size at the pmd and pte (last) level. The number of supported contiguous entries varies by page size and level of the page table. Using the contiguous bit allows additional hugepage sizes - CONT PTE PMD CONT PMD PUD -------- --- -------- --- 4K: 64K 2M 32M 1G 16K: 2M 32M 1G 64K: 2M 512M 16G Of these, 64K with 4K and 2M with 64K pages have been explicitly requested by a few different users. Entries with the contiguous bit set are required to be modified all together - which makes things like memory poisoning and migration impossible to do correctly without knowing the size of hugepage being dealt with - the reason for adding size parameter to a few of the hugepage helpers in this series. This patch (of 8): As we regularly check for contiguous pte's in the huge accessors, remove this extra check from find_num_contig. [punit.agrawal@arm.com: resolve rebase conflicts due to patch re-ordering] Link: http://lkml.kernel.org/r/20170524115409.31309-2-punit.agrawal@arm.com Signed-off-by:
Steve Capper <steve.capper@arm.com> Signed-off-by:
Punit Agrawal <punit.agrawal@arm.com> Cc: David Woods <dwoods@mellanox.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Aneesh Kumar K.V authored
This moves the #ifdef in C code to a Kconfig dependency. Also we move the gigantic_page_supported() function to be arch specific. This allows architectures to conditionally enable runtime allocation of gigantic huge page. Architectures like ppc64 supports different gigantic huge page size (16G and 1G) based on the translation mode selected. This provides an opportunity for ppc64 to enable runtime allocation only w.r.t 1G hugepage. No functional change in this patch. Link: http://lkml.kernel.org/r/1494995292-4443-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jul 04, 2017
-
-
Al Viro authored
no users left Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
- Jul 03, 2017
-
-
Marc Zyngier authored
Contrary to popular belief, PPIs connected to a GICv3 to not have an affinity field similar to that of GICv2. That is consistent with the fact that GICv3 is designed to accomodate thousands of CPUs, and fitting them as a bitmap in a byte is... difficult. Fixes: adbc3695 ("arm64: dts: add the Marvell Armada 3700 family and a development board") Cc: <stable@vger.kernel.org> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Lorenzo Pieralisi authored
With the introduction of struct pci_host_bridge.map_irq pointer it is possible to assign IRQs for all devices originating from a PCI host bridge at probe time; this is implemented through pci_assign_irq() that relies on the struct pci_host_bridge.map_irq pointer to map IRQ for a given device. The benefits this brings are twofold: - the IRQ for a device is assigned once at probe time - the IRQ assignment works also for hotplugged devices With all DT based PCI host bridges converted to the struct pci_host_bridge.{map/swizzle}_irq hooks mechanism the DT IRQ allocation in ARM64 pcibios_alloc_irq() is now redundant and can be removed. Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Will Deacon <will.deacon@arm.com>
-
- Jul 02, 2017
-
-
Maxime Ripard authored
This reverts commits 2c0cba48 ("arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module") to 2428fd0f ("arm64: defconfig: Enable dwmac-sun8i driver on defconfig") and 3432a86e ("arm: sun8i: orangepipc: use internal phy-mode") to 5a79b4f2 ("arm: sun8i: orangepi-2: use internal phy-mode") that should be merged through the arm-soc tree, and end up in merge conflicts and build failures. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Jul 01, 2017
-
-
Luc Van Oostenryck authored
struct jit_ctx::image is used the store a pointer to the jitted intructions, which are always little-endian. These instructions are thus correctly converted from native order to little-endian before being stored but the pointer 'image' is declared as for native order values. Fix this by declaring the field as __le32* instead of u32*. Same for the pointer used in jit_fill_hole() to initialize the image. Signed-off-by:
Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-