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>
7 years ago
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
menu "Device Drivers"
|
|
|
|
|
|
|
|
|
|
source "drivers/amba/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/base/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/bus/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/connector/Kconfig"
|
|
|
|
|
|
BACKPORT: gnss: add GNSS receiver subsystem
Add a new subsystem for GNSS (e.g. GPS) receivers.
While GNSS receivers are typically accessed using a UART interface they
often also support other I/O interfaces such as I2C, SPI and USB, while
yet other devices use iomem or even some form of remote-processor
messaging (rpmsg).
The new GNSS subsystem abstracts the underlying interface and provides a
new "gnss" class type, which exposes a character-device interface (e.g.
/dev/gnss0) to user space. This allows GNSS receivers to have a
representation in the Linux device model, something which is important
not least for power management purposes.
Note that the character-device interface provides raw access to whatever
protocol the receiver is (currently) using, such as NMEA 0183, UBX or
SiRF Binary. These protocols are expected to be continued to be handled
by user space for the time being, even if some hybrid solutions are also
conceivable (e.g. to have kernel drivers issue management commands).
This will still allow for better platform integration by allowing GNSS
devices and their resources (e.g. regulators and enable-gpios) to be
described by firmware and managed by kernel drivers rather than
platform-specific scripts and services.
While the current interface is kept minimal, it could be extended using
IOCTLs, sysfs or uevents as needs and proper abstraction levels are
identified and determined (e.g. for device and feature identification).
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2b6a440351436d792b1960822da4b7d6e673f568)
[adelva: adjusted for drivers/Makefile conflict, __poll_t->unsigned int,
EPOLL* -> POLL* for 4.14]
Bug: 146062677
Change-Id: I5704e952766cd8057fba3be3212091a726e0d85a
Signed-off-by: Alistair Delva <adelva@google.com>
7 years ago
|
|
|
source "drivers/gnss/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/mtd/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/of/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/parport/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/pnp/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/block/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/nvme/Kconfig"
|
|
|
|
|
|
|
|
|
|
# misc before ide - BLK_DEV_SGIIOC4 depends on SGI_IOC4
|
|
|
|
|
|
|
|
|
|
source "drivers/misc/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/ide/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/scsi/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/ata/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/md/Kconfig"
|
|
|
|
|
|
[SCSI] target: Add LIO target core v4.0.0-rc6
LIO target is a full featured in-kernel target framework with the
following feature set:
High-performance, non-blocking, multithreaded architecture with SIMD
support.
Advanced SCSI feature set:
* Persistent Reservations (PRs)
* Asymmetric Logical Unit Assignment (ALUA)
* Protocol and intra-nexus multiplexing, load-balancing and failover (MC/S)
* Full Error Recovery (ERL=0,1,2)
* Active/active task migration and session continuation (ERL=2)
* Thin LUN provisioning (UNMAP and WRITE_SAMExx)
Multiprotocol target plugins
Storage media independence:
* Virtualization of all storage media; transparent mapping of IO to LUNs
* No hard limits on number of LUNs per Target; maximum LUN size ~750 TB
* Backstores: SATA, SAS, SCSI, BluRay, DVD, FLASH, USB, ramdisk, etc.
Standards compliance:
* Full compliance with IETF (RFC 3720)
* Full implementation of SPC-4 PRs and ALUA
Significant code cleanups done by Christoph Hellwig.
[jejb: fix up for new block bdev exclusive interface. Minor fixes from
Randy Dunlap and Dan Carpenter.]
Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
14 years ago
|
|
|
source "drivers/target/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/message/fusion/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/firewire/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/macintosh/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/net/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/isdn/Kconfig"
|
|
|
|
|
|
lightnvm: Support for Open-Channel SSDs
Open-channel SSDs are devices that share responsibilities with the host
in order to implement and maintain features that typical SSDs keep
strictly in firmware. These include (i) the Flash Translation Layer
(FTL), (ii) bad block management, and (iii) hardware units such as the
flash controller, the interface controller, and large amounts of flash
chips. In this way, Open-channels SSDs exposes direct access to their
physical flash storage, while keeping a subset of the internal features
of SSDs.
LightNVM is a specification that gives support to Open-channel SSDs
LightNVM allows the host to manage data placement, garbage collection,
and parallelism. Device specific responsibilities such as bad block
management, FTL extensions to support atomic IOs, or metadata
persistence are still handled by the device.
The implementation of LightNVM consists of two parts: core and
(multiple) targets. The core implements functionality shared across
targets. This is initialization, teardown and statistics. The targets
implement the interface that exposes physical flash to user-space
applications. Examples of such targets include key-value store,
object-store, as well as traditional block devices, which can be
application-specific.
Contributions in this patch from:
Javier Gonzalez <jg@lightnvm.io>
Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Jesper Madsen <jmad@itu.dk>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
9 years ago
|
|
|
source "drivers/lightnvm/Kconfig"
|
|
|
|
|
|
|
|
|
|
# input before char - char/joystick depends on it. As does USB.
|
|
|
|
|
|
|
|
|
|
source "drivers/input/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/char/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/i2c/Kconfig"
|
|
|
|
|
|
[PATCH] spi: simple SPI framework
This is the core of a small SPI framework, implementing the model of a
queue of messages which complete asynchronously (with thin synchronous
wrappers on top).
- It's still less than 2KB of ".text" (ARM). If there's got to be a
mid-layer for something so simple, that's the right size budget. :)
- The guts use board-specific SPI device tables to build the driver
model tree. (Hardware probing is rarely an option.)
- This version of Kconfig includes no drivers. At this writing there
are two known master controller drivers (PXA/SSP, OMAP MicroWire)
and three protocol drivers (CS8415a, ADS7846, DataFlash) with LKML
mentions of other drivers in development.
- No userspace API. There are several implementations to compare.
Implement them like any other driver, and bind them with sysfs.
The changes from last version posted to LKML (on 11-Nov-2005) are minor,
and include:
- One bugfix (removes a FIXME), with the visible effect of making device
names be "spiB.C" where B is the bus number and C is the chipselect.
- The "caller provides DMA mappings" mechanism now has kerneldoc, for
DMA drivers that want to be fancy.
- Hey, the framework init can be subsys_init. Even though board init
logic fires earlier, at arch_init ... since the framework init is
for driver support, and the board init support uses static init.
- Various additional spec/doc clarifications based on discussions
with other folk. It adds a brief "thank you" at the end, for folk
who've helped nudge this framework into existence.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
19 years ago
|
|
|
source "drivers/spi/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/spmi/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/slimbus/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/hsi/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/pps/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/ptp/Kconfig"
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
14 years ago
|
|
|
source "drivers/pinctrl/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/gpio/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/gnsssirf/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/w1/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/power/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/hwmon/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/thermal/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/watchdog/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/ssb/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/bcma/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/mfd/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/regulator/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/media/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/video/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "sound/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/hid/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/usb/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/uwb/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/mmc/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/memstick/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/leds/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/switch/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/accessibility/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/infiniband/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/edac/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/rtc/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/dma/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/dma-buf/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/dca/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/auxdisplay/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/uio/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/vfio/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/vlynq/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/virt/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/virtio/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/hv/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/xen/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/vservices/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/staging/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/muic/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/rid_adc/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/afc/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/platform/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/clk/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/hwspinlock/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/clocksource/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/mailbox/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/iommu/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/remoteproc/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/rpmsg/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/soc/Kconfig"
|
|
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
13 years ago
|
|
|
source "drivers/devfreq/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/extcon/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/memory/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/iio/Kconfig"
|
|
|
|
|
|
PCI-Express Non-Transparent Bridge Support
A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
connecting 2 systems, providing electrical isolation between the two subsystems.
A non-transparent bridge is functionally similar to a transparent bridge except
that both sides of the bridge have their own independent address domains. The
host on one side of the bridge will not have the visibility of the complete
memory or I/O space on the other side of the bridge. To communicate across the
non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
the local system. Writes to these apertures are mirrored to memory on the
remote system. Communications can also occur through the use of doorbell
registers that initiate interrupts to the alternate domain, and scratch-pad
registers accessible from both sides.
The NTB device driver is needed to configure these memory windows, doorbell, and
scratch-pad registers as well as use them in such a way as they can be turned
into a viable communication channel to the remote system. ntb_hw.[ch]
determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
the underlying hardware to provide access and a common interface to the doorbell
registers, scratch pads, and memory windows. These hardware interfaces are
exported so that other, non-mainlined kernel drivers can access these.
ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
communication channel(s) and provide a reliable way of transferring data from
one side to the other, which it then exports so that "client" drivers can access
them. These client drivers are used to provide a standard kernel interface
(i.e., Ethernet device) to NTB, such that Linux can transfer data from one
system to the other in a standard way.
Signed-off-by: Jon Mason <jon.mason@intel.com>
Reviewed-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years ago
|
|
|
source "drivers/ntb/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/vme/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/pwm/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/gpu/msm/Kconfig"
|
|
|
|
|
|
ARM: bcm2835: add interrupt controller driver
The BCM2835 contains a custom interrupt controller, which supports 72
interrupt sources using a 2-level register scheme. The interrupt
controller, or the HW block containing it, is referred to occasionally
as "armctrl" in the SoC documentation, hence the symbol naming in the
code.
This patch was extracted from git://github.com/lp0/linux.git branch
rpi-split as of 2012/09/08, and modified as follows:
* s/bcm2708/bcm2835/.
* Modified device tree vendor prefix.
* Moved implementation to drivers/irchip/.
* Added devicetree documentation, and hence removed list of IRQs from
bcm2835.dtsi.
* Changed shift in MAKE_HWIRQ() and HWIRQ_BANK() from 8 to 5 to reduce
the size of the hwirq space, and pass the total size of the hwirq space
to irq_domain_add_linear(), rather than just the number of valid hwirqs;
the two are different due to the hwirq space being sparse.
* Added the interrupt controller DT node to the top-level of the DT,
rather than nesting it inside a /axi node. Hence, changed the reg value
since /axi had a ranges property. This seems simpler to me, but I'm not
sure if everyone will like this change or not.
* Don't set struct irq_domain_ops.map = irq_domain_simple_map, hence
removing the need to patch include/linux/irqdomain.h or
kernel/irq/irqdomain.c.
* Simplified armctrl_of_init() using of_iomap().
* Removed unused IS_VALID_BANK()/IS_VALID_IRQ() macros.
* Renamed armctrl_handle_irq() to prevent possible symbol clashes.
* Made armctrl_of_init() static.
* Removed comment "Each bank is registered as a separate interrupt
controller" since this is no longer true.
* Removed FSF address from license header.
* Added my name to copyright header.
Signed-off-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Signed-off-by: Dom Cobley <dc4@broadcom.com>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
12 years ago
|
|
|
source "drivers/irqchip/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/ipack/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/reset/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/fmc/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/phy/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/powercap/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/mcb/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/perf/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/ras/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/thunderbolt/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/android/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/gpu/trace/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/nvdimm/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/dax/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/nvmem/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/hwtracing/stm/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/hwtracing/intel_th/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/fpga/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/fsi/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/tee/Kconfig"
|
|
|
|
|
|
mux: minimal mux subsystem
Add a new minimalistic subsystem that handles multiplexer controllers.
When multiplexers are used in various places in the kernel, and the
same multiplexer controller can be used for several independent things,
there should be one place to implement support for said multiplexer
controller.
A single multiplexer controller can also be used to control several
parallel multiplexers, that are in turn used by different subsystems
in the kernel, leading to a need to coordinate multiplexer accesses.
The multiplexer subsystem handles this coordination.
Thanks go out to Lars-Peter Clausen, Jonathan Cameron, Rob Herring,
Wolfram Sang, Paul Gortmaker, Dan Carpenter, Colin Ian King, Greg
Kroah-Hartman and last but certainly not least to Philipp Zabel for
helpful comments, reviews, patches and general encouragement!
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 years ago
|
|
|
source "drivers/mux/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/sensors/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/esoc/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/samsung/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/battery/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/battery_v2/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/battery_qc/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/staging/samsung/sec_notifier/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/adsp_factory/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/fingerprint/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/motor/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/security/samsung/five_tee_driver/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/security/samsung/icdrv/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/ccic/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/security/samsung/tzic/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/spu_verify/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/kernelsu/Kconfig"
|
|
|
|
|
endmenu
|
