Pull gpio updates from Bartosz Golaszewski
"This was a quiet release cycle for the GPIO tree and so this
pull-request is relatively small.
We have one new driver, some minor improvements to the GPIO core code
and across several drivers, some DT and documentation updates but in
general nothing stands out or is controversial. All changes have spent
time in next with no reported issues (or ones that were quickly
fixed).
GPIO core:
- remove more unused legacy interfaces (after converting the last
remaining users to better alternatives)
- update kerneldocs
- improve error handling and log messages in GPIO ACPI code
- remove dead code (always true checks) from GPIOLIB
New drivers:
- add a driver for Intel Granite Rapids-D vGPIO
Driver improvements:
- use -ENOTSUPP consistently in gpio-regmap and gpio-pcie-idio-24
- provide an ID table for gpio-cros-ec to avoid a driver name
fallback check
- add support for gpio-ranges for GPIO drivers supporting multiple
GPIO banks
- switch to using dynamic GPIO base in gpio-brcmstb
- fix irq handling in gpio-npcm-sgpio
- switch to memory mapped IO accessors in gpio-sch
DT bindings:
- add support for gpio-ranges to gpio-brcmstb
- add support for a new model and the gpio-line-names property to
gpio-mpfs
Documentation:
- replace leading tabs with spaces in code blocks
- fix typos"
* tag 'gpio-updates-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (30 commits)
gpio: nuvoton: Fix sgpio irq handle error
gpiolib: Discourage to use formatting strings in line names
gpio: brcmstb: add support for gpio-ranges
gpio: of: support gpio-ranges for multiple gpiochip devices
dt-bindings: gpio: brcmstb: add gpio-ranges
gpio: Add Intel Granite Rapids-D vGPIO driver
gpio: brcmstb: Use dynamic GPIO base numbers
gpiolib: acpi: Set label for IRQ only lines
gpiolib: acpi: Add fwnode name to the GPIO interrupt label
gpiolib: Get rid of never false gpio_is_valid() calls
gpiolib: acpi: Pass con_id instead of property into acpi_dev_gpio_irq_get_by()
gpiolib: acpi: Move acpi_can_fallback_to_crs() out of __acpi_find_gpio()
gpiolib: acpi: Simplify error handling in __acpi_find_gpio()
gpiolib: acpi: Extract __acpi_find_gpio() helper
gpio: sch: Utilise temporary variable for struct device
gpio: sch: Switch to memory mapped IO accessors
gpio: regmap: Use -ENOTSUPP consistently
gpio: pcie-idio-24: Use -ENOTSUPP consistently
Documentation: gpio: Replace leading TABs by spaces in code blocks
gpiolib: acpi: Check for errors first in acpi_find_gpio()
...
Pull SoC driver updates from Arnd Bergmann:
"As usual, these are updates for drivers that are specific to certain
SoCs or firmware running on them.
Notable updates include
- The new STMicroelectronics STM32 "firewall" bus driver that is used
to provide a barrier between different parts of an SoC
- Lots of updates for the Qualcomm platform drivers, in particular
SCM, which gets a rewrite of its initialization code
- Firmware driver updates for Arm FF-A notification interrupts and
indirect messaging, SCMI firmware support for pin control and
vendor specific interfaces, and TEE firmware interface changes
across multiple TEE drivers
- A larger cleanup of the Mediatek CMDQ driver and some related bits
- Kconfig changes for riscv drivers to prepare for adding Kanaan k230
support
- Multiple minor updates for the TI sysc bus driver, memory
controllers, hisilicon hccs and more"
* tag 'soc-drivers-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (103 commits)
firmware: qcom: uefisecapp: Allow on sc8180x Primus and Flex 5G
soc: qcom: pmic_glink: Make client-lock non-sleeping
dt-bindings: soc: qcom,wcnss: fix bluetooth address example
soc/tegra: pmc: Add EQOS wake event for Tegra194 and Tegra234
bus: stm32_firewall: fix off by one in stm32_firewall_get_firewall()
bus: etzpc: introduce ETZPC firewall controller driver
firmware: arm_ffa: Avoid queuing work when running on the worker queue
bus: ti-sysc: Drop legacy idle quirk handling
bus: ti-sysc: Drop legacy quirk handling for smartreflex
bus: ti-sysc: Drop legacy quirk handling for uarts
bus: ti-sysc: Add a description and copyrights
bus: ti-sysc: Move check for no-reset-on-init
soc: hisilicon: kunpeng_hccs: replace MAILBOX dependency with PCC
soc: hisilicon: kunpeng_hccs: Add the check for obtaining complete port attribute
firmware: arm_ffa: Fix memory corruption in ffa_msg_send2()
bus: rifsc: introduce RIFSC firewall controller driver
of: property: fw_devlink: Add support for "access-controller"
soc: mediatek: mtk-socinfo: Correct the marketing name for MT8188GV
soc: mediatek: mtk-socinfo: Add entry for MT8395AV/ZA Genio 1200
soc: mediatek: mtk-mutex: Add support for MT8188 VPPSYS
...
RISC-V SoC Kconfig Updates for v6.10
A few different bits of SoC-related Kconfig work. The first part of
this is shared with the DT updates - the modification of all SOC_CANAAN
users to SOC_CANAAN_K210 to split the existing m-mode nommu k210 away
from the k230 that is able to be used in a "common" kernel.
The other thing here is the removal of most of the SOC_VENDOR options,
with their ARCH_VENDOR equivalents that've been waiting in the wings for
1 year+ now made visible. Due a lapse on my part when originally adding
the ARCH_VENDOR stuff, the Microchip transition isn't complete - the
_POLARFIRE was a mistake to keep as there's gonna be non-PolarFire
RISC-V stuff from Microchip soonTM.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
* tag 'riscv-config-for-v6.10' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
riscv: config: enable ARCH_CANAAN in defconfig
RISC-V: drop SOC_VIRT for ARCH_VIRT
RISC-V: drop SOC_SIFIVE for ARCH_SIFIVE
RISC-V: drop SOC_MICROCHIP_POLARFIRE for ARCH_MICROCHIP
RISC-V: Drop unused SOC_CANAAN
reset: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
pinctrl: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
clk: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
soc: canaan: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210
riscv: Kconfig.socs: Split ARCH_CANAAN and SOC_CANAAN_K210
Link: https://lore.kernel.org/r/20240503-mardi-underling-3d81a9f97329@spud
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
intel-gpio for v6.10-1
* New driver for vGPIO controller on Intel Granite Rapids-D
* Update ACPI GPIO library to unify the IRQ code path
* Better GPIO IRQ line labeling for ACPI
* Switched Intel SCH driver to use "mapped" I/O accessors
The following is an automated git shortlog grouped by driver:
Add Intel Granite Rapids-D vGPIO driver:
- Add Intel Granite Rapids-D vGPIO driver
crystalcove:
- Use -ENOTSUPP consistently
gpiolib:
- acpi: Set label for IRQ only lines
- acpi: Add fwnode name to the GPIO interrupt label
- acpi: Pass con_id instead of property into acpi_dev_gpio_irq_get_by()
- acpi: Move acpi_can_fallback_to_crs() out of __acpi_find_gpio()
- acpi: Simplify error handling in __acpi_find_gpio()
- acpi: Extract __acpi_find_gpio() helper
- acpi: Check for errors first in acpi_find_gpio()
- acpi: Remove never true check in acpi_get_gpiod_by_index()
sch:
- Utilise temporary variable for struct device
- Switch to memory mapped IO accessors
wcove:
- Use -ENOTSUPP consistently
Pull pin control fixes from Linus Walleij:
- Fix a double-free in the pinctrl_enable() errorpath
- Fix a refcount leak in pinctrl_dt_to_map()
- Fix selecting the GPIO pin control state and the UART3 pin config
group in the Intel Baytrail driver
- Fix readback of schmitt trigger status in the Mediatek Paris driver,
along with some semantic pin config issues in this driver
- Fix a pin suffix typo in the Meson A1 driver
- Fix an erroneous register offset in he Aspeed G6 driver
- Fix an inconsistent lock state and the interrupt type on resume in
the Renesas RZG2L driver
- Fix some minor confusion in the Renesas DT bindings
* tag 'pinctrl-v6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: renesas: rzg2l: Configure the interrupt type on resume
pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()
pinctrl: baytrail: Add pinconf group for uart3
pinctrl: baytrail: Fix selecting gpio pinctrl state
pinctrl: mediatek: paris: Rework support for PIN_CONFIG_{INPUT,OUTPUT}_ENABLE
pinctrl: mediatek: paris: Fix PIN_CONFIG_INPUT_SCHMITT_ENABLE readback
pinctrl: core: delete incorrect free in pinctrl_enable()
pinctrl/meson: fix typo in PDM's pin name
pinctrl: pinctrl-aspeed-g6: Fix register offset for pinconf of GPIOR-T
pinctrl: renesas: rzg2l: Execute atomically the interrupt configuration
dt-bindings: pinctrl: renesas,rzg2l-pinctrl: Allow 'input' and 'output-enable' properties
Arm SCMI updates for v6.10
1. Basic support for SCMI v3.2 pincontrol protocol
SCMI v3.2 introduces pincontrol protocol which is intended for
controlling pins and their configuration. The pin control protocol
provides commands to:
- List the pins, groups of pins, available functions, and their
association with each other.
- Set the parameter configuration and multiplexing of the pins or
groups of pins
- Optionally request exclusive access to a pin or group of pins.
- Optionally configure the permissions of an agent to access a pin
or group of pins.
These changes adds basic support for the same in the SCMI core layer
and an implementation of the generic scmi-pinctrl driver with associated
DT bindings.
2. Framework support for multiple vendors custom protocols
With the fixed space for vendor protocols, the possibility of having
multiple vendors implementing distinct SCMI vendor protocols with
the same overlapping protocol number is very high and with the need
to support them all in a single kernel image or a module is also high.
In order to implement the same we assume:
- vendor protocols has to be tagged at build time with a vendor_id
- vendor protocols could also optionally be tagged at build time with
sub_vendor_id and implementation version
At the initialisation all the built vendor protocols are registered
with the SCMI core using a key derived from the above tags
3. Logging and tracing improvements
This includes using dev_err_probe() to bail out from probe, adding
message dump traces for bad and unexpected replies and widening of
the tag buffer in trace_scmi_dump_msg to allow diverse tag names
4. Miscellaneous updates or improvements
This includes adding the accessor function get_max_msg_size() used
in pinctl protocol, updation of dt-bindings examples for protocol@13
to promote new bindings and simplification of scmi_devm_notifier_unregister
* tag 'scmi-updates-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
pinctrl: Implementation of the generic scmi-pinctrl driver
firmware: arm_scmi: Add basic support for SCMI v3.2 pincontrol protocol
dt-bindings: firmware: Support SCMI pinctrl protocol
firmware: arm_scmi: Introduce get_max_msg_size() helper/accessor
firmware: arm_scmi: Add support for multiple vendors custom protocols
dt-bindings: firmware: arm,scmi: Update examples for protocol@13
firmware: arm_scmi: Avoid non-constant printk format strings
firmware: arm_scmi: Use dev_err_probe to bail out
firmware: arm_scmi: Simplify scmi_devm_notifier_unregister
firmware: arm_scmi: Add message dump traces for bad and unexpected replies
firmware: arm_scmi: Add helper to trace bad messages
include: trace: Widen the tag buffer in trace_scmi_dump_msg
firmware: arm_scmi: Log the perf domain names in the error paths
Link: https://lore.kernel.org/r/20240426105031.1526987-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
intel-pinctrl for v6.9-1
* Correct GPIO selection and add UART3 pins for Intel Bay Trail
The following is an automated git shortlog grouped by driver:
baytrail:
- Add pinconf group for uart3
- Fix selecting gpio pinctrl state
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit dce0919c83 ("irqchip/renesas-rzg2l: Do not set TIEN and TINT
source at the same time") removed the setup of TINT from
rzg2l_irqc_irq_enable(). To address the spurious interrupt issue the
setup of TINT has been moved in rzg2l_tint_set_edge() through
rzg2l_disable_tint_and_set_tint_source(). With this, the interrupts are
not properly re-configured after a suspend-to-RAM cycle. To address
this issue and avoid spurious interrupts while resumming set the
interrupt type before enabling it.
Fixes: dce0919c83 ("irqchip/renesas-rzg2l: Do not set TIEN and TINT source at the same time")
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/20240419063822.3467424-1-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
pinctrl: renesas: Fixes for v6.9
- Fix a dtbs_check warning on RZ/G3S,
- Fix a lockdep warning on RZ/G2L.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
GPIO_S0_SC57 / GPIO_S0_SC61 can be muxed to PCU_UART_TXD / PCU_UART_RXD,
add a pinconf group for this.
On Bay Trail board schematics using these pins as UART these are
called UART3_TXD / UART3_RXD, name the pinconf group "uart3_grp"
to be consistent with the schematics.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
For all the "score" pin-groups all the intel_pingroup-s to select
the non GPIO function are re-used for byt_score_gpio_groups[].
But this is incorrect since a pin-group includes the mode setting,
which for the non GPIO functions generally is 1, where as to select
the GPIO function mode must be set to 0.
So the GPIO function needs separate intel_pingroup-s with their own mode
value of 0.
Add a new PIN_GROUP_GPIO macro which adds a foo_gpio entry to each
pin-group defined this way and update byt_score_gpio_groups[] to point
to the new foo_gpio entries.
The "sus" usb_oc_grp usb_ulpi_grp and pcu_spi_grp pin-groups are special
because these have a non 0 mode value to select the GPIO functions and
these already have matching foo_gpio pin-groups, leave these are unchanged.
The pmu_clk "sus" groups added in commit 2f46d7f7e9 ("pinctrl: baytrail:
Add pinconf group + function for the pmu_clk") do need to use the new
PIN_GROUP_GPIO macro.
Fixes: 2f46d7f7e9 ("pinctrl: baytrail: Add pinconf group + function for the pmu_clk")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
There is a misinterpretation of some of the PIN_CONFIG_* options in this
driver library. PIN_CONFIG_OUTPUT_ENABLE should refer to a buffer or
switch in the output direction of the electrical path. The MediaTek
hardware does not have such a thing. The driver incorrectly maps this
option to the GPIO function's direction.
Likewise, PIN_CONFIG_INPUT_ENABLE should refer to a buffer or switch in
the input direction. The hardware does have such a mechanism, and is
mapped to the IES bit. The driver however sets the direction in addition
to the IES bit, which is incorrect. On readback, the IES bit isn't even
considered.
Ironically, the driver does not support readback for PIN_CONFIG_OUTPUT,
while its readback of PIN_CONFIG_{INPUT,OUTPUT}_ENABLE is what it should
be doing for PIN_CONFIG_OUTPUT.
Rework support for these three options, so that PIN_CONFIG_OUTPUT_ENABLE
is completely removed, PIN_CONFIG_INPUT_ENABLE is only linked to the IES
bit, and PIN_CONFIG_OUTPUT is linked to the GPIO function's direction
and output level.
Fixes: 805250982b ("pinctrl: mediatek: add pinctrl-paris that implements the vendor dt-bindings")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Message-ID: <20240327091336.3434141-3-wenst@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In the generic pin config library, readback of some options are handled
differently compared to the setting of those options: the argument value
is used to convey enable/disable of an option in the set path, but
success or -EINVAL is used to convey if an option is enabled or disabled
in the debugfs readback path.
PIN_CONFIG_INPUT_SCHMITT_ENABLE is one such option. Fix the readback of
the option in the mediatek-paris library, so that the debugfs dump is
not showing "input schmitt enabled" for pins that don't have it enabled.
Fixes: 1bea6afbc8 ("pinctrl: mediatek: Refine mtk_pinconf_get()")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Message-ID: <20240327091336.3434141-2-wenst@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull Kbuild fixes from Masahiro Yamada:
- Deduplicate Kconfig entries for CONFIG_CXL_PMU
- Fix unselectable choice entry in MIPS Kconfig, and forbid this
structure
- Remove unused include/asm-generic/export.h
- Fix a NULL pointer dereference bug in modpost
- Enable -Woverride-init warning consistently with W=1
- Drop KCSAN flags from *.mod.c files
* tag 'kbuild-fixes-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kconfig: Fix typo HEIGTH to HEIGHT
Documentation/llvm: Note s390 LLVM=1 support with LLVM 18.1.0 and newer
kbuild: Disable KCSAN for autogenerated *.mod.c intermediaries
kbuild: make -Woverride-init warnings more consistent
modpost: do not make find_tosym() return NULL
export.h: remove include/asm-generic/export.h
kconfig: do not reparent the menu inside a choice block
MIPS: move unselectable FIT_IMAGE_FDT_EPM5 out of the "System type" choice
cxl: remove CONFIG_CXL_PMU entry in drivers/cxl/Kconfig
The -Woverride-init warn about code that may be intentional or not,
but the inintentional ones tend to be real bugs, so there is a bit of
disagreement on whether this warning option should be enabled by default
and we have multiple settings in scripts/Makefile.extrawarn as well as
individual subsystems.
Older versions of clang only supported -Wno-initializer-overrides with
the same meaning as gcc's -Woverride-init, though all supported versions
now work with both. Because of this difference, an earlier cleanup of
mine accidentally turned the clang warning off for W=1 builds and only
left it on for W=2, while it's still enabled for gcc with W=1.
There is also one driver that only turns the warning off for newer
versions of gcc but not other compilers, and some but not all the
Makefiles still use a cc-disable-warning conditional that is no
longer needed with supported compilers here.
Address all of the above by removing the special cases for clang
and always turning the warning off unconditionally where it got
in the way, using the syntax that is supported by both compilers.
Fixes: 2cd3271b7a ("kbuild: avoid duplicate warning options")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
so freeing it in pinctrl_enable() will lead to a double free.
The devm_pinctrl_dev_release() function frees the pindescs and destroys
the mutex as well.
Fixes: 6118714275 ("pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Message-ID: <578fbe56-44e9-487c-ae95-29b695650f7c@moroto.mountain>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Lockdep detects a possible deadlock as listed below. This is because it
detects the IA55 interrupt controller .irq_eoi() API is called from
interrupt context while configuration-specific API (e.g., .irq_enable())
could be called from process context on resume path (by calling
rzg2l_gpio_irq_restore()). To avoid this, protect the call of
rzg2l_gpio_irq_enable() with spin_lock_irqsave()/spin_unlock_irqrestore().
With this the same approach that is available in __setup_irq() is mimicked
to pinctrl IRQ resume function.
Below is the lockdep report:
WARNING: inconsistent lock state
6.8.0-rc5-next-20240219-arm64-renesas-00030-gb17a289abf1f #90 Not tainted
--------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
str_rwdt_t_001./159 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff00000b001d70 (&rzg2l_irqc_data->lock){?...}-{2:2}, at: rzg2l_irqc_irq_enable+0x60/0xa4
{IN-HARDIRQ-W} state was registered at:
lock_acquire+0x1e0/0x310
_raw_spin_lock+0x44/0x58
rzg2l_irqc_eoi+0x2c/0x130
irq_chip_eoi_parent+0x18/0x20
rzg2l_gpio_irqc_eoi+0xc/0x14
handle_fasteoi_irq+0x134/0x230
generic_handle_domain_irq+0x28/0x3c
gic_handle_irq+0x4c/0xbc
call_on_irq_stack+0x24/0x34
do_interrupt_handler+0x78/0x7c
el1_interrupt+0x30/0x5c
el1h_64_irq_handler+0x14/0x1c
el1h_64_irq+0x64/0x68
_raw_spin_unlock_irqrestore+0x34/0x70
__setup_irq+0x4d4/0x6b8
request_threaded_irq+0xe8/0x1a0
request_any_context_irq+0x60/0xb8
devm_request_any_context_irq+0x74/0x104
gpio_keys_probe+0x374/0xb08
platform_probe+0x64/0xcc
really_probe+0x140/0x2ac
__driver_probe_device+0x74/0x124
driver_probe_device+0x3c/0x15c
__driver_attach+0xec/0x1c4
bus_for_each_dev+0x70/0xcc
driver_attach+0x20/0x28
bus_add_driver+0xdc/0x1d0
driver_register+0x5c/0x118
__platform_driver_register+0x24/0x2c
gpio_keys_init+0x18/0x20
do_one_initcall+0x70/0x290
kernel_init_freeable+0x294/0x504
kernel_init+0x20/0x1cc
ret_from_fork+0x10/0x20
irq event stamp: 69071
hardirqs last enabled at (69071): [<ffff800080e0dafc>] _raw_spin_unlock_irqrestore+0x6c/0x70
hardirqs last disabled at (69070): [<ffff800080e0cfec>] _raw_spin_lock_irqsave+0x7c/0x80
softirqs last enabled at (67654): [<ffff800080010614>] __do_softirq+0x494/0x4dc
softirqs last disabled at (67645): [<ffff800080015238>] ____do_softirq+0xc/0x14
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&rzg2l_irqc_data->lock);
<Interrupt>
lock(&rzg2l_irqc_data->lock);
*** DEADLOCK ***
4 locks held by str_rwdt_t_001./159:
#0: ffff00000b10f3f0 (sb_writers#4){.+.+}-{0:0}, at: vfs_write+0x1a4/0x35c
#1: ffff00000e43ba88 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xe8/0x1a8
#2: ffff00000aa21dc8 (kn->active#40){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xf0/0x1a8
#3: ffff80008179d970 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9c/0x278
stack backtrace:
CPU: 0 PID: 159 Comm: str_rwdt_t_001. Not tainted 6.8.0-rc5-next-20240219-arm64-renesas-00030-gb17a289abf1f #90
Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT)
Call trace:
dump_backtrace+0x94/0xe8
show_stack+0x14/0x1c
dump_stack_lvl+0x88/0xc4
dump_stack+0x14/0x1c
print_usage_bug.part.0+0x294/0x348
mark_lock+0x6b0/0x948
__lock_acquire+0x750/0x20b0
lock_acquire+0x1e0/0x310
_raw_spin_lock+0x44/0x58
rzg2l_irqc_irq_enable+0x60/0xa4
irq_chip_enable_parent+0x1c/0x34
rzg2l_gpio_irq_enable+0xc4/0xd8
rzg2l_pinctrl_resume_noirq+0x4cc/0x520
pm_generic_resume_noirq+0x28/0x3c
genpd_finish_resume+0xc0/0xdc
genpd_resume_noirq+0x14/0x1c
dpm_run_callback+0x34/0x90
device_resume_noirq+0xa8/0x268
dpm_noirq_resume_devices+0x13c/0x160
dpm_resume_noirq+0xc/0x1c
suspend_devices_and_enter+0x2c8/0x570
pm_suspend+0x1ac/0x278
state_store+0x88/0x124
kobj_attr_store+0x14/0x24
sysfs_kf_write+0x48/0x6c
kernfs_fop_write_iter+0x118/0x1a8
vfs_write+0x270/0x35c
ksys_write+0x64/0xec
__arm64_sys_write+0x18/0x20
invoke_syscall+0x44/0x108
el0_svc_common.constprop.0+0xb4/0xd4
do_el0_svc+0x18/0x20
el0_svc+0x3c/0xb8
el0t_64_sync_handler+0xb8/0xbc
el0t_64_sync+0x14c/0x150
Fixes: 254203f9a9 ("pinctrl: renesas: rzg2l: Add suspend/resume 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/20240320104230.446400-2-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
There is a problem when a driver requests a shared interrupt line to run a
threaded handler on it without IRQF_ONESHOT set if that flag has been set
already for the IRQ in question by somebody else. Namely, the request
fails which usually leads to a probe failure even though the driver might
have worked just fine with IRQF_ONESHOT, but it does not want to use it by
default. Currently, the only way to handle this is to try to request the
IRQ without IRQF_ONESHOT, but with IRQF_PROBE_SHARED set and if this fails,
try again with IRQF_ONESHOT set. However, this is a bit cumbersome and not
very clean.
When commit 7a36b901a6 ("ACPI: OSL: Use a threaded interrupt handler for
SCI") switched the ACPI subsystem over to using a threaded interrupt
handler for the SCI, it had to use IRQF_ONESHOT for it because that's
required due to the way the SCI handler works (it needs to walk all of the
enabled GPEs before the interrupt line can be unmasked). The SCI interrupt
line is not shared with other users very often due to the SCI handling
overhead, but on sone systems it is shared and when the other user of it
attempts to install a threaded handler, a flags mismatch related to
IRQF_ONESHOT may occur.
As it turned out, that happened to the pinctrl-amd driver and so commit
4451e8e841 ("pinctrl: amd: Add IRQF_ONESHOT to the interrupt request")
attempted to address the issue by adding IRQF_ONESHOT to the interrupt
flags in that driver, but this is now causing an IRQF_ONESHOT-related
mismatch to occur on another system which cannot boot as a result of it.
Clearly, pinctrl-amd can work with IRQF_ONESHOT if need be, but it should
not set that flag by default, so it needs a way to indicate that to the
interrupt subsystem.
To that end, introdcuce a new interrupt flag, IRQF_COND_ONESHOT, which will
only have effect when the IRQ line is shared and IRQF_ONESHOT has been set
for it already, in which case it will be promoted to the latter.
This is sufficient for drivers sharing the interrupt line with the SCI as
it is requested by the ACPI subsystem before any drivers are probed, so
they will always see IRQF_ONESHOT set for the interrupt in question.
Fixes: 4451e8e841 ("pinctrl: amd: Add IRQF_ONESHOT to the interrupt request")
Reported-by: Francisco Ayala Le Brun <francisco@videowindow.eu>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: 6.8+ <stable@vger.kernel.org> # 6.8+
Closes: https://lore.kernel.org/lkml/CAN-StX1HqWqi+YW=t+V52-38Mfp5fAz7YHx4aH-CQjgyNiKx3g@mail.gmail.com/
Link: https://lore.kernel.org/r/12417336.O9o76ZdvQC@kreacher
Pull pin control updates from Linus Walleij:
"No core changes this time around.
New drivers:
- New driver for Renesas R8A779H0 also known as R-Car V4M.
- New driver for the Awinic AW9523/B I2C GPIO expander. I found this
living out-of-tree in OpenWrt as an upstream attempt had stalled on
the finishing line, so I picked it up and finished the job.
Improvements:
- The Nomadik pin control driver was for years re-used out of tree
for the ST STA chips, and now the IP was re-used in a MIPS
automotive SoC called MobilEyeq5, so it has been split in pin
control and GPIO drivers so the latter can be reused by MobilEyeq5.
(Along with a long list of cleanups)
- A lot of overall cleanup and tidying up"
* tag 'pinctrl-v6.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (87 commits)
drivers/gpio/nomadik: move dummy nmk_gpio_dbg_show_one() to header
gpio: nomadik: remove BUG_ON() in nmk_gpio_populate_chip()
dt-bindings: pinctrl: qcom: update compatible name for match with driver
pinctrl: aw9523: Make the driver tristate
pinctrl: nomadik: fix dereference of error pointer
gpio: nomadik: Back out some managed resources
pinctrl: aw9523: Add proper terminator
pinctrl: core: comment that pinctrl_add_gpio_range() is deprecated
pinctrl: pinmux: Suppress error message for -EPROBE_DEFER
pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander
dt-bindings: pinctrl: Add bindings for Awinic AW9523/AW9523B
gpio: nomadik: Finish conversion to use firmware node APIs
gpio: nomadik: fix Kconfig dependencies inbetween pinctrl & GPIO
pinctrl: da9062: Add OF table
dt-bindings: pinctrl: at91: add sam9x7
pinctrl: ocelot: remove redundant assignment to variable ret
gpio: nomadik: grab optional reset control and deassert it at probe
gpio: nomadik: support mobileye,eyeq5-gpio
gpio: nomadik: handle variadic GPIO count
gpio: nomadik: support shared GPIO IRQs
...
Pull pwm updates from Uwe Kleine-König:
"This contains the usual amount of driver and device tree changes.
Additionally there is a big rework of how pwm lowlevel drivers are
registered to prepare adding character device support.
Thanks to Dharma Balasubiramani, Dong Aisheng, Duje Mihanović, Jerome
Brunet, Raag Jadav and Rafał Miłecki for their contributions. And
sorry for those who still need some patience because I didn't manage
to empty my review queue"
* tag 'pwm/for-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: (185 commits)
pwm: imx-tpm: fix probe crash due to access registers without clock
pwm: meson: generalize 4 inputs clock on meson8 pwm type
dt-bindings: pwm: amlogic: Add a new binding for meson8 pwm types
dt-bindings: pwm: amlogic: fix s4 bindings
pwm: dwc: simplify error handling
pwm: dwc: Add 16 channel support for Intel Elkhart Lake
pwm: dwc: drop redundant error check
staging: greybus: pwm: Make use of devm_pwmchip_alloc() function
staging: greybus: pwm: Rework how the number of PWM lines is determined
staging: greybus: pwm: Drop unused gb_connection_set_data()
staging: greybus: pwm: Rely on pwm framework to pass a valid hwpwm
staging: greybus: pwm: Make use of pwmchip_parent() accessor
staging: greybus: pwm: Change prototype of helpers to prepare further changes
leds: qcom-lpg: Make use of devm_pwmchip_alloc() function
drm/bridge: ti-sn65dsi86: Make use of devm_pwmchip_alloc() function
drm/bridge: ti-sn65dsi86: Make use of pwmchip_parent() accessor
gpio: mvebu: Make use of devm_pwmchip_alloc() function
pwm: xilinx: Make use of devm_pwmchip_alloc() function
pwm: xilinx: Prepare removing pwm_chip from driver data
pwm: vt8500: Make use of devm_pwmchip_alloc() function
...
EPROBE_DEFER error returns are not really critical, since they cancel
the probe process, but the kernel will return later and retry.
However, depending on the probe order, this might issue quite some
verbatim and scary, though pointless messages:
[ 2.388731] 300b000.pinctrl: pin-224 (5000000.serial) status -517
[ 2.397321] 300b000.pinctrl: could not request pin 224 (PH0) from group PH0 on device 300b000.pinctrl
Replace dev_err() with dev_err_probe(), which not only drops the
priority of the message from error to debug, but also puts some text
into debugfs' devices_deferred file, for later reference.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Link: https://lore.kernel.org/r/20240305143859.2449147-1-andre.przywara@arm.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Awinic AW9523(B) is a multi-function I2C gpio expander in a
TQFN-24L package, featuring PWM (max 37mA per pin, or total max
power 3.2Watts) for LED driving capability.
It has two ports with 8 pins per port (for a total of 16 pins),
configurable as either PWM with 1/256 stepping or GPIO input/output,
1.8V logic input; each GPIO can be configured as input or output
independently from each other.
This IC also has an internal interrupt controller, which is capable
of generating an interrupt for each GPIO, depending on the
configuration, and will raise an interrupt on the INTN pin to
advertise this to an external interrupt controller.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Signed-off-by: David Bauer <mail@david-bauer.net>
Link: https://lore.kernel.org/r/20210624214458.68716-2-mail@david-bauer.net
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240301-awinic-aw9523-v8-1-7ec572f5dfb4@linaro.org
The variable ret is being assigned a value that is never read, it
is being re-assigned a value in every case statement in the following
switch statement. The assignment is redundant and can be removed.
Cleans up clang scan build warning:
drivers/pinctrl/pinctrl-ocelot.c:1404:3: warning: Value stored to 'ret'
is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20240223162850.3914349-1-colin.i.king@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We create a custom compatible for the STA2X11 IP block as integrated
into the Mobileye EyeQ5 platform. Its wake and alternate functions have
been disabled, we want to avoid touching those registers.
We both do: (1) early return in functions that do not support the
platform, but with warnings, and (2) avoid calling those functions in
the first place.
We ensure that pinctrl-nomadik is not used with this STA2X11 variant.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20240228-mbly-gpio-v2-24-3ba757474006@bootlin.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Move away from statically allocated GPIO IDs. Switch to dynamic ID
allocation. Static IDs are deprecated because they cause issues when
multiple GPIO controllers are to be found on the same platform.
Add a bit of complexity to do pin number -> GPIO chip + offset.
Previously, bank number and offsets were retrieved using division and
remainder (bank size being constant 32). Now, to get the pin number
matching a bank base, we must know the sum of ngpios of previous banks.
This is done in find_nmk_gpio_from_pin() which also exposes the offset
inside the bank.
Also remove the assumption that bank sizes are constant. Instead of
using NMK_GPIO_PER_CHIP as bank size, use nmk_gpio_chips[i]->ngpio.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20240228-mbly-gpio-v2-19-3ba757474006@bootlin.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix strict checkpatch warnings relative to if-else blocks and bool
expressions. Message types addressed:
CHECK: Comparison to NULL could be written "!nmk_cfg_params[index].choice"
CHECK: Unbalanced braces around else statement
CHECK: Using comparison to false is error prone
CHECK: Using comparison to true is error prone
CHECK: braces {} should be used on all arms of this statement
Before: 0 errors, 1 warnings, 16 checks.
After: 0 errors, 1 warnings, 7 checks.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20240228-mbly-gpio-v2-13-3ba757474006@bootlin.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
nmk_pinctrl_probe() iterates over each GPIO block. Use an early
conditional continue to skip to the next iteration rather than indent
all the loop code block.
Do not change code logic. The block is changed from:
for (i = 0; i < NMK_MAX_BANKS; i++) {
x = of_parse_phandle(...);
if (x) {
... do work ...
}
}
To:
for (i = 0; i < NMK_MAX_BANKS; i++) {
x = of_parse_phandle(...);
if (!x)
continue;
... do work ...
}
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20240228-mbly-gpio-v2-10-3ba757474006@bootlin.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Previously, drivers/pinctrl/nomadik/pinctrl-nomadik.c registered two
platform drivers: pinctrl & GPIO. Move the GPIO aspect to the
drivers/gpio/ folder, as would be expected.
Both drivers are intertwined for a reason; pinctrl requires access to
GPIO registers for pinmuxing, pull-disable, disabling interrupts while
setting the muxing and wakeup control. Information sharing is done
through a shared array containing GPIO chips and a few helper
functions. That shared array is not touched from gpio-nomadik when
CONFIG_PINCTRL_NOMADIK is not defined.
Make no change to the code that moved into gpio-nomadik; there should be
no behavior change following. A few functions are shared and header
comments are added. Checkpatch warnings are addressed. NUM_BANKS is
renamed to NMK_MAX_BANKS.
It is supported to compile gpio-nomadik without pinctrl-nomadik. The
opposite is not true.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20240228-mbly-gpio-v2-6-3ba757474006@bootlin.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
