-
Notifications
You must be signed in to change notification settings - Fork 43
Support for gpio connected ir senders/receivers #18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
linux4kix
merged 2 commits into
linux4kix:linux-linaro-lsk-v3.14-mx6
from
CurlyMoo:lirc_gpio
Sep 16, 2014
Merged
Support for gpio connected ir senders/receivers #18
linux4kix
merged 2 commits into
linux4kix:linux-linaro-lsk-v3.14-mx6
from
CurlyMoo:lirc_gpio
Sep 16, 2014
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This module allows users to use a GPIO connected IR receiver and/or sender with LIRC. The module uses the sysfs gpio kernel functions to interact with the gpio. You can configure the module from inside the device tree like this: lirc_gpio { compatible = "lirc_gpio"; gpios = <&gpio3 6 1 &gpio3 7 2>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_hummingboard_gpio3_6>; pinctrl-1 = <&pinctrl_hummingboard_gpio3_7>; linux,sense = <-1>; linux,softcarrier = <1>; linux,validgpios = <1 73 72 71 70 194 195 67>; }; It should therefor work on all platforms.
linux4kix
added a commit
that referenced
this pull request
Sep 16, 2014
Support for gpio connected ir senders/receivers
wolfgar
pushed a commit
to wolfgar/linux-linaro-stable-mx6
that referenced
this pull request
Sep 21, 2014
As the new x86 CPU bootup printout format code maintainer, I am taking immediate action to improve and clean (and thus indulge my OCD) the reporting of the cores when coming up online. Fix padding to a right-hand alignment, cleanup code and bind reporting width to the max number of supported CPUs on the system, like this: [ 0.074509] smpboot: Booting Node 0, Processors: linux4kix#1 linux4kix#2 linux4kix#3 linux4kix#4 linux4kix#5 linux4kix#6 linux4kix#7 OK [ 0.644008] smpboot: Booting Node 1, Processors: linux4kix#8 linux4kix#9 linux4kix#10 linux4kix#11 linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15 OK [ 1.245006] smpboot: Booting Node 2, Processors: linux4kix#16 linux4kix#17 linux4kix#18 linux4kix#19 linux4kix#20 linux4kix#21 linux4kix#22 linux4kix#23 OK [ 1.864005] smpboot: Booting Node 3, Processors: linux4kix#24 linux4kix#25 linux4kix#26 linux4kix#27 linux4kix#28 #29 #30 #31 OK [ 2.489005] smpboot: Booting Node 4, Processors: #32 #33 #34 #35 #36 #37 #38 #39 OK [ 3.093005] smpboot: Booting Node 5, Processors: #40 #41 #42 #43 #44 #45 #46 #47 OK [ 3.698005] smpboot: Booting Node 6, Processors: #48 #49 #50 #51 #52 #53 #54 #55 OK [ 4.304005] smpboot: Booting Node 7, Processors: #56 #57 #58 #59 #60 #61 #62 #63 OK [ 4.961413] Brought up 64 CPUs and this: [ 0.072367] smpboot: Booting Node 0, Processors: linux4kix#1 linux4kix#2 linux4kix#3 linux4kix#4 linux4kix#5 linux4kix#6 linux4kix#7 OK [ 0.686329] Brought up 8 CPUs Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Libin <huawei.libin@huawei.com> Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Link: http://lkml.kernel.org/r/20130927143554.GF4422@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
wolfgar
pushed a commit
to wolfgar/linux-linaro-stable-mx6
that referenced
this pull request
Sep 21, 2014
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: linux4kix#1 linux4kix#2 linux4kix#3 linux4kix#4 linux4kix#5 linux4kix#6 linux4kix#7 [ 0.603005] .... node linux4kix#1, CPUs: linux4kix#8 linux4kix#9 linux4kix#10 linux4kix#11 linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15 [ 1.200005] .... node linux4kix#2, CPUs: linux4kix#16 linux4kix#17 linux4kix#18 linux4kix#19 linux4kix#20 linux4kix#21 linux4kix#22 linux4kix#23 [ 1.796005] .... node linux4kix#3, CPUs: linux4kix#24 linux4kix#25 linux4kix#26 linux4kix#27 linux4kix#28 #29 #30 #31 [ 2.393005] .... node linux4kix#4, CPUs: #32 #33 #34 #35 #36 #37 #38 #39 [ 2.996005] .... node linux4kix#5, CPUs: #40 #41 #42 #43 #44 #45 #46 #47 [ 3.600005] .... node linux4kix#6, CPUs: #48 #49 #50 #51 #52 #53 #54 #55 [ 4.202005] .... node linux4kix#7, CPUs: #56 #57 #58 #59 #60 #61 #62 #63 [ 4.811005] .... node linux4kix#8, CPUs: #64 #65 #66 #67 #68 #69 #70 #71 [ 5.421006] .... node linux4kix#9, CPUs: #72 #73 #74 #75 #76 #77 #78 #79 [ 6.032005] .... node linux4kix#10, CPUs: #80 #81 #82 #83 #84 #85 #86 #87 [ 6.648006] .... node linux4kix#11, CPUs: #88 #89 #90 #91 #92 #93 #94 #95 [ 7.262005] .... node linux4kix#12, CPUs: #96 #97 #98 #99 #100 #101 #102 #103 [ 7.865005] .... node linux4kix#13, CPUs: #104 #105 #106 #107 #108 #109 #110 #111 [ 8.466005] .... node linux4kix#14, CPUs: #112 #113 #114 #115 #116 #117 #118 #119 [ 9.073006] .... node linux4kix#15, CPUs: #120 #121 #122 #123 #124 #125 #126 #127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: huawei.libin@huawei.com Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
wolfgar
pushed a commit
to wolfgar/linux-linaro-stable-mx6
that referenced
this pull request
Sep 21, 2014
When memcg code needs to know whether any given memcg has children, it uses the cgroup child iteration primitives and returns true/false depending on whether the iteration loop is executed at least once or not. Because a cgroup's list of children is RCU protected, these primitives require the RCU read-lock to be held, which is not the case for all memcg callers. This results in the following splat when e.g. enabling hierarchy mode: WARNING: CPU: 3 PID: 1 at kernel/cgroup.c:3043 css_next_child+0xa3/0x160() CPU: 3 PID: 1 Comm: systemd Not tainted 3.12.0-rc5-00117-g83f11a9-dirty linux4kix#18 Hardware name: LENOVO 3680B56/3680B56, BIOS 6QET69WW (1.39 ) 04/26/2012 Call Trace: dump_stack+0x54/0x74 warn_slowpath_common+0x78/0xa0 warn_slowpath_null+0x1a/0x20 css_next_child+0xa3/0x160 mem_cgroup_hierarchy_write+0x5b/0xa0 cgroup_file_write+0x108/0x2a0 vfs_write+0xbd/0x1e0 SyS_write+0x4c/0xa0 system_call_fastpath+0x16/0x1b In the memcg case, we only care about children when we are attempting to modify inheritable attributes interactively. Racing with deletion could mean a spurious -EBUSY, no problem. Racing with addition is handled just fine as well through the memcg_create_mutex: if the child group is not on the list after the mutex is acquired, it won't be initialized from the parent's attributes until after the unlock. Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
wolfgar
pushed a commit
to wolfgar/linux-linaro-stable-mx6
that referenced
this pull request
Sep 21, 2014
The probe function is supposed to return NULL on failure (as we can see in kobj_lookup: kobj = probe(dev, index, data); ... if (kobj) return kobj; However, in loop and brd, it returns negative error from ERR_PTR. This causes a crash if we simulate disk allocation failure and run less -f /dev/loop0 because the negative number is interpreted as a pointer: BUG: unable to handle kernel NULL pointer dereference at 00000000000002b4 IP: [<ffffffff8118b188>] __blkdev_get+0x28/0x450 PGD 23c677067 PUD 23d6d1067 PMD 0 Oops: 0000 [linux4kix#1] PREEMPT SMP Modules linked in: loop hpfs nvidia(PO) ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev msr ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_stats cpufreq_ondemand cpufreq_userspace cpufreq_powersave cpufreq_conservative hid_generic spadfs usbhid hid fuse raid0 snd_usb_audio snd_pcm_oss snd_mixer_oss md_mod snd_pcm snd_timer snd_page_alloc snd_hwdep snd_usbmidi_lib dmi_sysfs snd_rawmidi nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack snd soundcore lm85 hwmon_vid ohci_hcd ehci_pci ehci_hcd serverworks sata_svw libata acpi_cpufreq freq_table mperf ide_core usbcore kvm_amd kvm tg3 i2c_piix4 libphy microcode e100 usb_common ptp skge i2c_core pcspkr k10temp evdev floppy hwmon pps_core mii rtc_cmos button processor unix [last unloaded: nvidia] CPU: 1 PID: 6831 Comm: less Tainted: P W O 3.10.15-devel linux4kix#18 Hardware name: empty empty/S3992-E, BIOS 'V1.06 ' 06/09/2009 task: ffff880203cc6bc0 ti: ffff88023e47c000 task.ti: ffff88023e47c000 RIP: 0010:[<ffffffff8118b188>] [<ffffffff8118b188>] __blkdev_get+0x28/0x450 RSP: 0018:ffff88023e47dbd8 EFLAGS: 00010286 RAX: ffffffffffffff74 RBX: ffffffffffffff74 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: ffff88023e47dc18 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88023f519658 R13: ffffffff8118c300 R14: 0000000000000000 R15: ffff88023f519640 FS: 00007f2070bf7700(0000) GS:ffff880247400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000002b4 CR3: 000000023da1d000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: 0000000000000002 0000001d00000000 000000003e47dc50 ffff88023f519640 ffff88043d5bb668 ffffffff8118c300 ffff88023d683550 ffff88023e47de60 ffff88023e47dc98 ffffffff8118c10d 0000001d81605698 0000000000000292 Call Trace: [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60 [<ffffffff8118c10d>] blkdev_get+0x1dd/0x370 [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60 [<ffffffff813cea6c>] ? _raw_spin_unlock+0x2c/0x50 [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60 [<ffffffff8118c365>] blkdev_open+0x65/0x80 [<ffffffff8114d12e>] do_dentry_open.isra.18+0x23e/0x2f0 [<ffffffff8114d214>] finish_open+0x34/0x50 [<ffffffff8115e122>] do_last.isra.62+0x2d2/0xc50 [<ffffffff8115eb58>] path_openat.isra.63+0xb8/0x4d0 [<ffffffff81115a8e>] ? might_fault+0x4e/0xa0 [<ffffffff8115f4f0>] do_filp_open+0x40/0x90 [<ffffffff813cea6c>] ? _raw_spin_unlock+0x2c/0x50 [<ffffffff8116db85>] ? __alloc_fd+0xa5/0x1f0 [<ffffffff8114e45f>] do_sys_open+0xef/0x1d0 [<ffffffff8114e559>] SyS_open+0x19/0x20 [<ffffffff813cff16>] system_call_fastpath+0x1a/0x1f Code: 44 00 00 55 48 89 e5 41 57 49 89 ff 41 56 41 89 d6 41 55 41 54 4c 8d 67 18 53 48 83 ec 18 89 75 cc e9 f2 00 00 00 0f 1f 44 00 00 <48> 8b 80 40 03 00 00 48 89 df 4c 8b 68 58 e8 d5 a4 07 00 44 89 RIP [<ffffffff8118b188>] __blkdev_get+0x28/0x450 RSP <ffff88023e47dbd8> CR2: 00000000000002b4 ---[ end trace bb7f32dbf02398dc ]--- The brd change should be backported to stable kernels starting with 2.6.25. The loop change should be backported to stable kernels starting with 2.6.22. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Acked-by: Tejun Heo <tj@kernel.org> Cc: stable@kernel.org # 2.6.22+ Signed-off-by: Jens Axboe <axboe@kernel.dk>
wolfgar
pushed a commit
to wolfgar/linux-linaro-stable-mx6
that referenced
this pull request
Sep 21, 2014
…culation Currently mx53 (CortexA8) running at 1GHz reports: Calibrating delay loop... 663.55 BogoMIPS (lpj=3317760) Tom Evans verified that alignments of 0x0 and 0x8 run the two instructions of __loop_delay in one clock cycle (1 clock/loop), while alignments of 0x4 and 0xc take 3 clocks to run the loop twice. (1.5 clock/loop) The original object code looks like this: 00000010 <__loop_const_udelay>: 10: e3e01000 mvn r1, #0 14: e51f201c ldr r2, [pc, #-28] ; 0 <__loop_udelay-0x8> 18: e5922000 ldr r2, [r2] 1c: e0800921 add r0, r0, r1, lsr linux4kix#18 20: e1a00720 lsr r0, r0, linux4kix#14 24: e0822b21 add r2, r2, r1, lsr linux4kix#22 28: e1a02522 lsr r2, r2, linux4kix#10 2c: e0000092 mul r0, r2, r0 30: e0800d21 add r0, r0, r1, lsr linux4kix#26 34: e1b00320 lsrs r0, r0, linux4kix#6 38: 01a0f00e moveq pc, lr 0000003c <__loop_delay>: 3c: e2500001 subs r0, r0, linux4kix#1 40: 8afffffe bhi 3c <__loop_delay> 44: e1a0f00e mov pc, lr After adding the 'align 3' directive to __loop_delay (align to 8 bytes): 00000010 <__loop_const_udelay>: 10: e3e01000 mvn r1, #0 14: e51f201c ldr r2, [pc, #-28] ; 0 <__loop_udelay-0x8> 18: e5922000 ldr r2, [r2] 1c: e0800921 add r0, r0, r1, lsr linux4kix#18 20: e1a00720 lsr r0, r0, linux4kix#14 24: e0822b21 add r2, r2, r1, lsr linux4kix#22 28: e1a02522 lsr r2, r2, linux4kix#10 2c: e0000092 mul r0, r2, r0 30: e0800d21 add r0, r0, r1, lsr linux4kix#26 34: e1b00320 lsrs r0, r0, linux4kix#6 38: 01a0f00e moveq pc, lr 3c: e320f000 nop {0} 00000040 <__loop_delay>: 40: e2500001 subs r0, r0, linux4kix#1 44: 8afffffe bhi 40 <__loop_delay> 48: e1a0f00e mov pc, lr 4c: e320f000 nop {0} , which now reports: Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736) Some more test results: On mx31 (ARM1136) running at 532 MHz, before the patch: Calibrating delay loop... 351.43 BogoMIPS (lpj=1757184) On mx31 (ARM1136) running at 532 MHz after the patch: Calibrating delay loop... 528.79 BogoMIPS (lpj=2643968) Also tested on mx6 (CortexA9) and on mx27 (ARM926), which shows the same BogoMIPS value before and after this patch. Reported-by: Tom Evans <tom_usenet@optusnet.com.au> Suggested-by: Tom Evans <tom_usenet@optusnet.com.au> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
wolfgar
pushed a commit
to wolfgar/linux-linaro-stable-mx6
that referenced
this pull request
Sep 21, 2014
For devices with a separated audio-only interface (em2860), call em28xx_init_extension() only once. That fixes a bug with Kworld 305U (eb1a:e305): [ 658.730715] em2860 #0: V4L2 video device registered as video1 [ 658.730728] em2860 #0: V4L2 VBI device registered as vbi0 [ 658.736907] em2860 #0: Remote control support is not available for this card. [ 658.736965] em2860 linux4kix#1: Remote control support is not available for this card. [ 658.737230] ------------[ cut here ]------------ [ 658.737246] WARNING: CPU: 2 PID: 60 at lib/list_debug.c:36 __list_add+0x8a/0xc0() [ 658.737256] list_add double add: new=ffff8800a9a40410, prev=ffff8800a9a40410, next=ffffffffa08720d0. [ 658.737266] Modules linked in: tuner_xc2028 netconsole rc_hauppauge em28xx_rc rc_core tuner_simple tuner_types tda9887 tda8290 tuner tvp5150 msp3400 em28xx_v4l em28xx tveeprom v4l2_common fuse ccm nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6tabl e_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security bnep iptable_raw vfat fat arc4 iwldvm mac80211 x86_pkg_temp_thermal coretemp kvm_intel nfsd iwlwifi snd_hda_codec_hdmi kvm snd_hda _codec_realtek snd_hda_intel snd_hda_codec auth_rpcgss nfs_acl cfg80211 lockd snd_hwdep snd_seq btusb sunrpc crc32_pclmul bluetooth crc32c_intel snd_seq_device snd_pcm uvcvideo r8169 ghash_clmulni_intel videobuf2_vmalloc videobuf2_memops videobuf2_core snd_page_alloc snd_timer snd videodev mei_me iTCO_wdt mii shpchp joydev mei media iTCO_vendor_support lpc_ich m icrocode soundcore rfkill serio_raw i2c_i801 mfd_core nouveau i915 ttm i2c_algo_bit drm_kms_helper drm i2c_core mxm_wmi wmi video [ 658.738601] CPU: 2 PID: 60 Comm: kworker/2:1 Not tainted 3.13.0-rc1+ linux4kix#18 [ 658.738611] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 550P5C/550P7C/SAMSUNG_NP1234567890, BIOS P04ABI.013.130220.dg 02/20/2013 [ 658.738624] Workqueue: events request_module_async [em28xx] [ 658.738646] 0000000000000009 ffff8802209dfc68 ffffffff816a3c96 ffff8802209dfcb0 [ 658.738700] ffff8802209dfca0 ffffffff8106aaad ffff8800a9a40410 ffffffffa08720d0 [ 658.738754] ffff8800a9a40410 0000000000000000 0000000000000080 ffff8802209dfd00 [ 658.738814] Call Trace: [ 658.738836] [<ffffffff816a3c96>] dump_stack+0x45/0x56 [ 658.738851] [<ffffffff8106aaad>] warn_slowpath_common+0x7d/0xa0 [ 658.738864] [<ffffffff8106ab1c>] warn_slowpath_fmt+0x4c/0x50 [ 658.738880] [<ffffffffa0868a7d>] ? em28xx_init_extension+0x1d/0x80 [em28xx] [ 658.738898] [<ffffffff81343b8a>] __list_add+0x8a/0xc0 [ 658.738911] [<ffffffffa0868a98>] em28xx_init_extension+0x38/0x80 [em28xx] [ 658.738927] [<ffffffffa086a059>] request_module_async+0x19/0x110 [em28xx] [ 658.738942] [<ffffffff810873b5>] process_one_work+0x1f5/0x510 [ 658.738954] [<ffffffff81087353>] ? process_one_work+0x193/0x510 [ 658.738967] [<ffffffff810880bb>] worker_thread+0x11b/0x3a0 [ 658.738979] [<ffffffff81087fa0>] ? manage_workers.isra.24+0x2b0/0x2b0 [ 658.738992] [<ffffffff8108ea2f>] kthread+0xff/0x120 [ 658.739005] [<ffffffff8108e930>] ? kthread_create_on_node+0x250/0x250 [ 658.739017] [<ffffffff816b517c>] ret_from_fork+0x7c/0xb0 [ 658.739029] [<ffffffff8108e930>] ? kthread_create_on_node+0x250/0x250 [ 658.739040] ---[ end trace c1acd24b354108de ]--- [ 658.739051] em2860 linux4kix#1: Remote control support is not available for this card. [ 658.742407] em28xx-audio.c: probing for em28xx Audio Vendor Class [ 658.742429] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 658.742440] em28xx-audio.c: Copyright (C) 2007-2011 Mauro Carvalho Chehab [ 658.744798] em28xx-audio.c: probing for em28xx Audio Vendor Class [ 658.744823] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 658.744836] em28xx-audio.c: Copyright (C) 2007-2011 Mauro Carvalho Chehab [ 658.746849] em28xx-audio.c: probing for em28xx Audio Vendor Class [ 658.746863] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 658.746874] em28xx-audio.c: Copyright (C) 2007-2011 Mauro Carvalho Chehab ... Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This module allows users to use a GPIO connected
IR receiver and/or sender with LIRC. The module
uses the sysfs gpio kernel functions to interact
with the gpio. You can configure the module from
inside the device tree like this:
lirc_gpio {
compatible = "lirc_gpio";
gpios = <&gpio3 6 1 &gpio3 7 2>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard_gpio3_6>;
pinctrl-1 = <&pinctrl_hummingboard_gpio3_7>;
linux,sense = <-1>;
linux,softcarrier = <1>;
linux,validgpios = <1 73 72 71 70 194 195 67>;
};
It should therefor work on all platforms.