The file has gotten a little out of sync, as platforms got
added in the wrong place, or have been renamed. This moves
the options around, but should not change any functionality.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Footbridge has two debug ports that are handled a bit differently:

The 8250 port uses the normal debug/8250.S implementation that is shared
with a lot of other platforms, but it relies on the DEBUG_UART_8250
option to be turned on automatically instead of being selected by
DEBUG_FOOTBRIDGE_COM1 as we do for most other platforms. I'm changing
this to use a 'select' and change the dependency to the debug symbol
rather than the platform symbol for consistency.

The DC21285 UART has a separate top-level option, and relies on
the traditional include/mach/debug-macro.S method. With the s3c64xx
multiplatform series queued up for 4.5, it is now the last one that does
this, so by moving this file to include/debug/dc21285.S, we can get
all platforms to do things the same way.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

LPC32xx can not yet be configured in a multiplatform kernel, but
if we ever get there, enabling one of the LPC32xx platforms
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.

This changes the logic to use the LPC32xx default addresses only
if we have also picked the respective Kconfig symbols introduced
here.

While we're at it, this also reorders the virtual address as
it should be.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>

Gemini can not yet be configured in a multiplatform kernel, but
if we ever get there, enabling one of the gemini platforms
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.

This changes the logic to use the gemini default addresses and
the flow control settings only if we have also picked the respective
Kconfig symbols introduced here.

While we're at it, this also reorders the virtual address as
it should be.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NHans Ulli Kroll <ulli.kroll@googlemail.com>

Enabling one of the integrator platforms in a multiplatform kernel
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.

This changes the logic to use the integrator default addresses only
if we have also picked the respective Kconfig symbols introduced
here. Versatile is not yet part of multiplatform, but hopefully
soon will be, so we do the same change for versatile as well.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Enabling one of the SPEAr platforms in a multiplatform kernel
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.

This changes the logic to use the SPEAr default addresses only
if we have also picked the respective Kconfig symbols introduced
here.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This makes ep93xx debug-ll handling more consistent with the other
platforms, by adding a separate Kconfig symbol for it that
in turn selects the standard DEBUG_UART_PL01X symbol.

We still have to pick a physical address even if DEBUG_LL is disabled
here, because the EP93xx uncompress output code uses
CONFIG_DEBUG_UART_PHYS. If we ever move to multiplatform support,
this can go away.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

As we are moving dove/mv78xx0/orion into multiplatform, the debug-ll
configuration options for these platforms are conflicting with the
multiplatform configuration: enabling one of those platforms sometimes
changes the default addresses to the ones used on one of them, rather
than the one that was selected in Kconfig.

This changes the configuration so we share the physical address
configuration with mach-mvebu.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

We may have multiple platforms enabled and also DEBUG_LL
configured for one of them. However if we enable ARCH_KEYSTONE,
we default to using 32-bit UART access independent of which
platform we are actually using, which can be confusing.

This changes the logic so the 32-bit default gets only
used by default if we actually configure the keystone
UART, as opposed to picking some other 8250 setting on
a kernel that has keystone support enabled.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

I could not find any users of this file, past or present, and
it contains only a comment, so let's remove it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Some header files are never included outside of a mach-w90x900
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Some header files are never included outside of a mach-iop13xx
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Some header files are never included outside of a mach-davinci
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NSekhar Nori <nsekhar@ti.com>

Some header files are never included outside of a mach-ks8695
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NGreg Ungerer <gerg@uclinux.org>

Some header files are never included outside of a mach-omap1
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NTony Lindgren <tony@atomide.com>

Lots of header files are never included outside of a mach-pxa
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

On the ARM architecture, individual platforms select CONFIG_USE_OF if they
need it, but all device tree code is keyed off CONFIG_OF. When building
a platform without DT support and manually enabling CONFIG_OF, we now
get a number of build errors, e.g.

arch/arm/kernel/devtree.c: In function 'setup_machine_fdt':
arch/arm/kernel/devtree.c:215:19: error: implicit declaration of function 'early_init_dt_verify' [-Werror=implicit-function-declaration]

We could now try to separate the use case of booting from DT vs. the
case of using the dynamic implementation, but that seems more complicated
than it can gain us.

This simply changes the ARM Kconfig file to always enable OF_RESERVED_MEM
and OF_EARLY_FLATTREE when CONFIG_OF is enabled. These options add a little
extra code when we just want the dynamic OF implementation, but that seems
like a rather obscure case, and this version solves all CONFIG_OF related
randconfig regressions.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 0166dc11 ("of: make CONFIG_OF user selectable")
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

After commit 8c058b0b ("x86/irq: Probe for PIC presence before
allocating descs for legacy IRQs") early_irq_init() will no longer
preallocate descriptors for legacy interrupts if PIC does not
exist, which is the case for Xen PV guests.

Therefore we may need to allocate those descriptors ourselves.
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Suggested-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

Commit b3a72384 ("ARM/PCI: Replace pci_sys_data->align_resource with
global function pointer") introduced an ARM-specific align_resource()
function pointer.  This is not portable to other arches and doesn't work
for platforms with two different PCIe host bridge controllers.

Move the function pointer to the pci_host_bridge structure so each host
bridge driver can specify its own align_resource() function.
Signed-off-by: NGabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>

OMAP CPU hotplug uses cpu1's clocks and power domains for CPU1 wake up
from low power states (or turn on CPU1). This part of code is also
part of system suspend (disable_nonboot_cpus()).
>From other side, cpu1's clocks and power domains are used by CPUIdle. All above
functionality is mutually exclusive and, therefore, lockless clkdm/pwrdm api
can be used in omap4_boot_secondary().

This fixes below back-trace on -RT which is triggered by
pwrdm_lock/unlock():

BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
 in_atomic(): 1, irqs_disabled(): 0, pid: 118, name: sh
 9 locks held by sh/118:
  #0:  (sb_writers#4){.+.+.+}, at: [<c0144a6c>] vfs_write+0x13c/0x164
  #1:  (&of->mutex){+.+.+.}, at: [<c01b4c70>] kernfs_fop_write+0x48/0x19c
  #2:  (s_active#24){.+.+.+}, at: [<c01b4c78>] kernfs_fop_write+0x50/0x19c
  #3:  (device_hotplug_lock){+.+.+.}, at: [<c03cbff0>] lock_device_hotplug_sysfs+0xc/0x4c
  #4:  (&dev->mutex){......}, at: [<c03cd284>] device_online+0x14/0x88
  #5:  (cpu_add_remove_lock){+.+.+.}, at: [<c003af90>] cpu_up+0x50/0x1a0
  #6:  (cpu_hotplug.lock){++++++}, at: [<c003ae48>] cpu_hotplug_begin+0x0/0xc4
  #7:  (cpu_hotplug.lock#2){+.+.+.}, at: [<c003aec0>] cpu_hotplug_begin+0x78/0xc4
  #8:  (boot_lock){+.+...}, at: [<c002b254>] omap4_boot_secondary+0x1c/0x178
 Preemption disabled at:[<  (null)>]   (null)

 CPU: 0 PID: 118 Comm: sh Not tainted 4.1.12-rt11-01998-gb4a62c3-dirty #137
 Hardware name: Generic DRA74X (Flattened Device Tree)
 [<c0017574>] (unwind_backtrace) from [<c0013be8>] (show_stack+0x10/0x14)
 [<c0013be8>] (show_stack) from [<c05a8670>] (dump_stack+0x80/0x94)
 [<c05a8670>] (dump_stack) from [<c05ad158>] (rt_spin_lock+0x24/0x54)
 [<c05ad158>] (rt_spin_lock) from [<c0030dac>] (clkdm_wakeup+0x10/0x2c)
 [<c0030dac>] (clkdm_wakeup) from [<c002b2c0>] (omap4_boot_secondary+0x88/0x178)
 [<c002b2c0>] (omap4_boot_secondary) from [<c0015d00>] (__cpu_up+0xc4/0x164)
 [<c0015d00>] (__cpu_up) from [<c003b09c>] (cpu_up+0x15c/0x1a0)
 [<c003b09c>] (cpu_up) from [<c03cd2d4>] (device_online+0x64/0x88)
 [<c03cd2d4>] (device_online) from [<c03cd360>] (online_store+0x68/0x74)
 [<c03cd360>] (online_store) from [<c01b4ce0>] (kernfs_fop_write+0xb8/0x19c)
 [<c01b4ce0>] (kernfs_fop_write) from [<c0144124>] (__vfs_write+0x20/0xd8)
 [<c0144124>] (__vfs_write) from [<c01449c0>] (vfs_write+0x90/0x164)
 [<c01449c0>] (vfs_write) from [<c01451e4>] (SyS_write+0x44/0x9c)
 [<c01451e4>] (SyS_write) from [<c0010240>] (ret_fast_syscall+0x0/0x54)
 CPU1: smp_ops.cpu_die() returned, trying to resuscitate

Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add missing HWMOD_NO_IDLEST hwmod flag for entries not
having omap4 clkctrl values.
The emac0 hwmod flag fixes the davinci_emac driver probe
since the return of pm_resume() call is now checked.

This solves the following boot errors :
[    0.121429] omap_hwmod: l4_ls: _wait_target_ready failed: -16
[    0.121441] omap_hwmod: l4_ls: cannot be enabled for reset (3)
[    0.124342] omap_hwmod: l4_hs: _wait_target_ready failed: -16
[    0.124352] omap_hwmod: l4_hs: cannot be enabled for reset (3)
[    1.967228] omap_hwmod: emac0: _wait_target_ready failed: -16

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 5be9fc23 ("ARM: orion5x: fix legacy orion5x IRQ numbers") shifted
IRQ numbers by one but didn't update the get_irqnr_and_base macro
accordingly.  This macro is involved when CONFIG_MULTI_IRQ_HANDLER
is not defined.

[jac: 5d6bed2a went in to v4.2, but was backported to v3.18]
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Fixes: 5be9fc23 ("ARM: orion5x: fix legacy orion5x IRQ numbers")
Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Commit 5d6bed2a ("ARM: dove: fix legacy dove IRQ numbers") shifted
IRQ numbers by one but didn't update the get_irqnr_and_base macro
accordingly.  This macro is involved when CONFIG_MULTI_IRQ_HANDLER
is not defined.

[jac: 5d6bed2a went in to v4.2, but was backported to v3.18]
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Fixes: 5d6bed2a ("ARM: dove: fix legacy dove IRQ numbers")
Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Since commit 3fffd128 ("i2c: allow specifying
separate wakeup interrupt in device tree") we have
automatic wakeup irq support for i2c devices. That
commit missed the fact that rtc-1307 had its own
wakeup irq handling and ended up introducing a
kernel splat for at least Beagle x15 boards.

Fix that by reverting original commit _and_ passing
correct interrupt names on DTS so i2c-core can
choose correct IRQ as wakeup.

Now that we have automatic wakeirq support, we can
revert the original commit which did it manually.

Fixes the following warning:

[   10.346582] WARNING: CPU: 1 PID: 263 at linux/drivers/base/power/wakeirq.c:43 dev_pm_attach_wake_irq+0xbc/0xd4()
[   10.359244] rtc-ds1307 2-006f: wake irq already initialized

Cc: Tony Lindgren <tony@atomide.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

We were setting the physical active state on the GIC distributor in a
preemptible section, which could cause us to set the active state on
different physical CPU from the one we were actually going to run on,
hacoc ensues.

Since we are no longer descheduling/scheduling soft timers in the
flush/sync timer functions, simply moving the timer flush into a
non-preemptible section.
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>

The open coded tests for checking whether a PTE maps a page as
uncached use a flawed '(pte_val(xxx) & CONST) != CONST' pattern,
which is not guaranteed to work since the type of a mapping is
not a set of mutually exclusive bits

For HYP mappings, the type is an index into the MAIR table (i.e, the
index itself does not contain any information whatsoever about the
type of the mapping), and for stage-2 mappings it is a bit field where
normal memory and device types are defined as follows:

    #define MT_S2_NORMAL            0xf
    #define MT_S2_DEVICE_nGnRE      0x1

I.e., masking *and* comparing with the latter matches on the former,
and we have been getting lucky merely because the S2 device mappings
also have the PTE_UXN bit set, or we would misidentify memory mappings
as device mappings.

Since the unmap_range() code path (which contains one instance of the
flawed test) is used both for HYP mappings and stage-2 mappings, and
considering the difference between the two, it is non-trivial to fix
this by rewriting the tests in place, as it would involve passing
down the type of mapping through all the functions.

However, since HYP mappings and stage-2 mappings both deal with host
physical addresses, we can simply check whether the mapping is backed
by memory that is managed by the host kernel, and only perform the
D-cache maintenance if this is the case.

Cc: stable@vger.kernel.org
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: NPavel Fedin <p.fedin@samsung.com>
Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>

Per the Vybrid Reference Manual (section 3.8.6.1), dspi0 has 6 chip
select signals associated with it, while dspi1 has only 4.
Signed-off-by: NCory Tusar <cory.tusar@pid1solutions.com>
Acked-by: NStefan Agner <stefan@agner.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

Currently kernel crash randomly when K2L EVM is booted without
clk_ignore_unused in the bootargs. This workaround is not needed
on other K2 devices such as K2HK and K2E and with this fix, we can
remove the workaround altogether. netcp driver on K2L uses linked
ram on OSR (On chip Static RAM) and requires the clock to this peripheral
enabled for proper functioning. This is the reason for the kernel crash.
So add the clock node to fix this issue.

While at it, remove the workaround documentation as well.

With the fix applied, clk_summary dump shows the clock to OSR enabled.

cat /sys/kernel/debug/clk/clk_summary
 ------cut--------------
   tcp3d-1                   0            0   399360000          0 0
   tcp3d-0                   0            0   399360000          0 0
   osr                       1            1   399360000          0 0
   fftc-0                    0            0   399360000          0 0
 -----cut----------------
Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NSantosh Shilimkar <ssantosh@kernel.org>

GPC irq domain is a child domain of GIC, now all of platform irqs
are inside GPC domain, during the module populate, all devices irq
should have correct type setting in GIC, however, there is no
.irq_set_type callback setting in GPC, so the irq_set_type will be
skipped and cause all irqs' type in /proc/interrupt are "edge" which
mismatch with irq type setting in dtb file. Since GPC has no irq
type setting, so just tell kernel to use irq_chip_set_type_parent.
Signed-off-by: NAnson Huang <Anson.Huang@freescale.com>
Cc: <stable@vger.kernel.org> # 4.1+
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

Something seems to have gone wrong during the merging of the device
tree changes with the following patch

"ARM: dts: add property for maximum ADC clock frequencies"

The property "fsl,adck-max-frequency" instead of being applied for
the ADC1 node got applied to the esdhc0 node. This patch fixes it.
Signed-off-by: NSanchayan Maity <maitysanchayan@gmail.com>
Fixes: def0641e ("ARM: dts: add property for maximum ADC clock frequencies")
Cc: <stable@vger.kernel.org>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

Both the pointer array and the pointed data have to be const when using
__initconst to be correct.  This also fixes LTO builds that otherwise
fail with section mismatch errors.

Fixes: ec60d95b ("ARM: shmobile: Basic r8a7793 SoC support")
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

The newly added zx power domain code causes build errors in
some configurations:

warning: (PM_RMOBILE && SOC_ZX296702) selects PM_GENERIC_DOMAINS which has unmet direct dependencies (PM)
warning: (ARCH_EXYNOS) selects EXYNOS_THERMAL which has unmet direct dependencies (THERMAL && (ARCH_EXYNOS || COMPILE_TEST) && THERMAL_OF)
power/domain.c: In function 'genpd_queue_power_off_work':
power/domain.c:192:13: error: 'pm_wq' undeclared (first use in this function)
  queue_work(pm_wq, &genpd->power_off_work);
             ^
power/domain.c:192:13: note: each undeclared identifier is reported only once for each function it appears in

This ensures we don't try to enable it when CONFIG_PM is
disabled, mirroring what we do on most other platforms.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: f15107f4 ("ARM: zx: Add power domains for ZX296702")
Reviewed-by: NJun Nie <jun.nie@linaro.org>

The patches that were applied to add PWM lookup tables for legacy boards
were from v1 of the series instead of the revised v2 where the resulting
build errors had already been fixed.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The "reg" entry in the "poweroff" section of "kirkwood-ts219.dtsi"
addressed the wrong uart (0 = console). This patch changes the address
to select uart 1, which is the uart connected to the pic
microcontroller, which can switch the device off.
Signed-off-by: NHelmut Klein <hgkr.klein@gmail.com>
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Fixes: 4350a47b ("ARM: Kirkwood: Make use of the QNAP Power off driver.")
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>

Add the "init" anf "sleep" pinctrl as the OTP gpio state.
We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.

"init" pinctrl property is defined by Doug's Patch[0].

Patch[0]:
https://patchwork.kernel.org/patch/7454311/Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The eMMC of the minnie Chromebook doesn't like our current method of
tuning and while there are solutions on the horizon, they still need
investigating. Other Chromebooks tune just fine with the emmc, so
simply disable tuning on Minnie for now.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

For imx27, it needs three clocks to let the controller work,
the old code is wrong, and usbmisc has not included clock handling
code any more. Without this patch, it will cause below data
abort when accessing usbmisc registers.

usbcore: registered new interface driver usb-storage
Unhandled fault: external abort on non-linefetch (0x008) at 0xf4424600
pgd = c0004000
[f4424600] *pgd=10000452(bad)
Internal error: : 8 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.0-next-20150701-dirty #3089
Hardware name: Freescale i.MX27 (Device Tree Support)
task: c7832b60 ti: c783e000 task.ti: c783e000
PC is at usbmisc_imx27_init+0x4c/0xbc
LR is at usbmisc_imx27_init+0x40/0xbc
pc : [<c03cb5c0>]    lr : [<c03cb5b4>]    psr: 60000093
sp : c783fe08  ip : 00000000  fp : 00000000
r10: c0576434  r9 : 0000009c  r8 : c7a773a0
r7 : 01000000  r6 : 60000013  r5 : c7a776f0  r4 : c7a773f0
r3 : f4424600  r2 : 00000000  r1 : 00000001  r0 : 00000001
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005317f  Table: a0004000  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc783e190)
Stack: (0xc783fe08 to 0xc7840000)
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Reported-by: NFabio Estevam <fabio.estevam@freescale.com>
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Cc: <stable@vger.kernel.org> #v4.1+
Acked-by: NShawn Guo <shawnguo@kernel.org>

During review I noticed that the icache range we're flushing should
start at header already and not at ctx.image.

Reason is that after 55309dd3 ("net: bpf: arm: address randomize
and write protect JIT code"), we also want to make sure to flush the
random-sized trap in front of the start of the actual program (analogous
to x86). No operational differences from user side.
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Tested-by: NNicolas Schichan <nschichan@freebox.fr>
Cc: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add sdmmc and flexcom devices
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>