usb: cdns2: Add main part of Cadence USBHS driver

This patch introduces the main part of Cadence USBHS driver
to Linux kernel.
To reduce the patch size a little bit, the header file gadget.h was
int

usb: cdns2: Add main part of Cadence USBHS driver

This patch introduces the main part of Cadence USBHS driver
to Linux kernel.
To reduce the patch size a little bit, the header file gadget.h was
intentionally added as separate patch.

The Cadence USB 2.0 Controller is a highly configurable IP Core which
supports both full and high speed data transfer.

The current driver has been validated with FPGA platform. We have
support for PCIe bus, which is used on FPGA prototyping.

Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Message-ID: <20230602102644.77470-3-pawell@cadence.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

usb: gadget: Add support for RZ/V2M USB3DRD driver

The RZ/V2M USB3.1 Gen1 Interface (USB) composed of a USB3.1 Gen1 Dual Role
Device controller (USB3DRD), a USB3.1 Gen1 Host controller (USB3HOST), a

usb: gadget: Add support for RZ/V2M USB3DRD driver

The RZ/V2M USB3.1 Gen1 Interface (USB) composed of a USB3.1 Gen1 Dual Role
Device controller (USB3DRD), a USB3.1 Gen1 Host controller (USB3HOST), a
USB3.1 Gen1 Peripheral controller (USB3PERI).

The reset for both host and peri are located in USB3DRD block. The
USB3DRD registers are mapped in the AXI address space of the Peripheral
module.

Add USB3DRD driver to handle reset for both host and peri modules.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230121145853.4792-6-biju.das.jz@bp.renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

usb: gadget: udc: add Renesas RZ/N1 USBF controller support

Add support for the Renesas USBF controller.
This controller is an USB2.0 UDC controller available in the
Renesas r9a06g032 SoC (RZ/N1 fam

usb: gadget: udc: add Renesas RZ/N1 USBF controller support

Add support for the Renesas USBF controller.
This controller is an USB2.0 UDC controller available in the
Renesas r9a06g032 SoC (RZ/N1 family).

Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://lore.kernel.org/r/20230105152257.310642-4-herve.codina@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

usb: gadget: remove s3c24xx drivers

The s3c24xx platform is gone, so both the udc and hsudc drivers
can be removed as well.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-

usb: gadget: remove s3c24xx drivers

The s3c24xx platform is gone, so both the udc and hsudc drivers
can be removed as well.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

show more ...

usb: fotg210: Collect pieces of dual mode controller

The Faraday FOTG210 is a dual-mode OTG USB controller that can
act as host, peripheral or both. To be able to probe from one
hardware description

usb: fotg210: Collect pieces of dual mode controller

The Faraday FOTG210 is a dual-mode OTG USB controller that can
act as host, peripheral or both. To be able to probe from one
hardware description and to follow the pattern of other dual-
mode controllers such as MUSB or MTU3 we need to collect the
two, currently completely separate drivers in the same
directory.

After this, users need to select the main symbol USB_FOTG210
and then each respective subdriver. We pave the road to
compile both drivers into the same kernel and select the
one we want to use at probe() time, and possibly add OTG
support in the end.

This patch doesn't do much more than create the new symbol
and collect the drivers in one place. We also add a comment
for the section of dual-mode controllers in the Kconfig
file so people can see what these selections are about.

Also add myself as maintainer as there has been little
response on my patches to these drivers.

Cc: Fabian Vogt <fabian@ritter-vogt.de>
Cc: Yuan-Hsin Chen <yhchen@faraday-tech.com>
Cc: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20221023144708.3596563-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

usb: gadget: add Aspeed ast2600 udc driver

Aspeed udc is compliant with USB2.0, supports USB High Speed
and Full Speed, backward compatible with USB1.1.

Supports independent DMA channel for each ge

usb: gadget: add Aspeed ast2600 udc driver

Aspeed udc is compliant with USB2.0, supports USB High Speed
and Full Speed, backward compatible with USB1.1.

Supports independent DMA channel for each generic endpoint.
Supports 32/256 stages descriptor mode for all generic endpoints.

This driver supports full functionality including single/multiple
stages descriptor mode, and exposes 1 UDC gadget driver.

Signed-off-by: Neal Liu <neal_liu@aspeedtech.com>
Link: https://lore.kernel.org/r/20220523030134.2977116-2-neal_liu@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

usb: gadget: fsl_mxc_udc: Remove the driver

Since 5.10-rc1 i.MX is a devicetree-only platform, and this driver
was only used by the old non-DT i.MX devices.

Remove the driver as it has no users lef

usb: gadget: fsl_mxc_udc: Remove the driver

Since 5.10-rc1 i.MX is a devicetree-only platform, and this driver
was only used by the old non-DT i.MX devices.

Remove the driver as it has no users left.

Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Peter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20201210210413.15262-1-festevam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

usb: gadget: add udc driver for max3420

The MAX3420 is USB2.0 only, UDC-over-SPI controller. This driver
also supports the peripheral mode of MAX3421.

Signed-off-by: Jassi Brar <jaswinder.singh@lin

usb: gadget: add udc driver for max3420

The MAX3420 is USB2.0 only, UDC-over-SPI controller. This driver
also supports the peripheral mode of MAX3421.

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

show more ...

usb: gadget: Add UDC driver for tegra XUSB device mode controller

This patch adds UDC driver for tegra XUSB 3.0 device mode controller.
XUSB device mode controller supports SS, HS and FS modes

Base

usb: gadget: Add UDC driver for tegra XUSB device mode controller

This patch adds UDC driver for tegra XUSB 3.0 device mode controller.
XUSB device mode controller supports SS, HS and FS modes

Based on work by:
Mark Kuo <mkuo@nvidia.com>
Hui Fu <hfu@nvidia.com>
Andrew Bresticker <abrestic@chromium.org>

Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

show more ...

usb/gadget: Add driver for Aspeed SoC virtual hub

The Aspeed BMC SoCs support a "virtual hub" function. It provides some
HW support for a top-level USB2 hub behind which sit 5 gadget "ports".

This

usb/gadget: Add driver for Aspeed SoC virtual hub

The Aspeed BMC SoCs support a "virtual hub" function. It provides some
HW support for a top-level USB2 hub behind which sit 5 gadget "ports".

This driver adds support for the full functionality, emulating the
hub standard requests and exposing 5 UDC gadget drivers corresponding
to the ports.

The hub itself has HW provided dedicated EP0 and EP1 (the latter for
hub interrupts). It also has dedicated EP0s for each function. For
other endpoints, there's a pool of 15 "generic" endpoints that are
shared among the ports.

The driver relies on my previous patch adding a "dispose" EP op to
handle EP allocation between ports. EPs are allocated from the shared
pool in the UDC "match_ep" callback and assigned to the UDC instance
(added to the gadget ep_list).

When the composite driver gets unbound, the new hook will allow the UDC
to clean things up and return those EPs to the shared pool.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

show more ...

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

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>

show more ...

usb: gadget: udc: Add Synopsys UDC Platform driver

This patch adds platform driver support for Synopsys UDC.

A new driver file (snps_udc_plat.c) is created for this purpose
where the platform drive

usb: gadget: udc: Add Synopsys UDC Platform driver

This patch adds platform driver support for Synopsys UDC.

A new driver file (snps_udc_plat.c) is created for this purpose
where the platform driver registration is done based on OF
node.

Currently, UDC integrated into Broadcom's iProc SoCs (Northstar2
and Cygnus) work with this driver.

New members are added to the UDC data structure for having platform
device support along with extcon and phy support.

Kconfig and Makefiles are modified to select platform driver for
compilation.

Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

show more ...

usb: gadget: udc: Rename amd5536udc driver file based on IP

This patch renames the amd5536udc.c that has the core driver
functionality of Synopsys UDC to snps_udc_core.c

The symbols exported here c

usb: gadget: udc: Rename amd5536udc driver file based on IP

This patch renames the amd5536udc.c that has the core driver
functionality of Synopsys UDC to snps_udc_core.c

The symbols exported here can be used by any UDC driver that uses
the same Synopsys IP.

Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

show more ...

usb: gadget: udc: amd5536: split core and PCI layer

This patch splits the amd5536udc driver into two -- one that does
pci device registration and the other file that does the rest of
the driver task

usb: gadget: udc: amd5536: split core and PCI layer

This patch splits the amd5536udc driver into two -- one that does
pci device registration and the other file that does the rest of
the driver tasks like the gadget/ep ops etc for Synopsys UDC.

This way of splitting helps in exporting core driver symbols which
can be used by any other platform/pci driver that is written for
the same Synopsys USB device controller.

The current patch also includes a change in the Kconfig and Makefile.
A new config option USB_SNP_CORE will be selected automatically when
any one of the platform or pci driver for the same UDC is selected.

Main changes:
- amd5536udc_pci.c: PCI device registration is moved to this file.

- amd5536udc.c:
This file does rest of the core UDC fucntionality.
9 symbols are exported so as to be used by amd5536udc_pci.c.
Module parameter definitions are moved to header file.

- amd5536udc.h:
Function declarations, module parameters definitions and few common
header file includes are added to this file

- Kconfig:
New USB_SNP_CORE option is added which will be auto selected when
any pci or platform driver config option for the UDC is chosen.

- Makefile:
Compiles the core and pci files separately.

Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

show more ...

usb: gadget: add tracepoints to the gadget API

This new set of tracepoints will help all gadget
drivers and UDC drivers when problem appears. Note
that, in order to be able to add tracepoints to
udc

usb: gadget: add tracepoints to the gadget API

This new set of tracepoints will help all gadget
drivers and UDC drivers when problem appears. Note
that, in order to be able to add tracepoints to
udc-core.c we had to rename that to core.c and
statically link it with trace.c to form
udc-core.o. This is to make sure that module name
stays the same.

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

show more ...

usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller

R-Car H3 has USB3.0 peripheral controllers. This controller's has the
following features:
- Supports super, high and

usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller

R-Car H3 has USB3.0 peripheral controllers. This controller's has the
following features:
- Supports super, high and full speed
- Contains 30 pipes for bulk or interrupt transfer
- Contains dedicated DMA controller

This driver doesn't support the dedicated DMAC for now.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

show more ...

usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

This patch adds a UDC driver for Broadcom's USB3.0 Peripheral core named BDC.
BDC supports control traffic on ep0 and bulk/In

usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

This patch adds a UDC driver for Broadcom's USB3.0 Peripheral core named BDC.
BDC supports control traffic on ep0 and bulk/Int/Isoch traffic on all other
endpoints.

[ balbi@ti.com : fix build error on randconfig due to lack of
<linux/dmapool.h> ]

Signed-off-by: Ashwini Pahuja <ashwini.linux@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

show more ...

usb: gadget: Add xilinx usb2 device support

Xilinx USB2 device is a soft IP which supports both full
and high speed USB 2.0 data transfers. This patch adds
xilinx usb2 device driver support.

Signed

usb: gadget: Add xilinx usb2 device support

Xilinx USB2 device is a soft IP which supports both full
and high speed USB 2.0 data transfers. This patch adds
xilinx usb2 device driver support.

Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

show more ...

usb: gadget: Gadget directory cleanup - group UDC drivers

The drivers/usb/gadget directory contains many files.
Files which are related can be distributed into separate directories.
This patch moves

usb: gadget: Gadget directory cleanup - group UDC drivers

The drivers/usb/gadget directory contains many files.
Files which are related can be distributed into separate directories.
This patch moves the UDC drivers into a separate directory.

Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

show more ...

usb: gadget: add udc driver for max3420

The MAX3420 is USB2.0 only, UDC-over-SPI controller. This driver
also supports the peripheral mode of MAX3421.

Signed-off-by: Jassi Brar

usb: gadget: add udc driver for max3420

The MAX3420 is USB2.0 only, UDC-over-SPI controller. This driver
also supports the peripheral mode of MAX3421.

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

show more ...

usb: gadget: Add UDC driver for tegra XUSB device mode controller

This patch adds UDC driver for tegra XUSB 3.0 device mode controller.
XUSB device mode controller supports SS, HS and FS

usb: gadget: Add UDC driver for tegra XUSB device mode controller

This patch adds UDC driver for tegra XUSB 3.0 device mode controller.
XUSB device mode controller supports SS, HS and FS modes

Based on work by:
Mark Kuo <mkuo@nvidia.com>
Hui Fu <hfu@nvidia.com>
Andrew Bresticker <abrestic@chromium.org>

Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

show more ...

usb/gadget: Add driver for Aspeed SoC virtual hub

The Aspeed BMC SoCs support a "virtual hub" function. It provides some
HW support for a top-level USB2 hub behind which sit 5 gadget "po

usb/gadget: Add driver for Aspeed SoC virtual hub

The Aspeed BMC SoCs support a "virtual hub" function. It provides some
HW support for a top-level USB2 hub behind which sit 5 gadget "ports".

This driver adds support for the full functionality, emulating the
hub standard requests and exposing 5 UDC gadget drivers corresponding
to the ports.

The hub itself has HW provided dedicated EP0 and EP1 (the latter for
hub interrupts). It also has dedicated EP0s for each function. For
other endpoints, there's a pool of 15 "generic" endpoints that are
shared among the ports.

The driver relies on my previous patch adding a "dispose" EP op to
handle EP allocation between ports. EPs are allocated from the shared
pool in the UDC "match_ep" callback and assigned to the UDC instance
(added to the gadget ep_list).

When the composite driver gets unbound, the new hook will allow the UDC
to clean things up and return those EPs to the shared pool.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

show more ...

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

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>

show more ...

usb: gadget: udc: Add Synopsys UDC Platform driver

This patch adds platform driver support for Synopsys UDC.

A new driver file (snps_udc_plat.c) is created for this purpose
wher

usb: gadget: udc: Add Synopsys UDC Platform driver

This patch adds platform driver support for Synopsys UDC.

A new driver file (snps_udc_plat.c) is created for this purpose
where the platform driver registration is done based on OF
node.

Currently, UDC integrated into Broadcom's iProc SoCs (Northstar2
and Cygnus) work with this driver.

New members are added to the UDC data structure for having platform
device support along with extcon and phy support.

Kconfig and Makefiles are modified to select platform driver for
compilation.

Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

show more ...

usb: gadget: udc: Rename amd5536udc driver file based on IP

This patch renames the amd5536udc.c that has the core driver
functionality of Synopsys UDC to snps_udc_core.c

The sym

usb: gadget: udc: Rename amd5536udc driver file based on IP

This patch renames the amd5536udc.c that has the core driver
functionality of Synopsys UDC to snps_udc_core.c

The symbols exported here can be used by any UDC driver that uses
the same Synopsys IP.

Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

show more ...