This was done entirely with mindless brute force, using

    git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
        xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'

to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.

Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.

For the same reason the 'flex' versions will be done as a separate
conversion.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations:	kmalloc(sizeof(TYPE), ...)
are replaced with:	kmalloc_obj(TYPE, ...)

Array allocations:	kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with:	kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations:	kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with:	kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook <kees@kernel.org>

This generic pin config property is confusingly named so let's
rename it to make things clearer.

There are already drivers in the tree that use PIN_CONFIG_OUTPUT
to *read* the value of an output driven pin, which is a big
semantic confusion for the head: are we then reading the
setting of the output or the actual value/level that is put
out on the pin?

We already have PIN_CONFIG_OUTPUT_ENABLE that turns on driver
buffers for output, so this can by logical conclusion only
drive the voltage level if it should be any different.

But if we read the pin, are we then reading the *setting* of
the output value or the *actual* value we can see on the
line?

If the pin has not first been set into output mode with
PIN_CONFIG_OUTPUT_ENABLE, but is instead in some input mode
or tristate, what will reading this property actually
return?

Reading the current users reading this property it is clear
that what we read is the logical level of the pin as 0 or 1
depending on if it is low or high.

Rename it to PIN_CONFIG_LEVEL so it is crystal clear that
we set or read the voltage level of the pin and nothing else.

Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The conversion of all GPIO drivers to using the .set_rv() and
.set_multiple_rv() callbacks from struct gpio_chip (which - unlike their
predecessors - return an integer and allow the controller drivers to
indicate failures to users) is now complete and the legacy ones have
been removed. Rename the new callbacks back to their original names in
one sweeping change.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/20250612-gpiochip-set-rv-pinctrl-remaining-v1-1-556b0a530cd4@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Use the new gpiochip_dup_line_label() helper to safely retrieve the
descriptor label.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Acked-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230714174901.4062397-1-robh@kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Fix Smatch static checker warning:
potential null dereference 'configs'. (kmalloc returns null)

Changes in v2:
1. Add free allocated memory before returned -ENOMEM.
2. Add call of_node_put() before returned -ENOMEM.

Fixes: aa74c44be19c ("pinctrl: Add driver for Sunplus SP7021")
Signed-off-by: Wells Lu <wellslutw@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/1685277277-12209-1-git-send-email-wellslutw@gmail.com
[Rebased on the patch from Lu Hongfei]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Fix Smatch static checker warning:
potential null dereference 'configs'. (kmalloc returns null)

Fixes: aa74c44be19c ("pinctrl: Add driver for Sunplus SP7021")
Signed-off-by: Wells Lu <wellslutw@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/1685277277-12209-1-git-send-email-wellslutw@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Pull pin control updates from Linus Walleij:
 "Nothing special, notably a lot of new Qualcomm hardware is supported,
  a RISC-V reference SoC and then some cleanups both in code and device
  tree bindings.

  Core changes:

   - Add PINCTRL_PINFUNCTION() macro and use it in several drivers

  New drivers:

   - New driver for the StarFive JH7110 SoC "sys" and "aon" (always-on)
     pin controllers. (RISC-V.)

   - New subdriver for the Qualcomm QDU1000/QRU1000 SoC pin controller

   - New subdrivers for the Qualcomm SM8550 SoC and LPASS pin
     controllers

   - New subdriver for the Qualcomm SA8775P SoC pin controller

   - New subdriver for the Qualcomm IPQ5332 SoC pin controller

   - New (trivial) support for Qualcomm PM8550 and PMR735D PMIC pin
     control

   - New subdriver for the Mediatek MT7981 SoC pin controller

  Improvements:

   - Several cleanups and refactorings to the Intel drivers

   - Add 4KOhm bias support to the Intel driver

   - Use the NOIRQ_SYSTEM_SLEEP_PM_OPS for the AT91 driver

   - Support general purpose clocks in the Qualcomm MSM8226 SoC

   - Several conversions to use the new I2C .probe_new() call

   - Massive clean-up of the Qualcomm Device Tree YAML schemas

   - Add VIN[45] pins, groups and functions to the Renesas r8a77950 SoC
     driver"

* tag 'pinctrl-v6.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (118 commits)
  pinctrl: qcom: Add support for i2c specific pull feature
  pinctrl: starfive: Add StarFive JH7110 aon controller driver
  pinctrl: starfive: Add StarFive JH7110 sys controller driver
  dt-bindings: pinctrl: Add StarFive JH7110 aon pinctrl
  dt-bindings: pinctrl: Add StarFive JH7110 sys pinctrl
  pinctrl: add mt7981 pinctrl driver
  dt-bindings: pinctrl: add bindings for MT7981 SoC
  dt-bindings: pinctrl: rockchip,pinctrl: mark gpio sub nodes of pinctrl as deprecated
  pinctrl: qcom: Introduce IPQ5332 TLMM driver
  dt-bindings: pinctrl: qcom: add IPQ5332 pinctrl
  dt-bindings: pinctrl: qcom: lpass-lpi: correct GPIO name pattern
  pinctrl: qcom: pinctrl-sm8550-lpass-lpi: add SM8550 LPASS
  dt-bindings: pinctrl: qcom,sm8550-lpass-lpi-pinctrl: add SM8550 LPASS
  pinctrl: at91: use devm_kasprintf() to avoid potential leaks
  dt-bindings: pinctrl: qcom: correct gpio-ranges in examples
  dt-bindings: pinctrl: qcom,msm8994: correct number of GPIOs
  dt-bindings: pinctrl: qcom,sdx55: correct GPIO name pattern
  dt-bindings: pinctrl: qcom,msm8953: correct GPIO name pattern
  dt-bindings: pinctrl: qcom,sm6375: correct GPIO name pattern and example
  dt-bindings: pinctrl: qcom,msm8909: correct GPIO name pattern and example
  ...