- 04 9月, 2013 1 次提交
-
-
由 Linus Walleij 提交于
It appears some drivers are using gpio_set_debounce() opportunistically, i.e. without knowing whether it works or not. (Example: input/keyboard/gpio_keys.c) to account for this use case, return -ENOTSUPP and do not print any warnings in this case. Took a round over the other gpio_set_debounce() consumers to make sure that none of them are relying on the returned error code to be something specific. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 03 9月, 2013 1 次提交
-
-
由 Linus Walleij 提交于
At several places the gpiolib will proceed to handle a GPIO descriptor even if it's ->chip member is NULL and no gpiochip is associated. Fix this by checking that both the descriptor cookie *and* the chip pointer are valid. Also bail out earlier with more specific diagnostic messages on missing operations for setting as input/output or debounce. ChangeLog v1->v2: - Also return -EIO on gpiod_set_debounce() with missing operations in the vtable - Fix indentations. Suggested-by: NAlexandre Courbot <acourbot@nvidia.com> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Reviewed-by: NFrank Rowand <frank.rowand@sonymobile.com> Cc: Tim Bird <tim.bird@sonymobile.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 21 7月, 2013 1 次提交
-
-
由 Jingoo Han 提交于
The usage of strict_strtol() is not preferred, because strict_strtol() is obsolete. Thus, kstrtol() should be used. Signed-off-by: NJingoo Han <jg1.han@samsung.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 20 6月, 2013 1 次提交
-
-
由 Zhangfei Gao 提交于
Move of_gpiochip_add outof spin_lock, since kzalloc inside of_gpiochip_add -> of_gpiochip_add_pin_range -> gpiochip_add_pin_range -> kzalloc WARNING: at kernel/lockdep.c:2740 lockdep_trace_alloc+0xf8/0xfc() DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) Signed-off-by: NZhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 02 3月, 2013 3 次提交
-
-
由 Alexandre Courbot 提交于
This comment applies to gpio_to_chip(), not gpiod_to_chip(). Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Alexandre Courbot 提交于
Constify descriptor parameter of gpiod_* functions for those that should obviously not modify it. This includes value or direction get, cansleep, and IRQ number query. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Alexandre Courbot 提交于
Some functions dereferenced their GPIO descriptor argument without checking its validity first, potentially leading to an oops when given an invalid argument. This patch also makes gpio_get_value() more resilient when given an invalid GPIO, returning 0 instead of silently crashing. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Cc: Ryan Mallon <rmallon@gmail.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 28 2月, 2013 1 次提交
-
-
由 Tejun Heo 提交于
Convert to the much saner new idr interface. Signed-off-by: NTejun Heo <tj@kernel.org> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 2月, 2013 3 次提交
-
-
由 Grant Likely 提交于
The debugfs files really need to hold the gpiolib spinlock before accessing the list. Otherwise chip addition/removal will cause an oops. Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Alexandre Courbot 提交于
Add a pointer to the gpio_chip structure that references the array of GPIO descriptors belonging to the chip, and update gpiolib code to use this pointer instead of the global gpio_desc[] array. This is another step towards the removal of the gpio_desc[] global array. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.orh> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Alexandre Courbot 提交于
Make sure gpiolib works internally with descriptors and (chip, offset) pairs instead of using the global integer namespace. This prepares the ground for the removal of the global gpio_desc[] array and the introduction of the descriptor-based GPIO API. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> [grant.likely: Squash in fix for link error when CONFIG_SYSFS=n] Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 09 2月, 2013 5 次提交
-
-
由 Alexandre Courbot 提交于
Re-implement gpiochip_find_base using the list of chips instead of the global gpio_desc[] array. This makes it both simpler and more efficient, and is needed to remove the global descriptors array. The new code should preserve the exact same GPIO number assignment policy as the code it is replacing. There shouldn't be any visible change to the assigned GPIO numbers. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> [grant.likely: Added comment about assignment policy] Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Alexandre Courbot 提交于
This makes the code both simpler and faster compared to parsing the GPIO number space. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Alexandre Courbot 提交于
Using the GPIO chips list is much faster than parsing the entire GPIO number space. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Alexandre Courbot 提交于
Use the small list of GPIO chips instead of parsing the whole GPIO number space. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Alexandre Courbot 提交于
Add a list member to gpio_chip that allows all chips to be parsed quickly. The current method requires parsing the entire GPIO integer space, which is painfully slow. Using a list makes many chip operations that involve lookup or parsing faster, and also simplifies the code. It is also necessary to eventually get rid of the global gpio_desc[] array. The list of gpio_chips is always ordered by base GPIO number to ensure chips traversal is done in the right order. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 07 2月, 2013 1 次提交
-
-
由 Michał Mirosław 提交于
All in-kernel users of class_find_device() don't really need mutable data for match callback. In two places (kernel/power/suspend_test.c, drivers/scsi/osd/osd_uld.c) this patch changes match callbacks to use const search data. The const is propagated to rtc_class_open() and power_supply_get_by_name() parameters. Note that there's a dev reference leak in suspend_test.c that's not touched in this patch. Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: NGrant Likely <grant.likely@secretlab.ca> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 05 2月, 2013 2 次提交
-
-
由 Alexandre Courbot 提交于
Add missing braces in an if..else condition. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Alexandre Courbot 提交于
gpiochip_reserve() has no user and stands in the way of the removal of the static gpio_desc[] array. Remove this function as well as the now unneeded RESERVED flag of struct gpio_desc. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 21 11月, 2012 5 次提交
-
-
由 Axel Lin 提交于
This is introduced by commit 9ab6e988 "gpiolib: return any error code from range creation". Signed-off-by: NAxel Lin <axel.lin@ingics.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
To be crystal clear on what the arguments mean in this funtion dealing with both GPIO and PIN ranges with confusing naming, we now have gpio_offset and pin_offset and we are on the clear that these are offsets into the specific GPIO and pin controller respectively. The GPIO chip itself will of course keep track of the base offset into the global GPIO number space. Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
If we try to create a range for a certain GPIO chip and the target pin controller is not yet available it may return a probe deferral error code, so handle this all the way our by checking the error code. Reviewed-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Rename the function find_pinctrl_and_add_gpio_range() to pinctrl_find_and_add_gpio_range() so as to be consistent with the rest of the functions. Reviewed-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Like with commit 3c739ad0 it is not always enough to specify all the pins of a gpio_chip from offset zero to be added to a pin map range, since the mapping from GPIO to pin controller may not be linear at all, but need to be broken into a few consecutive sub-ranges or 1-pin entries for complicated cases. The ranges may also be sparse. This alters the signature of the function to accept offsets into both the GPIO-chip local pinspace and the pin controller local pinspace. Reviewed-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 12 11月, 2012 4 次提交
-
-
由 Linus Walleij 提交于
The fact that of_gpiochip_add_pin_range() and gpiochip_add_pin_range() share too much code is fragile and will invariably mean that bugs need to be fixed in two places instead of one. So separate the concerns of gpiolib.c and gpiolib-of.c and have the latter call the former as back-end. This is necessary also when going forward with other device descriptions such as ACPI. This is done by: - Adding a return code to gpiochip_add_pin_range() so we can reliably check whether this succeeds. - Get rid of the custom of_pinctrl_add_gpio_range() from pinctrl. Instead create of_pinctrl_get() to just retrive the pin controller per se from an OF node. This composite function was just begging to be deleted, it was way to purpose-specific. - Use pinctrl_dev_get_name() to get the name of the retrieved pin controller and use that to call back into the generic gpiochip_add_pin_range(). Now the pin range is only allocated and tied to a pin controller from the core implementation in gpiolib.c. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NStephen Warren <swarren@nvidia.com> Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
Commit 69e1601bca88809dc118abd1becb02c15a02ec71 "gpiolib: provide provision to register pin ranges" Got most of it's function prototypes wrong, so fix this up by: - Moving the void declarations into static inlines in <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: NStephen Warren <swarren@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Shiraz Hashim 提交于
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 <grant.likely@secretlab.ca> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NShiraz Hashim <shiraz.hashim@st.com> [Edited documentation a bit] Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 26 10月, 2012 3 次提交
-
-
由 Dan Carpenter 提交于
We need to unlock here before returning. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Mathias Nyman 提交于
gpios requested with invalid numbers, or gpios requested from userspace via sysfs should not try to be deferred on failure. Cc: stable@kernel.org Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Mathias Nyman 提交于
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: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 23 10月, 2012 1 次提交
-
-
由 Ryan Mallon 提交于
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: NRyan Mallon <rmallon@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 17 8月, 2012 1 次提交
-
-
由 Thierry Reding 提交于
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/3535Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de> Cc: Linus Walleij <linus.walleij@stericsson.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: linux-kernel@vger.kernel.org Reviewed-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 18 7月, 2012 1 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 19 5月, 2012 3 次提交
-
-
由 Grant Likely 提交于
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: NGrant Likely <grant.likely@secretlab.ca>
-
由 H Hartley Sweeten 提交于
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: NH Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Grant Likely 提交于
This patch changes the of_xlate API to make it possible for multiple gpio_chips to refer to the same device tree node. This is useful for banked GPIO controllers that use multiple gpio_chips for a single device. With this change the core code will try calling of_xlate on each gpio_chip that references the device_node and will return the gpio number for the first one to return 'true'. Tested-by: NRoland Stigge <stigge@antcom.de> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 06 4月, 2012 1 次提交
-
-
由 Wolfram Sang 提交于
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: NWolfram Sang <w.sang@pengutronix.de> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 05 3月, 2012 2 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Reviwed-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Laxman Dewangan 提交于
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: NLaxman Dewangan <ldewangan@nvidia.com> Reviwed-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-