pinmux: fix race causing mux_owner NULL with active mux_usecount
commit 5a3e85c3c397 ("pinmux: Use sequential access to access
desc->pinmux data") tried to address the issue when two client of the
same gpio calls pinctrl_select_state() for the same functionality, was
resulting in NULL pointer issue while accessing desc->mux_owner.
However, issue was not completely fixed due to the way it was handled
and it can still result in the same NULL pointer.
The issue occurs due to the following interleaving:
This sequence leads to a state where the pin appears to be in use
(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can
cause NULL pointer on next pin_request on the same pin.
Ensure that updates to mux_usecount and mux_owner are performed
atomically under the same lock. Only clear mux_owner when mux_usecount
reaches zero and no new owner has been assigned.
Yuanjie Yang [Tue, 24 Jun 2025 09:06:00 +0000 (17:06 +0800)]
pinctrl: qcom: add multi TLMM region option parameter
Add support for selecting multiple TLMM regions using the
tlmm-test tool.
The current implementation only selects the TLMM Node region
0, which can lead to incorrect region selection.
QCS615 gpio57 is in the south region with an offset of 0x39000,
and its address is 0x3d39000. However, the default region selection
is region 0 (east region), resulting in a wrong calculated address
of 0x3139000.
Add a tlmm option parameter named tlmm_reg_name to select the region.
If the user does not input the parameter, the default region is 0.
PINCTRL_RZV2M is selected by ARCH_R9A09G011, hence there is no need to
depend on the latter. Move the dependency on COMPILE_TEST to the symbol
prompt, like is done for all other auto-selected pin control symbols.
Renesas SoC has chip number / chip name. Some SoC is using chip number,
and some SoC is using chip name on current Renesas pincontrol Kconfig.
Let's unify "pin control support for ${CHIP_NUMBER} (${CHIP_NAME}).
Linus Walleij [Tue, 24 Jun 2025 18:47:57 +0000 (20:47 +0200)]
pinctrl: amlogic: Staticize some local structs
Sparse complains:
sparse warnings: (new ones prefixed by >>)
>> drivers/pinctrl/meson/pinctrl-amlogic-a4.c:126:24: sparse: sparse:
symbol 'multi_mux_s7' was not declared. Should it be static?
>> drivers/pinctrl/meson/pinctrl-amlogic-a4.c:135:28: sparse: sparse:
symbol 's7_priv_data' was not declared. Should it be static?
>> drivers/pinctrl/meson/pinctrl-amlogic-a4.c:140:24: sparse: sparse:
symbol 'multi_mux_s6' was not declared. Should it be static?
>> drivers/pinctrl/meson/pinctrl-amlogic-a4.c:154:28: sparse: sparse:
symbol 's6_priv_data' was not declared. Should it be static?
Colin Ian King [Mon, 23 Jun 2025 22:20:04 +0000 (23:20 +0100)]
pinctrl: eswin: Fix unsigned comparison to less than zero issue
The u32 variable voltage is being compared to less than zero and
this can never be true. Fix this by making voltage an int type which
is the same type as the return from the call to regulator_get_voltage.
Ze Huang [Mon, 23 Jun 2025 16:11:14 +0000 (00:11 +0800)]
pinctrl: canaan: k230: Fix order of DT parse and pinctrl register
Move DT parse before pinctrl register. This ensures that device tree
parsing is done before calling devm_pinctrl_register() to prevent using
uninitialized pin resources.
Ze Huang [Mon, 23 Jun 2025 16:11:13 +0000 (00:11 +0800)]
pinctrl: canaan: k230: add NULL check in DT parse
Add a NULL check for the return value of of_get_property() when
retrieving the "pinmux" property in the group parser. This avoids
a potential NULL pointer dereference if the property is missing
from the device tree node.
Also fix a typo ("sintenel") in the device ID match table comment,
correcting it to "sentinel".
Yuan Chen [Fri, 20 Jun 2025 01:53:43 +0000 (09:53 +0800)]
pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state()
In the original implementation, krealloc() failure handling incorrectly
assigned the original memory pointer to NULL after kfree(), causing a
memory leak when reallocation failed.
Yuan Chen [Fri, 20 Jun 2025 01:27:08 +0000 (09:27 +0800)]
pinctrl: sunxi: Fix memory leak on krealloc failure
In sunxi_pctrl_dt_node_to_map(), when krealloc() fails to resize
the pinctrl_map array, the function returns -ENOMEM directly
without freeing the previously allocated *map buffer. This results
in a memory leak of the original kmalloc_array allocation.
Shiji Yang [Wed, 18 Jun 2025 14:53:28 +0000 (22:53 +0800)]
pinctrl: falcon: mark pinctrl_falcon_init() as static
Fix the following missing-prototypes build warning:
drivers/pinctrl/pinctrl-falcon.c:508:12: error: no previous prototype for 'pinctrl_falcon_init' [-Werror=missing-prototypes]
508 | int __init pinctrl_falcon_init(void)
| ^~~~~~~~~~~~~~~~~~~
Lad Prabhakar [Mon, 16 Jun 2025 13:27:50 +0000 (14:27 +0100)]
pinctrl: renesas: rzg2l: Validate pins before setting mux function
Ensure only valid pins are configured by validating pin mappings before
setting the mux function.
Rename rzg2l_validate_gpio_pin() to rzg2l_validate_pin() to reflect its
broader purpose validating both GPIO pins and muxed pins. This helps
avoid invalid configurations.
gpio: mmio: add BGPIOF_NO_INPUT flag for GPO gpiochip
When using bgpio_init with a gpiochip acting as a GPO (output only), the
gpiochip ops `direction_input` was set to `bgpio_simple_dir_in` by
default but we have no input ability.
Adding this flag allows to set a valid ops for the `direction_output`
ops without setting a valid ops for `direction_input` by default.
Yulin Lu [Thu, 12 Jun 2025 10:51:59 +0000 (18:51 +0800)]
pinctrl: eswin: Add EIC7700 pinctrl driver
Add support for the pin controller in ESWIN's EIC7700 SoC,
which supports pin multiplexing, pin configuration,
and rgmii voltage control.
Co-developed-by: Samuel Holland <samuel.holland@sifive.com> Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Signed-off-by: Yulin Lu <luyulin@eswincomputing.com> Link: https://lore.kernel.org/20250612105159.1241-1-luyulin@eswincomputing.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Yulin Lu [Thu, 12 Jun 2025 10:48:11 +0000 (18:48 +0800)]
dt-bindings: pinctrl: eswin: Document for EIC7700 SoC
Add EIC7700 pinctrl device for all configurable pins.
For the EIC7700 pinctrl registers, each register (32 bits)
controls the characteristics of a single pin.
It supports setting function multiplexing, Schmitt trigger,
drive strength, pull-up/pull-down, and input enable.
Co-developed-by: Samuel Holland <samuel.holland@sifive.com> Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Signed-off-by: Yulin Lu <luyulin@eswincomputing.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/20250612104811.1206-1-luyulin@eswincomputing.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
irq_domain_create_simple() takes fwnode as the first argument. It can be
extracted from the struct device using dev_fwnode() helper instead of
using of_node with of_fwnode_handle().
Pin controller core code only stores the pointer to
'struct pinctrl_desc' and does not modify it anywhere. The pointer can
be changed to pointer to const which makes the code safer, explicit and
later allows constifying 'pinctrl_desc' allocations in individual
drivers.
Internal functions obtaining pointers to 'struct pinctrl_desc' do not
modify the contents so they can be made pointers to const. This makes
code safer, explicit and later allows constifying 'pinctrl_desc' in
pinctrl core code.
pinctrl: starfive: Allow compile testing on other platforms
Always descent to drivers/pinctrl/starfive/ because limiting it with
SOC_STARFIVE is redundant since its Makefile doesn't build anything if
no Starfive-specific pin control Kconfig options are enabled. This
allows compile testing on other architectures with allyesconfig.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Acked-by: Hal Feng <hal.feng@starfivetech.com> Link: https://lore.kernel.org/20250611-pinctrl-const-desc-v2-1-b11c1d650384@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Antonio Borneo [Tue, 10 Jun 2025 14:30:40 +0000 (16:30 +0200)]
pinctrl: stm32: Add RIF support for stm32mp257
On SoC stm32mp257, GPIO supports security and isolation compliant
with the Resource Isolation Framework (RIF). Each GPIO line can be
assigned to different security and compartment domains.
Add the generic code to handle the RIF configuration set by the
secure world and initialize the GPIO valid mask accordingly.
Antonio Borneo [Tue, 10 Jun 2025 14:30:38 +0000 (16:30 +0200)]
pinctrl: stm32: Declare stm32_pmx_get_mode() as static
The commit acaa037970f6 ("pinctrl: stm32: Implement .get_direction
gpio_chip callback") exported the function stm32_pmx_get_mode()
and the struct stm32_gpio_bank, but these were never used outside
the file that defines them.
Declare the function as static, drop it from the include file and
drop also the struct, not anymore visible outside the file.
Thomas Richard [Mon, 9 Jun 2025 11:51:15 +0000 (13:51 +0200)]
pinctrl: cirrus: madera-core: Use devm_pinctrl_register_mappings()
Use devm_pinctrl_register_mappings(), so the mappings are automatically
unregistered by the core. If pinctrl_enable() failed during the probe,
pinctrl_mappings were not freed. Now it is done by the core.
Xianwei Zhao [Tue, 27 May 2025 05:23:30 +0000 (13:23 +0800)]
pinctrl: meson: support amlogic S6/S7/S7D SoC
In some Amlogic SoCs, to save register space or due to some
abnormal arrangements, two sets of pins share one mux register.
A group starting from pin0 is the main pin group, which acquires
the register address through DTS and has management permissions,
but the register bit offset is undetermined.
Another GPIO group as a subordinate group. Some pins mux use share
register and bit offset from bit0 . But this group do not have
register management permissions.
Xianwei Zhao [Tue, 27 May 2025 05:23:29 +0000 (13:23 +0800)]
pinctrl: meson: a4: remove special data processing
According to the data specifications of Amlogic's existing SoCs,
the function register offset and the bit offset are the same
value among various chips. Therefore, general processing can
be carried out without the need for private data modification.
Drop special data processing.
Linus Torvalds [Sun, 8 Jun 2025 18:33:00 +0000 (11:33 -0700)]
Merge tag 'timers-cleanups-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer cleanup from Thomas Gleixner:
"The delayed from_timer() API cleanup:
The renaming to the timer_*() namespace was delayed due massive
conflicts against Linux-next. Now that everything is upstream finish
the conversion"
* tag 'timers-cleanups-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
treewide, timers: Rename from_timer() to timer_container_of()
Linus Torvalds [Sun, 8 Jun 2025 18:27:20 +0000 (11:27 -0700)]
Merge tag 'x86-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"A small set of x86 fixes:
- Cure IO bitmap inconsistencies
A failed fork cleans up all resources of the newly created thread
via exit_thread(). exit_thread() invokes io_bitmap_exit() which
does the IO bitmap cleanups, which unfortunately assume that the
cleanup is related to the current task, which is obviously bogus.
Make it work correctly
- A lockdep fix in the resctrl code removed the clearing of the
command buffer in two places, which keeps stale error messages
around. Bring them back.
- Remove unused trace events"
* tag 'x86-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
fs/resctrl: Restore the rdt_last_cmd_clear() calls after acquiring rdtgroup_mutex
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
x86/fpu: Remove unused trace events
Zhang Rui [Fri, 30 May 2025 00:09:28 +0000 (08:09 +0800)]
tools/power turbostat: Avoid probing the same perf counters
For the RAPL package energy status counter, Intel and AMD share the same
perf_subsys and perf_name, but with different MSR addresses.
Both rapl_counter_arch_infos[0] and rapl_counter_arch_infos[1] are
introduced to describe this counter for different Vendors.
As a result, the perf counter is probed twice, and causes a failure in
in get_rapl_counters() because expected_read_size and actual_read_size
don't match.
Fix the problem by skipping the already probed counter.
Note, this is not a perfect fix. For example, if different
vendors/platforms use the same MSR value for different purpose, the code
can be fooled when it probes a rapl_counter_arch_infos[] entry that does
not belong to the running Vendor/Platform.
In a long run, better to put rapl_counter_arch_infos[] into the
platform_features so that this becomes Vendor/Platform specific.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Zhang Rui [Sat, 17 May 2025 09:44:50 +0000 (17:44 +0800)]
tools/power turbostat: Allow probing RAPL with platform_features->rapl_msrs cleared
platform_features->rapl_msrs describes the RAPL MSRs supported. While
RAPL Perf counters can be exposed from different kernel backend drivers,
e.g. RAPL MSR I/F driver, or RAPL TPMI I/F driver.
Thus, turbostat should first blindly probe all the available RAPL Perf
counters, and falls back to the RAPL MSR counters if they are listed in
platform_features->rapl_msrs.
With this, platforms that don't have RAPL MSRs can clear the
platform_features->rapl_msrs bits and use RAPL Perf counters only.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
probe_rapl_msr() is reused for probing RAPL MSR counters, cstate MSR
counters and MPERF/APERF/SMI MSR counters, thus its name is misleading.
Similar to add_perf_counter(), introduce add_msr_counter() to probe a
counter via MSR. Introduce wrapper function add_rapl_msr_counter() at
the same time to add extra check for Zero return value for specified
RAPL counters.
No functional change intended.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
As the only caller of add_cstate_perf_counter_(),
add_cstate_perf_counter() just gives extra debug output on top. There is
no need to keep both functions.
Remove add_cstate_perf_counter_() and move all the logic to
add_cstate_perf_counter().
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
commit 05a2f07db888 ("tools/power turbostat: read RAPL counters via
perf") that adds support to read RAPL counters via perf defines the
notion of a RAPL domain_id which is set to physical_core_id on
platforms which support per_core_rapl counters (Eg: AMD processors
Family 17h onwards) and is set to the physical_package_id on all the
other platforms.
However, the physical_core_id is only unique within a package and on
platforms with multiple packages more than one core can have the same
physical_core_id and thus the same domain_id. (For eg, the first cores
of each package have the physical_core_id = 0). This results in all
these cores with the same physical_core_id using the same entry in the
rapl_counter_info_perdomain[]. Since rapl_perf_init() skips the
perf-initialization for cores whose domain_ids have already been
visited, cores that have the same physical_core_id always read the
perf file corresponding to the physical_core_id of the first package
and thus the package-energy is incorrectly reported to be the same
value for different packages.
Note: This issue only arises when RAPL counters are read via perf and
not when they are read via MSRs since in the latter case the MSRs are
read separately on each core.
Fix this issue by associating each CPU with rapl_core_id which is
unique across all the packages in the system.
Fixes: 05a2f07db888 ("tools/power turbostat: read RAPL counters via perf") Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Len Brown <len.brown@intel.com>
projects / thirdparty / kernel / linux.git / log
