the series of patches for irqdomain core in 3.11 has broken sirf
irq which uses legacy mapping. all users fail in the new kernel
while setupping irq.

this patch moves to linear irqdomain and drop old legacy irqdomain
codes since we don't need it any more, and at the same time, it
also fixes the broken interrupts of sirfsoc in 3.11.

on the other hand, we actually only have 64 interrupt sources for
prima2 and atlas6, but there are 128 interrupt souces for marco
which uses GIC. in the legacy codes, sirf gpio also uses legacy
irqdomain, so to make gpio interrupt mapping not depend on the
prima2/atlas6/marco an use unified marco,we enlarge prima2/atlas6
interrupt number to 128. here we don't need this workaround any
more as sirf gpio also moved to linear mode before. so we move
SIRFSOC_NUM_IRQS back to 64 too.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

This fixes a regression exposed during the merge window by commit
9f310ded "ARM: tegra: fix VBUS regulator GPIO polarity in DT"; namely that
USB VBUS doesn't get turned on, so USB devices are not detected. This
affects the internal USB port on TrimSlice (i.e. the USB->SATA bridge, to
which the SSD is connected) and the external port(s) on Seaboard/
Springbank and Whistler.

The Tegra DT as written in v3.11 allows two paths to enable USB VBUS:

1) Via the legacy DT binding for the USB controller; it can directly
   acquire a VBUS GPIO and activate it.

2) Via a regulator for VBUS, which is referenced by the new DT binding
   for the USB controller.

Those two methods both use the same GPIO, and hence whichever of the
USB controller and regulator gets probed first ends up owning the GPIO.
In practice, the USB driver only supports path (1) above, since the
patches to support the new USB binding are not present until v3.12:-(

In practice, the regulator ends up being probed first and owning the
GPIO. Since nothing enables the regulator (the USB driver code is not
yet present), the regulator ends up being turned off. This originally
caused no problem, because the polarity in the regulator definition was
incorrect, so attempting to turn off the regulator actually turned it
on, and everything worked:-(

However, when testing the new USB driver code in v3.12, I noticed the
incorrect polarity and fixed it in commit 9f310ded "ARM: tegra: fix VBUS
regulator GPIO polarity in DT". In the context of v3.11, this patch then
caused the USB VBUS to actually turn off, which broke USB ports with VBUS
control. I got this patch included in v3.11-rc1 since it fixed a bug in
device tree (incorrect polarity specification), and hence was suitable to
be included early in the rc series. I evidently did not test the patch at
all, or correctly, in the context of v3.11, and hence did not notice the
issue that I have explained above:-(

Fix this by making the USB VBUS regulators always enabled. This way, if
the regulator owns the GPIO, it will always be turned on, even if there
is no USB driver code to request the regulator be turned on. Even
ignoring this bug, this is a reasonable way to configure the HW anyway.

If this patch is applied to v3.11, it will cause a couple pretty trivial
conflicts in tegra20-{trimslice,seaboard}.dts when creating v3.12, since
the context right above the added lines changed in patches destined for
v3.12.
Reported-by: Kyle McMartin <kmcmarti@redhat.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

Starting with kernel v3.5, it is mandatory
to specify ECC strength when using hardware
ECC. Without this, kernel panics with a warning
of the sort:

Driver must set ecc.strength when using hardware ECC
------------[ cut here ]------------
kernel BUG at drivers/mtd/nand/nand_base.c:3519!

Fix this by specifying ECC strength for the boards
which were missing this.
Reported-by: Holger Freyther <holger@freyther.de>
Cc: <stable@vger.kernel.org> #v3.5+
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>

Peripheral-only mode got broken in v3.11-rc1 because of unknown reasons.
Change the mode to OTG, in practice that should work equally well even
when/if the regression gets fixed.

Note that the peripheral-only regression is a separate patch, this change
is still correct as the role is handled by hardware.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

Commit b7e2e75a ("usb: gadget: drop unused USB_GADGET_MUSB_HDRC")
dropped a config symbol that was unused by the musb core, but it turns
out that board support code still had references to it.

As the core now handles both dual role and host-only modes, we can just
pass MUSB_OTG as mode from board files.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

Goodbye TI. Welcome new life!
Signed-off-by: Benoit Cousson <bcousson@baylibre.com>
Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
[tony@atomide.com: updated subject for the name]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

From Nicolas Ferre:
Device tree related fixes:
- USB host numbering for 9x5 which was preventing from using all ports
- a missing UART (not USART) clock lookup table was preventing from using
  them on 9x5
- too large amount of memory was specified for 9n12ek

* tag 'at91-fixes' of git://github.com/at91linux/linux-at91:
  ARM: at91/DT: fix at91sam9n12ek memory node
  ARM: at91: add missing uart clocks DT entries
  ARM: at91/DT: at91sam9x5ek: fix USB host property to enable port C
Signed-off-by: Olof Johansson <olof@lixom.net>

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> # 3.5+

Add clocks to clock lookup table for uart DT entries.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Tested-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Merge tag 'samsung-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes

From Kukjin Kim:
Fix to boot kernel on exynos5440 which has no specific map_io(). Current kernel
cannot support no CPU specific map_io() for Samsung SoCs.

* tag 'samsung-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
  ARM: SAMSUNG: fix to support for missing cpu specific map_io
Signed-off-by: Olof Johansson <olof@lixom.net>

Adding maintainer for arch/arm/mach-keystone/
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>

Srinidhi's mail address is now bouncing and he has requested
me to delete this entry.
Acked-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kevin Hilman <khilman@linaro.org>

This was missed when splitting out the phy from the controller node in
commit 9dffe3be (ARM: tegra: modify ULPI reset GPIO properties).
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

This patch removes sti_secondary_start from _INIT section, there are 2
reason for this removal.
 1. discarding such a small code does not save much, given the RAM
sizes.
 2. Having this code discarded, creates corruption issue when we boot
smp-kernel with nrcpus=1 or with single cpu node in DT.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

This patch fixes cpu nodes with device_type = "cpu". This change was not
necessary before 3.10-rc7.
Without this patch STi SOCs does not boot as SMP.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'renesas-fixes2-for-v3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes

From Simon Horman:
Second round of Renesas ARM based SoC fixes for v3.11

* Lager board: do not annotate gpio_buttons as __initdata
  - This avoids accessing uninitialised memory if keys are pressed
    after kernel initialisation completes.
  - Bug introduced in gpio-keys were enabled in v3.11-rc1

* Bock-W board: fix SDHI0 PFC settings
  - Allow detection of SD card
  - Bug introduced in SDHI support was added in v3.11-rc1

* shdma: fixup sh_dmae_get_partial() calculation error
  - Bug introduced in 2.6.34-rc1.

* armadillo800eva board: Don't request GPIO 166 in board code
  - Allow use of touchscreen
  - Bug introduced in v3.11-rc1

* tag 'renesas-fixes2-for-v3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
  ARM: shmobile: lager: do not annotate gpio_buttons as __initdata
  ARM: shmobile: BOCK-W: fix SDHI0 PFC settings
  shdma: fixup sh_dmae_get_partial() calculation error
  ARM: shmobile: armadillo800eva: Don't request GPIO 166 in board code
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'for-v3.11-rc/omap-fixes-b' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes

From Paul Walmsley via Tony Lindgren:
Some OMAP hwmod fixes for v3.11-rc.  Mostly intended to fix an earlyprintk
regression and an AM33xx cpgmac power management regression.

Basic build, boot, and PM tests are available here:

http://www.pwsan.com/omap/testlogs/hwmod_fixes_a_v3.11-rc/20130730042132/

The tests include temporary fixes for the unrelated 2430SDP and OMAP3
boot regressions, which are not part of this signed tag.

* tag 'for-v3.11-rc/omap-fixes-b' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending:
  ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space
  ARM: OMAP2+: hwmod: rt address space index for DT
  ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device state
  ARM: OMAP2+: Avoid idling memory controllers with no drivers
  ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'omap-for-v3.11/fixes-omap5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

From Tony Lindgren:
Fixes for omap5-uevm regulators from Nishanth Menon <nm@ti.com>:

Due to wrong older revision of documentation used as reference, we
seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
series is based power tree on production board 750-2628-XXX platform.
Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
supply hardware blocks at voltages that are out of specification.

There is a chance that without these fixes there can be hardware
damage to omap5-uevm boards with the v3.11-rc series.

* tag 'omap-for-v3.11/fixes-omap5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: dts: omap5-uevm: update optional/unused regulator configurations
  ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC
  ARM: dts: omap5-uevm: document regulator signals used on the actual board
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'msm-3.11-fix1' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm into fixes

From David Brown, fixes for MSM for 3.11:

Two small fixes for MSM.

The first fixes the a gpio controller register address.  I didn't see
any acks from the devicetree maintainers, so I've copied them on this
pull request.  The change itself is minor, and just to the register
address.

The second change removes the gpiomux V1 code from MSM.  This was
breaking compilation for some of the targets.

* tag 'msm-3.11-fix1' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm:
  ARM: msm: Consolidate gpiomux for older architectures
  ARM: msm: dts: Fix the gpio register address for msm8960
Signed-off-by: Olof Johansson <olof@lixom.net>

When the gpio-keys device is registered using
platform_device_register_data() the platform data argument,
lager_keys_pdata is duplicated and thus should be marked as __initdata
to avoid wasting memory. However, this is not true of gpio_buttons,
a reference to it rather than its value is duplicated when lager_keys_pdata
is duplicated.

This avoids accessing freed memory if gpio-key events occur
after unused kernel memory is freed late in the kernel's boot.

This but was added when support for gpio-keys was added to lager
in c3842e4f
("ARM: shmobile: lager: support GPIO switches") which was included
in v3.11-rc1.
Tested-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

The following message is printed on the BOCK-W kernel bootup:

sh-pfc pfc-r8a7778: invalid group "sdhi0" for function "sdhi0"

In addition, SD card cannot be detected.  The reason is apparently that commit
ca7bb309 (ARM: shmobile: bockw: add SDHI0 support) matched
the previous version of commit 564617d2 (sh-pfc: r8a7778:
add SDHI support).

Add the missing pin groups according to the BOCK-W board schematics.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

sh_desc->hw.tcr is controlling real data size,
and, register TCR is controlling data transfer count
which was xmit_shifted value of hw.tcr.
Current sh_dmae_get_partial() is calculating in different unit.
This patch fixes it.

This bug has been present since c014906a
("dmaengine: shdma: extend .device_terminate_all() to record partial
transfer"), which was added in 2.6.34-rc1.

Cc: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Register target address to be used for cpgmac is the second device
address space. By default, hwmod picks first address space (0th index)
for register target.

With removal of address space from hwmod and using DT instead, cpgmac
is getting wrong address space for register target.

Fix it by indicating the address space to be used for register target.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

Address space is being removed from hwmod database and DT information
in <reg> property is being used. Currently the 0th index of device
address space is used to map for register target address. This is not
always true, eg. cpgmac has it's sysconfig in second address space.

Handle it by specifying index of device address space to be used for
register target. As default value of this field would be zero with
static initialization, existing behaviour of using first address space
for register target while using DT would be kept as such.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
[paul@pwsan.com: use u8 rather than int to save memory]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

Some hwmods which are marked with HWMOD_INIT_NO_IDLE are left in enabled
state post setup(). When a omap_device gets created for such hwmods
make sure the omap_device and pm_runtime states are also in sync for such
hwmods by doing a omap_device_enable() and pm_runtime_set_active() for the
device.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with
HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup.

Even if they have drivers missing, avoid idling them as part of
omap_device_late_idle()
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

With commit '82702ea1' "ARM: OMAP2+:
Fix serial init for device tree based booting" stubbing out
omap_serial_early_init() for Device tree based booting, there was a
crash observed on AM335x based devices when hwmod does a
_setup_reset() early at boot.

This was rootcaused to hwmod trying to reset console uart while
earlycon was using it.  The way to tell hwmod not to do this is to
specify the HWMOD_INIT_NO_RESET flag, which were infact set by the
omap_serial_early_init() function by parsing the cmdline to identify
the console device.

Parsing the cmdline to identify the uart used by earlycon itself seems
broken as there is nothing preventing earlycon to use a different one.

This patch, instead, attempts to populate the requiste flags for hwmod
based on the CONFIG_DEBUG_OMAPxUARTy FLAGS. This gets rid of the need
for cmdline parsing in the DT as well as non-DT cases to identify the
uart used by earlycon.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Reported-by: Mark Jackson <mpfj-list@newflow.co.uk>
Reported-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

commit e00c27ef
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

The following optional/unused regulators can be updated:

- SMPS9 supplies TWL6040 over VDDA_2v1_AUD. This regulator needs to be
enabled only when audio is active. Since it does not come active by
default, it does not require "always-on" or "boot-on".

- LDO2 and LDO8 do not go to any peripheral or connector on the board.
Further, these unused regulators should have been 2.8V for LDO2 and
3.0V for LDO8. Mark these LDOs as disabled in the dts until needed.
Reported-by: Marc Jüttner <m-juettner@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: J Keerthy <j-keerthy@ti.com>
Acked-by: Benoit Cousson <benoit.cousson@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

commit e00c27ef
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

The following fixes are hence mandatory to ensure right voltage is
supplied to key OMAP5 SoC voltage rails:

- LDO1 supplies VDDAPHY_CAM which is OMAP5's vdda_csiporta/b/c. This
can only be supplied at 1.5V or 1.8V and we currently supply 2.8V.

To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.

Remove 'always-on' and 'boot-on' settings here as it is
a 'on need' supply to SoC IP and is not enabled by PMIC by
default at boot.

- LDO3 supplies Low Latency Interface(LLI) hardware module which is a
special hardware to communicate with Modem. However since uEVM is
not setup by default for this communication, this should be disabled
by default.

Further, vdda_lli is supposed to be 1.5V and not 3V.

- LDO4 supplies VDDAPHY_DISP which is vdda_dsiporta/c/vdda_hdmi

This can only be supplied at 1.5V or 1.8V and we currently
supply 2.2V.

To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.

Remove 'always-on' and 'boot-on' settings here as it is a 'on need'
supply to SoC IP and is not enabled by PMIC by default at boot.

- LDO6 supplies the board specified VDDS_1V2_WKUP supply going to
ldo_emu_wkup/vdds_hsic. To stay within the SoC specification supply
1.2V instead of 1.5V.

- LDO7 supplies VDD_VPP which is vpp1. This is currently configured for
1.5V which as per data manual "A pulse width of 1000 ns and an amplitude
of 2V is required to program each eFuse bit. Otherwise, VPP1 must not
be supplied".

So, fix the voltage to 2V. and disable the supply since we have no plans
of programming efuse bits - it can only be done once - in factory.

Further it is not enabled by default by PMIC so, 'boot-on' must be
removed, and the 'always-on' needs to be removed to achieve pulsing
if efuse needs to be programmed.

- LDO9 supplies the board specified vdds_sdcard supply going within SoC
specification of 1.8V or 3.0V. Further the supply is controlled by
switch enabled by REGEN3. So, introduce REGEN3 and map sdcard slot to
be powered by LDO9. Remove 'always-on' allowing the LDO to be disabled
on need basis.
Reported-by: Marc Jüttner <m-juettner@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: J Keerthy <j-keerthy@ti.com>
Acked-by: Benoit Cousson <benoit.cousson@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

commit e00c27ef
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, currently we use the Palmas regulator names which is used for
different purposes on uEVM. Document the same based on 750-2628-XXX
boards - which is meant to be supported by this dts.
Reported-by: Marc Jüttner <m-juettner@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: J Keerthy <j-keerthy@ti.com>
Acked-by: Benoit Cousson <benoit.cousson@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Since commit 7ed76e08 (ARM: EXYNOS: Fix low level debug support)
map_io() is not needed for exynos5440 so need to fix to lookup
cpu which using map_io(). Without this, kernel boot log complains
'CPU EXYNOS5440 support not enabled' on exynos5440 and panic().
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

Merge tag 'pinctrl-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

Pull pin control fixes from Linus Walleij:
 - Driver fixes for AM33xx, SIRF and PFC pin controllers
 - Fix a compile warning from the pinctrl single-register driver
 - Fix a little nasty memory leak

* tag 'pinctrl-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
  pinctrl: fix a memleak when freeing maps
  pinctrl: pinctrl-single: fix compile warning when no CONFIG_PM
  pinctrl: sh-pfc: fix SDHI0 VccQ regulator on sh73a0 with DT
  arm/dts: sirf: fix the pingroup name mismatch between drivers and dts
  pinctrl: sirf: add usp0_uart_nostreamctrl pin group for usp-uart without flowctrl
  pinctrl: sirf: fix the pin number and mux bit for usp0
  pinctrl: am33xx dt binding: correct include path

Merge tag 'trace-fixes-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull tracing fixes from Steven Rostedt:
 "Oleg is working on fixing a very tight race between opening a event
  file and deleting that event at the same time (both must be done as
  root).

  I also found a bug while testing Oleg's patches which has to do with a
  race with kprobes using the function tracer.

  There's also a deadlock fix that was introduced with the previous
  fixes"

* tag 'trace-fixes-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Remove locking trace_types_lock from tracing_reset_all_online_cpus()
  ftrace: Add check for NULL regs if ops has SAVE_REGS set
  tracing: Kill trace_cpu struct/members
  tracing: Change tracing_fops/snapshot_fops to rely on tracing_get_cpu()
  tracing: Change tracing_entries_fops to rely on tracing_get_cpu()
  tracing: Change tracing_stats_fops to rely on tracing_get_cpu()
  tracing: Change tracing_buffers_fops to rely on tracing_get_cpu()
  tracing: Change tracing_pipe_fops() to rely on tracing_get_cpu()
  tracing: Introduce trace_create_cpu_file() and tracing_get_cpu()

Pull SCSI fixes from James Bottomley:
 "This is five bug fixes, two of which fix long standing problems
  causing crashes (sd and mvsas).  The remaining three are hung (isci
  race) or lost (qla2xxx, isci) devices"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  [SCSI] isci: fix breakage caused by >16byte CDB patch
  [SCSI] mvsas: Fix kernel panic on tile due to unaligned data access
  [SCSI] sd: fix crash when UA received on DIF enabled device
  [SCSI] qla2xxx: Properly set the tagging for commands.
  [SCSI] isci: Fix a race condition in the SSP task management path

Msm gpiomux can be used only for 7x30 and 8x50.
Prevent compilation and fix build issues on 7X00, 8X60 and 8960.
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>

Pull drm fixes from Dave Airlie:
 "This is just a regular fixes pull apart from the qxl one, it has
  radeon and intel bits in it,

  The intel fixes are for a regression with the RC6 fix and a 3.10 hdmi
  regression, whereas radeon is more DPM fixes, a few lockup fixes and
  some rn50/r100 DAC fixes"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon/dpm: fix r600_enable_sclk_control()
  drm/radeon/dpm: implement force performance levels for rv6xx
  drm/radeon/dpm: fix displaygap programming on rv6xx
  drm/radeon/dpm: fix a typo in the rv6xx mclk setup
  drm/i915: initialize gt_lock early with other spin locks
  drm/i915: fix hdmi portclock limits
  drm/radeon: fix combios tables on older cards
  drm/radeon: improve dac adjust heuristics for legacy pdac
  drm/radeon: Another card with wrong primary dac adj
  drm/radeon: fix endian issues with DP handling (v3)
  drm/radeon/vm: only align the pt base to 32k
  drm/radeon: wait for 3D idle before using CP DMA

Pull qxl drm fixes from Dave Airlie:
 "Okay as I warned, the qxl driver was running a bit free and loose with
  its ttm object reservations and the new lockdep enabled reservation
  tracking shone a bright light into it, it also with the new
  reservations mutexes hits a possible deadlock during boot.

  The first patch is a real fix to render the console correctly as the
  driver used to just drop irq renderering as too hard, this also fixes
  a sleeping while atomic warning.

  The other two patches are the big ugly ones that redo how the driver
  allocates objects and reserves them and makes things all work
  properly, I've tested this in a VM, and compared to the current code
  which hits a lockdep warning and the sleep while atomic warning before
  failing.

  So sorry this is coming in late, I should have tested qxl before
  merging the mutex code, but I'd rather just fix qxl with this than
  revert the reservations code at this point"

* 'qxl-fixes' of git://people.freedesktop.org/~airlied/linux:
  qxl: convert qxl driver to proper use for reservations
  qxl: allow creation of pre-pinned objects and use for releases.
  drm/qxl: add delayed fb operations

Pull ACPI and power management fixes from Rafael Wysocki:
 "These are just two fixes, a revert of the would-be backlight fix that
  didn't work and an intel_pstate fix for two problems related to
  maximum P-state selection.

  Specifics:

   - Revert of the ACPI video commit that I hoped would help fix
     backlight problems related to Windows 8 compatibility on some
     systems.  Unfortunately, it turned out to cause problems to happen
     too.

   - Fix for two problems in intel_pstate, a possible failure to respond
     to a load change on a quiet system and a possible failure to select
     the highest available P-state on some systems.  From Dirk
     Brandewie"

* tag 'pm+acpi-3.11-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8"
  cpufreq / intel_pstate: Change to scale off of max P-state

Pull arm64 fixes from Catalin Marinas:
 - Stack size increased to 16K (similar to other 64-bit architectures)
 - Additional cache flushing for secondary CPUs boot mode

* tag 'arm64-stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64:
  arm64: Change kernel stack size to 16K
  arm64: Fix definition of arm_pm_restart to match the declaration
  arm64: virt: ensure visibility of __boot_cpu_mode