android-sdk/kernel-video.git
6 years agoion: dummy: Increase carveout size to 8M ti-linux-3.14.y-drm
Hemant Hariyani [Wed, 3 Sep 2014 17:01:44 +0000 (12:01 -0500)]
ion: dummy: Increase carveout size to 8M

Allows allocation of buffers for larger displays.

Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
6 years agoion: dummy: Export dummy device
Hemant Hariyani [Wed, 3 Sep 2014 17:00:58 +0000 (12:00 -0500)]
ion: dummy: Export dummy device

Allows using dummy device from external kernel modules.

Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
6 years agodrm/omap: Allow importing of externally allocated dmabuf
Hemant Hariyani [Wed, 3 Sep 2014 16:53:32 +0000 (11:53 -0500)]
drm/omap: Allow importing of externally allocated dmabuf

This patch allows importing of dmabuf objects allocated by
non-gem allocaters (e.g. ion) into gem. This is helpful in
cases like Android where buffers are allocated by ion but need
to be imported into gem for display and video and for tiler
handling.

Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
6 years agoconfig_fragments: android: omap: Add config options for graphics/video/display
Hemant Hariyani [Wed, 3 Sep 2014 15:33:02 +0000 (10:33 -0500)]
config_fragments: android: omap: Add config options for graphics/video/display

Enables ION, dmabuf, ADF and sync framework.

Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
6 years agoarm: config: omap: Enable CONFIG_PREEMPT in omap2plus_defconfig
Hemant Hariyani [Wed, 3 Sep 2014 15:29:14 +0000 (10:29 -0500)]
arm: config: omap: Enable CONFIG_PREEMPT in omap2plus_defconfig

Required for OMAP/DRA graphics driver module.

Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
6 years ago(FIXUP) dra7: hwmod: Fix gpu iclk
Hemant Hariyani [Wed, 3 Sep 2014 15:27:52 +0000 (10:27 -0500)]
(FIXUP) dra7: hwmod: Fix gpu iclk

Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
6 years ago(FIXUP) arm/dts: dra7: Add gpu supply
Hemant Hariyani [Wed, 3 Sep 2014 15:25:22 +0000 (10:25 -0500)]
(FIXUP) arm/dts: dra7: Add gpu supply

Correct power supply for 3.14. Should be squashed with previous commit.

Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
6 years agoarm: dra7xx: Add gpu hwmod
Hemant Hariyani [Sun, 5 May 2013 23:29:18 +0000 (18:29 -0500)]
arm: dra7xx: Add gpu hwmod

GPU hwmod data for DRA7xx

Change-Id: I17f4c491e9a6a69052e9640e6bb2e74d5a753579
Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
Conflicts:

arch/arm/mach-omap2/omap_hwmod_7xx_data.c

6 years agoarm/dts: dra7: Add gpu supply
Hemant Hariyani [Thu, 11 Jul 2013 15:28:04 +0000 (10:28 -0500)]
arm/dts: dra7: Add gpu supply

Add smps6_reg as gpu supply

Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
6 years agoarm: dts: dra7xx: Add gpu data
Hemant Hariyani [Mon, 6 May 2013 14:24:48 +0000 (07:24 -0700)]
arm: dts: dra7xx: Add gpu data

Device tree entry for GPU.

Change-Id: I94c9a33f942b590244692001eb2ec8f9c98187c3
Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
Conflicts:
arch/arm/boot/dts/dra7.dtsi

6 years agoconfig_fragments: audio_display: enable DRM, FB and DSS configs
Subramaniam Chanderashekarapuram [Wed, 23 Jul 2014 23:33:32 +0000 (18:33 -0500)]
config_fragments: audio_display: enable DRM, FB and DSS configs

Added config flags to enable display support (DRM, FB, DSS, PANEL).

Change-Id: I64d1dd00ca98dac9aad8b0ef644715553aecee8c
Signed-off-by: Subramaniam Chanderashekarapuram <c.a.subramaniam@gmail.com>
6 years agoconfig_fragments: android: omap: fix boot options
Subramaniam Chanderashekarapuram [Tue, 22 Jul 2014 20:00:27 +0000 (15:00 -0500)]
config_fragments: android: omap: fix boot options

Fixed the boot options (CMDLINE and CMDLINE_EXTEND). This allows
the kernel to boot to console.

Change-Id: I6a2485189bab78581cecd2b03d04f19f92f5ca41
Signed-off-by: Subramaniam Chanderashekarapuram <c.a.subramaniam@gmail.com>
6 years agoARM: DRA7X: Fix DT_MACHINE_START name for DRA7X platforms
Subramaniam Chanderashekarapuram [Tue, 22 Jul 2014 16:37:20 +0000 (11:37 -0500)]
ARM: DRA7X: Fix DT_MACHINE_START name for DRA7X platforms

Fix the DRA72X and DRA74X DT_MACHINE_START names to be in line
with Android file system so that the init scripts load the appropriate
.rc files.

Change-Id: Idd25271feeaa15f02cd3ad840b41ff58ea375a06
Signed-off-by: Subramaniam Chanderashekarapuram <c.a.subramaniam@gmail.com>
6 years agoARM: dts: dra7: fix gpmc irq number
Subramaniam Chanderashekarapuram [Wed, 23 Jul 2014 23:06:25 +0000 (18:06 -0500)]
ARM: dts: dra7: fix gpmc irq number

Fix the gpmc node irq number. It should be using the crossbar
irq number and not the mpu irq number in the device tree node.

Change-Id: Id0b9c3366bf7c13d71059c5123a5c74f31af311d
Signed-off-by: Subramaniam Chanderashekarapuram <c.a.subramaniam@gmail.com>
6 years agoMerge branch 'dss_final' of git://git.ti.com/~a0393947/ti-linux-kernel/audio-video...
Praneeth Bajjuri [Tue, 22 Jul 2014 20:05:06 +0000 (15:05 -0500)]
Merge branch 'dss_final' of git://git.ti.com/~a0393947/ti-linux-kernel/audio-video-linux-feature-tree into p-ti-linux-3.14.y-dss

* 'dss_final' of git://git.ti.com/~a0393947/ti-linux-kernel/audio-video-linux-feature-tree: (46 commits)
  arm: dra7-evm.dts: Add support for HDMI connector
  ARM: dra7-evm.dts: Add LCD panel support
  arm: dra7.dtsi: add DSS DT support
  ARM: dts: set 'ti,set-rate-parent' for dss_dss_clk
  ARM: OMAP2+: Add detection of dra7-dss
  ARM: OMAP2+: Add DRA72xx version in omap_display_get_version()
  ARM: OMAP2+: Add DRA74xx version in omap_display_get_version()
  OMAPDSS: DPI: Add support for DRA72x DSS version
  OMAPDSS: dss/dispc/hdmi/pll: Add DRA72x version
  omapdss: Add new OMAPDSS version for DRA72x
  OMAPDSS: Add a custom TPD level shifter encoder driver for DRA7 EVM
  OMAPDSS: HDMI5: Allow external PLL control for DRA7x DSS versions
  OMAPDSS: HDMI4/5: Use PLL library
  OMAPDSS: PLL: Add HDMI PLL calculations to the library
  OMAPDSS: Displays: Add tlc59108 based DPI panel support
  omapdss: Add DRA74x version in dpi_get_channel()
  omapdss: dss/dispc/hdmi: Add compatible string for dra7
  OMAPDSS: DISPC: Choose the PLL type based on a dispc feature
  OMAPDSS: DPI: Use VIDEO PLLs on DRA7x
  OMAPDSS: Add Video DPLLs for DRA7x
  ...

Conflicts:
arch/arm/boot/dts/dra7-evm.dts
arch/arm/boot/dts/dra7.dtsi

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel...
Praneeth Bajjuri [Tue, 22 Jul 2014 16:27:23 +0000 (11:27 -0500)]
Merge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y

* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel: (111 commits)
  ARM: DTS: am437x-gp-evm: Rename fixed regulator vmmcsd_fixed to evm_v3_3d
  ARM: DTS: am43xx-epos-evm: Add regulator for VBAT and DCDC4 of tps65218
  ARM: OMAP2+: gpmc: fix gpmc_hwecc_bch_capable()
  mtd: Account for BBT blocks when a partition is being allocated
  mtd: Introduce mtd_block_isreserved()
  mtd: Add sysfs attributes to expose the ECC stats fields
  ARM: OMAP2+: Make GPMC skip disabled devices
  ARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()
  UBI: fastmap: do not miss bit-flips
  mtd: nand: omap: fix omap_calculate_ecc_bch() for-loop error
  mtd: devices: elm: fix elm_context_save() and elm_context_restore() functions
  ARM: dts: dra7: add support for parallel NAND flash
  am335x-evm: dtbs wl18xx handle suspend/resume padconf context loss
  OMAP/serial: Fix division by zero exception on 3M+ baud rates
  regulator: palmas: Fix SMPS list for 0V
  net: can: c_can_platform: Use devm_ioremap instead of devm_ioremap_resource.
  arm: dts: am437x-gp: Add dcan support
  arm: dts: am4372: Add dcan nodes
  Linux 3.14.13
  ACPI / battery: Retry to get battery information if failed during probing
  ...

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 years agoMerge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integrat...
Dan Murphy [Tue, 22 Jul 2014 15:00:13 +0000 (10:00 -0500)]
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  ARM: OMAP2+: gpmc: fix gpmc_hwecc_bch_capable()
  mtd: Account for BBT blocks when a partition is being allocated
  mtd: Introduce mtd_block_isreserved()
  mtd: Add sysfs attributes to expose the ECC stats fields
  ARM: OMAP2+: Make GPMC skip disabled devices
  ARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()
  UBI: fastmap: do not miss bit-flips
  mtd: nand: omap: fix omap_calculate_ecc_bch() for-loop error
  mtd: devices: elm: fix elm_context_save() and elm_context_restore() functions
  ARM: dts: dra7: add support for parallel NAND flash

Conflicts:
arch/arm/boot/dts/dra7.dtsi

Signed-off-by: Dan Murphy <dmurphy@ti.com>
6 years agoMerge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel...
Dan Murphy [Tue, 22 Jul 2014 13:48:58 +0000 (08:48 -0500)]
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-3.14.y

TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y

* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  ARM: DTS: am437x-gp-evm: Rename fixed regulator vmmcsd_fixed to evm_v3_3d
  ARM: DTS: am43xx-epos-evm: Add regulator for VBAT and DCDC4 of tps65218

Signed-off-by: Dan Murphy <dmurphy@ti.com>
6 years agoARM: DTS: am437x-gp-evm: Rename fixed regulator vmmcsd_fixed to evm_v3_3d
Peter Ujfalusi [Tue, 22 Jul 2014 10:58:20 +0000 (16:28 +0530)]
ARM: DTS: am437x-gp-evm: Rename fixed regulator vmmcsd_fixed to evm_v3_3d

The same regulator is used by other chips on the board. The power path is:
VBAT -> TPS63031 - Enable signal is V1_8D regulator -> V3_3D.
V3_3D is used by SD slot and tlv320aic3106 codec as well.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
6 years agoARM: DTS: am43xx-epos-evm: Add regulator for VBAT and DCDC4 of tps65218
Peter Ujfalusi [Tue, 22 Jul 2014 10:23:57 +0000 (13:23 +0300)]
ARM: DTS: am43xx-epos-evm: Add regulator for VBAT and DCDC4 of tps65218

The VBAT and DCDC4 regulator is needed for audio support (tlv320aic3111)

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
6 years agoMerge branch 'ti-linux-3.14.y-wlcore' of git.ti.com:wilink8-wlan/wilink8-wlan-ti...
Dan Murphy [Mon, 21 Jul 2014 19:12:02 +0000 (14:12 -0500)]
Merge branch 'ti-linux-3.14.y-wlcore' of git.ti.com:wilink8-wlan/wilink8-wlan-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: wlcore
TI-Tree: git@git.ti.com:wilink8-wlan/wilink8-wlan-ti-linux-kernel.git
TI-Branch: ti-linux-3.14.y-wlcore

* 'ti-linux-3.14.y-wlcore' of git.ti.com:wilink8-wlan/wilink8-wlan-ti-linux-kernel:
  am335x-evm: dtbs wl18xx handle suspend/resume padconf context loss
  OMAP/serial: Fix division by zero exception on 3M+ baud rates
  ARM: dra7: add bluetooth device-tree support
  ARM: DRA7: Add wlan support for DRA7
  am43x-epos-evm: add device tree support for bluetooth
  boot: dts: Add wlan support for Aegis-epos

Signed-off-by: Dan Murphy <DMurphy@ti.com>
6 years agoARM: OMAP2+: gpmc: fix gpmc_hwecc_bch_capable()
Christoph Fritz [Mon, 14 Jul 2014 01:36:18 +0000 (03:36 +0200)]
ARM: OMAP2+: gpmc: fix gpmc_hwecc_bch_capable()

This patch adds bch8 ecc software fallback which is mostly used by
omap3s because they lack hardware elm support.

Fixes: 0611c41934ab35ce84dea34ab291897ad3cbc7be (ARM: OMAP2+: gpmc:
update gpmc_hwecc_bch_capable() for new platforms and ECC schemes)
Cc: <stable@vger.kernel.org> # 3.15.x+
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Reviewed-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agomtd: Account for BBT blocks when a partition is being allocated
Ezequiel Garcia [Tue, 24 Jun 2014 13:55:52 +0000 (10:55 -0300)]
mtd: Account for BBT blocks when a partition is being allocated

With the introduction of mtd_block_isreserved(), it's now possible
to fix the bad and reserved block distribution exposed by ecc_stats,
instead of accounting all the bad or reserved blocks as 'bad'.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agomtd: Introduce mtd_block_isreserved()
Ezequiel Garcia [Tue, 24 Jun 2014 13:55:51 +0000 (10:55 -0300)]
mtd: Introduce mtd_block_isreserved()

In addition to mtd_block_isbad(), which checks if a block is bad or reserved,
it's needed to check if a block is reserved only (but not bad). This commit
adds an MTD interface for it, in a similar fashion to mtd_block_isbad().

While here, fix mtd_block_isbad() so the out-of-bounds checking is done the
callback check.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agomtd: Add sysfs attributes to expose the ECC stats fields
Ezequiel Garcia [Tue, 24 Jun 2014 13:55:50 +0000 (10:55 -0300)]
mtd: Add sysfs attributes to expose the ECC stats fields

These new sysfs device attributes allows to retrieve the ECC
and bad block stats by poking a sysfs file, which is often more convenient
than using the ioctl.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoARM: OMAP2+: Make GPMC skip disabled devices
Guido Martínez [Wed, 2 Jul 2014 13:35:18 +0000 (10:35 -0300)]
ARM: OMAP2+: Make GPMC skip disabled devices

Currently, child nodes of the gpmc node are iterated and probed
regardless of their 'status' property. This means adding 'status =
"disabled";' has no effect.

This patch changes the iteration to only probe nodes marked as
available.

Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()
Rostislav Lisovy [Wed, 9 Jul 2014 12:21:19 +0000 (14:21 +0200)]
ARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()

GPMC controller supports up to 8 memory devices connected to it.
Since there is one statically allocated "struct platform_device
gpmc_nand_device" it is not possible to configure the system to
use more than one NAND device connected to the GPMC. This
modification makes it possible to use up to 8 NAND devices
connected to the GPMC controller.

Signed-off-by: Rostislav Lisovy <lisovy@merica.cz>
[nsekhar@ti.com: fixed a 80-char line checkpatch warning]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoUBI: fastmap: do not miss bit-flips
Brian Norris [Wed, 21 May 2014 05:35:38 +0000 (22:35 -0700)]
UBI: fastmap: do not miss bit-flips

[ Upstream commit 44305ebde243a7cce2c592cc89afe5041d8bf884 ]

The return value from 'ubi_io_read_ec_hdr()' was stored in 'err', not in 'ret'.
This fix makes sure Fastmap-enabled UBI does not miss bit-flip while reading EC
headers, events and scrubs the affected PEBs.

This issue was reported by Coverity Scan.

Artem: improved the commit message.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agomtd: nand: omap: fix omap_calculate_ecc_bch() for-loop error
Ted Juan [Wed, 28 May 2014 14:33:06 +0000 (22:33 +0800)]
mtd: nand: omap: fix omap_calculate_ecc_bch() for-loop error

[ Upstream commit 2913aae5f9eae2f857cdeff5388bb22d0751aa08 ]

 Fixes:  2c9f2365d1e1d0e318b068f683f18c99515b80f8
 mtd: nand: omap: ecc.calculate: merge omap3_calculate_ecc_bch4 in omap_calculate_ecc_bch

 Fixes: 7bcd1dca1d587ad29f9825ba4414620440e8c8da
 mtd: nand: omap: ecc.calculate: merge omap3_calculate_ecc_bch8 in omap_calculate_ecc_bch

Cc: <stable@vger.kernel.org> # 3.13.x+
Signed-off-by: Ted Juan <ted.juan@gmail.com>
Acked-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agomtd: devices: elm: fix elm_context_save() and elm_context_restore() functions
Ted Juan [Fri, 20 Jun 2014 09:32:05 +0000 (17:32 +0800)]
mtd: devices: elm: fix elm_context_save() and elm_context_restore() functions

[ Upstream commit 6938ad40cb97a52d88a763008935340729a4acc7 ]

These two function's switch case lack the 'break' that make them always
return error.

Signed-off-by: Ted Juan <ted.juan@gmail.com>
Acked-by: Pekon Gupta <pekon@ti.com>
Cc: <stable@vger.kernel.org> # 3.12.x+
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoARM: dts: dra7: add support for parallel NAND flash
Minal Shah [Mon, 19 May 2014 09:15:47 +0000 (14:45 +0530)]
ARM: dts: dra7: add support for parallel NAND flash

[ Upstream commit ff66a3c86e004ce83f7c6e5f459d65c87f9d02b6 ]

DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
for accessing externel NAND flash device. This patch:
- adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
- adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
*Important*
On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
So following board settings are required for NAND device detection:
SW5.9 (GPMC_WPN) = LOW
SW5.1 (NAND_BOOTn) = HIGH

Signed-off-by: Minal Shah <minalkshah@gmail.com>
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoam335x-evm: dtbs wl18xx handle suspend/resume padconf context loss
Eyal Reizer [Thu, 20 Mar 2014 09:30:24 +0000 (11:30 +0200)]
am335x-evm: dtbs wl18xx handle suspend/resume padconf context loss

Some am335x pins are losing context during suspend and need to be
reconfigured on resume. This is affecting the mmc2 pins used for the com8
connector.

Use the default and sleep states mechanism of am33xx_pinmux for handling
these transitions.

Signed-off-by: Eyal Reizer <eyalr@ti.com>
6 years agoOMAP/serial: Fix division by zero exception on 3M+ baud rates
Alexey Pelykh [Thu, 31 Oct 2013 07:53:49 +0000 (13:23 +0530)]
OMAP/serial: Fix division by zero exception on 3M+ baud rates

Signed-off-by: Alexey Pelykh <alexey.pelykh@gmail.com>
 [Fixed checkpatch errors ]
Signed-off-by: Eyal Reizer <eyalr@ti.com>
6 years agoMerge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel...
Dan Murphy [Sat, 19 Jul 2014 16:33:01 +0000 (11:33 -0500)]
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-3.14.y

TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y

* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  regulator: palmas: Fix SMPS list for 0V

Signed-off-by: Dan Murphy <DMurphy@ti.com>
6 years agoregulator: palmas: Fix SMPS list for 0V
Nishanth Menon [Wed, 4 Jun 2014 19:34:31 +0000 (14:34 -0500)]
regulator: palmas: Fix SMPS list for 0V

[ Upstream commit 6b7f2d82d5dc30fd4a31faf44f701b683c28715e ]

get_voltage_sel reads from SMPS register - if the read selector value
is 0, the SMPS is actually disabled - So, this is in addition to the
ctrl_register that may also be used to enable/disable the SMPS.

The original logic(prior to commit dbabd624d4eec50b6) used to be:
static int palmas_map_voltage_smps(struct regulator_dev *rdev,
               int min_uV, int max_uV)
<snip>
       if (min_uV == 0)
               return 0;

To handle this scenario, with the transition to regulator_list
implementation, we seem to have missed the data necessary to mark as
one of the valid entries as "0" 'disabled regulator' which results in
0 volts - So, stick with pre-existing logic.

Without this added to the list, palmas regulator driver,
on probe, attempts to setup constraints and in the case of
OMAP5uEVM, SMPS9 (which is mapped for 2v1 audio supply) fails in
regulator_list_voltage_linear_range mapping of '0', and as a fall back
of constraints not being applied, the entire regulator list is not
enumerated due to assumption that something system wide has gone bad
on with the PMIC.

Fixes: dbabd624d4eec50b6 ("regulator: palmas: Reemove open coded functions with helper functions")
Reported-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
6 years agoMerge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux...
Dan Murphy [Fri, 18 Jul 2014 18:48:01 +0000 (13:48 -0500)]
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y

TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y

* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
  ARM: dts: dra7: add the necessary node for vpe support
  ARM: DRA7: hwmod: add the necessary hwmod entries for VPE module
  drm/omap: fix incorrect merge from mainline for ti-linux-3.14.y

Signed-off-by: Dan Murphy <DMurphy@ti.com>
6 years agoMerge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm...
Dan Murphy [Fri, 18 Jul 2014 18:09:34 +0000 (13:09 -0500)]
Merge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree into ti-linux-3.14.y

TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y

* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
  ARM: dts: dra72x: Enable 1.5GHz
  ARM: dts: dra72x: add clock nodes for CPU
  PM / Voltagedomain: core: Do not skip registration if regulator is found
  ARM: dts: dra74x: Enable 1.5GHz
  ARM: dts: dra72-evm: Add mapping of voltage domains to regulators

Signed-off-by: Dan Murphy <DMurphy@ti.com>
6 years agoMerge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integrat...
Dan Murphy [Fri, 18 Jul 2014 17:29:26 +0000 (12:29 -0500)]
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel: (23 commits)
  net: can: c_can_platform: Use devm_ioremap instead of devm_ioremap_resource.
  arm: dts: am437x-gp: Add dcan support
  arm: dts: am4372: Add dcan nodes
  ARM: dts: dra7: Add dt data for PCIe controller
  ARM: dts: dra7: Add dt data for PCIe PHY
  ARM: dts: dra7: Add dt data for PCIe PHY control module
  ARM: dts: dra7xx-clocks: Add missing clocks for second PCIe PHY instance
  ARM: dts: dra7xx-clocks: rename pcie clocks to accommodate second PHY instance
  ARM: dts: dra7xx-clocks: Add missing 32KHz clocks used for PHY
  ARM: dts: dra7xx-clocks: Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck
  ARM: dts: dra7xx-clocks: Add divider table to optfclk_pciephy_div clock
  PCI: host: pcie-dra7xx: add support for pcie-dra7xx controller
  Documentation: pci: ti: Add dt binding documentation for PCIe in DRA7xx
  PCI: designware: use untranslated address while programming ATU
  PCI: designware: Configuration space should be specified in 'reg'
  arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
  arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
  pci: pcie-designware: Remove irq_desc abuse
  PCI: designware: Use new OF interrupt mapping when possible
  PCI: designware: Split Exynos and i.MX bindings
  ...

Conflicts:
arch/arm/boot/dts/am4372.dtsi
arch/arm/boot/dts/am437x-gp-evm.dts

Signed-off-by: Dan Murphy <DMurphy@ti.com>
6 years agoMerge tag 'v3.14.13' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
Dan Murphy [Fri, 18 Jul 2014 16:07:42 +0000 (11:07 -0500)]
Merge tag 'v3.14.13' of git./linux/kernel/git/stable/linux-stable into ti-linux-3.14.y

This is the 3.14.13 stable release

* tag 'v3.14.13' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (61 commits)
  Linux 3.14.13
  ACPI / battery: Retry to get battery information if failed during probing
  x86, ioremap: Speed up check for RAM pages
  powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64
  drivers/rtc/rtc-puv3.c: use dev_dbg() instead of dev_debug() for typo issue
  drivers/rtc/rtc-puv3.c: remove "&dev->" for typo issue
  ring-buffer: Check if buffer exists before polling
  DMA, CMA: fix possible memory leak
  drm/i915: Don't clobber the GTT when it's within stolen memory
  drm/radeon: stop poisoning the GART TLB
  drm/radeon: fix typo in golden register setup on evergreen
  drm/radeon: fix typo in ci_stop_dpm()
  drm/radeon/dpm: Reenabling SS on Cayman
  ext4: fix a potential deadlock in __ext4_es_shrink()
  ext4: disable synchronous transaction batching if max_batch_time==0
  ext4: clarify ext4_error message in ext4_mb_generate_buddy_error()
  ext4: clarify error count warning messages
  ext4: fix unjournalled bg descriptor while initializing inode bitmap
  PCI: Fix unaligned access in AF transaction pending test
  intel_pstate: Set CPU number before accessing MSRs
  ...

Signed-off-by: Dan Murphy <DMurphy@ti.com>
6 years agonet: can: c_can_platform: Use devm_ioremap instead of devm_ioremap_resource.
George Cherian [Fri, 18 Jul 2014 05:59:12 +0000 (11:29 +0530)]
net: can: c_can_platform: Use devm_ioremap instead of devm_ioremap_resource.

The raminit register is shared register for both can0 and can1.
Using devm_ioremap_resource fails the mapping for can1 interface
leading to a non functional can interface.

Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoarm: dts: am437x-gp: Add dcan support
Mugunthan V N [Fri, 18 Jul 2014 05:59:11 +0000 (11:29 +0530)]
arm: dts: am437x-gp: Add dcan support

Add DCAN support for AM437x GP EVM with both DCAN instances.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoarm: dts: am4372: Add dcan nodes
Afzal Mohammed [Fri, 18 Jul 2014 05:59:10 +0000 (11:29 +0530)]
arm: dts: am4372: Add dcan nodes

Add dcan nodes.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
6 years agoLinux 3.14.13 v3.14.13
Greg Kroah-Hartman [Thu, 17 Jul 2014 23:21:11 +0000 (16:21 -0700)]
Linux 3.14.13

6 years agoACPI / battery: Retry to get battery information if failed during probing
Lan Tianyu [Mon, 7 Jul 2014 07:47:12 +0000 (15:47 +0800)]
ACPI / battery: Retry to get battery information if failed during probing

commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf upstream.

Some machines (eg. Lenovo Z480) ECs are not stable during boot up
and causes battery driver fails to be loaded due to failure of getting
battery information from EC sometimes. After several retries, the
operation will work. This patch is to retry to get battery information 5
times if the first try fails.

[ backport to 3.14.5: removed second parameter in acpi_battery_update(),
introduced by the commit 9e50bc14a7f58b5d8a55973b2d69355852ae2dae (ACPI /
battery: Accelerate battery resume callback)]

[naszar <naszar@ya.ru>: backport to 3.14.5]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581
Reported-and-tested-by: naszar <naszar@ya.ru>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agox86, ioremap: Speed up check for RAM pages
Roland Dreier [Fri, 2 May 2014 18:18:41 +0000 (11:18 -0700)]
x86, ioremap: Speed up check for RAM pages

commit c81c8a1eeede61e92a15103748c23d100880cc8a upstream.

In __ioremap_caller() (the guts of ioremap), we loop over the range of
pfns being remapped and checks each one individually with page_is_ram().
For large ioremaps, this can be very slow.  For example, we have a
device with a 256 GiB PCI BAR, and ioremapping this BAR can take 20+
seconds -- sometimes long enough to trigger the soft lockup detector!

Internally, page_is_ram() calls walk_system_ram_range() on a single
page.  Instead, we can make a single call to walk_system_ram_range()
from __ioremap_caller(), and do our further checks only for any RAM
pages that we find.  For the common case of MMIO, this saves an enormous
amount of work, since the range being ioremapped doesn't intersect
system RAM at all.

With this change, ioremap on our 256 GiB BAR takes less than 1 second.

Signed-off-by: Roland Dreier <roland@purestorage.com>
Link: http://lkml.kernel.org/r/1399054721-1331-1-git-send-email-roland@kernel.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agopowerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64
Guenter Roeck [Mon, 30 Jun 2014 18:45:30 +0000 (11:45 -0700)]
powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64

commit fb43e8477ed9006c4f397f904c691a120503038c upstream.

powerpc:allmodconfig has been failing for some time with the following
error.

arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards
make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1

A number of attempts to fix the problem by moving around code have been
unsuccessful and resulted in failed builds for some configurations and
the discovery of toolchain bugs.

Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead.
While this is less than perfect, it avoids substantial code changes
which would otherwise be necessary just to make COMPILE_TEST builds
happy and might have undesired side effects.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrivers/rtc/rtc-puv3.c: use dev_dbg() instead of dev_debug() for typo issue
Chen Gang [Sat, 3 May 2014 05:07:57 +0000 (13:07 +0800)]
drivers/rtc/rtc-puv3.c: use dev_dbg() instead of dev_debug() for typo issue

commit c863810cefc7ffd782e5648a21bfb36a32c8b081 upstream.

It is only a typo issue, the related commit:

  "1fbc4c4 drivers/rtc/rtc-puv3.c: use dev_dbg() instead of pr_debug()"

The related error (unicore32 with allmodconfig):

    CC [M]  drivers/rtc/rtc-puv3.o
  drivers/rtc/rtc-puv3.c: In function 'puv3_rtc_setpie':
  drivers/rtc/rtc-puv3.c:74: error: implicit declaration of function 'dev_debug'

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Acked-by: Xuetao Guan <gxt@mprc.pku.edu.cn>
Signed-off-by: Xuetao Guan <gxt@mprc.pku.edu.cn>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrivers/rtc/rtc-puv3.c: remove "&dev->" for typo issue
Chen Gang [Sat, 3 May 2014 05:09:02 +0000 (13:09 +0800)]
drivers/rtc/rtc-puv3.c: remove "&dev->" for typo issue

commit 73fa540618d8b1f8c2266934f23bd84bb9e28d9e upstream.

It is only a typo issue, the related commit:

  "1fbc4c4 drivers/rtc/rtc-puv3.c: use dev_dbg() instead of pr_debug()"

The related error (for unicore32 with allmodconfig):

    CC [M]  drivers/rtc/rtc-puv3.o
  drivers/rtc/rtc-puv3.c: In function 'puv3_rtc_setalarm':
  drivers/rtc/rtc-puv3.c:143: error: 'struct device' has no member named 'dev'

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Acked-by: Xuetao Guan <gxt@mprc.pku.edu.cn>
Signed-off-by: Xuetao Guan <gxt@mprc.pku.edu.cn>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoring-buffer: Check if buffer exists before polling
Steven Rostedt (Red Hat) [Tue, 10 Jun 2014 13:46:00 +0000 (09:46 -0400)]
ring-buffer: Check if buffer exists before polling

commit 8b8b36834d0fff67fc8668093f4312dd04dcf21d upstream.

The per_cpu buffers are created one per possible CPU. But these do
not mean that those CPUs are online, nor do they even exist.

With the addition of the ring buffer polling, it assumes that the
caller polls on an existing buffer. But this is not the case if
the user reads trace_pipe from a CPU that does not exist, and this
causes the kernel to crash.

Simple fix is to check the cpu against buffer bitmask against to see
if the buffer was allocated or not and return -ENODEV if it is
not.

More updates were done to pass the -ENODEV back up to userspace.

Link: http://lkml.kernel.org/r/5393DB61.6060707@oracle.com
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoDMA, CMA: fix possible memory leak
Joonsoo Kim [Mon, 23 Jun 2014 20:22:07 +0000 (13:22 -0700)]
DMA, CMA: fix possible memory leak

commit fe8eea4f4a3f299ef83ed090d5354698ebe4fda8 upstream.

We should free memory for bitmap when we find zone mismatch, otherwise
this memory will leak.

Additionally, I copy code comment from PPC KVM's CMA code to inform why
we need to check zone mis-match.

Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Reviewed-by: Michal Nazarewicz <mina86@mina86.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Gleb Natapov <gleb@kernel.org>
Cc: Alexander Graf <agraf@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrm/i915: Don't clobber the GTT when it's within stolen memory
Ville Syrjälä [Thu, 5 Jun 2014 17:02:59 +0000 (20:02 +0300)]
drm/i915: Don't clobber the GTT when it's within stolen memory

commit f1e1c2129b79cfdaf07bca37c5a10569fe021abe upstream.

On most gen2-4 platforms the GTT can be (or maybe always is?)
inside the stolen memory region. If that's the case, reduce the
size of the stolen memory appropriately to make make sure we
don't clobber the GTT.

v2: Deal with gen4 36 bit physical address

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80151
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrm/radeon: stop poisoning the GART TLB
Christian König [Wed, 4 Jun 2014 13:29:56 +0000 (15:29 +0200)]
drm/radeon: stop poisoning the GART TLB

commit 0986c1a55ca64b44ee126a2f719a6e9f28cbe0ed upstream.

When we set the valid bit on invalid GART entries they are
loaded into the TLB when an adjacent entry is loaded. This
poisons the TLB with invalid entries which are sometimes
not correctly removed on TLB flush.

For stable inclusion the patch probably needs to be modified a bit.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrm/radeon: fix typo in golden register setup on evergreen
Alex Deucher [Mon, 7 Jul 2014 21:59:37 +0000 (17:59 -0400)]
drm/radeon: fix typo in golden register setup on evergreen

commit 6abafb78f9881b4891baf74ab4e9f090ae45230e upstream.

Fixes hangs on driver load on some cards.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76998

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrm/radeon: fix typo in ci_stop_dpm()
Alex Deucher [Tue, 8 Jul 2014 22:25:25 +0000 (18:25 -0400)]
drm/radeon: fix typo in ci_stop_dpm()

commit ed96377132e564d797c48a5490fd46bed01c4273 upstream.

Need to use the RREG32_SMC() accessor since the register
is an smc indirect index.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodrm/radeon/dpm: Reenabling SS on Cayman
Alexandre Demers [Wed, 9 Jul 2014 02:27:36 +0000 (22:27 -0400)]
drm/radeon/dpm: Reenabling SS on Cayman

commit 41959341ac7e33dd360c7a881d13566f9eca37b2 upstream.

It reverts commit c745fe611ca42295c9d91d8e305d27983e9132ef now that
Cayman is stable since VDDCI fix. Spread spectrum was not the culprit.

This depends on b0880e87c1fd038b84498944f52e52c3e86ebe59
(drm/radeon/dpm: fix vddci setup typo on cayman).

Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoext4: fix a potential deadlock in __ext4_es_shrink()
Theodore Ts'o [Sat, 12 Jul 2014 19:32:24 +0000 (15:32 -0400)]
ext4: fix a potential deadlock in __ext4_es_shrink()

commit 3f1f9b851311a76226140b55b1ea22111234a7c2 upstream.

This fixes the following lockdep complaint:

[ INFO: possible circular locking dependency detected ]
3.16.0-rc2-mm1+ #7 Tainted: G           O
-------------------------------------------------------
kworker/u24:0/4356 is trying to acquire lock:
 (&(&sbi->s_es_lru_lock)->rlock){+.+.-.}, at: [<ffffffff81285fff>] __ext4_es_shrink+0x4f/0x2e0

but task is already holding lock:
 (&ei->i_es_lock){++++-.}, at: [<ffffffff81286961>] ext4_es_insert_extent+0x71/0x180

which lock already depends on the new lock.

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&ei->i_es_lock);
                               lock(&(&sbi->s_es_lru_lock)->rlock);
                               lock(&ei->i_es_lock);
  lock(&(&sbi->s_es_lru_lock)->rlock);

 *** DEADLOCK ***

6 locks held by kworker/u24:0/4356:
 #0:  ("writeback"){.+.+.+}, at: [<ffffffff81071d00>] process_one_work+0x180/0x560
 #1:  ((&(&wb->dwork)->work)){+.+.+.}, at: [<ffffffff81071d00>] process_one_work+0x180/0x560
 #2:  (&type->s_umount_key#22){++++++}, at: [<ffffffff811a9c74>] grab_super_passive+0x44/0x90
 #3:  (jbd2_handle){+.+...}, at: [<ffffffff812979f9>] start_this_handle+0x189/0x5f0
 #4:  (&ei->i_data_sem){++++..}, at: [<ffffffff81247062>] ext4_map_blocks+0x132/0x550
 #5:  (&ei->i_es_lock){++++-.}, at: [<ffffffff81286961>] ext4_es_insert_extent+0x71/0x180

stack backtrace:
CPU: 0 PID: 4356 Comm: kworker/u24:0 Tainted: G           O   3.16.0-rc2-mm1+ #7
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: writeback bdi_writeback_workfn (flush-253:0)
 ffffffff8213dce0 ffff880014b07538 ffffffff815df0bb 0000000000000007
 ffffffff8213e040 ffff880014b07588 ffffffff815db3dd ffff880014b07568
 ffff880014b07610 ffff88003b868930 ffff88003b868908 ffff88003b868930
Call Trace:
 [<ffffffff815df0bb>] dump_stack+0x4e/0x68
 [<ffffffff815db3dd>] print_circular_bug+0x1fb/0x20c
 [<ffffffff810a7a3e>] __lock_acquire+0x163e/0x1d00
 [<ffffffff815e89dc>] ? retint_restore_args+0xe/0xe
 [<ffffffff815ddc7b>] ? __slab_alloc+0x4a8/0x4ce
 [<ffffffff81285fff>] ? __ext4_es_shrink+0x4f/0x2e0
 [<ffffffff810a8707>] lock_acquire+0x87/0x120
 [<ffffffff81285fff>] ? __ext4_es_shrink+0x4f/0x2e0
 [<ffffffff8128592d>] ? ext4_es_free_extent+0x5d/0x70
 [<ffffffff815e6f09>] _raw_spin_lock+0x39/0x50
 [<ffffffff81285fff>] ? __ext4_es_shrink+0x4f/0x2e0
 [<ffffffff8119760b>] ? kmem_cache_alloc+0x18b/0x1a0
 [<ffffffff81285fff>] __ext4_es_shrink+0x4f/0x2e0
 [<ffffffff812869b8>] ext4_es_insert_extent+0xc8/0x180
 [<ffffffff812470f4>] ext4_map_blocks+0x1c4/0x550
 [<ffffffff8124c4c4>] ext4_writepages+0x6d4/0xd00
...

Reported-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: Minchan Kim <minchan@kernel.org>
Cc: Zheng Liu <gnehzuil.liu@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoext4: disable synchronous transaction batching if max_batch_time==0
Eric Sandeen [Sat, 5 Jul 2014 23:18:22 +0000 (19:18 -0400)]
ext4: disable synchronous transaction batching if max_batch_time==0

commit 5dd214248f94d430d70e9230bda72f2654ac88a8 upstream.

The mount manpage says of the max_batch_time option,

This optimization can be turned off entirely
by setting max_batch_time to 0.

But the code doesn't do that.  So fix the code to do
that.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoext4: clarify ext4_error message in ext4_mb_generate_buddy_error()
Theodore Ts'o [Sat, 5 Jul 2014 23:15:50 +0000 (19:15 -0400)]
ext4: clarify ext4_error message in ext4_mb_generate_buddy_error()

commit 94d4c066a4ff170a2671b1a9b153febbf36796f6 upstream.

We are spending a lot of time explaining to users what this error
means.  Let's try to improve the message to avoid this problem.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoext4: clarify error count warning messages
Theodore Ts'o [Sat, 5 Jul 2014 22:40:52 +0000 (18:40 -0400)]
ext4: clarify error count warning messages

commit ae0f78de2c43b6fadd007c231a352b13b5be8ed2 upstream.

Make it clear that values printed are times, and that it is error
since last fsck. Also add note about fsck version required.

Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoext4: fix unjournalled bg descriptor while initializing inode bitmap
Theodore Ts'o [Sat, 5 Jul 2014 20:28:35 +0000 (16:28 -0400)]
ext4: fix unjournalled bg descriptor while initializing inode bitmap

commit 61c219f5814277ecb71d64cb30297028d6665979 upstream.

The first time that we allocate from an uninitialized inode allocation
bitmap, if the block allocation bitmap is also uninitalized, we need
to get write access to the block group descriptor before we start
modifying the block group descriptor flags and updating the free block
count, etc.  Otherwise, there is the potential of a bad journal
checksum (if journal checksums are enabled), and of the file system
becoming inconsistent if we crash at exactly the wrong time.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoPCI: Fix unaligned access in AF transaction pending test
Alex Williamson [Tue, 17 Jun 2014 21:40:13 +0000 (15:40 -0600)]
PCI: Fix unaligned access in AF transaction pending test

commit d066c946a866268c14a120b33e7226e899981998 upstream.

pci_wait_for_pending() uses word access, so we shouldn't be passing
an offset that is only byte aligned.  Use the control register offset
instead, shifting the mask to match.

Fixes: d0b4cc4e3270 ("PCI: Wrong register used to check pending traffic")
Fixes: 157e876ffe0b ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agointel_pstate: Set CPU number before accessing MSRs
Vincent Minet [Fri, 4 Jul 2014 23:51:33 +0000 (01:51 +0200)]
intel_pstate: Set CPU number before accessing MSRs

commit 179e8471673ce0249cd4ecda796008f7757e5bad upstream.

Ensure that cpu->cpu is set before writing MSR_IA32_PERF_CTL during CPU
initialization. Otherwise only cpu0 has its P-state set and all other
cores are left with their values unchanged.

In most cases, this is not too serious because the P-states will be set
correctly when the timer function is run.  But when the default governor
is set to performance, the per-CPU current_pstate stays the same forever
and no attempts are made to write the MSRs again.

Signed-off-by: Vincent Minet <vincent@vincent-minet.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agointel_pstate: Update documentation of {max,min}_perf_pct sysfs files
Dirk Brandewie [Fri, 20 Jun 2014 14:28:00 +0000 (07:28 -0700)]
intel_pstate: Update documentation of {max,min}_perf_pct sysfs files

commit 41629a8233470325bfbb60377f555f9e8acc879f upstream.

Update documentation to make the interpretation of the values clearer

Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agointel_pstate: don't touch turbo bit if turbo disabled or unavailable.
Dirk Brandewie [Fri, 20 Jun 2014 14:27:59 +0000 (07:27 -0700)]
intel_pstate: don't touch turbo bit if turbo disabled or unavailable.

commit dd5fbf70f96dbfd7ee432096a1f979b2b3267856 upstream.

If turbo is disabled in the BIOS bit 38 should be set in
MSR_IA32_MISC_ENABLE register per section 14.3.2.1 of the SDM Vol 3
document 325384-050US Feb 2014.  If this bit is set do *not* attempt
to disable trubo via the MSR_IA32_PERF_CTL register.  On some systems
trying to disable turbo via MSR_IA32_PERF_CTL will cause subsequent
writes to MSR_IA32_PERF_CTL not take affect, in fact reading
MSR_IA32_PERF_CTL will not show the IDA/Turbo DISENGAGE bit(32) as
set. A write of bit 32 to zero returns to normal operation.

Also deal with the case where the processor does not support
turbo and the BIOS does not report the fact in MSR_IA32_MISC_ENABLE
but does report the max and turbo P states as the same value.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agointel_pstate: Fix setting VID
Dirk Brandewie [Fri, 20 Jun 2014 14:27:58 +0000 (07:27 -0700)]
intel_pstate: Fix setting VID

commit c16ed06024a6e699c332831dd50d8276744e3de8 upstream.

Commit 21855ff5 (intel_pstate: Set turbo VID for BayTrail) introduced
setting the turbo VID which is required to prevent a machine check on
some Baytrail SKUs under heavy graphics based workloads.  The
docmumentation update that brought the requirement to light also
changed the bit mask used for enumerating P state and VID values from
0x7f to 0x3f.

This change returns the mask value to 0x7f.

Tested with the Intel NUC DN2820FYK,
BIOS version FYBYT10H.86A.0034.2014.0513.1413 with v3.16-rc1 and
v3.14.8 kernel versions.

Fixes: 21855ff5 (intel_pstate: Set turbo VID for BayTrail)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77951
Reported-and-tested-by: Rune Reterson <rune@megahurts.dk>
Reported-and-tested-by: Eric Eickmeyer <erich@ericheickmeyer.com>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodm: allocate a special workqueue for deferred device removal
Mikulas Patocka [Sat, 14 Jun 2014 17:44:31 +0000 (13:44 -0400)]
dm: allocate a special workqueue for deferred device removal

commit acfe0ad74d2e1bfc81d1d7bf5e15b043985d3650 upstream.

The commit 2c140a246dc ("dm: allow remove to be deferred") introduced a
deferred removal feature for the device mapper.  When this feature is
used (by passing a flag DM_DEFERRED_REMOVE to DM_DEV_REMOVE_CMD ioctl)
and the user tries to remove a device that is currently in use, the
device will be removed automatically in the future when the last user
closes it.

Device mapper used the system workqueue to perform deferred removals.
However, some targets (dm-raid1, dm-mpath, dm-stripe) flush work items
scheduled for the system workqueue from their destructor.  If the
destructor itself is called from the system workqueue during deferred
removal, it introduces a possible deadlock - the workqueue tries to flush
itself.

Fix this possible deadlock by introducing a new workqueue for deferred
removals.  We allocate just one workqueue for all dm targets.  The
ability of dm targets to process IOs isn't dependent on deferred removal
of unused targets, so a deadlock due to shared workqueue isn't possible.

Also, cleanup local_init() to eliminate potential for returning success
on failure.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agodm io: fix a race condition in the wake up code for sync_io
Joe Thornber [Fri, 27 Jun 2014 19:29:04 +0000 (15:29 -0400)]
dm io: fix a race condition in the wake up code for sync_io

commit 10f1d5d111e8aed46a0f1179faf9a3cf422f689e upstream.

There's a race condition between the atomic_dec_and_test(&io->count)
in dec_count() and the waking of the sync_io() thread.  If the thread
is spuriously woken immediately after the decrement it may exit,
making the on stack io struct invalid, yet the dec_count could still
be using it.

Fix this race by using a completion in sync_io() and dec_count().

Reported-by: Minfei Huang <huangminfei@ucloud.cn>
Signed-off-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoDrivers: hv: vmbus: Fix a bug in the channel callback dispatch code
K. Y. Srinivasan [Mon, 7 Jul 2014 23:34:24 +0000 (16:34 -0700)]
Drivers: hv: vmbus: Fix a bug in the channel callback dispatch code

commit affb1aff300ddee54df307812b38f166e8a865ef upstream.

Starting with Win8, we have implemented several optimizations to improve the
scalability and performance of the VMBUS transport between the Host and the
Guest. Some of the non-performance critical services cannot leverage these
optimization since they only read and process one message at a time.
Make adjustments to the callback dispatch code to account for the way
non-performance critical drivers handle reading of the channel.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoclk: qcom: HDMI source sel is 3 not 2
Stephen Boyd [Wed, 25 Jun 2014 21:44:19 +0000 (14:44 -0700)]
clk: qcom: HDMI source sel is 3 not 2

commit c556bcddc78096caeb46dbe3ad0314dd951f1665 upstream.

The HDMI PLL input to the tv mux is supposed to be 3, not 2. Fix
the code so that we can properly select the HDMI PLL.

Fixes: 6d00b56fe "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)"
Reported-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoclk: s2mps11: Fix double free corruption during driver unbind
Krzysztof Kozlowski [Fri, 27 Jun 2014 12:21:10 +0000 (14:21 +0200)]
clk: s2mps11: Fix double free corruption during driver unbind

commit 2a96dfa49c83a2a7cbdb11382976aaa6b2636764 upstream.

After unbinding the driver memory was corrupted by double free of
clk_lookup structure. This lead to OOPS when re-binding the driver
again.

The driver allocated memory for 'clk_lookup' with devm_kzalloc. During
driver removal this memory was freed twice: once by clkdev_drop() and
second by devm code.

Kernel panic log:
[   30.839284] Unable to handle kernel paging request at virtual address 5f343173
[   30.846476] pgd = dee14000
[   30.849165] [5f343173] *pgd=00000000
[   30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[   30.858166] Modules linked in:
[   30.861208] CPU: 0 PID: 1 Comm: bash Not tainted 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   30.869364] task: df478000 ti: df480000 task.ti: df480000
[   30.874752] PC is at clkdev_add+0x2c/0x38
[   30.878738] LR is at clkdev_add+0x18/0x38
[   30.882732] pc : [<c0350908>]    lr : [<c03508f4>]    psr: 60000013
[   30.882732] sp : df481e78  ip : 00000001  fp : c0700ed8
[   30.894187] r10: 0000000c  r9 : 00000000  r8 : c07b0e3c
[   30.899396] r7 : 00000002  r6 : df45f9d0  r5 : df421390  r4 : c0700d6c
[   30.905906] r3 : 5f343173  r2 : c0700d84  r1 : 60000013  r0 : c0700d6c
[   30.912417] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   30.919534] Control: 10c53c7d  Table: 5ee1406a  DAC: 00000015
[   30.925262] Process bash (pid: 1, stack limit = 0xdf480240)
[   30.930817] Stack: (0xdf481e78 to 0xdf482000)
[   30.935159] 1e60:                                                       00001000 df6de610
[   30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510 dec9d69c 00000014
[   30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518 00000000 c0700e30 dec9d69c 00000006
[   30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420 c06fb150 c047cc20
[   30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 0000000c dec9d690 c02bef90
[   30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 0000000c c02be73c 0000000c c016ca8c
[   30.984116] 1f20: c016ca48 00000000 00000000 c016c1f4 00000000 00000000 b6f18000 df481f80
[   30.992276] 1f40: df7f66c0 0000000c df480000 df480000 b6f18000 c011094c df47839c 60000013
[   31.000435] 1f60: 00000000 00000000 df7f66c0 df7f66c0 0000000c df480000 b6f18000 c0110dd4
[   31.008594] 1f80: 00000000 00000000 0000000c b6ec05d8 0000000c b6f18000 00000004 c000f2a8
[   31.016753] 1fa0: 00001000 c000f0e0 b6ec05d8 0000000c 00000001 b6f18000 0000000c 00000000
[   31.024912] 1fc0: b6ec05d8 0000000c b6f18000 00000004 0000000c 00000001 00000000 00167b48
[   31.033071] 1fe0: 00000000 bed83a80 b6e004f0 b6e5122c 60000010 00000001 ffffffff ffffffff
[   31.041248] [<c0350908>] (clkdev_add) from [<c0355650>] (s2mps11_clk_probe+0x2b4/0x3b4)
[   31.049223] [<c0355650>] (s2mps11_clk_probe) from [<c02c1b7c>] (platform_drv_probe+0x18/0x48)
[   31.057728] [<c02c1b7c>] (platform_drv_probe) from [<c02c0420>] (driver_probe_device+0x13c/0x384)
[   31.066579] [<c02c0420>] (driver_probe_device) from [<c02bef90>] (bind_store+0x88/0xd8)
[   31.074564] [<c02bef90>] (bind_store) from [<c02be73c>] (drv_attr_store+0x20/0x2c)
[   31.082118] [<c02be73c>] (drv_attr_store) from [<c016ca8c>] (sysfs_kf_write+0x44/0x48)
[   31.090016] [<c016ca8c>] (sysfs_kf_write) from [<c016c1f4>] (kernfs_fop_write+0xc0/0x17c)
[   31.098176] [<c016c1f4>] (kernfs_fop_write) from [<c011094c>] (vfs_write+0xa0/0x1c4)
[   31.105899] [<c011094c>] (vfs_write) from [<c0110dd4>] (SyS_write+0x40/0x8c)
[   31.112931] [<c0110dd4>] (SyS_write) from [<c000f0e0>] (ret_fast_syscall+0x0/0x3c)
[   31.120481] Code: e2842018 e584501c e1a00004 e885000c (e5835000)
[   31.126596] ---[ end trace efad45bfa3a61b05 ]---
[   31.131181] Kernel panic - not syncing: Fatal exception
[   31.136368] CPU1: stopping
[   31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D       3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   31.148697] [<c0016480>] (unwind_backtrace) from [<c0012950>] (show_stack+0x10/0x14)
[   31.156419] [<c0012950>] (show_stack) from [<c0480db8>] (dump_stack+0x80/0xcc)
[   31.163622] [<c0480db8>] (dump_stack) from [<c001499c>] (handle_IPI+0x130/0x15c)
[   31.170998] [<c001499c>] (handle_IPI) from [<c000862c>] (gic_handle_irq+0x60/0x68)
[   31.178549] [<c000862c>] (gic_handle_irq) from [<c0013480>] (__irq_svc+0x40/0x70)
[   31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0)
[   31.191046] df80:                   ffffffed 00000000 00000000 00000000 df4bc000 c06d042c
[   31.199207] dfa0: 00000000 ffffffed c06d03c0 00000000 c070c288 00000000 00000000 df4bdfd0
[   31.207363] dfc0: c0010324 c0010328 60000013 ffffffff
[   31.212402] [<c0013480>] (__irq_svc) from [<c0010328>] (arch_cpu_idle+0x28/0x30)
[   31.219783] [<c0010328>] (arch_cpu_idle) from [<c005f150>] (cpu_startup_entry+0x2c4/0x3f0)
[   31.228027] [<c005f150>] (cpu_startup_entry) from [<400086c4>] (0x400086c4)
[   31.234968] ---[ end Kernel panic - not syncing: Fatal exception

Fixes: 7cc560dea415 ("clk: s2mps11: Add support for s2mps11")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoclk: spear3xx: Use proper control register offset
Thomas Gleixner [Thu, 19 Jun 2014 21:52:23 +0000 (21:52 +0000)]
clk: spear3xx: Use proper control register offset

commit 15ebb05248d025534773c9ef64915bd888f04e4b upstream.

The control register is at offset 0x10, not 0x0. This is wreckaged
since commit 5df33a62c (SPEAr: Switch to common clock framework).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agophy: core: Fix error path in phy_create()
Roger Quadros [Thu, 10 Jul 2014 06:25:02 +0000 (11:55 +0530)]
phy: core: Fix error path in phy_create()

commit e73b49f1c4e75c44d62585cc3e5b9c7894b61c32 upstream.

Prevent resources from being freed twice in case device_add() call
fails within phy_create(). Also use ida_simple_remove() instead of
ida_remove() as we had used ida_simple_get() to allocate the ida.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoarm64: implement TASK_SIZE_OF
Colin Cross [Wed, 18 Jun 2014 20:10:09 +0000 (21:10 +0100)]
arm64: implement TASK_SIZE_OF

commit fa2ec3ea10bd377f9d55772b1dab65178425a1a2 upstream.

include/linux/sched.h implements TASK_SIZE_OF as TASK_SIZE if it
is not set by the architecture headers.  TASK_SIZE uses the
current task to determine the size of the virtual address space.
On a 64-bit kernel this will cause reading /proc/pid/pagemap of a
64-bit process from a 32-bit process to return EOF when it reads
past 0xffffffff.

Implement TASK_SIZE_OF exactly the same as TASK_SIZE with
test_tsk_thread_flag instead of test_thread_flag.

Signed-off-by: Colin Cross <ccross@android.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agocrypto: caam - fix memleak in caam_jr module
Cristian Stoica [Mon, 7 Jul 2014 08:52:41 +0000 (11:52 +0300)]
crypto: caam - fix memleak in caam_jr module

commit 0378c9a855bfa395f595fbfb049707093e270f69 upstream.

This patch fixes a memory leak that appears when caam_jr module is unloaded.

Signed-off-by: Cristian Stoica <cristian.stoica@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agocrypto: sha512_ssse3 - fix byte count to bit count conversion
Jussi Kivilinna [Mon, 23 Jun 2014 16:41:05 +0000 (19:41 +0300)]
crypto: sha512_ssse3 - fix byte count to bit count conversion

commit cfe82d4f45c7cc39332a2be7c4c1d3bf279bbd3d upstream.

Byte-to-bit-count computation is only partly converted to big-endian and is
mixing in CPU-endian values. Problem was noticed by sparce with warning:

  CHECK   arch/x86/crypto/sha512_ssse3_glue.c
arch/x86/crypto/sha512_ssse3_glue.c:144:19: warning: restricted __be64 degrades to integer
arch/x86/crypto/sha512_ssse3_glue.c:144:17: warning: incorrect type in assignment (different base types)
arch/x86/crypto/sha512_ssse3_glue.c:144:17:    expected restricted __be64 <noident>
arch/x86/crypto/sha512_ssse3_glue.c:144:17:    got unsigned long long

Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agocpufreq: Makefile: fix compilation for davinci platform
Prabhakar Lad [Tue, 8 Jul 2014 15:25:38 +0000 (16:25 +0100)]
cpufreq: Makefile: fix compilation for davinci platform

commit 5a90af67c2126fe1d04ebccc1f8177e6ca70d3a9 upstream.

Since commtit 8a7b1227e303 (cpufreq: davinci: move cpufreq driver to
drivers/cpufreq) this added dependancy only for CONFIG_ARCH_DAVINCI_DA850
where as davinci_cpufreq_init() call is used by all davinci platform.

This patch fixes following build error:

arch/arm/mach-davinci/built-in.o: In function `davinci_init_late':
:(.init.text+0x928): undefined reference to `davinci_cpufreq_init'
make: *** [vmlinux] Error 1

Fixes: 8a7b1227e303 (cpufreq: davinci: move cpufreq driver to drivers/cpufreq)
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agopowerpc/perf: Clear MMCR2 when enabling PMU
Joel Stanley [Tue, 8 Jul 2014 06:38:22 +0000 (16:08 +0930)]
powerpc/perf: Clear MMCR2 when enabling PMU

commit b50a6c584bb47b370f84bfd746770c0bbe7129b7 upstream.

On POWER8 when switching to a KVM guest we set bits in MMCR2 to freeze
the PMU counters. Aside from on boot they are then never reset,
resulting in stuck perf counters for any user in the guest or host.

We now set MMCR2 to 0 whenever enabling the PMU, which provides a sane
state for perf to use the PMU counters under either the guest or the
host.

This was manifesting as a bug with ppc64_cpu --frequency:

    $ sudo ppc64_cpu --frequency
    WARNING: couldn't run on cpu 0
    WARNING: couldn't run on cpu 8
      ...
    WARNING: couldn't run on cpu 144
    WARNING: couldn't run on cpu 152
    min:    18446744073.710 GHz (cpu -1)
    max:    0.000 GHz (cpu -1)
    avg:    0.000 GHz

The command uses a perf counter to measure CPU cycles over a fixed
amount of time, in order to approximate the frequency of the machine.
The counters were returning zero once a guest was started, regardless of
weather it was still running or had been shut down.

By dumping the value of MMCR2, it was observed that once a guest is
running MMCR2 is set to 1s - which stops counters from running:

    $ sudo sh -c 'echo p > /proc/sysrq-trigger'
    CPU: 0 PMU registers, ppmu = POWER8 n_counters = 6
    PMC1:  5b635e38 PMC2: 00000000 PMC3: 00000000 PMC4: 00000000
    PMC5:  1bf5a646 PMC6: 5793d378 PMC7: deadbeef PMC8: deadbeef
    MMCR0: 0000000080000000 MMCR1: 000000001e000000 MMCRA: 0000040000000000
    MMCR2: fffffffffffffc00 EBBHR: 0000000000000000
    EBBRR: 0000000000000000 BESCR: 0000000000000000
    SIAR:  00000000000a51cc SDAR:  c00000000fc40000 SIER:  0000000001000000

This is done unconditionally in book3s_hv_interrupts.S upon entering the
guest, and the original value is only save/restored if the host has
indicated it was using the PMU. This is okay, however the user of the
PMU needs to ensure that it is in a defined state when it starts using
it.

Fixes: e05b9b9e5c10 ("powerpc/perf: Power8 PMU support")
Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agopowerpc/perf: Add PPMU_ARCH_207S define
Joel Stanley [Tue, 8 Jul 2014 06:38:21 +0000 (16:08 +0930)]
powerpc/perf: Add PPMU_ARCH_207S define

commit 4d9690dd56b0d18f2af8a9d4a279cb205aae3345 upstream.

Instead of separate bits for every POWER8 PMU feature, have a single one
for v2.07 of the architecture.

This saves us adding a MMCR2 define for a future patch.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agopowerpc/perf: Never program book3s PMCs with values >= 0x80000000
Anton Blanchard [Wed, 28 May 2014 22:15:38 +0000 (08:15 +1000)]
powerpc/perf: Never program book3s PMCs with values >= 0x80000000

commit f56029410a13cae3652d1f34788045c40a13ffc7 upstream.

We are seeing a lot of PMU warnings on POWER8:

    Can't find PMC that caused IRQ

Looking closer, the active PMC is 0 at this point and we took a PMU
exception on the transition from negative to 0. Some versions of POWER8
have an issue where they edge detect and not level detect PMC overflows.

A number of places program the PMC with (0x80000000 - period_left),
where period_left can be negative. We can either fix all of these or
just ensure that period_left is always >= 1.

This patch takes the second option.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoACPI / EC: Fix race condition in ec_transaction_completed()
Lv Zheng [Sun, 15 Jun 2014 00:42:07 +0000 (08:42 +0800)]
ACPI / EC: Fix race condition in ec_transaction_completed()

commit c0d653412fc8450370167a3268b78fc772ff9c87 upstream.

There is a race condition in ec_transaction_completed().

When ec_transaction_completed() is called in the GPE handler, it could
return true because of (ec->curr == NULL). Then the wake_up() invocation
could complete the next command unexpectedly since there is no lock between
the 2 invocations. With the previous cleanup, the IBF=0 waiter race need
not be handled any more. It's now safe to return a flag from
advance_condition() to indicate the requirement of wakeup, the flag is
returned from a locked context.

The ec_transaction_completed() is now only invoked by the ec_poll() where
the ec->curr is ensured to be different from NULL.

After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup
condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a
QR_SC command.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk>
Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org>
Reported-by: Barton Xu <tank.xuhan@gmail.com>
Tested-by: Steffen Weber <steffen.weber@gmail.com>
Tested-by: Arthur Chen <axchen@nvidia.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoACPI / EC: Remove duplicated ec_wait_ibf0() waiter
Lv Zheng [Sun, 15 Jun 2014 00:41:48 +0000 (08:41 +0800)]
ACPI / EC: Remove duplicated ec_wait_ibf0() waiter

commit 9b80f0f73ae1583c22325ede341c74195847618c upstream.

After we've added the first command byte write into advance_transaction(),
the IBF=0 waiter is duplicated with the command completion waiter
implemented in the ec_poll() because:
   If IBF=1 blocked the first command byte write invoked in the task
   context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed
   out and retried again in the task context.

Remove this seperate and duplicate IBF=0 waiter.  By doing so we can
reduce the overall number of times to access the EC_SC(R) status
register.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk>
Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org>
Reported-by: Barton Xu <tank.xuhan@gmail.com>
Tested-by: Steffen Weber <steffen.weber@gmail.com>
Tested-by: Arthur Chen <axchen@nvidia.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoACPI / EC: Add asynchronous command byte write support
Lv Zheng [Sun, 15 Jun 2014 00:41:35 +0000 (08:41 +0800)]
ACPI / EC: Add asynchronous command byte write support

commit f92fca0060fc4dc9227342d0072d75df98c1e5a5 upstream.

Move the first command byte write into advance_transaction() so that all
EC register accesses that can affect the command processing state machine
can happen in this asynchronous state machine advancement function.

The advance_transaction() function then can be a complete implementation
of an asyncrhonous transaction for a single command so that:
 1. The first command byte can be written in the interrupt context;
 2. The command completion waiter can also be used to wait the first command
    byte's timeout;
 3. In BURST mode, the follow-up command bytes can be written in the
    interrupt context directly, so that it doesn't need to return to the
    task context. Returning to the task context reduces the throughput of
    the BURST mode and in the worst cases where the system workload is very
    high, this leads to the hardware driven automatic BURST mode exit.

In order not to increase memory consumption, convert 'done' into 'flags'
to contain multiple indications:
 1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition,
    indicating the completion of the command transaction.
 2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first
    command byte. A new command can utilize this flag to compete for the
    right of accessing the underlying hardware. There is a follow-up bug
    fix that has utilized this new flag.

The 2 flags are important because it also reflects a key concept of IO
programs' design used in the system softwares. Normally an IO program
running in the kernel should first be implemented in the asynchronous way.
And the 2 flags are the most common way to implement its synchronous
operations on top of the asynchronous operations:
1. POLL: This flag can be used to block until the asynchronous operations
         can happen.
2. COMPLETE: This flag can be used to block until the asynchronous
             operations have completed.
By constructing code cleanly in this way, many difficult problems can be
solved smoothly.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk>
Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org>
Reported-by: Barton Xu <tank.xuhan@gmail.com>
Tested-by: Steffen Weber <steffen.weber@gmail.com>
Tested-by: Arthur Chen <axchen@nvidia.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoACPI / EC: Avoid race condition related to advance_transaction()
Lv Zheng [Sun, 15 Jun 2014 00:41:17 +0000 (08:41 +0800)]
ACPI / EC: Avoid race condition related to advance_transaction()

commit 66b42b78bc1e816f92b662e8888c89195e4199e1 upstream.

The advance_transaction() will be invoked from the IRQ context GPE handler
and the task context ec_poll(). The handling of this function is locked so
that the EC state machine are ensured to be advanced sequentially.

But there is a problem. Before invoking advance_transaction(), EC_SC(R) is
read. Then for advance_transaction(), there could be race condition around
the lock from both contexts. The first one reading the register could fail
this race and when it passes the stale register value to the state machine
advancement code, the hardware condition is totally different from when
the register is read. And the hardware accesses determined from the wrong
hardware status can break the EC state machine. And there could be cases
that the functionalities of the platform firmware are seriously affected.
For example:
 1. When 2 EC_DATA(W) writes compete the IBF=0, the 2nd EC_DATA(W) write may
    be invalid due to IBF=1 after the 1st EC_DATA(W) write. Then the
    hardware will either refuse to respond a next EC_SC(W) write of the next
    command or discard the current WR_EC command when it receives a EC_SC(W)
    write of the next command.
 2. When 1 EC_SC(W) write and 1 EC_DATA(W) write compete the IBF=0, the
    EC_DATA(W) write may be invalid due to IBF=1 after the EC_SC(W) write.
    The next EC_DATA(R) could never be responded by the hardware. This is
    the root cause of the reported issue.

Fix this issue by moving the EC_SC(R) access into the lock so that we can
ensure that the state machine is advanced consistently.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk>
Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org>
Reported-by: Barton Xu <tank.xuhan@gmail.com>
Tested-by: Steffen Weber <steffen.weber@gmail.com>
Tested-by: Arthur Chen <axchen@nvidia.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoACPI / resources: only reject zero length resources based at address zero
Andy Whitcroft [Thu, 19 Jun 2014 10:19:16 +0000 (11:19 +0100)]
ACPI / resources: only reject zero length resources based at address zero

commit 867f9d463b82462793ea4610e748be0b04b37fc7 upstream.

The recently merged change (in v3.14-rc6) to ACPI resource detection
(below) causes all zero length ACPI resources to be elided from the
table:

  commit b355cee88e3b1a193f0e9a81db810f6f83ad728b
  Author: Zhang Rui <rui.zhang@intel.com>
  Date:   Thu Feb 27 11:37:15 2014 +0800

    ACPI / resources: ignore invalid ACPI device resources

This change has caused a regression in (at least) serial port detection
for a number of machines (see LP#1313981 [1]).  These seem to represent
their IO regions (presumably incorrectly) as a zero length region.
Reverting the above commit restores these serial devices.

Only elide zero length resources which lie at address 0.

Fixes: b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources)
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoRevert "ACPI / AC: Remove AC's proc directory."
Lan Tianyu [Sun, 6 Jul 2014 23:13:46 +0000 (01:13 +0200)]
Revert "ACPI / AC: Remove AC's proc directory."

commit e63f6e28dda6de3de2392ddca321e211fd860925 upstream.

Revert commit ab0fd674d6ce (ACPI / AC: Remove AC's proc directory.),
because some old tools (e.g. kpowersave from kde 3.5.10) are still
using /proc/acpi/ac_adapter.

Fixes: ab0fd674d6ce (ACPI / AC: Remove AC's proc directory.)
Reported-and-tested-by: Sorin Manolache <sorinm@gmail.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agohwmon: (adm1021) Fix cache problem when writing temperature limits
Axel Lin [Thu, 3 Jul 2014 14:45:45 +0000 (22:45 +0800)]
hwmon: (adm1021) Fix cache problem when writing temperature limits

commit c024044d4da2c9c3b32933b4235df1e409293b84 upstream.

The module test script for the adm1021 driver exposes a cache problem
when writing temperature limits. temp_min and temp_max are expected
to be stored in milli-degrees C but are stored in degrees C.

Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agohwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div
Axel Lin [Wed, 2 Jul 2014 00:29:55 +0000 (08:29 +0800)]
hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div

commit 1035a9e3e9c76b64a860a774f5b867d28d34acc2 upstream.

Writing to fanX_div does not clear the cache. As a result, reading
from fanX_div may return the old value for up to two seconds
after writing a new value.

This patch ensures the fan_div cache is updated in set_fan_div().

Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agohwmon: (adm1031) Fix writes to limit registers
Guenter Roeck [Thu, 3 Jul 2014 20:44:23 +0000 (13:44 -0700)]
hwmon: (adm1031) Fix writes to limit registers

commit 145e74a4e5022225adb84f4e5d4fff7938475c35 upstream.

Upper limit for write operations to temperature limit registers
was clamped to a fractional value. However, limit registers do
not support fractional values. As a result, upper limits of 127.5
degrees C or higher resulted in a rounded limit of 128 degrees C.
Since limit registers are signed, this was stored as -128 degrees C.
Clamp limits to (-55, +127) degrees C to solve the problem.

Value on writes to auto_temp[12]_min and auto_temp[12]_max were not
clamped at all, but masked. As a result, out-of-range writes resulted
in a more or less arbitrary limit. Clamp those attributes to (0, 127)
degrees C for more predictable results.

Cc: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agohwmon: (emc2103) Clamp limits instead of bailing out
Guenter Roeck [Sun, 6 Jul 2014 18:39:24 +0000 (11:39 -0700)]
hwmon: (emc2103) Clamp limits instead of bailing out

commit f6c2dd20108c35e30e2c1f3c6142d189451a626b upstream.

It is customary to clamp limits instead of bailing out with an error
if a configured limit is out of the range supported by the driver.
This simplifies limit configuration, since the user will not typically
know chip and/or driver specific limits.

Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agohwmon: (amc6821) Fix permissions for temp2_input
Axel Lin [Tue, 1 Jul 2014 23:44:44 +0000 (07:44 +0800)]
hwmon: (amc6821) Fix permissions for temp2_input

commit df86754b746e9a0ff6f863f690b1c01d408e3cdc upstream.

temp2_input should not be writable, fix it.

Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agothermal: hwmon: Make the check for critical temp valid consistent
Aaron Lu [Wed, 21 May 2014 08:33:27 +0000 (16:33 +0800)]
thermal: hwmon: Make the check for critical temp valid consistent

commit e8db5d6736a712a3e2280c0e31f4b301d85172d8 upstream.

On 05/21/2014 04:22 PM, Aaron Lu wrote:
> On 05/21/2014 01:57 PM, Kui Zhang wrote:
>> Hello,
>>
>> I get following error when rmmod thermal.
>>
>> rmmod  thermal
>> Killed

While dealing with this problem, I found another problem that also
results in a kernel crash on thermal module removal:

From: Aaron Lu <aaron.lu@intel.com>
Date: Wed, 21 May 2014 16:05:38 +0800
Subject: thermal: hwmon: Make the check for critical temp valid consistent

We used the tz->ops->get_crit_temp && !tz->ops->get_crit_temp(tz, temp)
to decide if we need to create the temp_crit attribute file but we just
check if tz->ops->get_crit_temp exists to decide if we need to remove
that attribute file. Some ACPI thermal zone doesn't have a valid critical
trip point and that would result in removing a non-existent device file
on thermal module unload.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoi8k: Fix non-SMP operation
Guenter Roeck [Sat, 21 Jun 2014 15:08:08 +0000 (08:08 -0700)]
i8k: Fix non-SMP operation

commit 6d827fbcc370ca259a2905309f64161ab7b10596 upstream.

Commit f36fdb9f0266 (i8k: Force SMM to run on CPU 0) adds support
for multi-core CPUs to the driver. Unfortunately, that causes it
to fail loading if compiled without SMP support, at least on
32 bit kernels. Kernel log shows "i8k: unable to get SMM Dell
signature", and function i8k_smm is found to return -EINVAL.

Testing revealed that the culprit is the missing return value check
of set_cpus_allowed_ptr.

Fixes: f36fdb9f0266 (i8k: Force SMM to run on CPU 0)
Reported-by: Jim Bos <jim876@xs4all.nl>
Tested-by: Jim Bos <jim876@xs4all.nl>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: Andreas Mohr <andi@lisas.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoworkqueue: zero cpumask of wq_numa_possible_cpumask on init
Yasuaki Ishimatsu [Mon, 7 Jul 2014 13:56:48 +0000 (09:56 -0400)]
workqueue: zero cpumask of wq_numa_possible_cpumask on init

commit 5a6024f1604eef119cf3a6fa413fe0261a81a8f3 upstream.

When hot-adding and onlining CPU, kernel panic occurs, showing following
call trace.

  BUG: unable to handle kernel paging request at 0000000000001d08
  IP: [<ffffffff8114acfd>] __alloc_pages_nodemask+0x9d/0xb10
  PGD 0
  Oops: 0000 [#1] SMP
  ...
  Call Trace:
   [<ffffffff812b8745>] ? cpumask_next_and+0x35/0x50
   [<ffffffff810a3283>] ? find_busiest_group+0x113/0x8f0
   [<ffffffff81193bc9>] ? deactivate_slab+0x349/0x3c0
   [<ffffffff811926f1>] new_slab+0x91/0x300
   [<ffffffff815de95a>] __slab_alloc+0x2bb/0x482
   [<ffffffff8105bc1c>] ? copy_process.part.25+0xfc/0x14c0
   [<ffffffff810a3c78>] ? load_balance+0x218/0x890
   [<ffffffff8101a679>] ? sched_clock+0x9/0x10
   [<ffffffff81105ba9>] ? trace_clock_local+0x9/0x10
   [<ffffffff81193d1c>] kmem_cache_alloc_node+0x8c/0x200
   [<ffffffff8105bc1c>] copy_process.part.25+0xfc/0x14c0
   [<ffffffff81114d0d>] ? trace_buffer_unlock_commit+0x4d/0x60
   [<ffffffff81085a80>] ? kthread_create_on_node+0x140/0x140
   [<ffffffff8105d0ec>] do_fork+0xbc/0x360
   [<ffffffff8105d3b6>] kernel_thread+0x26/0x30
   [<ffffffff81086652>] kthreadd+0x2c2/0x300
   [<ffffffff81086390>] ? kthread_create_on_cpu+0x60/0x60
   [<ffffffff815f20ec>] ret_from_fork+0x7c/0xb0
   [<ffffffff81086390>] ? kthread_create_on_cpu+0x60/0x60

In my investigation, I found the root cause is wq_numa_possible_cpumask.
All entries of wq_numa_possible_cpumask is allocated by
alloc_cpumask_var_node(). And these entries are used without initializing.
So these entries have wrong value.

When hot-adding and onlining CPU, wq_update_unbound_numa() is called.
wq_update_unbound_numa() calls alloc_unbound_pwq(). And alloc_unbound_pwq()
calls get_unbound_pool(). In get_unbound_pool(), worker_pool->node is set
as follow:

3592         /* if cpumask is contained inside a NUMA node, we belong to that node */
3593         if (wq_numa_enabled) {
3594                 for_each_node(node) {
3595                         if (cpumask_subset(pool->attrs->cpumask,
3596                                            wq_numa_possible_cpumask[node])) {
3597                                 pool->node = node;
3598                                 break;
3599                         }
3600                 }
3601         }

But wq_numa_possible_cpumask[node] does not have correct cpumask. So, wrong
node is selected. As a result, kernel panic occurs.

By this patch, all entries of wq_numa_possible_cpumask are allocated by
zalloc_cpumask_var_node to initialize them. And the panic disappeared.

Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: bce903809ab3 ("workqueue: add wq_numa_tbl_len and wq_numa_possible_cpumask[]")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agocpuset,mempolicy: fix sleeping function called from invalid context
Gu Zheng [Wed, 25 Jun 2014 01:57:18 +0000 (09:57 +0800)]
cpuset,mempolicy: fix sleeping function called from invalid context

commit 391acf970d21219a2a5446282d3b20eace0c0d7a upstream.

When runing with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python
[ 9969.441175] INFO: lockdep is turned off.
[ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G       A      3.15.0-rc7+ #85
[ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012
[ 9969.706052]  ffffffff81a20e60 ffff8803e941fbd0 ffffffff8162f523 ffff8803e941fd18
[ 9969.795323]  ffff8803e941fbe0 ffffffff8109995a ffff8803e941fc58 ffffffff81633e6c
[ 9969.884710]  ffffffff811ba5dc ffff880405c6b480 ffff88041fdd90a0 0000000000002000
[ 9969.974071] Call Trace:
[ 9970.003403]  [<ffffffff8162f523>] dump_stack+0x4d/0x66
[ 9970.065074]  [<ffffffff8109995a>] __might_sleep+0xfa/0x130
[ 9970.130743]  [<ffffffff81633e6c>] mutex_lock_nested+0x3c/0x4f0
[ 9970.200638]  [<ffffffff811ba5dc>] ? kmem_cache_alloc+0x1bc/0x210
[ 9970.272610]  [<ffffffff81105807>] cpuset_mems_allowed+0x27/0x140
[ 9970.344584]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150
[ 9970.409282]  [<ffffffff811b1385>] __mpol_dup+0xe5/0x150
[ 9970.471897]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150
[ 9970.536585]  [<ffffffff81068c86>] ? copy_process.part.23+0x606/0x1d40
[ 9970.613763]  [<ffffffff810bf28d>] ? trace_hardirqs_on+0xd/0x10
[ 9970.683660]  [<ffffffff810ddddf>] ? monotonic_to_bootbased+0x2f/0x50
[ 9970.759795]  [<ffffffff81068cf0>] copy_process.part.23+0x670/0x1d40
[ 9970.834885]  [<ffffffff8106a598>] do_fork+0xd8/0x380
[ 9970.894375]  [<ffffffff81110e4c>] ? __audit_syscall_entry+0x9c/0xf0
[ 9970.969470]  [<ffffffff8106a8c6>] SyS_clone+0x16/0x20
[ 9971.030011]  [<ffffffff81642009>] stub_clone+0x69/0x90
[ 9971.091573]  [<ffffffff81641c29>] ? system_call_fastpath+0x16/0x1b

The cause is that cpuset_mems_allowed() try to take
mutex_lock(&callback_mutex) under the rcu_read_lock(which was hold in
__mpol_dup()). And in cpuset_mems_allowed(), the access to cpuset is
under rcu_read_lock, so in __mpol_dup, we can reduce the rcu_read_lock
protection region to protect the access to cpuset only in
current_cpuset_is_being_rebound(). So that we can avoid this bug.

This patch is a temporary solution that just addresses the bug
mentioned above, can not fix the long-standing issue about cpuset.mems
rebinding on fork():

"When the forker's task_struct is duplicated (which includes
 ->mems_allowed) and it races with an update to cpuset_being_rebound
 in update_tasks_nodemask() then the task's mems_allowed doesn't get
 updated. And the child task's mems_allowed can be wrong if the
 cpuset's nodemask changes before the child has been added to the
 cgroup's tasklist."

Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoworkqueue: fix dev_set_uevent_suppress() imbalance
Maxime Bizon [Mon, 23 Jun 2014 14:35:35 +0000 (16:35 +0200)]
workqueue: fix dev_set_uevent_suppress() imbalance

commit bddbceb688c6d0decaabc7884fede319d02f96c8 upstream.

Uevents are suppressed during attributes registration, but never
restored, so kobject_uevent() does nothing.

Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: 226223ab3c4118ddd10688cc2c131135848371ab
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoparisc,metag: Do not hardcode maximum userspace stack size
Helge Deller [Wed, 30 Apr 2014 21:26:02 +0000 (23:26 +0200)]
parisc,metag: Do not hardcode maximum userspace stack size

commit 042d27acb64924a0e8a43e972485913a32407beb upstream.

This patch affects only architectures where the stack grows upwards
(currently parisc and metag only). On those do not hardcode the maximum
initial stack size to 1GB for 32-bit processes, but make it configurable
via a config option.

The main problem with the hardcoded stack size is, that we have two
memory regions which grow upwards: stack and heap. To keep most of the
memory available for heap in a flexmap memory layout, it makes no sense
to hard allocate up to 1GB of the memory for stack which can't be used
as heap then.

This patch makes the stack size for 32-bit processes configurable and
uses 80MB as default value which has been in use during the last few
years on parisc and which hasn't showed any problems yet.

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoparisc: fix fanotify_mark() syscall on 32bit compat kernel
Helge Deller [Thu, 10 Jul 2014 16:07:17 +0000 (18:07 +0200)]
parisc: fix fanotify_mark() syscall on 32bit compat kernel

commit ab8a261ba5e2dd9206da640de5870cc31d568a7c upstream.

On parisc we can not use the existing compat implementation for fanotify_mark()
because for the 64bit mask parameter the higher and lower 32bits are ordered
differently than what the compat function expects from big endian
architectures.

Specifically:
It finally turned out, that on hppa we end up with different assignments
of parameters to kernel arguments depending on if we call the glibc
wrapper function
 int fanotify_mark (int __fanotify_fd, unsigned int __flags,
                    uint64_t __mask, int __dfd, const char *__pathname);
or directly calling the syscall manually
 syscall(__NR_fanotify_mark, ...)

Reason is, that the syscall() function is implemented as C-function and
because we now have the sysno as first parameter in front of the other
parameters the compiler will unexpectedly add an empty paramenter in
front of the u64 value to ensure the correct calling alignment for 64bit
values.
This means, on hppa you can't simply use syscall() to call the kernel
fanotify_mark() function directly, but you have to use the glibc
function instead.

This patch fixes the kernel in the hppa-arch specifc coding to adjust
the parameters in a way as if userspace calls the glibc wrapper function
fanotify_mark().

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoparisc: add serial ports of C8000/1GHz machine to hardware database
Helge Deller [Sat, 28 Jun 2014 15:44:51 +0000 (17:44 +0200)]
parisc: add serial ports of C8000/1GHz machine to hardware database

commit eadcc7208a2237016be7bdff4551ba7614da85c8 upstream.

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoiio: ti_am335x_adc: Fix: Use same step id at FIFOs both ends
Jan Kardell [Thu, 6 Nov 2014 22:18:00 +0000 (22:18 +0000)]
iio: ti_am335x_adc: Fix: Use same step id at FIFOs both ends

commit baa3c65298c089a9014b4e523a14ec2885cca1bc upstream.

Since AI lines could be selected at will (linux-3.11) the sending
and receiving ends of the FIFO does not agree about what step is used
for a line. It only works if the last lines are used, like 5,6,7,
and fails if ie 2,4,6 is selected in DT.

Signed-off-by: Jan Kardell <jan.kardell@telliq.com>
Tested-by: Zubair Lutfullah <zubair.lutfullah@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 years agoUSB: serial: ftdi_sio: Add Infineon Triboard
Michal Sojka [Thu, 10 Jul 2014 12:00:34 +0000 (14:00 +0200)]
USB: serial: ftdi_sio: Add Infineon Triboard

commit d8279a40e50ad55539780aa617a32a53d7f0953e upstream.

This adds support for Infineon TriBoard TC1798 [1]. Only interface 1
is used as serial line (see [2], Figure 8-6).

[1] http://www.infineon.com/cms/de/product/microcontroller/development-tools-software-and-kits/tricore-tm-development-tools-software-and-kits/starterkits-and-evaluation-boards/starter-kit-tc1798/channel.html?channel=db3a304333b8a7ca0133cfa3d73e4268
[2] http://www.infineon.com/dgdl/TriBoardManual-TC1798-V10.pdf?folderId=db3a304412b407950112b409ae7c0343&fileId=db3a304333b8a7ca0133cfae99fe426a

Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>