| fc13a4b9 | 15-May-2026 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper
Introduce devm_acpm_get_by_phandle() to standardize how consumer drivers acquire a handle to the ACPM IPC interface. Enforce the use of t
firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper
Introduce devm_acpm_get_by_phandle() to standardize how consumer drivers acquire a handle to the ACPM IPC interface. Enforce the use of the "samsung,acpm-ipc" property name across the SoC and simplify the boilerplate code in client drivers.
The first consumer of this helper is the Exynos ACPM Thermal Management Unit (TMU) driver. The TMU utilizes a hybrid management approach: direct register access from the Application Processor (AP) is restricted to the interrupt pending (INTPEND) registers for event identification. High-level functional tasks, such as sensor initialization, threshold programming, and temperature reads, are delegated to the ACPM firmware via this IPC interface.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Link: https://patch.msgid.link/20260515-acpm-tmu-helpers-v2-6-8ca011d5a965@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| 4ba23dfc | 15-May-2026 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: samsung: acpm: Add TMU protocol support
The Thermal Management Unit (TMU) on the Google GS101 SoC is managed through a hybrid model shared between the kernel and the Alive Clock and Power
firmware: samsung: acpm: Add TMU protocol support
The Thermal Management Unit (TMU) on the Google GS101 SoC is managed through a hybrid model shared between the kernel and the Alive Clock and Power Manager (ACPM) firmware.
Add the protocol helpers required to communicate with the ACPM for thermal operations, including initialization, threshold configuration, temperature reading, and system suspend/resume handshakes.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Link: https://patch.msgid.link/20260515-acpm-tmu-helpers-v2-5-8ca011d5a965@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| 50b40021 | 15-May-2026 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: samsung: acpm: Make acpm_ops const and access via pointer
Replace the embedded `struct acpm_ops` inside `struct acpm_handle` with a pointer to a `const struct acpm_ops`.
Previously, the o
firmware: samsung: acpm: Make acpm_ops const and access via pointer
Replace the embedded `struct acpm_ops` inside `struct acpm_handle` with a pointer to a `const struct acpm_ops`.
Previously, the operations structure was embedded directly within the handle and populated dynamically at runtime via `acpm_setup_ops()`. This resulted in mutable function pointers and unnecessary per-instance memory overhead.
By defining `exynos_acpm_driver_ops` statically as a `const` structure, the function pointers are now safely housed in the read-only `.rodata` section. This improves security by preventing function pointer overwrites, saves memory, and slightly reduces initialization overhead in `acpm_probe()`.
Consequently, update all consumer drivers (clk, mfd) to access the operations via the new pointer indirection (`->ops->`). Finally, fix the previously empty kernel-doc description for the ops member to reflect its new pointer nature.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Link: https://patch.msgid.link/20260515-acpm-tmu-helpers-v2-4-8ca011d5a965@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| 9d7a6819 | 15-May-2026 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
Rename the `dvfs_ops` and `pmic_ops` members of `struct acpm_ops` to `dvfs` and `pmic` respectively.
Since these members are
firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
Rename the `dvfs_ops` and `pmic_ops` members of `struct acpm_ops` to `dvfs` and `pmic` respectively.
Since these members are housed within the `acpm_ops` structure and utilize the `acpm_*_ops` types, the `_ops` suffix on the variable names creates unnecessary redundancy (e.g., `handle.ops.dvfs_ops`).
This cleanup removes the stuttering, leading to cleaner consumer code.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Acked-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/linux-samsung-soc/CADrjBPqzKpcd9vuCmNUptCUPyPpPbHcc19-7kN-1c0RpW1e5DQ@mail.gmail.com/T/#mcce154a7e0c6cd1ca6cd5a1e37541ed7a85a84d4 [1] Link: https://patch.msgid.link/20260515-acpm-tmu-helpers-v2-3-8ca011d5a965@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| 447f4065 | 15-May-2026 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: samsung: acpm: Annotate rx_data->cmd with __counted_by_ptr
Rename the `n_cmd` member of `struct acpm_rx_data` to `cmdcnt` to maintain consistent nomenclature across the driver (aligning wi
firmware: samsung: acpm: Annotate rx_data->cmd with __counted_by_ptr
Rename the `n_cmd` member of `struct acpm_rx_data` to `cmdcnt` to maintain consistent nomenclature across the driver (aligning with `txcnt`, `rxcnt`, and transfer helpers).
With the member renamed, annotate the dynamically allocated `cmd` pointer with the `__counted_by_ptr(cmdcnt)` macro to improve runtime bounds checking.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Link: https://patch.msgid.link/20260515-acpm-tmu-helpers-v2-2-8ca011d5a965@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| d5cfe2a9 | 15-May-2026 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: samsung: acpm: Consolidate transfer initialization helper
Both the DVFS and PMIC ACPM sub-drivers implement similar local helper functions (acpm_dvfs_set_xfer and acpm_pmic_set_xfer) to in
firmware: samsung: acpm: Consolidate transfer initialization helper
Both the DVFS and PMIC ACPM sub-drivers implement similar local helper functions (acpm_dvfs_set_xfer and acpm_pmic_set_xfer) to initialize the acpm_xfer structure before sending an IPC message.
Move this logic into a single centralized helper, acpm_set_xfer(), in the core ACPM driver to reduce boilerplate, eliminate code duplication, and prepare for the upcoming ACPM TMU helper sub-driver which will also utilize this method.
Note that there is no change in underlying functionality. While the old acpm_pmic_set_xfer() unconditionally assigned the RX buffer parameters (xfer->rxd and xfer->rxcnt), the new unified helper introduces a 'response' boolean. All updated PMIC call sites now explicitly pass 'true' for this argument. This ensures the unified helper takes the 'if (response)' branch, performing the exact same assignments and preserving the original PMIC behavior.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Link: https://patch.msgid.link/20260515-acpm-tmu-helpers-v2-1-8ca011d5a965@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| 7fe40c32 | 05-May-2026 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: samsung: acpm: Fix infinite loop on sequence number exhaustion
Sashiko identified a possible infinite loop [1].
ACPM IPC sequence numbers are tracked via a 64-bit bitmap. Previously, acpm
firmware: samsung: acpm: Fix infinite loop on sequence number exhaustion
Sashiko identified a possible infinite loop [1].
ACPM IPC sequence numbers are tracked via a 64-bit bitmap. Previously, acpm_prepare_xfer() used a do...while loop to search for a free sequence number.
If all 63 available sequence numbers are leaked due to transient hardware timeouts or mailbox failures, the bitmap becomes full. The next call to acpm_prepare_xfer() would enter an infinite loop.
Fix this by utilizing the kernel's optimized bitmap search functions (find_next_zero_bit / find_first_zero_bit). If the pool is completely exhausted, log the failure and return -EBUSY to allow the kernel to fail gracefully instead of hanging.
Furthermore, drop the allocation loop entirely. Because acpm_prepare_xfer() is strictly called under the 'tx_lock' mutex, sequence number allocations are perfectly serialized. If find_next_zero_bit() locates a free bit, a single test_and_set_bit_lock() is mathematically guaranteed to succeed.
To enforce this locking invariant, wrap the allocation in a WARN_ON_ONCE. If the atomic set fails, it indicates the driver's mutex serialization is fundamentally broken. The warning generates a stack trace for debugging, while returning -EIO immediately aborts the transfer to prevent silent payload corruption.
Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-7-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| bf296f83 | 05-May-2026 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: samsung: acpm: Fix missing LKMM barriers in sequence allocator
Sashiko identified memory ordering races in [1].
The ACPM driver uses a globally shared 'bitmap_seqnum' to track available s
firmware: samsung: acpm: Fix missing LKMM barriers in sequence allocator
Sashiko identified memory ordering races in [1].
The ACPM driver uses a globally shared 'bitmap_seqnum' to track available sequence numbers. Even though threads now strictly free their own sequence numbers, the allocation and freeing of these bits across concurrent threads are effectively lockless operations and require explicit LKMM memory barriers.
Previously, the driver used plain bitwise operators (test_bit, set_bit, clear_bit), which lack ordering guarantees. This creates two race conditions on weakly ordered architectures like ARM64:
1. Polling Release Violation: The polling thread copies its payload and calls clear_bit(). Without a release barrier, the CPU can reorder the memory operations, making the cleared bit globally visible before the payload reads have fully completed. 2. TX Acquire Violation: The TX thread loops on test_bit(), calls set_bit(), and then wipes the payload buffer via memset(). Without an acquire barrier, the CPU can speculatively execute the memset() before the bit is safely and formally claimed.
If these reorderings overlap, a new TX thread can claim the sequence number and overwrite the buffer while the original polling thread is still actively reading from it.
Fix this by upgrading the bitwise operators. Wrap the TX allocation in test_and_set_bit_lock() to establish formal LKMM Acquire semantics, and pair it with clear_bit_unlock() in the polling path to enforce Release semantics.
Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260423-acpm-fixes-sashiko-reports-v1-0-2217b790925e%40linaro.org [1] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-6-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| c889b146 | 05-May-2026 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: samsung: acpm: Fix false timeouts and Use-After-Free in polling
Sashiko identified severe races in the polling state machine [1].
In the ACPM driver's polling mode, threads waited for res
firmware: samsung: acpm: Fix false timeouts and Use-After-Free in polling
Sashiko identified severe races in the polling state machine [1].
In the ACPM driver's polling mode, threads waited for responses by monitoring the globally shared 'bitmap_seqnum'. This caused false timeouts because if a thread processed its response and freed the sequence number, a concurrent TX thread could immediately reallocate it before the polling thread woke up.
Additionally, the driver suffered from a cross-thread Use-After-Free (UAF) preemption race. Previously, acpm_get_rx() cleared the sequence number of whichever RX message it drained from the hardware queue. This meant Thread A could globally free Thread B's sequence slot while Thread B was asleep. A new Thread C could then steal the slot, overwrite the buffer, and leave Thread B to wake up to corrupted state or a timeout.
Fix this by rewriting the polling state machine: 1. Decouple polling from the global allocator by introducing a per-slot 'completed' flag, synchronized via smp_store_release() and smp_load_acquire(). 2. Strip acpm_get_saved_rx() out of acpm_get_rx() to make it a pure queue-draining function. Introduce a 'native_match' boolean argument which evaluates to true only if the thread natively processed its own sequence number during the call. This explicitly informs the polling loop whether it must retrieve its payload from the cross-thread cache. 3. Centralize the cache fallback and sequence number free (clear_bit) inside the polling loop. Crucially, the free operation now strictly targets the thread's own TX sequence number (xfer->txd[0]), rather than the drained RX sequence number. This enforces strict ownership: a thread only ever frees its own allocated sequence slot, and only at the exact moment it completes its poll, eliminating the UAF window.
Furthermore, explicitly guard the 'native_match' assignment with an if (rx_seqnum == tx_seqnum) check, even for zero-length (no payload) responses. While an unguarded assignment wouldn't crash (because the cache fallback acpm_get_saved_rx() safely returns early on zero-length transfers) doing so would "lie" to the state machine. If a thread drained the queue and found another thread's zero-length message, setting native_match = true would falsely convince the polling loop that it natively handled its own response. Maintaining a rigorous state machine requires that native_match is only set when a thread explicitly processes its own sequence number.
Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad%40linaro.org [1] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-5-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| b66829b1 | 05-May-2026 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: samsung: acpm: Fix mailbox channel leak on probe error
Sashiko identified the leak at [1].
The ACPM driver allocates hardware mailbox channels using `mbox_request_channel()` during `acpm_
firmware: samsung: acpm: Fix mailbox channel leak on probe error
Sashiko identified the leak at [1].
The ACPM driver allocates hardware mailbox channels using `mbox_request_channel()` during `acpm_channels_init()`. However, the driver lacked a `.remove` callback and did not free these channels on subsequent error paths inside `acpm_probe()`.
Additionally, if `acpm_achan_alloc_cmds()` failed during the channel initialization loop, the function returned immediately, bypassing the manual cleanup and permanently leaking any channels successfully requested in previous loop iterations.
Fix this by modifying `acpm_free_mbox_chans()` to match the `devres` action signature and registering it via `devm_add_action_or_reset()`.
Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-2-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| a2be37ee | 24-Feb-2026 |
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> |
firmware: exynos-acpm: Drop fake 'const' on handle pointer
All the functions operating on the 'handle' pointer are claiming it is a pointer to const thus they should not modify the handle. In fact
firmware: exynos-acpm: Drop fake 'const' on handle pointer
All the functions operating on the 'handle' pointer are claiming it is a pointer to const thus they should not modify the handle. In fact that's a false statement, because first thing these functions do is drop the cast to const with container_of:
struct acpm_info *acpm = handle_to_acpm_info(handle);
And with such cast the handle is easily writable with simple:
acpm->handle.ops.pmic_ops.read_reg = NULL;
The code is not correct logically, either, because functions like acpm_get_by_node() and acpm_handle_put() are meant to modify the handle reference counting, thus they must modify the handle. Modification here happens anyway, even if the reference counting is stored in the container which the handle is part of.
The code does not have actual visible bug, but incorrect 'const' annotations could lead to incorrect compiler decisions.
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260224104203.42950-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| 951b8eee | 19-Feb-2026 |
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> |
firmware: exynos-acpm: Count acpm_xfer buffers with __counted_by_ptr
Use __counted_by_ptr() attribute on the acpm_xfer buffers so UBSAN will validate runtime that we do not pass over the buffer size
firmware: exynos-acpm: Count acpm_xfer buffers with __counted_by_ptr
Use __counted_by_ptr() attribute on the acpm_xfer buffers so UBSAN will validate runtime that we do not pass over the buffer size, thus making code safer.
Usage of __counted_by_ptr() (or actually __counted_by()) requires that counter is initialized before counted array.
Tested-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260219-firmare-acpm-counted-v2-3-e1f7389237d3@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| 00808ae2 | 19-Feb-2026 |
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> |
firmware: exynos-acpm: Count number of commands in acpm_xfer
Struct acpm_xfer holds two buffers with u32 commands - rxd and txd - and counts their size by rxlen and txlen. "len" suffix is here ambi
firmware: exynos-acpm: Count number of commands in acpm_xfer
Struct acpm_xfer holds two buffers with u32 commands - rxd and txd - and counts their size by rxlen and txlen. "len" suffix is here ambiguous, so could mean length of the buffer or length of commands, and these are not the same since each command is u32. Rename these to rxcnt and txcnt, and change their usage to count the number of commands in each buffer.
This will have a benefit of allowing to use __counted_by_ptr later.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260219-firmare-acpm-counted-v2-2-e1f7389237d3@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
show more ...
|
| bad0d126 | 10-Oct-2025 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: exynos-acpm: register ACPM clocks pdev
Register by hand a platform device for the ACPM clocks. The ACPM clocks are not modeled as a DT child of ACPM because: 1/ they don't have their own r
firmware: exynos-acpm: register ACPM clocks pdev
Register by hand a platform device for the ACPM clocks. The ACPM clocks are not modeled as a DT child of ACPM because: 1/ they don't have their own resources. 2/ they are not a block that can be reused. The clock identifying data is reduced (clock ID, clock name and mailbox channel ID) and may differ from a SoC to another.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Peter Griffin <peter.griffin@linaro.org> # on gs101-oriole Link: https://patch.msgid.link/20251010-acpm-clk-v6-3-321ee8826fd4@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|
| 2c2e5e90 | 24-Apr-2025 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
firmware: exynos-acpm: Correct kerneldoc and use typical np argument name
Correct kerneldoc warnings after commit a8dc26a0ec43 ("firmware: exynos-acpm: introduce devm_acpm_get_by_node()") changed th
firmware: exynos-acpm: Correct kerneldoc and use typical np argument name
Correct kerneldoc warnings after commit a8dc26a0ec43 ("firmware: exynos-acpm: introduce devm_acpm_get_by_node()") changed the function prototype:
exynos-acpm.c:672: warning: Function parameter or struct member 'acpm_np' not described in 'acpm_get_by_node' exynos-acpm.c:672: warning: expecting prototype for acpm_get_by_phandle(). Prototype was for acpm_get_by_node() instead
While touching the lines, change the name of device_node pointer to 'np' to match convention.
Fixes: a8dc26a0ec43 ("firmware: exynos-acpm: introduce devm_acpm_get_by_node()") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202504222051.7TqaSQ48-lkp@intel.com/ Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/r/20250424203308.402168-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|
| a8dc26a0 | 27-Mar-2025 |
André Draszik <andre.draszik@linaro.org> |
firmware: exynos-acpm: introduce devm_acpm_get_by_node()
To allow ACPM clients to simply be children of the ACPM node in DT, they need to be able to get the ACPM handle based on that ACPM node direc
firmware: exynos-acpm: introduce devm_acpm_get_by_node()
To allow ACPM clients to simply be children of the ACPM node in DT, they need to be able to get the ACPM handle based on that ACPM node directly.
Add an API to allow them to do so, devm_acpm_get_by_node().
At the same time, the previous approach of acquiring the ACPM handle via a DT phandle is now obsolete and we can remove devm_acpm_get_by_phandle(), which was there to facilitate that. There are no existing or anticipated upcoming users of that API, because all clients should be children of the ACPM node going forward.
Note that no DTs have been merged that use the old approach, so doing this API change in this driver now will not affect any existing DTs or client drivers.
Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250327-acpm-children-v1-2-0afe15ee2ff7@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|
| 636baba9 | 27-Mar-2025 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
firmware: exynos-acpm: populate devices from device tree data
ACPM clients (PMIC, clocks, etc.) will be modeled as children of the ACPM interface. Populate children platform_devices from device tree
firmware: exynos-acpm: populate devices from device tree data
ACPM clients (PMIC, clocks, etc.) will be modeled as children of the ACPM interface. Populate children platform_devices from device tree.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250327-acpm-children-v1-1-0afe15ee2ff7@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|
| 53734383 | 19-Mar-2025 |
André Draszik <andre.draszik@linaro.org> |
firmware: exynos-acpm: silence EPROBE_DEFER error on boot
This driver emits error messages when client drivers are trying to get an interface handle to this driver here before this driver has comple
firmware: exynos-acpm: silence EPROBE_DEFER error on boot
This driver emits error messages when client drivers are trying to get an interface handle to this driver here before this driver has completed _probe().
Given this driver returns -EPROBE_DEFER in that case, this is not an error and shouldn't be emitted to the log, similar to how dev_err_probe() behaves, so just remove them.
This change also allows us to simplify the logic around releasing of the acpm_np handle.
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250319-acpm-fixes-v2-2-ac2c1bcf322b@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|
| 67af3cd8 | 19-Mar-2025 |
André Draszik <andre.draszik@linaro.org> |
firmware: exynos-acpm: fix reading longer results
ACPM commands that return more than 8 bytes currently don't work correctly, as this driver ignores any such returned bytes.
This is evident in at l
firmware: exynos-acpm: fix reading longer results
ACPM commands that return more than 8 bytes currently don't work correctly, as this driver ignores any such returned bytes.
This is evident in at least acpm_pmic_bulk_read(), where up to 8 registers can be read back and those 8 register values are placed starting at &xfer->rxd[8].
The reason is that xfter->rxlen is initialized with the size of a pointer (8 bytes), rather than the size of the byte array that pointer points to (16 bytes)
Update the code such that we set the number of bytes expected to be the size of the rx buffer.
Note1: While different commands have different lengths rx buffers, we have to specify the same length for all rx buffers since acpm_get_rx() assumes they're all the same length.
Note2: The different commands also have different lengths tx buffers, but before switching the code to use the minimum possible length, some more testing would have to be done to ensure this works correctly in all situations. It seems wiser to just apply this fix here without additional logic changes for now.
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250319-acpm-fixes-v2-1-ac2c1bcf322b@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
show more ...
|