aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-01-14usb: dwc3: gadget: Fix TRB preparation during SGAmit Virdi1-2/+1
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 <[email protected]> Cc: <[email protected]> # v3.9+ Signed-off-by: Felipe Balbi <[email protected]>
2015-01-14gpio: unregister gpiochip device before removing itJohan Hovold1-1/+2
Unregister gpiochip device (used to export information through sysfs) before removing it internally. This way removal will reverse addition. Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-01-14gpio: fix sleep-while-atomic in gpiochip_removeJohan Hovold1-3/+1
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 <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-01-14gpio: fix memory leak and sleep-while-atomicJohan Hovold1-1/+2
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 <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-01-14gpio: clean up gpiochip_add error handlingJohan Hovold1-21/+17
Clean up gpiochip_add error handling. Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-01-14gpio: fix gpio-chip list corruptionJohan Hovold1-7/+10
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-01-14gpio: fix memory and reference leaks in gpiochip_add error pathJohan Hovold1-4/+7
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 <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-01-14pinctrl: lantiq: remove bogus of_gpio_chip_addJohan Hovold1-2/+0
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-01-14pinctrl: Fix two deadlocksJim Lin1-2/+3
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 <[email protected]> Signed-off-by: Jim Lin <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-01-14pinctrl: rockchip: Avoid losing interrupts when supporting both edgesDoug Anderson1-25/+20
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 <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-01-14gpio: crystalcove: use handle_nested_irqAaron Lu1-1/+1
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 <[email protected]> Cc: Stable <[email protected]> Signed-off-by: Aaron Lu <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-01-14sched/debug: Print rq->clock_taskPeter Zijlstra1-0/+1
We seem to have forgotten adding it to the debug output like forever... do so now. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2015-01-14sched/core: Rework rq->clock update skipsPeter Zijlstra4-10/+28
The original purpose of rq::skip_clock_update was to avoid 'costly' clock updates for back to back wakeup-preempt pairs. The big problem with it has always been that the rq variable is unaware of the context and causes indiscrimiate clock skips. Rework the entire thing and create a sense of context by only allowing schedule() to skip clock updates. (XXX can we measure the cost of the added store?) By ensuring only schedule can ever skip an update, we guarantee we're never more than 1 tick behind on the update. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-01-14sched/core: Validate rq_clock*() serializationPeter Zijlstra2-1/+8
rq->clock{,_task} are serialized by rq->lock, verify this. One immediate fail is the usage in scale_rt_capability, so 'annotate' that for now, there's more 'funny' there. Maybe change rq->lock into a raw_seqlock_t? (Only 32-bit is affected) Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Cc: Linus Torvalds <[email protected]> Cc: [email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-01-14sched/core: Remove check of p->sched_classYao Dongdong1-6/+6
Search all usage of p->sched_class in sched/core.c, no one check it before use, so it seems that every task must belong to one sched_class. Signed-off-by: Yao Dongdong <[email protected]> [ Moved the early class assignment to make it boot. ] Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-01-14sched/fair: Fix sched_entity::avg::decay_count initializationKirill Tkhai2-1/+3
Child has the same decay_count as parent. If it's not zero, we add it to parent's cfs_rq->removed_load: wake_up_new_task()->set_task_cpu()->migrate_task_rq_fair(). Child's load is a just garbade after copying of parent, it hasn't been on cfs_rq yet, and it must not be added to cfs_rq::removed_load in migrate_task_rq_fair(). The patch moves sched_entity::avg::decay_count intialization in sched_fork(). So, migrate_task_rq_fair() does not change removed_load. Signed-off-by: Kirill Tkhai <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Ben Segall <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/1418644618.6074.13.camel@tkhai Signed-off-by: Ingo Molnar <[email protected]>
2015-01-14sched/debug: Fix potential call to __ffs(0) in sched_show_task()Tetsuo Handa1-2/+3
"struct task_struct"->state is "volatile long" and __ffs() warns that "Undefined if no bit exists, so code should check against 0 first." Therefore, at expression state = p->state ? __ffs(p->state) + 1 : 0; in sched_show_task(), CPU might see "p->state" before "?" as "non-zero" but "p->state" after "?" as "zero", which could result in "state >= sizeof(stat_nam)" being true and bogus '?' is printed. This patch changes "state" from "unsigned int" to "unsigned long" and save "p->state" before calling __ffs(), in order to avoid potential call to __ffs(0). Signed-off-by: Tetsuo Handa <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-01-14sched/debug: Check for stack overflow in ___might_sleep()Eric Sandeen1-0/+3
Sometimes a "BUG: sleeping function called from invalid context" message is not indicative of locking problems, but is the result of a stack overflow corrupting the thread info. Witness http://oss.sgi.com/archives/xfs/2014-02/msg00325.html for example, which took a few go-rounds to sort out. If we're printing the warning, things are wonky already, and it'd be informative to check for the stack end corruption at this point, too. Signed-off-by: Eric Sandeen <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-01-14sched/fair: Fix the dealing with decay_count in __synchronize_entity_decay()Xunlei Pang1-1/+1
In __synchronize_entity_decay(), if "decays" happens to be zero, se->avg.decay_count will not be zeroed, holding the positive value assigned when dequeued last time. This is problematic in the following case: If this runnable task is CFS-balanced to other CPUs soon afterwards, migrate_task_rq_fair() will treat it as a blocked task due to its non-zero decay_count, thereby adding its load to cfs_rq->removed_load wrongly. Thus, we must zero se->avg.decay_count in this case as well. Signed-off-by: Xunlei Pang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Ben Segall <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-01-14mmc: sdhci: Set SDHCI_POWER_ON with external vmmcTim Kryger1-0/+6
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 <[email protected]> Tested-by: Bjorn Andersson <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2015-01-14Merge branch 'fixes' of ↵Zhang Rui6-12/+31
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 Remy1-0/+44
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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-01-14net: fec: fix MDIO bus assignement for dual fec SoC'sStefan Agner4-4/+37
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 <[email protected]> Signed-off-by: Stefan Agner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-01-14Merge branch 'leds-fixes-for-3.19' of ↵Linus Torvalds1-6/+6
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 Torvalds1-6/+6
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 Vrabel1-29/+42
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 <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-01-13drivers: net: cpsw: fix multicast flush in dual emac modeMugunthan V N3-4/+19
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: <[email protected]> # v3.9+ Signed-off-by: Mugunthan V N <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-01-13leds: netxbig: fix oops at probe timeSimon Guinot1-6/+6
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 <[email protected]> Cc: <[email protected]> # 3.17+ Acked-by: Johan Hovold <[email protected]> Signed-off-by: Bryan Wu <[email protected]>
2015-01-13cxgb4vf: Initialize mdio_addr before using itHariprasad Shenai1-0/+2
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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-01-13ata: pata_at91: depend on !ARCH_MULTIPLATFORMAlexandre Belloni1-0/+1
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 <[email protected]> Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2015-01-13devicetree: document the "qemu" and "virtio" vendor prefixesLaszlo Ersek1-0/+2
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 <[email protected]> Suggested-by: Arnd Bergmann <[email protected]> Signed-off-by: Laszlo Ersek <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2015-01-13devicetree: document ARM bindings for QEMU's Firmware Config interfaceLaszlo Ersek1-0/+72
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 <[email protected]> Signed-off-by: Laszlo Ersek <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2015-01-13Documentation: of: fix typo in graph bindingsKaixu Xia1-1/+1
Just fix a minor typo about the example path. Signed-off-by: Kaixu Xia <[email protected]> Acked-by: Philipp Zabel <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2015-01-13dma-mapping: fix debug print to display correct dma_pfn_offsetMurali Karicheri1-1/+1
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 <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2015-01-13of: replace Asahi Kasei Corp vendor prefixKuninori Morimoto2-2/+2
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 <[email protected]> Acked-by: Thierry Reding <[email protected]> Acked-by: Alexandre Courbot <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2015-01-13ARM: dt: GIC: Spelling s/specific/specifier/, s/flaggs/flags/Geert Uytterhoeven1-2/+2
Signed-off-by: Geert Uytterhoeven <[email protected]> Cc: Stephen Warren <[email protected]> Cc: Rob Herring <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2015-01-13dt/bindings: arm-boards: Spelling s/pointong/pointing/Geert Uytterhoeven1-1/+1
Signed-off-by: Geert Uytterhoeven <[email protected]> Cc: Russell King <[email protected]> Cc: Rob Herring <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2015-01-13MAINTAINERS: Update DT website and git repositoryRob Herring1-2/+2
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 <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2015-01-13MAINTAINERS: drop DT regex matching on of_get_property and of_match_tableRob Herring1-3/+1
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 <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2015-01-13kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)Christian Borntraeger1-6/+6
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 <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Acked-by: Davidlohr Bueso <[email protected]> Acked-by: Paul E. McKenney <[email protected]>
2015-01-14Merge tag 'linux-kselftest-3.19-rc-5' of ↵Linus Torvalds3-9/+15
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull kselftest fixes from Shuah Khan: "This update contains three patches to fix one compile error, and two run-time bugs. One of them fixes infinite loop on ARM" * tag 'linux-kselftest-3.19-rc-5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: selftests/vm: fix link error for transhuge-stress test tools: testing: selftests: mq_perf_tests: Fix infinite loop on ARM selftests/exec: allow shell return code of 126
2015-01-14Merge tag 'stable/for-linus-3.19-rc4-tag' of ↵Linus Torvalds5-46/+107
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen bug fixes from David Vrabel: "Several critical linear p2m fixes that prevented some hosts from booting" * tag 'stable/for-linus-3.19-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: x86/xen: properly retrieve NMI reason xen: check for zero sized area when invalidating memory xen: use correct type for physical addresses xen: correct race in alloc_p2m_pmd() xen: correct error for building p2m list on 32 bits x86/xen: avoid freeing static 'name' when kasprintf() fails x86/xen: add extra memory for remapped frames during setup x86/xen: don't count how many PFNs are identity mapped x86/xen: Free bootmem in free_p2m_page() during early boot x86/xen: Remove unnecessary BUG_ON(preemptible()) in xen_setup_timer()
2015-01-13net: Corrected the comment describing the ndo operations to reflect the ↵B Viswanath1-2/+2
actual prototype for couple of operations Corrected the comment describing the ndo operations to reflect the actual prototype for couple of operations Signed-off-by: B Viswanath <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-01-13clk: berlin: bg2q: remove non-exist "smemc" gate clockJisheng Zhang1-1/+0
The "smemc" clock is removed on BG2Q SoCs. In fact, bit19 of clkenable register is for nfc. Current code use bit19 for non-exist "smemc" incorrectly, this prevents eMMC from working due to the sdhci's "core" clk is still gated. Signed-off-by: Jisheng Zhang <[email protected]> Cc: [email protected] # 3.16+ Signed-off-by: Michael Turquette <[email protected]>
2015-01-13clk: at91: keep slow clk enabled to prevent system hangBoris Brezillon1-0/+27
All slow clk users are not properly claiming it (get + prepare + enable) before using it. If all users properly claiming this clock release it, the clock is disabled, but faulty users still depends on it, and the system hangs. This fix prevents the slow clock from being disabled, and should solve the hanging issue, but offending drivers should be patched to properly claim this clock. Signed-off-by: Boris Brezillon <[email protected]> Reported-by: Bo Shen <[email protected]> Cc: [email protected] Signed-off-by: Michael Turquette <[email protected]>
2015-01-14Merge branch 'for-rc' of ↵Linus Torvalds3-16/+13
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal management fixes from Zhang Rui: "Specifics: - Fix a problem that Intel SoC DTS thermal driver does not work when CONFIG_THERMAL_INT340X is not set. - Fix a NULL pointer dereference when processor_thermal_device driver is loaded on a platform without ACPI support" * 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: int340x_thermal/processor_thermal_device: return failure when ACPI/int340x_thermal: enumerate INT3401 for Intel SoC DTS thermal driver ACPI/int340x_thermal: enumerate INT340X devices even if they're not in _ART/_TRT
2015-01-13dmaengine: dw: balance PM runtime callsAndy Shevchenko2-2/+5
In case of PCI driver we will get a warning: dw_dmac_pci 0000:00:18.0: Unbalanced pm_runtime_enable! dw_dmac_pci 0000:00:18.0: DesignWare DMA Controller, 8 channels This happens due to pm_runtime_enable() call from the driver when PM runtime is enabled by core. This patch moves that call to the platform driver where it might make sense. Fixes: bb32baf76e56 (dmaengine: dw: enable runtime PM) Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2015-01-13ahci: Remove Device ID for Intel Sunrise Point PCHJames Ralston1-1/+0
This patch removes a duplicate AHCI-mode SATA Device ID for the Intel Sunrise Point PCH. Signed-off-by: James Ralston <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2015-01-13usb: phy: mv-usb: fix usb_phy build errorsArnd Bergmann1-3/+2
The driver was recently adapted to a core API change, but the change was incomplete, missing out the suspend helper and leaving an extraneous local variable around: usb/phy/phy-mv-usb.c: In function 'mv_otg_update_state': usb/phy/phy-mv-usb.c:341:18: warning: unused variable 'phy' [-Wunused-variable] usb/phy/phy-mv-usb.c: In function 'mv_otg_suspend': usb/phy/phy-mv-usb.c:861:16: error: 'struct usb_phy' has no member named 'state' Signed-off-by: Arnd Bergmann <[email protected]> Fixes: e47d92545c297 ("usb: move the OTG state from the USB PHY to the OTG structure") Signed-off-by: Felipe Balbi <[email protected]>
2015-01-13fbdev/broadsheetfb: fix memory leakColin Ian King1-3/+5
static code analysis from cppcheck reports: [drivers/video/fbdev/broadsheetfb.c:673]: (error) Memory leak: sector_buffer sector_buffer is not being kfree'd on each call to broadsheet_spiflash_rewrite_sector(), so free it. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.