Commit graph

40276 commits

Author SHA1 Message Date
Ingo Molnar
65c2ce7004 Linux 3.15-rc6
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJTfR2zAAoJEHm+PkMAQRiG3noH/2s+KUge3qO2M+AmxttUo74B
 +npAMdbqYR3MdEiwxYZfsHcMu4Ye/IKLcrh4pydB5hI2mdjtGkH1bnmia0f1ve/c
 Z/a0256+W8gWp7mcUBqSNztqLPAWa7wKOqNdLjj5idr1BSj6u8im+fQ9FBh2woki
 1fyYAuq/60lq4CMOKJvkA95V1Ome/jO+8tS4PguOgsCETQxCVFGurZcBbG3Mx5Y3
 v+ioCqeRc6GvxPFR6YngnTZCrsLxSRT3tnO2Qy5zX7dxjIQkCEbvIckpBQv01Y3R
 wNUaX+2Jae207igxrEv8CjmCFnmZFuUI15aWWCy6fOS/j8bjuk6ThYJO8N4ZBM0=
 =2ShG
 -----END PGP SIGNATURE-----

Merge tag 'v3.15-rc6' into sched/core, to pick up the latest fixes

Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-05-22 10:28:56 +02:00
Olof Johansson
91f0f06ccb Merge branch 'depends/clockevents-cleanups' into next/boards
Bringing in as an external dependency that the renesas/clock-cleanup2 branch
relies on.

* depends/clockevents-cleanups: (52 commits)
  clocksource: sh_mtu2: Sort headers alphabetically
  clocksource: sh_mtu2: Remove FSF mail address from GPL notice
  clocksource: sh_mtu2: Rename clock to "fck" in the non-legacy case
  clocksource: sh_mtu2: Add support for multiple channels per device
  clocksource: sh_mtu2: Hardcode MTU2 clock event rating to 200
  clocksource: sh_mtu2: Set cpumask to cpu_possible_mask
  clocksource: sh_mtu2: Replace hardcoded register values with macros
  clocksource: sh_mtu2: Allocate channels dynamically
  clocksource: sh_mtu2: Replace kmalloc + memset with kzalloc
  clocksource: sh_mtu2: Add index to struct sh_mtu2_channel
  clocksource: sh_mtu2: Add memory base to sh_mtu2_channel structure
  clocksource: sh_mtu2: Constify name argument to sh_mtu2_register()
  clocksource: sh_mtu2: Split channel setup to separate function
  clocksource: sh_mtu2: Rename struct sh_mtu2_priv to sh_mtu2_device
  clocksource: sh_mtu2: Split channel fields from sh_mtu2_priv
  clocksource: sh_mtu2: Turn sh_mtu2_priv fields into local variables
  clocksource: sh_mtu2: Use request_irq() instead of setup_irq()
  clocksource: sh_tmu: Sort headers alphabetically
  clocksource: sh_tmu: Remove FSF mail address from GPL notice
  clocksource: sh_tmu: Rename clock to "fck" in the non-legacy case
  ...

Signed-off-by: Olof Johansson <olof@lixom.net>
2014-05-21 14:05:27 -07:00
Xuelin Shi
c1f43dd9c2 dmaengine: fix dmaengine_unmap failure
The count which is used to get_unmap_data maybe not the same as the
count computed in dmaengine_unmap which causes to free data in a
wrong pool.

This patch fixes this issue by keeping the map count with unmap_data
structure and use this count to get the pool.

Cc: <stable@vger.kernel.org>
Signed-off-by: Xuelin Shi <xuelin.shi@freescale.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2014-05-21 14:02:37 -07:00
Jens Axboe
e814e71ba4 blk-mq: allow the hctx cpu hotplug notifier to return errors
Prepare this for the next patch which adds more smarts in the
plugging logic, so that we can save some memory.

Signed-off-by: Jens Axboe <axboe@fb.com>
2014-05-21 13:59:08 -06:00
Linus Torvalds
439c610992 Driver core fixes for 3.15-rc6
Here are two driver core (well, sysfs) fixes for 3.15-rc6 that resolve
 some reported issues and a regression from 3.13.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iEUEABECAAYFAlN8LzgACgkQMUfUDdst+ynJnQCeKQt7KdEBlHAKI5/iP2IQVNNx
 KG8AmMepPCjpp9/MbrFQnx3miGgNEug=
 =813a
 -----END PGP SIGNATURE-----

Merge tag 'driver-core-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull driver core fixes from Greg KH:
 "Here are two driver core (well, sysfs) fixes for 3.15-rc6 that resolve
  some reported issues and a regression from 3.13"

* tag 'driver-core-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  sysfs: make sure read buffer is zeroed
  kernfs, sysfs, cgroup: restrict extra perm check on open to sysfs
2014-05-21 18:59:25 +09:00
Matt Porter
9e1e726311 mfd: bcm590xx: Add support for secondary I2C slave address
BCM590xx utilizes a secondary I2C slave address to access additional
register space. Add support for the secondary address space by
instantiating a dummy I2C device with the appropriate secondary
I2C slave address. Also expose a secondary regmap register space so
that MFD drivers can access this secondary i2c slave address space.

Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-05-21 10:40:08 +01:00
Linus Torvalds
06eb4cc2e7 Merge branch 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull more cgroup fixes from Tejun Heo:
 "Three more patches to fix cgroup_freezer breakage due to the recent
  cgroup internal locking changes - an operation cgroup_freezer was
  using now requires sleepable context and cgroup_freezer was invoking
  that while holding a spin lock.  cgroup_freezer was using an overly
  elaborate hierarchical locking scheme.

  While it's possible to convert the hierarchical spinlocks directly to
  mutexes, this patch simplifies the overall locking so that it uses a
  global mutex.  This has the added benefit of avoiding iterating
  potentially huge number of tasks under a spinlock.  While the patch is
  on the larger side in the devel cycle, the changes made are mostly
  straight-forward and the locking logic is a lot simpler afterwards"

* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cgroup: fix rcu_read_lock() leak in update_if_frozen()
  cgroup_freezer: replace freezer->lock with freezer_mutex
  cgroup: introduce task_css_is_root()
2014-05-21 18:36:40 +09:00
Alexandre Courbot
f01d907582 gpio: make of_get_named_gpiod_flags() private
of_get_named_gpiod_flags() is visible and directly usable by GPIO
consumers, but it really should not as the gpiod interface relies
on the simpler gpiod_get() to provide properly-configured GPIOs.

of_get_named_gpiod_flags() is just used internally by gpiolib to
implement gpiod_get(), and by the old of_get_named_gpio_flags()
function, therefore it makes sense to make it gpiolib-private.

As a side-effect, the unused (and unneeded) of_get_gpiod_flags()
inline function is also removed, and of_get_named_gpio_flags() is moved
from a static inline function to a regular one in gpiolib-of.c

This results in all references to gpiod_* functions in of_gpio.h being
gone, which is the way it should be since this file is part of the old
integer GPIO interface.

Changes since v1:
- Fixed compilation error when CONFIG_OF_GPIO is not defined
- Fixed warning due to of_gpio_flags enum not being declared
  in private gpiolib.h header

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-05-21 11:14:46 +02:00
Linus Torvalds
31a3fcab11 Drivercore bugfixes for v3.15
This branch contains bug fixes important to get into v3.15. There is a
 fix for modifying properties seen during early boot, a fix for an
 incorrect prototype when CONFIG_OF=n, and a couple of corrections to
 device tree memory nodes on  a few platforms.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJTdh+wAAoJEMWQL496c2LNfOsQAI/zg5nrUcTEPMg9MXANCPvL
 4cGQTbN0bbWLY55wXTglyw/1qlPWmGc7nE5EOpeuVU/HO/EOzDckMcXcm/kUX6mk
 7oZjrTVmAySBgBt1XdHOpN6C6IMfiFtsyLvUnpxF0D/Vm9FsD1NyfHlhPmExm4Gg
 DSPXf5YmgT9AZL4f1NtCOCcsm/zNpGNDGQLvwDU5CrUKYNAivv+C42ysScQY0DkG
 VOfSt9mDmRzWL1+cBq0qMEmXWO+vRpV/pg/OZYfgT8TFsJCNv4bsQp1DI+fJucMn
 E48FGuJ2S3YnFBiWc3dCnyEF3J/5zqmu1pH7kXbjEvGWJ0I4c7J1oVqTRAdYDpfy
 PIfAob4X8N9rCELO1P1GPrS7/xBYKjD51RKkT6saowvdhLD1e8XbMhAS1emoc2fq
 l16yCu+mk6WKi7fPOQDLLt9Rp41sx+9tl7XuS27BxoHQdFpLhY4yq1EYRXozuYDb
 oXo3e7tgOJSWLNnoJDU/1v1GE53cpiPC/++hGVg1hHKDCVxz19sUUAsaneDoz74s
 5rvSzyWzM7y5FG6L7pIVT//fRuceY5itmYY91MrOuUVhdN8/1a1altGuT60eol7g
 XYShsFrxs4gemgDZ4tfpva6/fCep3Nqz3brAV/7j8cE51SkdhlyMUftaJFSZvy/S
 LVM/lVHY57KxeODngtXW
 =kY49
 -----END PGP SIGNATURE-----

Merge tag 'dt-for-linus' of git://git.secretlab.ca/git/linux

Pull device tree fixes from Grant Likely:
 "Drivercore bugfixes for v3.15

  This branch contains bug fixes important to get into v3.15.  There is
  a fix for modifying properties seen during early boot, a fix for an
  incorrect prototype when CONFIG_OF=n, and a couple of corrections to
  device tree memory nodes on a few platforms"

* tag 'dt-for-linus' of git://git.secretlab.ca/git/linux:
  mips: dts: Fix missing device_type="memory" property in memory nodes
  arm: dts: Fix missing device_type="memory" for ste-ccu8540
  of: fix CONFIG_OF=n prototype of of_node_full_name()
  of: make of_update_property() usable earlier in the boot process
2014-05-21 17:54:55 +09:00
Arnd Bergmann
a8246fedac dmaengine: omap: hide filter_fn for built-in drivers
It is not possible to reference the omap_dma_filter_fn filter
function from a built-in driver if the dmaengine driver itself
is a loadable module, which is a valid configuration otherwise.

This provides only the dummy alternative if the function
is referenced by a built-in driver to allow a successful
build. The filter function is only required by ATAGS based
platforms, which will continue to be broken after this change
for the bogus configuration. When booting from DT, with the
dma channels correctly listed there, it will work fine.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: dmaengine@vger.kernel.org
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-05-21 11:40:49 +05:30
Bjorn Helgaas
88a984ba07 DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t
dma_declare_coherent_memory() takes two addresses for a region of memory: a
"bus_addr" and a "device_addr".  I think the intent is that "bus_addr" is
the physical address a *CPU* would use to access the region, and
"device_addr" is the bus address the *device* would use to address the
region.

Rename "bus_addr" to "phys_addr" and change its type to phys_addr_t.
Most callers already supply a phys_addr_t for this argument.  The others
supply a 32-bit integer (a constant, unsigned int, or __u32) and need no
change.

Use "unsigned long", not phys_addr_t, to hold PFNs.

No functional change (this could theoretically fix a truncation in a config
with 32-bit dma_addr_t and 64-bit phys_addr_t, but I don't think there are
any such cases involving this code).

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: James Bottomley <jbottomley@Parallels.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
2014-05-20 16:55:23 -06:00
Bjorn Helgaas
77f2ea2f8d DMA-API: Clarify physical/bus address distinction
The DMA-API documentation sometimes refers to "physical addresses" when it
really means "bus addresses."  Sometimes these are identical, but they may
be different if the bridge leading to the bus performs address translation.
Update the documentation to use "bus address" when appropriate.

Also, consistently capitalize "DMA", use parens with function names, use
dev_printk() in examples, and reword a few sections for clarity.

No functional change; documentation changes only.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: James Bottomley <jbottomley@Parallels.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
2014-05-20 16:54:21 -06:00
Rob Herring
e06e8b2708 of/fdt: add FDT address translation support
Copy u-boot's FDT address translation code from common/fdt_support. This
code was originally based on the kernel's unflattened DT address parsing
code.

This commit can be reverted once relicensing of this code to GPLv2/BSD
is done and it is added to libfdt.

Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
2014-05-20 15:19:25 -05:00
Rob Herring
b0b6abd34c serial: earlycon: add DT support
This adds the infrastructure to generic earlycon for earlycon setup
using DT. The actual setup is not enabled until a following commit to
add the FDT parsing.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Grant Likely <grant.likely@linaro.org>
2014-05-20 15:19:25 -05:00
Rob Herring
54196ccbe0 of: consolidate linker section OF match table declarations
We now have several OF match tables using linker sections that are
nearly the same definition. The only variation is the callback function
prototype. Create a common define for creating linker section OF match
table entries which each table declaration can use.

Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
2014-05-20 14:25:24 -05:00
Rob Herring
9dd3107576 of: align RESERVEDMEM_OF_DECLARE function callbacks to other callbacks
All the parameters for RESERVEDMEM_OF_DECLARE function callbacks are
members of struct reserved_mem, so just pass the struct ptr to callback
functions so the function callback is more in line with other OF match
table callbacks.

Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
2014-05-20 14:25:21 -05:00
Rob Herring
6e87b7030e Merge branch 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty into for-next
Conflicts:
	arch/arm64/kernel/early_printk.c
2014-05-20 14:22:54 -05:00
Jens Axboe
e3a2b3f931 blk-mq: allow changing of queue depth through sysfs
For request_fn based devices, the block layer exports a 'nr_requests'
file through sysfs to allow adjusting of queue depth on the fly.
Currently this returns -EINVAL for blk-mq, since it's not wired up.
Wire this up for blk-mq, so that it now also always dynamic
adjustments of the allowed queue depth for any given block device
managed by blk-mq.

Signed-off-by: Jens Axboe <axboe@fb.com>
2014-05-20 11:49:02 -06:00
Vlad Yasevich
e1618d461c vlan: Fix build error wth vlan_get_encap_level()
The new function vlan_get_encap_level() uses vlan_dev_priv()
which is only conditionally avaialble when VLAN support is
enabled.  Make vlan_get_encap_level() conditionally available
as well.

Fixes: 44a4085538 ("bonding: Fix stacked device detection in arp monitoring")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
CC: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-20 11:24:26 -04:00
Heikki Krogerus
e2d0e90fae clk: new basic clk type for fractional divider
Fractional divider clocks are fairly common. This adds basic
type for them.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-20 13:34:02 +02:00
Heikki Krogerus
4cf563c5d9 ACPI / PM: Export rest of the subsys PM callbacks
No reason for excluding the remaining ones.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
[rjw: Rebased and exported the new acpi_subsys_complete() too.]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-20 13:23:07 +02:00
Rafael J. Wysocki
55cc33ceb7 Merge branch 'pm-sleep' into acpi-pm 2014-05-20 13:22:15 +02:00
Philipp Hachtmann
70210ed950 mm/memblock: add physical memory list
Add the physmem list to the memblock structure. This list only exists
if HAVE_MEMBLOCK_PHYS_MAP is selected and contains the unmodified
list of physically available memory. It differs from the memblock
memory list as it always contains all memory ranges even if the
memory has been restricted, e.g. by use of the mem= kernel parameter.

Signed-off-by: Philipp Hachtmann <phacht@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-05-20 08:58:39 +02:00
Philipp Hachtmann
f1af9d3af3 mm/memblock: Do some refactoring, enhance API
Refactor the memblock code and extend the memblock API to make it
more flexible. With the extended API it is simple to define and
work with additional memory lists.

The static functions memblock_add_region and __memblock_remove are
renamed to memblock_add_range and meblock_remove_range and added to
the memblock API.

The __next_free_mem_range and __next_free_mem_range_rev functions
are replaced with calls to the more generic list walkers
__next_mem_range and __next_mem_range_rev.

To walk an arbitrary memory list two new macros for_each_mem_range
and for_each_mem_range_rev are added. These new macros are used
to define for_each_free_mem_range and for_each_free_mem_range_reverse.

Signed-off-by: Philipp Hachtmann <phacht@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-05-20 08:58:39 +02:00
Linus Torvalds
3f017a4ca2 Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Thomas Gleixner:
 "Two small updates from the irq departement:

   - Provide missing inline stub for a SMP only function

   - Add sub-maintainer for the drivers/irqchip/ part of the irq
     subsystem.  YAY!"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  MAINTAINERS: Add co-maintainer for drivers/irqchip
  genirq: Provide irq_force_affinity fallback for non-SMP
2014-05-20 14:18:04 +09:00
Olof Johansson
5df22a6148 mvebu SoC changes for v3.16
- Armada 375/38x coherency support
  - Armada 375/38x SMP support
  - mvebu PMSU and CPU reset support
  - Armada 370/XP cpuidle support
  - kirkwood remove platform init of audio device
  - small fixes and cleanup for new SoC (375/38x)
 
 Note:
  - due to complex deps, cpuidle changes Acked by appropriate maintainer for
    going though arm-soc tree.
 
 Depends:
  - tags/irqchip-mvebu-3.16 in the mvebu/irqchip branch (tglx already pulled) for:
 
     d7df84b3ce irqchip: irq-armada-370-xp: Use cpu notifier to initialize secondary CPUs
     ef37d337e1 irqchip: irq-armada-370-xp: Do the set_smp_cross_call() in the driver
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQIcBAABAgAGBQJTbOGvAAoJEP45WPkGe8Zn53UP/jn5IEn7T/wMKt+m+K4HTPH4
 tLbimH60wKtBDK+R978GqaKibgzqjBy/CeGcV9ip7NCOAVZTXBi3bZW/bHHw9azu
 pCUAUBdX6uAt6Ua+SxtyrI3nqI5g8QrQhg7Loa08r34buL07qRIbR7TwR13cr5pV
 w5svXJeb4bdnvPmMlpzMYFAfvYhUxf5S0aALh1hLzeMsfEq4pfBH581UZQliPAus
 8MVE/eeiam+6wI2mpNyxedaevLJ875SDZo8n7r4yytGvoexIfegvd9GIwKRLe06z
 Owqn05PkU0Zo+X4FSQBWZ81DcRNKP+D3gWJkN7pTVRWNjNVGJtZTkQX4Cyo6JZiX
 0Qz9APp8ZzrnzG4uhYdq0vwlgiMgd5KoxzMF8Wbid3JW+NEMST6QnNqDmF1R86s6
 K4f/DDJtQU9fonicNM8yPlGYvBCBO7Jbb5hoc5QaxTTHSv0hFJVwWtoejwtnhmJA
 wcvTu+oGKmF4nM63zV2P2YbWF0FahGS4ssm2VWk9OsZuXzG4AAV3QGP85qw+3QuV
 ry/GjqT81ExC04KnXsanFz7nw2a74DU1UVZgpkyKEJbS0zcNvr+6u9AIA1zmoF5P
 Nmjwjn4nsC9Y2YuabSGMkM11gCUjFjIG+fA6E5/m5rBwH8UtgPHyLKIt/2nXm6DG
 LVNzCvQpYeh1NTA6Mro6
 =wNp0
 -----END PGP SIGNATURE-----

Merge tag 'mvebu-soc-3.16' of git://git.infradead.org/linux-mvebu into next/soc

Merge "ARM: mvebu: SoC changes for v3.16" from Jason Cooper:

mvebu SoC changes for v3.16

 - Armada 375/38x coherency support
 - Armada 375/38x SMP support
 - mvebu PMSU and CPU reset support
 - Armada 370/XP cpuidle support
 - kirkwood remove platform init of audio device
 - small fixes and cleanup for new SoC (375/38x)

Note:
 - due to complex deps, cpuidle changes Acked by appropriate maintainer for
   going though arm-soc tree.

* tag 'mvebu-soc-3.16' of git://git.infradead.org/linux-mvebu: (46 commits)
  ARM: mvebu: Fix pmsu compilation when ARMv6 is selected
  ARM: mvebu: conditionalize Armada 375 coherency workaround
  ARM: mvebu: conditionalize Armada 375 SMP workaround
  ARM: mvebu: add Armada 375 A0 revision definition
  ARM: mvebu: initialize mvebu-soc-id earlier
  ARM: mvebu: fix thermal quirk SoC revision check
  ARM: Kirkwood: t5325: Remove platform device to instantiate audio
  ARM: Kirkwood: Remove platform driver for codec
  ARM: mvebu: Add thermal quirk for the Armada 375 DB board
  ARM: mvebu: Select HAVE_ARM_TWD only if SMP is enabled
  ARM: mvebu: fix the name of the parameter used in mvebu_get_soc_id
  ARM: mvebu: remove unnecessary ifdef around l2x0_of_init
  ARM: mvebu: register the cpuidle driver for the Armada XP SoCs
  cpuidle: mvebu: Add initial CPU idle support for Armada 370/XP SoC
  ARM: mvebu: Register notifier callback for the cpuidle transition
  ARM: mvebu: refine which files are build in mach-mvebu
  ARM: mvebu: Add the PMSU related part of the cpu idle functions
  ARM: mvebu: Allow to power down L2 cache controller in idle mode
  ARM: mvebu: Low level function to disable HW coherency support
  ARM: mvebu: Split low level functions to manipulate HW coherency
  ...

Signed-off-by: Olof Johansson <olof@lixom.net>
2014-05-19 21:59:55 -07:00
Ulf Hansson
5080a08d0f mmc: mmci: Enforce max frequency configuration through DT
Remove the option to provide a maximum frequency as platform data,
enforce it through DT.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-05-20 06:06:56 +02:00
Alan Cox
8d9e9857c5 goldfish: fix >> 32 warning
We should be checking for a 64bit platform not 64bit DMA address types in
the case of Goldfish. The Goldfish virtual platform is either 32/32 or
64/64.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 10:30:40 +09:00
Greg Kroah-Hartman
6aba2ae764 for 3.16 merge window
Bunch of fixes and a new driver for Exynos5 USB 3.0 PHY.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJTdggGAAoJEA5ceFyATYLZZXEQAI3aOHMET9KP6f34vOWRfZvv
 tbcU+hHKkzPAqZaRjX1DErMHfMW09Lcd0K2xSq6UK9xoD9QrYdxl33KaOTHJ3cGC
 ioSKBXFbx1BNXDLezl7gWPRsdYLWAJLzzR+3Xh/XGcLMBI0Scxka+iOm5i/2kH6G
 VwMJ/RAhbVVlTxiOzhdH8FUfdIcsv4n07BfYtHIa2UOw+kiLl1bjNtn2MJisbkO/
 N5doz7gy5CBXCGo8g6P88H2NrHY2/VPYUiog+uGgq6punncvh9Jrt+veZFm+9Biv
 HPE1/l/q6XvJpy82qB1wyk+ERZTSlZP0f/GZhCtysa5NX16efnbdVA0kAcMF3Cgc
 V6hDx1PuY1GjQO9MobIo6RE23RQfy+ktKQ6maxkJDrqM2v+oj6dr3q/R1gpnfjz3
 Cs3ndtPYEEA+1TJRgvLr9M+DEB4SPeZYCRil4JMsEr0upMlXo81t12Tvk8/QIpO0
 hmZPgfPnKkuF8AnYrQkM3qAawzbaVsBAtnJGfExmPyFMOrtjS0VgG0TPDmj7G6Hx
 PGovqPokEFj2F+HAhQcQynx3RjUFcyboDpY4uHNYqL1h3ZuqOpoGwbjI1cjUEHm4
 ExKF4MpePRwHCSxzcVrpoqKeHGkcAhKPZc1BA4Cul1jv0aNS6HEs8Nylf7eUsX0O
 5b34Zk0GXHNfP6xnQiHi
 =gwmY
 -----END PGP SIGNATURE-----

Merge tag 'for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-next

Kishon writes:

for 3.16 merge window

Bunch of fixes and a new driver for Exynos5 USB 3.0 PHY.
2014-05-20 09:56:05 +09:00
Greg Kroah-Hartman
6a57bad6e7 Update extcon for v3.16
This patchset add resource-managed functions to automatically control the memory
 and unregistration operation of extcon. Also, This series support new MAX77836
 extcon device driver on existing MAX14577 device because existed a little
 difference between MAX77836 and MAX14577. Finally, Fix minor issue of extcon
 driver.
 
 Detailed description for patchset:
 1. Add resource-managed functions
 - Add resource-managed functions to automatically free the memory of extcon
 structure and to control unregistration behavior as following. This new devm_*
 functions applied all of extcon drivers in drivers/extcon/.
 : devm_extcon_dev_register/unregister()
 : devm_extcon_dev_allocate/free()
 : extcon_dev_allocate/free() for devm_extcon_dev_allocate/free()
 
 2. Add new MAX77836 extcon device
 - Support MAX77836 device on existing MAX14577 device driver using
 different compatible string. This patchset has dependency on MFD/
 Regulator/Extcon. So, Lee Jones(MFD Maintainer) created Immutable
 branch between MFD and Extcon due for v3.16 merge-window and then
 I merged this patchset from MFD git repo[1] to Extcon git repo.
 : [1] git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
   (branch: ib-mfd-extcon-3.16)
 
 3. Fix minor issue of extcon driver
 - extcon-palmas driver
 : Fix issue of extcon device name for probe
 - extcon-max14577
 : Fix probe failure about handling wrong return value.
 : Properly Handle return value of regmap_irq_get_virq function.
 - extcon-max8997/max77693 driver
 : Fix NULL pointer exception on missing pdata
 
 4. Code clean for extcon driver
 - extcon-max8997/max77693
 : Use power efficient workqueue for delayed cable detection
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJTepzmAAoJEJzN3yze689TSHMP/2l/pzI1IVqEQIzDnf6ga9AT
 rHo7kdLya+TxLBggasj21N9jprI3145bkWBL00EcnZkqrav7ctnU71347u7wkMzg
 pREYwK0OZAeF33rjbCrCPVrUL55XuTzipf4phtcKDSxmbFh/OdRZe4/vOEo0mBxE
 kTKb0zaePz0jeCur/ajxnZ1E/2DkKTsvUyiYSUYQ1FAjY4RvKkW/3qDYXqMetoYZ
 7sJdH5cpbsdGdQj74axuFWqvnINH1i9LY2gGw30tLKa7D15r72wBfA9HuRB/P5XB
 prvVb19wYLgkfxevZenvDjmyqeMUkFnk2a25Ntd3xndeaBJSCIM9y9tXxtz/fWyq
 ZPgsE0ma/E2PkKt4c4/mg1BzAGyL8lXU0SEivp03iLV3ByK2rmug7NdwG0Tw0/iE
 rcx3cdr7QvK4wSgaOt2Hcv+QLqXDZ7onrt3fhx+eHyD5X1ThRCCKbdr+H08eWnqw
 zGJQ6Ru4nrzZ1NS8bJuAjpKLfWwEWhN1QwvJ/Aw13yP/CIRtWgik+m1cUVTZriJL
 rlcdKJHbs8lGw07oROurmcEcKCBdr8HDZ4Ajht4qv7LQnYZK4q1N7xbbaI1tqTjb
 CawoA2ZfZMjNPkt97wwYselL2eRHVEHg5AwhzhVVPzbf/GxGU3GR2NLUeJBzbTaQ
 TtZbRo8l8GRGT5dGp86J
 =7wRd
 -----END PGP SIGNATURE-----

Merge tag 'extcon-next-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next

Chanwoo writes:

Update extcon for v3.16

This patchset add resource-managed functions to automatically control the memory
and unregistration operation of extcon. Also, This series support new MAX77836
extcon device driver on existing MAX14577 device because existed a little
difference between MAX77836 and MAX14577. Finally, Fix minor issue of extcon
driver.

Detailed description for patchset:
1. Add resource-managed functions
- Add resource-managed functions to automatically free the memory of extcon
structure and to control unregistration behavior as following. This new devm_*
functions applied all of extcon drivers in drivers/extcon/.
: devm_extcon_dev_register/unregister()
: devm_extcon_dev_allocate/free()
: extcon_dev_allocate/free() for devm_extcon_dev_allocate/free()

2. Add new MAX77836 extcon device
- Support MAX77836 device on existing MAX14577 device driver using
different compatible string. This patchset has dependency on MFD/
Regulator/Extcon. So, Lee Jones(MFD Maintainer) created Immutable
branch between MFD and Extcon due for v3.16 merge-window and then
I merged this patchset from MFD git repo[1] to Extcon git repo.
: [1] git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
  (branch: ib-mfd-extcon-3.16)

3. Fix minor issue of extcon driver
- extcon-palmas driver
: Fix issue of extcon device name for probe
- extcon-max14577
: Fix probe failure about handling wrong return value.
: Properly Handle return value of regmap_irq_get_virq function.
- extcon-max8997/max77693 driver
: Fix NULL pointer exception on missing pdata

4. Code clean for extcon driver
- extcon-max8997/max77693
: Use power efficient workqueue for delayed cable detection
2014-05-20 09:44:38 +09:00
Jens Axboe
39a9f97e5e Merge branch 'for-3.16/blk-mq-tagging' into for-3.16/core
Signed-off-by: Jens Axboe <axboe@fb.com>

Conflicts:
	block/blk-mq-tag.c
2014-05-19 11:52:35 -06:00
Rik van Riel
61f38db3e3 rcu: Provide API to suppress stall warnings while sysrc runs
Some sysrq handlers can run for a long time, because they dump a lot
of data onto a serial console. Having RCU stall warnings pop up in
the middle of them only makes the problem worse.

This commit provides rcu_sysrq_start() and rcu_sysrq_end() APIs to
temporarily suppress RCU CPU stall warnings while a sysrq request is
handled.

Signed-off-by: Rik van Riel <riel@redhat.com>
[ paulmck: Fix TINY_RCU build error. ]
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2014-05-19 10:52:04 -07:00
Jens Axboe
1429d7c946 blk-mq: switch ctx pending map to the sparser blk_align_bitmap
Each hardware queue has a bitmap of software queues with pending
requests. When new IO is queued on a software queue, the bit is
set, and when IO is pruned on a hardware queue run, the bit is
cleared. This causes a lot of traffic. Switch this from the regular
BITS_PER_LONG bitmap to a sparser layout, similarly to what was
done for blk-mq tagging.

20% performance increase was observed for single threaded IO, and
about 15% performanc increase on multiple threads driving the
same device.

Signed-off-by: Jens Axboe <axboe@fb.com>
2014-05-19 11:02:47 -06:00
Peter Zijlstra
b69cf53640 perf: Fix a race between ring_buffer_detach() and ring_buffer_attach()
Alexander noticed that we use RCU iteration on rb->event_list but do
not use list_{add,del}_rcu() to add,remove entries to that list, nor
do we observe proper grace periods when re-using the entries.

Merge ring_buffer_detach() into ring_buffer_attach() such that
attaching to the NULL buffer is detaching.

Furthermore, ensure that between any 'detach' and 'attach' of the same
event we observe the required grace period, but only when strictly
required. In effect this means that only ioctl(.request =
PERF_EVENT_IOC_SET_OUTPUT) will wait for a grace period, while the
normal initial attach and final detach will not be delayed.

This patch should, I think, do the right thing under all
circumstances, the 'normal' cases all should never see the extra grace
period, but the two cases:

 1) PERF_EVENT_IOC_SET_OUTPUT on an event which already has a
    ring_buffer set, will now observe the required grace period between
    removing itself from the old and attaching itself to the new buffer.

    This case is 'simple' in that both buffers are present in
    perf_event_set_output() one could think an unconditional
    synchronize_rcu() would be sufficient; however...

 2) an event that has a buffer attached, the buffer is destroyed
    (munmap) and then the event is attached to a new/different buffer
    using PERF_EVENT_IOC_SET_OUTPUT.

    This case is more complex because the buffer destruction does:
      ring_buffer_attach(.rb = NULL)
    followed by the ioctl() doing:
      ring_buffer_attach(.rb = foo);

    and we still need to observe the grace period between these two
    calls due to us reusing the event->rb_entry list_head.

In order to make 2 happen we use Paul's latest cond_synchronize_rcu()
call.

Cc: Paul Mackerras <paulus@samba.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Reported-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140507123526.GD13658@twins.programming.kicks-ass.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-05-19 21:44:56 +09:00
Vlad Yasevich
44a4085538 bonding: Fix stacked device detection in arp monitoring
Prior to commit fbd929f2dc
	bonding: support QinQ for bond arp interval

the arp monitoring code allowed for proper detection of devices
stacked on top of vlans.  Since the above commit, the
code can still detect a device stacked on top of single
vlan, but not a device stacked on top of Q-in-Q configuration.
The search will only set the inner vlan tag if the route
device is the vlan device.  However, this is not always the
case, as it is possible to extend the stacked configuration.

With this patch it is possible to provision devices on
top Q-in-Q vlan configuration that should be used as
a source of ARP monitoring information.

For example:
ip link add link bond0 vlan10 type vlan proto 802.1q id 10
ip link add link vlan10 vlan100 type vlan proto 802.1q id 100
ip link add link vlan100 type macvlan

Note:  This patch limites the number of stacked VLANs to 2,
just like before.  The original, however had another issue
in that if we had more then 2 levels of VLANs, we would end
up generating incorrectly tagged traffic.  This is no longer
possible.

Fixes: fbd929f2dc (bonding: support QinQ for bond arp interval)
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@redhat.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Ding Tianhong <dingtianhong@huawei.com>
CC: Patric McHardy <kaber@trash.net>
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16 22:29:05 -04:00
Vlad Yasevich
c674ac30c5 macvlan: Fix lockdep warnings with stacked macvlan devices
Macvlan devices try to avoid stacking, but that's not always
successfull or even desired.  As an example, the following
configuration is perefectly legal and valid:

eth0 <--- macvlan0 <---- vlan0.10 <--- macvlan1

However, this configuration produces the following lockdep
trace:
[  115.620418] ======================================================
[  115.620477] [ INFO: possible circular locking dependency detected ]
[  115.620516] 3.15.0-rc1+ #24 Not tainted
[  115.620540] -------------------------------------------------------
[  115.620577] ip/1704 is trying to acquire lock:
[  115.620604]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80
[  115.620686]
but task is already holding lock:
[  115.620723]  (&macvlan_netdev_addr_lock_key){+.....}, at: [<ffffffff815da5be>] dev_set_rx_mode+0x1e/0x40
[  115.620795]
which lock already depends on the new lock.

[  115.620853]
the existing dependency chain (in reverse order) is:
[  115.620894]
-> #1 (&macvlan_netdev_addr_lock_key){+.....}:
[  115.620935]        [<ffffffff810d57f2>] lock_acquire+0xa2/0x130
[  115.620974]        [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50
[  115.621019]        [<ffffffffa07296c3>] vlan_dev_set_rx_mode+0x53/0x110 [8021q]
[  115.621066]        [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0
[  115.621105]        [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40
[  115.621143]        [<ffffffff815da6be>] __dev_open+0xde/0x140
[  115.621174]        [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170
[  115.621174]        [<ffffffff815daaa9>] dev_change_flags+0x29/0x60
[  115.621174]        [<ffffffff815e7f11>] do_setlink+0x321/0x9a0
[  115.621174]        [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730
[  115.621174]        [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250
[  115.621174]        [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0
[  115.621174]        [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40
[  115.621174]        [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0
[  115.621174]        [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740
[  115.621174]        [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0
[  115.621174]        [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380
[  115.621174]        [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80
[  115.621174]        [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20
[  115.621174]        [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b
[  115.621174]
-> #0 (&vlan_netdev_addr_lock_key/1){+.....}:
[  115.621174]        [<ffffffff810d4d43>] __lock_acquire+0x1773/0x1a60
[  115.621174]        [<ffffffff810d57f2>] lock_acquire+0xa2/0x130
[  115.621174]        [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50
[  115.621174]        [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80
[  115.621174]        [<ffffffffa0696d2a>] macvlan_set_mac_lists+0xca/0x110 [macvlan]
[  115.621174]        [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0
[  115.621174]        [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40
[  115.621174]        [<ffffffff815da6be>] __dev_open+0xde/0x140
[  115.621174]        [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170
[  115.621174]        [<ffffffff815daaa9>] dev_change_flags+0x29/0x60
[  115.621174]        [<ffffffff815e7f11>] do_setlink+0x321/0x9a0
[  115.621174]        [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730
[  115.621174]        [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250
[  115.621174]        [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0
[  115.621174]        [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40
[  115.621174]        [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0
[  115.621174]        [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740
[  115.621174]        [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0
[  115.621174]        [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380
[  115.621174]        [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80
[  115.621174]        [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20
[  115.621174]        [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b
[  115.621174]
other info that might help us debug this:

[  115.621174]  Possible unsafe locking scenario:

[  115.621174]        CPU0                    CPU1
[  115.621174]        ----                    ----
[  115.621174]   lock(&macvlan_netdev_addr_lock_key);
[  115.621174]                                lock(&vlan_netdev_addr_lock_key/1);
[  115.621174]                                lock(&macvlan_netdev_addr_lock_key);
[  115.621174]   lock(&vlan_netdev_addr_lock_key/1);
[  115.621174]
 *** DEADLOCK ***

[  115.621174] 2 locks held by ip/1704:
[  115.621174]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff815e6dbb>] rtnetlink_rcv+0x1b/0x40
[  115.621174]  #1:  (&macvlan_netdev_addr_lock_key){+.....}, at: [<ffffffff815da5be>] dev_set_rx_mode+0x1e/0x40
[  115.621174]
stack backtrace:
[  115.621174] CPU: 3 PID: 1704 Comm: ip Not tainted 3.15.0-rc1+ #24
[  115.621174] Hardware name: Hewlett-Packard HP xw8400 Workstation/0A08h, BIOS 786D5 v02.38 10/25/2010
[  115.621174]  ffffffff82339ae0 ffff880465f79568 ffffffff816ee20c ffffffff82339ae0
[  115.621174]  ffff880465f795a8 ffffffff816e9e1b ffff880465f79600 ffff880465b019c8
[  115.621174]  0000000000000001 0000000000000002 ffff880465b019c8 ffff880465b01230
[  115.621174] Call Trace:
[  115.621174]  [<ffffffff816ee20c>] dump_stack+0x4d/0x66
[  115.621174]  [<ffffffff816e9e1b>] print_circular_bug+0x200/0x20e
[  115.621174]  [<ffffffff810d4d43>] __lock_acquire+0x1773/0x1a60
[  115.621174]  [<ffffffff810d3172>] ? trace_hardirqs_on_caller+0xb2/0x1d0
[  115.621174]  [<ffffffff810d57f2>] lock_acquire+0xa2/0x130
[  115.621174]  [<ffffffff815df49c>] ? dev_uc_sync+0x3c/0x80
[  115.621174]  [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50
[  115.621174]  [<ffffffff815df49c>] ? dev_uc_sync+0x3c/0x80
[  115.621174]  [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80
[  115.621174]  [<ffffffffa0696d2a>] macvlan_set_mac_lists+0xca/0x110 [macvlan]
[  115.621174]  [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0
[  115.621174]  [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40
[  115.621174]  [<ffffffff815da6be>] __dev_open+0xde/0x140
[  115.621174]  [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170
[  115.621174]  [<ffffffff815daaa9>] dev_change_flags+0x29/0x60
[  115.621174]  [<ffffffff811e1db1>] ? mem_cgroup_bad_page_check+0x21/0x30
[  115.621174]  [<ffffffff815e7f11>] do_setlink+0x321/0x9a0
[  115.621174]  [<ffffffff810d394c>] ? __lock_acquire+0x37c/0x1a60
[  115.621174]  [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730
[  115.621174]  [<ffffffff815ea169>] ? rtnl_newlink+0xe9/0x730
[  115.621174]  [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250
[  115.621174]  [<ffffffff810d329d>] ? trace_hardirqs_on+0xd/0x10
[  115.621174]  [<ffffffff815e6dbb>] ? rtnetlink_rcv+0x1b/0x40
[  115.621174]  [<ffffffff815e6de0>] ? rtnetlink_rcv+0x40/0x40
[  115.621174]  [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0
[  115.621174]  [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40
[  115.621174]  [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0
[  115.621174]  [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740
[  115.621174]  [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0
[  115.621174]  [<ffffffff8119d4af>] ? might_fault+0x5f/0xb0
[  115.621174]  [<ffffffff8119d4f8>] ? might_fault+0xa8/0xb0
[  115.621174]  [<ffffffff8119d4af>] ? might_fault+0x5f/0xb0
[  115.621174]  [<ffffffff815cb51e>] ? verify_iovec+0x5e/0xe0
[  115.621174]  [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380
[  115.621174]  [<ffffffff816faa0d>] ? __do_page_fault+0x11d/0x570
[  115.621174]  [<ffffffff810cfe9f>] ? up_read+0x1f/0x40
[  115.621174]  [<ffffffff816fab04>] ? __do_page_fault+0x214/0x570
[  115.621174]  [<ffffffff8120a10b>] ? mntput_no_expire+0x6b/0x1c0
[  115.621174]  [<ffffffff8120a0b7>] ? mntput_no_expire+0x17/0x1c0
[  115.621174]  [<ffffffff8120a284>] ? mntput+0x24/0x40
[  115.621174]  [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80
[  115.621174]  [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20
[  115.621174]  [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b

Fix this by correctly providing macvlan lockdep class.

Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16 22:14:49 -04:00
Vlad Yasevich
d38569ab2b vlan: Fix lockdep warning with stacked vlan devices.
This reverts commit dc8eaaa006.
	vlan: Fix lockdep warning when vlan dev handle notification

Instead we use the new new API to find the lock subclass of
our vlan device.  This way we can support configurations where
vlans are interspersed with other devices:
  bond -> vlan -> macvlan -> vlan

Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16 22:14:49 -04:00
Vlad Yasevich
25175ba5c9 net: Allow for more then a single subclass for netif_addr_lock
Currently netif_addr_lock_nested assumes that there can be only
a single nesting level between 2 devices.  However, if we
have multiple devices of the same type stacked, this fails.
For example:
 eth0 <-- vlan0.10 <-- vlan0.10.20

A more complicated configuration may stack more then one type of
device in different order.
Ex:
  eth0 <-- vlan0.10 <-- macvlan0 <-- vlan1.10.20 <-- macvlan1

This patch adds an ndo_* function that allows each stackable
device to report its nesting level.  If the device doesn't
provide this function default subclass of 1 is used.

Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16 22:14:49 -04:00
Vlad Yasevich
4085ebe8c3 net: Find the nesting level of a given device by type.
Multiple devices in the kernel can be stacked/nested and they
need to know their nesting level for the purposes of lockdep.
This patch provides a generic function that determines a nesting
level of a particular device by its type (ex: vlan, macvlan, etc).
We only care about nesting of the same type of devices.

For example:
  eth0 <- vlan0.10 <- macvlan0 <- vlan1.20

The nesting level of vlan1.20 would be 1, since there is another vlan
in the stack under it.

Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16 22:14:49 -04:00
Rafael J. Wysocki
aae4518b31 PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.

For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle).  We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.

However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle.  Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.

To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.

If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended.  It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended.  In that case, the PM
core will set the device's power.direct_complete flag.  Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).

Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set.  It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary.  For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().

Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 23:15:44 +02:00
Matan Barak
ce8d9e0d67 net/mlx4_core: Add UPDATE_QP SRIOV wrapper support
This patch adds UPDATE_QP SRIOV wrapper support.

The mechanism is a general one, but currently only source MAC
index changes are allowed for VFs.

Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-16 15:12:45 -04:00
Arnd Bergmann
cdf86cd233 gpio: include linux/bug.h in interface header
Today's linux-next kernel started showing build errors for the
use of WARN_ON in linux/gpio/consumer.h:

In file included from drivers/video/backlight/pwm_bl.c:13:0:
include/linux/gpio/consumer.h: In function 'gpiod_put':
include/linux/gpio/consumer.h:81:2: error: implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration]

It's not clear why this never happened before, but this patch
fixes it by including the header that contains the defintion
of this macro.

Signed-off-by: Arnd Bergmann <arnd@arnd.de>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-05-16 17:52:36 +02:00
Rafael J. Wysocki
1f0b63866f ACPI / PM: Hold ACPI scan lock over the "freeze" sleep state
The "freeze" sleep state suffers from the same issue that was
addressed by commit ad07277e82 (ACPI / PM: Hold acpi_scan_lock over
system PM transitions) for ACPI sleep states, that is, things break
if ->remove() is called for devices whose system resume callbacks
haven't been executed yet.

It also can be addressed in the same way, by holding the ACPI scan
lock over the "freeze" sleep state and PM transitions to and from
that state, but ->begin() and ->end() platform operations for the
"freeze" sleep state are needed for this purpose.

This change has been tested on Acer Aspire S5 with Thunderbolt.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-16 12:18:27 +02:00
Sebastian Reichel
dc7bf5d718 HSI: Introduce driver for SSI Protocol
This adds a driver for the SSI McSAAB protocol as used in
the Nokia N900.

Signed-off-by: Carlos Chinea <carlos.chinea@nokia.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Tested-By: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
2014-05-16 00:55:30 +02:00
Sebastian Reichel
a2aa24734d HSI: Add common DT binding for HSI client devices
Implement and document generic DT bindings for HSI clients.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Tested-By: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
2014-05-16 00:54:45 +02:00
Sebastian Reichel
8491451024 HSI: export method to (un)register clients
Expose method for registering and unregistering HSI clients, so that
client drivers can register other client drivers.

This is useful for HSI drivers, which want to use the functionality
of other HSI drivers. For example the N900 modem driver can load HSI
drivers for mcsaab protocol and speech protocol.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Tested-By: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
2014-05-16 00:54:41 +02:00
Sebastian Reichel
a088cf161c HSI: Add channel resource support to HSI clients
Make HSI channel ids platform data, which can be provided
by platform data.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
Tested-By: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
2014-05-16 00:54:36 +02:00
Sebastian Reichel
a0bf37edb4 HSI: method to unregister clients from an hsi port
This exports a method to unregister all clients from
an hsi port.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Tested-By: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
2014-05-16 00:54:29 +02:00
Cong Wang
200b916f35 rtnetlink: wait for unregistering devices in rtnl_link_unregister()
From: Cong Wang <cwang@twopensource.com>

commit 50624c934d (net: Delay default_device_exit_batch until no
devices are unregistering) introduced rtnl_lock_unregistering() for
default_device_exit_batch(). Same race could happen we when rmmod a driver
which calls rtnl_link_unregister() as we call dev->destructor without rtnl
lock.

For long term, I think we should clean up the mess of netdev_run_todo()
and net namespce exit code.

Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-15 15:30:33 -04:00
Pawel Moll
6b2c31c71d ARM: vexpress: move HBI check to sysreg driver
The last reason for static memory mapping is the HBI (board
identification number) check early in the machine code.

Moving the check to the sysreg driver makes it possible to
completely remove the early mapping and init functions.

Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
2014-05-15 17:02:21 +01:00