- 28 Jul, 2014 5 commits
-
-
Alexandre Courbot authored
The huge majority of GPIOs have their direction and initial value set right after being obtained by one of the gpiod_get() functions. The integer GPIO API had gpio_request_one() that took a convenience flags parameter allowing to specify an direction and value applied to the returned GPIO. This feature greatly simplifies client code and ensures errors are always handled properly. A similar feature has been requested for the gpiod API. Since setting the direction of a GPIO is so often the very next action done after obtaining its descriptor, we prefer to extend the existing functions instead of introducing new functions that would raise the number of gpiod getters to 16 (!). The drawback of this approach is that all gpiod clients need to be updated. To limit the pain, temporary macros are introduced that allow gpiod_get*() to be called with or without the extra flags argument. They will be removed once all consumer code has been updated. Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Reviewed-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Sachin Kamat authored
Update to reflect the recent file movement to a sub-directory. Signed-off-by:
Sachin Kamat <sachin.kamat@samsung.com> Acked-by:
Tomasz Figa <t.figa@samsung.com> Signed-off-by:
-
Mika Westerberg authored
Since now we have irqchip helpers that the GPIO chip drivers are supposed to use if possible, we can move the registration of ACPI events to happen in these helpers. This seems to be more natural place and might encourage GPIO chip driver writers to take advantage of the irqchip helpers. We make the functions available to GPIO chip drivers via private gpiolib.h, just in case generic irqchip helpers are not suitable. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Mika Westerberg authored
Instead of open-coding irqchip handling in the driver we can take advantage of the new irqchip helpers provided by the gpiolib core. While doing this we also make sure that we call gpiochip_irqchip_add() after the gpiochip itself is registered as required. Signed-off-by:
-
Linus Walleij authored
As per example from the regulator subsystem: put all defines and functions related to registering board info for GPIO descriptors into a separate <linux/gpio/machine.h> header. Cc: Andrew Victor <linux@maxim.org.za> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Thierry Reding <thierry.reding@gmail.com> Acked-by:
Stephen Warren <swarren@wwwdotorg.org> Reviewed-by:
Alexandre Courbot <gnurou@gmail.com> Signed-off-by:
-
- 24 Jul, 2014 3 commits
-
-
Alexandre Courbot authored
gpio_ensure_requested() has been introduced in Feb. 2008 by commit d2876d08 to force users of the GPIO API to explicitly request GPIOs before using them. Hopefully by now all GPIOs are correctly requested and this extra check can be omitted ; in any case the GPIO maintainers won't feel bad if machines start failing after 6 years of warnings. This patch removes that function from the dark ages. Signed-off-by:
-
Alexandre Courbot authored
An iterator variable cannot be NULL in its loop. Reported-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
-
Guenter Roeck authored
Both functions were introduced to let gpio drivers request their own gpio pins. Without exporting the functions, this can however only be used by gpio drivers built into the kernel. Secondary impact is that the functions can not currently be used by platform initialization code associated with the gpio-pca953x driver. This code permits auto-export of gpio pins through platform data, but if this functionality is used, the module can no longer be unloaded due to the problem solved with the introduction of gpiochip_request_own_desc and gpiochip_free_own_desc. Export both function so they can be used from modules and from platform initialization code. Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
- 23 Jul, 2014 8 commits
-
-
Alexandre Courbot authored
gpio_ensure_requested() only makes sense when using the integer-based GPIO API, so make sure it is called from there instead of the gpiod API which we know cannot be called with a non-requested GPIO anyway. The uses of gpio_ensure_requested() in the gpiod API were kind of out-of-place anyway, so putting them in gpio-legacy.c helps clearing the code. Actually, considering the time this ensure_requested mechanism has been around, maybe we should just turn this patch into "remove gpio_ensure_requested()" if we know for sure that no user depend on it anymore? Signed-off-by:
-
Alexandre Courbot authored
gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and are thus not using the old integer namespace. Therefore, there is no reason to have gpiod variants of these functions working with descriptors, especially since the (chip, offset) tuple is more suitable to the users of these functions (GPIO drivers, whereas GPIO descriptors are targeted at GPIO consumers). Signed-off-by:
-
Alexandre Courbot authored
As GPIO descriptors are not going to remain unique anymore, having this function public is not safe. Restrain its use to gpiolib since we have no user outside of it. Signed-off-by:
-
Alexandre Courbot authored
For some reason gpiochip_export() would invalidate all the descriptors of a chip if exporting it to sysfs failed. This does not appear as necessary. Remove that part of the code. While we are at it, add a note about the non-safety of temporarily releasing a spinlock in the middle of the loop that protects its iterator, and explain why this is done. Signed-off-by:
-
Alexandre Courbot authored
of_get_named_gpio_flags() has been made gpiolib-private by commit f01d9075, but its EXPORT statement has not been removed. Fix this. Signed-off-by:
-
Guenter Roeck authored
The gpio include file and the gpio documentation declare and document GPIOF_ACTIVE_LOW as one of the flags to be passed to gpio_request_one and related functions. However, the flag is not evaluated or used. This can cause problems in at least two areas: First, the same API can be used to auto-export pins to user space. The missing support for GPIOF_ACTIVE_LOW results in unexpected behavior for such auto-exported pins. Second, the requested gpio pin can be convered for use by gpiod functions with gpio_to_desc(). While gpio API functions do not support GPIOF_ACTIVE_LOW, gpiod functions do, which again results in unexpected behavior. Check the flag in gpio_request_one and set the gpio internal flag FLAG_ACTIVE_LOW if it is set to address those problems. Signed-off-by:
-
Lars-Peter Clausen authored
The Zynq GPIO controller does not disable the interrupt detection when the interrupt is masked and only disables the propagation of the interrupt. This means when the controller detects an interrupt condition while the interrupt is logically disabled (and masked) it will propagate the recorded interrupt event once the interrupt is enabled. This will cause the interrupt consumer to see spurious interrupts to prevent this first make sure that the interrupt is not asserted and then enable it. E.g. when a interrupt is requested with request_irq() it will be configured according to the requested type (edge/level triggered, etc.) after that it will be enabled. But the detection circuit might have already registered a false interrupt before the interrupt type was correctly configured and once the interrupt is unmasked this false interrupt will be propagated and the interrupt handler for the just request interrupt will called. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Linus Walleij authored
As we start to decomission the return value from gpiochip_remove() the compilers emit warnings due to the function being tagged __must_check. So drop this until we remove the return value altogether. Cc: Abdoulaye Berthe <berthe.ab@gmail.com> Suggested-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 22 Jul, 2014 1 commit
-
-
abdoulaye berthe authored
Signed-off-by:
abdoulaye berthe <berthe.ab@gmail.com> Signed-off-by:
-
- 10 Jul, 2014 2 commits
-
-
Harini Katakam authored
Add gpio-zynq bindings documentation. Signed-off-by:
Harini Katakam <harinik@xilinx.com> Signed-off-by:
Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by:
-
Harini Katakam authored
Add support for GPIO controller used by Xilinx Zynq. v3 changes: - Use linux/gpio/driver.h instead of linux/gpio.h - Make irq a local variable in probe v2 changes: - convert to pm_runtime_force_(suspend|resume) - add pm_runtime_set_active in probe() - also (un)prepare clocks when they are dis-/enabled - add some missing calls to pm_runtime_get() - use pm_runtime_put() instead of sync variant - remove gpio chip in driver remove() - remove redundant type casts - directly use IO helpers - use BIT macro to set/clear bits - migrate to GPIOLIB_IRQCHIP Signed-off-by:
-
- 09 Jul, 2014 11 commits
-
-
Tushar Behera authored
Following is the debug output (only a few examples) before and after the patch. $ dmesg | grep of_get_named_gpiod_flags Before: of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12220000[0]' of_get_named_gpiod_flags exited with status 0 After: of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12220000[0]' of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/power[0]' - status (0) Signed-off-by:
Tushar Behera <tushar.b@samsung.com> Reviewed-by:
-
Alexandre Courbot authored
The old integer GPIO interface is, in effect, a privileged user of the gpiod interface. Reflect this fact further by moving legacy GPIO support into its own source file. This makes the code clearer and will allow us to disable legacy GPIO support in the (far) future. Signed-off-by:
-
Alexandre Courbot authored
sysfs support is currently entangled within the core GPIO support, while it should relly just be a (privileged) user of the integer GPIO API. This patch is a first step towards making the gpiolib code more readable by splitting it into logical parts. Move all sysfs support to their own source file, and share static members of gpiolib that need to be in the private gpiolib.h file. In the future we will want to put some of them back into gpiolib.c, but this first patch let us at least identify them. Signed-off-by:
-
Alexandre Courbot authored
Compiling out GPIO labels results in a space gain so small that it can hardly be justified. Labels can also be useful for printing debug messages, so always keep them around. Signed-off-by:
-
Javier Martinez Canillas authored
The GPIO OMAP driver didn't have a consistent naming scheme for all its functions. Some of them had an omap prefix while others didn't. There are many advantages on having a separate namespace for driver functions so let's add an "omap" prefix to all of them. Signed-off-by:
Javier Martinez Canillas <jmartinez@softcrates.net> Acked-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
-
Javier Martinez Canillas authored
The <linux/irqchip/chained_irq.h> header is already included when selecting GPIOLIB_IRQCHIP so there is no need to do it in the driver. This is a left over from commit fb655f5 ("gpio: omap: convert driver to use gpiolib irqchip"). Signed-off-by: -
Javier Martinez Canillas authored
GPIO irqchips assign to the cascaded IRQs their own lock class in order to avoid warnings about lockdep recursions since that allow the lockdep core to keep track of things. Since commit e45d1c80 ("gpio: put GPIO IRQs into their own lock class") there is no need to do this in a driver if it's using the GPIO irqchip helpers since gpiolib already assigns a lockdep class. Signed-off-by:
-
Rickard Strandqvist authored
Removal of null pointer checks that could never happen This was found using a static code analysis program called cppcheck Signed-off-by:
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by:
-
Rickard Strandqvist authored
Removal of null pointer checks that could never happen This was found using a static code analysis program called cppcheck Signed-off-by:
-
Linus Walleij authored
The driver was not checking the return value from gpiochip_add() properly, so add a bail-out check. Reported-by:
-
Jürg Billeter authored
While it will be clamped to bool by gpiolib, let's make this sane in the driver as well. Signed-off-by:
Jürg Billeter <j@bitron.ch> Signed-off-by:
-
- 07 Jul, 2014 1 commit
-
-
Andrew Ruder authored
pxa_gpio_probe() has some issues supporting the gpio0 and gpio1 interrupts under device-tree - it never actually sets up the chain handler to get interrupts on edge detect for GPIO0 and GPIO1. Signed-off-by:
Andrew Ruder <andrew.ruder@elecsyscorp.com> Acked-by:
Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by:
-
- 19 Jun, 2014 4 commits
-
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Acked-by:
Neil Zhang <zhangwm@marvell.com> Signed-off-by:
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
Roland Stigge <stigge@antcom.de> Signed-off-by:
-
Linus Walleij authored
This switches the Intel MID GPIO driver over to using the gpiolib irqchip helpers in the gpiolib core. Cc: xinhui.pan <xinhuiX.pan@intel.com> Acked-by:
David Cohen <david.a.cohen@linux.intel.com> Signed-off-by:
-
Linus Walleij authored
This switches the STMPE driver to use the gpiolib irqchip helpers. Tested-by:
Silvio Fricke <silvio.fricke@gmail.com> Signed-off-by:
-
- 16 Jun, 2014 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Fix checksumming regressions, from Tom Herbert. 2) Undo unintentional permissions changes for SCTP rto_alpha and rto_beta sysfs knobs, from Denial Borkmann. 3) VXLAN, like other IP tunnels, should advertize it's encapsulation size using dev->needed_headroom instead of dev->hard_header_len. From Cong Wang. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: net: sctp: fix permissions for rto_alpha and rto_beta knobs vxlan: Checksum fixes net: add skb_pop_rcv_encapsulation udp: call __skb_checksum_complete when doing full checksum net: Fix save software checksum complete net: Fix GSO constants to match NETIF flags udp: ipv4: do not waste time in __udp4_lib_mcast_demux_lookup vxlan: use dev->needed_headroom instead of dev->hard_header_len MAINTAINERS: update cxgb4 maintainer -
git://git.linaro.org/people/mike.turquette/linuxLinus Torvalds authored
Pull more clock framework updates from Mike Turquette: "This contains the second half the of the clk changes for 3.16. They are simply fixes and code refactoring for the OMAP clock drivers. The sunxi clock driver changes include splitting out the one mega-driver into several smaller pieces and adding support for the A31 SoC clocks" * tag 'clk-for-linus-3.16-part2' of git://git.linaro.org/people/mike.turquette/linux: (25 commits) clk: sunxi: document PRCM clock compatible strings clk: sunxi: add PRCM (Power/Reset/Clock Management) clks support clk: sun6i: Protect SDRAM gating bit clk: sun6i: Protect CPU clock clk: sunxi: Rework clock protection code clk: sunxi: Move the GMAC clock to a file of its own clk: sunxi: Move the 24M oscillator to a file of its own clk: sunxi: Remove calls to clk_put clk: sunxi: document new A31 USB clock compatible clk: sunxi: Implement A31 USB clock ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing with higher frequencies CLK: TI: dpll: support OMAP5 MPU DPLL that need special handling for higher frequencies ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC) CLK: TI: clk-54xx: Set the rate for dpll_abe_m2x2_ck CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic) dt:/bindings: DRA7 ATL (Audio Tracking Logic) clock bindings ARM: dts: dra7xx-clocks: Correct name for atl clkin3 clock CLK: TI: gate: add composite interface clock to OMAP2 only build ARM: OMAP2: clock: add DT boot support for cpufreq_ck CLK: TI: OMAP2: add clock init support ...
-
git://git.infradead.org/users/willy/linux-nvmeLinus Torvalds authored
Pull NVMe update from Matthew Wilcox: "Mostly bugfixes again for the NVMe driver. I'd like to call out the exported tracepoint in the block layer; I believe Keith has cleared this with Jens. We've had a few reports from people who're really pounding on NVMe devices at scale, hence the timeout changes (and new module parameters), hotplug cpu deadlock, tracepoints, and minor performance tweaks" [ Jens hadn't seen that tracepoint thing, but is ok with it - it will end up going away when mq conversion happens ] * git://git.infradead.org/users/willy/linux-nvme: (22 commits) NVMe: Fix START_STOP_UNIT Scsi->NVMe translation. NVMe: Use Log Page constants in SCSI emulation NVMe: Define Log Page constants NVMe: Fix hot cpu notification dead lock NVMe: Rename io_timeout to nvme_io_timeout NVMe: Use last bytes of f/w rev SCSI Inquiry NVMe: Adhere to request queue block accounting enable/disable NVMe: Fix nvme get/put queue semantics NVMe: Delete NVME_GET_FEAT_TEMP_THRESH NVMe: Make admin timeout a module parameter NVMe: Make iod bio timeout a parameter NVMe: Prevent possible NULL pointer dereference NVMe: Fix the buffer size passed in GetLogPage(CDW10.NUMD) NVMe: Update data structures for NVMe 1.2 NVMe: Enable BUILD_BUG_ON checks NVMe: Update namespace and controller identify structures to the 1.1a spec NVMe: Flush with data support NVMe: Configure support for block flush NVMe: Add tracepoints NVMe: Protect against badly formatted CQEs ...
-
- 15 Jun, 2014 1 commit
-
-
Daniel Borkmann authored
Commit 3fd091e7 ("[SCTP]: Remove multiple levels of msecs to jiffies conversions.") has silently changed permissions for rto_alpha and rto_beta knobs from 0644 to 0444. The purpose of this was to discourage users from tweaking rto_alpha and rto_beta knobs in production environments since they are key to correctly compute rtt/srtt. RFC4960 under section 6.3.1. RTO Calculation says regarding rto_alpha and rto_beta under rule C3 and C4: [...] C3) When a new RTT measurement R' is made, set RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| and SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' Note: The value of SRTT used in the update to RTTVAR is its value before updating SRTT itself using the second assignment. After the computation, update RTO <- SRTT + 4 * RTTVAR. C4) When data is in flight and when allowed by rule C5 below, a new RTT measurement MUST be made each round trip. Furthermore, new RTT measurements SHOULD be made no more than once per round trip for a given destination transport address. There are two reasons for this recommendation: First, it appears that measuring more frequently often does not in practice yield any significant benefit [ALLMAN99]; second, if measurements are made more often, then the values of RTO.Alpha and RTO.Beta in rule C3 above should be adjusted so that SRTT and RTTVAR still adjust to changes at roughly the same rate (in terms of how many round trips it takes them to reflect new values) as they would if making only one measurement per round-trip and using RTO.Alpha and RTO.Beta as given in rule C3. However, the exact nature of these adjustments remains a research issue. [...] While it is discouraged to adjust rto_alpha and rto_beta and not further specified how to adjust them, the RFC also doesn't explicitly forbid it, but rather gives a RECOMMENDED default value (rto_alpha=3, rto_beta=2). We have a couple of users relying on the old permissions before they got changed. That said, if someone really has the urge to adjust them, we could allow it with a warning in the log. Fixes: 3fd091e7 ("[SCTP]: Remove multiple levels of msecs to jiffies conversions.") Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Cc: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
