aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* s390/xpram: mark xpram as non-rotationalChristian Borntraeger2013-05-17
| | | | | | | xpram is a memory technology. Lets mark that as non-rotational. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* s390/smp: fix cpu re-scan vs. cpu stateMartin Schwidefsky2013-05-17
| | | | | | | | | | The cpu-info array starts with a list of cpus in configured state, followed by the cpus in standby state. The comparison to decide which state a cpu has is incorrect, this causes configured cpus appear as standby cpus. The correct comparison is the index of the new cpu in the cpu-info array vs. the number of configured cpus. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* s390/cio: add channel ID sysfs attributePeter Oberparleiter2013-05-15
| | | | | | | | | | Add new attributes "chid" and "chid_external" to the channel-path sysfs directory. These attributes contain information related to the channel-ID of the channel-path. Reviewed-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* s390/ftrace: fix mcount adjustmentHeiko Carstens2013-05-15
| | | | | | | | | | | | | | | | | | | | | | | | | Tony Jones reported that the ftrace self tests on s390 do not work: <6>Testing dynamic ftrace ops #1: (0 0 0 0 0) FAILED! <6>Testing tracer irqsoff: <3>failed to start irqsoff tracer <4>.. no entries found ..FAILED! <6>Testing tracer wakeup: <3>failed to start wakeup tracer <4>.. no entries found ..FAILED! <6>Testing tracer function_graph: <4>Failed to init function_graph tracer, init returned -19 <4>FAILED! This happens because we forgot to adjust the instruction pointer that gets passed to the ftrace trace function by MCOUNT_INSN_SIZE. In addition change MCOUNT_INSN_SIZE to the correct value on 31 bit. It only worked so far because the to be patched instruction was identical. Reported-by: Tony Jones <tonyj@suse.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* s390: fix gmap_ipte_notifier vs. software dirty pagesChristian Borntraeger2013-05-15
| | | | | | | | | | | | | | On heavy paging load some guest cpus started to loop in gmap_ipte_notify. This was visible as stalled cpus inside the guest. The gmap_ipte_notifier tries to map a user page and then made sure that the pte is valid and writable. Turns out that with the software change bit tracking the pte can become read-only (and only software writable) if the page is clean. Since we loop in this code, the page would stay clean and, therefore, be never writable again. Let us just use fixup_user_fault, that guarantees to call handle_mm_fault. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* s390: disable pfmf for clear page instructionChristian Borntraeger2013-05-07
| | | | | | | | | | | | | | | Wit the introduction of large pages Linux also used pfmf for page clearing. The current implementation is not ideal, though: - currently we set usage intent=0, but cleared pages are often used directly after the clearing - z/VM does not yet provide EDAT - KVM does have to intercept PFMF even for resident pages Lets just the mvcl loop in all cases until we have a well defined pattern were pfmf is besser. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* s390/disassembler: prevent endless loop in print_fn_code()Heiko Carstens2013-05-07
| | | | | | | | | | | | If the size of the opcode to be printed is larger than "len" we'll see an overflow of an unsigned long value, which means that the while loop within print_fn_code() will loop quite a long time until there is the next chance for an exit. So add an early exit check. Reported-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* s390: remove non existent reference to GENERIC_KERNEL_THREADAlexander Shiyan2013-05-07
| | | | | | Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds2013-05-06
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull networking fixes from David Miller: "Just a small pile of fixes" 1) Fix race conditions in IP fragmentation LRU list handling, from Konstantin Khlebnikov. 2) vfree() is no longer verboten in interrupts, so deferring is pointless, from Al Viro. 3) Conversion from mutex to semaphore in netpoll left trylock test inverted, caught by Dan Carpenter. 4) 3c59x uses wrong base address when releasing regions, from Sergei Shtylyov. 5) Bounds checking in TIPC from Dan Carpenter. 6) Fastopen cookies should not be expired as aggressively as other TCP metrics. From Eric Dumazet. 7) Fix retrieval of MAC address in ibmveth, from Ben Herrenschmidt. 8) Don't use "u16" in virtio user headers, from Stephen Hemminger * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: tipc: potential divide by zero in tipc_link_recv_fragment() tipc: add a bounds check in link_recv_changeover_msg() net/usb: new driver for RTL8152 3c59x: fix freeing nonexistent resource on driver unload netpoll: inverted down_trylock() test rps_dev_flow_table_release(): no need to delay vfree() fib_trie: no need to delay vfree() net: frag, fix race conditions in LRU list maintenance tcp: do not expire TCP fastopen cookies net/eth/ibmveth: Fixup retrieval of MAC address virtio: don't expose u16 in userspace api
| * tipc: potential divide by zero in tipc_link_recv_fragment()Dan Carpenter2013-05-06
| | | | | | | | | | | | | | | | The worry here is that fragm_sz could be zero since it comes from skb->data. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * tipc: add a bounds check in link_recv_changeover_msg()Dan Carpenter2013-05-06
| | | | | | | | | | | | | | | | | | The bearer_id here comes from skb->data and it can be a number from 0 to 7. The problem is that the ->links[] array has only 2 elements so I have added a range check. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net/usb: new driver for RTL8152hayeswang2013-05-06
| | | | | | | | | | | | | | | | Add new driver for supporting Realtek RTL8152 Based USB 2.0 Ethernet Adapters Signed-off-by: Hayes Wang <hayeswang@realtek.com> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * 3c59x: fix freeing nonexistent resource on driver unloadSergei Shtylyov2013-05-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When unloading the driver that drives an EISA board, a message similar to the following one is displayed: Trying to free nonexistent resource <0000000000013000-000000000001301f> Then an user is unable to reload the driver because the resource it requested in the previous load hasn't been freed. This happens most probably due to a typo in vortex_eisa_remove() which calls release_region() with 'dev->base_addr' instead of 'edev->base_addr'... Reported-by: Matthew Whitehead <tedheadster@gmail.com> Tested-by: Matthew Whitehead <tedheadster@gmail.com> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * netpoll: inverted down_trylock() testDan Carpenter2013-05-06
| | | | | | | | | | | | | | The return value is reversed from mutex_trylock(). Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * rps_dev_flow_table_release(): no need to delay vfree()Al Viro2013-05-06
| | | | | | | | | | | | | | | | The same story as with fib_trie patch - vfree() from RCU callbacks is legitimate now. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
| * fib_trie: no need to delay vfree()Al Viro2013-05-06
| | | | | | | | | | | | | | | | | | Now that vfree() can be called from interrupt contexts, there's no need to play games with schedule_work() to escape calling vfree() from RCU callbacks. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: frag, fix race conditions in LRU list maintenanceKonstantin Khlebnikov2013-05-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes race between inet_frag_lru_move() and inet_frag_lru_add() which was introduced in commit 3ef0eb0db4bf92c6d2510fe5c4dc51852746f206 ("net: frag, move LRU list maintenance outside of rwlock") One cpu already added new fragment queue into hash but not into LRU. Other cpu found it in hash and tries to move it to the end of LRU. This leads to NULL pointer dereference inside of list_move_tail(). Another possible race condition is between inet_frag_lru_move() and inet_frag_lru_del(): move can happens after deletion. This patch initializes LRU list head before adding fragment into hash and inet_frag_lru_move() doesn't touches it if it's empty. I saw this kernel oops two times in a couple of days. [119482.128853] BUG: unable to handle kernel NULL pointer dereference at (null) [119482.132693] IP: [<ffffffff812ede89>] __list_del_entry+0x29/0xd0 [119482.136456] PGD 2148f6067 PUD 215ab9067 PMD 0 [119482.140221] Oops: 0000 [#1] SMP [119482.144008] Modules linked in: vfat msdos fat 8021q fuse nfsd auth_rpcgss nfs_acl nfs lockd sunrpc ppp_async ppp_generic bridge slhc stp llc w83627ehf hwmon_vid snd_hda_codec_hdmi snd_hda_codec_realtek kvm_amd k10temp kvm snd_hda_intel snd_hda_codec edac_core radeon snd_hwdep ath9k snd_pcm ath9k_common snd_page_alloc ath9k_hw snd_timer snd soundcore drm_kms_helper ath ttm r8169 mii [119482.152692] CPU 3 [119482.152721] Pid: 20, comm: ksoftirqd/3 Not tainted 3.9.0-zurg-00001-g9f95269 #132 To Be Filled By O.E.M. To Be Filled By O.E.M./RS880D [119482.161478] RIP: 0010:[<ffffffff812ede89>] [<ffffffff812ede89>] __list_del_entry+0x29/0xd0 [119482.166004] RSP: 0018:ffff880216d5db58 EFLAGS: 00010207 [119482.170568] RAX: 0000000000000000 RBX: ffff88020882b9c0 RCX: dead000000200200 [119482.175189] RDX: 0000000000000000 RSI: 0000000000000880 RDI: ffff88020882ba00 [119482.179860] RBP: ffff880216d5db58 R08: ffffffff8155c7f0 R09: 0000000000000014 [119482.184570] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88020882ba00 [119482.189337] R13: ffffffff81c8d780 R14: ffff880204357f00 R15: 00000000000005a0 [119482.194140] FS: 00007f58124dc700(0000) GS:ffff88021fcc0000(0000) knlGS:0000000000000000 [119482.198928] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [119482.203711] CR2: 0000000000000000 CR3: 00000002155f0000 CR4: 00000000000007e0 [119482.208533] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [119482.213371] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [119482.218221] Process ksoftirqd/3 (pid: 20, threadinfo ffff880216d5c000, task ffff880216d3a9a0) [119482.223113] Stack: [119482.228004] ffff880216d5dbd8 ffffffff8155dcda 0000000000000000 ffff000200000001 [119482.233038] ffff8802153c1f00 ffff880000289440 ffff880200000014 ffff88007bc72000 [119482.238083] 00000000000079d5 ffff88007bc72f44 ffffffff00000002 ffff880204357f00 [119482.243090] Call Trace: [119482.248009] [<ffffffff8155dcda>] ip_defrag+0x8fa/0xd10 [119482.252921] [<ffffffff815a8013>] ipv4_conntrack_defrag+0x83/0xe0 [119482.257803] [<ffffffff8154485b>] nf_iterate+0x8b/0xa0 [119482.262658] [<ffffffff8155c7f0>] ? inet_del_offload+0x40/0x40 [119482.267527] [<ffffffff815448e4>] nf_hook_slow+0x74/0x130 [119482.272412] [<ffffffff8155c7f0>] ? inet_del_offload+0x40/0x40 [119482.277302] [<ffffffff8155d068>] ip_rcv+0x268/0x320 [119482.282147] [<ffffffff81519992>] __netif_receive_skb_core+0x612/0x7e0 [119482.286998] [<ffffffff81519b78>] __netif_receive_skb+0x18/0x60 [119482.291826] [<ffffffff8151a650>] process_backlog+0xa0/0x160 [119482.296648] [<ffffffff81519f29>] net_rx_action+0x139/0x220 [119482.301403] [<ffffffff81053707>] __do_softirq+0xe7/0x220 [119482.306103] [<ffffffff81053868>] run_ksoftirqd+0x28/0x40 [119482.310809] [<ffffffff81074f5f>] smpboot_thread_fn+0xff/0x1a0 [119482.315515] [<ffffffff81074e60>] ? lg_local_lock_cpu+0x40/0x40 [119482.320219] [<ffffffff8106d870>] kthread+0xc0/0xd0 [119482.324858] [<ffffffff8106d7b0>] ? insert_kthread_work+0x40/0x40 [119482.329460] [<ffffffff816c32dc>] ret_from_fork+0x7c/0xb0 [119482.334057] [<ffffffff8106d7b0>] ? insert_kthread_work+0x40/0x40 [119482.338661] Code: 00 00 55 48 8b 17 48 b9 00 01 10 00 00 00 ad de 48 8b 47 08 48 89 e5 48 39 ca 74 29 48 b9 00 02 20 00 00 00 ad de 48 39 c8 74 7a <4c> 8b 00 4c 39 c7 75 53 4c 8b 42 08 4c 39 c7 75 2b 48 89 42 08 [119482.343787] RIP [<ffffffff812ede89>] __list_del_entry+0x29/0xd0 [119482.348675] RSP <ffff880216d5db58> [119482.353493] CR2: 0000000000000000 Oops happened on this path: ip_defrag() -> ip_frag_queue() -> inet_frag_lru_move() -> list_move_tail() -> __list_del_entry() Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Jesper Dangaard Brouer <brouer@redhat.com> Cc: Florian Westphal <fw@strlen.de> Cc: Eric Dumazet <edumazet@google.com> Cc: David S. Miller <davem@davemloft.net> Acked-by: Florian Westphal <fw@strlen.de> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * tcp: do not expire TCP fastopen cookiesEric Dumazet2013-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TCP metric cache expires entries after one hour. This probably make sense for TCP RTT/RTTVAR/CWND, but not for TCP fastopen cookies. Its better to try previous cookie. If it appears to be obsolete, server will send us new cookie anyway. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net/eth/ibmveth: Fixup retrieval of MAC addressBenjamin Herrenschmidt2013-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some ancient pHyp versions used to create a 8 bytes local-mac-address property in the device-tree instead of a 6 bytes one for veth. The Linux driver code to deal with that is an insane hack which also happens to break with some choices of MAC addresses in qemu by testing for a bit in the address rather than just looking at the size of the property. Sanitize this by doing the latter instead. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: <stable@vger.kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * virtio: don't expose u16 in userspace apistephen hemminger2013-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Programs using virtio headers outside of kernel will no longer build because u16 type does not exist in userspace. All user ABI must use __u16 typedef instead. Bug introduce by: commit 986a4f4d452dec004697f667439d27c3fda9c928 Author: Jason Wang <jasowang@redhat.com> Date: Fri Dec 7 07:04:56 2012 +0000 virtio_net: multiqueue support Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'for-next' of ↵Linus Torvalds2013-05-06
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED subsystem updates from Bryan Wu: - move LED trigger drivers into a new directory - lp55xx common driver updates - other led drivers updates and bug fixing * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: leds: leds-asic3: switch to using SIMPLE_DEV_PM_OPS leds: leds-bd2802: add CONFIG_PM_SLEEP to suspend/resume functions leds: lp55xx: configure the clock detection leds: lp55xx: use common clock framework when external clock is used leds: leds-ns2: fix oops at module removal leds: leds-pwm: Defer led_pwm_set() if PWM can sleep leds: lp55xx: fix the sysfs read operation leds: lm355x, lm3642: support camera LED triggers for flash and torch leds: add camera LED triggers leds: trigger: use inline functions instead of macros leds: tca6507: Use of_match_ptr() macro leds: wm8350: Complain if we fail to reenable DCDC leds: renesas: set gpio_request_one() flags param correctly leds: leds-ns2: set devm_gpio_request_one() flags param correctly leds: leds-lt3593: set devm_gpio_request_one() flags param correctly leds: leds-bd2802: remove erroneous __exit annotation leds: atmel-pwm: remove erroneous __exit annotation leds: move LED trigger drivers into new subdirectory leds: add new LP5562 LED driver
| * | leds: leds-asic3: switch to using SIMPLE_DEV_PM_OPSJingoo Han2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Switch to using SIMPLE_DEV_PM_OPS macro to declare the driver's pm_ops. It reduces code size. Also, CONFIG_PM_SLEEP is added to suspend/ resume functions to prevent build warnings when CONFIG_PM_SLEEP is not selected. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: leds-bd2802: add CONFIG_PM_SLEEP to suspend/resume functionsJingoo Han2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following build warning when CONFIG_PM_SLEEP is not selected. This is because sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when the CONFIG_PM_SLEEP is enabled. drivers/leds/leds-bd2802.c:766:12: warning: 'bd2802_suspend' defined but not used [-Wunused-function] drivers/leds/leds-bd2802.c:776:12: warning: 'bd2802_resume' defined but not used [-Wunused-function] Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: lp55xx: configure the clock detectionKim, Milo2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now LP55xx provides automatic clock detection API, lp55xx_is_extclk_used(). The clock configuration can be done by the driver itself. (a) Concept The default value is set by each driver with clock selection. The internal clock selection bit is updated in case that the external clock is not detected or clock rate is not 32KHz. (b) Change on LP55xx platform data The clock configuration is done automatically, so no need to define 'update_config' in the platform side. Correlated information are removed in the documentations and header. (c) Definitions moved from header to driver files CONFIG register values are moved each driver, LP5521 and LP5562. Not necessary definitions are removed also. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: lp55xx: use common clock framework when external clock is usedKim, Milo2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Program execution is timed with 32768Hz clock in the LP55xx family devices. To run LED functionalities, LP55xx devices provide two options. One is using internal clock. The other is using external clock. This patch enables external clock detection automatically. If external clock is not detected, then the internal clock will be used in the LP55xx driver. Valid clock rate is 32768Hz in LP55xx devices. This new API is used in each LP55xx driver like LP5521 and LP5562. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: leds-ns2: fix oops at module removalSimon Guinot2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a regression introduced by commit 72052fcc10 ("leds: leds-ns2: add device tree binding"). When the driver is initialized with device tree data, platform_data pointer is NULL. This causes a kernel oops at removal. To fix this bug, num_leds is moved into driver_data and platform_data is not longer used from ns2_led_remove(). Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: leds-pwm: Defer led_pwm_set() if PWM can sleepFlorian Vaussard2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Call to led_pwm_set() can happen inside atomic context, like triggers. If the PWM call can sleep, defer using a worker. Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: lp55xx: fix the sysfs read operationKim, Milo2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | According to a sysfs documentation(Documentation/filesystem/sysfs.txt), scnprintf() should be used in a read operation method. It guarantees safe buffer size(PAGE_SIZE) which is allocated by the sysfs. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: lm355x, lm3642: support camera LED triggers for flash and torchKim, Milo2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LM355x and LM3642 support flash and torch functionality. (Camera driver) (LED trigger for camera) (LED driver) Turn on the flash ...> ledtrig_flash_ctrl(true) ...> LM355x or LM3642 brightness ctrl <actual driving here> Flash/torch LEDs are controlled by other driver using LED camera trigger APIs, ledtrig_flash_ctrl()/ledtrig_torch_ctrl(). Then, actual device control is activated by each LED driver such like LM355x or LM3642. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: add camera LED triggersKim, Milo2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some LED devices support flash/torch functionality through the LED subsystem. This patch enables direct LED trigger controls by the driver. Flash on/off and torch on/off can be done simply by other driver space. Two trigger APIs are added, ledtrig_flash_ctrl() and ledtrig_torch_ctrl(). Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: trigger: use inline functions instead of macrosKim, Milo2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Macros are used in case that an inline function doesn't work. Otherwise, use an empty inline function. (a) Case of !CONFIG_LEDS_TRIGGERS Following macros are replaced with inline functions. led_trigger_register_simple() led_trigger_unregister_simple() led_trigger_event() To make inline types, the structure, 'led_trigger' should be defined. This structure has no member at all. (b) Case of !CONFIG_LEDS_TRIGGER_IDE_DISK ledtrig_ide_activity() macro is replaced with an inline function as well. (c) DEFINE_LED_TRIGGER() and DEFINE_LED_TRIGGER_GLOBAL() Struct 'led_trigger' is defined both cases, with CONFIG_LEDS_TRIGGERS and without CONFIG_LEDS_TRIGGERS. Those macros are moved out of CONFIG_LED_TRIGGERS because of no-dependency on CONFIG_LEDS_TRIGGERS. (d) Fix build errors in mmc-core driver After replacing macros with inline functions, following build errors occur. (condition: CONFIG_LEDS_TRIGGERS is not set) drivers/mmc/core/core.c: In function 'mmc_request_done': drivers/mmc/core/core.c:164:25: error: 'struct mmc_host' has no member named 'led' drivers/mmc/core/core.c: In function 'mmc_start_request': drivers/mmc/core/core.c:254:24: error: 'struct mmc_host' has no member named 'led' make[3]: *** [drivers/mmc/core/core.o] Error 1 The reason of these errors is non-existent member variable, 'led'. It is only valid when CONFIG_LEDS_TRIGGERS is set. But now, it can be used without this dependency. To fix build errors, member 'led' is always used without its config option in 'include/linux/mmc/host.h'. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: tca6507: Use of_match_ptr() macroSachin Kamat2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | This eliminates having an #ifdef returning NULL for the case when OF is disabled. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: wm8350: Complain if we fail to reenable DCDCMark Brown2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | Provide some trace, though the hardware is most likely non-functional if this happens. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: renesas: set gpio_request_one() flags param correctlyJingoo Han2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gpio_request_one() flags parameter was set to: GPIOF_DIR_OUT | !!brightness GPIOF_DIR_OUT and GPIOF_DIR_IN are defined as below: GPIOF_DIR_OUT (0 << 0) GPIOF_DIR_IN (1 << 0) So, when '!!brightness' is 1, the gpio pin can be set as input, instead of output. To prevent this problem, GPIOF_OUT_INIT flags should be used when using gpio_request_one(). Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: leds-ns2: set devm_gpio_request_one() flags param correctlyJingoo Han2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The devm_gpio_request_one() flags parameter was set to: GPIOF_DIR_OUT | gpio_get_value(template->cmd) GPIOF_DIR_OUT and GPIOF_DIR_IN are defined as below: GPIOF_DIR_OUT (0 << 0) GPIOF_DIR_IN (1 << 0) So, when 'gpio_get_value(template->cmd)' is 1, the gpio pin can be set as input, instead of output. To prevent this problem, GPIOF_OUT_INIT flags should be used when using devm_gpio_request_one(). Same goes for 'gpio_get_value(template->slow)' case. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: leds-lt3593: set devm_gpio_request_one() flags param correctlyJingoo Han2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The devm_gpio_request_one() flags parameter was set to: GPIOF_DIR_OUT | state GPIOF_DIR_OUT and GPIOF_DIR_IN are defined as below: GPIOF_DIR_OUT (0 << 0) GPIOF_DIR_IN (1 << 0) So, when 'state' is 1, the gpio pin can be set as input, instead of output. To prevent this problem, GPIOF_OUT_INIT flags should be used when using devm_gpio_request_one(). Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: leds-bd2802: remove erroneous __exit annotationJingoo Han2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | CONFIG_HOTPLUG was removed, so __devexit or __exit of remove() should not be used. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: atmel-pwm: remove erroneous __exit annotationJingoo Han2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | CONFIG_HOTPLUG was removed, so __devexit or __exit of remove() should not be used. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: move LED trigger drivers into new subdirectoryKim, Milo2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For better driver management, new subdirectory, 'trigger' is created. All LED trigger drivers are moved into this directory. Internal header, 'leds.h' is included in each LED trigger drivers. Fix the location of header file, "leds.h" -> "../leds.h" in driver files. One exception is here, 'ledtrig-timer.c'. There is no need to include 'leds.h'. so '#include "leds.h"' line was removed. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * | leds: add new LP5562 LED driverKim, Milo2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LP5562 can drive up to 4 channels, RGB and White. LEDs can be controlled directly via the led class control interface. LP55xx common driver LP5562 is one of LP55xx family device, so LP55xx common code are used. On the other hand, chip specific configuration is defined in the structure 'lp55xx_device_config' LED pattern data LP5562 has also internal program memory which is used for running various LED patterns. LP5562 driver supports the firmware interface and the predefined pattern data as well. LP5562 device attributes: 'led_pattern' and 'engine_mux' A 'led_pattern' is an index code which runs the predefined pattern data. And 'engine_mux' is updated with the firmware interface is activated. Detailed description has been updated in the documentation files, 'leds-lp55xx.txt' and 'leds-lp5562.txt'. Changes on the header file LP5562 configurable definitions are added. Pattern RGB data is fixed as constant value. (No side effect on other devices, LP5521 or LP5523.) (cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan Carpenter <dan.carpenter@oracle.com>) Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* | | Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linuxLinus Torvalds2013-05-06
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull GPIO changes from Grant Likely: "The usual selection of bug fixes and driver updates for GPIO. Nothing really stands out except the addition of the GRGPIO driver and some enhacements to ACPI support" I'm pulling this despite the earlier mess. Let's hope it compiles these days. * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux: (46 commits) gpio: grgpio: Add irq support gpio: grgpio: Add device driver for GRGPIO cores gpiolib-acpi: introduce acpi_get_gpio_by_index() helper GPIO: gpio-generic: remove kfree() from bgpio_remove call gpio / ACPI: Handle ACPI events in accordance with the spec gpio: lpc32xx: Fix off-by-one valid range checking for bank gpio: mcp23s08: convert driver to DT gpio/omap: force restore if context loss is not detectable gpio/omap: optimise interrupt service routine gpio/omap: remove extra context restores in *_runtime_resume() gpio/omap: free irq domain in probe() failure paths gpio: gpio-generic: Add 16 and 32 bit big endian byte order support gpio: samsung: Add terminating entry for exynos_pinctrl_ids gpio: mvebu: add dbg_show function MAX7301 GPIO: Do not force SPI speed when using OF Platform gpio: gpio-tps65910.c: fix checkpatch error gpio: gpio-timberdale.c: fix checkpatch error gpio: gpio-tc3589x.c: fix checkpatch errors gpio: gpio-stp-xway.c: fix checkpatch error gpio: gpio-sch.c: fix checkpatch error ...
| * | | gpio: grgpio: Add irq supportAndreas Larsson2013-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The drivers sets up an irq domain and hands out unique irqs to irq capable gpio lines regardless of how underlying irq maps to gpio lines. Any gpio line can map to any one or none of the irqs of the core, independently of each other. Signed-off-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | gpio: grgpio: Add device driver for GRGPIO coresAndreas Larsson2013-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This driver supports GRGPIO gpio cores available in the GRLIB VHDL IP core library from Aeroflex Gaisler. Signed-off-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | gpiolib-acpi: introduce acpi_get_gpio_by_index() helperMika Westerberg2013-04-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of open-coding ACPI GPIO resource lookup in each driver, we provide a helper function analogous to Device Tree version that allows drivers to specify which GPIO resource they are interested (using an index to the GPIO resources). The function then finds out the correct resource, translates the ACPI GPIO number to the corresponding Linux GPIO number and returns that. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | GPIO: gpio-generic: remove kfree() from bgpio_remove callAlexander Shiyan2013-04-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Memory for basic-mmio-gpio driver is allocated by the driver using it, whether it's the generic GPIO driver itself or another driver. In either case, the owner shall allocate and free the struct bgpio_chip it is using, preferably using a managed resource. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | gpio / ACPI: Handle ACPI events in accordance with the specRafael J. Wysocki2013-04-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 0d1c28a (gpiolib-acpi: Add ACPI5 event model support to gpio.) that added support for ACPI events signalled through GPIO interrupts covered only GPIO pins whose numbers are less than or equal to 255. However, there may be GPIO pins with numbers greater than 255 and the ACPI spec (ACPI 5.0, Section 5.6.5.1) requires the _EVT method to be used for handling events corresponding to those pins. Moreover, according to the spec, _EVT is the default mechanism for handling all ACPI events signalled through GPIO interrupts, so if the _Exx/_Lxx method is not present for the given pin, _EVT should be used instead. If present, though, _Exx/_Lxx take precedence over _EVT which shouldn't be executed in that case (ACPI 5.0, Section 5.6.5.3). Modify acpi_gpiochip_request_interrupts() to follow the spec as described above and add acpi_gpiochip_free_interrupts() needed to free interrupts associated with _EVT. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | gpio: lpc32xx: Fix off-by-one valid range checking for bankAxel Lin2013-04-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The valid bank should be 0 ... ARRAY_SIZE(lpc32xx_gpiochip) - 1. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | gpio: mcp23s08: convert driver to DTLars Poeschel2013-04-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This converts the mcp23s08 driver to be able to be used with device tree. There is a "spi-present-mask" device tree property, that allows to use multiple of this spi chips on the same chipselect. v4: - removed the ability to specify the pullup from device tree - updated binding doc v3: - removed mcp,chips device tree property in favour of a mcp,spi-present-mask and a flag for the pullup of every gpio - seperated the match table. Now there is one for i2c and one for spi - do the of reading stuff on stack of the probe function - no devm any more v2: - squashed booth patches together - fixed build warning, when CONFIG_OF is not defined - use of_match_ptr macro for of_match_table Signed-off-by: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | gpio/omap: force restore if context loss is not detectableJon Hunter2013-04-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When booting with device-tree the function pointer for detecting context loss is not populated. Ideally, the pm_runtime framework should be enhanced to allow a means for reporting context/state loss and we could avoid populating such function pointers altogether. In the interim until a generic non-device specific solution is in place, force a restore of the gpio bank when enabling the gpio controller. Adds a new device-tree property for the OMAP GPIO controller to indicate if the GPIO controller is located in a power-domain that never loses power and hence will always maintain its logic state. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | gpio/omap: optimise interrupt service routineJon Hunter2013-04-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OMAP GPIO interrupt service routine is checking each bit in the GPIO interrupt status register to see which bits are set. It is not efficient to check every bit especially if only a few bits are set. Therefore, instead of checking every bit use the __ffs() function, which returns the location of the first set bit, to find all the set bits. This optimisation was suggested-by and developed in collaboration with Felipe Balbi. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
generated by cgit v1.2.2 (git 2.25.0) at 2025-01-15 06:38:54 -0500