[GIT,PULL] pin control bulk changes for v4.16

Message ID CACRpkdaTv4NBrRXeJE6dVi4W88+LZdsTCSzTHi0vdcKMW3Qfmw@mail.gmail.com
State New
Headers show
Series
  • [GIT,PULL] pin control bulk changes for v4.16
Related show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git

Message

Linus Walleij Feb. 2, 2018, 1:28 p.m.
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

Comments

Linus Torvalds Feb. 2, 2018, 10:56 p.m. | #1
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
Linus Torvalds Feb. 3, 2018, 12:44 a.m. | #2
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;
Linus Torvalds Feb. 3, 2018, 12:51 a.m. | #3
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
Ingo Molnar Feb. 3, 2018, 10:45 a.m. | #4
* 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
Linus Walleij Feb. 5, 2018, 9:20 a.m. | #5
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
Julia Lawall Feb. 5, 2018, 9:27 a.m. | #6
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
Linus Walleij Feb. 5, 2018, 9:42 a.m. | #7
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
Julia Lawall Feb. 5, 2018, 9:58 a.m. | #8
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
David Laight Feb. 5, 2018, 10:09 a.m. | #9
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
Linus Torvalds Feb. 5, 2018, 4:55 p.m. | #10
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
Linus Torvalds Feb. 5, 2018, 5:19 p.m. | #11
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
Paul Gortmaker Feb. 5, 2018, 7:08 p.m. | #12
[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