HID: sensor-hub: make dyn_callback_lock IRQ-safe

dyn_callback_lock is being taken from IRQ context through hid_irq_in() ->
hid_input_report() -> sensor_hub_raw_event() -> sensor_hub_get_callback(),
therefore anyone else acquiring it needs to disable IRQs to disable deadlocks.

Reported-by: Alexander Holler <holler@ahsoftware.de>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Reported-by: Reyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: sensor-hub: introduce Kconfig dependency on IOMEM

When NO_IOMEM is enabled (e.g. score architecture), some drivers which
need HAS_IOMEM need notice about it, or it will report related warning:

  warning: (GPIO_SCH && GPIO_ICH && GPIO_VX855 && GPIO_RDC321X && IE6XX_WDT && RADIO_WL1273 && HID_SENSOR_HUB && MFD_NVEC) selects MFD_CORE which has unmet direct dependencies (HAS_IOMEM)

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: rmi: Protect PM-only functions by #ifdef CONFIG_PM

If CONFIG_PM=n:

drivers/hid/hid-rmi.c:432: warning: ‘rmi_post_reset’ defined but not used
drivers/hid/hid-rmi.c:437: warning: ‘rmi_post_resume’ defined but not used

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX

am43xx reset register layout is more similar to am33xx than omap4 so
use the am33xx functions for hwmod hardreset soc_ops rather than the
currently used omap4 functions. Without this, assert_hardreset and
deassert_hardreset will not work on am43xx.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[paul@pwsan.com: fixed build errors for an AM43xx-only Kconfig]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods

Create hwmods for ocp2scp3 and sata modules.

[Roger Q] Clean up.

CC: Benoit Cousson <bcousson@baylibre.com>
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: dts: Enable twl4030 off-idle configuration for selected omaps

N900 now seems to shut down the external oscillator when hitting
off-idle.

And Beagle XM seems to have OSC_EN pin connected to allow shutting
down the oscillator looking at the schematics. The oscillator
output is cut off in off-idle and you can monitor it from R56 on
the bottom side of the board near the power jack. Note that for
beagle we need to also enable the UART wake-up event, the others
have that enabled in earlier patches.

OMAP37XX EVM (TMDSEVM3730) does not seem to have twl4030 clken
pin connected, so there is no point trying to enable shutting
down of the oscillator on it for the extra latency it adds.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Merge tag 'for-v3.16-rc/omap-fixes-a' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.16/fixes

Two OMAP hwmod patches for early v3.16-rc kernels.

There's one OMAP SoC integration fix for the AM43xx SoC, without
which, IP blocks can't be placed into hard-reset.

There is also one OMAP5 SoC data addition patch that should have gone
in for v3.16. Normally I wouldn't send this as part of an -rc series,
since it's not technically a fix. But I'd like to make an exception in
this case because:

- it's intended to go in very early in the v3.16-rc series (or even
pre-rc1);

- it's a fairly small change;

- the impact is limited to a single SoC and a single device;

- the only reason that it didn't go in earlier is because it "slipped
through the cracks," rather than for any technical reason.

Basic build, boot, and PM test logs are available here:

http://www.pwsan.com/omap/testlogs/hwmod-a-v3.16-rc/20140615201307/
ARM: DRA722: add detection of SoC information

Add support for DRA72x device DIEID. Currently these devices are
reported as DRA75/74 family of processors.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: dts: omap5: Update CPU OPP table as per final production Manual

As per the Final production Data Manual for OMAP5432,
SWPS050F(APRIL 2014)

There are only two OPPs - 1GHz and 1.5GHz. the older OPP_LOW has been
completely descoped. The Nominal voltages are still correct though.
However, expectation for final production configuration is operation
with Adaptive Body Bias (ABB) and Adaptive Voltage Scaling Class 0
operation.

There are no IDcode or version change information encoded to
programmatically detect this and software is supposed to NOT use
OPP_LOW(500MHz) anymore for all devices (legacy and production
samples).

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: dts: am43x-epos-evm: Add Missing cpsw-phy-sel for am43x-epos-evm

AM437x EPOS evm use external clock for RMII interface.
Enable the same in DT.

Signed-off-by: George Cherian <george.cherian@ti.com>
Reported-by: Nishanth Menon <nm@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: drop unused function

gic_init_irq() is no longer used as of:

    commit b42b918194c4791510ac049e3d507169a7de8544
    Author: Tony Lindgren <tony@atomide.com>
    Date:   Thu May 30 12:53:05 2013 -0700

        ARM: OMAP2+: Remove board-omap4panda.c

Drop it.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: DTS: dra7/dra7xx-clocks: ATL related changes

Modify the clock nodes for the ATL clocks to use the ATL clock driver to
handle them.

Add the ATL device node at the same time for DRA7.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: Fix parser-bug in platform muxing code

Fix a parser-bug in the omap2 muxing code where muxtable-entries will be
wrongly selected if the requested muxname is a *prefix* of their
m0-entry and they have a matching mN-entry. Fix by additionally checking
that the length of the m0_entry is equal.

For example muxing of "dss_data2.dss_data2" on omap32xx will fail
because the prefix "dss_data2" will match the mux-entries "dss_data2" as
well as "dss_data20", with the suffix "dss_data2" matching m0 (for
dss_data2) and m4 (for dss_data20). Thus both are recognized as signal
path candidates:

Relevant muxentries from mux34xx.c:
        _OMAP3_MUXENTRY(DSS_DATA20, 90,
                "dss_data20", NULL, "mcspi3_somi", "dss_data2",
                "gpio_90", NULL, NULL, "safe_mode"),
        _OMAP3_MUXENTRY(DSS_DATA2, 72,
                "dss_data2", NULL, NULL, NULL,
                "gpio_72", NULL, NULL, "safe_mode"),

This will result in a failure to mux the pin at all:

 _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2

Patch should apply to linus' latest master down to rather old linux-2.6
trees.

Signed-off-by: David R. Piegdon <lkml@p23q.org>
Cc: stable@vger.kernel.org
[tony@atomide.com: updated description to include full description]
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: dts: dra7-evm: remove interrupt binding

The qspi node defines crossbar number as its interrupt number. But,
the crossbar dts patches are not yet there, this causes a warning during
boot.  So interrupts = < > property should be removed from DT and added
later by crossbar series.

Reported-by: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
pinctrl: sunxi: Fix potential null pointer dereference

kzalloc can fail. Add a null check to avoid null pointer
dereference error while accessing the pointer later.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
irqchip: armada-370-xp: Mask all interrupts during initialization.

Until now, the irq-armada-370-xp irqchip driver was not masking all
interrupts at initialization. While in most cases this is not a
problem because the bootloader has probably masked all interrupts, it
becomes a problem when you use kexec: you're in kernel A, with many
interrupts enabled, and then kexec into kernel B, without going
through the bootloader. So during the boot process, if an interrupt
occurs while the corresponding driver has not been loaded, you would
get spurious interrupts.

This commit fixes that by ensuring all interrupts are properly masked
when the irqchip driver is initialized. Note that interrupt masking
takes place at two level: at the global level (main_int_base) and at
the per-CPU level (per_cpu_int_base).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1401481098-23326-6-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
irqchip: brcmstb-l2: Level-2 interrupts are edge sensitive

The driver was configuring the interrupt handler for the Level-2
interrupts to be "level" triggered while they are in fact "edge"
triggered. Fix this by using the correct handler.

Reported-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lkml.kernel.org/r/1402337102-19428-1-git-send-email-f.fainelli@gmail.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
irqchip: spear_shirq: Fix interrupt offset

The ras3 block on spear320 claims to have 3 interrupts. In fact it has
one and 6 reserved interrupts. Account the 6 reserved to this block so
it has 7 interrupts total. That matches the datasheet and the device
tree entries.

Broken since commit 80515a5a(ARM: SPEAr3xx: shirq: simplify and move
the shared irq multiplexor to DT). Testing is overrated....

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20140619212712.872379208@linutronix.de
Fixes: 80515a5a2e3c ('ARM: SPEAr3xx: shirq: simplify and move the shared irq multiplexor to DT')
Cc: <stable@vger.kernel.org> # v3.8+
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
scsi_error: fix invalid setting of host byte

After scsi_try_to_abort_cmd returns, the eh_abort_handler may have
already found that the command has completed in the device, causing
the host_byte to be nonzero (e.g. it could be DID_ABORT).  When
this happens, ORing DID_TIME_OUT into the host byte will corrupt
the result field and initiate an unwanted command retry.

Fix this by using set_host_byte instead, following the model of
commit 2082ebc45af9c9c648383b8cde0dc1948eadbf31.

Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Obergfell <uobergfe@redhat.com>
[Fix all instances according to review comments. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
scsi_error: set DID_TIME_OUT correctly

Any callbacks in scsi_timeout_out() might return BLK_EH_RESET_TIMER,
in which case we should leave the result alone and not set
DID_TIME_OUT, as the command didn't actually timeout.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>