<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/media/rc, branch v4.11.5</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.11.5</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.11.5'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-06-14T13:07:44+00:00</updated>
<entry>
<title>rc-core: race condition during ir_raw_event_register()</title>
<updated>2017-06-14T13:07:44+00:00</updated>
<author>
<name>Sean Young</name>
<email>sean@mess.org</email>
</author>
<published>2017-05-24T09:24:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d31fff8cbc9afc539bdf34b39a8e116551fa69a8'/>
<id>urn:sha1:d31fff8cbc9afc539bdf34b39a8e116551fa69a8</id>
<content type='text'>
commit 963761a0b2e85663ee4a5630f72930885a06598a upstream.

A rc device can call ir_raw_event_handle() after rc_allocate_device(),
but before rc_register_device() has completed. This is racey because
rcdev-&gt;raw is set before rcdev-&gt;raw-&gt;thread has a valid value.

Reported-by: kbuild test robot &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mceusb: fix NULL-deref at probe</title>
<updated>2017-05-25T13:46:19+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2017-03-07T18:14:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f2b30b2f19a9cc013fbb04144cea3896df2eabb1'/>
<id>urn:sha1:f2b30b2f19a9cc013fbb04144cea3896df2eabb1</id>
<content type='text'>
commit 03eb2a557ed552e920a0942b774aaf931596eec1 upstream.

Make sure to check for the required out endpoint to avoid dereferencing
a NULL-pointer in mce_request_packet should a malicious device lack such
an endpoint. Note that this path is hit during probe.

Fixes: 66e89522aff7 ("V4L/DVB: IR: add mceusb IR receiver driver")

Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge tag 'media/v4.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media</title>
<updated>2017-03-09T23:50:56+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-03-09T23:50:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bb61ce54e8986ea18f7eb13cfa4a6fa8eb311bbd'/>
<id>urn:sha1:bb61ce54e8986ea18f7eb13cfa4a6fa8eb311bbd</id>
<content type='text'>
Pull media fixes from Mauro Carvalho Chehab:
 "Media regression fixes:

   - serial_ir: fix a Kernel crash during boot on Kernel 4.11-rc1, due
     to an IRQ code called too early

   - other IR regression fixes at lirc and at the raw IR decoding

   - a deadlock fix at the RC nuvoton driver

   - fix another issue with DMA on stack at dw2102 driver

  There's an extra patch there that change a driver interface for the
  SoC VSP1 driver, with is shared between the DRM and V4L2 driver. The
  patch itself is trivial, and was acked by David Arlie"

* tag 'media/v4.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] v4l: vsp1: Adapt vsp1_du_setup_lif() interface to use a structure
  [media] dw2102: don't do DMA on stack
  [media] rc: protocol is not set on register for raw IR devices
  [media] rc: raw decoder for keymap protocol is not loaded on register
  [media] rc: nuvoton: fix deadlock in nvt_write_wakeup_codes
  [media] lirc: fix dead lock between open and wakeup_filter
  [media] serial_ir: ensure we're ready to receive interrupts
</content>
</entry>
<entry>
<title>[media] rc: protocol is not set on register for raw IR devices</title>
<updated>2017-03-03T10:06:59+00:00</updated>
<author>
<name>Sean Young</name>
<email>sean@mess.org</email>
</author>
<published>2017-02-23T09:11:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5df62771c556e4ec9d7ecea1f070ff6da4bce151'/>
<id>urn:sha1:5df62771c556e4ec9d7ecea1f070ff6da4bce151</id>
<content type='text'>
ir_raw_event_register() sets up change_protocol(), and without that set,
rc_setup_rx_device() does not set the protocol for the device on register.

The standard udev rules run ir-keytable, which writes to the protocols
file again, which hides this problem.

Fixes: 7ff2c2b ("[media] rc-main: split setup and unregister functions")

Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
</entry>
<entry>
<title>[media] rc: raw decoder for keymap protocol is not loaded on register</title>
<updated>2017-03-03T10:06:58+00:00</updated>
<author>
<name>Sean Young</name>
<email>sean@mess.org</email>
</author>
<published>2017-02-22T21:48:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=413808685dd7c9b54bbc5af79da2eaddd0fc3cb2'/>
<id>urn:sha1:413808685dd7c9b54bbc5af79da2eaddd0fc3cb2</id>
<content type='text'>
When the protocol is set via the sysfs protocols attribute, the
decoder is loaded. However, when it is not when a device is first
plugged in or registered.

Fixes: acc1c3c ("[media] media: rc: load decoder modules on-demand")

Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.5+
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
</entry>
<entry>
<title>[media] rc: nuvoton: fix deadlock in nvt_write_wakeup_codes</title>
<updated>2017-03-03T10:06:57+00:00</updated>
<author>
<name>Heiner Kallweit</name>
<email>hkallweit1@gmail.com</email>
</author>
<published>2017-02-12T17:01:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c1305a40722f3e02f3d971acc22f5991aff239a6'/>
<id>urn:sha1:c1305a40722f3e02f3d971acc22f5991aff239a6</id>
<content type='text'>
nvt_write_wakeup_codes acquires the same lock as the ISR but doesn't
disable interrupts on the local CPU. This caused the following
deadlock. Fix this by using spin_lock_irqsave.

[  432.362008] ================================
[  432.362074] WARNING: inconsistent lock state
[  432.362144] 4.10.0-rc7-next-20170210 #1 Not tainted
[  432.362219] --------------------------------
[  432.362286] inconsistent {HARDIRQ-ON-W} -&gt; {IN-HARDIRQ-W} usage.
[  432.362379] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[  432.362457]  (&amp;(&amp;nvt-&gt;lock)-&gt;rlock){?.+...}, at: [&lt;ffffffffa016b17d&gt;] nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[  432.362611] {HARDIRQ-ON-W} state was registered at:
[  432.362686]
[  432.362698] [&lt;ffffffff810adb7c&gt;] __lock_acquire+0x5dc/0x1260
[  432.362812]
[  432.362817] [&lt;ffffffff810aec29&gt;] lock_acquire+0xe9/0x1d0
[  432.362927]
[  432.362934] [&lt;ffffffff81609f63&gt;] _raw_spin_lock+0x33/0x50
[  432.363045]
[  432.363051] [&lt;ffffffffa016b822&gt;] nvt_write_wakeup_codes.isra.12+0x22/0xe0 [nuvoton_cir]
[  432.363193]
[  432.363199] [&lt;ffffffffa016b9bf&gt;] wakeup_data_store+0xdf/0xf0 [nuvoton_cir]
[  432.363327]
[  432.363333] [&lt;ffffffff81484223&gt;] dev_attr_store+0x13/0x20
[  432.363441]
[  432.363449] [&lt;ffffffff81232450&gt;] sysfs_kf_write+0x40/0x50
[  432.363558]
[  432.363564] [&lt;ffffffff81231640&gt;] kernfs_fop_write+0x150/0x1e0
[  432.363676]
[  432.363685] [&lt;ffffffff811b36a3&gt;] __vfs_write+0x23/0x120
[  432.363791]
[  432.363798] [&lt;ffffffff811b4d53&gt;] vfs_write+0xc3/0x1e0
[  432.363902]
[  432.363909] [&lt;ffffffff811b6124&gt;] SyS_write+0x44/0xa0
[  432.364012]
[  432.364021] [&lt;ffffffff81002c47&gt;] do_syscall_64+0x57/0x140
[  432.364129]
[  432.364135] [&lt;ffffffff8160a9e4&gt;] return_from_SYSCALL_64+0x0/0x7a
[  432.364252] irq event stamp: 415118
[  432.364313] hardirqs last  enabled at (415115): [&lt;ffffffff814fd2eb&gt;] cpuidle_enter_state+0x11b/0x370
[  432.364445] hardirqs last disabled at (415116): [&lt;ffffffff8160b2cb&gt;] common_interrupt+0x8b/0x90
[  432.364573] softirqs last  enabled at (415118): [&lt;ffffffff8106157c&gt;] _local_bh_enable+0x1c/0x50
[  432.364699] softirqs last disabled at (415117): [&lt;ffffffff810629a3&gt;] irq_enter+0x43/0x60
[  432.364814]
               other info that might help us debug this:
[  432.364909]  Possible unsafe locking scenario:

[  432.367821]        CPU0
[  432.370645]        ----
[  432.373432]   lock(&amp;(&amp;nvt-&gt;lock)-&gt;rlock);
[  432.376228]   &lt;Interrupt&gt;
[  432.378982]     lock(&amp;(&amp;nvt-&gt;lock)-&gt;rlock);
[  432.381757]
                *** DEADLOCK ***

[  432.389888] no locks held by swapper/0/0.
[  432.392574]
               stack backtrace:
[  432.397774] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc7-next-20170210 #1
[  432.400375] Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
[  432.403023] Call Trace:
[  432.405636]  &lt;IRQ&gt;
[  432.408208]  dump_stack+0x68/0x93
[  432.410775]  print_usage_bug+0x1dd/0x1f0
[  432.413334]  mark_lock+0x559/0x5c0
[  432.415871]  ? print_shortest_lock_dependencies+0x1a0/0x1a0
[  432.418431]  __lock_acquire+0x6b1/0x1260
[  432.420941]  lock_acquire+0xe9/0x1d0
[  432.423396]  ? nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[  432.425844]  _raw_spin_lock+0x33/0x50
[  432.428252]  ? nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[  432.430670]  nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[  432.433085]  __handle_irq_event_percpu+0x43/0x330
[  432.435493]  handle_irq_event_percpu+0x1e/0x50
[  432.437884]  handle_irq_event+0x34/0x60
[  432.440236]  handle_edge_irq+0x6a/0x150
[  432.442561]  handle_irq+0x15/0x20
[  432.444854]  do_IRQ+0x57/0x110
[  432.447115]  common_interrupt+0x90/0x90
[  432.449380] RIP: 0010:cpuidle_enter_state+0x120/0x370
[  432.451653] RSP: 0018:ffffffff81c03dd8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffffcc
[  432.453994] RAX: ffffffff81c14500 RBX: 0000000000000008 RCX: 00000064aac6f2d2
[  432.456349] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff81c14500
[  432.458704] RBP: ffffffff81c03e18 R08: cccccccccccccccd R09: 0000000000000018
[  432.461072] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880100a21260
[  432.463450] R13: ffffffff81c7e6f8 R14: 0000000000000008 R15: ffffffff81c7e6e0
[  432.465819]  &lt;/IRQ&gt;
[  432.468104]  ? cpuidle_enter_state+0x11b/0x370
[  432.470413]  cpuidle_enter+0x12/0x20
[  432.472698]  call_cpuidle+0x1e/0x40
[  432.474967]  do_idle+0xe3/0x1c0
[  432.477172]  cpu_startup_entry+0x18/0x20
[  432.479376]  rest_init+0x130/0x140
[  432.481565]  start_kernel+0x3cc/0x3d9
[  432.483750]  x86_64_start_reservations+0x2a/0x2c
[  432.485980]  x86_64_start_kernel+0x178/0x18b
[  432.488222]  start_cpu+0x14/0x14
[  432.490453]  ? start_cpu+0x14/0x14

Fixes: 97c129747af5 "[media] rc: nuvoton-cir: Add support wakeup via sysfs filter callback"

Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
</entry>
<entry>
<title>[media] lirc: fix dead lock between open and wakeup_filter</title>
<updated>2017-03-03T10:06:57+00:00</updated>
<author>
<name>Sean Young</name>
<email>sean@mess.org</email>
</author>
<published>2017-02-13T12:35:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=db5b15b74ed9a5c04bb808d18ffa2c773f5c18c0'/>
<id>urn:sha1:db5b15b74ed9a5c04bb808d18ffa2c773f5c18c0</id>
<content type='text'>
The locking in lirc needs improvement, but for now just fix this potential
deadlock.

======================================================
[ INFO: possible circular locking dependency detected ]
4.10.0-rc1+ #1 Not tainted
-------------------------------------------------------
bash/2502 is trying to acquire lock:
 (ir_raw_handler_lock){+.+.+.}, at: [&lt;ffffffffc06f6a5e&gt;] ir_raw_encode_scancode+0x3e/0xb0 [rc_core]

               but task is already holding lock:
 (&amp;dev-&gt;lock){+.+.+.}, at: [&lt;ffffffffc06f511f&gt;] store_filter+0x9f/0x240 [rc_core]

               which lock already depends on the new lock.

               the existing dependency chain (in reverse order) is:

               -&gt; #2 (&amp;dev-&gt;lock){+.+.+.}:

[&lt;ffffffffa110adad&gt;] lock_acquire+0xfd/0x200
[&lt;ffffffffa1921327&gt;] mutex_lock_nested+0x77/0x6d0
[&lt;ffffffffc06f436a&gt;] rc_open+0x2a/0x80 [rc_core]
[&lt;ffffffffc07114ca&gt;] lirc_dev_fop_open+0xda/0x1e0 [lirc_dev]
[&lt;ffffffffa12975e0&gt;] chrdev_open+0xb0/0x210
[&lt;ffffffffa128eb5a&gt;] do_dentry_open+0x20a/0x2f0
[&lt;ffffffffa128ffcc&gt;] vfs_open+0x4c/0x80
[&lt;ffffffffa12a35ec&gt;] path_openat+0x5bc/0xc00
[&lt;ffffffffa12a5271&gt;] do_filp_open+0x91/0x100
[&lt;ffffffffa12903f0&gt;] do_sys_open+0x130/0x220
[&lt;ffffffffa12904fe&gt;] SyS_open+0x1e/0x20
[&lt;ffffffffa19278c1&gt;] entry_SYSCALL_64_fastpath+0x1f/0xc2
               -&gt; #1 (lirc_dev_lock){+.+.+.}:
[&lt;ffffffffa110adad&gt;] lock_acquire+0xfd/0x200
[&lt;ffffffffa1921327&gt;] mutex_lock_nested+0x77/0x6d0
[&lt;ffffffffc0711f47&gt;] lirc_register_driver+0x67/0x59b [lirc_dev]
[&lt;ffffffffc06db7f4&gt;] ir_lirc_register+0x1f4/0x260 [ir_lirc_codec]
[&lt;ffffffffc06f6cac&gt;] ir_raw_handler_register+0x7c/0xb0 [rc_core]
[&lt;ffffffffc0398010&gt;] 0xffffffffc0398010
[&lt;ffffffffa1002192&gt;] do_one_initcall+0x52/0x1b0
[&lt;ffffffffa11ef5c8&gt;] do_init_module+0x5f/0x1fa
[&lt;ffffffffa11566b5&gt;] load_module+0x2675/0x2b00
[&lt;ffffffffa1156dcf&gt;] SYSC_finit_module+0xdf/0x110
[&lt;ffffffffa1156e1e&gt;] SyS_finit_module+0xe/0x10
[&lt;ffffffffa1003f5c&gt;] do_syscall_64+0x6c/0x1f0
[&lt;ffffffffa1927989&gt;] return_from_SYSCALL_64+0x0/0x7a
               -&gt; #0 (ir_raw_handler_lock){+.+.+.}:
[&lt;ffffffffa110a7b7&gt;] __lock_acquire+0x10f7/0x1290
[&lt;ffffffffa110adad&gt;] lock_acquire+0xfd/0x200
[&lt;ffffffffa1921327&gt;] mutex_lock_nested+0x77/0x6d0
[&lt;ffffffffc06f6a5e&gt;] ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
[&lt;ffffffffc0b0f492&gt;] loop_set_wakeup_filter+0x62/0xbd [rc_loopback]
[&lt;ffffffffc06f522a&gt;] store_filter+0x1aa/0x240 [rc_core]
[&lt;ffffffffa15e46f8&gt;] dev_attr_store+0x18/0x30
[&lt;ffffffffa13318e5&gt;] sysfs_kf_write+0x45/0x60
[&lt;ffffffffa1330b55&gt;] kernfs_fop_write+0x155/0x1e0
[&lt;ffffffffa1290797&gt;] __vfs_write+0x37/0x160
[&lt;ffffffffa12921f8&gt;] vfs_write+0xc8/0x1e0
[&lt;ffffffffa12936e8&gt;] SyS_write+0x58/0xc0
[&lt;ffffffffa19278c1&gt;] entry_SYSCALL_64_fastpath+0x1f/0xc2

               other info that might help us debug this:

Chain exists of:
                 ir_raw_handler_lock --&gt; lirc_dev_lock --&gt; &amp;dev-&gt;lock

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;dev-&gt;lock);
                               lock(lirc_dev_lock);
                               lock(&amp;dev-&gt;lock);
  lock(ir_raw_handler_lock);

                *** DEADLOCK ***

4 locks held by bash/2502:
 #0:  (sb_writers#4){.+.+.+}, at: [&lt;ffffffffa12922c5&gt;] vfs_write+0x195/0x1e0
 #1:  (&amp;of-&gt;mutex){+.+.+.}, at: [&lt;ffffffffa1330b1f&gt;] kernfs_fop_write+0x11f/0x1e0
 #2:  (s_active#215){.+.+.+}, at: [&lt;ffffffffa1330b28&gt;] kernfs_fop_write+0x128/0x1e0
 #3:  (&amp;dev-&gt;lock){+.+.+.}, at: [&lt;ffffffffc06f511f&gt;] store_filter+0x9f/0x240 [rc_core]

               stack backtrace:
CPU: 3 PID: 2502 Comm: bash Not tainted 4.10.0-rc1+ #1
Hardware name:                  /DG45ID, BIOS IDG4510H.86A.0135.2011.0225.1100 02/25/2011
Call Trace:
 dump_stack+0x86/0xc3
 print_circular_bug+0x1be/0x210
 __lock_acquire+0x10f7/0x1290
 lock_acquire+0xfd/0x200
 ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
 ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
 mutex_lock_nested+0x77/0x6d0
 ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
 ? loop_set_wakeup_filter+0x44/0xbd [rc_loopback]
 ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
 loop_set_wakeup_filter+0x62/0xbd [rc_loopback]
 ? loop_set_tx_duty_cycle+0x70/0x70 [rc_loopback]
 store_filter+0x1aa/0x240 [rc_core]
 dev_attr_store+0x18/0x30
 sysfs_kf_write+0x45/0x60
 kernfs_fop_write+0x155/0x1e0
 __vfs_write+0x37/0x160
 ? rcu_read_lock_sched_held+0x4a/0x80
 ? rcu_sync_lockdep_assert+0x2f/0x60
 ? __sb_start_write+0x10c/0x220
 ? vfs_write+0x195/0x1e0
 ? security_file_permission+0x3b/0xc0
 vfs_write+0xc8/0x1e0
 SyS_write+0x58/0xc0
 entry_SYSCALL_64_fastpath+0x1f/0xc2

Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
</entry>
<entry>
<title>[media] serial_ir: ensure we're ready to receive interrupts</title>
<updated>2017-03-03T09:42:41+00:00</updated>
<author>
<name>Sean Young</name>
<email>sean@mess.org</email>
</author>
<published>2017-02-25T11:28:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0265634eb9e04a16ae99941c320718c38eb865e0'/>
<id>urn:sha1:0265634eb9e04a16ae99941c320718c38eb865e0</id>
<content type='text'>
When the interrupt requested with devm_request_irq(), serial_ir.rcdev
is still null so will cause null deference if the irq handler is called
early on.

Also ensure that timeout_timer is setup.

Link: http://lkml.kernel.org/r/CA+55aFxsh2uF8gi5sN_guY3Z+tiLv7LpJYKBw+y8vqLzp+TsnQ@mail.gmail.com

[mchehab@s-opensource.com: moved serial_ir_probe() back to its original place]

Cc: &lt;stable@vger.kernel.org&gt; # 4.10
Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
</entry>
<entry>
<title>sched/headers: Prepare to move signal wakeup &amp; sigpending methods from &lt;linux/sched.h&gt; into &lt;linux/sched/signal.h&gt;</title>
<updated>2017-03-02T07:42:32+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@kernel.org</email>
</author>
<published>2017-02-02T18:15:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=174cd4b1e5fbd0d74c68cf3a74f5bd4923485512'/>
<id>urn:sha1:174cd4b1e5fbd0d74c68cf3a74f5bd4923485512</id>
<content type='text'>
Fix up affected files that include this signal functionality via sched.h.

Acked-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Mike Galbraith &lt;efault@gmx.de&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>[media] mce_kbd: add missing keys from UK layout</title>
<updated>2017-02-03T16:23:37+00:00</updated>
<author>
<name>Sean Young</name>
<email>sean@mess.org</email>
</author>
<published>2017-02-02T16:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=44750606b9dd2a3a070c3c17d4e44b3a7b363cf7'/>
<id>urn:sha1:44750606b9dd2a3a070c3c17d4e44b3a7b363cf7</id>
<content type='text'>
The UK layout of the Microsoft Remote Keyboard has two missing keys:
the hash key, and the messenger key which is sent using rc6 mce.

Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
</entry>
</feed>
