fwnode_handle_put() should be used when terminating
device_for_each_child_node() iteration with break or
return to prevent stale device node references from
being left behind.
Generated by Coccinelle.
Fixes: 4ba8cfa79f ("gpio: dwapb: convert device node to fwnode")
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is a potential race when two threads do the writes to the same register
in parallel.
Prevent out of order in such case by protecting I/O access by spin lock.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Intel Merrifield platform has a special GPIO controller to
drive pads when they are muxed in corresponding mode.
Intel Merrifield GPIO IP is slightly different here and there
in comparison to the older Intel MID platforms. These differences
include in particular the shaked register offsets, specific
support of level triggered interrupts and wake capable sources,
as well as a pinctrl which is a separate IP.
Instead of uglifying existing driver I decide to provide a new
one slightly based on gpio-intel-mid.c. So, anyone can easily
compare what changes are happened to be here.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Brian J Wood <brian.j.wood@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This GPIO controller is a part of Intel MID platforms which are somehow
different to pure PCs. Thus, there is no need that driver is compiled for them.
Replace dependency to X86_INTEL_MID.
While here, fix capitalization of MID abbreviation.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Sort the header inclusion lines by alphabetical order.
While here, update Intel Copyright.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The commit d56d6b3d7d ("gpio: langwell: add Intel Merrifield support")
doesn't look at all as a proper support for Intel Merrifield and I dare to say
that it distorts the behaviour of the hardware.
The register map is different on Intel Merrifield, i.e. only 6 out of 8
register have the same purpose but none of them has same location in the
address space. The current case potentially harmful to existing hardware since
it's poking registers on wrong offsets and may set some pin to be GPIO output
when connected hardware doesn't expect such.
Besides the above GPIO and pinctrl on Intel Merrifield have been located in
different IP blocks. The functionality has been extended as well, i.e. added
support of level interrupts, special registers for wake capable sources and
thus, in my opinion, requires a completele separate driver.
If someone wondering the existing gpio-intel-mid.c would be converted to actual
pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do
that.
Fixes: d56d6b3d7d ("gpio: langwell: add Intel Merrifield support")
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Renesas R8A7792 SoC is a member of the R-Car gen2 family, add support for
its GPIO controllers.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
I stumbled over a build error with COMPILE_TEST and CONFIG_OF
disabled:
drivers/gpio/gpio-tegra.c: In function 'tegra_gpio_probe':
drivers/gpio/gpio-tegra.c:603:9: error: 'struct gpio_chip' has no member named 'of_node'
The problem is that the newly added GPIO_TEGRA Kconfig symbol
does not have a dependency on CONFIG_OF. However, there is another
problem here as the driver gets enabled unconditionally whenever
COMPILE_TEST is set.
This fixes both problems, by making the symbol user-visible
when COMPILE_TEST is set and default-enabled for ARCH_TEGRA=y.
As a side-effect, it is now possible to compile-test a Tegra
kernel with GPIO support disabled, which is harmless.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 4dd4dd1d21 ("gpio: tegra: Allow compile test")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This reverts commit 7e7c059cb5.
I was wrong about trying to do this, as it breaks the
orthogonality between gpiochips and irqchips.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since commit dd34c37aa3 ("gpio: of: Allow -gpio suffix for property
names") when requesting a GPIO from the devicetree gpiolib looks for
properties with both the '-gpio' and the '-gpios' suffix. This was
implemented by first searching for the property with the '-gpios' suffix
and if that yields an error try the '-gpio' suffix. This approach has the
issue that any error returned when looking for the '-gpios' suffix is
silently discarded.
Commit 06fc3b70f1 ("gpio: of: Fix handling for deferred probe for -gpio
suffix") partially addressed the issue by treating the EPROBE_DEFER error
as a special condition. This fixed the case when the property is specified,
but the GPIO provider is not ready yet. But there are other cases in which
of_get_named_gpiod_flags() returns an error even though the property is
specified, e.g. if the specification is incorrect.
of_find_gpio() should only try to look for the property with the '-gpio'
suffix if no property with the '-gpios' suffix was found. If the property
was not found of_get_named_gpiod_flags() will return -ENOENT, so update the
condition to abort and propagate the error to the caller in all other
cases.
This is important for gpiod_get_optinal() and friends to behave correctly
in case the specifier contains errors. Without this patch they'll return
NULL if the property uses the '-gpios' suffix and the specifier contains
errors, which falsely indicates to the caller that no GPIO was specified.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When registering a GPIO chip, drivers can override the device tree node
associated with the chip by setting the chip's ->of_node field. If set,
this field is supposed to take precedence over the ->parent->of_node
field, but the code doesn't actually do that.
Commit 762c2e46c0 ("gpio: of: remove of_gpiochip_and_xlate() and
struct gg_data") exposes this because it now no longer matches on the
GPIO chip's ->of_node field, but the GPIO device's ->of_node field that
is set using the procedure described above.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This reverts commit 1e4a806403.
This creates more problems than it solves right now. Compile
testing needs to go in with patches fixing the problems it
uncovers.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If we fail when copying the ioctl() struct to userspace we still
need to clean up the cruft otherwise left behind or it will stay
around until the issuing process terminates the file handle.
Reported-by: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This reverts commit 923b93e451.
Make sure consumers do not overwrite gpio flags for pins that have
already been claimed.
While adding support for gpio drivers to refuse a request using
unsupported flags, the order of when the requested flag was checked and
the new flags were applied was reversed to that consumers could
overwrite flags for already requested gpios.
This not only affects device-tree setups where two drivers could request
the same gpio using conflicting configurations, but also allowed user
space to clear gpio flags for already claimed pins simply by attempting
to export them through the sysfs interface. By for example clearing the
FLAG_ACTIVE_LOW flag this way, user space could effectively change the
polarity of a signal.
Reverting this change obviously prevents gpio drivers from doing sanity
checks on the flags in their request callbacks. Fortunately only one
recently added driver (gpio-tps65218 in v4.6) appears to do this, and a
follow up patch could restore this functionality through a different
interface.
Cc: stable <stable@vger.kernel.org> # 4.4
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This fixes the issue descirbe in bug 117531
(https://bugzilla.kernel.org/show_bug.cgi?id=117531).
It's a regression introduced in linux 4.5 that causes a Oops at load of
gpio_sch and prevents powering off the computer.
The issue is that sch_gpio_reg_set is called in sch_gpio_probe before
gpio_chip data is initialized with the pointer to the sch_gpio struct. As
sch_gpio_reg_set calls gpiochip_get_data, it returns NULL which causes
the Oops.
The patch follows Mika's advice (https://lkml.org/lkml/2016/5/9/61) and
consists in modifying sch_gpio_reg_get and sch_gpio_reg_set to take a
sch_gpio struct directly instead of a gpio_chip, which avoids the call to
gpiochip_get_data.
Thanks Mika for your patience with me :-)
Cc: stable@vger.kernel.org
Signed-off-by: Colin Pitrat <colin.pitrat@gmail.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
platform_device_id table is needed for adding the tps65218-gpio
module to the mfd_cell array.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Gpio direction is determined by DIRx bit of GPIO
configuration register, return max77620 gpio value
based on direction in or out.
Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- Driver fixes for i.MX, single register, Tegra and BayTrail.
- MAINTAINERS entry for the documentation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXc3S0AAoJEEEQszewGV1zbZoP+wcffLAiH4YWO/iKPpZatSLK
zAtFIYPvzHgITaF8VTyNKvNRiOv+11QECQAw8Eibn2hd28AUGrpPpNkeU6edCFdK
myh/QSROM1VYTCDq76KW+zsRaCkZ9HRPj2HGz3vyqe8pStJgOYlCPY7hKTDdr3/h
Umg01CBlzr74dMIQ51CgfiIAR7IMYBfoE2TU+/kR7C+HaLyRB7sUDSw+/HGkG+g/
5++dwPMbk+Z7J+bDjnKlO+jNcuLrRERwoMGCd2mzu8rvmd7Yh0c0IamKbbiTfZS5
QfT+fI6eVulcStlImAOZdLR79KB2JEdQH/1wSFupABCrucHBVxQiPSisKsa6qzw5
cia6hW8IzLwbGfytYIX89lPYP43FLbUqfjIplCXMZaUIQcnikgmmyIi/VgZAN1AY
Mi1SxXJ8EUtoQ/21nZpYdqIb4kRWiIqmjklSPDc/oiFnGGIuH+X5jnRka4Fws7Cz
1ilGpccfoQL04lvaWpKQK2FnNXU9USPGXg8hV/RXuAjNddrvxa9PQU0NxrVVhR9S
h1u2LVtjx4CELnPY9+hWUgxfXGEGbgv1V4xHOdofytBvfVhf+Qyzbg7Gn5+30s1p
VgVliGHyA0/Up7u8E1HTSsxbioyJkdvZ1A+6ibESJnlnCL5/2oKFhMAbMTdD/QQ9
LXmkKpXY+kWhEM/9z8MV
=e4gh
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v4.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here are a bunch of fixes for pin control. Just drivers and a
MAINTAINERS fixup:
- Driver fixes for i.MX, single register, Tegra and BayTrail.
- MAINTAINERS entry for the documentation"
* tag 'pinctrl-v4.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: baytrail: Fix mingled clock pins
MAINTAINERS: belong Documentation/pinctrl.txt properly
pinctrl: tegra: Fix build dependency
gpio: tegra: Make lockdep class file-scoped
pinctrl: single: Fix missing flush of posted write for a wakeirq
pinctrl: imx: Do not treat a PIN without MUX register as an error
When devres API is in use we are not supposed to call plain gpiochip_remove().
Remove redundant call to gpiochip_remove().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The error handling is not correct since the commit 3f7dbfd8ee ("gpio:
intel-mid: switch to using gpiolib irqchip helpers"). Switch to devres API to
fix the potential resource leak.
Fixes: commit 3f7dbfd8ee ("gpio: intel-mid: switch to using gpiolib irqchip helpers")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The conversion from a DT spec to struct gpio_desc is common between
of_get_named_gpiod_flags() and of_parse_own_gpio(). Factor out the
common code to a new helper, of_xlate_and_get_gpiod_flags().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The usage of gpiochip_find(&gg_data, of_gpiochip_and_xlate) is odd.
Usually gpiochip_find() is used to find a gpio_chip. Here, however,
the return value from gpiochip_find() is just discarded. Instead,
gpiochip_find(&gg_data, of_gpiochip_and_xlate) is called for the
side-effect of the match function.
The match function, of_gpiochip_find_and_xlate(), fills the given
struct gg_data, but a match function should be simply called to
judge the matching.
This commit fixes this distortion and makes the code more readable.
Remove of_gpiochip_find_and_xlate() and struct gg_data. Instead,
this adds a very simple helper function of_find_gpiochip_by_node().
Now, of_get_named_gpiod_flags() is implemented more straight-forward.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Do this sanity check only once when the gpio_chip is added
rather than every time gpio-hog is handled.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This function is doing more complicated than needed. The caller of
this function, of_gpiochip_scan_gpios() already knows the pointer to
the gpio_chip. It can pass it to of_parse_own_gpio() instead of
looking up the gpio_chip by gpiochip_find().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Call of_property_read_u32_array() only once rather than iterating
of_property_read_u32_index().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The generic IRQ helper library just checks if the IRQ line is
set as input before activating it for interrupts. As we
recently started to check things better with .get_dir() it
turns out that it's good to try to convince the line to become
an input before attempting to lock it as IRQ.
Reviewed-by: Björn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- It was discovered that too many parts of the kernel does not
respect gpiod_to_irq() returning zero for an invalid IRQ.
While this gets fixed, we need to make it return negative
errorcodes again.
- Harden the library a bit when passed error pointers. It is
a bug to use these, but let's be helpful and warn the users.
- Fix an uninitialized spinlock in the 104-idi-48 driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXaraQAAoJEEEQszewGV1zfUQQAKOAYtQ6nMat4R12UR0RKTIV
oHALxvZVHvaZbMxwSwcyIognHQJ6u6tgsTrv4M8+XQqW9LsIyw7wWzbLHY+ceYSO
l29RKzjm0diUcFBQ+E9bYoETYtg1XDjJwAtu/hRhNp3MYXZg7UeoHijvAprGYmkM
ZyQ90Et4E0TfaLV+nuHBHPlU/5kzdkKXdzH+DwNxEbFKK0y35QaOWHRolRV8/qh3
H/WgDyFo0KzRb6Ehd/MnTCq5UyQp0cAoPDuyOp6LIihFlu81UQfFhSr5kS3Q4jV+
EbZ59XbhjXy+UUsYRaFOmGlIsVOyVhqwsRa5VzuBEdKsrW5BG2zKNBz2ANteoyUp
1nmcde4r28G10zJU0uiNasPk2VEpAhbcGyu6VfSyS9nSNn2sBR+tEYhn7IYP26xo
PN53tjDB3xc0hpAvNUwdJBJ6kJGlqT5GyLkTwy9Yt1IlMi7aKUforyh6e8feEri4
j/BQWFrmxnjcQWpPJhPdkVZozmFeHBM9+tREhEjBXRiEWIyBzAh9m2kNK3Gg3vfW
YLikNGdo2w7rmKA+BvFfzOlqg2R/SWvPXSqL0Y4H/IAe+OT5pV0rf/UW6FBKLTuY
qgmavFcTbMCbTRR3nVtaAN5HZiW5eXN8u16ONaZbGgroT9PPzLwXJ58gpkXv+v/3
VTg2vw1debYCwrastDdi
=cwEd
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.7-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"More GPIO fixes. Most prominent the gpiod_to_irq() fix brought to my
attention by Hans de Goede. The hardening patch is a consequence of
the reasoning around that bug.
- It was discovered that too many parts of the kernel does not
respect gpiod_to_irq() returning zero for an invalid IRQ. While
this gets fixed, we need to make it return negative errorcodes
again.
- Harden the library a bit when passed error pointers. It is a bug
to use these, but let's be helpful and warn the users.
- Fix an uninitialized spinlock in the 104-idi-48 driver"
* tag 'gpio-v4.7-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: make library immune to error pointers
gpio: make sure gpiod_to_irq() returns negative on NULL desc
gpio: 104-idi-48: Fix missing spin_lock_init for ack_lock
Commit b546be0db9 ("gpio: tegra: Get rid of all file scoped global
variables") moved all file scoped variables into the driver-private
structure to allow potentially multiple instances of the driver. The
change also included turning the lockdep class into a driver-private
field, which doesn't work and produces error messages such as this:
[ 0.142310] BUG: key ffff8000fb3f7ab0 not in .data!
Make the lockdep class file-scoped again to fix this issue.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The lineevent_irq_thread is not exported, so make it static
to fix the following warning:
drivers/gpio/gpiolib.c:654:13: warning: symbol 'lineevent_irq_thread' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When initializing the GPIO handles, we use the iterator (i)
to back off if something goes wrong. But since the iterator
is also used after we pass the loop, we must decrement by
one after exiting the loop so that we point at the last
element in the array.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Walter Harms <wharms@bfs.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus
allowing them to build for X86_64 as they are expected to.
Cc: Alexandre Courbot <gnurou@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Most functions that take a GPIO descriptor in need to check the
descriptor for IS_ERR(). We do this mostly in the VALIDATE_DESC()
macro except for the gpiod_to_irq() function which needs special
handling.
Cc: stable@vger.kernel.org
Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
commit 54d77198fd
("gpio: bail out silently on NULL descriptors")
doesn't work for gpiod_to_irq(): drivers assume that NULL
descriptors will give negative IRQ numbers in return.
It has been pointed out that returning 0 is NO_IRQ and that
drivers should be amended to treat this as an error, but that
is for the longer term: now let us repair the semantics.
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Reported-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gcc reports a theoretical case for returning uninitialized data in
the kfifo when a GPIO interrupt happens and neither
GPIOEVENT_REQUEST_RISING_EDGE nor GPIOEVENT_REQUEST_FALLING_EDGE
are set:
drivers/gpio/gpiolib.c: In function 'lineevent_irq_thread':
drivers/gpio/gpiolib.c:683:87: error: 'ge.id' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This case should not happen, but to be on the safe side, let's
return from the irq handler without adding data to the FIFO
to ensure we can never leak stack data to user space.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 61f922db72 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This adds an ABI for listening to events on GPIO lines.
The mechanism returns an anonymous file handle to a request
to listen to a specific offset on a specific gpiochip.
To fetch the stream of events from the file handle, userspace
simply reads an event.
- Events can be requested with the same flags as ordinary
handles, i.e. open drain or open source. An ioctl() call
GPIO_GET_LINEEVENT_IOCTL is issued indicating the desired
line.
- Events can be requested for falling edge events, rising
edge events, or both.
- All events are timestamped using the kernel real time
nanosecond timestamp (the same as is used by IIO).
- The supplied consumer label will appear in "lsgpio"
listings of the lines, and in /proc/interrupts as the
mechanism will request an interrupt from the gpio chip.
- Events are not supported on gpiochips that do not serve
interrupts (no legal .to_irq() call). The event interrupt
is threaded to avoid any realtime problems.
- It is possible to also directly read the current value
of the registered GPIO line by issuing the same
GPIOHANDLE_GET_LINE_VALUES_IOCTL as used by the
line handles. Setting the value is not supported: we
do not listen to events on output lines.
This ABI is strongly influenced by Industrial I/O and surpasses
the old sysfs ABI by providing proper precision timestamps,
making it possible to set flags like open drain, and put
consumer names on the GPIO lines.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This adds a userspace ABI for reading and writing GPIO lines.
The mechanism returns an anonymous file handle to a request
to read/write n offsets from a gpiochip. This file handle
in turn accepts two ioctl()s: one that reads and one that
writes values to the selected lines.
- Handles can be requested as input/output, active low,
open drain, open source, however when you issue a request
for n lines with GPIO_GET_LINEHANDLE_IOCTL, they must all
have the same flags, i.e. all inputs or all outputs, all
open drain etc. If a granular control of the flags for
each line is desired, they need to be requested
individually, not in a batch.
- The GPIOHANDLE_GET_LINE_VALUES_IOCTL read ioctl() can be
issued also to output lines to verify that the hardware
is in the expected state.
- It reads and writes up to GPIOHANDLES_MAX lines at once,
utilizing the .set_multiple() call in the driver if
possible, making the call efficient if several lines
can be written with a single register update.
The limitation of GPIOHANDLES_MAX to 64 lines is done under
the assumption that we may expect hardware that can issue a
transaction updating 64 bits at an instant but unlikely
anything larger than that.
ChangeLog v2->v3:
- Use gpiod_get_value_cansleep() so we support also slowpath
GPIO drivers.
- Fix up the UAPI docs kerneldoc.
- Allocate the anonymous fd last, so that the release
function don't get called until that point of something
fails. After this point, skip the errorpath.
ChangeLog v1->v2:
- Handle ioctl_compat() properly based on a similar patch
to the other ioctl() handling code.
- Use _IOWR() as we pass pointers both in and out of the
ioctl()
- Use kmalloc() and kfree() for the linehandled, do not
try to be fancy with devm_* it doesn't work the way I
thought.
- Fix const-correctness on the linehandle name field.
Acked-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Intel Edison board has 4 GPIO expanders PCA9555a connected to I2C bus. Add an
ID to support them.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
On Acer One 10, the ACPI battery driver can not be probed because
it depends on the GPIO controller as well as the I2C controller to work,
Device (BATC)
{
Name (_HID, EisaId ("PNP0C0A") /* Control Method Battery */)
...
Name (_DEP, Package (0x03) // _DEP: Dependencies
{
I2C1,
GPO2,
GPO0
})
...
}
The I2C dependency also exists on other platforms and has been fixed by commit
40e7fcb192 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA"),
this patch resolves the GPIO dependency for Acer One 10.
Link:https://bugzilla.kernel.org/show_bug.cgi?id=115191
Tested-by: Stace A. Zacharov <stace75@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fixes: 9ae482104c ("gpio: 104-idi-48: Clear pending interrupt once in IRQ handler")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and
hence results in 0 banks for PCA9536 which has just 4 gpios. This is
wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized
PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in
NBANK().
Cc: stable@vger.kernel.org
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The bcm_kona_gpio_reset() calls bcm_kona_gpio_write_lock_regs()
with what looks like the wrong parameter. The write_lock_regs
function takes a pointer to the registers, not the bcm_kona_gpio
structure.
Fix the warning, and probably bug by changing the function to
pass reg_base instead of kona_gpio, fixing the following warning:
drivers/gpio/gpio-bcm-kona.c:550:47: warning: incorrect type in argument 1
(different address spaces)
expected void [noderef] <asn:2>*reg_base
got struct bcm_kona_gpio *kona_gpio
warning: incorrect type in argument 1 (different address spaces)
expected void [noderef] <asn:2>*reg_base
got struct bcm_kona_gpio *kona_gpio
Cc: stable@vger.kernel.org
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The build servers found that gpiolib is using ANON_INODES but
has forgotten to select it. Fix this.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Fixes: 521a2ad6f8 ("gpio: add userspace ABI for GPIO line information")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds support for the Western Digital's
MyBook Live memory-mapped GPIO controllers.
The GPIOs will be supported by the generic driver
for memory-mapped GPIO controllers.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds support for defining memory-mapped GPIOs which
are compatible with the existing gpio-mmio interface. The generic
library provides support for many memory-mapped GPIO controllers
that are found in various on-board FPGA and ASIC solutions that
are used to control board's switches, LEDs, chip-selects,
Ethernet/USB PHY power, etc.
For setting GPIOs there are three configurations:
1. single input/output register resource (named "dat"),
2. set/clear pair (named "set" and "clr"),
3. single output register resource and single input resource
("set" and dat").
The configuration is detected by which resources are present.
For the single output register, this drives a 1 by setting a bit
and a zero by clearing a bit. For the set clr pair, this drives
a 1 by setting a bit in the set register and clears it by setting
a bit in the clear register.
For setting the GPIO direction, there are three configurations:
a. simple bidirectional GPIOs that requires no configuration.
b. an output direction register (named "dirout")
where a 1 bit indicates the GPIO is an output.
c. an input direction register (named "dirin")
where a 1 bit indicates the GPIO is an input.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
config GPIO_LPC18XX
bool "NXP LPC18XX/43XX GPIO support"
...meaning that it currently is not being built as a module by anyone.
When targeting orphaned modular code in non-modular drivers, this
came up. Joachim indicated that the driver was actually meant to
be tristate but ended up bool by accident. So here we make it
tristate instead of removing the modular code that was essentially
orphaned.
Cc: Joachim Eastwood <manabian@gmail.com>
Acked-by: Joachim Eastwood <manabian@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When enabling the gpiolib for all archs a build robot came
up with this:
All errors (new ones prefixed by >>):
drivers/gpio/gpiolib-of.c: In function 'of_mm_gpiochip_add_data':
>> drivers/gpio/gpiolib-of.c:317:2: error: implicit declaration of
function 'iounmap' [-Werror=implicit-function-declaration]
iounmap(mm_gc->regs);
^~~~~~~
cc1: some warnings being treated as errors
Fix this by including <linux/io-mapping.h> explicitly.
Fixes: 296ad4acb8 ("gpio: remove deps on ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add ACPI support for GPIO controller on Broadcom Vulcan ARM64.
ACPI ID for this device is BRCM9006.
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
irq_alloc_descs need not be called in case of Vulcan, where we use
a dynamic IRQ range for GPIO interrupt numbers.
Update code not to call irq_alloc_descs and pass 0 as irq_base in
case of Vulcan.
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since board support for the CLPS711X platform was removed,
remove the board support from the driver.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch changes the compatibility string to match with the smallest
supported chip (EP7209). Since the DT-support for this CPU is not yet
announced, this change is safe.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch changes the compatibility string to match with the smallest
supported chip (EP7209). Since the DT-support for this CPU is not yet
announced, this change is safe.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiolib relies on the reference counters to clean up the gpio_device
structure.
Although the number of get/put is properly aligned on gpiolib.c
itself, it does not take into consideration how the referece counters
are affected by other external functions such as cdev_add and device_add.
Because of this, after the last call to put_device, the reference counter
has a value of +3, therefore never calling gpiodevice_release.
Due to the fact that some of the device has already been cleaned on
gpiochip_remove, the library will end up OOPsing the kernel (e.g. a call
to of_gpiochip_find_and_xlate).
Cc: stable@vger.kernel.org
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Under some circumstances, a gpiochip might be half cleaned from the
gpio_device list.
This patch makes sure that the chip pointer is still valid, before
calling the match function.
[ 104.088296] BUG: unable to handle kernel NULL pointer dereference at
0000000000000090
[ 104.089772] IP: [<ffffffff813d2045>] of_gpiochip_find_and_xlate+0x15/0x80
[ 104.128273] Call Trace:
[ 104.129802] [<ffffffff813d2030>] ? of_parse_own_gpio+0x1f0/0x1f0
[ 104.131353] [<ffffffff813cd910>] gpiochip_find+0x60/0x90
[ 104.132868] [<ffffffff813d21ba>] of_get_named_gpiod_flags+0x9a/0x120
...
[ 104.141586] [<ffffffff8163d12b>] gpio_led_probe+0x11b/0x360
Cc: stable@vger.kernel.org
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When the PM initialization was moved in the commit referenced below, the
code enabling the clock was removed from the probe function. On
CONFIG_PM=y kernels, this is not a problem as the pm resume hook enables
the clock, but when power management is disabled, all those pm_*
functions are noops and the clock is never enabled resulting in a
dysfunctional gpio controller.
Put the clock initialization back to support CONFIG_PM=n.
Cc: stable@vger.kernel.org
Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
Fixes: 3773c195d3 ("gpio: zynq: Do PM initialization earlier to support gpio hogs")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add function to set multiple GPIO of the same chip at the same time
and register it
Signed-off-by: Iban Rodriguez <irodriguez@cemitec.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There are only two control ports, each controlling three distinct I/O
ports. To compute the control port address offset for a respective I/O
port, the I/O port address offset should be divided by 3; dividing by 2
may result in not only the wrong address offset but possibly also an
out-of-bounds array memory access for a non-existent third control port.
Fixes: 1b06d64f73 ("gpio: Add GPIO support for the ACCES 104-DIO-48E")
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The commit 9b8e3ec343 ("gpio: pca953x: Use correct u16 value for register
word write") fixed regression in pca953x_write_regs(). At the same time the
solution introduced a sparse warning:
drivers/gpio/gpio-pca953x.c:168:39: warning: incorrect type in argument 3 (different base types)
drivers/gpio/gpio-pca953x.c:168:39: expected unsigned short [unsigned] [usertype] value
drivers/gpio/gpio-pca953x.c:168:39: got restricted __le16 [usertype] <noident>
Fix the code by enforcing the type of i2c_smbus_write_word_data() parameter.
Cc: Yong Li <sdliyong@gmail.com>
Cc: Phil Reid <preid@electromag.com.au>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There are few redundant assignments of ret variable which is updated anyway.
Remove them for good.
While here, correct indentation of the constant definition and remove one empty
line.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The reset values for all the PCF lines are high and hence on
shutdown we should drive all the lines high in order to
bring it to the reset state.
This is actually required since PCF doesn't have a reset
line and even after warm reset (by invoking "reboot" in
prompt) the PCF lines maintains it's previous programmed
state. This becomes a problem if the boards are designed to
work with the default initial state.
DRA7XX_evm uses PCF8575 and one of the PCF output lines
feeds to MMC/SD VDD and this line should be driven high in order
for the MMC/SD to be detected. This line is modelled as
regulator and the hsmmc driver takes care of enabling and
disabling it. In the case of 'reboot', during shutdown path
as part of it's cleanup process the hsmmc driver disables
this regulator. This makes MMC *boot* not functional.
Fix it by driving all the pcf lines high.
This patch was sent long back
(https://patchwork.ozlabs.org/patch/420382/)
But there was a concern that contention might occur if the
PCF shutdown handler is invoked before the shutdown handler
of the PCF's consumers. In that case PCF shutdown handler can't
drive all the pcf lines high without knowing if the PCF
consumers are still active.
However commit 52cdbdd498 ("driver core: correct device's
shutdown order") will make sure shutdown handler of PCF's
consumers are invoked before invoking the shutdown
handler of PCF. So it should be safe to merge this now.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
A platform_driver need not set an owner since it will be populated
by platform_driver_register().
Likewise for mcb_driver (gpio-menz127.c).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
As the comment block of of_parse_phandle_with_fixed_args() says,
the caller is responsible to call of_node_put() on the returned
node when done.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The MAX77620 have a GPIO pins which can act as open drain or
push pull mode. Implement support for controlling this from GPIO
descriptor tables or other hardware descriptions such as
device tree by implementing the .set_single_ended() callback.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO sub modules of MAX77620 offers to configure the GPIO
interrupt trigger level as RISING and FALLING edge.
Pass this information to regmap-irg when registering for GPIO
interrupts.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This implements the .get_direction() callback for the STMPE
expander GPIO.
Cc: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
TI PCA9536 is 4-Bit I2C GPIO expander without interrupt support[1].
Add support for the same.
[1] TRM: http://www.ti.com/lit/ds/symlink/pca9536.pdf
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO
pins. It also supports interrupts from these pins.
Add GPIO driver for these pins to control via GPIO APIs.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When adding the gpiochip, the GPIO HW drivers' callback get_direction()
could get called in atomic context. Some of the GPIO HW drivers may
sleep when accessing the register.
Move the lock before initializing the descriptors.
Reported-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In fdeb8e1547
("gpio: reflect base and ngpio into gpio_device")
assumed that GPIO descriptors are either valid or error
pointers, but gpiod_get_[index_]optional() actually return
NULL descriptors and then all subsequent calls should just
bail out.
Cc: stable@vger.kernel.org
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Fixes: fdeb8e1547 ("gpio: reflect base and ngpio into gpio_device")
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If we're using the compatible ioctl() we need to handle the
argument pointer in a special way or there will be trouble.
Fixes: 3c702e9987 ("gpio: add a userspace chardev ABI for GPIOs")
Reported-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
As irqchip and gpiochip functions are orthogonal, the IRQ
set-up or something else can have changed the direction of
the GPIO line from what the GPIO descriptor knows when we
get into gpiochip_lock_as_irq(). Make sure to re-read the
direction setting if we have the .get_direction() callback
enabled for the chip.
Else we get problems like this:
iio iio:device2: interrupts on the rising edge
gpio gpiochip2: (8012e080.gpio): gpiochip_lock_as_irq:
tried to flag a GPIO set as output for IRQ
gpio gpiochip2: (8012e080.gpio): unable to lock HW IRQ 0 for IRQ
genirq: Failed to request resources for l3g4200d-trigger
(irq 111) on irqchip nmk1-32-63
iio iio:device2: failed to request trigger IRQ.
st-gyro-i2c: probe of 2-0068 failed with error -22
Fixes: 72d3200061 ("gpio: set up initial state from .get_direction()")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The "to_irq" functionality is broken inside this driver since commit
76ba59f836 ("genirq: Add irq_domain-aware core IRQ handler").
The addition of the new lpc32xx irqchip driver in 4.7, fixed the
lpc32xx platform interrupt issue.
When switching to the new lpc32xx irqchip driver, a warning appear
in the lpc32xx gpio driver: warning: "NR_IRQS" redefined.
To remove this warning (temporary solution), this patch
disables the broken "to_irq" mapping functionality support.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.
However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.
Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.
This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.
Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.
I was using this definition for testing:
#define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.
I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.
[ Updated the 9p parts as per Al Viro - Linus ]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Here's the "big" driver core update for 4.7-rc1.
Mostly just debugfs changes, the long-known and messy races with removing
debugfs files should be fixed thanks to the great work of Nicolai Stange. We
also have some isa updates in here (the x86 maintainers told me to take it
through this tree), a new warning when we run out of dynamic char major
numbers, and a few other assorted changes, details in the shortlog.
All have been in linux-next for some time with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlc/0mwACgkQMUfUDdst+ynjXACgjNxR5nMUiM8ZuuD0i4Xj7VXd
hnIAoM08+XDCv41noGdAcKv+2WZVZWMC
=i+0H
-----END PGP SIGNATURE-----
Merge tag 'driver-core-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here's the "big" driver core update for 4.7-rc1.
Mostly just debugfs changes, the long-known and messy races with
removing debugfs files should be fixed thanks to the great work of
Nicolai Stange. We also have some isa updates in here (the x86
maintainers told me to take it through this tree), a new warning when
we run out of dynamic char major numbers, and a few other assorted
changes, details in the shortlog.
All have been in linux-next for some time with no reported issues"
* tag 'driver-core-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (32 commits)
Revert "base: dd: don't remove driver_data in -EPROBE_DEFER case"
gpio: ws16c48: Utilize the ISA bus driver
gpio: 104-idio-16: Utilize the ISA bus driver
gpio: 104-idi-48: Utilize the ISA bus driver
gpio: 104-dio-48e: Utilize the ISA bus driver
watchdog: ebc-c384_wdt: Utilize the ISA bus driver
iio: stx104: Utilize the module_isa_driver and max_num_isa_dev macros
iio: stx104: Add X86 dependency to STX104 Kconfig option
Documentation: Add ISA bus driver documentation
isa: Implement the max_num_isa_dev macro
isa: Implement the module_isa_driver macro
pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS
isa: Decouple X86_32 dependency from the ISA Kconfig option
driver-core: use 'dev' argument in dev_dbg_ratelimited stub
base: dd: don't remove driver_data in -EPROBE_DEFER case
kernfs: Move faulting copy_user operations outside of the mutex
devcoredump: add scatterlist support
debugfs: unproxify files created through debugfs_create_u32_array()
debugfs: unproxify files created through debugfs_create_blob()
debugfs: unproxify files created through debugfs_create_bool()
...
Core infrastructural changes:
- Support for natively single-ended GPIO driver stages. This
means that if the hardware has registers to configure open
drain or open source configuration, we use that rather than
(as we did before) try to emulate it by switching the line
to an input to get high impedance. This is also documented
throughly in Documentation/gpio/driver.txt for those of you
who did not understand one word of what I just wrote.
- Start to do away with the unnecessarily complex and
unitelligible ARCH_REQUIRE_GPIOLIB and
ARCH_WANT_OPTIONAL_GPIOLIB, another evolutional artifact from
the time when the GPIO subsystem was unmaintained. Archs can
now just select GPIOLIB and be done with it, cleanups to
arches will trickle in for the next kernel. Some minor archs
ACKed the changes immediately so these are included in this
pull request.
- Advancing the use of the data pointer inside the GPIO device
for storing driver data by switching the PowerPC, Super-H
Unicore and a few other subarches or subsystem drivers in
ALSA SoC, Input, serial, SSB, staging etc to use it.
- The initialization now reads the input/output state of the
GPIO lines, so that each GPIO descriptor knows - if this
callback is implemented - whether the line is input or
output. This also reflects nicely in userspace "lsgpio".
- It is now possible to name GPIO producer names, line names,
from the device tree. (Platform data has been supported for
a while.) I bet we will get a similar mechanism for ACPI
one of those days. This makes is possible to get sensible
producer names for e.g. GPIO rails in "lsgpio" in userspace.
New drivers:
- New driver for the Loongson1.
- The XLP driver now supports Broadcom Vulcan ARM64.
- The IT87 driver now supports IT8620 and IT8628.
- The PCA953X driver now supports Galileo Gen2.
Driver improvements:
- MCP23S08 was switched to use the gpiolib irqchip helpers and
now also suppors level-triggered interrupts.
- 74x164 and RCAR now supports the .set_multiple() callback
- AMDPT was converted to use generic GPIO.
- TC3589x, TPS65218, SX150X, F7188X, MENZ127, VX855, WM831X, WM8994
support the new single ended callback for open drain
and in some cases open source.
- Implement the .get_direction() callback for a few more drivers
like PL061, Xgene.
Cleanups:
- Paul Gortmaker combed through the drivers and de-modularized
those who are not really modules.
- Move the GPIO poweroff DT bindings to the power subdir where
they belong.
- Rename gpio-generic.c to gpio-mmio.c, which is much more to the
point. That's what it is handling, nothing more, nothing less.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXOuJ5AAoJEEEQszewGV1zNXsQAII5wtkP69WRJ3goYBKg1dZN
DkuLqZyVI4hCgRhptzUW10gDLHKKOCVubfetTJHSpyG/dWDJXPCyH6FHF+pW6lMX
y+em8kAvWctKpaosy4EM7O55/IohW0/fNCTOfzfrUNivjydFuA2XwPUiPqC7111O
DeKlC/t+W1JEvZTiKMi83pKq+9wqhiHmD0qxRHhV57S+MT8e7mdlSKOp7uUkKPkg
LPlerXosnmeFjL2emuSnKl/tq8pOyruU6uaIGG/uwpbo2W86Dok9GY2GWkQ4pANT
pDtprc4aJ/Clf6Q0CoKwQbmAozqTDeJo+Und9tRs2KuZRly2bWOcyVE0lyK+Y4s0
544LcKw2q6cB9ARZ6JExEVRJejPISGKMqo9TaHkyNSIJoiiatKYvNS4WVeFtTgbI
W+1WfM1svPymNRqVPO1PMLV+3m9dalDH2WjtaFF21uCAQ/G0AuPEHjEDbbx0HIpb
qrvWmYzZ97Rm/LdYROFRO53nEdCp2jh6c3n4/2kGYM8H0suvGxXZsB1g4i+Dm+B+
qKVTS282azlDuH9ohXeXizeb6atK6s8TC3Rmew97SmXDO00cUQzEQO/ZquRLHY9r
n83afQ4OL2Z9yruAxAk7pCshVSyheOsHuFPuZ7bwPW31VMdoWNRkhnaTUXMjGfYg
3y39IHrCKWNMCCVM1iNl
=z4d6
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for kernel cycle v4.7:
Core infrastructural changes:
- Support for natively single-ended GPIO driver stages.
This means that if the hardware has registers to configure open
drain or open source configuration, we use that rather than (as we
did before) try to emulate it by switching the line to an input to
get high impedance.
This is also documented throughly in Documentation/gpio/driver.txt
for those of you who did not understand one word of what I just
wrote.
- Start to do away with the unnecessarily complex and unitelligible
ARCH_REQUIRE_GPIOLIB and ARCH_WANT_OPTIONAL_GPIOLIB, another
evolutional artifact from the time when the GPIO subsystem was
unmaintained.
Archs can now just select GPIOLIB and be done with it, cleanups to
arches will trickle in for the next kernel. Some minor archs ACKed
the changes immediately so these are included in this pull request.
- Advancing the use of the data pointer inside the GPIO device for
storing driver data by switching the PowerPC, Super-H Unicore and
a few other subarches or subsystem drivers in ALSA SoC, Input,
serial, SSB, staging etc to use it.
- The initialization now reads the input/output state of the GPIO
lines, so that each GPIO descriptor knows - if this callback is
implemented - whether the line is input or output. This also
reflects nicely in userspace "lsgpio".
- It is now possible to name GPIO producer names, line names, from
the device tree. (Platform data has been supported for a while).
I bet we will get a similar mechanism for ACPI one of those days.
This makes is possible to get sensible producer names for e.g.
GPIO rails in "lsgpio" in userspace.
New drivers:
- New driver for the Loongson1.
- The XLP driver now supports Broadcom Vulcan ARM64.
- The IT87 driver now supports IT8620 and IT8628.
- The PCA953X driver now supports Galileo Gen2.
Driver improvements:
- MCP23S08 was switched to use the gpiolib irqchip helpers and now
also suppors level-triggered interrupts.
- 74x164 and RCAR now supports the .set_multiple() callback
- AMDPT was converted to use generic GPIO.
- TC3589x, TPS65218, SX150X, F7188X, MENZ127, VX855, WM831X, WM8994
support the new single ended callback for open drain and in some
cases open source.
- Implement the .get_direction() callback for a few more drivers like
PL061, Xgene.
Cleanups:
- Paul Gortmaker combed through the drivers and de-modularized those
who are not really modules.
- Move the GPIO poweroff DT bindings to the power subdir where they
belong.
- Rename gpio-generic.c to gpio-mmio.c, which is much more to the
point. That's what it is handling, nothing more, nothing less"
* tag 'gpio-v4.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (126 commits)
MIPS: do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB
gpio: zevio: make it explicitly non-modular
gpio: timberdale: make it explicitly non-modular
gpio: stmpe: make it explicitly non-modular
gpio: sodaville: make it explicitly non-modular
pinctrl: sh-pfc: Let gpio_chip.to_irq() return zero on error
gpio: dwapb: Add ACPI device ID for DWAPB GPIO controller on X-Gene platforms
gpio: dt-bindings: add wd,mbl-gpio bindings
gpio: of: make it possible to name GPIO lines
gpio: make gpiod_to_irq() return negative for NO_IRQ
gpio: xgene: implement .get_direction()
gpio: xgene: Enable ACPI support for X-Gene GFC GPIO driver
gpio: tegra: Implement gpio_get_direction callback
gpio: set up initial state from .get_direction()
gpio: rename gpio-generic.c into gpio-mmio.c
gpio: generic: fix GPIO_GENERIC_PLATFORM is set to module case
gpio: dwapb: add gpio-signaled acpi event support
gpio: dwapb: convert device node to fwnode
gpio: dwapb: remove name from dwapb_port_property
gpio/qoriq: select IRQ_DOMAIN
...
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_ZEVIO
drivers/gpio/Kconfig: bool "LSI ZEVIO SoC memory mapped GPIOs"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Fabian Vogt <fabian@ritter-vogt.de>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_TIMBERDALE
drivers/gpio/Kconfig: bool "Support for timberdale GPIO IP"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_STMPE
drivers/gpio/Kconfig: bool "STMPE GPIOs"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
Curiously, this driver was using subsys_initcall since day one, so
we don't have the "normal" module_init replacement in this change
like we've done in other similar driver updates.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Rabin Vincent <rabin.vincent@stericsson.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_SODAVILLE
drivers/gpio/Kconfig: bool "Intel Sodaville GPIO support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
Since module_pci_driver() uses the same init level as the
builtin_pci_driver() does, there is no init ordering change
caused by this commit.
We don't replace module.h with init.h since the file already has that.
We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.
Cc: Hans J. Koch <hjk@linutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Make it possible to name the producer side of a GPIO line using
a "gpio-line-names" property array, modeled on the
"clock-output-names" property from the clock bindings.
This naming is especially useful for:
- Debugging: lines are named after function, not just opaque
offset numbers.
- Exploration: systems where some or all GPIO lines are available
to end users, such as prototyping, one-off's "makerspace usecases"
users are helped by the names of the GPIO lines when tinkering.
This usecase has been surfacing recently.
The gpio-line-names attribute is completely optional.
Example output from lsgpio on a patched Snowball tree:
GPIO chip: gpiochip6, "8000e180.gpio", 32 GPIO lines
line 0: unnamed unused
line 1: "AP_GPIO161" "extkb3" [kernel]
line 2: "AP_GPIO162" "extkb4" [kernel]
line 3: "ACCELEROMETER_INT1_RDY" unused [kernel]
line 4: "ACCELEROMETER_INT2" unused
line 5: "MAG_DRDY" unused [kernel]
line 6: "GYRO_DRDY" unused [kernel]
line 7: "RSTn_MLC" unused
line 8: "RSTn_SLC" unused
line 9: "GYRO_INT" unused
line 10: "UART_WAKE" unused
line 11: "GBF_RESET" unused
line 12: unnamed unused
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Amit Kucheria <amit.kucheria@linaro.org>
Cc: David Mandala <david.mandala@linaro.org>
Cc: Lee Campbell <leecam@google.com>
Cc: devicetree@vger.kernel.org
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The WinSystems WS16C48 communicates via the ISA bus. As such, it is more
appropriate to use the ISA bus driver over the platform driver to
control the WinSystems WS16C48 GPIO driver.
This patch also adds support for multiple devices via the base and irq
module array parameters. Each element of the base array corresponds to a
discrete device; each element of the irq array corresponds to the
respective device addressed in the respective base array element.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ACCES 104-IDIO-16 series communicates via the ISA bus. As such, it
is more appropriate to use the ISA bus driver over the platform driver
to control the ACCES 104-IDIO-16 GPIO driver.
This patch also adds support for multiple devices via the base and irq
module array parameters. Each element of the base array corresponds to a
discrete device; each element of the irq array corresponds to the
respective device addressed in the respective base array element.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ACCES 104-IDI-48 series communicates via the ISA bus. As such, it
is more appropriate to use the ISA bus driver over the platform driver
to control the ACCES 104-IDI-48 GPIO driver.
This patch also adds support for multiple devices via the base and irq
module array parameters. Each element of the base array corresponds to a
discrete device; each element of the irq array corresponds to the
respective device addressed in the respective base array element.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ACCES 104-DIO-48E series communicates via the ISA bus. As such, it
is more appropriate to use the ISA bus driver over the platform driver
to control the ACCES 104-DIO-48E GPIO driver.
This patch also adds support for multiple devices via the base and irq
module array parameters. Each element of the base array corresponds to a
discrete device; each element of the irq array corresponds to the
respective device addressed in the respective base array element.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If a translation returns zero, that means NO_IRQ, so we
should return an error since the function is documented to
return a negative code on error.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This implements the .get_direction() callback for the xgene GPIO
controller.
Cc: Duc Dang <dhdang@apm.com>
Cc: Feng Kan <fkan@apm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Implement gpio_get_direction() callback for Tegra GPIO.
The direction is only valid if the pin is configured as
GPIO. If pin is not configured in GPIO mode then this
function return error.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If the gpiochip supports the .get_direction() callback, then
the initial state of the descriptor flags should be set up
as output accordingly. Also put in comments explaining what is
going on.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch renames the gpio-generic.c into gpio-mmio.c.
This is because currently the file only contains code
for a memory-mapped GPIO driver. There isn't any support
for ioports or other resource type.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
GPIO_GENERIC_PLATFORM is a tristate. If the module option is
selected the resulting gpio-generic.ko will lack most of the
module initialzation and probe code.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch converts device node to fwnode for dwapb driver, so
as to provide a unified fwnode for DT and ACPI bindings.
Tested-by: Alan Tull <delicious.quinoa@gmail.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jiang Qiu <qiujiang@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch removed the name property from dwapb_port_property.
The name property is redundant, since we can get this info
from dwapb_gpio dev node.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jiang Qiu <qiujiang@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The gpio-mpc8xxx driver requires IRQ domains but can be built
without them, resulting on a failure to build certain randconfigs
on ARM:
drivers/gpio/gpio-mpc8xxx.c: In function 'mpc8xxx_gpio_to_irq':
drivers/gpio/gpio-mpc8xxx.c:92:10: error: implicit declaration of function 'irq_create_mapping' [-Werror=implicit-function-declaration]
return irq_create_mapping(mpc8xxx_gc->irq, offset);
This selects IRQ_DOMAIN from the driver to ensure we can build it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 5df7fd46b7 ("gpio/qoriq: Add qoriq platforms support")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
NVIDIA's Tegra210 support the HW debounce in the GPIO controller
for all its GPIO pins.
Add support for setting debounce timing by implementing the
set_debounce callback of gpiochip.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Move the file scoped multiple global variable from Tegra GPIO
driver to the structure and make this as gpiochip data which
can be referred from GPIO chip callbacks.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The data member of the of_device_id is the constant type
and hence all static structure which is used for this
initialisation as static.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Suggested-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Implement this callback so that the driver reports correctly
the direction setting of each line.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Now GPIO IRQ loss is observed on dra7-evm after suspend/resume cycle
in the following case:
extcon_usb1(id_irq) -> pcf8575.gpio1 -> omapgpio6.gpio11 -> gic
the extcon_usb1 is wake up source and it enables IRQ wake up for
id_irq by calling enable/disable_irq_wake() during suspend/resume
which, in turn, causes execution of omap_gpio_wake_enable(). And
omap_gpio_wake_enable() will set/clear corresponding bit in
GPIO_IRQWAKEN_x register.
omapgpio6 configuration after boot - wakeup is enabled for GPIO IRQs
by default from omap_gpio_irq_type:
GPIO_IRQSTATUS_SET_0 | 0x00000400
GPIO_IRQSTATUS_CLR_0 | 0x00000400
GPIO_IRQWAKEN_0 | 0x00000400
GPIO_RISINGDETECT | 0x00000000
GPIO_FALLINGDETECT | 0x00000400
omapgpio6 configuration after after suspend/resume cycle:
GPIO_IRQSTATUS_SET_0 | 0x00000400
GPIO_IRQSTATUS_CLR_0 | 0x00000400
GPIO_IRQWAKEN_0 | 0x00000000 <---
GPIO_RISINGDETECT | 0x00000000
GPIO_FALLINGDETECT | 0x00000400
As result, system will start to lose interrupts from pcf8575 GPIO
expander, because when OMAP GPIO IP is in smart-idle wakeup mode, there
is no guarantee that transition(s) on input non wake up GPIO pin will
trigger asynchronous wake-up request to PRCM and then IRQ generation.
IRQ will be generated when GPIO is in active mode - for example, some
time after accessing GPIO bank registers IRQs will be generated
normally, but issue will happen again once PRCM will put GPIO in low
power smart-idle wakeup mode.
Note 1. Issue is not reproduced if debounce clk is enabled for GPIO
bank.
Note 2. Issue hardly reproducible if GPIO pins group contains both
wakeup/non-wakeup gpios - for example, it will be hard to reproduce
issue with pin2 if GPIO_IRQWAKEN_0=0x1 GPIO_IRQSTATUS_SET_0=0x3
GPIO_FALLINGDETECT = 0x3 (TRM "Power Saving by Grouping the Edge/Level
Detection").
Note 3. There nothing common bitween System wake up and OMAP GPIO bank
IP wake up logic - the last one defines how the GPIO bank ON-IDLE-ON
transition will happen inside SoC under control of PRCM.
Hence, fix the problem by removing omap_set_gpio_wakeup() function
completely and so keeping always in sync GPIO IRQ mask/unmask
(IRQSTATUS_SET) and wake up enable (GPIO_IRQWAKEN) bits; and adding
IRQCHIP_MASK_ON_SUSPEND flag in OMAP GPIO irqchip. That way non wakeup
GPIO IRQs will be properly masked/unmask by IRQ PM core during
suspend/resume cycle.
Cc: Roger Quadros <rogerq@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIOLIB symbol currently require that
ARCH_WANT_OPTIONAL_GPIOLIB or ARCH_REQUIRE_GPIOLIB is selected
to be selectable.
The ARCH_REQUIRE_GPIOLIB does only one thing: select GPIOLIB.
This is just confusing: architectures that want GPIOLIB should
be able to configure it in no matter what, and those who
require it should just select GPIOLIB.
It also creates problems for drivers that need to state
"select GPIOLIB" to get dependencies: those depend on the
selected architecture to select
ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB first, and will cause
compile errors for the few archs that state neither.
These intermediary symbols need to go.
As a first step, remove the dependencies so that:
- ARCH_WANT_OPTIONAL_GPIOLIB becomes a noop (GPIOLIB will be
available for everyone) and
- "select ARCH_REQUIRE_GPIOLIB" can be replaced by just
"select GPIOLIB"
After this patch we can follow up with patches cleaning up the
architectures one-by one and eventually remove the
ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB symbols altogether.
Reported-by: Michael Hennerich <michael.hennerich@analog.com>
Cc: Michael Büsch <m@bues.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This renames gpiod_set_array_value_priv() to
gpiod_set_array_value_complex() and moves it to the gpiolib.h
private header file so we can reuse it in the subsystem.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix a typo causing a build regression.
Fixes: f90c6bdb69 ("gpio: f7188x: use the new open drain callback")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Return proper error in brcmstb_gpio_probe if bank width is invalid.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Print the error number of GPIO hog failed during its configurations.
This helps in identifying the failure without instrumenting the code.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Look for child node which are available when iterating for
gpio hog node for request/set GPIO initial configuration
during OF gpio chip registration.
All it really does is make it possible to set
status = "disabled"; in the hog nodes, and then they will
not be applied.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Allow compile testing this driver by adding a new config option which
is enabled by default and depends on the old symbol or COMPILE_TEST.
Signed-off-by: Alexander Stein <alexanders83@web.de>
The WM8994 GPIOs clearly have a dedicated open drain control
register. Implement support for controlling this from GPIO
descriptor tables or other hardware descriptions such as
device tree by implementing the .set_single_ended() callback.
Before this patch, lines requesting open drain will just be
switched to input mode by the framework, thus emulating open
drain. But the hardware can do the real thing, so let's
support that.
As part of this, rename the debugfs string for output mode
from "CMOS" to "push-pull" because it is the term used in
the framework to signify a tomem-pole CMOS output.
Cc: patches@opensource.wolfsonmicro.com
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The WM831x GPIOs clearly have a dedicated open drain control
register. Implement support for controlling this from GPIO
descriptor tables or other hardware descriptions such as
device tree by implementing the .set_single_ended() callback.
Before this patch, lines requesting open drain will just be
switched to input mode by the framework, thus emulating open
drain. But the hardware can do the real thing, so let's
support that.
As part of this, rename the debugfs string for output mode
from "CMOS" to "push-pull" because it is the term used in
the framework to signify a tomem-pole CMOS output.
Cc: patches@opensource.wolfsonmicro.com
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The vx855 driver clearly states it has three groups of lines:
GPI, GPO and GPIO. The GPO are assumedly push-pull. The GPIO
are implicit open drain, but if the GPIO subsystem ask for them
to be explicitly open drain (i.e. set the flag on a machine table
that we want open drain) it will currently misbehave: it will
switch the GPIOs to input mode (emulate open drain). Instead:
indicate in the .set_single_ended() callback that we support
open drain and open drain only.
Cc: Daniel Drake <drake@endlessm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The menz127 driver tries to support open drain by detecting it
at request time. However: without the new callbacks from the
gpiolib it is not really working: the core will still just emulate
the open drain mode by switching the line to an input.
By adding a hook into the new .set_single_ended() call rather than
trying to autodetect at request() time, proper open drain can be
supported.
Cc: Andreas Werner <andy@wernerandy.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The F7188x chips supports setting the pins in open drain mode.
Activate the new .set_single_ended() callback.
Cc: Peter Hung <hpeter@gmail.com>
Cc: Andreas Bofjall <andreas@gazonk.org>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Align to how we handle bitmasks in most drivers in the
subsystem: using the BIT(n) macro over (1 << n).
Cc: Peter Hung <hpeter@gmail.com>
Cc: Andreas Bofjall <andreas@gazonk.org>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
One variant of the SX150X GPIO chip supports setting the pins in
open drain mode. This is currently available to set from platform
data, but completely unused in the kernel.
Activate the new .set_single_ended() callback so users can set
this up from e.g. device tree or board files using the new
GPIO descriptors.
As part of this, delete the platform data open drain setting
method.
Cc: Wei Chen <Wei.Chen@csr.com>
Cc: Peter Rosin <peda@axentia.se>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The sx150x has some platform data definition in <linux/i2c/sx150x.h>
but this file is only included from the driver in the whole kernel
so move its contents into the driver.
Cc: Wei Chen <Wei.Chen@csr.com>
Cc: Peter Rosin <peda@axentia.se>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The TPS65218 supports open drain mode on its three pins,
with one of them configurable also as push-pull. Use the
new .set_single_ended() callback to set this up properly
from the core, so the core actually see it can drive the
pin(s) as open drain, and does not attempt to emulate
open drain by switching the pin to an input.
Acked-by: Nicolas Saenz Julienne <nicolassaenzj@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If GPIO hog configuration failed while adding OF based
gpiochip() then return the error instead of ignoring it.
This helps of properly handling the gpio driver dependency.
When adding the gpio hog nodes for NVIDIA's Tegra210 platforms,
the gpio_hogd() fails with EPROBE_DEFER because pinctrl is not
ready at this time and gpio_request() for Tegra GPIO driver
returns error. The error was not causing the Tegra GPIO driver
to fail as the error was getting ignored.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Benoit Parrot <bparrot@ti.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Galileo Gen2 board uses the PCAL9535 as the GPIO expansion,
it is different from PCA9535 and includes interrupt mask/status registers,
The current driver does not support the interrupt registers configuration,
it causes some gpio pins cannot trigger interrupt events,
this patch fix this issue.
The original patch was submitted by
Josef Ahmad <josef.ahmad@linux.intel.com>
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-quark/tree/recipes-kernel/linux/files/0015-Quark-GPIO-1-2-quark.patch
Signed-off-by: Yong Li <yong.b.li@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pm_runtime_disable is called only in remove it is missed
out in the error path.
Fix the same.
Signed-off-by: Shubhrajyoti Datta <shubhraj@xilinx.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The current implementation only uses the first byte in val,
the second byte is always 0. Change it to use cpu_to_le16
to write the two bytes into the register
Cc: stable@vger.kernel.org
Signed-off-by: Yong Li <sdliyong@gmail.com>
Reviewed-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since commit ff2b135922 ("gpio: make the gpiochip a real device"),
attempts to add a gpio chip prior to gpiolib initialization cause
the system to crash. This happens because gpio_bus_type has not been
registered yet. Defer creating gpio devices until after gpiolib has
been initialized to fix the problem.
Cc: Greg Ungerer <gerg@uclinux.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Fixes: ff2b135922 ("gpio: make the gpiochip a real device")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It is possible that a gpio chip is registered before the gpiolib
initialization code has run. This means we can not use devm_ functions
to allocate memory at that time. Do it the old fashioned way.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In legacy pxa builds, ie. non device-tree and platform-data only builds,
pinctrl is not yet available. As a consequence, the pinctrl gpio
direction change function is a stub, returning always success.
In the current state, the gpio driver direction function believes the
pinctrl direction change was successful, and exits without actually
changing the gpio direction.
This patch changes the logic :
- if the pinctrl direction function fails, gpio direction will report
that failure
- if the pinctrl direction function succeeds, gpio direction is changed
by the gpio driver anyway.
This is sub optimal in the pinctrl aware case, as the gpio direction
will be changed twice: once by pinctrl function and another time by
the gpio direction function.
Yet it should be acceptable in this form, as this is functional for all
pxa platforms (device-tree and platform-data), and moreover changing a
gpio direction is very very seldom, usually in machine initialization,
seldom in drivers probe, and an exception for ac97 reset bug.
Fixes: a770d94637 ("gpio: pxa: add pin control gpio direction and request")
Reported-by: Guenter Roeck <guenter@roeck-us.net>
Tested-by: Guenter Roeck <guenter@roeck-us.net>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When firmware does not use _DSD properties that allow properly name GPIO
resources, the kernel falls back on parsing _CRS resources, and will
return entries described as GpioInt() as general purpose GPIOs even
though they are meant to be used simply as interrupt sources for the
device:
Device (ETSA)
{
Name (_HID, "ELAN0001")
...
Method(_CRS, 0x0, NotSerialized)
{
Name(BUF0,ResourceTemplate ()
{
I2CSerialBus(
0x10, /* SlaveAddress */
ControllerInitiated, /* SlaveMode */
400000, /* ConnectionSpeed */
AddressingMode7Bit, /* AddressingMode */
"\\_SB.I2C1", /* ResourceSource */
)
GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone,,
"\\_SB.GPSW") { BOARD_TOUCH_GPIO_INDEX }
} )
Return (BUF0)
}
...
}
This gives troubles with drivers such as Elan Touchscreen driver
(elants_i2c) that uses devm_gpiod_get to look up "reset" GPIO line and
decide whether the driver is responsible for powering up and resetting
the device, or firmware is. In the above case the lookup succeeds, we
map GPIO as output and later fail to request client->irq interrupt that
is mapped to the same GPIO.
Let's ignore resources described as GpioInt() while parsing _CRS when
requesting output GPIOs (but allow them when requesting GPIOD_ASIS or
GPIOD_IN as some drivers, such as i2c-hid, do request GPIO as input and
then map it to interrupt with gpiod_to_irq).
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_TPS6586X
drivers/gpio/Kconfig: bool "TPS6586X GPIO"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_TPS65910
drivers/gpio/Kconfig: bool "TPS65910 GPIO"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Graeme Gregory <gg@slimlogic.co.uk>
Cc: Jorge Eduardo Candelaria <jedu@slimlogic.co.uk>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_PALMAS
drivers/gpio/Kconfig: bool "TI PALMAS series PMICs GPIO"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_SX150X
drivers/gpio/Kconfig: bool "Semtech SX150x I2C GPIO expander"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.
Cc: Gregory Bean <gbean@codeaurora.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_TC3589X
drivers/gpio/Kconfig: bool "TC3589X GPIOs"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Rabin Vincent <rabin.vincent@stericsson.com>
Cc: Hanumath Prasad <hanumath.prasad@stericsson.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_RC5T583
drivers/gpio/Kconfig: bool "RICOH RC5T583 GPIO"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This makes use of the new .set_single_ended() callback to
set the GPIO line as open drain/open source using hardware.
The TC3589x can do this by either disabling the N-MOS
transistor (open drain) or the P-MOS transistor (open source)
of the output driver stage, in the first case making the signal
drive actively low and high impedance as "high" and in the second
case actively high and high impedance, which is as close to native
open drain support as we come.
Cc: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This switch to use BIT(n) instead of (1 << n) which is less
to the point. Most GPIO drivers do this to avoid mistakes.
Also switch from using <linux/gpio.h> to the apropriate
<linux/gpio/driver.h> include.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some GPIO controllers has a special hardware bit we can flip
to support open drain / source. This means that on these hardwares
we do not need to emulate OD/OS by setting the line to input
instead of actively driving it high/low. Add an optional vtable
callback to the driver set_single_ended() so that driver can
implement this in hardware if they have it.
We may need a pinctrl_gpio_set_config() call at some point to
propagate this down to a backing pin control device on systems
with split GPIO/pin control.
Reported-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
i2c_smbus_write_byte_data() can fail. To ensure the
cached buffer has consistent status with h/w status, don't
update the cached gpio->buffer if write fails.
Also refactor the code a bit by adding a tpic2810_set_mask_bits()
helper and use it to simplify the code.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
config GPIO_ZX
bool "ZTE ZX GPIO support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modularity so that when reading the
driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Jun Nie <jun.nie@linaro.org>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_XGENE
drivers/gpio/Kconfig: bool "APM X-Gene GPIO controller support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Feng Kan <fkan@apm.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_STA2X11
drivers/gpio/Kconfig: bool "STA2x11/ConneXt GPIO support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modularity, so that when reading
the driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig for this driver is currently:
config GPIO_PL061
bool "PrimeCell PL061 GPIO support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modularity, so that when reading the
driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Acked-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_MVEBU
drivers/gpio/Kconfig: def_bool y
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modularity so that when reading the
driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Kconfig currently controlling compilation of this code is:
drivers/gpio/Kconfig:config GPIO_MOXART
drivers/gpio/Kconfig: bool "MOXART GPIO support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modular references so that when reading
the driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
We don't replace module.h with init.h since the file already has that.
Cc: Jonas Jensen <jonas.jensen@gmail.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Wei Yongjun
Andy Shevchenko
Sergei Shtylyov
Arnd Bergmann
Linus Walleij
Lars-Peter Clausen
Thierry Reding
Johan Hovold
Colin Pitrat
Keerthy
Venkat Reddy Talla
Linus Torvalds
Geert Uytterhoeven
Masahiro Yamada
Ben Dooks
William Breathitt Gray
Rui Zhang
plr.vincent@gmail.com
Axel Lin
Vignesh R
Christian Lamparter
Álvaro Fernández Rojas
Paul Gortmaker
Kamlakant Patel
Alexander Shiyan
Ricardo Ribalda Delgado
Helmut Grohne
Iban Rodriguez
Kishon Vijay Abraham I
Laxman Dewangan
Sylvain Lemieux
Duc Dang
Ville Syrjälä
Jiang Qiu
Grygorii Strashko
Alexander Stein
Yong Li
Shubhrajyoti Datta
Kelvin Cheung
Yong Li
Guenter Roeck
Robert Jarzmik
Dmitry Torokhov