License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2009-12-11 11:00:00 +00:00
|
|
|
|
2010-04-02 23:01:00 +00:00
|
|
|
obj-y += keymaps/
|
|
|
|
|
|
2010-11-17 16:28:38 +00:00
|
|
|
obj-$(CONFIG_RC_CORE) += rc-core.o
|
2017-09-23 14:41:13 +00:00
|
|
|
rc-core-y := rc-main.o rc-ir-raw.o
|
2017-11-02 20:39:16 +00:00
|
|
|
rc-core-$(CONFIG_LIRC) += lirc_dev.o
|
2021-02-26 10:37:47 +00:00
|
|
|
rc-core-$(CONFIG_MEDIA_CEC_RC) += keymaps/rc-cec.o
|
2018-05-27 11:24:09 +00:00
|
|
|
rc-core-$(CONFIG_BPF_LIRC_MODE2) += bpf-lirc.o
|
2010-03-24 23:47:53 +00:00
|
|
|
obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
|
2010-04-04 13:27:20 +00:00
|
|
|
obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
|
2010-04-08 23:04:40 +00:00
|
|
|
obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
|
2010-04-15 21:46:05 +00:00
|
|
|
obj-$(CONFIG_IR_JVC_DECODER) += ir-jvc-decoder.o
|
2010-04-15 21:46:10 +00:00
|
|
|
obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o
|
2011-11-23 15:04:08 +00:00
|
|
|
obj-$(CONFIG_IR_SANYO_DECODER) += ir-sanyo-decoder.o
|
2014-01-17 13:58:48 +00:00
|
|
|
obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
|
[media] rc-core support for Microsoft IR keyboard/mouse
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: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-13 21:09:48 +00:00
|
|
|
obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
|
2014-07-26 20:28:26 +00:00
|
|
|
obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
|
2017-12-03 16:06:54 +00:00
|
|
|
obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
|
2019-01-17 08:50:13 +00:00
|
|
|
obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
|
2010-04-16 21:29:02 +00:00
|
|
|
|
|
|
|
|
# stand-alone IR receivers/transmitters
|
2011-08-06 21:18:07 +00:00
|
|
|
obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
|
2014-08-31 02:39:10 +00:00
|
|
|
obj-$(CONFIG_IR_HIX5HD2) += ir-hix5hd2.o
|
2010-04-16 21:29:02 +00:00
|
|
|
obj-$(CONFIG_IR_IMON) += imon.o
|
2018-01-05 19:58:51 +00:00
|
|
|
obj-$(CONFIG_IR_IMON_RAW) += imon_raw.o
|
2011-03-16 20:14:52 +00:00
|
|
|
obj-$(CONFIG_IR_ITE_CIR) += ite-cir.o
|
2010-06-01 20:32:08 +00:00
|
|
|
obj-$(CONFIG_IR_MCEUSB) += mceusb.o
|
[media] fintek-cir: new driver for Fintek LPC SuperIO CIR function
This is a new driver for the Fintek LPC SuperIO CIR function, in the
Fintek F71809 chip. Hardware and datasheets were provided by Fintek, so
thanks go to them for supporting this effort.
This driver started out as a copy of the nuvoton-cir driver, and was
then modified as needed for the Fintek chip. The two share many
similaries, though the buffer handling for the Fintek chip is actually
nearly identical to the mceusb buffer handling, so the parser routine is
almost a drop-in copy of the mceusb buffer parser (a candidate for being
abstracted out into shared code at some point).
This initial code drop *only* supports receive, but the hardware does
support transmit as well. I really haven't even started to look at
what's required, but my guess is that its also pretty similar to mceusb.
Most people are probably only really interested in RX anyway though, so
I think its good to get this out there even with only RX.
(Nb: there are also Fintek-made mceusb receivers, which presumably, this
chip shares CIR hardware with).
This hardware can be found on at least Jetway NC98 boards and derivative
systems, and likely others as well. Functionality was tested with an
NC98 development board, in-kernel decode of RC6 (mce), RC5 (hauppauge)
and NEC-ish (tivo) remotes all successful, as was lirc userspace decode
of the RC6 remote.
CC: Aaron Huang <aaron_huang@fintek.com.tw>
CC: Tom Tsai <tom_tsai@fintek.com.tw>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-25 16:35:13 +00:00
|
|
|
obj-$(CONFIG_IR_FINTEK) += fintek-cir.o
|
2014-11-18 20:22:34 +00:00
|
|
|
obj-$(CONFIG_IR_MESON) += meson-ir.o
|
2021-07-19 17:05:06 +00:00
|
|
|
obj-$(CONFIG_IR_MESON_TX) += meson-ir-tx.o
|
[media] IR: add driver for Nuvoton w836x7hg integrated CIR
This is a new ir-core pnp driver for the Nuvoton w836x7hg integrated CIR
function. The chip is found on at least the ASRock ION 330HT boxes and
apparently, on a number of Intel DP55-series motherboards:
http://www.asrock.com/nettop/overview.asp?Model=ION%20330HT
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17685&lang=eng
This driver was made possible by a hardware donation from Nuvoton, along
with sample code (in the form of an lirc driver) and datasheet, so huge
thanks to them for supporting this effort. Note that this driver
constitutes a massive rewrite, porting from the lirc interfaces to the
ir-core interfaces, and restructuring the driver to look more like Maxim
Levitsky's ene_ir driver (as well as generally making it look more like
kernel code).
There's some work left to be done on this driver, to fully support the
range of functionality possible, but receive and IR power-on/wake are
both functional (may require setting wake key under another OS atm). The
hardware I've got (one of the ASRock boxes) only supports RX, so TX is
completely untested as of yet. Certain RX parameters, like sample
resolution and RX IRQ sample length trigger level could possibly stand
to be made tweakable via modparams or sysfs nodes, but the current
values work well enough for me w/an MCE RC6A remote.
The original lirc driver carried support for the Windows MCE IR
keyboard/mouse device, which I plan to add back generically, in a way
that should be usable by any raw IR receiver (or at least by this driver
and the mceusb driver).
Suspend and resume have also been tested, the power button on my remote
can be used to wake the machine, and CIR functionality resumes just
fine. Module unload/reload has also been tested, though not extensively
or repetitively. Also tested to work with the lirc bridge plugin for
userspace decoding.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-10-07 20:50:34 +00:00
|
|
|
obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
|
2010-07-31 14:59:26 +00:00
|
|
|
obj-$(CONFIG_IR_ENE) += ene_ir.o
|
[media] redrat3: new rc-core IR transceiver device driver
This is a new rc-core device driver for the IR transceivers made by
RedRat Ltd. (http://redrat.co.uk/). It started out life as an
out-of-lirc-tree lirc driver, maintained in its own repo on sourceforge,
by Stephen Cox. He started porting it to what was then ir-core, and I
finally picked it up about two week ago and did a fairly large overhaul
on it, and its now into a state where I'm fairly comfortable submitting
it here for review and inclusion in the kernel. I'm claiming authorship
of this driver, since while it started out as Stephen's work, its
definitely a derivative work now, at 876 lines added and 1698 lines
removed since grabbing it from sourceforge. Stephen's name is retained
as secondary author though, and credited in the headers. Those
interested in seeing how the changes evolved can (at least for now) look
at this branch in my git tree:
http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/redrat3
That won't be around forever though, and I'm doing this as a single
commit to go into mainline. Anyway...
I've successfully tested in-kernel decode of rc5, rc6 and nec remotes,
as well as lirc userspace decode of rc5 and rc6. There are still some
quirks here to sort out with rc5 lirc userspace decode, but I'm working
with the RedRat folks themselves to figure out what's going on there
(rc5 lirc decode works, but you only get an event on key release --
in-kernel rc5 decode behaves perfectly fine). Note that lirc decode of
rc6 is working perfectly. Transmit is also working, tested by pointing
the redrat3 at an mceusb transceiver, which happily picked up the
transmitted signals and properly decoded them.
There's no default remote for this hardware, so its somewhat arbitrarily
set to use the Hauppauge RC5 keymap by default. Easily changed out by
way of ir-keytable and irrelevant if you're using lircd for decode.
CC: Chris Dodge <chris@redrat.co.uk>
CC: Andrew Vincer <Andrew.Vincer@redrat.co.uk>
CC: Stephen Cox <scox_nz@yahoo.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-04 17:02:42 +00:00
|
|
|
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
|
2012-08-10 09:16:36 +00:00
|
|
|
obj-$(CONFIG_IR_RX51) += ir-rx51.o
|
[media] rc: add support for IR LEDs driven through SPI
The ir-spi is a simple device driver which supports the
connection between an IR LED and the MOSI line of an SPI device.
The driver, indeed, uses the SPI framework to stream the raw data
provided by userspace through an rc character device. The chardev
is handled by the LIRC framework and its functionality basically
provides:
- write: the driver gets a pulse/space signal and translates it
to a binary signal that will be streamed to the IR led through
the SPI framework.
- set frequency: sets the frequency whith which the data should
be sent. This is handle with ioctl with the
LIRC_SET_SEND_CARRIER flag (as per lirc documentation)
- set duty cycle: this is also handled with ioctl with the
LIRC_SET_SEND_DUTY_CYCLE flag. The driver handles duty cycles
of 50%, 60%, 70%, 75%, 80% and 90%, calculated on 16bit data.
The character device is created under /dev/lircX name, where X is
and ID assigned by the LIRC framework.
Example of usage:
fd = open("/dev/lirc0", O_RDWR);
if (fd < 0)
return -1;
val = 608000;
ret = ioctl(fd, LIRC_SET_SEND_CARRIER, &val);
if (ret < 0)
return -1;
val = 60;
ret = ioctl(fd, LIRC_SET_SEND_DUTY_CYCLE, &val);
if (ret < 0)
return -1;
n = write(fd, buffer, BUF_LEN);
if (n < 0 || n != BUF_LEN)
ret = -1;
close(fd);
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-16 06:12:18 +00:00
|
|
|
obj-$(CONFIG_IR_SPI) += ir-spi.o
|
2010-08-02 18:46:03 +00:00
|
|
|
obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
|
2010-10-29 19:08:28 +00:00
|
|
|
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
|
2010-11-25 21:36:27 +00:00
|
|
|
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
|
2012-02-28 04:51:40 +00:00
|
|
|
obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
|
2017-07-07 09:51:59 +00:00
|
|
|
obj-$(CONFIG_IR_GPIO_TX) += gpio-ir-tx.o
|
2017-07-07 09:52:02 +00:00
|
|
|
obj-$(CONFIG_IR_PWM_TX) += pwm-ir-tx.o
|
2014-10-23 20:58:22 +00:00
|
|
|
obj-$(CONFIG_IR_IGORPLUGUSB) += igorplugusb.o
|
2012-07-15 16:31:00 +00:00
|
|
|
obj-$(CONFIG_IR_IGUANA) += iguanair.o
|
2012-08-13 11:59:46 +00:00
|
|
|
obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
|
2013-10-18 09:01:14 +00:00
|
|
|
obj-$(CONFIG_RC_ST) += st_rc.o
|
2014-06-08 18:08:10 +00:00
|
|
|
obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
|
2014-02-28 23:28:55 +00:00
|
|
|
obj-$(CONFIG_IR_IMG) += img-ir/
|
2016-11-21 21:55:53 +00:00
|
|
|
obj-$(CONFIG_IR_SERIAL) += serial_ir.o
|
2017-01-13 07:35:39 +00:00
|
|
|
obj-$(CONFIG_IR_MTK) += mtk-cir.o
|
2018-10-09 16:02:11 +00:00
|
|
|
obj-$(CONFIG_RC_XBOX_DVD) += xbox_remote.o
|
2020-05-03 09:27:55 +00:00
|
|
|
obj-$(CONFIG_IR_TOY) += ir_toy.o
|
