With ARCH_VEXPRESS_SPC option, kernel build has the following
warning:

arch/arm/mach-vexpress/spc.c: In function ‘ve_spc_clk_init’:
arch/arm/mach-vexpress/spc.c:431:38: warning: array subscript is below array bounds [-Warray-bounds]
  struct ve_spc_opp *opps = info->opps[cluster];
                                      ^
since 'cluster' maybe '-1' in UP system. This patch does a active
checking to fix this issue.
Signed-off-by: NAlex Shi <alex.shi@linaro.org>
Acked-by: NPawel Moll <pawel.moll@arm.com>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Without this patch the kexec-purgatory.c and purgatory.ro files are not
removed after make mrproper.
Signed-off-by: NMichael Welling <mwelling@ieee.org>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix building errors occuring due to a missing export of
flush_icache_range() in

kisskb.ellerman.id.au/kisskb/buildresult/11677809/

ERROR: "flush_icache_range" [drivers/misc/lkdtm.ko] undefined!
Signed-off-by: NPranith Kumar <bobby.prani@gmail.com>
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Vineet Gupta <vgupta@synopsys.com>	[arc]
Acked-by: Richard Kuo <rkuo@codeaurora.org>	[hexagon]
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Chris Zankel <chris@zankel.net>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>	[xtensa]
Cc: Noam Camus <noamc@ezchip.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Acked-by: Zhigang Lu <zlu@tilera.com>		[tile]
Cc: Kirill Tkhai <tkhai@yandex.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Thomas reported that build of x86_64 kernel was failing for him.  He is
using 32bit tool chain.

Problem is that while compiling purgatory, I have not specified -m64
flag.  And 32bit tool chain must be assuming -m32 by default.

Following is error message.

(mini) [~/work/linux-2.6] make
scripts/kconfig/conf --silentoldconfig Kconfig
  CHK     include/config/kernel.release
  UPD     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  UPD     include/generated/utsrelease.h
  CC      arch/x86/purgatory/purgatory.o
arch/x86/purgatory/purgatory.c:1:0: error: code model 'large' not supported in
the 32 bit mode

Fix it by explicitly passing appropriate -m64/-m32 build flag for
purgatory.
Reported-by: NThomas Glanzmann <thomas@glanzmann.de>
Tested-by: NThomas Glanzmann <thomas@glanzmann.de>
Suggested-by: NH. Peter Anvin <hpa@zytor.com>
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

New system call depends on crypto.  As it did not have a separate config
option, CONFIG_KEXEC was modified to select CRYPTO and CRYPTO_SHA256.

But now previous patch introduced a new config option for new syscall.
So CONFIG_KEXEC does not require crypto.  Remove that dependency.
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently new system call kexec_file_load() and all the associated code
compiles if CONFIG_KEXEC=y.  But new syscall also compiles purgatory
code which currently uses gcc option -mcmodel=large.  This option seems
to be available only gcc 4.4 onwards.

Hiding new functionality behind a new config option will not break
existing users of old gcc.  Those who wish to enable new functionality
will require new gcc.  Having said that, I am trying to figure out how
can I move away from using -mcmodel=large but that can take a while.

I think there are other advantages of introducing this new config
option.  As this option will be enabled only on x86_64, other arches
don't have to compile generic kexec code which will never be used.  This
new code selects CRYPTO=y and CRYPTO_SHA256=y.  And all other arches had
to do this for CONFIG_KEXEC.  Now with introduction of new config
option, we can remove crypto dependency from other arches.

Now CONFIG_KEXEC_FILE is available only on x86_64.  So whereever I had
CONFIG_X86_64 defined, I got rid of that.

For CONFIG_KEXEC_FILE, instead of doing select CRYPTO=y, I changed it to
"depends on CRYPTO=y".  This should be safer as "select" is not
recursive.
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Tested-by: NShaun Ruffell <sruffell@digium.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at
mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels:
where zap_pte_range() checks page->mapping to see if PageAnon(page).

Those addresses fit struct pages for pfns d2001 and d2000, and in each
dump a register or a stack slot showed d2001730 or d2000730: pte flags
0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has
a hole between cfffffff and 100000000, which would need special access.

Commit c46a7c81 ("x86: define _PAGE_NUMA by reusing software bits on
the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL
pte no longer passes the pte_special() test, so zap_pte_range() goes on
to try to access a non-existent struct page.

Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to
complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE).  A
hint that this was a problem was that c46a7c81 added pte_numa() test
to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast
path: This was papering over a pte_special() snag when the zero page was
encountered during zap.  This patch reverts vm_normal_page() to how it
was before, relying on pte_special().

It still appears that this patch may be incomplete: aren't there other
places which need to be handling PROTNONE along with PRESENT?  For
example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a
PROT_NONE area, that would make it pte_special().  This is side-stepped
by the fact that NUMA hinting faults skipped PROT_NONE VMAs and there
are no grounds where a NUMA hinting fault on a PROT_NONE VMA would be
interesting.

Fixes: c46a7c81 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels")
Reported-by: NSasha Levin <sasha.levin@oracle.com>
Tested-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NHugh Dickins <hughd@google.com>
Signed-off-by: NMel Gorman <mgorman@suse.de>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: <stable@vger.kernel.org>	[3.16]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O writes with weaker barrier semantics than the
non-relaxed variants.

This patch implements these write macros for Alpha, in the same vein as
the relaxed read macros, which are already implemented.
Acked-by: NRichard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NMichael Cree <mcree@orcon.net.nz>
Signed-off-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
We need to keep IRQ assignment for PCI devices during runtime power
management, otherwise it may cause failure of device wakeups.

Commit 3eec5952 "x86, irq, PCI: Keep IRQ assignment for PCI
devices during suspend/hibernation" has fixed the issue for suspend/
hibernation, we also need the same fix for runtime device sleep too.

Fix: https://bugzilla.kernel.org/show_bug.cgi?id=83271Reported-and-Tested-by: NEmanueL Czirai <amanual@openmailbox.org>
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: EmanueL Czirai <amanual@openmailbox.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Grant Likely <grant.likely@linaro.org>
Link: http://lkml.kernel.org/r/1409304383-18806-1-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Commit 43fef47f (mfd: twl4030-power: Add a configuration to turn
off oscillator during off-idle) added support for configuring the PMIC
to cut off resources during deeper idle states to save power.

This however caused regression for n900 display power that needed the
PMIC configuration to be disabled with commit d937678a (ARM: dts:
Revert enabling of twl configuration for n900).

Turns out the root cause of the problem is that we must use
TWL4030_RESCONFIG_UNDEF instead of DEV_GRP_NULL to avoid disabling
regulators that may have been enabled before the init function
for twl4030-power.c runs. With TWL4030_RESCONFIG_UNDEF we let the
regulator framework control the regulators like it should. Here we
need to only configure the sys_clken and sys_off_mode triggers for
the regulators that cannot be done by the regulator framework as
it's not running at that point.

This allows us to enable the PMIC configuration for n900.

Fixes: 43fef47f (mfd: twl4030-power: Add a configuration to turn off oscillator during off-idle)

Cc: stable@vger.kernel.org # v3.16
Signed-off-by: NTony Lindgren <tony@atomide.com>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

To deal with IPs which are specific to dra74x and dra72x, maintain seperate
ocp interface lists, while keeping the common list for all common IPs.

Move USB OTG SS4 to dra74x only list since its unavailable in
dra72x and is giving an abort during boot. The dra72x only list
is empty for now and a placeholder for future hwmod additions which
are specific to dra72x.

Fixes: d904b38d ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss")
Reported-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
[paul@pwsan.com: fixed comment style to conform with CodingStyle]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Use the corresponding compatibles to identify the devices.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit 15a3c7cc "x86, irq: Introduce two helper functions
to support irqdomain map operation" breaks LPSS ACPI enumerated
devices.

On startup, IOAPIC driver preallocates IRQ descriptors and programs
IOAPIC pins with default level and polarity attributes for all legacy
IRQs. Later legacy IRQ users may fail to set IOAPIC pin attributes
if the requested attributes conflicts with the default IOAPIC pin
attributes. So change mp_irqdomain_map() to allow the first legacy IRQ
user to reprogram IOAPIC pin with different attributes.
Reported-and-tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Link: http://lkml.kernel.org/r/1409118795-17046-1-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

This patch is important for the MicroSOM implementation due to the
following details -

1. VIH of the Atheros phy is 1.7V.
2. NVCC_ENET which is the power domain of the MDIO pad is driven by the
   PHY's LDO (i.e. either 1.8v or 2.5v).
3. The MicroSOM implements an onbouard 1.6kohm pull up to 3.3v (R3000).

In the case the PHY's LDO was 1.8v then there would be only a 100mV
margin for the signal to be acknowledged as high (1.8v-1.7v).
Due to that setting the pad as an open drain will let the 1.6kohm pull
that signal high to 3.3 that assures enough margins to the PHY to be
acked as '1' logic.
Signed-off-by: NRabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>

Similarly to DRA7, OMAP5 has l3 and l4 clock rates incorrectly calculated.
Fixed by using proper divider clock types for the clock nodes.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reported-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

There were several issues (of varying degree of importance) pointed out
with this code late in the review cycle, yet the code was still merged.
Let's rip it out for now and look at resubmitting at a later time.

This reverts most of commit 4fbe66d9.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Looks like MUSB cable removal can cause wake-up interrupts to
stop working for device tree based booting at least for UART3
even as nothing is dynamically remuxed. This can be fixed by
calling reconfigure_io_chain() for device tree based booting
in hwmod code. Note that we already do that for legacy booting
if the legacy mux is configured.

My guess is that this is related to UART3 and MUSB ULPI
hsusb0_data0 and hsusb0_data1 support for Carkit mode that
somehow affect the configured IO chain for UART3 and require
rearming the wake-up interrupts.

In general, for device tree based booting, pinctrl-single
calls the rearm hook that in turn calls reconfigure_io_chain
so calling reconfigure_io_chain should not be needed from the
hwmod code for other events.

So let's limit the hwmod rearming of iochain only to
HWMOD_FORCE_MSTANDBY where MUSB is currently the only user
of it. If we see other devices needing similar changes we can
add more checks for it.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: stable@vger.kernel.org # v3.16
Signed-off-by: NTony Lindgren <tony@atomide.com>

For device tree based booting, we need to use wake-up
interrupts like we already do for some omaps. This fixes
a PM regression on beagleboard compared to legacy booting.
Tested-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The kernel has never supported clk32g as a regulator since it is a clock
and not a regulator. Fortunately nothing actually references this node so
we can just remove it.
Signed-off-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

When an alias for a clock already exists the warning is printed. For
every module with a main_clk defined, a clk alias for fck is added.
There are some components that have the same main_clk defined, so this
is a really normal situation.

For example the am33xx edma device has 4 components using the same main
clock. So there are three warnings in the boot log for this already
existing clock alias:
	platform 49000000.edma: alias fck already exists
	platform 49000000.edma: alias fck already exists
	platform 49000000.edma: alias fck already exists

As this is only interesting for developers, this patch changes the
message to a debug message.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix %d confusingly prefixed with 0x in format string.
Signed-off-by: NHans Wennborg <hans@hanshq.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>

GPIO modules are also interrupt sources. However, they require both the
GPIO number and IRQ type to function properly.

By declaring that GPIO uses interrupt-cells=<1>, we essentially do not
allow users of the nodes to use the interrupt property appropritely.

With this change, the following now works:

interrupt-parent = <&gpio6>;
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;

Fixes: 6e58b8f1 ('ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board')
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For v3.14 and prior, 1-bit Hamming code ECC via software was used
for NAND on this board.
Commit c06c5270 in v3.15 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.14
and prior to be unusable in v3.15 and later. So revert back to
using software ECC scheme.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For v3.14 and prior, 1-bit Hamming code ECC via software was the
default choice for some boards e.g. 3430sdp.
Commit ac65caf5 in v3.15 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.14
and prior to be unusable in v3.15 and later. So don't mark "sw" scheme
as deperecated and support it.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For v3.12 and prior, 1-bit Hamming code ECC via software was the
default choice. Commit c66d0391 in v3.13 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.12
and prior to be unusable in v3.13 and later. So revert back to
using software ECC by default if an ECC scheme is not explicitely
specified.

This defect can be observed on the following boards during legacy boot

-omap3beagle
-omap3touchbook
-overo
-am3517crane
-devkit8000
-ldp
-3430sdp
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Tested-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Upstream commit:

  95d76acc ("x86, irq: Count legacy IRQs by legacy_pic->nr_legacy_irqs instead of NR_IRQS_LEGACY")

removed reserved interrupts for the platforms that do not have a legacy IOAPIC.

Which breaks the boot on Intel MID platforms such as Medfield:

  BUG: unable to handle kernel NULL pointer dereference at 0000003a
  IP: [<c107079a>] setup_irq+0xf/0x4d [    0.000000] *pdpt = 0000000000000000 *pde = 9bbf32453167e510

The culprit is an uncoditional setting of IRQ2 which is used
as cascade IRQ on legacy platforms. It seems we have to check
if we have enough legacy IRQs reserved before we can call
setup_irq().

The fix adds such check in native_init_IRQ() and in setup_default_timer_irq().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NJiang Liu <jiang.liu@linux.intel.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Cc: David Cohen <david.a.cohen@linux.intel.com>
Link: http://lkml.kernel.org/r/1405931920-12871-1-git-send-email-andriy.shevchenko@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>

Hummingboard has no over current hardware, so disable the over current
detection for both ports.

Cubox-i has over current hardware, so appropriately configure this.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>

On r8a7791, i2c6 (aka iic3) doesn't need pinmux, but the koelsch dts
refers to non-existent pinmux configuration data:

pinmux core: sh-pfc does not support function i2c6
sh-pfc e6060000.pfc: invalid function i2c6 in map table

Remove it to fix this.

Fixes: commit 1d41f36a ("ARM: shmobile:
       koelsch dts: Add VDD MPU regulator for DVFS")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Working on Gigabit/PCIe support in U-Boot for Apalis T30 I realised
that the current device tree source includes for our modules only
happen to work due to referencing the on-carrier 5v0 supply from USB
which is not at all available on-module. The modules actually contain
TPS60150 charge pumps to generate the PMIC required 5 volts from the
one and only 3.3 volt module supply. This patch fixes this.

(Note: When back-porting this to v3.16 stable releases, simply drop the
change to tegra30-apalis.dtsi; that file was added in v3.17)

Cc: <stable@vger.kernel.org> #v3.16+
Signed-off-by: NMarcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

During the restructuring of the Rockchip Cortex-A9 dtsi files it seems
like the pinctrl settings vanished at some point from the mmc0 support.

This of course renders them unusable, so readd the necessary pinctrl
properties.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

"efi" global data structure contains "runtime_version" field which must
be assigned in order to use it later in Runtime Services virtual calls
(virt_efi_* functions).

Before this patch "runtime_version" was unassigned (0), so each
Runtime Service virtual call that checks revision would fail.
Signed-off-by: NSemen Protsenko <semen.protsenko@linaro.org>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Currently the sh-intc driver is compiled on all SuperH and
non-multiplatform SH-Mobile platforms, while it's only used on a limited
number of platforms:
  - SuperH: SH2(A), SH3(A), SH4(A)(L) (all but SH5)
  - ARM: sh7372, sh73a0

Drop the "default y" on SH_INTC, make all CPU platforms that use it
select it, and protect all sub-options by "if SH_INTC" to fix this.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NMagnus Damm <damm+renesas@opensource.se>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

4bfb358b
(ARM: shmobile: Add r8a7791 legacy SDHI clocks)
added r8a7791 SDHI clock support.

But, it is missing
"0x0100: x 1/8" division ratio.
This patch fixes hidden bug.
It is based on R-Car H2 v0.7, R-Car M2 v0.9.
Reported-by: NYusuke Goda <yusuke.goda.sx@renesas.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

9f13ee6f
(ARM: shmobile: r8a7790: add div4 clocks)
added r8a7790 DIV4 clock support.

But, it is missing
"0x0100: x 1/8" division ratio.
This patch fixes hidden bug.
It is based on R-Car H2 v0.7, R-Car M2 v0.9.
Reported-by: NYusuke Goda <yusuke.goda.sx@renesas.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Add new memfd_create syscall.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Add new getrandom syscall.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Add new seccomp syscall.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Increase max i2c bus frequency beyond the default for faster
data transfers. According to the manual, these faster speeds are
only available when the board is wired up the right way. In this case,
the vendor kernel has run at this speed for a long time.

sda-delay is needed for talking to RTC on PMIC, otherwise the i2c
controller never sees an ACK. Strangely the other PMIC i2c slave (the
main one) works fine even without this delay. I Chose value 100 to
match the vendor kernel.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>