- Nov 16, 2016
-
-
Andy Yan authored
RK1108 EVB is designed by Rockchip for CVR field. This patch add basic support for it, which can boot with initramfs into shell. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Andy Yan authored
RK1108 is embedded with an ARM Cortex-A7 single core and a DSP core. It is designed for varies application scenario such as car DVR, sports DV, secure camera and UAV camera. This patch add basic support for it with DMAC / UART / CRU / pinctrl / MMC enabled. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Jacob Chen <jacob2.chen@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
- Nov 14, 2016
-
-
Paweł Jarosz authored
DMA controller driver is in good shape these days on rockchip platforms. So lets enable DMA for uart and mmc. Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Paweł Jarosz authored
This patch fixes incorectly assigned rk3066a TSADC node Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
- Nov 09, 2016
-
-
Jaehoon Chung authored
In drivers/mmc/core/host.c, there is "max-frequency" property. It should be same behavior. So use the "max-frequency" instead of "clock-freq-min-max". Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
- Nov 06, 2016
-
-
Paweł Jarosz authored
Currently driver leaves sdmmc frequency at its default. So lets set this to 50MHz. This gives us performance boost in mmc transfers. Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
- Oct 22, 2016
-
-
Andy Yan authored
Use definition in rockchip pinctrl header to describe gpios, this will make it more clear. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Paweł Jarosz authored
MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports - host and otg, micro sd card slot and onboard wifi RK901. Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chip.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
- Oct 21, 2016
-
-
Paweł Jarosz authored
Initialize PLL, cpu bus and peripherial bus rate while kernel init. No other module does than. This gives us performance boost observable for example in mmc transfers. Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
- Oct 16, 2016
-
-
Shawn Lin authored
Enable these two modes to speed up the booting and improve the performance. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Shawn Lin authored
PopMetal-RK3288 board could enable SD3.0 card but need vccio_sd to support the voltage range from 1V8 to 3V3 and we also need to add more UHS mode here. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Shawn Lin authored
Please don't add these for vcc_sd, and mmc-core/driver will control it. Otherwise, it will waste energy even without sdmmc in slot. Moreover, it will causes a bug: If we insert/remove sd card, we could see [9.337271] mmc0: new ultra high speed SDR25 SDHC card at address 0007 [9.345144] mmcblk0: mmc0:0007 SD32G 29.3 GiB This is okay for normal sd insert/remove test, but when I debug some issues for sdmmc, I did unbind/bind test. And there is a interesting phenomenon when we bind the driver again: [58.314069] mmc0: new high speed SDHC card at address 0007 [58.320282] mmcblk0: mmc0:0007 SD32G 29.3 GiB So the sd card could just support high speed without power cycle since the vcc_sd is always on, which makes the sd card fail to reinit its internal ocr mask. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Finley Xiao authored
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Andy Yan authored
PX3 EVB is designed by Rockchip for automotive field, with integrated CVBS (TP2825) / MIPI DSI / LVDS / HDMI video input/output interface, WIFI/BT/GPS (on a module named S500 which based on MT6620), Gsensor BMA250E and light&proximity sensor STK3410. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Javier Martinez Canillas authored
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same, besides empty chosen nodes being removed. So the change should not have a functional impact. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same, besides empty chosen nodes being removed. So the change should not have a functional impact. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same, besides empty chosen nodes being removed. So the change should not have a functional impact. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Javier Martinez Canillas authored
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" The disassembled DTB are almost the same, besides empty chosen nodes being removed. So the change should not have a functional impact. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
- Oct 12, 2016
-
-
Masahiro Yamada authored
Kernel source files need not include <linux/kconfig.h> explicitly because the top Makefile forces to include it with: -include $(srctree)/include/linux/kconfig.h This commit removes explicit includes except the following: * arch/s390/include/asm/facilities_src.h * tools/testing/radix-tree/linux/kernel.h These two are used for host programs. Link: http://lkml.kernel.org/r/1473656164-11929-1-git-send-email-yamada.masahiro@socionext.com Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Jason Cooper authored
Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Link: http://lkml.kernel.org/r/20160803233913.32511-4-jason@lakedaemon.net Signed-off-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Kees Cook <keescook@chromium.org> Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- Oct 08, 2016
-
-
Chris Metcalf authored
When doing an nmi backtrace of many cores, most of which are idle, the output is a little overwhelming and very uninformative. Suppress messages for cpus that are idling when they are interrupted and just emit one line, "NMI backtrace for N skipped: idling at pc 0xNNN". We do this by grouping all the cpuidle code together into a new .cpuidle.text section, and then checking the address of the interrupted PC to see if it lies within that section. This commit suitably tags x86 and tile idle routines, and only adds in the minimal framework for other architectures. Link: http://lkml.kernel.org/r/1472487169-14923-5-git-send-email-cmetcalf@mellanox.com Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm] Tested-by: Petr Mladek <pmladek@suse.com> Cc: Aaron Tomlin <atomlin@redhat.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Russell King <linux@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Chris Metcalf authored
Currently on arm there is code that checks whether it should call dump_stack() explicitly, to avoid trying to raise an NMI when the current context is not preemptible by the backtrace IPI. Similarly, the forthcoming arch/tile support uses an IPI mechanism that does not support generating an NMI to self. Accordingly, move the code that guards this case into the generic mechanism, and invoke it unconditionally whenever we want a backtrace of the current cpu. It seems plausible that in all cases, dump_stack() will generate better information than generating a stack from the NMI handler. The register state will be missing, but that state is likely not particularly helpful in any case. Or, if we think it is helpful, we should be capturing and emitting the current register state in all cases when regs == NULL is passed to nmi_cpu_backtrace(). Link: http://lkml.kernel.org/r/1472487169-14923-3-git-send-email-cmetcalf@mellanox.com Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com> Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm] Reviewed-by: Petr Mladek <pmladek@suse.com> Acked-by: Aaron Tomlin <atomlin@redhat.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Russell King <linux@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Chris Metcalf authored
Patch series "improvements to the nmi_backtrace code" v9. This patch series modifies the trigger_xxx_backtrace() NMI-based remote backtracing code to make it more flexible, and makes a few small improvements along the way. The motivation comes from the task isolation code, where there are scenarios where we want to be able to diagnose a case where some cpu is about to interrupt a task-isolated cpu. It can be helpful to see both where the interrupting cpu is, and also an approximation of where the cpu that is being interrupted is. The nmi_backtrace framework allows us to discover the stack of the interrupted cpu. I've tested that the change works as desired on tile, and build-tested x86, arm, mips, and sparc64. For x86 I confirmed that the generic cpuidle stuff as well as the architecture-specific routines are in the new cpuidle section. For arm, mips, and sparc I just build-tested it and made sure the generic cpuidle routines were in the new cpuidle section, but I didn't attempt to figure out which the platform-specific idle routines might be. That might be more usefully done by someone with platform experience in follow-up patches. This patch (of 4): Currently you can only request a backtrace of either all cpus, or all cpus but yourself. It can also be helpful to request a remote backtrace of a single cpu, and since we want that, the logical extension is to support a cpumask as the underlying primitive. This change modifies the existing lib/nmi_backtrace.c code to take a cpumask as its basic primitive, and modifies the linux/nmi.h code to use the new "cpumask" method instead. The existing clients of nmi_backtrace (arm and x86) are converted to using the new cpumask approach in this change. The other users of the backtracing API (sparc64 and mips) are converted to use the cpumask approach rather than the all/allbutself approach. The mips code ignored the "include_self" boolean but with this change it will now also dump a local backtrace if requested. Link: http://lkml.kernel.org/r/1472487169-14923-2-git-send-email-cmetcalf@mellanox.com Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com> Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm] Reviewed-by: Aaron Tomlin <atomlin@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Russell King <linux@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: David Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Vineet Gupta authored
This came to light when implementing native 64-bit atomics for ARCv2. The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE to check whether atomic64_dec_if_positive() is available. It seems it was needed when not every arch defined it. However as of current code the Kconfig option seems needless - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a generic definition of API is present lib/atomic64.c - arches with native 64-bit atomics select it in arch/*/Kconfig and define the API in their headers So I see no point in keeping the Kconfig option Compile tested for: - blackfin (CONFIG_GENERIC_ATOMIC64) - x86 (!CONFIG_GENERIC_ATOMIC64) - ia64 Link: http://lkml.kernel.org/r/1473703083-8625-3-git-send-email-vgupta@synopsys.com Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Ralf Baechle <ralf@linux-mips.org> 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: "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: Vineet Gupta <vgupta@synopsys.com> Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Ming Lin <ming.l@ssi.samsung.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Borislav Petkov <bp@suse.de> Cc: Andi Kleen <ak@linux.intel.com> Cc: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- Oct 06, 2016
-
-
Russell King authored
Commit 215e362d ("ARM: 8306/1: loop_udelay: remove bogomips value limitation") tried to increase the bogomips limitation, but in doing so messed up udelay such that it always gives about a 5% error in the delay, even if we use a timer. The calculation is: loops = UDELAY_MULT * us_delay * ticks_per_jiffy >> UDELAY_SHIFT Originally, UDELAY_MULT was ((UL(2199023) * HZ) >> 11) and UDELAY_SHIFT 30. Assuming HZ=100, us_delay of 1000 and ticks_per_jiffy of 1660000 (eg, 166MHz timer, 1ms delay) this would calculate: ((UL(2199023) * HZ) >> 11) * 1000 * 1660000 >> 30 => 165999 With the new values of 2047 * HZ + 483648 * HZ / 1000000 and 31, we get: (2047 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31 => 158269 which is incorrect. This is due to a typo - correcting it gives: (2147 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31 => 165999 i.o.w, the original value. Fixes: 215e362d ("ARM: 8306/1: loop_udelay: remove bogomips value limitation") Cc: <stable@vger.kernel.org> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-
- Oct 03, 2016
-
-
Vladimir Zapolskiy authored
The change adds a new device node with description of generic SRAM on-chip memory found on NXP LPC32xx SoC series and connected to AHB matrix slave port 3. Note that NXP LPC3220 SoC has 128KiB of SRAM memory, the other LPC3230, LPC3240 and LPC3250 SoCs all have 256KiB SRAM space, in the shared DTSI file this change specifies 128KiB SRAM size. Also it's worth to mention that the SRAM area contains of 64KiB banks, 2 banks on LPC3220 and 4 banks on the other SoCs from the series, and all SRAM banks but the first one have independent power controls, the description of this feature will be added with the introduction of power domains for the SoC series. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Cc: Sylvain Lemieux <slemieux.tyco@gmail.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
Srinivas Ramana authored
If the bootloader uses the long descriptor format and jumps to kernel decompressor code, TTBCR may not be in a right state. Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use TTBR0 for translation table walks. The commit dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N. Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to indicate the use of TTBR0 and the correct base address width. Fixes: dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Srinivas Ramana <sramana@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- Sep 29, 2016
-
-
Roger Quadros authored
Since commit 6ce0d200 ("ARM: dma: Use dma_pfn_offset for dma address translation"), dma_to_pfn() already returns the PFN with the physical memory start offset so we don't need to add it again. This fixes USB mass storage lock-up problem on systems that can't do DMA over the entire physical memory range (e.g.) Keystone 2 systems with 4GB RAM can only do DMA over the first 2GB. [K2E-EVM]. What happens there is that without this patch SCSI layer sets a wrong bounce buffer limit in scsi_calculate_bounce_limit() for the USB mass storage device. dma_max_pfn() evaluates to 0x8fffff and bounce_limit is set to 0x8fffff000 whereas maximum DMA'ble physical memory on Keystone 2 is 0x87fffffff. This results in non DMA'ble pages being given to the USB controller and hence the lock-up. NOTE: in the above case, USB-SCSI-device's dma_pfn_offset was showing as 0. This should have really been 0x780000 as on K2e, LOWMEM_START is 0x80000000 and HIGHMEM_START is 0x800000000. DMA zone is 2GB so dma_max_pfn should be 0x87ffff. The incorrect dma_pfn_offset for the USB storage device is because USB devices are not correctly inheriting the dma_pfn_offset from the USB host controller. This will be fixed by a separate patch. Fixes: 6ce0d200 ("ARM: dma: Use dma_pfn_offset for dma address translation") Cc: stable@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Olof Johansson <olof@lixom.net> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Reported-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Robin Murphy authored
Whilst MPIDR values themselves are less than 32 bits, it is still perfectly valid for a DT to have #address-cells > 1 in the CPUs node, resulting in the "reg" property having leading zero cell(s). In that situation, the big-endian nature of the data conspires with the current behaviour of only reading the first cell to cause the kernel to think all CPUs have ID 0, and become resoundingly unhappy as a consequence. Take the full property length into account when parsing CPUs so as to be correct under any circumstances. Cc: Russell King <linux@armlinux.org.uk> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /soc has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /soc has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /soc has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
As noted in [1], "there are a number of problems with skeleton.dtsi, and it would be prefereable to remove it entirely." This patch is to remove skeleton.dtsi inclusion from berlin2. [1] http://www.spinics.net/lists/arm-kernel/msg528080.html Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-