summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)Author
2015-01-14Merge branch 'tg3-net'David S. Miller
Prashant Sreedharan says: ==================== tg3: synchronize_irq() should be called without taking locks v2: Added Reported-by, Tested-by fields and reference to the thread that reported the problem This series addresses the problem reported by Peter Hurley in mail thread https://lkml.org/lkml/2015/1/12/1082 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-14tg3: Release tp->lock before invoking synchronize_irq()Prashant Sreedharan
synchronize_irq() can sleep waiting, for pending IRQ handlers so driver should release the tp->lock spin lock before invoking synchronize_irq() Reported-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Prashant Sreedharan <prashant@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-14tg3: tg3_reset_task() needs to use rtnl_lock to synchronizePrashant Sreedharan
Currently tg3_reset_task() uses only tp->lock for synchronizing with code paths like tg3_open() etc. But since tp->lock is released before doing synchronize_irq(), rtnl_lock should be taken in tg3_reset_task() to synchronize it with other code paths. Reported-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Prashant Sreedharan <prashant@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-14tg3: tg3_timer() should grab tp->lock before checking for tp->irq_syncPrashant Sreedharan
This is to avoid the race between tg3_timer() and the execution paths which does not invoke tg3_timer_stop() and releases tp->lock before calling synchronize_irq() Reported-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Prashant Sreedharan <prashant@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "Two bugfixes for arm64. I will have another pull request next week, but otherwise things are calm" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: arm64: KVM: Fix HCR setting for 32bit guests arm64: KVM: Fix TLB invalidation by IPA/VMID
2015-01-14team: avoid possible underflow of count_pending value for notify_peers and ↵Jiri Pirko
mcast_rejoin This patch is fixing a race condition that may cause setting count_pending to -1, which results in unwanted big bulk of arp messages (in case of "notify peers"). Consider following scenario: count_pending == 2 CPU0 CPU1 team_notify_peers_work atomic_dec_and_test (dec count_pending to 1) schedule_delayed_work team_notify_peers atomic_add (adding 1 to count_pending) team_notify_peers_work atomic_dec_and_test (dec count_pending to 1) schedule_delayed_work team_notify_peers_work atomic_dec_and_test (dec count_pending to 0) schedule_delayed_work team_notify_peers_work atomic_dec_and_test (dec count_pending to -1) Fix this race by using atomic_dec_if_positive - that will prevent count_pending running under 0. Fixes: fc423ff00df3a1955441 ("team: add peer notification") Fixes: 492b200efdd20b8fcfd ("team: add support for sending multicast rejoins") Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "Two small performance tweaks, the plumbing for the execveat system call and a couple of bug fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/uprobes: fix user space PER events s390/bpf: Fix JMP_JGE_X (A > X) and JMP_JGT_X (A >= X) s390/bpf: Fix ALU_NEG (A = -A) s390/mm: avoid using pmd_to_page for !USE_SPLIT_PMD_PTLOCKS s390/timex: fix get_tod_clock_ext() inline assembly s390: wire up execveat syscall s390/kernel: use stnsm 255 instead of stosm 0 s390/vtime: Get rid of redundant WARN_ON s390/zcrypt: kernel oops at insmod of the z90crypt device driver
2015-01-14openvswitch: packet messages need their own probe attribtueThomas Graf
User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow and packet messages. This leads to an out-of-bounds access in ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE > OVS_PACKET_ATTR_MAX. Introduce a new OVS_PACKET_ATTR_PROBE with the same numeric value as OVS_FLOW_ATTR_PROBE to grow the range of accepted packet attributes while maintaining to be binary compatible with existing OVS binaries. Fixes: 05da589 ("openvswitch: Add support for OVS_FLOW_ATTR_PROBE.") Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Tracked-down-by: Florian Westphal <fw@strlen.de> Signed-off-by: Thomas Graf <tgraf@suug.ch> Reviewed-by: Jesse Gross <jesse@nicira.com> Acked-by: Pravin B Shelar <pshelar@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-14i40e: adds FCoE configure optionVasu Dev
Adds FCoE config option I40E_FCOE, so that FCoE can be enabled as needed but otherwise have it disabled by default. This also eliminate multiple FCoE config checks, instead now just one config check for CONFIG_I40E_FCOE. The I40E FCoE was added with 3.17 kernel and therefore this patch shall be applied to stable 3.17 kernel also. CC: <stable@vger.kernel.org> Signed-off-by: Vasu Dev <vasu.dev@intel.com> Tested-by: Jim Young <jamesx.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-14cxgb4vf: Fix queue allocation for 40G adapterHariprasad Shenai
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15Merge tag 'locks-v3.19-1' of git://git.samba.org/jlayton/linuxLinus Torvalds
Pull file locking fix from Jeff Layton: "Just a simple bugfix for a regression that I introduced into v3.18 with the internal lease API overhaul -- mea culpa. Kudos to Linda and Neil for tracking this down and fixing it" * tag 'locks-v3.19-1' of git://git.samba.org/jlayton/linux: locks: fix NULL-deref in generic_delete_lease
2015-01-14netdevice: Add missing parentheses in macroBenjamin Poirier
For example, one could conceivably call for_each_netdev_in_bond_rcu(condition ? bond1 : bond2, slave) and get an unexpected result. Signed-off-by: Benjamin Poirier <bpoirier@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15Merge branch 'for-linus' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull block layer fixes from Jens Axboe: "The major part is an update to the NVMe driver, fixing various issues around surprise removal and hung controllers. Most of that is from Keith, and parts are simple blk-mq fixes or exports/additions of minor functions to aid this effort, and parts are changes directly to the NVMe driver. Apart from the above, this contains: - Small blk-mq change from me, killing an unused member of the hardware queue structure. - Small fix from Ming Lei, fixing up a few drivers that didn't properly check for ERR_PTR() returns from blk_mq_init_queue()" * 'for-linus' of git://git.kernel.dk/linux-block: NVMe: Fix locking on abort handling NVMe: Start and stop h/w queues on reset NVMe: Command abort handling fixes NVMe: Admin queue removal handling NVMe: Reference count admin queue usage NVMe: Start all requests blk-mq: End unstarted requests on a dying queue blk-mq: Allow requests to never expire blk-mq: Add helper to abort requeued requests blk-mq: Let drivers cancel requeue_work blk-mq: Export if requests were started blk-mq: Wake tasks entering queue on dying blk-mq: get rid of ->cmd_size in the hardware queue block: fix checking return value of blk_mq_init_queue block: wake up waiters when a queue is marked dying NVMe: Fix double free irq blk-mq: Export freeze/unfreeze functions blk-mq: Exit queue on alloc failure
2015-01-14bridge: only provide proxy ARP when CONFIG_INET is enabledArnd Bergmann
When IPV4 support is disabled, we cannot call arp_send from the bridge code, which would result in a kernel link error: net/built-in.o: In function `br_handle_frame_finish': :(.text+0x59914): undefined reference to `arp_send' :(.text+0x59a50): undefined reference to `arp_tbl' This makes the newly added proxy ARP support in the bridge code depend on the CONFIG_INET symbol and lets the compiler optimize the code out to avoid the link error. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 958501163ddd ("bridge: Add support for IEEE 802.11 Proxy ARP") Cc: Kyeyoon Park <kyeyoonp@codeaurora.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-14ASoC: wm8904: fix runtime warningBo Shen
Correct the path name for mux to get rid of the following warning: --->8--- wm8904 1-001a: Control not supported for path ADCL -> [Left] -> AIFOUTL wm8904 1-001a: ASoC: no dapm match for ADCL --> Left --> AIFOUTL wm8904 1-001a: ASoC: Failed to add route ADCL -> Left -> AIFOUTL wm8904 1-001a: Control not supported for path ADCR -> [Right] -> AIFOUTL wm8904 1-001a: ASoC: no dapm match for ADCR --> Right --> AIFOUTL wm8904 1-001a: ASoC: Failed to add route ADCR -> Right -> AIFOUTL wm8904 1-001a: Control not supported for path ADCL -> [Left] -> AIFOUTR wm8904 1-001a: ASoC: no dapm match for ADCL --> Left --> AIFOUTR wm8904 1-001a: ASoC: Failed to add route ADCL -> Left -> AIFOUTR wm8904 1-001a: Control not supported for path ADCR -> [Right] -> AIFOUTR wm8904 1-001a: ASoC: no dapm match for ADCR --> Right --> AIFOUTR wm8904 1-001a: ASoC: Failed to add route ADCR -> Right -> AIFOUTR wm8904 1-001a: Control not supported for path AIFINR -> [Right] -> DACL wm8904 1-001a: ASoC: no dapm match for AIFINR --> Right --> DACL wm8904 1-001a: ASoC: Failed to add route AIFINR -> Right -> DACL wm8904 1-001a: Control not supported for path AIFINL -> [Left] -> DACL wm8904 1-001a: ASoC: no dapm match for AIFINL --> Left --> DACL wm8904 1-001a: ASoC: Failed to add route AIFINL -> Left -> DACL wm8904 1-001a: Control not supported for path AIFINR -> [Right] -> DACR wm8904 1-001a: ASoC: no dapm match for AIFINR --> Right --> DACR wm8904 1-001a: ASoC: Failed to add route AIFINR -> Right -> DACR wm8904 1-001a: Control not supported for path AIFINL -> [Left] -> DACR wm8904 1-001a: ASoC: no dapm match for AIFINL --> Left --> DACR wm8904 1-001a: ASoC: Failed to add route AIFINL -> Left -> DACR ---8<--- Signed-off-by: Bo Shen <voice.shen@atmel.com> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-01-14usb: dwc3: gadget: Stop TRB preparation after limit is reachedAmit Virdi
DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This means, the max TRBs that can be submitted for an EP is fixed to 32. Since the request queue for an EP is a linked list, any number of requests can be queued to it by the gadget layer. However, the dwc3 driver must not submit TRBs more than the pool it has created for. This limit wasn't respected when SG was used resulting in submitting more than the max TRBs, eventually leading to non-transfer of the TRBs submitted over the max limit. Root cause: When SG is used, there are two loops iterating to prepare TRBs: - Outer loop over the request_list - Inner loop over the SG list The code was missing break to get out of the outer loop. Fixes: eeb720fb21d6 (usb: dwc3: gadget: add support for SG lists) Cc: <stable@vger.kernel.org> # v3.9+ Signed-off-by: Amit Virdi <amit.virdi@st.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-14usb: dwc3: gadget: Fix TRB preparation during SGAmit Virdi
When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3 request (dwc3_request). So while preparing TRBs, the 'last' flag should be set only when it is the last TRB being prepared from the last dwc3_request entry. The current implementation uses list_is_last to check if the dwc3_request is the last entry from the request_list. However, list_is_last returns false for the last entry too. This is because, while preparing the first TRB from a request, the function dwc3_prepare_one_trb modifies the request's next and prev pointers while moving the URB to req_queued. Hence, list_is_last always returns false no matter what. The correct way is not to access the modified pointers of dwc3_request but to use list_empty macro instead. Fixes: e5ba5ec833aa (usb: dwc3: gadget: fix scatter gather implementation) Signed-off-by: Amit Virdi <amit.virdi@st.com> Cc: <stable@vger.kernel.org> # v3.9+ Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-14ASoC: simple-card: Fix crash in asoc_simple_card_unref()Geert Uytterhoeven
If asoc_simple_card_probe() fails, asoc_simple_card_unref() may be called before dev_set_drvdata(), causing a NULL pointer dereference in asoc_simple_card_unref(): Unable to handle kernel NULL pointer dereference at virtual address 000000d4 ... PC is at asoc_simple_card_unref+0x14/0x48 LR is at asoc_simple_card_probe+0x3d4/0x40c This typically happens because asoc_simple_card_parse_of() returns -EPROBE_DEFER, but other failure modes are possible. devm_snd_soc_register_card()/snd_soc_register_card() may fail either before or after dev_set_drvdata(). Pass a snd_soc_card pointer instead of a platform_device pointer to asoc_simple_card_unref() to fix this. Note that if CONFIG_OF_DYNAMIC=n, of_node_put() is a dummy, and gcc may optimize away the loop over card->dai_link, never actually dereferencing card, and thus avoiding the crash... Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Fixes: e512e001dafa54e5 ("ASoC: simple-card: Fix the reference count of device nodes") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-01-14ASoC: fsl: imx-wm8962: Set the card owner fieldFabio Estevam
The following crash happens when trying to unload the snd_soc_imx_wm8962 module while playback is active: [ 208.666868] Unable to handle kernel paging request at virtc [ 208.674110] pgd = 80004000 [ 208.676867] [7f06541c] *pgd=4c334811, *pte=00000000, *ppte=00000000 [ 208.683211] Internal error: Oops: 80000007 [#1] SMP ARM [ 208.688445] Modules linked in: snd_soc_wm8962 snd_soc_fsl_ssi snd_soc_imx_audmux imx_pcm_fiq evbug] ... In order to avoid such problem, fill the card owner field as suggested by Lars-Peter Clausen: "But looking at the source it seems that this is a core feature of ALSA and at least for the card module itself it will do the ref-counting when a stream is started/stopped. And we even support setting the owner of a card in ASoC. It's just that pretty much no ASoC card driver bothers to set the owner field in the snd_soc_card struct. So this particular problem can be fixed by updating the imx-wm8962 driver to set the owner field." By doing as suggested, we no longer see the crash when attempting to unload the snd_soc_imx_wm8962 module while playback is active: $ modprobe -r snd_soc_imx_wm8962 modprobe: can't unload module snd_soc_imx_wm8962: Resource temporarily unavailable Reported-by: Jiada Wang <jiada_wang@mentor.com> Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-01-14gpio: unregister gpiochip device before removing itJohan Hovold
Unregister gpiochip device (used to export information through sysfs) before removing it internally. This way removal will reverse addition. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14gpio: fix sleep-while-atomic in gpiochip_removeJohan Hovold
Move direct and indirect calls to gpiochip_remove_pin_ranges outside of spin lock as they can end up taking a mutex in pinctrl_remove_gpio_range. Note that the pin ranges are already added outside of the lock. Fixes: 9ef0d6f7628b ("gpiolib: call pin removal in chip removal function") Fixes: f23f1516b675 ("gpiolib: provide provision to register pin ranges") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14gpio: fix memory leak and sleep-while-atomicJohan Hovold
Fix memory leak and sleep-while-atomic in gpiochip_remove. The memory leak was introduced by afa82fab5e13 ("gpio / ACPI: Move event handling registration to gpiolib irqchip helpers") that moved the release of acpi interrupt resources to gpiochip_irqchip_remove, but by then the resources are no longer accessible as the acpi_gpio_chip has already been freed by acpi_gpiochip_remove. Note that this also fixes a few potential sleep-while-atomics, which has been around since 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib") when the call to gpiochip_irqchip_remove while holding a spinlock was added (a couple of irq-domain paths can end up grabbing mutexes). Fixes: afa82fab5e13 ("gpio / ACPI: Move event handling registration to gpiolib irqchip helpers") Fixes: 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14gpio: clean up gpiochip_add error handlingJohan Hovold
Clean up gpiochip_add error handling. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14gpio: fix gpio-chip list corruptionJohan Hovold
Fix potential corruption of gpio-chip list due to failure to remove the chip from the list before returning in gpiochip_add error path. The chip could be long gone when the global list is next traversed, something which could lead to a null-pointer dereference. In the best case (chip not deallocated) we are just leaking the gpio range. Fixes: 14e85c0e69d5 ("gpio: remove gpio_descs global array") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14gpio: fix memory and reference leaks in gpiochip_add error pathJohan Hovold
Memory allocated and references taken by of_gpiochip_add and acpi_gpiochip_add were never released on errors in gpiochip_add (e.g. failure to find free gpio range). Fixes: 391c970c0dd1 ("of/gpio: add default of_xlate function if device has a node pointer") Fixes: 664e3e5ac64c ("gpio / ACPI: register to ACPI events automatically") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14pinctrl: lantiq: remove bogus of_gpio_chip_addJohan Hovold
Remove bogus call to of_gpiochip_add (and of_gpio_chip remove in error path) which is also called when adding the gpio chip. This prevents adding the same pinctrl range twice. Fixes: 3f8c50c9b110 ("OF: pinctrl: MIPS: lantiq: implement lantiq/xway pinctrl support") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14pinctrl: Fix two deadlocksJim Lin
This patch is to fix two deadlock cases. Deadlock 1: CPU #1 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #0 pinctrl_unregister (Holding lock pinctrldev_list_mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) Simply to say CPU#1 is holding lock A and trying to acquire lock B, CPU#0 is holding lock B and trying to acquire lock A. Deadlock 2: CPU #3 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #2 pinctrl_unregister (Holding lock pctldev->mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) CPU #0 tegra_gpio_request (Holding lock pinctrldev_list_mutex) -> pinctrl_get_device_gpio_range (Trying to acquire lock pctldev->mutex) Simply to say CPU#3 is holding lock A and trying to acquire lock D, CPU#2 is holding lock B and trying to acquire lock A, CPU#0 is holding lock D and trying to acquire lock B. Cc: Stable <stable@vger.kernel.org> Signed-off-by: Jim Lin <jilin@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14pinctrl: rockchip: Avoid losing interrupts when supporting both edgesDoug Anderson
I was seeing cases where I was losing interrupts when inserting and removing SD cards. Sometimes the card would get "stuck" in the inserted state. I believe that the problem was related to the code to handle the case where we needed both rising and falling edges. This code would disable the interrupt as the polarity was switched. If an interrupt came at the wrong time it could be lost. We'll match what the gpio-dwapb.c driver does upstream and change the interrupt polarity without disabling things. Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14gpio: crystalcove: use handle_nested_irqAaron Lu
The CrystalCove GPIO chip has can_sleep set so its demultiplexed irqs will have IRQ_NESTED_THREAD flag set, thus we should use the nested version handle_nested_irq in CrystalCove's irq handler instead of handle_generic_irq, or the following warning will be hit and the functionality is lost: [ 4089.639554] Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.313 08/13/2014 [ 4089.639564] 00000002 00000000 c24fbdf4 c16e0257 c24fbe38 c24fbe28 c105390c c18ec480 [ 4089.639596] c24fbe54 00000048 c18f8e3b 00000295 c10a60fc 00000295 c10a60fc f4464540 [ 4089.639626] f446459c c278ad40 c24fbe40 c1053974 00000009 c24fbe38 c18ec480 c24fbe54 [ 4089.639656] Call Trace: [ 4089.639685] [<c16e0257>] dump_stack+0x41/0x52 [ 4089.639707] [<c105390c>] warn_slowpath_common+0x8c/0xc0 [ 4089.639727] [<c10a60fc>] ? irq_nested_primary_handler+0x2c/0x30 [ 4089.639744] [<c10a60fc>] ? irq_nested_primary_handler+0x2c/0x30 [ 4089.639763] [<c1053974>] warn_slowpath_fmt+0x34/0x40 [ 4089.639781] [<c10a60fc>] irq_nested_primary_handler+0x2c/0x30 [ 4089.639800] [<c10a5c56>] handle_irq_event_percpu+0x76/0x190 [ 4089.639818] [<c1461570>] ? regmap_format_10_14_write+0x30/0x30 [ 4089.639836] [<c1464f4c>] ? _regmap_bus_raw_write+0x4c/0x70 [ 4089.639854] [<c10a5da1>] handle_irq_event+0x31/0x50 [ 4089.639872] [<c10a83eb>] handle_simple_irq+0x4b/0x70 [ 4089.639889] [<c10a5384>] generic_handle_irq+0x24/0x40 [ 4089.639908] [<c1366d87>] crystalcove_gpio_irq_handler+0xa7/0xc0 [ 4089.639927] [<c10a85a7>] handle_nested_irq+0x77/0x190 [ 4089.639947] [<c1469801>] regmap_irq_thread+0x1b1/0x360 [ 4089.639966] [<c10a6ae8>] irq_thread_fn+0x18/0x30 [ 4089.639983] [<c10a6906>] irq_thread+0xf6/0x110 [ 4089.640001] [<c10a6ad0>] ? irq_finalize_oneshot.part.30+0x1b0/0x1b0 [ 4089.640019] [<c10a6b50>] ? irq_forced_thread_fn+0x50/0x50 [ 4089.640037] [<c10a6810>] ? irq_thread_check_affinity+0xc0/0xc0 [ 4089.640054] [<c106f389>] kthread+0xa9/0xc0 [ 4089.640074] [<c16e6401>] ret_from_kernel_thread+0x21/0x30 [ 4089.640091] [<c106f2e0>] ? kthread_create_on_node+0x110/0x110 [ 4089.640105] ---[ end trace dca7946ad31eba7d ]--- Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=90521 Reported-and-tested-by: Brian Loften <bloften80@gmail.com> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14mmc: sdhci: Set SDHCI_POWER_ON with external vmmcTim Kryger
Host controllers lacking the required internal vmmc regulator may still follow the spec with regard to the LSB of SDHCI_POWER_CONTROL. Set the SDHCI_POWER_ON bit when vmmc is enabled to encourage the controller to to drive CMD, DAT, SDCLK. This fixes a regression observed on some Qualcomm and Nvidia boards caused by 5222161 mmc: sdhci: Improve external VDD regulator support. Fixes: 52221610dd84 (mmc: sdhci: Improve external VDD regulator support) Signed-off-by: Tim Kryger <tim.kryger@gmail.com> Tested-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-01-14Merge branch 'fixes' of ↵Zhang Rui
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal into thermal-soc
2015-01-14neighbour: fix base_reachable_time(_ms) not effective immediatly when changedJean-Francois Remy
When setting base_reachable_time or base_reachable_time_ms on a specific interface through sysctl or netlink, the reachable_time value is not updated. This means that neighbour entries will continue to be updated using the old value until it is recomputed in neigh_period_work (which recomputes the value every 300*HZ). On systems with HZ equal to 1000 for instance, it means 5mins before the change is effective. This patch changes this behavior by recomputing reachable_time after each set on base_reachable_time or base_reachable_time_ms. The new value will become effective the next time the neighbour's timer is triggered. Changes are made in two places: the netlink code for set and the sysctl handling code. For sysctl, I use a proc_handler. The ipv6 network code does provide its own handler but it already refreshes reachable_time correctly so it's not an issue. Any other user of neighbour which provide its own handlers must refresh reachable_time. Signed-off-by: Jean-Francois Remy <jeff@melix.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-14net: fec: fix MDIO bus assignement for dual fec SoC'sStefan Agner
On i.MX28, the MDIO bus is shared between the two FEC instances. The driver makes sure that the second FEC uses the MDIO bus of the first FEC. This is done conditionally if FEC_QUIRK_ENET_MAC is set. However, in newer designs, such as Vybrid or i.MX6SX, each FEC MAC has its own MDIO bus. Simply removing the quirk FEC_QUIRK_ENET_MAC is not an option since other logic, triggered by this quirk, is still needed. Furthermore, there are board designs which use the same MDIO bus for both PHY's even though the second bus would be available on the SoC side. Such layout are popular since it saves pins on SoC side. Due to the above quirk, those boards currently do work fine. The boards in the mainline tree with such a layout are: - Freescale Vybrid Tower with TWR-SER2 (vf610-twr.dts) - Freescale i.MX6 SoloX SDB Board (imx6sx-sdb.dts) This patch adds a new quirk FEC_QUIRK_SINGLE_MDIO for i.MX28, which makes sure that the MDIO bus of the first FEC is used in any case. However, the boards above do have a SoC with a MDIO bus for each FEC instance. But the PHY's are not connected in a 1:1 configuration. A proper device tree description is needed to allow the driver to figure out where to find its PHY. This patch fixes that shortcoming by adding a MDIO bus child node to the first FEC instance, along with the two PHY's on that bus, and making use of the phy-handle property to add a reference to the PHY's. Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-14Merge branch 'leds-fixes-for-3.19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED fix from Bryan Wu. * 'leds-fixes-for-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: leds: netxbig: fix oops at probe time
2015-01-14Merge tag 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux Pull WRITE_ONCE argument order change from Christian Borntraeger: "As discussed on LKML[1] it was agreed that WRITE_ONCE(x, val) is better than ASSIGN_ONCE(val, x) Lets change that for 3.19 as 3.19 has no user yet, but the first users will hit linux-next soon" [1] http://marc.info/?l=linux-kernel&m=142081181707596 * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux: kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)
2015-01-13xen-netfront: use different locks for Rx and Tx statsDavid Vrabel
In netfront the Rx and Tx path are independent and use different locks. The Tx lock is held with hard irqs disabled, but Rx lock is held with only BH disabled. Since both sides use the same stats lock, a deadlock may occur. [ INFO: possible irq lock inversion dependency detected ] 3.16.2 #16 Not tainted --------------------------------------------------------- swapper/0/0 just changed the state of lock: (&(&queue->tx_lock)->rlock){-.....}, at: [<c03adec8>] xennet_tx_interrupt+0x14/0x34 but this lock took another, HARDIRQ-unsafe lock in the past: (&stat->syncp.seq#2){+.-...} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&stat->syncp.seq#2); local_irq_disable(); lock(&(&queue->tx_lock)->rlock); lock(&stat->syncp.seq#2); <Interrupt> lock(&(&queue->tx_lock)->rlock); Using separate locks for the Rx and Tx stats fixes this deadlock. Reported-by: Dmitry Piotrovsky <piotrovskydmitry@gmail.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-13drivers: net: cpsw: fix multicast flush in dual emac modeMugunthan V N
Since ALE table is a common resource for both the interfaces in Dual EMAC mode and while bringing up the second interface in cpsw_ndo_set_rx_mode() all the multicast entries added by the first interface is flushed out and only second interface multicast addresses are added. Fixing this by flushing multicast addresses based on dual EMAC port vlans which will not affect the other emac port multicast addresses. Fixes: d9ba8f9 (driver: net: ethernet: cpsw: dual emac interface implementation) Cc: <stable@vger.kernel.org> # v3.9+ Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-13leds: netxbig: fix oops at probe timeSimon Guinot
This patch fixes a NULL pointer dereference on led_dat->mode_val. Due to this bug, a kernel oops can be observed at probe time on the LaCie 2Big and 5Big v2 boards: Unable to handle kernel NULL pointer dereference at virtual address 00000008 [...] [<c03f244c>] (netxbig_led_probe) from [<c02c8c6c>] (platform_drv_probe+0x4c/0x9c) [<c02c8c6c>] (platform_drv_probe) from [<c02c72d0>] (driver_probe_device+0x98/0x25c) [<c02c72d0>] (driver_probe_device) from [<c02c7520>] (__driver_attach+0x8c/0x90) [<c02c7520>] (__driver_attach) from [<c02c5c24>] (bus_for_each_dev+0x68/0x94) [<c02c5c24>] (bus_for_each_dev) from [<c02c6408>] (bus_add_driver+0x124/0x1dc) [<c02c6408>] (bus_add_driver) from [<c02c7ac0>] (driver_register+0x78/0xf8) [<c02c7ac0>] (driver_register) from [<c000888c>] (do_one_initcall+0x80/0x1cc) [<c000888c>] (do_one_initcall) from [<c0733618>] (kernel_init_freeable+0xe4/0x1b4) [<c0733618>] (kernel_init_freeable) from [<c058db9c>] (kernel_init+0xc/0xec) [<c058db9c>] (kernel_init) from [<c0009850>] (ret_from_fork+0x14/0x24) [...] This bug was introduced by commit 588a6a99286ae30afb1339d8bc2163517b1b7dd1 ("leds: netxbig: fix attribute-creation race"). Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Cc: <stable@vger.kernel.org> # 3.17+ Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-01-13cxgb4vf: Initialize mdio_addr before using itHariprasad Shenai
In commit 5ad24def21b205a8 ("cxgb4vf: Fix ethtool get_settings for VF driver") mdio_addr of port_info structure was used unininitialzed. Fixing it. Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-13ata: pata_at91: depend on !ARCH_MULTIPLATFORMAlexandre Belloni
Until the driver is corrected to stop using mach/at91isam9_smc.h, it won't compile in a ARCH_MULTIPLATFORM configuration. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2015-01-13devicetree: document the "qemu" and "virtio" vendor prefixesLaszlo Ersek
The QEMU open source machine emulator and virtualizer presents firmware and operating systems running in virtual machines ("guests") with purely virtual hardware (ie. hardware that has never existed in physical form). Since QEMU exposes some of these devices in a DTB, it makes sense to define "qemu" and "virtio" as vendor prefixes. The qemu definition is from [1], revision 4451 (22:24, 25 November 2014). The virtio definition is composed from [2] and [3]. [1] http://wiki.qemu.org/Main_Page [2] http://docs.oasis-open.org/virtio/virtio/v1.0/csprd01/virtio-v1.0-csprd01.html [3] http://en.wikipedia.org/wiki/OASIS_%28organization%29 Suggested-by: Mark Rutland <mark.rutland@arm.com> Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rob Herring <robh@kernel.org>
2015-01-13devicetree: document ARM bindings for QEMU's Firmware Config interfaceLaszlo Ersek
Peter Maydell suggested that we describe new devices / DTB nodes in the kernel Documentation tree that we expose to arm "virt" guests in QEMU. Although the kernel is not required to access the fw_cfg interface, "Documentation/devicetree/bindings/arm" is probably the best central spot to keep the fw_cfg description in. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rob Herring <robh@kernel.org>
2015-01-13Documentation: of: fix typo in graph bindingsKaixu Xia
Just fix a minor typo about the example path. Signed-off-by: Kaixu Xia <xiakaixu@huawei.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Rob Herring <robh@kernel.org>
2015-01-13dma-mapping: fix debug print to display correct dma_pfn_offsetMurali Karicheri
fix the dev_dbg to display the offset which is the calculated dma_pfn_offset value and set later in the code. Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Rob Herring <robh@kernel.org>
2015-01-13of: replace Asahi Kasei Corp vendor prefixKuninori Morimoto
Current vendor-prefixes.txt already has "ak" prefix for Asahi Kasei Corp by ae8c4209af2c(of: Add vendor prefix for Asahi Kasei Corp.) It went through the appropriate review process. But, almost all Asahi Kasei chip drivers are using "asahi-kasei" prefix today. (arch/arm/boot/dts/tegra20-seaboard.dts only is using "ak,ak8975", but there are instances of "asahi-kasei,ak8975" in other dts files. And drivers/iio/magnetometer/ak8975.c doesn't support "ak,ak8975" prefix) So, we made a mistake there. In addition, checkpatch.pl reports WARNING if it is using "asahi-kasei" prerfix in DT file. (DT compatible string vendor "asahi-kasei" appears un-documented) Marking it deprecated and warning with checkpatch is certainly preferable. So, this patch replace "ak" to "asahi-kasei" in vendor-prefixes.txt. (and fixup tegra20-seaboard) OTOH, Asahi Kasei is usually referred to as "AKM", but this patch doesn't care about it. Because no DT is using that today. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Rob Herring <robh@kernel.org>
2015-01-13ARM: dt: GIC: Spelling s/specific/specifier/, s/flaggs/flags/Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Stephen Warren <swarren@nvidia.com> Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
2015-01-13dt/bindings: arm-boards: Spelling s/pointong/pointing/Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
2015-01-13MAINTAINERS: Update DT website and git repositoryRob Herring
Per Grant, secretlab.ca is defunct and he has moved his tree to kernel.org so update the DT website and git tree. devicetree.org needs work, but is better than "Internal Server Error" that secretlab.ca returns. Cc: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
2015-01-13MAINTAINERS: drop DT regex matching on of_get_property and of_match_tableRob Herring
The regex matching on of_get_property and of_match_table cause Grant and me to be copied on loads of drivers as well as be listed as maintainers of those drivers. I believe the intent here was to check for documenting of properties, but that has proven horribly ineffective. checkpatch now at least partially covers this checking compatible strings. So remove these regex's to reduce the firehose somewhat. Cc: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
2015-01-13kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)Christian Borntraeger
Feedback has shown that WRITE_ONCE(x, val) is easier to use than ASSIGN_ONCE(val,x). There are no in-tree users yet, so lets change it for 3.19. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Davidlohr Bueso <dave@stgolabs.net> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2025-03-17 17:23:13 +0000