linux-stable.git/drivers, branch v4.4.9

extcon: max77843: Use correct size for reading the interrupt register

2016-05-04T21:48:54+00:00

commit c4924e92442d7218bd725e47fa3988c73aae84c9 upstream.

The info->status[] array has 3 elements.  We are using size
MAX77843_MUIC_IRQ_NUM (16) instead of MAX77843_MUIC_STATUS_NUM (3) as
intended.

Fixes: 135d9f7d135a ('extcon: max77843: Clear IRQ bits state before request IRQ')
Signed-off-by: Dan Carpenter 
Reviewed-by: Jaewon Kim 
Reviewed-by: Krzysztof Kozlowski 
[cw00.choi: Modify the patch title]
Signed-off-by: Chanwoo Choi 
Signed-off-by: Greg Kroah-Hartman

stm class: Select CONFIG_SRCU

2016-05-04T21:48:54+00:00

commit 042d4460b5b4379a12f375045ff9065cf6758735 upstream.

The newly added STM code uses SRCU, but does not ensure that
this code is part of the kernel:

drivers/built-in.o: In function `stm_source_link_show':
include/linux/srcu.h:221: undefined reference to `__srcu_read_lock'
include/linux/srcu.h:238: undefined reference to `__srcu_read_unlock'
drivers/built-in.o: In function `stm_source_link_drop':
include/linux/srcu.h:221: undefined reference to `__srcu_read_lock'
include/linux/srcu.h:238: undefined reference to `__srcu_read_unlock'

This adds a Kconfig 'select' statement like all the other SRCU using
drivers have.

Signed-off-by: Arnd Bergmann 
Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices")
Signed-off-by: Alexander Shishkin 
Signed-off-by: Greg Kroah-Hartman

megaraid_sas: add missing curly braces in ioctl handler

2016-05-04T21:48:54+00:00

commit 3deb9438d34a09f6796639b652a01d110aca9f75 upstream.

gcc-6 found a dubious indentation in the megasas_mgmt_fw_ioctl
function:

drivers/scsi/megaraid/megaraid_sas_base.c: In function 'megasas_mgmt_fw_ioctl':
drivers/scsi/megaraid/megaraid_sas_base.c:6658:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
    kbuff_arr[i] = NULL;
    ^~~~~~~~~
drivers/scsi/megaraid/megaraid_sas_base.c:6653:3: note: ...this 'if' clause, but it is not
   if (kbuff_arr[i])
   ^~

The code is actually correct, as there is no downside in clearing a NULL
pointer again.

This clarifies the code and avoids the warning by adding extra curly
braces.

Signed-off-by: Arnd Bergmann 
Fixes: 90dc9d98f01b ("megaraid_sas : MFI MPT linked list corruption fix")
Reviewed-by: Hannes Reinecke 
Acked-by: Sumit Saxena 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

thermal: rockchip: fix a impossible condition caused by the warning

2016-05-04T21:48:54+00:00

commit 43b4eb9fe719b107c8e5d49d1edbff0c135a42cb upstream.

As the Dan report the smatch check the thermal driver warning:
drivers/thermal/rockchip_thermal.c:551 rockchip_configure_from_dt()
warn: impossible condition '(thermal->tshut_temp > ((~0 >> 1))) =>
(s32min-s32max > s32max)'

Although The shut_temp read from DT is u32,the temperature is currently
represented as int not long in the thermal driver.
Let's change to make shut_temp instead of the thermal->tshut_temp for
the condition.

Fixes: commit 437df2172e8d
("thermal: rockchip: consistently use int for temperatures")

Reported-by: Dan Carpenter 
Signed-off-by: Caesar Wang 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Greg Kroah-Hartman

jme: Fix device PM wakeup API usage

2016-05-04T21:48:54+00:00

commit 81422e672f8181d7ad1ee6c60c723aac649f538f upstream.

According to Documentation/power/devices.txt

The driver should not use device_set_wakeup_enable() which is the policy
for user to decide.

Using device_init_wakeup() to initialize dev->power.should_wakeup and
dev->power.can_wakeup on driver initialization.

And use device_may_wakeup() on suspend to decide if WoL function should
be enabled on NIC.

Reported-by: Diego Viola 
Signed-off-by: Guo-Fu Tseng 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

jme: Do not enable NIC WoL functions on S0

2016-05-04T21:48:54+00:00

commit 0772a99b818079e628a1da122ac7ee023faed83e upstream.

Otherwise it might be back on resume right after going to suspend in
some hardware.

Reported-by: Diego Viola 
Signed-off-by: Guo-Fu Tseng 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bus: imx-weim: Take the 'status' property value into account

2016-05-04T21:48:54+00:00

commit 33b96d2c9579213cf3f36d7b29841b1e464750c4 upstream.

Currently we have an incorrect behaviour when multiple devices
are present under the weim node. For example:

&weim {
	...
	status = "okay";

	sram@0,0 {
		...
        	status = "okay";
	};

	mram@0,0 {
		...
        	status = "disabled";
    	};
};

In this case only the 'sram' device should be probed and not 'mram'.

However what happens currently is that the status variable is ignored,
causing the 'sram' device to be disabled and 'mram' to be enabled.

Change the weim_parse_dt() function to use
for_each_available_child_of_node()so that the devices marked with
'status = disabled' are not probed.

Suggested-by: Wolfgang Netbal 
Signed-off-by: Fabio Estevam 
Reviewed-by: Sascha Hauer 
Acked-by: Shawn Guo 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

mtd: nand: Drop mtd.owner requirement in nand_scan

2016-05-04T21:48:52+00:00

commit 20c07a5bf094198ff2382aa5e7c930b3c9807792 upstream.

Since commit 807f16d4db95 ("mtd: core: set some defaults
when dev.parent is set"), it's now legal for drivers
to call nand_scan and nand_scan_ident without setting
mtd.owner.

Drop the check and while at it remove the BUG() abuse.

Fixes: 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set")
Signed-off-by: Ezequiel Garcia 
Acked-by: Boris Brezillon 
[Brian: editorial note - while commit 807f16d4db95 wasn't explicitly
    broken, some follow-up commits in the v4.4 release broke a few
    drivers, since they would hit this BUG() if they used nand_scan()
    and were built as modules]
Signed-off-by: Brian Norris 
Signed-off-by: Greg Kroah-Hartman

mtd: brcmnand: Fix v7.1 register offsets

2016-05-04T21:48:52+00:00

commit d267aefc54a28efc5bda7f009598dc83b5f98734 upstream.

The BRCMNAND controller revision 7.1 is almost 100% compatible with the
previous v6.0 register offset layout, except for the Correctable Error
Reporting Threshold registers. Fix this by adding another table with the
correct offsets for CORR_THRESHOLD and CORR_THRESHOLD_EXT.

Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
Signed-off-by: Florian Fainelli 
Signed-off-by: Brian Norris 
Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: remove micron_quad_enable()

2016-05-04T21:48:52+00:00

commit 3b5394a3ccffbfa1d1d448d48742853a862822c4 upstream.

This patch remove the micron_quad_enable() function which force the Quad
SPI mode. However, once this mode is enabled, the Micron memory expect ALL
commands to use the SPI 4-4-4 protocol. Hence a failure does occur when
calling spi_nor_wait_till_ready() right after the update of the Enhanced
Volatile Configuration Register (EVCR) in the micron_quad_enable() as
the SPI controller driver is not aware about the protocol change.

Since there is almost no performance increase using Fast Read 4-4-4
commands instead of Fast Read 1-1-4 commands, we rather keep on using the
Extended SPI mode than enabling the Quad SPI mode.

Let's take the example of the pretty standard use of 8 dummy cycles during
Fast Read operations on 64KB erase sectors:

Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the
3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles
for the read data; so 131112 clock cycles.

On the other hand the Fast Read 4-4-4 would require 2 cycles for the
command, then 6 cycles for the 3byte address followed by 8 dummy clock
cycles and finally 65536*2 cycles for the read data. So 131088 clock
cycles. The theorical bandwidth increase is 0.0%.

Now using Fast Read operations on 512byte pages:
Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast
Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the
theorical bandwidth increase is 2.3%.
Consecutive reads for non sequential pages is not a relevant use case so
The Quad SPI mode is not worth it.

mtd_speedtest seems to confirm these figures.

Signed-off-by: Cyrille Pitchen 
Fixes: 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR")
Signed-off-by: Brian Norris 
Signed-off-by: Greg Kroah-Hartman