- Oct 24, 2016
-
-
Marcin Niestroj authored
liteBoard is a development board which uses liteSOM as its base. Hardware specification: * liteSOM (i.MX6UL, DRAM, eMMC) * Ethernet PHY (id 0) * USB host (usb_otg1) * MicroSD slot (uSDHC1) Signed-off-by:
Marcin Niestroj <m.niestroj@grinn-global.com> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Marcin Niestroj authored
This is a SOM (System on Module), so it will be part of another boards. Hence, this is a "dtsi" file that will be included from another device tree files. Hardware specification: * Freescale i.MX6UL SoC * up to 512 MB RAM * eMMC on uSDHC2 Signed-off-by:
Marcin Niestroj <m.niestroj@grinn-global.com> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Marek Vasut authored
Enable PWM1, otherwise the backlight cannot work. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Andreas Färber authored
Add initial device trees for UDOO Neo Basic, Extended and Full boards: * Serial console is enabled, other serial ports are prepared. * I2C based PMIC is enabled. * Ethernet is enabled for Basic and Full. * SDHC is enabled, with the SDIO_PWR GPIO modeled as a regulator. * Both user LEDs are enabled, with the orange one reserved for the M4 and with the SD card as default trigger for the red LED. The decision on a board compatible string is deferred to later. Cc: Ettore Chimenti <ettore.chimenti@udoo.org> Signed-off-by:
Andreas Färber <afaerber@suse.de> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Hongtao Jia authored
Also add nodes and properties for thermal management support. Signed-off-by:
Jia Hongtao <hongtao.jia@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Sanchayan Maity authored
Enable DMA for DSPI on Vybrid. Signed-off-by:
Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Marek Vasut authored
The LCDIF interrupt should be triggered by the rising edge of the IRQ line because we only want the interrupt to trigger once per each frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted by software, so the previous behavior before this patch, where the interrupt was triggered by level-high status of the IRQ line, caused the interrupt to fire again immediatelly after it was handled, which caused the system to lock up due to the high rate of interrupts. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Andrey Smirnov authored
Add node corresponding to OCOTP IP block. Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Andrey Smirnov authored
I2C3 bus was only brought out in revision A1 of the board and revision B1 only brings out 3 I2C busses (I2C0, I2C1 and I2C2). Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Jagan Teki authored
Fixed error in trailing whitespace in wandboard-rev1 dtsi. Signed-off-by:
Jagan Teki <jteki@openedev.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Jagan Teki authored
Fixed code indent tabs in respetcive imx6qdl dtsi files. Signed-off-by:
Jagan Teki <jteki@openedev.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Jagan Teki authored
Fixed no space before tabs warnings in respetcive imx6qdl dtsi files. Signed-off-by:
Jagan Teki <jteki@openedev.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
- Oct 23, 2016
-
-
Jaret Cantu authored
Calibrate the USB PHY TX settings to pass the eye diagram signal integrity test. The settings are taken from the i.MX6 reference manual's recommended configuration for USB certification (66.2.6). Signed-off-by:
Jaret Cantu <jaret.cantu@timesys.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
- Oct 22, 2016
-
-
Sanchayan Maity authored
Use enable-gpios property of PWM backlight driver for backlight control. Signed-off-by:
Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Sanchayan Maity authored
Remove use of pwm-leds and use the standard /sys/class/pwm interface from PWM subsystem. Signed-off-by:
Sanchayan Maity <maitysanchayan@gmail.com> Acked-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
Sanchayan Maity authored
Add support for Toradex Colibri iMX6 module. Signed-off-by:
Sanchayan Maity <maitysanchayan@gmail.com> Acked-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org>
-
- 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>
-
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 berlin2cd. [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>
-
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 berlin2q. [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>
-
Jisheng Zhang authored
After commit f29a72c2 ("watchdog: dw_wdt: Convert to use watchdog infrastructure"), the dw_wdt driver can support multiple variants, so unconditionally enable all dw_wdt nodes now. Signed-off-by:
Jisheng Zhang <jszhang@marvell.com> Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
After commit f29a72c2 ("watchdog: dw_wdt: Convert to use watchdog infrastructure"), the dw_wdt driver can support multiple variants, so unconditionally enable all dw_wdt nodes now. Signed-off-by:
Jisheng Zhang <jszhang@marvell.com> Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Linus Walleij authored
The HTC GPIO driver is a pure GPIO driver and I just can not see what it is doing inside MFD. Let's just move it to GPIO and take this opportunity to move the platform data to <linux/platform_data/gpio-htc-egpio.h> Cc: arm@kernel.org Cc: Russell King <linux@armlinux.org.uk> Acked-by:
Lee Jones <lee.jones@linaro.org> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
- Sep 28, 2016
-
-
Al Viro authored
externs and defines for stuff that is never used Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-