02 Nov, 2017
1 commit
-
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
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
19 Feb, 2016
1 commit
-
The ARM version of asm/gpio.h basically just contains the same definitions
as the gpiolib version, with the exception of ARCH_NR_GPIOS.This adds the option for overriding the constant through Kconfig to
the architecture-independent header, so we can remove the ARM specific
file later.Signed-off-by: Arnd Bergmann
Signed-off-by: Linus Walleij
12 May, 2015
1 commit
-
Remove gpiod_sysfs_set_active_low (and gpio_sysfs_set_active_low) which
allowed code to change the polarity of a gpio line even after it had
been exported through sysfs.Drivers should not care, and generally does not know, about gpio-line
polarity which is a hardware feature that needs to be described by
firmware.It is currently possible to define gpio-line polarity in device-tree and
acpi firmware or using platform data. Userspace can also change the
polarity through sysfs.Note that drivers using the legacy gpio interface could still use
GPIOF_ACTIVE_LOW to change the polarity before exporting the gpio.There are no in-kernel users of this interface.
Cc: Jonathan Corbet
Cc: Harry Wei
Cc: Arnd Bergmann
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@zh-kernel.org
Cc: linux-arch@vger.kernel.org
Signed-off-by: Johan Hovold
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij
19 Mar, 2015
1 commit
-
These functions do not belong in since the
split into separate GPIO headers under . Move them
to as is apropriate.Acked-by: Alexandre Courbot
Signed-off-by: Linus Walleij
23 Sep, 2014
1 commit
-
Some newer Intel SoCs, like Braswell already have more than 256 GPIOs
available so the default limit is exceeded. Instead of adding more
architecture specific gpio.h files with custom ARCH_NR_GPIOs we increase
the gpiolib default limit to be twice the current.Current generic ARCH_NR_GPIOS limit is 256 which starts to be too small
for newer Intel SoCs like Braswell. In order to support GPIO controllers
on these SoCs we increase ARCH_NR_GPIOS to be 512 which should be
sufficient for now.The kernel size increases a bit with this change. Below is an example of
x86_64 kernel image.ARCH_NR_GPIOS=256
text data bss dec hex filename
11476173 1971328 1265664 14713165 e0814d vmlinuxARCH_NR_GPIOS=512
text data bss dec hex filename
11476173 1971328 1269760 14717261 e0914d vmlinuxSo the BSS size and this the kernel image size increases by 4k.
Signed-off-by: Mika Westerberg
Signed-off-by: Linus Walleij
25 Jul, 2014
1 commit
-
gpio_ensure_requested() has been introduced in Feb. 2008 by commit
d2876d08d86f2 to force users of the GPIO API to explicitly request GPIOs
before using them.Hopefully by now all GPIOs are correctly requested and this extra check
can be omitted ; in any case the GPIO maintainers won't feel bad if
machines start failing after 6 years of warnings.This patch removes that function from the dark ages.
Signed-off-by: Alexandre Courbot
Signed-off-by: Linus Walleij
23 Jul, 2014
2 commits
-
gpio_ensure_requested() only makes sense when using the integer-based
GPIO API, so make sure it is called from there instead of the gpiod
API which we know cannot be called with a non-requested GPIO anyway.The uses of gpio_ensure_requested() in the gpiod API were kind of
out-of-place anyway, so putting them in gpio-legacy.c helps clearing the
code.Actually, considering the time this ensure_requested mechanism has been
around, maybe we should just turn this patch into "remove
gpio_ensure_requested()" if we know for sure that no user depend on it
anymore?Signed-off-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and
are thus not using the old integer namespace. Therefore, there is no
reason to have gpiod variants of these functions working with
descriptors, especially since the (chip, offset) tuple is more suitable
to the users of these functions (GPIO drivers, whereas GPIO descriptors
are targeted at GPIO consumers).Signed-off-by: Alexandre Courbot
Signed-off-by: Linus Walleij
07 Feb, 2014
1 commit
-
The documentation was not clear about whether
gpio_direction_output should take a logical value or the physical
level on the output line, i.e. whether the ACTIVE_LOW status
would be taken into account.This converts gpiod_direction_output to use the logical level
and adds a new gpiod_direction_output_raw for the raw value.Signed-off-by: Philipp Zabel
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij
12 Nov, 2013
1 commit
-
Pull GPIO changes from Linus Walleij:
"Here is the bulk of GPIO changes for the v3.13 development cycle.I've got ACKs for the things that affect other subsystems (or it's my
own subsystem, like pinctrl). Most of that pertain to an attempt from
my side to consolidate and get rid of custom GPIO implementations in
the ARM tree. I will continue doing this.The main change this time is the new GPIO descriptor API, background
for this can be found in Corbet's summary from this january in LWN:http://lwn.net/Articles/533632/
Summary:
- Merged the GPIO descriptor API from Alexandre Courbot. This is a
first step toward trying to get rid of the global GPIO numberspace
for the future.- Add an API so that driver can flag that a certain GPIO line is
being used by a irqchip backend for generating IRQs, so that we can
enforce checks, like not allowing users to switch that line to an
output at runtime, since this makes no sense. Implemented
corresponding calls in a few select drivers.- ACPI GPIO cleanups, refactorings and switch to using the
descriptor-based interface.- Support for the TPS80036 Palmas GPIO variant.
- A new driver for the Broadcom Kona GPIO SoC IP block.
- Device tree support for the PCF857x driver.
- A set of ARM GPIO refactorings with the goal of getting rid of a
bunch of custom GPIO implementations from the arch/arm/* tree:* Move the IOP GPIO driver to the GPIO subsystem and fix all users
to use the gpiolib API for accessing GPIOs. Delete the old
custom GPIO implementation.* Delete the unused custom PXA GPIO implemention.
* Convert all users of the IXP4 custom GPIO implementation to use
gpiolib and delete the custom implementation.* Delete the custom Gemini GPIO implementation, also completely
unused.- Various cleanups and renamings"
* tag 'gpio-v3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (85 commits)
gpio: gpio-mxs: Remove unneeded dt checks
gpio: pl061: don't depend on CONFIG_ARM
gpio: bcm-kona: add missing .owner to struct gpio_chip
gpiolib: provide a declaration of seq_file in gpio/driver.h
gpiolib: include gpio/consumer.h in of_gpio.h for desc_to_gpio()
gpio: provide stubs for devres gpio functions
gpiolib: devres: add missing headers
gpiolib: make GPIO_DEVRES depend on GPIOLIB
gpiolib: devres: fix devm_gpiod_get_index()
gpiolib / ACPI: document the GPIO descriptor based interface
gpiolib / ACPI: allow passing GPIOF_ACTIVE_LOW for GpioInt resources
gpiolib / ACPI: add ACPI support for gpiod_get_index()
gpiolib / ACPI: convert to gpiod interfaces
gpiolib: add gpiod_get() and gpiod_put() functions
gpiolib: port of_ functions to use gpiod
gpiolib: export descriptor-based GPIO interface
Fixup "MAINTAINERS: GPIO-INTEL-MID: add maintainer"
gpio: bcm281xx: Don't print addresses of GPIO area in probe()
gpio: tegra: use new gpio_lock_as_irq() API
gpio: rcar: Include linux/of.h header
...
20 Oct, 2013
1 commit
-
This patch exports the gpiod_* family of API functions, a safer
alternative to the legacy GPIO interface. Differences between the gpiod
and legacy gpio APIs are:- gpio works with integers, whereas gpiod operates on opaque handlers
which cannot be forged or used before proper acquisition
- gpiod get/set functions are aware of the active low state of a GPIO
- gpio consumers should now include to access
the new interface, whereas chips drivers will use
The legacy gpio API is now built as inline functions on top of gpiod.
Signed-off-by: Alexandre Courbot
Signed-off-by: Linus Walleij
16 Oct, 2013
2 commits
-
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.Signed-off-by: Christian Ruppert
Signed-off-by: Linus Walleij -
It is currently often possible in many GPIO drivers to request
a GPIO line to be used as IRQ after calling gpio_to_irq() and,
as the gpiolib is not aware of this, set the same line to
output and start driving it, with undesired side effects.As it is a bogus usage scenario to request a line flagged as
output to used as IRQ, we introduce APIs to let gpiolib track
the use of a line as IRQ, and also set this flag from the
userspace ABI.The API is symmetric so that lines can also be flagged from
.irq_enable() and unflagged from IRQ by .irq_disable().
The debugfs file is altered so that we see if a line is
reserved for IRQ.Cc: Enric Balletbo i Serra
Cc: Grant Likely
Cc: Jean-Christophe PLAGNIOL-VILLARD
Cc: Santosh Shilimkar
Acked-by: Alexandre Courbot
Reviewed-by: Stephen Warren
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Linus Walleij
12 Feb, 2013
1 commit
-
Add a pointer to the gpio_chip structure that references the array of
GPIO descriptors belonging to the chip, and update gpiolib code to use
this pointer instead of the global gpio_desc[] array. This is another
step towards the removal of the gpio_desc[] global array.Signed-off-by: Alexandre Courbot
Reviewed-by: Linus Walleij
Signed-off-by: Grant Likely
09 Feb, 2013
1 commit
-
Add a list member to gpio_chip that allows all chips to be parsed
quickly. The current method requires parsing the entire GPIO integer
space, which is painfully slow. Using a list makes many chip operations
that involve lookup or parsing faster, and also simplifies the code. It
is also necessary to eventually get rid of the global gpio_desc[] array.The list of gpio_chips is always ordered by base GPIO number to ensure
chips traversal is done in the right order.Signed-off-by: Alexandre Courbot
Reviewed-by: Linus Walleij
Signed-off-by: Grant Likely
05 Feb, 2013
1 commit
-
gpiochip_reserve() has no user and stands in the way of the removal of
the static gpio_desc[] array. Remove this function as well as the now
unneeded RESERVED flag of struct gpio_desc.Signed-off-by: Alexandre Courbot
Signed-off-by: Linus Walleij
22 Jan, 2013
2 commits
-
Some architectures (e.g. blackfin) provide gpio API without requiring
GPIOLIB support (ARCH_WANT_OPTIONAL_GPIOLIB). devm_gpio_* functions
should also work for these architectures, since they do not really
depend on GPIOLIB.Add a new option GPIO_DEVRES (enabled by default) to control the build
of devres.c. It also removes the empty version of devm_gpio_*
functions for !GENERIC_GPIO build from linux/gpio.h, and moves the
function declarations from asm-generic/gpio.h into linux/gpio.h.Signed-off-by: Shawn Guo
Signed-off-by: Linus Walleij -
The struct gpio_chip is only defined inside #ifdef CONFIG_GPIOLIB,
but it's referenced by gpiochip_add_pin_range() and
gpiochip_remove_pin_ranges() which are outside #ifdef CONFIG_GPIOLIB.
Thus, we see the following warning when building blackfin image, where
GPIOLIB is not required.CC arch/blackfin/kernel/bfin_gpio.o
CC init/version.o
In file included from arch/blackfin/include/asm/gpio.h:321,
from arch/blackfin/kernel/bfin_gpio.c:15:
include/asm-generic/gpio.h:298: warning: 'struct gpio_chip' declared inside parameter list
include/asm-generic/gpio.h:298: warning: its scope is only this definition or declaration, which is probably not what you want
include/asm-generic/gpio.h:304: warning: 'struct gpio_chip' declared inside parameter listMove pinctrl trunk into #ifdef CONFIG_GPIOLIB to fix the warning,
since it appears that pinctrl gpio range support depends on GPIOLIB.Signed-off-by: Shawn Guo
Signed-off-by: Linus Walleij
12 Dec, 2012
1 commit
-
Pull GPIO updates from Grant Likely:
"GPIO follow up patch and type change for v3.5 merge windowPrimarily device driver additions, features and bug fixes. Not much
touching gpio common subsystem support. Should not be scary."* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6: (34 commits)
gpio: Provide the STMPE GPIO driver with its own IRQ Domain
gpio: add TS-5500 DIO blocks support
gpio: pcf857x: use client->irq for gpio_to_irq()
gpio: stmpe: Add DT support for stmpe gpio
gpio: pl061 depends on ARM
gpio/pl061: remove old comment
gpio: SPEAr: add spi chipselect control driver
gpio: gpio-max710x: Support device tree probing
gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration
gpio: tegra: read output value when gpio is set in direction_out
gpio: pca953x: Add compatible strings to gpio-pca953x driver
gpio: pca953x: Register an IRQ domain
gpio: mvebu: Set free callback for gpio_chip
gpio: tegra: Drop exporting static functions
gpio: tegra: Staticize non-exported symbols
gpio: tegra: fix suspend/resume apis
gpio-pch: Set parent dev for gpio chip
gpio: em: Fix build errors
GPIO: clps711x: use platform_device_unregister in gpio_clps711x_init()
gpio/tc3589x: convert to use the simple irqdomain
...
21 Nov, 2012
2 commits
-
To be crystal clear on what the arguments mean in this
funtion dealing with both GPIO and PIN ranges with confusing
naming, we now have gpio_offset and pin_offset and we are
on the clear that these are offsets into the specific GPIO
and pin controller respectively. The GPIO chip itself will
of course keep track of the base offset into the global
GPIO number space.Reviewed-by: Viresh Kumar
Signed-off-by: Linus Walleij -
Like with commit 3c739ad0df5eb41cd7adad879eda6aa09879eb76
it is not always enough to specify all the pins of a gpio_chip
from offset zero to be added to a pin map range, since the
mapping from GPIO to pin controller may not be linear at all,
but need to be broken into a few consecutive sub-ranges or
1-pin entries for complicated cases. The ranges may also be
sparse.This alters the signature of the function to accept offsets
into both the GPIO-chip local pinspace and the pin controller
local pinspace.Reviewed-by: Stephen Warren
Reviewed-by: Viresh Kumar
Signed-off-by: Linus Walleij
12 Nov, 2012
4 commits
-
The includes are updated again: now we need to account
for the problem introduced by commit:
595679a8038584df7b9398bf34f61db3c038bfea
"gpiolib: fix up function prototypes etc"Actually we need static inlines in include/asm-generic/gpio.h
as well since we may have GPIOLIB but not PINCTRL.
Make sure to move all the CONFIG_PINCTRL business
to the end of the file so we are sure we have
declared struct gpio_chip.And we need to keep the static inlines in
but here for the !CONFIG_GENERIC_GPIO case, and then we
may as well throw in a few warnings like the other
prototypes there, if someone would have the bad taste
of compiling without GENERIC_GPIO even.Signed-off-by: Linus Walleij
-
The fact that of_gpiochip_add_pin_range() and
gpiochip_add_pin_range() share too much code is fragile and
will invariably mean that bugs need to be fixed in two places
instead of one.So separate the concerns of gpiolib.c and gpiolib-of.c and
have the latter call the former as back-end. This is necessary
also when going forward with other device descriptions such
as ACPI.This is done by:
- Adding a return code to gpiochip_add_pin_range() so we can
reliably check whether this succeeds.- Get rid of the custom of_pinctrl_add_gpio_range() from
pinctrl. Instead create of_pinctrl_get() to just retrive the
pin controller per se from an OF node. This composite
function was just begging to be deleted, it was way to
purpose-specific.- Use pinctrl_dev_get_name() to get the name of the retrieved
pin controller and use that to call back into the generic
gpiochip_add_pin_range().Now the pin range is only allocated and tied to a pin
controller from the core implementation in gpiolib.c.Signed-off-by: Linus Walleij
-
Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"Got most of it's function prototypes wrong, so fix this up by:
- Moving the void declarations into static inlines in
(previously the actual prototypes were declared
here...)- Declare the gpiochip_add_pin_range() and
gpiochip_remove_pin_ranges() functions in
together with the pin range struct declaration itself.- Actually only implement these very functions in gpiolib.c
if CONFIG_PINCTRL is set.- Additionally export the symbols since modules will need to
be able to do this.Reviewed-by: Stephen Warren
Signed-off-by: Linus Walleij -
pinctrl subsystem needs gpio chip base to prepare set of gpio
pin ranges, which a given pinctrl driver can handle. This is
important to handle pinctrl gpio request calls in order to
program a given pin properly for gpio operation.As gpio base is allocated dynamically during gpiochip
registration, presently there exists no clean way to pass this
information to the pinctrl subsystem.After few discussions from [1], it was concluded that may be
gpio controller reporting the pin range it supports, is a
better way than pinctrl subsystem directly registering it.[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816
Cc: Grant Likely
Signed-off-by: Viresh Kumar
Signed-off-by: Shiraz Hashim
[Edited documentation a bit]
Signed-off-by: Linus Walleij
26 Oct, 2012
1 commit
-
Add .get_direction callback to gpio_chip. This allows gpiolib
to check the current direction of a gpio.
Used to show the correct gpio direction in sysfs and debug entries.If callback is not set then gpiolib will work as previously;
e.g. guessing everything is input until a direction is set.Signed-off-by: Mathias Nyman
Signed-off-by: Linus Walleij
30 Sep, 2012
1 commit
-
This patch adds documentation for set_debounce in struct device_node.
Signed-off-by: Roland Stigge
Signed-off-by: Linus Walleij
19 May, 2012
3 commits
-
Commit 3d0f7cf0 "gpio: Adjust of_xlate API to support multiple GPIO
chips" changed the api of gpiochip_find to drop const from the data
parameter of the match hook, but didn't also drop const from data
causing a build warning.Signed-off-by: Grant Likely
-
This patch changes the of_xlate API to make it possible for multiple
gpio_chips to refer to the same device tree node. This is useful for
banked GPIO controllers that use multiple gpio_chips for a single
device. With this change the core code will try calling of_xlate on
each gpio_chip that references the device_node and will return the
gpio number for the first one to return 'true'.Tested-by: Roland Stigge
Acked-by: Arnd Bergmann
Signed-off-by: Grant Likely -
Allow drivers to use the modern request and configure idiom together
with devres.As with plain gpio_request() and gpio_request_one() we can't implement
the old school version in terms of _one() as this would force the
explicit selection of a direction in gpio_request() which could break
systems if we pick the wrong one. Implementing devm_gpio_request_one()
in terms of devm_gpio_request() would needlessly complicate things or
lead to duplication from the unmanaged version depending on how it's
done.Signed-off-by: Mark Brown
Acked-by: Linus Walleij
Signed-off-by: Grant Likely
03 Mar, 2012
1 commit
-
Signed-off-by: Grant Likely
05 Jan, 2012
1 commit
-
This patch adds 2 functions that allow managed devices to request GPIOs.
These GPIOs will then be managed by drivers/base/devres.c.Signed-off-by: John Crispin
Signed-off-by: Grant Likely
13 Dec, 2011
2 commits
-
of_parse_phandle_with_args() needs to return quite a bit of data. Rather
than making each datum a separate **out_ argument, this patch creates
struct of_phandle_args to contain all the returned data and reworks the
user of the function. This patch also enables of_parse_phandle_with_args()
to return the device node pointer for the phandle node.This patch also ends up being fairly major surgery to
of_parse_handle_with_args(). The existing structure didn't work well
when extending to use of_phandle_args, and I discovered bugs during testing.
I also took the opportunity to rename the function to be like the
existing of_parse_phandle().v2: - moved declaration of of_phandle_args to fix compile on non-DT builds
- fixed incorrect index in example usage
- fixed incorrect return code handling for empty entriesReviewed-by: Shawn Guo
Signed-off-by: Grant Likely -
A large chunk of qe_pin_request() is unnecessarily cut-and-paste
directly from of_get_named_gpio_flags(). This patch cuts out the
duplicate code and replaces it with a call to of_get_gpio().v2: fixed compile error due to missing gpio_to_chip()
Signed-off-by: Grant Likely
Cc: Benjamin Herrenschmidt
Cc: Kumar Gala
27 Oct, 2011
1 commit
-
Should call the platform-specific __gpio_{get,set}_value
instead of generic gpio_{get,set}_valueSigned-off-by: Yang Bai
Acked-by: Arnd Bergmann
Signed-off-by: Grant Likely
24 Oct, 2011
1 commit
-
Currently struct gpio is only defined when using gpiolib which makes the
stub gpio_request_array() much less useful in drivers than is ideal as
they can't work with struct gpio. Since there are no other definitions
in kernel instead make the define always available no matter if gpiolib
is selectable or selected, ensuring that drivers can always use the
type.Signed-off-by: Mark Brown
Signed-off-by: Grant Likely
16 Jun, 2011
1 commit
-
Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
is enabled by moving them to .Fixes these build errors in linux-next:
sound/soc/codecs/ak4641.c:524: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
sound/soc/codecs/wm8915.c:2921: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)Signed-off-by: Randy Dunlap
Signed-off-by: Grant Likely
28 May, 2011
1 commit
-
gpio_{request,free}_array should not (and do not) modify the passed gpio
array, so make the parameter const.Signed-off-by: Lars-Peter Clausen
Acked-by: Eric Miao
Acked-by: Wolfram Sang
Signed-off-by: Andrew Morton
Signed-off-by: Grant Likely
27 May, 2011
1 commit
-
Make the code a bit more readable.
Instead of casting an int to an unsigned then comparing to
MAX_NR_GPIOS, add a >= 0 test and let the compiler optimizer
do the conversion to unsigned.The generated code should be the same.
Signed-off-by: Joe Perches
Acked-by: Linus Walleij
Signed-off-by: Grant Likely
14 Jan, 2011
1 commit
-
This reverts commit 0fdae42d361bbb431ca0ab0efed5126a94821177, which
wasn't really supposed to go in, and causes lots of annoying warnings.Quoth Andrew:
"Complete brainfart - I meant to drop that patch ages ago."Quoth Greg:
"Ick, yeah, that patch isn't ok to go in as-is, all of the callers
need to be fixed up first, which is what I thought we had agreed on..."Reported-by: Stephen Rothwell
Acked-by: Andrew Morton
Acked-by: Greg KH
Signed-off-by: Linus Torvalds