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 22:07:57 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2005-04-17 06:20:36 +08:00
|
|
|
#
|
|
|
|
# linux/drivers/nand/Makefile
|
|
|
|
#
|
|
|
|
|
2010-03-19 23:22:54 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND) += nand.o
|
|
|
|
obj-$(CONFIG_MTD_NAND_ECC) += nand_ecc.o
|
2011-03-11 18:05:33 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_BCH) += nand_bch.o
|
2010-02-23 02:39:39 +08:00
|
|
|
obj-$(CONFIG_MTD_SM_COMMON) += sm_common.o
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-10-06 22:36:29 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_CAFE) += cafe_nand.o
|
2006-05-22 01:11:55 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_AMS_DELTA) += ams-delta.o
|
2010-05-13 22:57:33 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_DENALI) += denali.o
|
2012-09-28 00:58:05 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_DENALI_PCI) += denali_pci.o
|
2012-09-28 00:58:06 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_DENALI_DT) += denali_dt.o
|
2005-04-17 06:20:36 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_AU1550) += au1550nd.o
|
2007-10-03 04:56:05 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_BF5XX) += bf5xx_nand.o
|
2005-04-17 06:20:36 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_S3C2410) += s3c2410.o
|
2016-10-26 00:10:47 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_TANGO) += tango_nand.o
|
2009-03-05 04:01:37 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_DAVINCI) += davinci_nand.o
|
2005-04-17 06:20:36 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_DISKONCHIP) += diskonchip.o
|
mtd: nand: add support for diskonchip G4 nand flash device
This patch adds a driver for the M-Sys / Sandisk diskonchip G4 nand flash found
in various smartphones and PDAs, among them the Palm Treo680, HTC Prophet and
Wizard, Toshiba Portege G900, Asus P526, and O2 XDA Zinc. It was tested on the
Treo 680, but should work generically.
Since v3, this patch adds power management functions, a scan of the factory bad
block table during initialization, several fixes, and more extensive testing.
Also, the platform data header file, which only contained partitioning
information, was removed. Command-line partitioning can be used, at least until
an mtd parser is written for the saftl format with which these chips are
shipped.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Reviewed-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-01-04 08:05:44 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_DOCG4) += docg4.o
|
2010-09-13 06:35:22 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_FSMC) += fsmc_nand.o
|
2005-04-17 06:20:36 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_SHARPSL) += sharpsl.o
|
|
|
|
obj-$(CONFIG_MTD_NAND_NANDSIM) += nandsim.o
|
2006-05-12 05:35:28 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_CS553X) += cs553x_nand.o
|
2006-05-23 17:43:28 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o
|
mtd: nand: Cleanup/rework the atmel_nand driver
This is a complete rewrite of the driver whose main purpose is to
support the new DT representation where the NAND controller node is now
really visible in the DT and appears under the EBI bus. With this new
representation, we can add other devices under the EBI bus without
risking pinmuxing conflicts (the NAND controller is under the EBI
bus logic and as such, share some of its pins with other devices
connected on this bus).
Even though the goal of this rework was not necessarily to add new
features, the new driver has been designed with this in mind. With a
clearer separation between the different blocks and different IP
revisions, adding new functionalities should be easier (we already
have plans to support SMC timing configuration so that we no longer
have to rely on the configuration done by the bootloader/bootstrap).
Also note that we no longer have a custom ->cmdfunc() implementation,
which means we can now benefit from new features added in the core
implementation for free (support for new NAND operations for example).
The last thing that we gain with this rework is support for multi-chips
and multi-dies chips, thanks to the clean NAND controller <-> NAND
devices representation.
During this transition we also dropped support for AVR32 SoCs which
should soon disappear from mainline (removal of the AVR32 arch is
planned for 4.12).
This new driver has been tested on several platforms (at91sam9261,
at91sam9g45, at91sam9x5, sama5d3 and sama5d4) to make sure it did not
introduce regressions, and it's worth mentioning that old bindings are
still supported (which partly explain the positive diffstat).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
2017-03-16 16:02:40 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_ATMEL) += atmel/
|
2008-10-15 14:38:49 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_GPIO) += gpio.o
|
2015-08-21 18:45:35 +08:00
|
|
|
omap2_nand-objs := omap2.o
|
|
|
|
obj-$(CONFIG_MTD_NAND_OMAP2) += omap2_nand.o
|
2014-10-01 19:33:29 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_OMAP_BCH_BUILD) += omap_elm.o
|
2007-04-22 13:53:21 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o
|
2008-02-14 15:48:23 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_PXA3xx) += pxa3xx_nand.o
|
2008-07-15 23:04:22 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_TMIO) += tmio_nand.o
|
2007-05-06 23:31:18 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_PLATFORM) += plat_nand.o
|
2007-11-29 08:37:31 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_PASEMI) += pasemi_nand.o
|
2007-10-17 07:10:40 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_ORION) += orion_nand.o
|
2016-10-20 16:49:01 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_OXNAS) += oxnas_nand.o
|
2008-02-07 05:36:21 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_FSL_ELBC) += fsl_elbc_nand.o
|
2012-03-15 13:34:23 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_FSL_IFC) += fsl_ifc_nand.o
|
2008-03-12 03:33:13 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_FSL_UPM) += fsl_upm.o
|
2012-06-07 18:22:15 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_SLC_LPC32XX) += lpc32xx_slc.o
|
2012-07-01 00:50:38 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_MLC_LPC32XX) += lpc32xx_mlc.o
|
2008-10-14 20:23:26 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_SH_FLCTL) += sh_flctl.o
|
2008-09-02 23:16:59 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_MXC) += mxc_nand.o
|
2009-03-25 18:48:38 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_SOCRATES) += socrates_nand.o
|
2009-03-05 04:01:34 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_TXX9NDFMC) += txx9ndfmc.o
|
2010-01-01 20:16:47 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_NUC900) += nuc900_nand.o
|
2010-02-16 01:35:05 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
|
2015-09-03 09:06:33 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_VF610_NFC) += vf610_nfc.o
|
2010-02-23 02:39:42 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_RICOH) += r852.o
|
2010-07-17 19:15:29 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
|
2016-01-04 20:34:43 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_JZ4780) += jz4780_nand.o jz4780_bch.o
|
2011-09-08 10:47:11 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/
|
2012-08-24 02:28:32 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o
|
2012-11-12 20:03:21 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/
|
2014-10-21 21:08:41 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o
|
2015-01-25 18:53:13 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o
|
mtd: nand: add NAND driver "library" for Broadcom STB NAND controller
This core originated in Set-Top Box chips (BCM7xxx) but is used in a
variety of other Broadcom chips, including some BCM63xxx, BCM33xx, and
iProc/Cygnus. It's been used only on ARM and MIPS SoCs, so restrict it
to those architectures.
There are multiple revisions of this core throughout the years, and
almost every version broke register compatibility in some small way, but
with some effort, this driver is able to support v4.0, v5.0, v6.x, v7.0,
and v7.1. It's been tested on v5.0, v6.0, v6.1, v7.0, and v7.1 recently,
so there hopefully are no more lurking inconsistencies.
This patch adds just some library support, on which platform drivers can
be built.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
2015-03-07 03:38:08 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/
|
mtd: nand: Qualcomm NAND controller driver
The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx,
MDM9x15 series.
It exists as a sub block inside the IPs EBI2 (External Bus Interface 2)
and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a
broader interface for external slow peripheral devices such as LCD and
NAND/NOR flash memory or SRAM like interfaces.
We add support for the NAND controller found within EBI2. For the SoCs
of our interest, we only use the NAND controller within EBI2. Therefore,
it's safe for us to assume that the NAND controller is a standalone block
within the SoC.
The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND
flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and
16 bit correction/step) and RS ECC(4 bit correction/step) that covers main
and spare data. The controller contains an internal 512 byte page buffer
to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA
for register read/write and data transfers. The controller performs page
reads and writes at a codeword/step level of 512 bytes. It can support up
to 2 external chips of different configurations.
The driver prepares register read and write configuration descriptors for
each codeword, followed by data descriptors to read or write data from the
controller's internal buffer. It uses a single ADM DMA channel that we get
via dmaengine API. The controller requires 2 ADM CRCIs for command and
data flow control. These are passed via DT.
The ecc layout used by the controller is syndrome like, but we can't use
the standard syndrome ecc ops because of several reasons. First, the amount
of data bytes covered by ecc isn't same in each step. Second, writing to
free oob space requires us writing to the entire step in which the oob
lies. This forces us to create our own ecc ops.
One more difference is how the controller accesses the bad block marker.
The controller ignores reading the marker when ECC is enabled. ECC needs
to be explicity disabled to read or write to the bad block marker. The
nand_bbt helpers library hence can't access BBMs for the controller.
For now, we skip the creation of BBT and populate chip->block_bad and
chip->block_markbad helpers instead.
Reviewed-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-02-03 16:59:50 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_QCOM) += qcom_nandc.o
|
2017-10-28 14:52:23 +08:00
|
|
|
obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2016-05-25 05:07:46 +08:00
|
|
|
nand-objs := nand_base.o nand_bbt.o nand_timings.o nand_ids.o
|
2016-06-08 16:42:23 +08:00
|
|
|
nand-objs += nand_amd.o
|
2016-06-08 16:30:18 +08:00
|
|
|
nand-objs += nand_hynix.o
|
2016-06-08 16:43:26 +08:00
|
|
|
nand-objs += nand_macronix.o
|
2016-06-08 16:38:57 +08:00
|
|
|
nand-objs += nand_micron.o
|
2016-06-08 16:22:19 +08:00
|
|
|
nand-objs += nand_samsung.o
|
2016-06-08 16:34:57 +08:00
|
|
|
nand-objs += nand_toshiba.o
|