- 01 May, 2012 2 commits
-
-
Dong Aisheng authored
Currently most code to get child count in kernel are almost same, add a helper to implement this function for dt to use. Cc: Grant Likely <grant.likely@secretlab.ca> Acked-by:
Rob Herring <rob.herring@calxeda.com> Acked-by:
Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Dong Aisheng authored
As pinctrl handles, it may be possible the pinctrl gpio ranges are still not got registered when user call pinctrl_gpio_request. Thus, add defer support for it too. Signed-off-by:
-
- 26 Apr, 2012 4 commits
-
-
Dong Aisheng authored
Add a interface pinctrl_provide_dummies for platform to indicate whether it needs use pinctrl dummy state. ChangeLog v3->v4: * remove dummy gpio support in pinctrl subsystem. Let gpio driver decide whether it wants to use pinctrl gpio mux function. ChangeLog v2->v3: * Also changed the missed pinctrl gpio APIs in v1. ChangeLog v1->v2: * Based on sascha's suggestion, drop using kconfig since it will hide pinctrl errors on all other boards. See: https://lkml.org/lkml/2012/4/18/282 It seemed both Linus and Stephen agreed with this way, so i'm ok with it too. * Add dummy gpio support. pinctrl gpio in the same situation as state. * Patch name changed. Original is pinctrl: handle dummy state in core. * Split removing old dt dummy interface into a separate patch Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Acked-by:
-
John Crispin authored
There are a few places in the api where the code simply returns -EINVAL when it finds an error. An example is pinmux_map_to_setting() which now reports an error if we try to match a group with a function that it does not support. The reporting of errors in pinconf_check_ops and pinmux_check_ops now has the same style and is located inside the according functions and not the calling code. When the map is found in the DT but the default state can not be selected we get an error to know that the code at least tried. The patch also removes a stray word from one comment and a "->" from another for the sake of consistency. Finally we replace a few pr_err/debug() calls with dev_err/dbg(). Thanks go to Stephen Warren for reviewing the patch and enhancing the reporting inside pinmux_map_to_setting(). Signed-off-by:
John Crispin <blogic@openwrt.org> Acked-by:
-
Stephen Warren authored
Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Stephen Warren authored
pinctrl_register_map() was returning early if pinmux_validate_map() or pinconf_validate_map() failed, but was not actually returning the error code. Signed-off-by:
-
- 25 Apr, 2012 1 commit
-
-
Linus Walleij authored
This comment was referring to an older PINMUX define, it should be PINCTRL now. Reported-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by:
-
- 24 Apr, 2012 1 commit
-
-
John Crispin authored
pinmux_map_to_setting() uses setting->data.mux.func/group to store the return code of pinmux_func_name_to_selector/pinctrl_get_group_selector(). However, struct pinctrl_setting_mux defines these elements as unsigned, resulting in all error codes getting lost. The conditionals following the assignments will always evaluate to false thus breaking the error paths. This bug can be triggered by loading a pinmux group map from the devicetree with an invalid function/group string. Signed-off-by:
-
- 18 Apr, 2012 24 commits
-
-
Dong Aisheng authored
Pin name is more useful to users. After change, when cat pingroups in sysfs, it becomes: root@freescale /sys/kernel/debug/pinctrl/20e0000.iomuxc$ cat pingroups registered pin groups: group: uart4grp-1 pin 219 (MX6Q_PAD_KEY_ROW0) pin 218 (MX6Q_PAD_KEY_COL0) group: usdhc4grp-1 pin 305 (MX6Q_PAD_SD4_CMD) pin 306 (MX6Q_PAD_SD4_CLK) pin 315 (MX6Q_PAD_SD4_DAT0) pin 316 (MX6Q_PAD_SD4_DAT1) pin 317 (MX6Q_PAD_SD4_DAT2) pin 318 (MX6Q_PAD_SD4_DAT3) pin 319 (MX6Q_PAD_SD4_DAT4) pin 320 (MX6Q_PAD_SD4_DAT5) pin 321 (MX6Q_PAD_SD4_DAT6) pin 322 (MX6Q_PAD_SD4_DAT7) Acked-by:
-
Dong Aisheng authored
Pin name is more useful to users. Acked-by:
-
Stephen Warren authored
These functions allow the driver core to automatically clean up any allocations made by drivers, thus leading to simplified drivers. Signed-off-by:
-
Dong Aisheng authored
Signed-off-by:
-
Viresh Kumar authored
When we compile pinctrl layer for platforms without CONFIG_PINCONF, we get following compilation errors: drivers/built-in.o: In function `pinctrl_show': linux-2.6/drivers/pinctrl/core.c:1116: undefined reference to `pinconf_show_setting' drivers/built-in.o: In function `pinctrl_maps_show': linux-2.6/drivers/pinctrl/core.c:1071: undefined reference to `pinconf_show_map' drivers/built-in.o: In function `pinctrl_init_device_debugfs': linux-2.6/drivers/pinctrl/core.c:1224: undefined reference to `pinconf_init_device_debugfs' make[1]: *** [.tmp_vmlinux1] Error 1 This patch fixes this. Signed-off-by:
Viresh Kumar <viresh.kumar@st.com> Signed-off-by:
-
Stephen Warren authored
Add a pinconf op so that pin controller drivers can decode their pin config settings for debugfs. Signed-off-by:
-
Stephen Warren authored
Only provide prototypes for pin{mux,conf}.c debugfs-related functions when both CONFIG_PIN* /and/ CONFIG_DEBUG_FS are enabled, otherwise provide static inlines. Signed-off-by: -
Linus Walleij authored
With the finalization of the external driver API and the device tree support, this subsystem is now mature and can be promoted to non-experimental status. Acked-by:
-
Stephen Warren authored
Implement pinctrl_ops dt_node_to_map() and dt_free_map(). These allow complete specification of the desired pinmux configuration using device tree. Signed-off-by:
-
Stephen Warren authored
Define a new binding for the Tegra pin controller, which is capable of defining all aspects of desired pin multiplexing and pin configuration. This is all based on the new common pinctrl bindings. Add Tegra30 binding based on Tegra20 binding. Add some basic stuff that was missing before: * How many and what reg property entries must be provided. * An example. Signed-off-by:
-
Stephen Warren authored
This places the file in the new location for all pin controller bindings. Also, rename the file using the full compatible value for easier avoidance of conflicts between multiple bindings. Signed-off-by:
-
Stephen Warren authored
The core pin controller bindings define: * The fact that pin controllers expose pin configurations as nodes in device tree. * That the bindings for those pin configuration nodes is defined by the individual pin controller drivers. * A standardized set of properties for client devices to define numbered or named pin configuration states, each referring to some number of the afore-mentioned pin configuration nodes. * That the bindings for the client devices determines the set of numbered or named states that must exist. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Acked-by:
Tony Lindgren <tony@atomide.com> Acked-by:
Simon Glass <sjg@chromium.org> Acked-by:
-
Stephen Warren authored
This patch adds macros of_property_for_each_u32() and of_property_for_each_string(), which iterate over an array of values within a device-tree property. Usage is for example: struct property *prop; const __be32 *p; u32 u; of_property_for_each_u32(np, "propname", prop, p, u) printk("U32 value: %x\n", u); struct property *prop; const char *s; of_property_for_each_string(np, "propname", prop, s) printk("String value: %s\n", s); Based on work by Rob Herring <robherring2@gmail.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: -
Linus Walleij authored
If drivers try to obtain pinctrl handles for a pin controller that has not yet registered to the subsystem, we need to be able to back out and retry with deferred probing. So let's return -EPROBE_DEFER whenever this location fails. Also downgrade the errors to info, maybe we will even set them to debug once the deferred probing is commonplace. Cc: Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
-
Dong Aisheng authored
This patch can avoid kernel oops in case the mux or config function is not supported by driver. Acked-by:
-
Dong Aisheng authored
Do not use get_functions_count before checking. Acked-by:
-
Viresh Kumar authored
Most of the SoC drivers implement list_groups() and list_functions() routines for pinctrl and pinmux. These routines continue returning zero until the selector argument is greater than total count of available groups or functions. This patch replaces these list_*() routines with get_*_count() routines, which returns the number of available selection for SoC driver. pinctrl layer will use this value to check the range it can choose. This patch fixes all user drivers for this change. There are other routines in user drivers, which have checks to check validity of selector passed to them. It is also no more required and hence removed. Documentation updated as well. Acked-by:
-
Uwe Kleine-König authored
As long as there is no other non-const variable marked __initdata in the same compilation unit it doesn't hurt. If there were one however compilation would fail with error: $variablename causes a section type conflict because a section containing const variables is marked read only and so cannot contain non-const variables. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Viresh Kumar authored
Missed one group from the documentation when proofreading. Signed-off-by:
-
Stephen Warren authored
pinctrl/devicetree.c won't compile when !CONFIG_PINCTRL, since the pinctrl headers don't declare some types when !PINCTRL. Make sure pinctrl/Makefile only attempts to compile devicetree.c when OF && PINCTRL. Acked-by:
-
Stephen Warren authored
During pinctrl_get(), if the client device has a device tree node, look for the common pinctrl properties there. If found, parse the referenced device tree nodes, with the help of the pinctrl drivers, and generate mapping table entries from them. During pinctrl_put(), free any results of device tree parsing. Acked-by:
-
Stephen Warren authored
Most code assumes that the pinctrl ops are present. Validate this when registering a pinctrl driver. Remove the one place in the code that was checking whether one of these non-optional ops was present. Signed-off-by:
-
Stephen Warren authored
Macros in <linux/pinctrl/machine.h> call ARRAY_SIZE(), the definition of which eventually calls BUILD_BUG_ON_ZERO(), which is defined in <linux/bug.h>. Include that so that every .c file using the pinctrl macros doesn't have to do that itself. Signed-off-by:
-
Dong Aisheng authored
The pinctrl_register_mappings is defined in core.c, so change the dependent macro from CONFIG_MUX to CONFIG_PINCTRL. The compile error message is: drivers/pinctrl/core.c:886: error: redefinition of 'pinctrl_register_mappings' include/linux/pinctrl/machine.h:160: note: previous definition of 'pinctrl_register_mappings' was here make[2]: *** [drivers/pinctrl/core.o] Error 1 make[1]: *** [drivers/pinctrl] Error 2 make: *** [drivers] Error 2 Acked-by:
-
- 16 Apr, 2012 3 commits
-
-
Linus Torvalds authored
-
git://git.linaro.org/people/rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: "Nothing too disasterous, the biggest thing being the removal of the regulator support for vcore in the AMBA driver; only one SoC was using this and it got broken during the last merge window, which then started causing problems for other people. Mutual agreement was reached for it to be removed." * 'fixes' of git://git.linaro.org/people/rmk/linux-arm: ARM: 7386/1: jump_label: fixup for rename to static_key ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus ARM: 7383/1: nommu: populate vectors page from paging_init ARM: 7381/1: nommu: fix typo in mm/Kconfig ARM: 7380/1: DT: do not add a zero-sized memory property ARM: 7379/1: DT: fix atags_to_fdt() second call site ARM: 7366/3: amba: Remove AMBA level regulator support ARM: 7377/1: vic: re-read status register before dispatching each IRQ handler ARM: 7368/1: fault.c: correct how the tsk->[maj|min]_flt gets incremented
-
Linus Torvalds authored
The 'max' range needs to be unsigned, since the size of the user address space is bigger than 2GB. We know that 'count' is positive in 'long' (that is checked in the caller), so we will truncate 'max' down to something that fits in a signed long, but before we actually do that, that comparison needs to be done in unsigned. Bug introduced in commit 92ae03f2 ("x86: merge 32/64-bit versions of 'strncpy_from_user()' and speed it up"). On x86-64 you can't trigger this, since the user address space is much smaller than 63 bits, and on x86-32 it works in practice, since you would seldom hit the strncpy limits anyway. I had actually tested the corner-cases, I had only tested them on x86-64. Besides, I had only worried about the case of a pointer *close* to the end of the address space, rather than really far away from it ;) This also changes the "we hit the user-specified maximum" to return 'res', for the trivial reason that gcc seems to generate better code that way. 'res' and 'count' are the same in that case, so it really doesn't matter which one we return. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 15 Apr, 2012 5 commits
-
-
Rabin Vincent authored
c5905afb ("static keys: Introduce 'struct static_key'...") renamed struct jump_label_key to struct static_key. Fixup ARM for this to eliminate these build warnings: include/linux/jump_label.h:113:2: warning: passing argument 1 of 'arch_static_branch' from incompatible pointer type include/asm/jump_label.h:17:82: note: expected 'struct jump_label_key *' but argument is of type 'struct static_key *' Signed-off-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Jonathan Austin authored
Currently when ThumbEE is not enabled (!CONFIG_ARM_THUMBEE) the ThumbEE register states are not saved/restored at context switch. The default state of the ThumbEE Ctrl register (TEECR) allows userspace accesses to the ThumbEE Base Handler register (TEEHBR). This can cause unexpected behaviour when people use ThumbEE on !CONFIG_ARM_THUMBEE kernels, as well as allowing covert communication - eg between userspace tasks running inside chroot jails. This patch sets up TEECR in order to prevent user-space access to TEEHBR when !CONFIG_ARM_THUMBEE. In this case, tasks are sent SIGILL if they try to access TEEHBR. Cc: stable@vger.kernel.org Reviewed-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Jonathan Austin <jonathan.austin@arm.com> Signed-off-by:
-
Will Deacon authored
If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE kernel then we will hang early during boot since the memory bank will have wrapped around to zero. This patch truncates memory banks for !LPAE configurations when the end address is not representable in 32 bits. Acked-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
-
Linus Walleij authored
During booting of cpu1, there is a short window where cpu1 is online, but not active where cpu1 is occupied by waiting to become active. If cpu0 then decides to schedule something on cpu1 and wait for it to complete, before cpu0 has set cpu1 active, we have a deadlock. Typically it's this CPU frequency transition that happens at this time, so let's just not wait for it to happen, it will happen whenever the CPU eventually comes online instead. Cc: Peter Zijlstra <peterz@infradead.org> Cc: stable@kernel.org Signed-off-by:
Jonas Aaberg <jonas.aberg@stericsson.com> Reviewed-by:
Rickard Andersson <rickard.andersson@stericsson.com> Signed-off-by:
-
Rafael J. Wysocki authored
Commit 26f41062 ("PCI: check for pci bar restore completion and retry") attempted to address problems with PCI BAR restoration on systems where FLR had not been completed before pci_restore_state() was called, but it did that in an utterly wrong way. First off, instead of retrying the writes for the BAR registers only, it did that for all of the PCI config space of the device, including the status register (whose value after the write quite obviously need not be the same as the written one). Second, it added arbitrary delay to pci_restore_state() even for systems where the PCI config space restoration was successful at first attempt. Finally, the mdelay(10) it added to every iteration of the writing loop was way too much of a delay for any reasonable device. All of this actually caused resume failures for some devices on Mikko's system. To fix the regression, make pci_restore_state() only retry the writes for BAR registers and only wait if the first read from the register doesn't return the written value. Additionaly, make it wait for 1 ms, instead of 10 ms, after every failing attempt to write into config space. Reported-by:
Mikko Vinni <mmvinni@yahoo.com> Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
