linux-toradex.git/drivers/base, branch v3.14.16

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

topology: Fix compilation warning when not in SMP

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

commit 53974e06603977f348ed978d75c426b0532daa67 upstream.

The topology_##name() macro does not use its argument when CONFIG_SMP is not
set, as it ultimately calls the cpu_data() macro.

So we avoid maintaining a possibly unused `cpu' variable, to avoid the
following compilation warning:

  drivers/base/topology.c: In function ‘show_physical_package_id’:
  drivers/base/topology.c:103:118: warning: unused variable ‘cpu’ [-Wunused-variable]
   define_id_show_func(physical_package_id);

  drivers/base/topology.c: In function ‘show_core_id’:
  drivers/base/topology.c:106:106: warning: unused variable ‘cpu’ [-Wunused-variable]
   define_id_show_func(core_id);

This can be seen with e.g. x86 defconfig and CONFIG_SMP not set.

Signed-off-by: Vincent Stehlé 
Signed-off-by: Greg Kroah-Hartman

of/irq: do irq resolution in platform_get_irq

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

commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef upstream.

Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux@48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)

This is because we're wrongly trying to populate resources that are not
yet available. It's perfectly valid to create irqchips dynamically, so
let's fix up the issue by resolving the interrupt resources when
platform_get_irq is called.

And then we also need to accept the fact that some irqdomains do not
exist that early on, and only get initialized later on. So we can
make the current WARN_ON into just into a pr_debug().

We still attempt to populate irq resources when we create the devices.
This allows current drivers which don't use platform_get_irq to continue
to function. Once all drivers are fixed, this code can be removed.

Suggested-by: Russell King 
Signed-off-by: Rob Herring 
Signed-off-by: Tony Lindgren 
Tested-by: Tony Lindgren 
Signed-off-by: Grant Likely 
Signed-off-by: Greg Kroah-Hartman

PM / hibernate: Fix restore hang in freeze_processes()

2014-02-26T00:13:15+00:00

During restore, pm_notifier chain are called with
PM_RESTORE_PREPARE.  The firmware_class driver handler
fw_pm_notify does not have a handler for this.  As a result,
it keeps a reader on the kmod.c umhelper_sem.  During
freeze_processes, the call to __usermodehelper_disable tries to
take a write lock on this semaphore and hangs waiting.

Signed-off-by: Sebastian Capella 
Acked-by: Ming Lei 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki

Merge tag 'dma-buf-for-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf

2014-02-17T20:42:45+00:00

Pull dma-buf fix from Sumit Semwal:
 "Just some debugfs output updates.

  There's another patch related to dma-buf, but it'll get upstreamed via
  Greg KH's pull request"

* tag 'dma-buf-for-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf:
  dma-buf: update debugfs output

dma-buf: update debugfs output

2014-02-13T04:38:52+00:00

Russell King observed 'wierd' looking output from debugfs, and also suggested
better ways of getting device names (use KBUILD_MODNAME, dev_name())

This patch addresses these issues to make the debugfs output correct and better
looking.

While at it, replace seq_printf with seq_puts to remove the checkpatch.pl
warnings.

Reported-by: Russell King - ARM Linux 
Signed-off-by: Sumit Semwal

drivers/base: fix devres handling for master device

2014-02-08T00:45:14+00:00

We weren't handling the devres issues for the master device failing a
bind, or being unbound properly.  Add a devres group to contain these,
and release the resources at the appropriate points.

Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman