Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Replace the pinctrl helpers taking the global GPIO number as argument
with the improved variants that instead take a pointer to the GPIO chip
and the controller-relative offset.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Currently the pinctrl GPIO helpers all take a number from the global
GPIO numberspace - of which we're trying to get rid of as argument.
These helpers are almost universally called from GPIOLIB driver
callbacks which take a pointer to the backing gpio_chip and the
controller-relative offset as arguments.
Let's provide improved variants of these functions that match the
GPIOLIB signatures as the first step in removing the older flavor.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
New drivers:
- Realtek RTD family pin control driver and RTD1619B,
RTD1319D and RTD1315E subdrivers.
- Nuvoton NPCM8xx combined pin control and GPIO driver.
- Amlogic T7 pin control driver.
- Renesas RZ/G3S pin control driver.
Improvements:
- A number of additional UART groups added to the Mediatek
MT7981 driver.
- MPM pin maps added for Qualcomm MSM8996, SM6115, SM6125
and SDM660.
- Extra GPIO banks for the Sunxi H616.
- MLSP I2C6 function support in Qualcomm MSM8226.
- Some __counted_by() annotations for dynamic arrays.
- Ongoing work to make remove() return void.
- LSBC groups and functions in the Renesas R8A7778.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmVEp+oACgkQQRCzN7AZ
XXPmqg/7BX2u2/1jpOpEjoqbUC7KEU3ptR2j1vAMCBibBq0IsnHVUH3DQ80leEpf
gcf5vbY72PCTg5KGYZZ35XvrqzEP/z25qOnUZ+4Y7JljoXyNBb6eW1I3UstdPR1C
E9hFVjMVFD7YePCGK/Ytwp/1dFLgLsADjk6Zc4gfHlPV/Op8NaxIIcM0FjFvu+X1
znf3lRkaxedhdM0TsL6efOoNXJNHGZNXI+dUzgbEr+fyYcjHJFjh8HejJvcZDyvc
581k6EVE0aGBz857OZz+ojADhtnE2+GYCB2kkdT5iHFeHtHGbRrwIc6Fh3gInMBI
6yj86AaZEFJwLec/ckMn+kWdKwF17Q2qUOryr7UHlU8YP5DBAjSAZaocFynNto+I
ikQPde2s04tRpveMCJSYnvy2eQpJ2DEpWtkSAGMzg0Ly71zfSH1TMrhjR9AxDP0F
nrIBB7hEzTosxvrFTXHcCh8LxSDlohUL/UveA2Tiz/m1gvR51OnIx61EzqizHF5x
WkuLxgLlC4P1ZqFyV1guwcOqUD4rpwpqTyIgAIoVIQfnvZR5jgFXHBKDJPXyjJTD
oDEX8fVWX0xzwAoqBXqVs/TJcD9q8qKuuPaK8266XP5D/zM/PP1jRKQnC8IFPSq2
Ory4TDLCrSmVw+c8q+jZHgKiEXuwGzPJ+ImypTMV+uZZzCdR4YE=
=vonG
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v6.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control updates from Linus Walleij:
"No pin control core changes this time.
New drivers:
- Realtek RTD family pin control driver and RTD1619B, RTD1319D and
RTD1315E subdrivers
- Nuvoton NPCM8xx combined pin control and GPIO driver
- Amlogic T7 pin control driver
- Renesas RZ/G3S pin control driver
Improvements:
- A number of additional UART groups added to the Mediatek MT7981
driver
- MPM pin maps added for Qualcomm MSM8996, SM6115, SM6125 and SDM660
- Extra GPIO banks for the Sunxi H616
- MLSP I2C6 function support in Qualcomm MSM8226
- Some __counted_by() annotations for dynamic arrays
- Ongoing work to make remove() return void
- LSBC groups and functions in the Renesas R8A7778"
* tag 'pinctrl-v6.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (110 commits)
pinctrl: Use device_get_match_data()
dt-bindings: pinctrl: qcom,sa8775p-tlmm: add missing wakeup-parent
dt-bindings: pinctrl: nuvoton,npcm845: Add missing additionalProperties on gpio child nodes
dt-bindings: pinctrl: brcm: Ensure all child node properties are documented
pinctrl: renesas: rzn1: Convert to platform remove callback returning void
pinctrl: renesas: rzg2l: Add RZ/G3S support
dt-bindings: pinctrl: renesas: Document RZ/G3S SoC
pinctrl: renesas: rzg2l: Add support for different DS values on different groups
pinctrl: renesas: rzg2l: Move DS and OI to SoC-specific configuration
pinctrl: renesas: rzg2l: Adapt function number for RZ/G3S
pinctrl: renesas: rzg2l: Adapt for different SD/PWPR register offsets
pinctrl: renesas: rzg2l: Index all registers based on port offset
pinctrl: renesas: rzg2l: Add validation of GPIO pin in rzg2l_gpio_request()
pinctrl: renesas: r8a7778: Add LBSC pins, groups, and functions
pinctrl: intel: fetch community only when we need it
pinctrl: cherryview: reduce scope of PIN_CONFIG_BIAS_HIGH_IMPEDANCE case
pinctrl: cherryview: Convert to platform remove callback returning void
pinctrl: sprd-sc9860: Convert to platform remove callback returning void
pinctrl: qcom/msm: Convert to platform remove callback returning void
pinctrl: qcom/lpi: Convert to platform remove callback returning void
...
GPIOLIB core:
- provide interfaces allowing users to retrieve, manage and query the
reference counted GPIO device instead of accessing the private gpio_chip
structure
- replace gpiochip_find() with gpio_device_find()
- remove unused acpi_get_and_request_gpiod()
- improve the ignore_interrupt functionality in GPIO ACPI
- correct notifier return codes in gpiolib-of
- unexport gpiod_set_transitory() as it's unused outside of core GPIO code
- while there are still external users accessing struct gpio_chip, let's
make gpiochip_get_desc() public so that they at least use the preferred
helper
- improve locking for lookup tables
- annotate struct linereq with __counted_by
- improve GPIOLIB docs
- add an OF quirk for LED trigger sources
Driver improvements:
- convert all GPIO drivers with .remove() callbacks to using the new
variant returning void instead of int
- stop accessing the GPIOLIB private structures in gpio-mockup,
i2c-mux-gpio, hte-tegra194, gpio-sim
- use the recommended pattern for autofree variables in gpio-sim
- add support for more models to gpio-loongson
- use a notifier chain to notify other blocks about interrupts in
gpio-eic-sprd instead of looking up GPIO devices on every interrupt
- convert gpio-pca953x and gpio-fx6408 to using the maple tree regmap
cache
- don't include GPIOLIB internal headers in drivers which don't need them
- move the ingenic NAND quirk into gpiolib-of
- add an ignore interrupt quirk for Peaq C1010
- drop static GPIO base from gpio-omap, gpio-f7188x
- use the preferred device_get_match_data() function in drivers that still
don't
- refactor gpio-pca953x: switch to using DEFINE_SIMPLE_DEV_PM_OPS(), use
cleanup helpers, use dev_err_probe() where it makes sense, fully convert
to using devres and some other minor tweaks
DT bindings:
- add support for a new model to gpio-vf610 and update existing properties
- add support for more loongson models
- add missing support for imx models that are used but undocumented
- convert bindings for Intel IXP4xx to schema
Minor stuff:
- deprecate gpio-mockup in favor of gpio-sim
- include missing headers here and there
- stop using gpiochip_find() in OMAP1 board files
- minor tweaks in gpio-vf610, gpio-hisi
- remove unneeded 'extern' specifiers from headers
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmU7ixgACgkQEacuoBRx
13JwfxAA4CeZdXdUpx6EMUw+6ST4EWb5JanrPjNcQbyBxNFrHx+6yJJL4AOQJStQ
WkG+Zi8Li9uV3wZQixBDs0WN8xVwJU+4QLSwwtNhEjl2x9MkVjghh4la6TqBrMj8
e/iJufTyKUgcm2P4MRTDXFarAin4doBQUPKWfCgL18VvlKxLXG0KMndUl3jAd/Rm
YZLm4Z/iqWaxjfrm+E9LfWFmWS5T7t/g+7TYzMp2AHQ9dHFiwoodpiHTkdWH4dfL
zxF8Ek2132Up0BYC1lQlwz1aoLIlHcr9xVOqOrIxZI/B5xRcUfoXnQQmCCfH2UYr
wtfwKMI7IO2d5E+F7anFC67d9wm7tWacKEifw9lWUAD6xr6yv/13ZOU6aoWXj1Vq
xOMe6gEeZSboF/XiqlmrpZYH+ljDp/mYWkGcOJrUg7WYUgvUCFWu6l6DmuUFMr7m
ACtOUqwbTuWTXN28QtMOpjiQRqlAWyrY6PqhBCllhmcjsoVaZNgWEfriPlSOyoBg
EBRBcURXLs7/h86nEsK/8BIsC0myHbpNiNpG5qaMjrrYJxMh4qS4MIG83MWAy1dZ
8ZtYrxx4XClyaYwYomsIkseLaSCrBTIoYws7wmyTjYfKC7P/t6/XXPS1suyMnf9I
/n5tN8Rv1pDrnS3iQflHQVl9H5m4yezHOOBJUiWW+gs5MUr4vK0=
=1QF8
-----END PGP SIGNATURE-----
Merge tag 'gpio-updates-for-v6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio updates from Bartosz Golaszewski:
"We don't have any new drivers. The loongson driver is getting extended
with support for new models. There's a big refactor of gpio-pca953x
and many small improvements to others.
The GPIO code in the kernel has acquired a lot of cruft over the years
as well as many abusers of the API across the kernel tree. This
release cycle we have started a major cleanup and improvement effort
that will most likely span several releases. We have started by
converting external users of struct gpio_chip to accessing the wrapper
around it - struct gpio_device. This is because the latter is
reference counted while the former is removed when the provider is
unbound. We also removed several instances of drivers accessing
private GPIOLIB structures and including the private header from
drivers/gpio/.
To that end you'll see several commits aimed at different subsystems
(acked by relevant maintainers) as well as two merges from the
x86/platform tree.
We'll then rework the locking in GPIOLIB which currently uses a big
spinlock for many different things and could use becoming more
fine-grained, especially as it doesn't even get the locking right.
We'll also use SRCU for protecting the gpio_chip pointer against
in-kernel hot-unplug crashes similar to what we saw triggered from
user-space and fixed with semaphores in gpiolib-cdev. The core GPIOLIB
is still vulnerable to these use-cases. I'm just mentioning the plans
here, this is not part of this PR.
You'll see some new instances of using __free(). We've added a
gpio_device_put cleanup helper similar to the put_device one
introduced by Peter Zijlstra and used it according to the preferred
pattern except where it didn't make sense.
GPIOLIB core:
- provide interfaces allowing users to retrieve, manage and query the
reference counted GPIO device instead of accessing the private
gpio_chip structure
- replace gpiochip_find() with gpio_device_find()
- remove unused acpi_get_and_request_gpiod()
- improve the ignore_interrupt functionality in GPIO ACPI
- correct notifier return codes in gpiolib-of
- unexport gpiod_set_transitory() as it's unused outside of core GPIO
code
- while there are still external users accessing struct gpio_chip,
let's make gpiochip_get_desc() public so that they at least use the
preferred helper
- improve locking for lookup tables
- annotate struct linereq with __counted_by
- improve GPIOLIB docs
- add an OF quirk for LED trigger sources
Driver improvements:
- convert all GPIO drivers with .remove() callbacks to using the new
variant returning void instead of int
- stop accessing the GPIOLIB private structures in gpio-mockup,
i2c-mux-gpio, hte-tegra194, gpio-sim
- use the recommended pattern for autofree variables in gpio-sim
- add support for more models to gpio-loongson
- use a notifier chain to notify other blocks about interrupts in
gpio-eic-sprd instead of looking up GPIO devices on every interrupt
- convert gpio-pca953x and gpio-fx6408 to using the maple tree regmap
cache
- don't include GPIOLIB internal headers in drivers which don't need
them
- move the ingenic NAND quirk into gpiolib-of
- add an ignore interrupt quirk for Peaq C1010
- drop static GPIO base from gpio-omap, gpio-f7188x
- use the preferred device_get_match_data() function in drivers that
still don't
- refactor gpio-pca953x: switch to using DEFINE_SIMPLE_DEV_PM_OPS(),
use cleanup helpers, use dev_err_probe() where it makes sense,
fully convert to using devres and some other minor tweaks
DT bindings:
- add support for a new model to gpio-vf610 and update existing
properties
- add support for more loongson models
- add missing support for imx models that are used but undocumented
- convert bindings for Intel IXP4xx to schema
Minor stuff:
- deprecate gpio-mockup in favor of gpio-sim
- include missing headers here and there
- stop using gpiochip_find() in OMAP1 board files
- minor tweaks in gpio-vf610, gpio-hisi
- remove unneeded 'extern' specifiers from headers"
* tag 'gpio-updates-for-v6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (108 commits)
hte: tegra194: add GPIOLIB dependency
hte: tegra194: don't access struct gpio_chip
gpiolib: provide gpio_device_get_base()
i2c: mux: gpio: don't fiddle with GPIOLIB internals
gpiolib: provide gpiod_to_gpio_device()
gpiolib: provide gpio_device_to_device()
gpio: hisi: Fix format specifier
gpiolib: provide gpio_device_find_by_fwnode()
gpio: acpi: remove acpi_get_and_request_gpiod()
gpio: Use device_get_match_data()
gpio: vf610: update comment for i.MX8ULP and i.MX93 legacy compatibles
platform/x86: int3472: Switch to devm_get_gpiod()
platform/x86: int3472: Stop using gpiod_toggle_active_low()
platform/x86: int3472: Add new skl_int3472_gpiod_get_from_temp_lookup() helper
platform/x86: int3472: Add new skl_int3472_fill_gpiod_lookup() helper
gpio: vf610: simplify code by dropping data check
gpio: vf610: add i.MX8ULP of_device_id entry
dt-bindings: gpio: vf610: add i.MX95 compatible
dt-bindings: gpio: vf610: correct i.MX8ULP and i.MX93
dt-bindings: gpio: vf610: update gpio-ranges
...
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20231009172923.2457844-18-robh@kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Merge ACPI EC driver updates, ACPI sysfs interface updates, misc updates
related to ACPI and changes related to ACPI _UID handling for 6.7-rc1:
- Add EC GPE detection quirk for HP 250 G7 Notebook PC (Jonathan
Denose).
- Fix and clean up create_pnp_modalias() and create_of_modalias()
(Christophe JAILLET).
- Modify 2 pieces of code to use acpi_evaluate_dsm_typed() (Andy
Shevchenko).
- Define acpi_dev_uid_match() for matching _UID and use it in several
places (Raag Jadav).
- Use acpi_device_uid() for fetching _UID in 2 places (Raag Jadav).
* acpi-ec:
ACPI: EC: Add quirk for HP 250 G7 Notebook PC
* acpi-sysfs:
ACPI: sysfs: Clean up create_pnp_modalias() and create_of_modalias()
ACPI: sysfs: Fix create_pnp_modalias() and create_of_modalias()
* acpi-misc:
ACPI: x86: s2idle: Switch to use acpi_evaluate_dsm_typed()
ACPI: PCI: Switch to use acpi_evaluate_dsm_typed()
* acpi-uid:
perf: arm_cspmu: use acpi_dev_hid_uid_match() for matching _HID and _UID
ACPI: x86: use acpi_dev_uid_match() for matching _UID
ACPI: utils: use acpi_dev_uid_match() for matching _UID
pinctrl: intel: use acpi_dev_uid_match() for matching _UID
ACPI: utils: Introduce acpi_dev_uid_match() for matching _UID
perf: qcom: use acpi_device_uid() for fetching _UID
ACPI: sysfs: use acpi_device_uid() for fetching _UID
Convert manual _UID references to use the standard ACPI helper.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge "Drop runtime PM support for Baytrail and Lynxpoint pinctrl" (Raag)
* Small improvements here and there in the Intel pin control drivers (Raag)
* Switch to RAII for locking in the Intel core and Cherry View drivers
* Enable non-ACPI enumeration in the Intel Denverton driver
* Use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS() in a couple of drivers
* Introduce array_size.h and use in in the Intel pin control drivers
The following is an automated git shortlog grouped by driver:
baytrail:
- Replace kernel.h by what is actually being used
- drop runtime PM support
- fix debounce disable case
broxton:
- Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE()
cherryview:
- reduce scope of PIN_CONFIG_BIAS_HIGH_IMPEDANCE case
- Convert to platform remove callback returning void
- Simplify code with cleanup helpers
- Avoid duplicated I/O
- Replace kernel.h by what is actually being used
denverton:
- Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE()
- Enable platform device in the absence of ACPI enumeration
intel:
- fetch community only when we need it
- refine intel_config_set_pull() function
- Replace kernel.h by what is actually being used
- Simplify code with cleanup helpers
lynxpoint:
- Replace kernel.h by what is actually being used
- drop runtime PM support
merrifield:
- Replace kernel.h by what is actually being used
moorefield:
- Replace kernel.h by what is actually being used
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEqaflIX74DDDzMJJtb7wzTHR8rCgFAmUtPmkACgkQb7wzTHR8
rCjQ2Q/+MdyxO1vlv2ZN6xpY25lpzELfRs6S2EHcrnRMoONjH6t1k6yh2Xmnlmte
byMFggOSDoyZAmqzmQioWo6e8tO9zme17mAhNOnmNpZ4luyPOhgCp0SF61UpOrl/
r2MBJyhFfCyI/7aXQ8p0+tVX988CgezYWEhfeXP2Xt10o90eK+fbks8bBW5a3gZ5
Gpx3L3EXkBBIpW4ec1ji4vXNKiKVvePZZWIb612KZ3ttfk7jGqaC3kJXFFGGWO2z
eKxuuDo5oNbYocS+/jNxSCBBoqKw50r507sqireQ/cV3H22wOK/OmejKJzSPszqB
tQnvafqx8EaNLajhDW9EG1nzexeYbT6jHaNg/b2y0rSPWNSwi5zXgL2lEaPo+c5N
Pv9Ys6dp+ftfM/zO8fjKWOYyjo0zqTRAB/yxTwfw+hXUvMQuzbHOaoMnVpmj+7he
GqRbjyM5thWYFTFIz7Hearq12a9csvJPNKWz4ClPey4/AEkMyR0csvIgkmh8GZu+
ORPwKmGIqQWC1JkJKMsmLx4j92JPN0xaIf6ILTMwgnzYihhPeCfIFMv1VbXZCaZA
SfdbwK2f4cGMUS2s16Zf3Dl79jSrJ140igmCvsz8HDBZrz2C6Bey0qnWF4tQEy1Q
NVGpyYpDTNtLZxelDZfB6bezyYoX7TLlCoTUvcYxbMIF7ax4QYI=
=o8D/
-----END PGP SIGNATURE-----
Merge tag 'intel-pinctrl-v6.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel
intel-pinctrl for v6.7-1
* Merge "Drop runtime PM support for Baytrail and Lynxpoint pinctrl" (Raag)
* Small improvements here and there in the Intel pin control drivers (Raag)
* Switch to RAII for locking in the Intel core and Cherry View drivers
* Enable non-ACPI enumeration in the Intel Denverton driver
* Use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS() in a couple of drivers
* Introduce array_size.h and use in in the Intel pin control drivers
The following is an automated git shortlog grouped by driver:
baytrail:
- Replace kernel.h by what is actually being used
- drop runtime PM support
- fix debounce disable case
broxton:
- Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE()
cherryview:
- reduce scope of PIN_CONFIG_BIAS_HIGH_IMPEDANCE case
- Convert to platform remove callback returning void
- Simplify code with cleanup helpers
- Avoid duplicated I/O
- Replace kernel.h by what is actually being used
denverton:
- Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE()
- Enable platform device in the absence of ACPI enumeration
intel:
- fetch community only when we need it
- refine intel_config_set_pull() function
- Replace kernel.h by what is actually being used
- Simplify code with cleanup helpers
lynxpoint:
- Replace kernel.h by what is actually being used
- drop runtime PM support
merrifield:
- Replace kernel.h by what is actually being used
moorefield:
- Replace kernel.h by what is actually being used
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Qualcomm LPASS LPI pin controller driver uses one lock for guarding
Read-Modify-Write code for slew rate registers. However the pin
configuration and muxing registers have exactly the same RMW code but
are not protected.
Pin controller framework does not provide locking here, thus it is
possible to trigger simultaneous change of pin configuration registers
resulting in non-atomic changes.
Protect from concurrent access by re-using the same lock used to cover
the slew rate register. Using the same lock instead of adding second
one will make more sense, once we add support for newer Qualcomm SoC,
where slew rate is configured in the same register as pin
configuration/muxing.
Fixes: 6e261d1090 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver")
Cc: stable@vger.kernel.org
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20231013145705.219954-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- Add pin groups for the Local Bus State Controller (LBSC) on R-Car
M1A,
- Add support for the RZ/G3S (R9A08G045) SoC,
- Miscellaneous fixes and improvements.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCZSk0XwAKCRCKwlD9ZEnx
cCykAP9rDQKb83aBYHLBAmlyRKT1+e8Lm1r4QC7KeiC0v8WHQwEAyLILM38KFwyG
vGaiXlp0MfGmA82a0orjdRBiUdyHqAE=
=QFrw
-----END PGP SIGNATURE-----
Merge tag 'renesas-pinctrl-for-v6.7-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel
pinctrl: renesas: Updates for v6.7 (take two)
- Add pin groups for the Local Bus State Controller (LBSC) on R-Car
M1A,
- Add support for the RZ/G3S (R9A08G045) SoC,
- Miscellaneous fixes and improvements.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231009083856.222030-20-u.kleine-koenig@pengutronix.de
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add basic support for RZ/G3S to be able to boot from SD card, have a
running console port, and use GPIOs. RZ/G3S has 82 general-purpose IO
ports. Support for the remaining pin functions (e.g. Ethernet, XSPI)
will be added along with controller-specific support.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230929053915.1530607-22-claudiu.beznea@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
RZ/G3S supports different drive strength values for different power
sources and pin groups (A, B, C). On each group there could be up to 4
drive strength values per power source. Available power sources are
1v8, 2v5, 3v3. Drive strength values are more fine tuned than what was
previously available on the driver thus the necessity of having
micro-amp support. As drive strength and power source values are linked
together the hardware setup for these was moved at the end of
rzg2l_pinctrl_pinconf_set() to ensure proper validation of the new
values.
The drive strength values are expected to be initialized though the
SoC-specific hardware configuration data structure.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230929053915.1530607-19-claudiu.beznea@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Move drive strength and output impedance values to the SoC-specific
configuration data structure (struct rzg2l_hwcfg). This allows
extending the drive strength support for RZ/G3S. Along with this the DS
values were converted to uA for simple integration with RZ/G3S support.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230929053915.1530607-18-claudiu.beznea@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
On RZ/G3S PFC register allow setting 8 functions for individual ports
(function1 to function8). For function1 the register need to be
configured with 0, for function8 the register need to be configured with
7. We cannot use zero based addressing when requesting functions from
different code places as the documentation
(RZG3S_pinfunction_List_r1.0.xlsx) states explicitly that function0 is
GPIO.
Add a new member to struct rzg2l_hwcfg that will keep the offset that
needs to be substracted before applying a value to a PFC register.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230929053915.1530607-17-claudiu.beznea@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
SD, PWPR power registers have different offsets b/w RZ/G2L and RZ/G3S.
Add a per SoC configuration data structure that is initialized with the
proper register offsets for individual SoCs. The rzg2l_hwcfg structure
will be extended further in later commits.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230929053915.1530607-16-claudiu.beznea@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
To get the address that needs to be read/written for specific port
functionalities, the P(), PM(), PMC(), PFC(), PIN(), IOLH() IEN(),
ISEL() macros are used. Some of these macros receive as argument the
hardware port identifier, some the hardware port offset address (e.g.
ISEL() received port identifier, IOLH() received port offset address).
This makes it hard to extend the current driver for SoCs where port
identifiers are not contiguous in the memory map of the pin controller.
This is the case for the RZ/G3S pin controller where ports are mapped as
follows:
port offset port identifier
----------- ---------------
0x20 P0
0x21 P5
0x22 P6
0x23 P11
0x24 P12
0x25 P13
0x26 P14
0x27 P15
0x28 P16
0x29 P17
0x2a P18
0x30 P1
0x31 P2
0x32 P3
0x33 P4
0x34 P7
0x35 P8
0x36 P8
0x37 P10
To make this achievable, change all the above macros used to get the
address of a port register for a specific port functionality based on
the port hardware address. Summarized, all the above macros will get as
argument the port offset address listed in the above table.
With this RZG2L_SINGLE_PIN_GET_PORT_OFFSET(),
RZG2L_PIN_ID_TO_PORT_OFFSET() and RZG2L_GPIO_PORT_GET_INDEX() were
replaced by RZG2L_PIN_CFG_TO_PORT_OFFSET(); RZG2L_SINGLE_PIN_GET_CFGS()
and RZG2L_GPIO_PORT_GET_CFGS() were replaced by RZG2L_PIN_CFG_TO_CAPS().
Also rzg2l_pinctrl_set_pfc_mode() does not need the port argument
anymore. Also rzg2l_gpio_direction_input() and
rzg2l_gpio_direction_output() do not need to translate port and bit
locally as this can be done by rzg2l_gpio_set_direction().
To use the same naming for port, bit/pin, and register offset, replace
the port_offset variable names in different places by variables named
off. There is no longer a need to initialize cfg and bit in different
code places.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20230929053915.1530607-15-claudiu.beznea@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Validate the GPIO pin request in the rzg2l_gpio_request() callback using
the rzg2l_validate_gpio_pin() function. This stops any accidental usage
of GPIO pins which are not supported by the SoC.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/r/20230925154548.27048-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Enable pin muxing (eg. programmable function), so that the RZ/N1 GPIO
pins will be configured as specified by the pinmux in the DTS.
This used to be enabled implicitly via CONFIG_GENERIC_PINMUX_FUNCTIONS,
however that was removed, since the RZ/N1 driver does not call any of
the generic pinmux functions.
Fixes: 1308fb4e4e ("pinctrl: rzn1: Do not select GENERIC_PIN{CTRL_GROUPS,MUX_FUNCTIONS}")
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20231004200008.1306798-1-ralph.siemsen@linaro.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We check community features only in case PIN_CONFIG_BIAS_PULL_DOWN while
setting/getting pad termination. No need to fetch the community otherwise.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We have a couple of pinconfig cases inside the braces which are meant for
PIN_CONFIG_BIAS_HIGH_IMPEDANCE case. Although it is valid C, it makes the
code less readable and prone to misinterpretation. Limit the braces to
PIN_CONFIG_BIAS_HIGH_IMPEDANCE case to avoid this.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
To convert the sprd-sc9860 driver, make sprd_pinctrl_remove()
return void (instead of zero) and use .remove_new as callback.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009162510.335208-4-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
To convert all those qcom pinctrl drivers, make msm_pinctrl_remove()
return void (instead of zero) and use .remove_new in all drivers.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009162510.335208-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
To convert all those qcom pinctrl drivers, make msm_pinctrl_remove()
return void (instead of zero) and use .remove_new in all drivers.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009162510.335208-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-21-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-19-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-18-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-17-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-16-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-15-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-14-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-13-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20231009083856.222030-12-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-11-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Link: https://lore.kernel.org/r/20231009083856.222030-10-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-9-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-8-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20231009083856.222030-5-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ti_iodelay_remove() is only called after ti_iodelay_probe() completed
successfully. In this case platform_set_drvdata() was called with a
non-NULL argument and so platform_get_drvdata() won't return NULL.
Simplify by removing the if block with the always false condition.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-4-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pcs_remove() is only called after pcs_probe() completed successfully. In
this case platform_set_drvdata() was called with a non-NULL argument and
so platform_get_drvdata() won't return NULL.
Simplify by removing the if block with the always false condition.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The driver core has no handling for errors returned by the .remove()
callback. The only action on error is a dev_warn() with generic error
message that the returned value is returned.
Replace it by a more specific and useful message. Then returning zero is
the right thing to do, the only effect is to suppress the core's
warning.
This prepares the driver for the conversion to .remove_new().
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some platforms unfortunately have their SPI mode selection bits
strapped incorrectly (such as being configured for passthrough mode
when master mode is in fact the only useful configuration for it) and
thus require correction in software. Add the SPI mode bits to the
GPIO passthrough bits as the exceptions to the read-only rule for the
hardware strap register so that the pinctrl subsystem can be used for
such corrections.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Link: https://lore.kernel.org/r/20231005030849.11352-2-zev@bewilderbeest.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The 'fsl,mxs-gpio' property is not documented in gpio-mxs.yaml, but
the imx23 and imx28 dtsi describe the gpios as:
compatible = "fsl,imx28-gpio", "fsl,mxs-gpio";
This gives schema warnings like:
imx28-cfa10037.dtb: pinctrl@80018000: gpio@0:compatible: ['fsl,imx28-gpio', 'fsl,mxs-gpio'] is too long
from schema $id: http://devicetree.org/schemas/gpio/gpio-mxs.yaml#
"fsl,mxs-gpio" is only used inside pinctrl-mxs, but can be removed if
the compatible check is done against fsl,imx23-gpio and fsl,imx28-gpio.
Introduce is_mxs_gpio() and remove the need for "fsl,mxs-gpio".
Tested on a imx28-evk.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20230928134321.438547-1-festevam@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add struct mcp23s08_info and simplify probe()/mcp23s08_spi_regmap_init() by
replacing match data 'type' with 'struct mcp23s08_info'.
While at it, replace 'dev_err()'->'dev_err_probe()' and drop printing
'type' in error path for i2c_get_match_data().
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231001150113.7752-4-biju.das.jz@bp.renesas.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Simpilfy probe() by replacing device_get_match_data() and ID lookup for
retrieving match data by spi_get_device_match_data().
While at it, replace data type of variable type from 'int'->'unsigned int'
and declare variables following a reverse christmas tree order.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231001150113.7752-3-biju.das.jz@bp.renesas.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The driver has OF match table, still it uses ID lookup table for
retrieving match data. Currently the driver is working on the
assumption that a I2C device registered via OF will always match a
legacy I2C device ID. The correct approach is to have an OF device ID
table using of_device_match_data() if the devices are registered via OF.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231001150113.7752-2-biju.das.jz@bp.renesas.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Past versions of this driver have manually calculated base values for
both the pinctrl numberspace and the global GPIO numberspace, giving
both the same values. This was necessary for the global GPIO
numberspace, since its values need to be unique system-wide. However, it
was not necessary for the pinctrl numberspace, since its values only
need to be unique for a single instance of the pinctrl device. It was
just convenient to use the same values for both spaces.
Right now those calculations are only used for the pinctrl numberspace,
since GPIO numberspace bases are selected by the GPIO subsystem.
Therefore, those calculations are unnecessary.
Signed-off-by: Mateusz Majewski <m.majewski2@samsung.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20231006125557.212681-5-m.majewski2@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Selecting it statically is deprecated and results in a warning while
booting the system:
gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation.
Signed-off-by: Mateusz Majewski <m.majewski2@samsung.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20231006125557.212681-4-m.majewski2@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
This is preferable since we can read the base in the global GPIO
numberspace from the chip instead of needing to select it ourselves.
Past versions could not do this, since they needed to add all the ranges
before enabling the pinctrl subsystem, which was done before registering
the GPIO chip. However, right now we enable the pinctrl subsystem after
registering the chip and so this became possible.
Signed-off-by: Mateusz Majewski <m.majewski2@samsung.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20231006125557.212681-3-m.majewski2@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
dev_pinctrl_register function immediately enables the pinctrl subsystem,
which is unpreferable in general, since drivers might be unable to
handle calls immediately. Hence devm_pinctrl_register_and_init, which
does not call pinctrl_enable, is preferred.
In case of our driver using the old function does not seem to be
problematic for now, but will become an issue when we postpone parts of
pinctrl initialization in a future commit, and it is a good idea to move
off a deprecated-ish function anyway.
Signed-off-by: Mateusz Majewski <m.majewski2@samsung.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20231006125557.212681-2-m.majewski2@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for
array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct
exynos_muxed_weint_data. Additionally, since the element count member
must be set before accessing the annotated flexible array member, move
its initialization earlier.
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Cc: linux-hardening@vger.kernel.org
Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci [1]
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20231006201707.work.405-kees@kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
These pin definitions are helpful to have when working with the
driver in the future, so they are in a sense a bit like
documentation. They could be commented out as well, but why.
This should fix these build warnings:
drivers/pinctrl/realtek/pinctrl-rtd1315e.c:231:35: warning:
'rtd1315e_boot_sel_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1315e.c:231:35: warning:
'rtd1315e_reset_n_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1315e.c:231:35: warning:
'rtd1315e_scan_switch_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1315e.c:231:35: warning:
'rtd1315e_testmode_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1315e.c:231:35: warning:
'rtd1315e_wd_rset_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1319d.c:237:35: warning:
'rtd1319d_boot_sel_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1319d.c:237:35: warning:
'rtd1319d_reset_n_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1319d.c:237:35: warning:
'rtd1319d_scan_switch_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1319d.c:237:35: warning:
'rtd1319d_testmode_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1319d.c:237:35: warning:
'rtd1319d_wd_rset_pins' defined but not used [-Wunused-const-variable=]
Cc: Tzuyi Chang <tychang@realtek.com>
Link: https://lore.kernel.org/oe-kbuild-all/202309270313.mBEc9o1A-lkp@intel.com/
Link: https://lore.kernel.org/oe-kbuild-all/202309270448.7Aen3Sgx-lkp@intel.com/
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231006-fix-realtek-warnings-v1-1-09af253312ba@linaro.org
There are several issues in the probe function:
1) of_iomap() return NULL on error but the code checks for error
pointers.
2) pinctrl_register() is the reverse. It returns error pointers
but the code checks for NULL.
3) The error paths need to call iounmap(data->base) before returning
to avoid a resource leak.
Fixes: e99ce78030 ("pinctrl: realtek: Add common pinctrl driver for Realtek DHC RTD SoCs")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/590b337a-13ce-4391-a09d-d2b06fbc912d@moroto.mountain
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use macros defined in linux/cleanup.h to automate resource lifetime
control in the driver.
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
In some cases we already read the value from the register followed
by a reading of it again for other purposes, but the both reads
are under the lock and bits we are insterested in are not going
to change (they are not volatile from HW perspective). Hence, no
need to read the same register twice.
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
As Krzysztof pointed out the better is to use MODULE_DEVICE_TABLE()
as it will be consistent with the content of the real ID table of
the platform devices.
Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
As Krzysztof pointed out the better is to use MODULE_DEVICE_TABLE()
as it will be consistent with the content of the real ID table of
the platform devices.
Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The kernel.h is a mess of unrelated things and we only used it
as a proxy to array_size.h, hence switch from former to the latter.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The kernel.h is a mess of unrelated things and we only used it
as a proxy to array_size.h, hence switch from former to the latter.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The kernel.h is a mess of unrelated things and we only used it
as a proxy to array_size.h, hence switch from former to the latter.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The kernel.h is a mess of unrelated things and we only used it
as a proxy to array_size.h, hence switch from former to the latter.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The kernel.h is a mess of unrelated things and we only used it
as a proxy to array_size.h, hence switch from former to the latter.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Since Lynxpoint pinctrl device is not attached to acpi_lpss_pm_domain,
runtime PM serves no purpose here. Drop it and switch to pm_sleep_ptr()
as now we only have resume handle in place.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20231003114036.27674-3-raag.jadav@intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Since Baytrail pinctrl device is not attached to acpi_lpss_pm_domain,
runtime PM serves no purpose here. Drop it and switch to pm_sleep_ptr()
as now we only have suspend and resume handles in place.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20231003114036.27674-2-raag.jadav@intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Improve intel_config_set_pull() implementation in Intel pinctrl driver by:
- Reducing scope of spinlock by moving unneeded operations out of it.
- Utilizing temporary variables for common operations.
- Limiting IO operations to positive cases.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The kernel.h is a mess of unrelated things and we only used it
as a proxy to array_size.h, hence switch from former to the latter.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The kernel.h is a mess of unrelated things and we only used it
as a proxy to array_size.h, hence switch from former to the latter.
While at it, group and sort the headers where it makes sense.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
This is to cater the need for non-ACPI system whereby
a platform device has to be created in order to bind
with the Denverton pinctrl platform driver.
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct uniphier_pinctrl_reg_region.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: linux-gpio@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175006.work.421-kees@kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
These errors are not quite clear without also logging they device tree node
being parsed, especially when the pinmux node has lots of subnodes. Adding
the node name helps a lot in finding the node that triggers the error.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20230926103938.334055-1-luca.ceresoli@bootlin.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add pin <-> wakeirq mappings to allow for waking up the AP from sleep
through MPM-connected pins.
Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com>
Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
Link: https://lore.kernel.org/r/20230923131432.21721-3-matti.lehtimaki@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add pin <-> wakeirq mappings to allow for waking up the AP from sleep
through MPM-connected pins.
Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com>
Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
Link: https://lore.kernel.org/r/20230923131432.21721-2-matti.lehtimaki@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
On GPIO22 and GPIO23 there is another I2C bus. Add the function for it.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20230922-msm8226-i2c6-v2-2-3fb55c47a084@z3ntu.xyz
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
mtk_pinmux_set_mux() doesn't check the result of mtk_hw_set_value()
despite it may return a negative error code. Propagate error code
to caller functions.
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Signed-off-by: Karina Yankevich <k.yankevich@omp.ru>
Link: https://lore.kernel.org/r/20230922135926.3653428-2-k.yankevich@omp.ru
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
mtk_pmx_set_mux() doesn't check the result of mtk_hw_set_value()
despite it may return negative error code. Propagate error code
to caller functions.
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Signed-off-by: Karina Yankevich <k.yankevich@omp.ru>
Link: https://lore.kernel.org/r/20230922135926.3653428-1-k.yankevich@omp.ru
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use macros defined in linux/cleanup.h to automate resource lifetime
control in the driver.
While at it, unify the variables and approach in intel_gpio_irq_*().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
We usually do reverse order of enable() for disable(). Currently, the
ordering of irq_chip_disable_parent() is not correct in
rzg2l_gpio_irq_disable(). Fix the incorrect order.
Fixes: db2e5f21a4 ("pinctrl: renesas: pinctrl-rzg2l: Add IRQ domain to handle GPIO interrupt")
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230918123355.262115-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add a new pinctrl driver for Amlogic T7 SoCs which share
the same register layout as the previous Amlogic S4.
Signed-off-by: Huqiang Qin <huqiang.qin@amlogic.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20230922094342.637251-3-huqiang.qin@amlogic.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
