| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The fact that of_gpiochip_add_pin_range() and
gpiochip_add_pin_range() share too much code is fragile and
will invariably mean that bugs need to be fixed in two places
instead of one.
So separate the concerns of gpiolib.c and gpiolib-of.c and
have the latter call the former as back-end. This is necessary
also when going forward with other device descriptions such
as ACPI.
This is done by:
- Adding a return code to gpiochip_add_pin_range() so we can
reliably check whether this succeeds.
- Get rid of the custom of_pinctrl_add_gpio_range() from
pinctrl. Instead create of_pinctrl_get() to just retrive the
pin controller per se from an OF node. This composite
function was just begging to be deleted, it was way to
purpose-specific.
- Use pinctrl_dev_get_name() to get the name of the retrieved
pin controller and use that to call back into the generic
gpiochip_add_pin_range().
Now the pin range is only allocated and tied to a pin
controller from the core implementation in gpiolib.c.
Signed-off-by: Linus Walleij <[email protected]>
|
|
This makes us call gpiochio_remove_pin_ranges() in the
gpiochip_remove() function, so we get rid of ranges when
freeing the chip.
Reviewed-by: Stephen Warren <[email protected]>
Reviewed-by: Viresh Kumar <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"
Got most of it's function prototypes wrong, so fix this up by:
- Moving the void declarations into static inlines in
<linux/gpio.h> (previously the actual prototypes were declared
here...)
- Declare the gpiochip_add_pin_range() and
gpiochip_remove_pin_ranges() functions in <asm-generic/gpio.h>
together with the pin range struct declaration itself.
- Actually only implement these very functions in gpiolib.c
if CONFIG_PINCTRL is set.
- Additionally export the symbols since modules will need to
be able to do this.
Reviewed-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
pinctrl subsystem needs gpio chip base to prepare set of gpio
pin ranges, which a given pinctrl driver can handle. This is
important to handle pinctrl gpio request calls in order to
program a given pin properly for gpio operation.
As gpio base is allocated dynamically during gpiochip
registration, presently there exists no clean way to pass this
information to the pinctrl subsystem.
After few discussions from [1], it was concluded that may be
gpio controller reporting the pin range it supports, is a
better way than pinctrl subsystem directly registering it.
[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816
Cc: Grant Likely <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Shiraz Hashim <[email protected]>
[Edited documentation a bit]
Signed-off-by: Linus Walleij <[email protected]>
|
|
We need to unlock here before returning.
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
gpios requested with invalid numbers, or gpios requested from userspace via sysfs
should not try to be deferred on failure.
Cc: [email protected]
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Add .get_direction callback to gpio_chip. This allows gpiolib
to check the current direction of a gpio.
Used to show the correct gpio direction in sysfs and debug entries.
If callback is not set then gpiolib will work as previously;
e.g. guessing everything is input until a direction is set.
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The gpio_export function uses nested if statements and the status
variable to handle the failure cases. This makes the function logic
difficult to follow. Refactor the code to abort immediately on failure
using goto. This makes the code slightly longer, but significantly
reduces the nesting and number of split lines and makes the code easier
to read.
Signed-off-by: Ryan Mallon <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
When dumping a collection of items via seq_file, it is recommended to
use the iterator interface. For the gpiolib debugfs interface this can
be done to dump each GPIO chip in turn.
Note that for gpiolib this is a little cumbersome because it does not
provide a list of registered GPIO chips and the only way to iterate is
over each GPIO individually. Once a chip is found, the number of GPIOs
it provides can be skipped as a small optimization.
This patch was requested by Arnd Bergmann here:
http://article.gmane.org/gmane.linux.ports.tegra/3535
Signed-off-by: Thierry Reding <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Grant Likely <[email protected]>
Cc: [email protected]
Reviewed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Since users must be explicitly provided with a GPIO number in order to
request one the overwhelmingly common case for failing to request will
be that the required GPIO driver has not yet registered and we should
therefore defer until it has registered.
In order to avoid having to code this logic in individual drivers have
gpio_request() return -EPROBE_DEFER when failing to look up the GPIO.
Drivers which don't want this behaviour can override it if they desire.
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Commit 3d0f7cf0 "gpio: Adjust of_xlate API to support multiple GPIO
chips" changed the api of gpiochip_find to drop const from the data
parameter of the match hook, but didn't also drop const from data
causing a build warning.
Signed-off-by: Grant Likely <[email protected]>
|
|
The pr_info message in gpiochip_add gets displayed for every
gpiochip registered. When first bringing up a system this
information could be helpful but for normal use it's just a
bunch of noise. Change the message to a pr_debug.
Signed-off-by: H Hartley Sweeten <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
This patch changes the of_xlate API to make it possible for multiple
gpio_chips to refer to the same device tree node. This is useful for
banked GPIO controllers that use multiple gpio_chips for a single
device. With this change the core code will try calling of_xlate on
each gpio_chip that references the device_node and will return the
gpio number for the first one to return 'true'.
Tested-by: Roland Stigge <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Introduce new flags to automatically export GPIOs when using the convenience
functions gpio_request_one() or gpio_request_array(). This eases support for
custom boards where lots of GPIOs need to be exported for customer
applications.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
I've seen users getting very confused by the WARN_ON()s for can_sleep
GPIOs in the atomic-safe paths, the discoverability of the non-atomic
version of the API seems to be hampered by the fact that it's defined
in a header file not the .c file where the warnings are.
Add a couple of comments next to the warnings to help people on their
way.
Signed-off-by: Mark Brown <[email protected]>
Reviwed-by: Mark Brown <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Adding support for the open source gpio on which client
can specify the open source property through GPIO flag
GPIOF_OPEN_SOURCE at the time of gpio request.
The open source pins are normally pulled low and it
cannot be driven to output with value of 0 and so
when client request for setting the pin to LOW, the
gpio will be set to input direction to make pin in tristate
and hence PULL-DOWN on pins will make the state to LOW.
The open source pin can be driven to HIGH by setting output
with value of 1.
Signed-off-by: Laxman Dewangan <[email protected]>
Reviwed-by: Mark Brown <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Adding support for the open drain gpio on which client
can specify the open drain property through GPIO flag
GPIOF_OPEN_DRAIN at the time of gpio request.
The open drain pins are normally pulled high and it
cannot be driven to output with value of 1 and so
when client request for setting the pin to HIGH, the
gpio will be set to input direction to make pin in tristate
and hence PULL-UP on pins will make the state to HIGH.
The open drain pin can be driven to LOW by setting output
with value of 0.
Signed-off-by: Laxman Dewangan <[email protected]>
Reviwed-by: Mark Brown <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Signed-off-by: Grant Likely <[email protected]>
|
|
Hi,
On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <[email protected]> wrote:
> Hi guys,
>
> I have just triggered the folllowing:
>
> [ 84.860321] ======================================================
> [ 84.860321] [ INFO: possible circular locking dependency detected ]
> [ 84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
> [ 84.860321] -------------------------------------------------------
> [ 84.860321] bash/949 is trying to acquire lock:
> [ 84.860321] (sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc
> [ 84.860321]
> [ 84.860321] but task is already holding lock:
> [ 84.860321] (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
> [ 84.911468]
> [ 84.911468] which lock already depends on the new lock.
> [ 84.911468]
> [ 84.920043]
> [ 84.920043] the existing dependency chain (in reverse order) is:
> [ 84.920043]
> [ 84.927886] -> #1 (s_active#22){++++.+}:
> [ 84.927886] [<c008f640>] check_prevs_add+0xdc/0x150
> [ 84.927886] [<c008fc18>] validate_chain.clone.24+0x564/0x694
> [ 84.927886] [<c0090cdc>] __lock_acquire+0x49c/0x980
> [ 84.951660] [<c0091838>] lock_acquire+0x98/0x100
> [ 84.951660] [<c016a8e8>] sysfs_deactivate+0xb0/0x100
> [ 84.962982] [<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c
> [ 84.962982] [<c016b8bc>] sysfs_remove_dir+0x84/0x98
> [ 84.962982] [<c02590d8>] kobject_del+0x10/0x78
> [ 84.974670] [<c02c29e8>] device_del+0x140/0x170
> [ 84.974670] [<c02c2a24>] device_unregister+0xc/0x18
> [ 84.985382] [<c0276894>] gpio_unexport+0xbc/0xdc
> [ 84.985382] [<c02768c8>] gpio_free+0x14/0xfc
> [ 85.001708] [<c0276a28>] unexport_store+0x78/0x8c
> [ 85.001708] [<c02c5af8>] class_attr_store+0x18/0x24
> [ 85.007293] [<c0169990>] sysfs_write_file+0x100/0x184
> [ 85.018981] [<c0109d48>] vfs_write+0xb4/0x148
> [ 85.018981] [<c0109fd0>] sys_write+0x40/0x70
> [ 85.018981] [<c0013cc0>] ret_fast_syscall+0x0/0x3c
> [ 85.035003]
> [ 85.035003] -> #0 (sysfs_lock){+.+.+.}:
> [ 85.035003] [<c008f54c>] check_prev_add+0x680/0x698
> [ 85.035003] [<c008f640>] check_prevs_add+0xdc/0x150
> [ 85.052093] [<c008fc18>] validate_chain.clone.24+0x564/0x694
> [ 85.052093] [<c0090cdc>] __lock_acquire+0x49c/0x980
> [ 85.052093] [<c0091838>] lock_acquire+0x98/0x100
> [ 85.069885] [<c047e280>] mutex_lock_nested+0x3c/0x2f4
> [ 85.069885] [<c0275358>] gpio_value_store+0x24/0xcc
> [ 85.069885] [<c02c18dc>] dev_attr_store+0x18/0x24
> [ 85.087158] [<c0169990>] sysfs_write_file+0x100/0x184
> [ 85.087158] [<c0109d48>] vfs_write+0xb4/0x148
> [ 85.098297] [<c0109fd0>] sys_write+0x40/0x70
> [ 85.098297] [<c0013cc0>] ret_fast_syscall+0x0/0x3c
> [ 85.109069]
> [ 85.109069] other info that might help us debug this:
> [ 85.109069]
> [ 85.117462] Possible unsafe locking scenario:
> [ 85.117462]
> [ 85.117462] CPU0 CPU1
> [ 85.128417] ---- ----
> [ 85.128417] lock(s_active#22);
> [ 85.128417] lock(sysfs_lock);
> [ 85.128417] lock(s_active#22);
> [ 85.142486] lock(sysfs_lock);
> [ 85.151794]
> [ 85.151794] *** DEADLOCK ***
> [ 85.151794]
> [ 85.151794] 2 locks held by bash/949:
> [ 85.158020] #0: (&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184
> [ 85.170349] #1: (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
> [ 85.170349]
> [ 85.178588] stack backtrace:
> [ 85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114)
> [ 85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698)
> [ 85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150)
> [ 85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694)
> [ 85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980)
> [ 85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100)
> [ 85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4)
> [ 85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc)
> [ 85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24)
> [ 85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184)
> [ 85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148)
> [ 85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70)
> [ 85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c)
> -bash: echo: write error: Operation not permitted
>
> the way to trigger is:
>
> root@legolas:~# cd /sys/class/gpio/
> root@legolas:/sys/class/gpio# echo 2 > export
> root@legolas:/sys/class/gpio# echo 2 > unexport
> root@legolas:/sys/class/gpio# echo 2 > export
> root@legolas:/sys/class/gpio# cd gpio2/
> root@legolas:/sys/class/gpio/gpio2# echo 1 > value
Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
fix the problem.
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
A large chunk of qe_pin_request() is unnecessarily cut-and-paste
directly from of_get_named_gpio_flags(). This patch cuts out the
duplicate code and replaces it with a call to of_get_gpio().
v2: fixed compile error due to missing gpio_to_chip()
Signed-off-by: Grant Likely <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Kumar Gala <[email protected]>
|
|
This patch adds a kernel message, containing GPIO range and device
name on successful device registration, and removes duplicate messages from the following drivers:
* gpio-adp5588
* gpio-bt8xx
* gpio-cs5535
* gpio-janz-ttl
* gpio-nomadik
* gpio-pcf857x
* gpio-xilinx
* drivers/of/gpio.c
Signed-off-by: Hartmut Knaack <[email protected]>
[[email protected]: squashed 2 patches together]
Signed-off-by: Grant Likely <[email protected]>
|
|
gpio_{request,free}_array should not (and do not) modify the passed gpio
array, so make the parameter const.
Signed-off-by: Lars-Peter Clausen <[email protected]>
Acked-by: Eric Miao <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
This patch allows to trace gpio operations using ftrace
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Export function gpiochip_find so that modules can use it.
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
gpiolib plus two gpio implementations in arm fiddle in the guts of
irq_desc in a racy and buggy way. Remove the stuff. I already told the
gpio folks that we can provide that information in a proper way if
necessary.
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Grant Likely <[email protected]>
LKML-Reference: <[email protected]>
|
|
If GPIO request succeeds, but configuration fails, it should be released.
Signed-off-by: Aaro Koskinen <[email protected]>
Acked-by: Eric Miao <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The pca953x driver requires the use of threaded irqs as its irq
demultiplexer can sleep. Our irq handler can be called from any context,
so use request_any_context_irq to allow threaded irqs as well.
Signed-off-by: Daniel Gl?ckner <[email protected]>
Reported-by: Ian Jeffray <[email protected]>
Cc: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
As sysfs_notify_dirent has been made irq safe, there is no reason to not
call it directly from irq. With the work_struct removed, the remaining
element in poll_desc is a sysfs_dirent pointer which may not be NULL. We
can therefore store it directly in the idr and pass it as context to the
irq handler.
Most part of the patch deals with renaming defines and variables to
reflect their new use without functional change.
I also took the opportunity to initialize the idr statically.
Signed-off-by: Daniel Gl?ckner <[email protected]>
Cc: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Be more consistent about runtime programming interface abuse warnings,
which can reduce some confusion and trigger bugfixes. Based on an
observation and patch from Jani Nikula.
Also update doc to highlight some sleeping-call issues and to match some
recent changes.
Signed-off-by: David Brownell <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: "Ryan Mallon" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
* 'next-devicetree' of git://git.secretlab.ca/git/linux-2.6: (63 commits)
of/platform: Register of_platform_drivers with an "of:" prefix
of/address: Clean up function declarations
of/spi: call of_register_spi_devices() from spi core code
of: Provide default of_node_to_nid() implementation.
of/device: Make of_device_make_bus_id() usable by other code.
of/irq: Fix endian issues in parsing interrupt specifiers
of: Fix phandle endian issues
of/flattree: fix of_flat_dt_is_compatible() to match the full compatible string
of: remove of_default_bus_ids
of: make of_find_device_by_node generic
microblaze: remove references to of_device and to_of_device
sparc: remove references to of_device and to_of_device
powerpc: remove references to of_device and to_of_device
of/device: Replace of_device with platform_device in includes and core code
of/device: Protect against binding of_platform_drivers to non-OF devices
of: remove asm/of_device.h
of: remove asm/of_platform.h
of/platform: remove all of_bus_type and of_platform_bus_type references
of: Merge of_platform_bus_type with platform_bus_type
drivercore/of: Add OF style matching to platform bus
...
Fix up trivial conflicts in arch/microblaze/kernel/Makefile due to just
some obj-y removals by the devicetree branch, while the microblaze
updates added a new file.
|
|
When freeing a gpio that has not been exported, gpio_unexport() prints a
debug message when it should just fall through silently.
Example spurious message:
gpio_unexport: gpio0 status -22
Signed-off-by: Jon Povey <[email protected]>
Cc: David Brownell <[email protected]>
Acked-by: Uwe Kleine-K?nig <[email protected]>
Cc: Gregory Bean <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Implement generic OF gpio hooks and thus make device-enabled GPIO chips
(i.e. the ones that have gpio_chip->dev specified) automatically attach
to the OpenFirmware subsystem. Which means that now we can handle I2C and
SPI GPIO chips almost* transparently.
* "Almost" because some chips still require platform data, and for these
chips OF-glue is still needed, though with this change the glue will
be much smaller.
Signed-off-by: Anton Vorontsov <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
Cc: David Brownell <[email protected]>
Cc: Bill Gatliff <[email protected]>
Cc: Dmitry Eremin-Solenikov <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Jean Delvare <[email protected]>
Cc: Andrew Morton <[email protected]>
CC: [email protected]
CC: [email protected]
|
|
Currently the kernel uses the struct device_node.data pointer to resolve
a struct gpio_chip pointer from a device tree node. However, the .data
member doesn't provide any type checking and there aren't any rules
enforced on what it should be used for. There's no guarantee that the
data stored in it actually points to an gpio_chip pointer.
Instead of relying on the .data pointer, this patch modifies the code
to add a lookup function which scans through the registered gpio_chips
and returns the gpio_chip that has a pointer to the specified
device_node.
Signed-off-by: Grant Likely <[email protected]>
CC: Andrew Morton <[email protected]>
CC: Anton Vorontsov <[email protected]>
CC: Grant Likely <[email protected]>
CC: David Brownell <[email protected]>
CC: Bill Gatliff <[email protected]>
CC: Dmitry Eremin-Solenikov <[email protected]>
CC: Benjamin Herrenschmidt <[email protected]>
CC: Jean Delvare <[email protected]>
CC: [email protected]
CC: [email protected]
|
|
Hopefully it makes the code look nicer and makes it easier to extend
this function.
Signed-off-by: Anton Vorontsov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
CC: [email protected]
CC: [email protected]
|
|
A few architectures, like OMAP, allow you to set a debouncing time for the
gpio before generating the IRQ. Teach gpiolib about that.
Mark said:
: This would be generally useful for embedded systems, especially where
: the interrupt concerned is a wake source. It allows drivers to avoid
: spurious interrupts from noisy sources so if the hardware supports it
: the driver can avoid having to explicitly wait for the signal to become
: stable and software has to cope with fewer events. We've lived without
: it for quite some time, though.
David said:
: I looked at adding debounce support to the generic GPIO calls (and thus
: gpiolib) some time back, but decided against it. I forget why at this
: time (check list archives) but it wasn't because of lack of utility in
: certain contexts.
:
: One thing to watch out for is just how variable the hardware capabilities
: are. Atmel GPIOs have something like a fixed number of 32K clock cycles
: for debounce, twl4030 had something odd, OMAPs were more like the Atmel
: chips but with a different clock. In some cases debouncing had to be
: ganged, not per-GPIO. And so forth.
Signed-off-by: Felipe Balbi <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: David Brownell <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The current message, 'not registered' is confusing as it implies it was
not registered with something, whereas printing 'failed to register'
implies it was the gpiochip_add() call that did not work correctly.
Signed-off-by: Ben Dooks <[email protected]>
Cc: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Signed-off-by: Uwe Kleine-König <[email protected]>
Cc: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
gpiolib doesn't need to modify the names and I assume most initializers
use string constants that shouldn't be modified anyhow.
[[email protected]: fix drivers/gpio/cs5535-gpio.c]
Signed-off-by: Uwe Kleine-König <[email protected]>
Cc: Kevin Wells <[email protected]>
Cc: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The problem. When implementing a network namespace I need to be able
to have multiple network devices with the same name. Currently this
is a problem for /sys/class/net/*, /sys/devices/virtual/net/*, and
potentially a few other directories of the form /sys/ ... /net/*.
What this patch does is to add an additional tag field to the
sysfs dirent structure. For directories that should show different
contents depending on the context such as /sys/class/net/, and
/sys/devices/virtual/net/ this tag field is used to specify the
context in which those directories should be visible. Effectively
this is the same as creating multiple distinct directories with
the same name but internally to sysfs the result is nicer.
I am calling the concept of a single directory that looks like multiple
directories all at the same path in the filesystem tagged directories.
For the networking namespace the set of directories whose contents I need
to filter with tags can depend on the presence or absence of hotplug
hardware or which modules are currently loaded. Which means I need
a simple race free way to setup those directories as tagged.
To achieve a reace free design all tagged directories are created
and managed by sysfs itself.
Users of this interface:
- define a type in the sysfs_tag_type enumeration.
- call sysfs_register_ns_types with the type and it's operations
- sysfs_exit_ns when an individual tag is no longer valid
- Implement mount_ns() which returns the ns of the calling process
so we can attach it to a sysfs superblock.
- Implement ktype.namespace() which returns the ns of a syfs kobject.
Everything else is left up to sysfs and the driver layer.
For the network namespace mount_ns and namespace() are essentially
one line functions, and look to remain that.
Tags are currently represented a const void * pointers as that is
both generic, prevides enough information for equality comparisons,
and is trivial to create for current users, as it is just the
existing namespace pointer.
The work needed in sysfs is more extensive. At each directory
or symlink creating I need to check if the directory it is being
created in is a tagged directory and if so generate the appropriate
tag to place on the sysfs_dirent. Likewise at each symlink or
directory removal I need to check if the sysfs directory it is
being removed from is a tagged directory and if so figure out
which tag goes along with the name I am deleting.
Currently only directories which hold kobjects, and
symlinks are supported. There is not enough information
in the current file attribute interfaces to give us anything
to discriminate on which makes it useless, and there are
no potential users which makes it an uninteresting problem
to solve.
Signed-off-by: Eric W. Biederman <[email protected]>
Signed-off-by: Benjamin Thery <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Smatch found a potential null dereference in gpio_setup_irq(). The
"pdesc" variable is allocated with idr_find() that can return NULL. If
gpio_setup_irq() is called with 0 as gpio_flags and "pdesc" is null, it
would OOPs here.
Signed-off-by: Dan Carpenter <[email protected]>
Cc: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <[email protected]>
Guess-its-ok-by: Christoph Lameter <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Lee Schermerhorn <[email protected]>
|
|
Passing the attribute to the low level IO functions allows all kinds
of cleanups, by sharing low level IO code without requiring
an own function for every piece of data.
Also drivers can extend the attributes with own data fields
and use that in the low level function.
This makes the class attributes the same as sysdev_class attributes
and plain attributes.
This will allow further cleanups in drivers.
Full tree sweep converting all users.
Signed-off-by: Andi Kleen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
gpio_request() without initial configuration of the GPIO is normally
useless, introduce gpio_request_one() together with GPIOF_ flags for
input/output direction and initial output level.
gpio_{request,free}_array() for multiple GPIOs.
Signed-off-by: Eric Miao <[email protected]>
Cc: David Brownell <[email protected]>
Cc: Ben Nizette <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Previously enabled poll(2) support on one edge was never reconfigured when
sysfs polarity change was triggered from kernel, because 'struct device
*dev' shadowed an earlier definition.
Found by sparse, which I should've run much earlier.
Signed-off-by: Jani Nikula <[email protected]>
Cc: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Drivers may use gpiolib sysfs as part of their public user space
interface. The GPIO number and polarity might change from board to
board. The gpio_export_link() call can be used to hide the GPIO number
from user space. Add support for also hiding the GPIO line polarity
changes from user space.
Signed-off-by: Jani Nikula <[email protected]>
Cc: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
In case of failure, device_create() returns not NULL but the error code.
The current code checks for non-NULL though which causes kernel oops in
sysfs_create_group() when device_create() fails. Check for error using
IS_ERR() and propagate the error value using PTR_ERR() instead of fixed
-ENODEV code returned now...
Signed-off-by: Sergei Shtylyov <[email protected]>
Cc: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
[[email protected]: fix KVM]
Signed-off-by: Alexey Dobriyan <[email protected]>
Acked-by: Mike Frysinger <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Many gpio chips allow to generate interrupts when the value of a pin
changes. This patch gives usermode application the opportunity to make
use of this feature by calling poll(2) on the /sys/class/gpio/gpioN/value
sysfs file. The edge to trigger can be set in the edge file in the same
directory. Possible values are "none", "rising", "falling", and "both".
Using level triggers is not possible with current sysfs since nothing
changes the GPIO value (and the IRQ keeps triggering). Edge triggering
will "just work". Note that if there was an event between read() and
poll(), the poll() returns immediately.
Also note that this version only supports true GPIO interrupts. Some
later patch might be able to synthesize this behavior by timer-driven
polling; some systems seem to need that.
[[email protected]: align ids to 16 bit ids; whitespace]
Signed-off-by: Daniel Glöckner <[email protected]>
Signed-off-by: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Commit 926b663ce8215ba448960e1ff6e58b67a2c3b99b (gpiolib: allow GPIOs to
be named) already provides naming on the chip level. This patch provides
more flexibility by allowing multiple names where ever in sysfs on a per
GPIO basis.
Adapted from David Brownell's comments on a similar concept:
http://lkml.org/lkml/2009/4/20/203.
[[email protected]: fix build for CONFIG_GENERIC_GPIO=n]
Signed-off-by: Jani Nikula <[email protected]>
Acked-by: David Brownell <[email protected]>
Cc: Daniel Silverstone <[email protected]>
Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
We want to phase out the GPIO "autorequest" mechanism in gpiolib and
require all callers to use gpio_request().
- Update feature-removal-schedule
- Update the documentation now
- Convert the relevant pr_warning() in gpiolib to a WARN()
so folk using this mechanism get a noisy stack dump
Some drivers and board init code will probably need to change.
Implementations not using gpiolib will still be fine; they are already
required to implement gpio_{request,free}() stubs.
Signed-off-by: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|