linux-stable.git/drivers/base, branch v3.14.23

firmware_class: make sure fw requests contain a name

2014-10-30T16:38:20+00:00

commit 471b095dfe0d693a8d624cbc716d1ee4d74eb437 upstream.

An empty firmware request name will trigger warnings when building
device names. Make sure this is caught earlier and rejected.

The warning was visible via the test_firmware.ko module interface:

echo -ne "\x00" > /sys/devices/virtual/misc/test_firmware/trigger_request

Reported-by: Sasha Levin 
Signed-off-by: Kees Cook 
Tested-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

regmap: fix possible ZERO_SIZE_PTR pointer dereferencing error.

2014-10-30T16:38:20+00:00

commit d6b41cb06044a7d895db82bdd54f6e4219970510 upstream.

Since we cannot make sure the 'val_count' will always be none zero
here, and then if it equals to zero, the kmemdup() will return
ZERO_SIZE_PTR, which equals to ((void *)16).

So this patch fix this with just doing the zero check before calling
kmemdup().

Signed-off-by: Xiubo Li 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: fix NULL pointer dereference in _regmap_write/read

2014-10-30T16:38:20+00:00

commit 5336be8416a71b5568d2cf54a2f2066abe9f2a53 upstream.

If LOG_DEVICE is defined and map->dev is NULL it will lead to NULL
pointer dereference. This patch fixes this issue by adding check for
dev->NULL in all such places in regmap.c

Signed-off-by: Pankaj Dubey 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: debugfs: fix possbile NULL pointer dereference

2014-10-30T16:38:20+00:00

commit 2c98e0c1cc6b8e86f1978286c3d4e0769ee9d733 upstream.

If 'map->dev' is NULL and there will lead dev_name() to be NULL pointer
dereference. So before dev_name(), we need to have check of the map->dev
pionter.

We also should make sure that the 'name' pointer shouldn't be NULL for
debugfs_create_dir(). So here using one default "dummy" debugfs name when
the 'name' pointer and 'map->dev' are both NULL.

Signed-off-by: Xiubo Li 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: Don't attempt block writes when syncing cache on single_rw devices

2014-10-05T21:52:17+00:00

commit 5c1ebe7f73f9166893c3459915db8a09d6d1d715 upstream.

If the device can't support block writes then don't attempt to use raw
syncing which will automatically generate block writes for adjacent
registers, use the existing _single() block syncing implementation.

Reported-by: Jarkko Nikula 
Tested-by: Jarkko Nikula 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: Fix handling of volatile registers for format_write() chips

2014-10-05T21:52:17+00:00

commit 5844a8b9d98ec11ce1d77610daacf3f0a0e14715 upstream.

A previous over-zealous factorisation of code means that we only treat
registers as volatile if they are readable. For most devices this is fine
since normally most registers can be read and volatility implies
readability but for format_write() devices where there is no readback from
the hardware and we use volatility to mean simply uncacheability this means
that we end up treating all registers as cacheble.

A bigger refactoring of the code to clarify this is in order but as a fix
make a minimal change and only check readability when checking volatility
if there is no format_write() operation defined for the device.

Signed-off-by: Mark Brown 
Tested-by: Lars-Peter Clausen 
Signed-off-by: Greg Kroah-Hartman

platform_get_irq: Revert to platform_get_resource if of_irq_get fails

2014-07-31T19:52:57+00:00

commit aff008ad813c7cf3cfe7b532e7ba2c526c136f22 upstream.

Commits 9ec36ca (of/irq: do irq resolution in platform_get_irq)
and ad69674 (of/irq: do irq resolution in platform_get_irq_byname)
change the semantics of platform_get_irq and platform_get_irq_byname
to always rely on devicetree information if devicetree is enabled
and if a devicetree node is attached to the device. The functions
now return an error if the devicetree data does not include interrupt
information, even if the information is available as platform resource
data.

This causes mfd client drivers to fail if the interrupt number is
passed via platform resources. Therefore, if of_irq_get fails, try
platform_get_resource as method of last resort. This restores the
original functionality for drivers depending on platform resources
to get irq information.

Cc: Russell King 
Cc: Tony Lindgren 
Cc: Grant Likely 
Cc: Grygorii Strashko 
Signed-off-by: Guenter Roeck 
Acked-by: Rob Herring 
[ Guenter Roeck: backported to 3.15 ]
Signed-off-by: Guenter Roeck

DMA, CMA: fix possible memory leak

2014-07-17T23:21:06+00:00

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 
Acked-by: Zhang Yanfei 
Reviewed-by: Michal Nazarewicz 
Reviewed-by: Aneesh Kumar K.V 
Acked-by: Minchan Kim 
Cc: "Aneesh Kumar K.V" 
Cc: Marek Szyprowski 
Cc: Michal Nazarewicz 
Cc: Paolo Bonzini 
Cc: Gleb Natapov 
Cc: Alexander Graf 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

PM / OPP: fix incorrect OPP count handling in of_init_opp_table

2014-07-01T03:11:59+00:00

commit 086abb58590a4df73e8a6ed71fd418826937cd46 upstream.

In of_init_opp_table function, if a failure to add an OPP is
detected, the count of OPPs, yet to be added is not updated.
Fix this by decrementing this count on failure as well.

Signed-off-by: Chander Kashyap 
Signed-off-by: Inderpal Singh 
Acked-by: Viresh Kumar 
Acked-by: Nishanth Menon 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

drivercore: deferral race condition fix

2014-06-07T17:28:11+00:00

commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 upstream.

When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need for external event to kick the deferred queue to probe
these drivers.

The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
audio support built as modules and using nfsroot for root filesystem.

The following log fragment shows such sequence when all audio modules
were loaded but the sound card is not present since the machine driver has
failed to probe due to missing dependency during it's probe.
The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
machine driver:

...
[   12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
[   12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
[   12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
[   12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
[   12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
[   12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
[   12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
[   13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
[   13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
[   13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
[   13.346755] davinci_mcasp_driver_init: LEAVE
[   13.377446] platform sound.3: Driver davinci_evm requests probe deferral
[   13.592527] platform sound.3: really_probe: probe_count = 0

In the log the machine driver enters it's probe at 12.719969 (this point it
has been removed from the deferred lists). McASP driver already executing
it's probing (since 12.615118).
The machine driver tries to construct the sound card (12.950839) but did
not found one of the components so it fails. After this McASP driver
registers all the ASoC components (the machine driver still in it's probe
function after it failed to construct the card) and the deferred work is
prepared at 13.099026 (note that this time the machine driver is not in the
lists so it is not going to be handled when the work is executing).
Lastly the machine driver exit from it's probe and the core places it to
the deferred list but there will be no other driver going to load and the
deferred queue is not going to be kicked again - till we have external event
like connecting USB stick, etc.

The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers loaded while this last
driver was probing.

This way we can avoid drivers stuck in the deferred queue.

Signed-off-by: Grant Likely 
Reviewed-by: Peter Ujfalusi 
Tested-by: Peter Ujfalusi 
Acked-by: Greg Kroah-Hartman 
Cc: Mark Brown 
Signed-off-by: Greg Kroah-Hartman