linux-stable.git/drivers, branch v3.18.17

x86: Clean up cr4 manipulation

2015-06-28T17:39:27+00:00

[ Upstream commit 375074cc736ab1d89a708c0a8d7baa4a70d5d476 ]

CR4 manipulation was split, seemingly at random, between direct
(write_cr4) and using a helper (set/clear_in_cr4).  Unfortunately,
the set_in_cr4 and clear_in_cr4 helpers also poke at the boot code,
which only a small subset of users actually wanted.

This patch replaces all cr4 access in functions that don't leave cr4
exactly the way they found it with new helpers cr4_set_bits,
cr4_clear_bits, and cr4_set_bits_and_update_boot.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrea Arcangeli 
Cc: Vince Weaver 
Cc: "hillf.zj" 
Cc: Valdis Kletnieks 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: Kees Cook 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/495a10bdc9e67016b8fd3945700d46cfd5c12c2f.1414190806.git.luto@amacapital.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

spi: bitbang: Make setup_transfer() callback optional

2015-06-28T17:39:27+00:00

[ Upstream commit 7d0ec8b6f40b356f780b79de63eeafd6b907d68c ]

Some controller drivers have no need of this callback (spi-altera even
causes a NULL pointer dereference because it doesn't register the callback,
falsely assuming that it is already optional).

Fixes: 30af9b558a56 ("spi/bitbang: Drop empty setup() functions")
Signed-off-by: Pelle Nilsson 
Reviewed-by: Ezequiel Garcia 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

dmaengine: shdmac: avoid unused variable warnings

2015-06-28T17:39:26+00:00

[ Upstream commit 7d3beab16dd9eee86bb1a4dd05b51159fc7772f0 ]

This driver uses '#ifdef CONFIG_ARCH_SHMOBILE' and '#ifdef CONFIG_ARM'
interchangeably in its sh_dmae_probe function, which causes a build
warning when building for ARM without also enabling shmobile:

dma/sh/shdmac.c: In function sh_dmae_probe:
dma/sh/shdmac.c:696:6: warning: unused variable errirq [-Wunused-variable]
dma/sh/shdmac.c:695:16: warning: unused variable irqflags [-Wunused-variable]
dma/sh/shdmac.c: At top level:
dma/sh/shdmac.c:447:20: warning: sh_dmae_err defined but not used [-Wunused-function]

This changes all the #ifdef to test for CONFIG_ARCH_SHMOBILE to
avoid that warning. An earlier patch from Laurent had fixed the warning
for non-ARM case, but it still remained present in ARM randconfig builds.

Signed-off-by: Arnd Bergmann 
Fixes: 52d6a5ee101bf ("DMA: shdma: Fix warnings due to declared but unused symbols")
Acked-by: Laurent Pinchart 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

mlx5: wrong page mask if CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for 32Bit architectures

2015-06-28T17:39:25+00:00

[ Upstream commit 59d2d18cc4e9ba30b370db18d0e02d792699da96 ]

If CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for x86 systems and physical
memory is more than 4GB, dma_map_page may return a valid memory
address which greater than 0xffffffff. As a result, the mlx5 device page
allocator RB tree will be initialized with valid addresses greater than
0xfffffff.

However, (addr & PAGE_MASK) set the high four bytes to zeros. So, it's
impossible for the function, free_4k, to release the pages whose
addresses greater than 4GB. Memory leaks. And mlx5_ib module can't
release the pages when user try to remove the module, as a result,
system hang.

[root@rdma05 root]# dmesg  | grep addr | head
addr             = 3fe384000
addr & PAGE_MASK =  fe384000
[root@rdma05 root]# rmmod mlx5_ib   <---- hang on

---------------------- cosnole log -----------------
mlx5_ib 0000:04:00.0: irq 138 for MSI/MSI-X
  alloc irq_desc for 139 on node -1
  alloc kstat_irqs on node -1
mlx5_ib 0000:04:00.0: irq 139 for MSI/MSI-X
0000:04:00.0:free_4k:221:(pid 1519): page not found
0000:04:00.0:free_4k:221:(pid 1519): page not found
0000:04:00.0:free_4k:221:(pid 1519): page not found
0000:04:00.0:free_4k:221:(pid 1519): page not found
---------------------- cosnole log -----------------

Fixes: bf0bf77f6519 ('mlx5: Support communicating arbitrary host page size to firmware')
Signed-off-by: Honggang Li 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin

[media] Add and use IS_REACHABLE macro

2015-06-28T17:39:23+00:00

[ Upstream commit 9b174527e7b756cda9f5d9e541f87b7fec9cfdf0 ]

In the media drivers, the v4l2 core knows about all submodules
and calls into them from a common function. However this cannot
work if the modules that get called are loadable and the
core is built-in. In that case we get

drivers/built-in.o: In function `set_type':
drivers/media/v4l2-core/tuner-core.c:301: undefined reference to `tea5767_attach'
drivers/media/v4l2-core/tuner-core.c:307: undefined reference to `tea5761_attach'
drivers/media/v4l2-core/tuner-core.c:349: undefined reference to `tda9887_attach'
drivers/media/v4l2-core/tuner-core.c:405: undefined reference to `xc4000_attach'

This was working previously, until the IS_ENABLED() macro was used
to replace the construct like

 #if defined(CONFIG_DVB_CX24110) || (defined(CONFIG_DVB_CX24110_MODULE) && defined(MODULE))

with the difference that the new code no longer checks whether it is being
built as a loadable module itself.

To fix this, this new patch adds an 'IS_REACHABLE' macro, which evaluates
true in exactly the condition that was used previously. The downside
of this is that this trades an obvious link error for a more subtle
runtime failure, but it is clear that the change that introduced the
link error was unintentional and it seems better to revert it for
now. Also, a similar change was originally created by Trent Piepho
and then reverted by teh change to the IS_ENABLED macro.

Ideally Kconfig would be used to avoid the case of a broken dependency,
or the code restructured in a way to turn around the dependency, but either
way would require much larger changes here.

Fixes: 7b34be71db53 ("[media] use IS_ENABLED() macro")
See-also: c5dec9fb248e ("V4L/DVB (4751): Fix DBV_FE_CUSTOMISE for card drivers compiled into kernel")

Signed-off-by: Arnd Bergmann 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

usb: dwc2: hcd: use new USB_RESUME_TIMEOUT

2015-06-28T17:39:22+00:00

[ Upstream commit 74bd7b69801819707713b88e9d0bc074efa2f5e7 ]

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Cc:  # v3.10+
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

serial: 8250_dw: add support for AMD SOC Carrizo

2015-06-28T17:39:20+00:00

[ Upstream commit 5ef86b74209db33c133b5f18738dd8f3189b63a1 ]

Add ACPI identifier for UART on AMD SOC Carrizo.

Signed-off-by: Ken Xue 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: 8250: add support for ACPI-probed serial port for X-Gene platform

2015-06-28T17:39:20+00:00

[ Upstream commit 5e1aeea52f6a0763e79473b1767401fda88eb7e1 ]

Enable APM X-Gene SoC serial port functionality when using ACPI table to
initialize serial port.

Signed-off-by: Feng Kan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Driver core: Unified device properties interface for platform firmware

2015-06-28T17:39:20+00:00

[ Upstream commit b31384fa5de37a100507751dfb5c0a49d06cee67 ]

Add a uniform interface by which device drivers can request device
properties from the platform firmware by providing a property name
and the corresponding data type.  The purpose of it is to help to
write portable code that won't depend on any particular platform
firmware interface.

The following general helper functions are added:

device_property_present()
device_property_read_u8()
device_property_read_u16()
device_property_read_u32()
device_property_read_u64()
device_property_read_string()
device_property_read_u8_array()
device_property_read_u16_array()
device_property_read_u32_array()
device_property_read_u64_array()
device_property_read_string_array()

The first one allows the caller to check if the given property is
present.  The next 5 of them allow single-valued properties of
various types to be retrieved in a uniform way.  The remaining 5 are
for reading properties with multiple values (arrays of either numbers
or strings).

The interface covers both ACPI and Device Trees.

This change set includes material from Mika Westerberg and Aaron Lu.

Signed-off-by: Aaron Lu 
Signed-off-by: Mika Westerberg 
Acked-by: Greg Kroah-Hartman 
Acked-by: Grant Likely 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: Add support for device specific properties

2015-06-28T17:39:20+00:00

[ Upstream commit ffdcd955c3078af3ce117edcfce80fde1a512bed ]

Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.

ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.

In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.

If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:

	Name (_DSD, Package () {
		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
		Package () {
			Package () {"name1", },
			Package () {"name2", },
			...
		}
	})

The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].

We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.

The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.

[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf

Reviewed-by: Hanjun Guo 
Reviewed-by: Josh Triplett 
Reviewed-by: Grant Likely 
Signed-off-by: Darren Hart 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin