| Message ID | CACRpkdaTv4NBrRXeJE6dVi4W88+LZdsTCSzTHi0vdcKMW3Qfmw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [GIT,PULL] pin control bulk changes for v4.16 | expand |
On Fri, Feb 2, 2018 at 5:28 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > > here is the big slew of changes in pin control for the v4.16 cycle. So I pulled this, and then was surprised by how *everything* got rebuilt even though it only touched pinctl files. The reason for that seems to be that the pinctl pull got me this: include/linux/pinctrl/devinfo.h | 2 + and in include/linux/device.h we have #include <linux/pinctrl/devinfo.h> so pretty much *every* driver ends up depending on that silly two-line change. I *think* that the only reason that happens is because of this: #ifdef CONFIG_PINCTRL struct dev_pin_info *pins; #endif and honestly, that could be trivially done by just having a forward declaration, replacing the pinctrl/devinfo.h header include entirely. Ironically, that two-line change to pinctrl/devinfo.h was a forward declaration in the exact reverse direction: +struct device; + so I would really prefer to speed up recompiles and just generally try to avoid horrible header file inclusion by doing the same thing in <linux/device.h>, adding just that struct dev_pin_info; declaration, and removing the <linux/pinctrl/devinfo.h> include. Hmm? I also wonder if there are any automated tools that try to find these kinds of crazy things. I suspect a lot of our build times is the poor compiler just reading and parsing header files over and over again, and a lot of them are probably not needed. A year ago, Ingo did patches limit some of the header file issues for the core headers (<linux/sched.h> in particular). Maybe he had tooling? Ingo? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 2, 2018 at 2:56 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > so I would really prefer to speed up recompiles and just generally try > to avoid horrible header file inclusion by doing the same thing in > <linux/device.h>, adding just that > > struct dev_pin_info; > > declaration, and removing the <linux/pinctrl/devinfo.h> include. It turns out that some pinctl users seem to depend on this broken situation., with at least drivers/pinctrl/core.c drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c drivers/pinctrl/pinctrl-ocelot.c drivers/pinctrl/bcm/pinctrl-iproc-gpio.c expecting to magically get some of the pinctrl function declarations not through some pinctrl header file, but just from <linux/device.h>. Adding that include to <linux/pinctrl/pinctrl.h> would seem to make those happy and make 'allmodconfig' build for me. But I'm only testing x86-64. Can somebody test at least arm too? Stupid patch attached. I don't know how much this helps the insane dependency hell for <linux/pinctrl/devinfo.h>, but it's bound to help _some_. Comments? Linus include/linux/device.h | 2 +- include/linux/pinctrl/pinctrl.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/device.h b/include/linux/device.h index f649fc0c2571..b093405ed525 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -20,7 +20,6 @@ #include <linux/compiler.h> #include <linux/types.h> #include <linux/mutex.h> -#include <linux/pinctrl/devinfo.h> #include <linux/pm.h> #include <linux/atomic.h> #include <linux/ratelimit.h> @@ -41,6 +40,7 @@ struct fwnode_handle; struct iommu_ops; struct iommu_group; struct iommu_fwspec; +struct dev_pin_info; struct bus_attribute { struct attribute attr; diff --git a/include/linux/pinctrl/pinctrl.h b/include/linux/pinctrl/pinctrl.h index 5e45385c5bdc..8f5dbb84547a 100644 --- a/include/linux/pinctrl/pinctrl.h +++ b/include/linux/pinctrl/pinctrl.h @@ -18,6 +18,7 @@ #include <linux/list.h> #include <linux/seq_file.h> #include <linux/pinctrl/pinctrl-state.h> +#include <linux/pinctrl/devinfo.h> struct device; struct pinctrl_dev;
On Fri, Feb 2, 2018 at 4:44 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Stupid patch attached. I don't know how much this helps the insane > dependency hell for <linux/pinctrl/devinfo.h>, but it's bound to help > _some_. Testing it, that patch definitely cuts down on recompiles after touch include/linux/pinctrl/devinfo.h a lot. It still ends up rebuilding a fair amount of odd drivers, but now the files it rebuilds at least make _some_ sense. It used to really rebuild just about everything (because pretty much everything includes <linux/device.h>). Now it rebuilds various snd/soc files,gpio stuff and mmc/mfc stuff. I'm sure it could be improved upon still, but I think this is already a fairly noticeable improvement. One odd header include down. Ten million to go. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Linus Torvalds <torvalds@linux-foundation.org> wrote: > I also wonder if there are any automated tools that try to find these > kinds of crazy things. I suspect a lot of our build times is the poor > compiler just reading and parsing header files over and over again, > and a lot of them are probably not needed. Yes. I'd guesstimate that in a typical defconfig kernel build the compiler is building at least 10x as much as it should with a cleaner header file layout, based on preprocessed source code file sizes. Interestingly the .i file linecount difference isn't all that large between allmodconfig and allnoconfig kernels - which I think is further proof of our 'header spaghetti bloat' problems. While central files like fork.c or sched/*.c are expected to have a lot of dependencies, we also have a lot of bloat if we build much more isolated, standalone core kernel functionality: # allmodconfig: triton:~/tip> wc -l kernel/task_work.i 43522 kernel/task_work.i # allnoconfig: triton:~/tip> wc -l kernel/task_work.i 37123 kernel/task_work.i # source code size: triton:~/tip> wc -l kernel/task_work.c 118 kernel/task_work.c We are bringing in 37 KLOC of headers to build a 0.1 KLOC .c file ... > A year ago, Ingo did patches limit some of the header file issues for > the core headers (<linux/sched.h> in particular). Maybe he had > tooling? Ingo? No, unfortunately I didn't use much tooling: I only used simple manual tools like 'grep' and small ad-hoc shell scripts to discover some of the deeper dependencies (long lost - nor was there any real value in them). What I relied on mostly was randconfig build coverage. In that sched.h split-up effort a year ago I literally removed/moved the prototypes and header files one by one and tried to see what breaks. If the breakage was too widespread I tried to grep. But based on the sched.h experiment I do think our kernel build times could be significantly improved by organizing the headers better. Splitting up sched.h also improved readability and maintainability, so it was a win-win all around. With a more aggressive reorganization of our header architecture I believe we could achieve a more than 5x improvement in kernel build times (!) - but that would involve some trade-offs for header maintainability: a finer grained hierarchy is somewhat harder to maintain. With extreme measures that would involve runtime performance trade-offs as well (to get rid of excessive inlining cross-dependencies) we could possibly achieve a 30x improvement in kernel compilation times: the build would be link time and build parallelism limited on most systems. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Feb 3, 2018 at 1:51 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Fri, Feb 2, 2018 at 4:44 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> >> Stupid patch attached. I don't know how much this helps the insane >> dependency hell for <linux/pinctrl/devinfo.h>, but it's bound to help >> _some_. > > Testing it, that patch definitely cuts down on recompiles after > > touch include/linux/pinctrl/devinfo.h > > a lot. Hey very nice. Sorry I was offline this weekend and didn't provide much feedback. Indeed it is smarter to forward-declare struct dev_pin_info. I rebuilt my platforms with the mainline and all is working just fine of course. > It still ends up rebuilding a fair amount of odd drivers, but now the > files it rebuilds at least make _some_ sense. Yeah :/ I guess the lesson learned is that when I push stuff into device core like this, it needs to be done as exquisitely as cache-aligned structs because of the overall impact on the build systems. > One odd header include down. Ten million to go. Sorry about contributing to that :( Another thing that comes to mind was Paul Gortmaker's tedious work to remove #include <linux/module.h> from drivers that cannot be built as modules that happened in the last few months. My subsystems had a few of those and it visibly impacted build time. As usual clean and consistent code is code that compiles quickly... We definitely need some better tooling to find these things, using Ingo's head and your occasional frustration is not going to scale. Julia: do you have ideas on tooling that can loosen #include deps and advise on when to replace #includes with forward declarations of structs (etc) to bring down rebuild-triggering dependencies? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 5 Feb 2018, Linus Walleij wrote: > On Sat, Feb 3, 2018 at 1:51 AM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > On Fri, Feb 2, 2018 at 4:44 PM, Linus Torvalds > > <torvalds@linux-foundation.org> wrote: > >> > >> Stupid patch attached. I don't know how much this helps the insane > >> dependency hell for <linux/pinctrl/devinfo.h>, but it's bound to help > >> _some_. > > > > Testing it, that patch definitely cuts down on recompiles after > > > > touch include/linux/pinctrl/devinfo.h > > > > a lot. > > Hey very nice. Sorry I was offline this weekend and didn't provide > much feedback. > > Indeed it is smarter to forward-declare struct dev_pin_info. > > I rebuilt my platforms with the mainline and all is working just fine > of course. > > > It still ends up rebuilding a fair amount of odd drivers, but now the > > files it rebuilds at least make _some_ sense. > > Yeah :/ > > I guess the lesson learned is that when I push stuff into device > core like this, it needs to be done as exquisitely as cache-aligned > structs because of the overall impact on the build systems. > > > One odd header include down. Ten million to go. > > Sorry about contributing to that :( > > Another thing that comes to mind was Paul Gortmaker's tedious > work to remove #include <linux/module.h> from drivers that cannot > be built as modules that happened in the last few months. My > subsystems had a few of those and it visibly impacted build > time. As usual clean and consistent code is code that compiles > quickly... > > We definitely need some better tooling to find these things, > using Ingo's head and your occasional frustration is not going to > scale. > > Julia: do you have ideas on tooling that can loosen #include > deps and advise on when to replace #includes with forward > declarations of structs (etc) to bring down rebuild-triggering > dependencies? Could you explain more? Is the point that you want to remove an include but it has one declaration that you need, and so you want to bring it down into the .c file? Would the need for that actually indicate that the include file is designed incorrectly? Can one assume that each include is self contained, ie it includes the things that it needs and does not rely on the .c file having included other things beforehand? julia -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 5, 2018 at 10:27 AM, Julia Lawall <julia.lawall@lip6.fr> wrote: > On Mon, 5 Feb 2018, Linus Walleij wrote: >> We definitely need some better tooling to find these things, >> using Ingo's head and your occasional frustration is not going to >> scale. >> >> Julia: do you have ideas on tooling that can loosen #include >> deps and advise on when to replace #includes with forward >> declarations of structs (etc) to bring down rebuild-triggering >> dependencies? > > Could you explain more? Is the point that you want to remove an include > but it has one declaration that you need, and so you want to bring it down > into the .c file? Would the need for that actually indicate that the > include file is designed incorrectly? > > Can one assume that each include is self contained, ie it includes the > things that it needs and does not rely on the .c file having included > other things beforehand? Usually (in my limited experience, le's see what Ingo and Torvalds say) the problem manifests mainly in include files including other include files. So say <linux/foo.h>: #include <linux/bar.h> struct foo { struct bar *barp; }; Since this is only putting a pointer inside its struct and doesn't need the information on the whole structs, as the size of a pointer is well known we can reduce it to: struct bar; struct foo { struct bar *barp; }; And thus as <linux/bar.h> is not even included, it can change all it wants, our foo.h include file is not affected, neither will any driver just casually #including <linux/foo.h> need to be rebuilt. This type of case (and variations on this theme) is the reason we put a bunch of forward-declarations in kernel .h-files just to break dependencies to stuff just referenced by pointer. There is a counter-pattern saying "files should #include the headers prototypes, structs (etc) it uses" that drives a truck through this approach. But IMO when done properly, this forward-declaring approach is quite readable. I have very limited idea of where, whether in the preprocessor or the compiler itself, the decision to treat struct bar *barp as "just some pointer" happens, but it is a real neat trick, the dependency chain is broken in CPP AFAICT anyways, and cuts down the rebuilds. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 5 Feb 2018, Linus Walleij wrote: > On Mon, Feb 5, 2018 at 10:27 AM, Julia Lawall <julia.lawall@lip6.fr> wrote: > > On Mon, 5 Feb 2018, Linus Walleij wrote: > > >> We definitely need some better tooling to find these things, > >> using Ingo's head and your occasional frustration is not going to > >> scale. > >> > >> Julia: do you have ideas on tooling that can loosen #include > >> deps and advise on when to replace #includes with forward > >> declarations of structs (etc) to bring down rebuild-triggering > >> dependencies? > > > > Could you explain more? Is the point that you want to remove an include > > but it has one declaration that you need, and so you want to bring it down > > into the .c file? Would the need for that actually indicate that the > > include file is designed incorrectly? > > > > Can one assume that each include is self contained, ie it includes the > > things that it needs and does not rely on the .c file having included > > other things beforehand? > > Usually (in my limited experience, le's see what Ingo and Torvalds > say) the problem manifests mainly in include files including other > include files. > > So say <linux/foo.h>: > > #include <linux/bar.h> > > struct foo { > struct bar *barp; > }; > > Since this is only putting a pointer inside its struct and doesn't > need the information on the whole structs, as the size of a pointer > is well known we can reduce it to: > > struct bar; > > struct foo { > struct bar *barp; > }; > > And thus as <linux/bar.h> is not even included, it can change > all it wants, our foo.h include file is not affected, neither will > any driver just casually #including <linux/foo.h> need to be > rebuilt. > > This type of case (and variations on this theme) is the reason > we put a bunch of forward-declarations in kernel .h-files > just to break dependencies to stuff just referenced by pointer. > > There is a counter-pattern saying "files should #include the > headers prototypes, structs (etc) it uses" that drives a truck > through this approach. But IMO when done properly, this > forward-declaring approach is quite readable. > > I have very limited idea of where, whether in the preprocessor > or the compiler itself, the decision to treat struct bar *barp > as "just some pointer" happens, but it is a real neat trick, the > dependency chain is broken in CPP AFAICT anyways, and cuts > down the rebuilds. OK, thanks for the explanation. It seems like a very interesting problem. I will think about it and see if something can be done. It seems like it may need careful checking by a human, due to macros, ifdefs, etc, but perhaps it can at least be heplful to narrow down the opportunities. julia -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Linus Torvalds > Sent: 02 February 2018 22:57 ... > I also wonder if there are any automated tools that try to find these > kinds of crazy things. I suspect a lot of our build times is the poor > compiler just reading and parsing header files over and over again, > and a lot of them are probably not needed. I've counted system calls during a NetBSD kernel build, I imagine Linux is much the same. Most of the calls were open(), and most of those failing opens. I suspected that most came from searching the -I path to find headers. Build over NFS and the cost is even more significant (every directory name in the path (used to) require an NFS message exchange). David
On Mon, Feb 5, 2018 at 2:09 AM, David Laight <David.Laight@aculab.com> wrote: > From: Linus Torvalds >> Sent: 02 February 2018 22:57 > ... >> I also wonder if there are any automated tools that try to find these >> kinds of crazy things. I suspect a lot of our build times is the poor >> compiler just reading and parsing header files over and over again, >> and a lot of them are probably not needed. > > I've counted system calls during a NetBSD kernel build, I imagine Linux is > much the same. > Most of the calls were open(), and most of those failing opens. > I suspected that most came from searching the -I path to find headers. > Build over NFS and the cost is even more significant (every directory > name in the path (used to) require an NFS message exchange). I suspect that Linux is actually very _different_ in this area, because Linux has a very extensive name cache for pathname lookup that also captures negative path component entries. End result: opening a file - whether it exists or not - doesn't actually go down to the filesystem at all when things are cached. My kernel profiles also show that very clearly, there's absolutely no filesystem component to the build at all (but there is a noticeable VFS component to it, and __d_lookup_rcu is generally one of the hottest kernel functions along with the system call entry/exit code). Now, on NFS the caching will be a bit less effective because we have a timeout that forces re-validation of the caches, but even there at least the "look up the same header pathname" will be captured very well. So the most common case - of doing the include path lookup for all those really core header files that _everbody_ ends up including - ends up being captured pretty much 100% in the caches even on NFS. On a local filesystem, as long as you have enough RAM, those lookups will be cached even across multiple kernel compiles. At least if you are like me, and all you do all day long is build the kernel ;) Linus -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 5, 2018 at 8:55 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > End result: opening a file - whether it exists or not - doesn't > actually go down to the filesystem at all when things are cached. My > kernel profiles also show that very clearly, there's absolutely no > filesystem component to the build at all (but there is a noticeable > VFS component to it, and __d_lookup_rcu is generally one of the > hottest kernel functions along with the system call entry/exit code). Note that when I do kernel profiles of kernel builds, I do it mostly for the "everything is already built" case, so the real footprint for much of my profiles is actually mostly "make" doing millions of open/stat calls. Because once you actually build things, the kernel is almost not noticeable any more. It's all gcc. And people always say that it's optimizations that are expensive, but from the profiling I've done of user space, a _lot_ of time is spent in just parsing and reading the data. In fact, having just re-done this, the top function in profiling is "_cpp_lex_token()" at 3.4% of overall time for my test kernel build. That matches my experience from sparse: the real overhead in a compiler is just the stupid lexing/parsing. Cache misses galore, and there's nothing really smart you can do about it. Once you get to optimization, you can do smart things like hash the SSA representation to do CSE cheaply etc clever data structures. But lexing and parsing the tree is reading text and allocating and generating the internal representation, and it's just "work". Lots of it. And that is why trying to avoid unnecessary header includes matters so much. Because the front-end really does matter for compiler performance. (And it's at least partly why C++ is such a pain to compile, and why C++ people want pre-compiled headers etc. You can't just do a forward declaration of a struct type, and you get header inclusion from hell when you have "clever" classes and inheritance etc. C++ build times tend to be really nasty as a result). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Re: [GIT PULL] pin control bulk changes for v4.16] On 05/02/2018 (Mon 10:27) Julia Lawall wrote: > > > On Mon, 5 Feb 2018, Linus Walleij wrote: > [...] > > > > Another thing that comes to mind was Paul Gortmaker's tedious > > work to remove #include <linux/module.h> from drivers that cannot > > be built as modules that happened in the last few months. I also took aim at headers including giant headers ; see below. [...] > Could you explain more? Is the point that you want to remove an include > but it has one declaration that you need, and so you want to bring it down > into the .c file? Would the need for that actually indicate that the > include file is designed incorrectly? I put a bit of an explanation in this commit: commit d47529b2e9fe0ec2eb1f072afad8849f52e385c4 Author: Paul Gortmaker <paul.gortmaker@windriver.com> Date: Mon Sep 12 18:16:31 2016 -0400 gpio: don't include module.h in shared driver header Most shared headers in include/linux don't need to know what the internals of a struct module are; all they care about is that it is a struct and hence they may require a pointer to one. The advantage in this is that module.h is including a lot of stuff itself, and an otherwise empty C file that just contains module.h will result in ~750kB from CPP (compared to say 12kB from init.h) So we have approximately 50 instances of "struct module;" in the various include/linux headers already that help us keep module.h out of other headers; here we do the same for gpio. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: linux-gpio@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> I'm sure I've got more of these type of commits sitting around locally, unfortunately there have been other "interesting" things going on in the linux world in the last month that have prevented me from touching any of them. :-/ Paul. -- > > Can one assume that each include is self contained, ie it includes the > things that it needs and does not rely on the .c file having included > other things beforehand? > > julia -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Linus, here is the big slew of changes in pin control for the v4.16 cycle. Like with GPIO it is actually a bit calm this time. The patches moving AXP209 from GPIO to pin control appear again (with the same hashes) and everything should be just smooth. Details are in the signed tag as usual. Please pull it in! Yours, Linus Walleij The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: Linux 4.15-rc1 (2017-11-26 16:01:47 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git tags/pinctrl-v4.16-1 for you to fetch changes up to 02e389e63e3523828fc3832f27e0341885f60f6f: pinctrl: mcp23s08: fix irq setup order (2018-01-30 15:17:14 +0100) ---------------------------------------------------------------- This is the bulk of pin control changes for the v4.16 kernel cycle: Core changes: - After lengthy discussions and partly due to my ignorance, we have merged a patch making pinctrl_force_default() and pinctrl_force_sleep() reprogram the states into the hardware of any hogged pins, even if they are already in the desired state. This only apply to hogged pins since groups of pins owned by drivers need to be managed by each driver, lest they could not do things like runtime PM and put pins to sleeping state even if the system as a whole is not in sleep. New drivers: - New driver for the Microsemi Ocelot SoC. This is used in ethernet switches. - The X-Powers AXP209 GPIO driver was extended to also deal with pin control and moved over from the GPIO subsystem. This circuit is a mixed-mode integrated circuit which is part of AllWinner designs. - New subdriver for the Qualcomm MSM8998 SoC, core of a high end mobile devices (phones) chipset. - New subdriver for the ST Microelectronics STM32MP157 MPU and STM32F769 MCU from the STM32 family. - New subdriver for the MediaTek MT7622 SoC. This is used for routers, repeater, gateways and such network infrastructure. - New subdriver for the NXP (former Freescale) i.MX 6ULL. This SoC has multimedia features and target "smart devices", I guess in-car entertainment, in-flight entertainment, industrial control panels etc. General improvements: - Incremental improvements on the SH-PFC subdrivers for things like the CAN bus. - Enable the glitch filter on Baytrail GPIOs used for interrupts. - Proper handling of pins to GPIO ranges on the Semtec SX150X - An IRQ setup ordering fix on MCP23S08. - A good set of janitorial coding style fixes. ---------------------------------------------------------------- Alexandre Belloni (2): dt-bindings: pinctrl: Add bindings for Microsemi Ocelot pinctrl: Add Microsemi Ocelot SoC driver Alexandre Torgue (2): dt-bindings: pinctrl: stm32: fix copyright and adopt SPDX identifier pinctrl: stm32: add STM32F769 MCU support Andy Shevchenko (1): pinctrl: intel: merrifield: Introduce ACPI device table Bai Ping (1): pinctrl: imx6ul: add IOMUXC SNVS pinctrl driver for i.MX 6ULL Benjamin Gaignard (1): pinctrl: stm32: Fix copyright Biju Das (1): pinctrl: sh-pfc: r8a7794: Add i2c5 pin groups and function Brian Norris (1): pinctrl: rockchip: enable clock when reading pin direction register Colin Ian King (1): pinctrl: intel: ensure error return ret is initialized Dmitry Mastykin (1): pinctrl: mcp23s08: fix irq setup order Fabrizio Castro (6): pinctrl: sh-pfc: r8a7745: Add CAN[01] support pinctrl: sh-pfc: r8a7794: Add can_clk function pinctrl: sh-pfc: r8a7791: Add can_clk function pinctrl: sh-pfc: r8a7794: Add PWM[0123456] support pinctrl: sh-pfc: r8a7794: Add tpu groups and function pinctrl: sh-pfc: r8a7791: Add tpu groups and function Florian Fainelli (1): pinctrl: Really force states during suspend/resume Geert Uytterhoeven (1): pinctrl: sunxi: Use of_clk_get_parent_count() instead of open coding Hans de Goede (1): pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts Icenowy Zheng (1): pinctrl: sunxi: fix a typo when merging A20 support to A10 driver Jesse Chan (1): pinctrl: pxa: pxa2xx: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE Julia Lawall (3): pinctrl: at91-pio4: account for const type of of_device_id.data pinctrl: axp209: account for const type of of_device_id.data pinctrl: armada-37xx: account for const type of of_device_id.data Khan, Imran (1): pinctrl: qcom: Add msm8998 pinctrl driver Krzysztof Kozlowski (1): pinctrl: samsung: Add SPDX license identifiers Ladislav Michl (1): pinctrl: Forward declare struct device Linus Walleij (5): pinctrl: gemini: Add two missing GPIO groups pinctrl: gemini: Support drive strength setting Merge branch 'ib-move-axp209' of /home/linus/linux-gpio into devel Merge tag 'sh-pfc-for-v4.16-tag1' of git://git.kernel.org/.../geert/renesas-drivers into devel Merge tag 'sh-pfc-for-v4.16-tag2' of git://git.kernel.org/.../geert/renesas-drivers into devel Ludovic Barre (2): devicetree: bindings: Document supported STM32 SoC family pinctrl: stm32: Add STM32MP157 MPU support Markus Elfring (26): pinctrl: mcp23s08: Improve unlocking of a mutex in mcp23s08_irq() pinctrl: mvebu: Delete an error message for a failed memory allocation in mvebu_pinctrl_probe() pinctrl/nomadik/abx500: Delete an error message for a failed memory allocation in abx500_gpio_probe() pinctrl/nomadik/abx500: Improve a size determination in abx500_gpio_probe() pinctrl: adi2: Delete an error message for a failed memory allocation in two functions pinctrl: adi2: Improve a size determination in two functions pinctrl: msm: Delete an error message for a failed memory allocation in msm_pinctrl_probe() pinctrl: at91: Delete an error message for a failed memory allocation in at91_pinctrl_mux_mask() pinctrl: palmas: Delete an error message for a failed memory allocation in palmas_pinctrl_probe() pinctrl: rockchip: Delete error messages for a failed memory allocation in two functions pinctrl: rockchip: Improve a size determination in rockchip_pinctrl_probe() pinctrl: rockchip: Fix a typo in four comment lines pinctrl: single: Delete an error message for a failed memory allocation in pcs_probe() pinctrl: single: Delete an unnecessary return statement in pcs_irq_chain_handler() pinctrl: tz1090: Delete an error message for a failed memory allocation in two functions pinctrl: tz1090-pdc: Delete an error message for a failed memory allocation in two functions pinctrl: utils: Delete an error message for a failed memory allocation in pinctrl_utils_add_map_configs() pinctrl: xway: Delete two error messages for a failed memory allocation in pinmux_xway_probe() pinctrl/spear/plgpio: Delete two error messages for a failed memory allocation in plgpio_probe() pinctrl: spear: Delete an error message for a failed memory allocation in spear_pinctrl_probe() pinctrl: tegra: Delete two error messages for a failed memory allocation in tegra_pinctrl_probe() pinctrl: vt8500: Delete an error message for a failed memory allocation in five functions pinctrl: mcp23s08: Combine two function calls into one in mcp23s08_dbg_show() pinctrl: abx500: Use seq_putc() in abx500_gpio_dbg_show() pinctrl: pinmux: Use seq_putc() in pinmux_pins_show() pinctrl: sprd: Use seq_putc() in sprd_pinconf_group_dbg_show() Masahiro Yamada (4): gpio: uniphier: fix mismatch between license text and MODULE_LICENSE dt-bindings: pinctrl: uniphier: add UniPhier pinctrl binding pinctrl: remove redundant mux_setting clear in pinmux_disable_setting() pinctrl: uniphier: refactor drive strength get/set functions Mika Westerberg (4): gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation pinctrl: intel: Allow custom GPIO base for pad groups pinctrl: cannonlake: Align GPIO number space with Windows pinctrl: intel: Initialize GPIO properly when used through irqchip Peter Rosin (3): pinctrl: sx150x: Unregister the pinctrl on release pinctrl: sx150x: Register pinctrl before adding the gpiochip pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping Quentin Schulz (10): gpio: axp209: switch unsigned variables to unsigned int pinctrl: move gpio-axp209 to pinctrl pinctrl: axp209: add pinctrl features dt-bindings: gpio: gpio-axp209: add pinctrl features pinctrl: axp209: rename everything from gpio to pctl pinctrl: axp209: add programmable gpio_status_offset pinctrl: axp209: add programmable ADC muxing value pinctrl: axp209: add support for AXP813 GPIOs pinctrl: axp209: dereference pointer after it's been set pinctrl: axp209: add missing Kconfig dependencies Ramesh Shanmugasundaram (2): pinctrl: sh-pfc: r8a7795: Add CAN support pinctrl: sh-pfc: r8a7795: Add CAN FD support Sean Wang (6): dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC pinctrl: mediatek: cleanup for placing all drivers under the menu pinctrl: mediatek: add pinctrl driver for MT7622 SoC pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl driver pinctrl: mediatek: mt7622: fix potential uninitialized value being returned pinctrl: mediatek: mt7622: align error handling of mtk_hw_get_value call Sergei Shtylyov (2): pinctrl: sh-pfc: Add PORT_GP_CFG_{6|22}() helper macros pinctrl: sh-pfc: Add R8A77970 PFC support Stefan Agner (4): pinctrl: imx: use struct imx_pinctrl_soc_info as a const pinctrl: imx7d: simplify imx7d_pinctrl_probe pinctrl: imx: constify struct imx_pinctrl_soc_info pinctrl: imx7ulp: constify struct imx_cfg_params_decode Takeshi Kihara (6): pinctrl: sh-pfc: r8a7795: Add GP-1-28 port pin support pinctrl: sh-pfc: r8a7795-es1: Fix MOD_SEL1 bit[25:24] to 0x3 when using STP_ISEN_1_D pinctrl: sh-pfc: r8a7795: Fix to delete A20..A25 pins function definitions pinctrl: sh-pfc: r8a7796: Fix to delete A20..A25 pins function definitions pinctrl: sh-pfc: r8a7795: Rename RTS{0,1,3,4}# pin function definitions pinctrl: sh-pfc: r8a7796: Rename RTS{0,1,3,4}# pin function definitions Tony Lindgren (1): pinctrl: single: Remove invalid message Ulrich Hecht (3): pinctrl: sh-pfc: r8a77995: Add missing pins SCL0 and SDA0 to pinmux data pinctrl: sh-pfc: r8a77995: Add CAN support pinctrl: sh-pfc: r8a77995: Add CAN FD support Wei Yongjun (1): pinctrl: ingenic: Remove redundant dev_err call in ingenic_pinctrl_probe() Wolfram Sang (1): pinctrl: sh-pfc: r8a7795: Add SATA pins, groups, and functions Xingyu Chen (3): documentation: Add compatibles for Amlogic Meson AXG pin controllers pinctrl: meson-axg: Introduce a pinctrl pinmux ops for Meson-AXG SoC pinctrl: meson-axg: Add new pinctrl driver for Meson AXG SoC Yixun Lan (1): pinctrl: meson-axg: adjust spicc pin naming hao_zhang (1): pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly. Documentation/devicetree/bindings/arm/stm32.txt | 9 + .../devicetree/bindings/gpio/gpio-axp209.txt | 49 +- .../bindings/pinctrl/cortina,gemini-pinctrl.txt | 3 + .../bindings/pinctrl/fsl,imx6ul-pinctrl.txt | 3 +- .../devicetree/bindings/pinctrl/meson,pinctrl.txt | 2 + .../bindings/pinctrl/mscc,ocelot-pinctrl.txt | 39 + .../devicetree/bindings/pinctrl/pinctrl-mt7622.txt | 351 +++ .../bindings/pinctrl/qcom,msm8998-pinctrl.txt | 193 ++ .../bindings/pinctrl/renesas,pfc-pinctrl.txt | 1 + .../pinctrl/socionext,uniphier-pinctrl.txt | 27 + .../bindings/pinctrl/st,stm32-pinctrl.txt | 2 + MAINTAINERS | 11 + drivers/gpio/Kconfig | 6 - drivers/gpio/Makefile | 1 - drivers/gpio/gpio-axp209.c | 188 -- drivers/gpio/gpio-uniphier.c | 2 +- drivers/gpio/gpiolib-acpi.c | 75 +- drivers/pinctrl/Kconfig | 25 + drivers/pinctrl/Makefile | 4 +- drivers/pinctrl/core.c | 24 +- drivers/pinctrl/freescale/pinctrl-imx.c | 81 +- drivers/pinctrl/freescale/pinctrl-imx.h | 13 +- drivers/pinctrl/freescale/pinctrl-imx25.c | 2 +- drivers/pinctrl/freescale/pinctrl-imx35.c | 2 +- drivers/pinctrl/freescale/pinctrl-imx50.c | 2 +- drivers/pinctrl/freescale/pinctrl-imx51.c | 2 +- drivers/pinctrl/freescale/pinctrl-imx53.c | 2 +- drivers/pinctrl/freescale/pinctrl-imx6dl.c | 2 +- drivers/pinctrl/freescale/pinctrl-imx6q.c | 2 +- drivers/pinctrl/freescale/pinctrl-imx6sl.c | 2 +- drivers/pinctrl/freescale/pinctrl-imx6sx.c | 2 +- drivers/pinctrl/freescale/pinctrl-imx6ul.c | 52 +- drivers/pinctrl/freescale/pinctrl-imx7d.c | 10 +- drivers/pinctrl/freescale/pinctrl-imx7ulp.c | 7 +- drivers/pinctrl/freescale/pinctrl-vf610.c | 5 +- drivers/pinctrl/intel/pinctrl-baytrail.c | 6 + drivers/pinctrl/intel/pinctrl-cannonlake.c | 65 +- drivers/pinctrl/intel/pinctrl-cherryview.c | 59 +- drivers/pinctrl/intel/pinctrl-intel.c | 179 +- drivers/pinctrl/intel/pinctrl-intel.h | 3 + drivers/pinctrl/intel/pinctrl-merrifield.c | 7 + drivers/pinctrl/mediatek/Kconfig | 15 +- drivers/pinctrl/mediatek/Makefile | 3 +- drivers/pinctrl/mediatek/pinctrl-mt7622.c | 1597 ++++++++++++++ drivers/pinctrl/meson/Kconfig | 9 + drivers/pinctrl/meson/Makefile | 2 + drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c | 118 + drivers/pinctrl/meson/pinctrl-meson-axg-pmx.h | 62 + drivers/pinctrl/meson/pinctrl-meson-axg.c | 975 ++++++++ drivers/pinctrl/meson/pinctrl-meson.h | 1 + drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 4 +- drivers/pinctrl/mvebu/pinctrl-mvebu.c | 5 +- drivers/pinctrl/nomadik/pinctrl-abx500.c | 10 +- drivers/pinctrl/pinctrl-adi2.c | 13 +- drivers/pinctrl/pinctrl-at91-pio4.c | 4 +- drivers/pinctrl/pinctrl-at91.c | 4 +- drivers/pinctrl/pinctrl-axp209.c | 478 ++++ drivers/pinctrl/pinctrl-gemini.c | 84 +- drivers/pinctrl/pinctrl-ingenic.c | 4 +- drivers/pinctrl/pinctrl-mcp23s08.c | 54 +- drivers/pinctrl/pinctrl-ocelot.c | 511 +++++ drivers/pinctrl/pinctrl-palmas.c | 4 +- drivers/pinctrl/pinctrl-rockchip.c | 31 +- drivers/pinctrl/pinctrl-single.c | 10 +- drivers/pinctrl/pinctrl-sx150x.c | 40 +- drivers/pinctrl/pinctrl-tz1090-pdc.c | 9 +- drivers/pinctrl/pinctrl-tz1090.c | 9 +- drivers/pinctrl/pinctrl-utils.c | 4 +- drivers/pinctrl/pinctrl-xway.c | 10 +- drivers/pinctrl/pinmux.c | 4 +- drivers/pinctrl/pxa/pinctrl-pxa2xx.c | 4 + drivers/pinctrl/qcom/Kconfig | 8 + drivers/pinctrl/qcom/Makefile | 1 + drivers/pinctrl/qcom/pinctrl-msm.c | 5 +- drivers/pinctrl/qcom/pinctrl-msm8998.c | 1590 +++++++++++++ drivers/pinctrl/samsung/Kconfig | 1 + drivers/pinctrl/samsung/pinctrl-exynos-arm.c | 33 +- drivers/pinctrl/samsung/pinctrl-exynos-arm64.c | 33 +- drivers/pinctrl/samsung/pinctrl-exynos.c | 33 +- drivers/pinctrl/samsung/pinctrl-exynos.h | 6 +- drivers/pinctrl/samsung/pinctrl-exynos5440.c | 21 +- drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 23 +- drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 27 +- drivers/pinctrl/samsung/pinctrl-samsung.c | 37 +- drivers/pinctrl/samsung/pinctrl-samsung.h | 6 +- drivers/pinctrl/sh-pfc/Kconfig | 5 + drivers/pinctrl/sh-pfc/Makefile | 1 + drivers/pinctrl/sh-pfc/core.c | 6 + drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 62 +- drivers/pinctrl/sh-pfc/pfc-r8a7794.c | 473 ++++ drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c | 2 +- drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 193 +- drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 66 +- drivers/pinctrl/sh-pfc/pfc-r8a77970.c | 2329 ++++++++++++++++++++ drivers/pinctrl/sh-pfc/pfc-r8a77995.c | 88 + drivers/pinctrl/sh-pfc/sh_pfc.h | 17 +- drivers/pinctrl/spear/pinctrl-plgpio.c | 8 +- drivers/pinctrl/spear/pinctrl-spear.c | 4 +- drivers/pinctrl/sprd/pinctrl-sprd.c | 2 +- drivers/pinctrl/stm32/Kconfig | 12 + drivers/pinctrl/stm32/Makefile | 2 + drivers/pinctrl/stm32/pinctrl-stm32.c | 3 +- drivers/pinctrl/stm32/pinctrl-stm32.h | 3 +- drivers/pinctrl/stm32/pinctrl-stm32f429.c | 3 +- drivers/pinctrl/stm32/pinctrl-stm32f469.c | 6 +- drivers/pinctrl/stm32/pinctrl-stm32f746.c | 3 +- drivers/pinctrl/stm32/pinctrl-stm32f769.c | 1827 +++++++++++++++ drivers/pinctrl/stm32/pinctrl-stm32h743.c | 6 +- drivers/pinctrl/stm32/pinctrl-stm32mp157.c | 2188 ++++++++++++++++++ drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c | 2 +- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 7 +- drivers/pinctrl/tegra/pinctrl-tegra.c | 9 +- drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 176 +- drivers/pinctrl/vt8500/pinctrl-vt8500.c | 4 +- drivers/pinctrl/vt8500/pinctrl-wm8505.c | 4 +- drivers/pinctrl/vt8500/pinctrl-wm8650.c | 4 +- drivers/pinctrl/vt8500/pinctrl-wm8750.c | 4 +- drivers/pinctrl/vt8500/pinctrl-wm8850.c | 4 +- include/dt-bindings/gpio/meson-axg-gpio.h | 116 + include/dt-bindings/pinctrl/stm32-pinfunc.h | 6 + include/linux/pinctrl/devinfo.h | 2 + 121 files changed, 14122 insertions(+), 947 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/stm32.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.txt delete mode 100644 drivers/gpio/gpio-axp209.c create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7622.c create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg-pmx.h create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg.c create mode 100644 drivers/pinctrl/pinctrl-axp209.c create mode 100644 drivers/pinctrl/pinctrl-ocelot.c create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8998.c create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a77970.c create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f769.c create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32mp157.c create mode 100644 include/dt-bindings/gpio/meson-axg-gpio.h -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html