Overloading dev->s_filter to do two different functions (set wakeup filters
and generic hardware filters) makes it impossible to tell what the
hardware actually supports, so create a separate dev->s_wakeup_filter and
make the distinction explicit.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

rc_map_get() takes a single string literal for the module to load,
so make sure it cannot be used as a format string in the call to
request_module().
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

While playing with make coccicheck I noticed this message:
drivers/media/rc/rc-main.c:1245:3-9: preceding lock on line 1238

It was introduced by commit 587d1b06 ([media] rc-core: reuse device
numbers) which returns -ENOMEM after a mutex_lock without first
unlocking it when there are no more device numbers left. The added code
doesn't depend on the device lock, so move it before the lock is taken.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

When either of the normal or wakeup filter protocols are changed,
refresh the corresponding scancode filter, i.e. try and set the same
scancode filter with the new protocol. If that fails clear the filter
instead.

If no protocol was selected the filter is just cleared, and if no
s_filter callback exists the filter is left unmodified.

Similarly clear the filter mask when the filter is set if no protocol is
currently selected.

This simplifies driver code which no longer has to explicitly worry
about modifying the filter on a protocol change. This also allows the
change_wakeup_protocol callback to be omitted entirely if there is only
a single available wakeup protocol at a time, since selecting no
protocol will automatically clear the wakeup filter, disabling wakeup.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Add a wakeup_protocols sysfs file which controls the new
rc_dev::enabled_protocols[RC_FILTER_WAKEUP], which is the mask of
protocols that are used for the wakeup filter.

A new RC driver callback change_wakeup_protocol() is called to change
the wakeup protocol mask.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Only a single allowed and enabled protocol mask currently exists in
struct rc_dev, however to support a separate wakeup filter protocol two
of each are needed, ideally as an array.

Therefore make both rc_dev::allowed_protos and rc_dev::enabled_protocols
arrays, update all users to reference the first element
(RC_FILTER_NORMAL), and add a couple more helper functions for drivers
to use for setting the allowed and enabled wakeup protocols.

We also rename allowed_protos to allowed_protocols while we're at it,
which is more consistent with enabled_protocols.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Add generic scancode filtering of RC input events, and fall back to
permitting any RC_FILTER_NORMAL scancode filter to be set if no s_filter
callback exists. This allows raw IR decoder events to be filtered, and
potentially allows hardware decoders to set looser filters and rely on
generic code to filter out the corner cases.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Propagate errors returned by drivers from the s_filter callback back to
userland when updating scancode filters. This allows userland to see
when the filter couldn't be updated, usually because it's not a valid
filter for the hardware.

Previously the filter was being updated conditionally on success of
s_filter, but the write always reported success back to userland.
Reported-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

There are several left overs with my old email address.
Remove their occurrences and add myself at CREDITS, to
allow people to be able to reach me on my new addresses.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Add and document a generic sysfs based scancode filtering interface for
making use of IR data matching hardware to filter out uninteresting
scancodes. Two filters exist, one for normal operation and one for
filtering scancodes which are permitted to wake the system from suspend.

The following files are added to /sys/class/rc/rc?/:
 - filter: normal scancode filter value
 - filter_mask: normal scancode filter mask
 - wakeup_filter: wakeup scancode filter value
 - wakeup_filter_mask: wakeup scancode filter mask

A new s_filter() driver callback is added which must arrange for the
specified filter to be applied at the right time. Drivers can convert
the scancode filter into a raw IR data filter, which can be applied
immediately or later (for wake up filters).
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: linux-media@vger.kernel.org
Cc: Rob Landley <rob@landley.net>
Cc: linux-doc@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Add Sharp infrared protocol constants RC_TYPE_SHARP and RC_BIT_SHARP.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Since v3.12, specifically 153a60bb ([media] rc: add feedback led
trigger for rc keypresses), an LED trigger is activated on IR keydown
whether or not a keypress is generated (i.e. even if there's no matching
keycode). However the repeat and keyup logic isn't used unless there is
a keypress, which results in non-keypress keydown events turning on the
LED and not turning it off again.

On the assumption that the intent was for the LED only to light up on
valid key presses (you probably don't want it lighting up for the wrong
remote control for example), move the led_trigger_event() call inside
the keycode check.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Acked-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Fix sparse warning:
	drivers/media/rc/rc-main.c:27:1: sparse: symbol 'ir_core_dev_number' was not declared. Should it be static?
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Before changeset d8b4b582, the remote controller device numbers
were released when the device were unregistered. That helped to maintain
some sanity, as, when USB devices are replugged, the remote controller
would get the same number.

Restore the same behaviour.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

At least technisat-usb2.c doesn't set these...
Signed-off-by: NJuergen Lock <nox@jelal.kn-bremen.de>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Many devices with an ir receiver also have a feedback led. Add the
led trigger to support this.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This patch adds user count to rc_dev structure, the reason to add this
new member is to allow other code like lirc to open rc device directly.
In the existing code, rc device is only opened by input subsystem which
works ok if we have any input drivers to match. But in case like lirc
where there will be no input driver, rc device will be never opened.
Having this user count variable will be usefull to allow rc device to be
opened from code other than rc-main.
This patch also adds rc_open and rc_close functions for other drivers
like lirc to open and close rc devices. This functions safely increment
and decrement the user count. Other driver wanting to open rc device
should call rc_open and rc_close, rather than directly modifying the
rc_dev structure.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for
two reasons. First of all, it is pretty bogus to change the protocol type of
the keymap just because the hardware has been asked to decode a different
protocol.
Second, dev->rc_map.rc_type is an enum (i.e. a single protocol) as pointed
out by James Hogan <james.hogan@imgtec.com>.
Fix both issues by introducing a separate enabled_protocols member to
struct rc_dev.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The name is already misleading and will be more so in the future as the
connection to the input subsystem is obscured away further.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

rc-core is a subsystem so it should be registered earlier if built into the
kernel.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This error path is missing the unlock.

[mchehab@redhat.com: Merged two equal patches into one]
Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
Acked-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We recently introduced a new return -ENODEV in this function but we need
to unlock before returning.

[mchehab@redhat.com: found two patches with the same fix. Merged SOB's/acks into one patch]
Acked-by: NHerton R. Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDouglas Bagnall <douglas@paradise.net.nz>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The RC_TYPE_* defines are currently used both where a single protocol is
expected and where a bitmap of protocols is expected.

Functions like rc_keydown() and functions which add/remove entries to the
keytable want a single protocol. Future userspace APIs would also
benefit from numeric protocols (rather than bitmap ones). Keytables are
smaller if they can use a small(ish) integer rather than a bitmap.

Other functions or struct members (e.g. allowed_protos,
enabled_protocols, etc) accept multiple protocols and need a bitmap.

Using different types reduces the risk of programmer error. Using a
protocol enum whereever possible also makes for a more future-proof
user-space API as we don't need to worry about a sufficient number of
bits being available (e.g. in structs used for ioctl() calls).

The use of both a number and a corresponding bit is dalso one in e.g.
the input subsystem as well (see all the references to set/clear bit when
changing keytables for example).

This patch separate the different usages in preparation for
upcoming patches.

Where a single protocol is expected, enum rc_type is used; where one or more
protocol(s) are expected, something like u64 is used.

The patch has been rewritten so that the format of the sysfs "protocols"
file is no longer altered (at the loss of some detail). The file itself
should probably be deprecated in the future though.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Cc: Andy Walls <awalls@md.metrocast.net>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Mike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

For some reason, when the lirc daemon learns that a usb remote control
has been unplugged, it wants to read the sysfs attributes of the
disappearing device. This is useful for uncovering transient
inconsistencies, but less so for keeping the system running when such
inconsistencies exist.

Under some circumstances (like every time I unplug my dvb stick from
my laptop), lirc catches an rc_dev whose raw event handler has been
removed (presumably by ir_raw_event_unregister), and proceeds to
interrogate the raw protocols supported by the NULL pointer.

This patch avoids the NULL dereference, and ignores the issue of how
this state of affairs came about in the first place.

Version 2 incorporates changes recommended by Mauro Carvalho Chehab
(-ENODEV instead of -EINVAL, and a signed-off-by).
Signed-off-by: NDouglas Bagnall <douglas@paradise.net.nz>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This changes rc_core to not load the IR decoders at load time,
postponing it to load only if a RC_DRIVER_IR_RAW device is
registered via rc_register_device.
We use a static boolean variable, to ensure decoders modules
are only loaded once.
Tested with rc-loopback device only.
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

both callers of device_get_devnode() are only interested in lower 16bits
and nobody tries to return anything wider than 16bit anyway.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This protocol is found on Sanyo/Aiwa remotes.

Tested with an Aiwa RC-7AS06 remote control.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A pending cleanup will mean that module.h won't be implicitly
everywhere anymore.  Make sure the modular drivers in clocksource
are actually calling out for <module.h> explicitly in advance.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

rc unregister logic were deadly broken, preventing some drivers to
be removed. Among the broken things, rc_dev_uevent() is being called
during device_del(), causing a data filling on an area that it is
not ready anymore.

Also, some drivers have a stop callback defined, that needs to be called
before data removal, as it stops data polling.
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is a custom IR protocol decoder, for the RC-6-ish protocol used by
the Microsoft Remote Keyboard, apparently developed internally at
Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and
transceiver requirements and specifications document, which also touches
on this IR keyboard/mouse device.

Its a standard keyboard with embedded thumb stick mouse pointer and
mouse buttons, along with a number of media keys. The media keys are
standard RC-6, identical to the signals from the stock MCE remotes, and
will be handled as such. The keyboard and mouse signals will be decoded
and delivered to the system by an input device registered specifically
by this driver.

Successfully tested with multiple mceusb-driven transceivers, as well as
with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware
with enough sampling resolution should be able to use this decoder,
nothing about it is at all receiver-hardware-specific.

This work is inspired by lirc_mod_mce:

The documentation there and code aided in understanding and decoding the
protocol, but the bulk of the code is actually borrowed more from the
existing in-kernel decoders than anything. I did recycle the keyboard
keycode table, a few defines, and some of the keyboard and mouse data
parsing bits from lirc_mod_mce though.

Special thanks to James Meyer for providing the hardware, and being
patient with me as I took forever to get around to writing this.

callback routine to ensure we don't get any stuck keys, and used
symbolic names for the keytable. Also cc'ing Florian this time, who I
believe is the original mod-mce author...

CC: Florian Demski <fdemski@users.sourceforge.net>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If change_protocol() fails and we goto out_raw, then it calls unlock
twice.  I noticed that the other time we called change_protocol() we
held the &dev->lock, so I changed it to hold it here too.
Reviewed-by: NJarod Wilson <jarod@redhat.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Due to commit cdda911c, evdev only
becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If
we get a repeat or a scancode we don't have a mapping for, we never call
input_sync, and thus those events don't get reported in a timely
fashion.

For example, take an mceusb transceiver with a default rc6 keymap. Press
buttons on an rc5 remote while monitoring with ir-keytable, and you'll
see nothing. Now press a button on the rc6 remote matching the keymap.
You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6
key spit out all at the same time.

Pressing and holding a button on a remote we do have a keymap for also
works rather unreliably right now, due to repeat events also happening
without a call to input_sync (we bail from ir_do_keydown before getting
to the point where it calls input_sync).

Easy fix though, just add two strategically placed input_sync calls
right after our input_event calls for EV_MSC, and all is well again.
Technically, we probably should have been doing this all along, its just
that it never caused any functional difference until the referenced
change went into the input layer.

input_sync once per IR signal. There was another hidden bug in the code
where we were calling input_report_key using last_keycode instead of our
just discovered keycode, which manifested with the reordering of calling
input_report_key and setting last_keycode.
Reported-by: NStephan Raue <sraue@openelec.tv>
CC: Stephan Raue <sraue@openelec.tv>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
CC: Jeff Brown <jeffbrown@android.com>
Acked-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The default REP_PERIOD is 33 ms. This doesn't make sense for IR's,
as, in general, an IR repeat scancode is provided at every 110/115ms,
depending on the RC protocol. So, increase its default, to do a
better job avoiding ghost repeat events.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: NJarod Wilson <jarod@redhat.com>

When device_add is called in rc_register_device, the rc sysfs nodes show
up, and there's a window in which ir-keytable can be launched via udev
and trigger a show_protocols call, which runs without various rc_dev
fields filled in yet. Add some locking around registration and
store/show_protocols to prevent that from happening.

The problem manifests thusly:

[64692.957872] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
[64692.957878] IP: [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core]
[64692.957890] PGD 19cfc7067 PUD 19cfc6067 PMD 0
[64692.957894] Oops: 0000 [#1] SMP
[64692.957897] last sysfs file: /sys/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/rc/rc2/protocols
[64692.957902] CPU 3
[64692.957903] Modules linked in: redrat3(+) ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_hauppauge ir_nec
_decoder rc_core ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_mi
di_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem pcsp
kr tg3 snd_hwdep emu10k1_gp snd amd64_edac_mod gameport edac_core soundcore edac_mce_amd k8temp shpchp i2c_piix4 lm63 e100 mii uinput ipv6 raid0 rai
d1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t sata_svw pata_serverworks floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core
[last unloaded: redrat3]
[64692.957949] [64692.957952] Pid: 12265, comm: ir-keytable Tainted: G   M    W   2.6.39-rc6+ #2 empty empty/TYAN Thunder K8HM S3892
[64692.957957] RIP: 0010:[<ffffffffa036a4c1>]  [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core]
[64692.957962] RSP: 0018:ffff880194509e38  EFLAGS: 00010202
[64692.957964] RAX: 0000000000000000 RBX: ffffffffa036d1e0 RCX: ffffffffa036a47a
[64692.957966] RDX: ffff88019a84d000 RSI: ffffffffa036d1e0 RDI: ffff88019cf2f3f0
[64692.957969] RBP: ffff880194509e68 R08: 0000000000000002 R09: 0000000000000000
[64692.957971] R10: 0000000000000002 R11: 0000000000001617 R12: ffff88019a84d000
[64692.957973] R13: 0000000000001000 R14: ffff8801944d2e38 R15: ffff88019ce5f190
[64692.957976] FS:  00007f0a30c9a720(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
[64692.957979] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[64692.957981] CR2: 0000000000000090 CR3: 000000019a8e0000 CR4: 00000000000006e0
[64692.957983] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[64692.957986] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[64692.957989] Process ir-keytable (pid: 12265, threadinfo ffff880194508000, task ffff88019a9fc720)
[64692.957991] Stack:
[64692.957992]  0000000000000002 ffffffffa036d1e0 ffff880194509f58 0000000000001000
[64692.957997]  ffff8801944d2e38 ffff88019ce5f190 ffff880194509e98 ffffffff8131484b
[64692.958001]  ffffffff8118e923 ffffffff810e9b2f ffff880194509e98 ffff8801944d2e18
[64692.958005] Call Trace:
[64692.958014]  [<ffffffff8131484b>] dev_attr_show+0x27/0x4e
[64692.958014]  [<ffffffff8118e923>] ? sysfs_read_file+0x94/0x172
[64692.958014]  [<ffffffff810e9b2f>] ? __get_free_pages+0x16/0x52
[64692.958014]  [<ffffffff8118e94c>] sysfs_read_file+0xbd/0x172
[64692.958014]  [<ffffffff8113205e>] vfs_read+0xac/0xf3
[64692.958014]  [<ffffffff8113347b>] ? fget_light+0x3a/0xa1
[64692.958014]  [<ffffffff811320f2>] sys_read+0x4d/0x74
[64692.958014]  [<ffffffff814c19c2>] system_call_fastpath+0x16/0x1b

Its a bit difficult to reproduce, but I'm fairly confident this has
fixed the problem.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The following is a patch to avoid a kernel oops when running rmmod
saa7134 on kernel 2.6.27.1. The change is as suggested by mchehab on
irc.freenode.org
Signed-off-by: NHussam Al-Tayeb <ht990332@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

With the current matching rules the lookup for rc protocol named rc-5-sz matches with "rc-5" before finding "rc-5-sz". Thus one is able to never enable/disable the rc-5-sz protocol via sysfs.

Fix the lookup to require an exact match which allows the manipulation of sz protocol.
Signed-off-by: NAntti Seppälä <a.seppala@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

All users of old style get/setkeycode methids have been converted so
it is time to retire them.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Do not respond with -EINVAL to EVIOCGKEYCODE for not-yet-mapped
scancodes, but rather return KEY_RESERVED.

This fixes breakage with Ubuntu's input-kbd utility that stopped
returning full keymaps for remote controls.
Tested-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Tested-by: NMark Lord <kernel@teksavvy.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>