* Re: [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller
From: Icenowy Zheng @ 2026-05-18 11:57 UTC (permalink / raw)
To: dri-devel, Joey Lu, Icenowy Zheng, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <520e1683-6d5c-4e1f-8811-0ef78cf8d605@gmail.com>
于 2026年5月15日 GMT+08:00 17:08:25，Joey Lu <a0987203069@gmail.com> 写道：
>
>On 5/15/2026 4:38 PM, Icenowy Zheng wrote:
>> 在 2026-05-15五的 14:25 +0800，Joey Lu写道：
>>> On 5/12/2026 9:12 PM, Icenowy Zheng wrote:
>>>> 在 2026-05-12二的 18:59 +0800，Joey Lu写道：
>>>>> On 5/12/2026 6:01 PM, Icenowy Zheng wrote:
>>>>>> 在 2026-05-12二的 17:06 +0800，Joey Lu写道：
>>>>>>
>>>>>> ======= 8< =============
>>>>>>>>>>> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>>> b/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>>> index 7a93049368db..225af322de32 100644
>>>>>>>>>>> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>>> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>>> @@ -164,13 +164,16 @@ static void
>>>>>>>>>>> vs_bridge_enable_common(struct
>>>>>>>>>>> vs_crtc *crtc,
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_CLK_E
>>>>>>>>>>> N);
>>>>>>>>>>> regmap_set_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG(output),
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_RUNNI
>>>>>>>>>>> NG);
>>>>>>>>>>> - regmap_clear_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>>> -
>>>>>>>>>>> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>>>>>>>>>>> - regmap_set_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>>> -
>>>>>>>>>>> VSDC_DISP_PANEL_START_RUNNIN
>>>>>>>>>>> G(ou
>>>>>>>>>>> tput));
>>>>>>>>>>> - regmap_set_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>>>>>>>>>>> id),
>>>>>>>>>>> -
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX_CO
>>>>>>>>>>> MMIT);
>>>>>>>>>>> + if (dc->info->has_config_ex) {
>>>>>>>>>>> + regmap_clear_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>>> +
>>>>>>>>>>> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>>>>>>>>>>> + regmap_set_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>>> + VSDC_DISP_PANEL_STAR
>>>>>>>>>>> T_RU
>>>>>>>>>>> NNIN
>>>>>>>>>>> G(ou
>>>>>>>>>>> tput
>>>>>>>>>>> ));
>>>>>>>>>>> +
>>>>>>>>>>> + regmap_set_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
>>>>>>>>>>> + VSDC_DISP_PANEL_CONF
>>>>>>>>>>> IG_E
>>>>>>>>>>> X_CO
>>>>>>>>>>> MMIT
>>>>>>>>>>> );
>>>>>>>>>> Should the commit operation happen on
>>>>>>>>>> DC8000/DCUltraLite
>>>>>>>>>> too?
>>>>>>>>>> (By
>>>>>>>>>> writing to DcregFrameBufferConfig0.VALID).
>>>>>>>>>>
>>>>>>>>>> Many registers written has "Note: This field is double
>>>>>>>>>> buffered" in
>>>>>>>>>> the
>>>>>>>>>> DCUltraLite documentation.
>>>>>>>>>>
>>>>>>>>>> I suggest create a static function for commit -- write
>>>>>>>>>> to
>>>>>>>>>> the
>>>>>>>>>> corresponding commit bit on DC8200, and write to
>>>>>>>>>> DcregFrameBufferConfig0.VALID on DC8000/DCUltraLite.
>>>>>>>>> [a] There is no commit operation for DCUltra Lite.
>>>>>>>>> I'll not add a `VSDC_FB_CONFIG_VALID` macro. VALID
>>>>>>>>> (BIT(3))
>>>>>>>>> is a
>>>>>>>>> hardware-managed double-buffer status bit: hardware
>>>>>>>>> writes
>>>>>>>>> 1=PENDING
>>>>>>>>> when a new register set is ready and clears to 0=WORKING
>>>>>>>>> after
>>>>>>>>> the
>>>>>>>>> VBLANK copy. Software must never write it, and there is
>>>>>>>>> no
>>>>>>>>> polling
>>>>>>>>> use
>>>>>>>> It seems to be writable and controls whether register
>>>>>>>> buffering
>>>>>>>> is
>>>>>>>> enabled, see [1].
>>>>>>>>
>>>>>>>> The description of this bit in MA35D1 TRM says "This
>>>>>>>> ensures a
>>>>>>>> frame
>>>>>>>> will always start with a valid working set if this register
>>>>>>>> is
>>>>>>>> programmed last, which reduces the need for SW to wait for
>>>>>>>> the
>>>>>>>> start of
>>>>>>>> a VBLANK signal in order to ensure all states are loaded
>>>>>>>> before
>>>>>>>> the
>>>>>>>> next VBLANK", which indicates some kind of "committing
>>>>>>>> write",
>>>>>>>> although
>>>>>>>> the code at [1] seems to indicate that double buffering is
>>>>>>>> only
>>>>>>>> enabled
>>>>>>>> when bit is cleared.
>>>>>>>>
>>>>>>>> Anyway this bit should be programmable, and "Software must
>>>>>>>> never
>>>>>>>> write
>>>>>>>> it" contradicts with the MA35D1 TRM.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Icenowy
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/rockos-riscv/rockos-kernel/blob/rockos-v6.6.y/drivers/gpu/drm/eswin/es_dc_hw.c#L993
>>>>>>> Thank you for the correction. I'll add
>>>>>>> `#define VSDC_FB_CONFIG_VALID BIT(3)` to
>>>>>>> vs_primary_plane_regs.h
>>>>>>> and
>>>>>>> write it in `vs_primary_plane_commit()` for non-config_ex
>>>>>>> variants.
>>>>>>>>> case in the driver that requires a named constant. For
>>>>>>>>> non-
>>>>>>>>> config_ex
>>>>>>>>> variants, `vs_primary_plane_commit()` performs no commit
>>>>>>>>> operation —
>>>>>>>>> `VSDC_FB_CONFIG_ENABLE` (OUTPUT, BIT(0)) is set in
>>>>>>>>> `vs_crtc_atomic_enable()` and `VSDC_FB_CONFIG_RESET`
>>>>>>>>> (BIT(4))
>>>>>>>>> is
>>>>>>>>> set/cleared in the bridge enable/disable paths.
>>>>>> Well according to the driver code for DC8000 from Eswin, and
>>>>>> the
>>>>>> bit
>>>>>> named "VALID", maybe it should be cleared before programming
>>>>>> the
>>>>>> registers, and set after programming registers, to make the
>>>>>> process
>>>>>> of
>>>>>> programming registers atomic from the perspective of the
>>>>>> display
>>>>>> controller.
>>>>>>
>>>>>> Anyway this should require testing on real hardware to verify.
>>>>>>
>>>>>> By the way, I see multiple peripheral drivers for MA35D1 get
>>>>>> applied in
>>>>>> the torvalds tree, but the device tree is still only a
>>>>>> skeleton;
>>>>>> when
>>>>>> will the device tree be updated?
>>>>>>
>>>>>> Thanks,
>>>>>> Icenowy
>>>>> Thanks for pointing this out. I’ll perform tests on real hardware
>>>>> since
>>>>> I haven’t used this bit before.
>>>>>
>>>>> As for the device tree, we plan to update it comprehensively
>>>>> after
>>>>> completing several major IPs, with the goal of releasing the
>>>>> update
>>>>> later this year.
>>>> Well I bought a MA35D1 board (MYIR MYB-LMA35 + RGB LCD) earlier
>>>> this
>>>> year (and this is where I got the MA35D1 identification register
>>>> values). Hope I can have a chance to test this driver by myself.
>>>>
>>>> As MMC, Ethernet and USB support is all applied, maybe it's already
>>>> worthy to update the device tree ;-)
>>>>
>>>> Thanks,
>>>> Icenowy
>>> Yes you can!
>>>
>>> I have performed hardware validation on the MA35D1 and found that
>>> this
>>> bit acts as a manual latch for the shadow registers rather than an
>>> auto-clearing trigger, which clarifies the slightly ambiguous
>>> description in the TRM.
>>>
>>> Following your suggestion, I will align the implementation with
>>> ESWIN's
>>> DC8000 logic: setting the VALID bit at atomic_begin and clearing it
>> Ah do you mean clearing it at begin and setting it at flush?
>>
>> In the Eswin driver (which seems to be based on reference code by
>> Verisilicon, I saw similar driver code for DC8200),
>> dc_hw_enable_shadow_register() clears VALID bit when enable is true,
>> and all register setting sequences calls that function with enable =
>> true before setting and enable = false after setting.
>>
>> In addition, considering this bit is called "VALID" instead of
>> "INVALID", I think it represents that the DC will apply the new setting
>> when it's set and keep the current setting when it's cleared, so I
>> think it should be cleared before modeset sequence and be set after
>> modeset sequence.
>>
>> Thanks,
>> Icenowy
>Thanks for pointing that out. To clarify, the TRM defines the states for this bit as:
>1: PENDING (Shadow registers are locked; incoming CPU writes are held in the shadow buffer).
>0: WORKING (Shadow registers are unfrozen/live; configuration is committed).
This sounds reasonable, thanks for the clarification.
Sorry for me to be too lazy to verify it in HW.
Thanks,
Icenowy
>
>Regarding the Eswin reference, `dc_hw_enable_shadow_register(hw, false)` actually writes a 1 to isolate the registers during a batch update, and then transitions back to true (0) to flush them out.
>My hardware test confirms this sequence:
>
>- atomic_begin: We set VALID = 1. This safely freezes the current scanout configuration so we can update multiple registers (like frame addresses and pitches) without mid-frame tearing.
>- atomic_update: We write the new register values safely into the frozen shadow space.
>- atomic_flush: We clear VALID = 0. This releases the shadow lock, triggering the hardware to latch the whole batch atomically.
>
>If we reverse this logic—leaving the bit at 1 after the flush — the hardware remains permanently stuck in the PENDING state, waiting to be unfrozen, which starves the display engine and results in the blank screen behavior I observed.
>>> at
>>> atomic_flush. My tests confirm this allows the hardware to latch the
>>> plane configuration correctly while avoiding the blank screen issues
>>> observed with other configurations.
>>>
>>> I am preparing the v2 patchset with this change, along with the
>>> requested commit splits, and will submit it shortly.🙂
>>>
>>>>>>>> ========= 8< ==========
>>>>>>>>
^ permalink raw reply
* [PATCH v4 01/10] ACPI: APEI: GHES: share macros via a private header
From: Ahmed Tiba @ 2026-05-18 11:57 UTC (permalink / raw)
To: rafael, bp, saket.dumbre, will, xueshuai, mchehab, krzk+dt, dave,
conor+dt, vishal.l.verma, jic23, corbet, guohanjun, dave.jiang,
catalin.marinas, lenb, tony.luck, skhan, djbw, alison.schofield,
ira.weiny, robh
Cc: Ahmed Tiba, devicetree, linux-acpi, linux-doc, Dmitry.Lamerov,
linux-cxl, Michael.Zhao2, acpica-devel, linux-kernel,
linux-arm-kernel, linux-edac
In-Reply-To: <20260518-topics-ahmtib01-ras_ffh_arm_internal_review-v4-0-42698675ba61@arm.com>
Carve the CPER helper macros out of ghes.c and place them in a private
header so they can be shared with upcoming helper files. This is a
mechanical include change with no functional differences.
Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
---
drivers/acpi/apei/ghes.c | 94 +++++++++----------------------------------
include/acpi/ghes_cper.h | 102 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 120 insertions(+), 76 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 3236a3ce79d6..4f67f46410c4 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -49,6 +49,7 @@
#include <acpi/actbl1.h>
#include <acpi/ghes.h>
+#include <acpi/ghes_cper.h>
#include <acpi/apei.h>
#include <asm/fixmap.h>
#include <asm/tlbflush.h>
@@ -57,40 +58,6 @@
#include "apei-internal.h"
-#define GHES_PFX "GHES: "
-
-#define GHES_ESTATUS_MAX_SIZE 65536
-#define GHES_ESOURCE_PREALLOC_MAX_SIZE 65536
-
-#define GHES_ESTATUS_POOL_MIN_ALLOC_ORDER 3
-
-/* This is just an estimation for memory pool allocation */
-#define GHES_ESTATUS_CACHE_AVG_SIZE 512
-
-#define GHES_ESTATUS_CACHES_SIZE 4
-
-#define GHES_ESTATUS_IN_CACHE_MAX_NSEC 10000000000ULL
-/* Prevent too many caches are allocated because of RCU */
-#define GHES_ESTATUS_CACHE_ALLOCED_MAX (GHES_ESTATUS_CACHES_SIZE * 3 / 2)
-
-#define GHES_ESTATUS_CACHE_LEN(estatus_len) \
- (sizeof(struct ghes_estatus_cache) + (estatus_len))
-#define GHES_ESTATUS_FROM_CACHE(estatus_cache) \
- ((struct acpi_hest_generic_status *) \
- ((struct ghes_estatus_cache *)(estatus_cache) + 1))
-
-#define GHES_ESTATUS_NODE_LEN(estatus_len) \
- (sizeof(struct ghes_estatus_node) + (estatus_len))
-#define GHES_ESTATUS_FROM_NODE(estatus_node) \
- ((struct acpi_hest_generic_status *) \
- ((struct ghes_estatus_node *)(estatus_node) + 1))
-
-#define GHES_VENDOR_ENTRY_LEN(gdata_len) \
- (sizeof(struct ghes_vendor_record_entry) + (gdata_len))
-#define GHES_GDATA_FROM_VENDOR_ENTRY(vendor_entry) \
- ((struct acpi_hest_generic_data *) \
- ((struct ghes_vendor_record_entry *)(vendor_entry) + 1))
-
/*
* NMI-like notifications vary by architecture, before the compiler can prune
* unused static functions it needs a value for these enums.
@@ -102,25 +69,6 @@
static ATOMIC_NOTIFIER_HEAD(ghes_report_chain);
-static inline bool is_hest_type_generic_v2(struct ghes *ghes)
-{
- return ghes->generic->header.type == ACPI_HEST_TYPE_GENERIC_ERROR_V2;
-}
-
-/*
- * A platform may describe one error source for the handling of synchronous
- * errors (e.g. MCE or SEA), or for handling asynchronous errors (e.g. SCI
- * or External Interrupt). On x86, the HEST notifications are always
- * asynchronous, so only SEA on ARM is delivered as a synchronous
- * notification.
- */
-static inline bool is_hest_sync_notify(struct ghes *ghes)
-{
- u8 notify_type = ghes->generic->notify.type;
-
- return notify_type == ACPI_HEST_NOTIFY_SEA;
-}
-
/*
* This driver isn't really modular, however for the time being,
* continuing to use module_param is the easiest way to remain
@@ -165,12 +113,6 @@ static DEFINE_MUTEX(ghes_devs_mutex);
*/
static DEFINE_SPINLOCK(ghes_notify_lock_irq);
-struct ghes_vendor_record_entry {
- struct work_struct work;
- int error_severity;
- char vendor_record[];
-};
-
static struct gen_pool *ghes_estatus_pool;
static struct ghes_estatus_cache __rcu *ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE];
@@ -266,7 +208,7 @@ static void ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
apei_write(val, &gv2->read_ack_register);
}
-static struct ghes *ghes_new(struct acpi_hest_generic *generic)
+struct ghes *ghes_new(struct acpi_hest_generic *generic)
{
struct ghes *ghes;
unsigned int error_block_length;
@@ -313,7 +255,7 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
return ERR_PTR(rc);
}
-static void ghes_fini(struct ghes *ghes)
+void ghes_fini(struct ghes *ghes)
{
kfree(ghes->estatus);
apei_unmap_generic_address(&ghes->generic->error_status_address);
@@ -363,8 +305,8 @@ static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
}
/* Check the top-level record header has an appropriate size. */
-static int __ghes_check_estatus(struct ghes *ghes,
- struct acpi_hest_generic_status *estatus)
+int __ghes_check_estatus(struct ghes *ghes,
+ struct acpi_hest_generic_status *estatus)
{
u32 len = cper_estatus_len(estatus);
u32 max_len = min(ghes->generic->error_block_length,
@@ -389,9 +331,9 @@ static int __ghes_check_estatus(struct ghes *ghes,
}
/* Read the CPER block, returning its address, and header in estatus. */
-static int __ghes_peek_estatus(struct ghes *ghes,
- struct acpi_hest_generic_status *estatus,
- u64 *buf_paddr, enum fixed_addresses fixmap_idx)
+int __ghes_peek_estatus(struct ghes *ghes,
+ struct acpi_hest_generic_status *estatus,
+ u64 *buf_paddr, enum fixed_addresses fixmap_idx)
{
struct acpi_hest_generic *g = ghes->generic;
int rc;
@@ -400,7 +342,7 @@ static int __ghes_peek_estatus(struct ghes *ghes,
if (rc) {
*buf_paddr = 0;
pr_warn_ratelimited(FW_WARN GHES_PFX
-"Failed to read error status block address for hardware error source: %d.\n",
+ "Failed to read error status block address for hardware error source: %d.\n",
g->header.source_id);
return -EIO;
}
@@ -417,9 +359,9 @@ static int __ghes_peek_estatus(struct ghes *ghes,
return 0;
}
-static int __ghes_read_estatus(struct acpi_hest_generic_status *estatus,
- u64 buf_paddr, enum fixed_addresses fixmap_idx,
- size_t buf_len)
+int __ghes_read_estatus(struct acpi_hest_generic_status *estatus,
+ u64 buf_paddr, enum fixed_addresses fixmap_idx,
+ size_t buf_len)
{
ghes_copy_tofrom_phys(estatus, buf_paddr, buf_len, 1, fixmap_idx);
if (cper_estatus_check(estatus)) {
@@ -431,9 +373,9 @@ static int __ghes_read_estatus(struct acpi_hest_generic_status *estatus,
return 0;
}
-static int ghes_read_estatus(struct ghes *ghes,
- struct acpi_hest_generic_status *estatus,
- u64 *buf_paddr, enum fixed_addresses fixmap_idx)
+int ghes_read_estatus(struct ghes *ghes,
+ struct acpi_hest_generic_status *estatus,
+ u64 *buf_paddr, enum fixed_addresses fixmap_idx)
{
int rc;
@@ -449,9 +391,9 @@ static int ghes_read_estatus(struct ghes *ghes,
cper_estatus_len(estatus));
}
-static void ghes_clear_estatus(struct ghes *ghes,
- struct acpi_hest_generic_status *estatus,
- u64 buf_paddr, enum fixed_addresses fixmap_idx)
+void ghes_clear_estatus(struct ghes *ghes,
+ struct acpi_hest_generic_status *estatus,
+ u64 buf_paddr, enum fixed_addresses fixmap_idx)
{
estatus->block_status = 0;
diff --git a/include/acpi/ghes_cper.h b/include/acpi/ghes_cper.h
new file mode 100644
index 000000000000..6b7632cfaf66
--- /dev/null
+++ b/include/acpi/ghes_cper.h
@@ -0,0 +1,102 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * GHES declarations used by both the ACPI APEI GHES driver
+ * and the firmware-first CPER provider.
+ *
+ * These declarations lets GHES and other firmware-first error sources use
+ * the same helper so the non-ACPI path follows the same
+ * behavior as GHES instead of carrying a separate copy.
+ *
+ * Derived from the ACPI APEI GHES driver.
+ *
+ * Copyright 2010,2011 Intel Corp.
+ * Author: Huang Ying <ying.huang@intel.com>
+ */
+
+#ifndef ACPI_APEI_GHES_CPER_H
+#define ACPI_APEI_GHES_CPER_H
+
+#include <linux/workqueue.h>
+
+#include <acpi/ghes.h>
+
+#define GHES_PFX "GHES: "
+
+#define GHES_ESTATUS_MAX_SIZE 65536
+#define GHES_ESOURCE_PREALLOC_MAX_SIZE 65536
+
+#define GHES_ESTATUS_POOL_MIN_ALLOC_ORDER 3
+
+/* This is just an estimation for memory pool allocation */
+#define GHES_ESTATUS_CACHE_AVG_SIZE 512
+
+#define GHES_ESTATUS_CACHES_SIZE 4
+
+#define GHES_ESTATUS_IN_CACHE_MAX_NSEC 10000000000ULL
+/* Prevent too many caches are allocated because of RCU */
+#define GHES_ESTATUS_CACHE_ALLOCED_MAX (GHES_ESTATUS_CACHES_SIZE * 3 / 2)
+
+#define GHES_ESTATUS_CACHE_LEN(estatus_len) \
+ (sizeof(struct ghes_estatus_cache) + (estatus_len))
+#define GHES_ESTATUS_FROM_CACHE(estatus_cache) \
+ ((struct acpi_hest_generic_status *) \
+ ((struct ghes_estatus_cache *)(estatus_cache) + 1))
+
+#define GHES_ESTATUS_NODE_LEN(estatus_len) \
+ (sizeof(struct ghes_estatus_node) + (estatus_len))
+#define GHES_ESTATUS_FROM_NODE(estatus_node) \
+ ((struct acpi_hest_generic_status *) \
+ ((struct ghes_estatus_node *)(estatus_node) + 1))
+
+#define GHES_VENDOR_ENTRY_LEN(gdata_len) \
+ (sizeof(struct ghes_vendor_record_entry) + (gdata_len))
+#define GHES_GDATA_FROM_VENDOR_ENTRY(vendor_entry) \
+ ((struct acpi_hest_generic_data *) \
+ ((struct ghes_vendor_record_entry *)(vendor_entry) + 1))
+
+static inline bool is_hest_type_generic_v2(struct ghes *ghes)
+{
+ return ghes->generic->header.type == ACPI_HEST_TYPE_GENERIC_ERROR_V2;
+}
+
+/*
+ * A platform may describe one error source for the handling of synchronous
+ * errors (e.g. MCE or SEA), or for handling asynchronous errors (e.g. SCI
+ * or External Interrupt). On x86, the HEST notifications are always
+ * asynchronous, so only SEA on ARM is delivered as a synchronous
+ * notification.
+ */
+static inline bool is_hest_sync_notify(struct ghes *ghes)
+{
+ u8 notify_type = ghes->generic->notify.type;
+
+ return notify_type == ACPI_HEST_NOTIFY_SEA;
+}
+
+struct ghes_vendor_record_entry {
+ struct work_struct work;
+ int error_severity;
+ char vendor_record[];
+};
+
+#ifdef CONFIG_ACPI_APEI
+struct ghes *ghes_new(struct acpi_hest_generic *generic);
+void ghes_fini(struct ghes *ghes);
+
+int ghes_read_estatus(struct ghes *ghes,
+ struct acpi_hest_generic_status *estatus,
+ u64 *buf_paddr, enum fixed_addresses fixmap_idx);
+void ghes_clear_estatus(struct ghes *ghes,
+ struct acpi_hest_generic_status *estatus,
+ u64 buf_paddr, enum fixed_addresses fixmap_idx);
+int __ghes_peek_estatus(struct ghes *ghes,
+ struct acpi_hest_generic_status *estatus,
+ u64 *buf_paddr, enum fixed_addresses fixmap_idx);
+int __ghes_check_estatus(struct ghes *ghes,
+ struct acpi_hest_generic_status *estatus);
+int __ghes_read_estatus(struct acpi_hest_generic_status *estatus,
+ u64 buf_paddr, enum fixed_addresses fixmap_idx,
+ size_t buf_len);
+#endif
+
+#endif /* ACPI_APEI_GHES_CPER_H */
--
2.43.0
^ permalink raw reply related
* [PATCH v4 00/10] ACPI: APEI: share GHES CPER helpers and add DT FFH provider
From: Ahmed Tiba @ 2026-05-18 11:57 UTC (permalink / raw)
To: rafael, bp, saket.dumbre, will, xueshuai, mchehab, krzk+dt, dave,
conor+dt, vishal.l.verma, jic23, corbet, guohanjun, dave.jiang,
catalin.marinas, lenb, tony.luck, skhan, djbw, alison.schofield,
ira.weiny, robh
Cc: Ahmed Tiba, devicetree, linux-acpi, linux-doc, Dmitry.Lamerov,
linux-cxl, Michael.Zhao2, acpica-devel, linux-kernel,
linux-arm-kernel, linux-edac
This is v4 of the GHES refactor series. Compared to v3, it mainly
updates the shared header comment and the DT binding/description
for the firmware-owned CPER buffer.
Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
Changes in v4:
- Reworded the ghes_cper.h header comment and kept the original copyrights.
- Fixed the ghes_cper.h W=1 warnings by limiting the ACPI
fixmap-based declarations to the ACPI build path.
- Updated the DT binding to describe the CPER buffer
as firmware-owned shared memory.
- Described the optional ack area as a second memory-region entry.
- Updated the DT example accordingly.
- Link to v3: https://lore.kernel.org/r/20260318-topics-ahmtib01-ras_ffh_arm_internal_review-v3-0-48e6a1c249ef@arm.com
Changes in v3:
- Fixed the new ghes_cper.h header comment and kept the original
copyrights.
- Added <linux/bitfield.h> to fix the kernel test robot build failure.
- Renamed the binding/compatible and DT-side naming to ras-cper.
- Switched the DT provider to generic firmware property accessors.
- Replaced atomic source IDs with IDA.
- Updated IRQ/error/resource handling as suggested in review
(platform_get_irq(), dev_err_probe(), devm platform ioremap
helpers).
- Removed the ARM64 dependency and fixed Kconfig/build coverage.
- Clarified comments and kept the early move patches mechanical.
- Link to v2: https://lore.kernel.org/r/20260220-topics-ahmtib01-ras_ffh_arm_internal_review-v2-0-347fa2d7351b@arm.com
Changes in v2:
- Dropped the proposed "estatus core" and kept GHES naming/flow intact
(per Borislav Petkov).
- Re-sliced the series into smaller mechanical steps (per Mauro Carvalho Chehab).
- Minor DT binding fixes based on Krzysztof Kozlowski's feedback.
- Removed fixmap slot usage from the DT FFH driver (per Will Deacon).
Series structure:
- Patches 1-8 are mechanical moves only and do not change behavior.
- Patch 9 wires the shared helpers back into GHES.
- The DT firmware-first CPER buffer provider is added in the final patches.
- "ACPI: APEI: introduce GHES helper" is internal build glue only
and does not introduce a new user-visible configuration option.
- Link to v1: https://lore.kernel.org/r/20251217112845.1814119-1-ahmed.tiba@arm.com
---
Ahmed Tiba (10):
ACPI: APEI: GHES: share macros via a private header
ACPI: APEI: GHES: move CPER read helpers
ACPI: APEI: GHES: move GHESv2 ack and alloc helpers
ACPI: APEI: GHES: move estatus cache helpers
ACPI: APEI: GHES: move vendor record helpers
ACPI: APEI: GHES: move CXL CPER helpers
ACPI: APEI: introduce GHES helper
ACPI: APEI: share GHES CPER helpers
dt-bindings: firmware: add arm,ras-cper
RAS: add firmware-first CPER provider
Documentation/admin-guide/RAS/main.rst | 18 +
.../devicetree/bindings/firmware/arm,ras-cper.yaml | 71 ++
MAINTAINERS | 6 +
drivers/Makefile | 1 +
drivers/acpi/Kconfig | 4 +
drivers/acpi/apei/Kconfig | 1 +
drivers/acpi/apei/apei-internal.h | 10 +-
drivers/acpi/apei/ghes.c | 1025 +------------------
drivers/acpi/apei/ghes_cper.c | 1027 ++++++++++++++++++++
drivers/ras/Kconfig | 11 +
drivers/ras/Makefile | 1 +
drivers/ras/cper-esource.c | 257 +++++
include/acpi/ghes.h | 10 +-
include/acpi/ghes_cper.h | 151 +++
include/cxl/event.h | 2 +-
15 files changed, 1559 insertions(+), 1036 deletions(-)
---
base-commit: e1914add2799225a87502051415fc5c32aeb02ae
change-id: 20260220-topics-ahmtib01-ras_ffh_arm_internal_review-bfddc7fc7cab
Best regards,
--
Ahmed Tiba <ahmed.tiba@arm.com>
^ permalink raw reply
* Re: [PATCH v12 06/15] kasan: arm64: x86: Make page_to_virt() KASAN aware
From: Will Deacon @ 2026-05-18 11:56 UTC (permalink / raw)
To: Maciej Wieczor-Retman
Cc: Catalin Marinas, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Maciej Wieczor-Retman, linux-arm-kernel, linux-kernel, kasan-dev,
linux-mm
In-Reply-To: <b9f7bd991dd2ba0b4c187f5c63962626f00c6a62.1774872838.git.m.wieczorretman@pm.me>
On Mon, Mar 30, 2026 at 02:33:43PM +0000, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>
> Special page_to_virt() implementation is needed if an architecture wants
> to enable KASAN software tag-based mode.
>
> Make page_to_virt() KASAN aware in arch-independent code so
> architectures implementing the software tag-based mode don't have to
> define their own implementations anymore. When KASAN is disabled or for
> architectures that don't implement the software tag-based mode
> page_to_virt() will be optimized to it's previous form.
>
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> ---
> Changelog v11:
> - Redo the patch to work on the page_to_virt macro. Split off changes
> about virt to phys conversion to an earlier patch.
> - Remove Alexander's acked-by due to bigger changes.
>
> Changelog v7:
> - Add Alexander's Acked-by tag.
>
> Changelog v5:
> - Move __tag_reset() calls into __phys_addr_nodebug() and
> __virt_addr_valid() instead of calling it on the arguments of higher
> level functions.
>
> Changelog v4:
> - Simplify page_to_virt() by removing pointless casts.
> - Remove change in __is_canonical_address() because it's taken care of
> in a later patch due to a LAM compatible definition of canonical.
>
> arch/arm64/include/asm/memory.h | 5 -----
> include/linux/kasan.h | 10 ++++++++++
> include/linux/mm.h | 5 ++++-
> 3 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 875c0bd0d85a..39dd0071d3ec 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -411,11 +411,6 @@ static inline unsigned long virt_to_pfn(const void *kaddr)
> */
>
> #if defined(CONFIG_DEBUG_VIRTUAL)
> -#define page_to_virt(x) ({ \
> - __typeof__(x) __page = x; \
> - void *__addr = __va(page_to_phys(__page)); \
> - (void *)__tag_set((const void *)__addr, page_kasan_tag(__page));\
> -})
So here we're using '__page' to avoid multiple evaluations of 'x'...
> #define virt_to_page(x) pfn_to_page(virt_to_pfn(x))
> #else
> #define page_to_virt(x) ({ \
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index e18908f3ad6e..271c59e9f422 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -527,6 +527,11 @@ static inline void *kasan_reset_tag(const void *addr)
> return (void *)arch_kasan_reset_tag(addr);
> }
>
> +static inline void *kasan_set_tag(const void *addr, u8 tag)
> +{
> + return (void *)arch_kasan_set_tag(addr, tag);
> +}
> +
> /**
> * kasan_report - print a report about a bad memory access detected by KASAN
> * @addr: address of the bad access
> @@ -544,6 +549,11 @@ static inline void *kasan_reset_tag(const void *addr)
> return (void *)addr;
> }
>
> +static inline void *kasan_set_tag(const void *addr, u8 tag)
> +{
> + return (void *)addr;
> +}
> +
> #endif /* CONFIG_KASAN_SW_TAGS || CONFIG_KASAN_HW_TAGS*/
>
> #ifdef CONFIG_KASAN_HW_TAGS
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 09044934dda8..f234650a4edf 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -117,7 +117,10 @@ extern int mmap_rnd_compat_bits __read_mostly;
> #endif
>
> #ifndef page_to_virt
> -#define page_to_virt(x) __va(PFN_PHYS(page_to_pfn(x)))
> +#define page_to_virt(x) ({ \
> + void *__addr = __va(PFN_PHYS(page_to_pfn((struct page *)x))); \
> + kasan_set_tag(__addr, page_kasan_tag(x)); \
> +})
... but in the new code you're proposing, you evaluate 'x' twice.
Is there a reason not to take the arm64 code as-is?
Will
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Paul Kocialkowski @ 2026-05-18 11:54 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: Andre Przywara, linux-sunxi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <6d8659f393e0bb4f0805107a17e306422982247c.camel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]
Hi Alexander,
Le Mon 18 May 26, 13:29, Alexander Sverdlin a écrit :
> Hi Andre,
>
> On Mon, 2026-05-18 at 13:16 +0200, Andre Przywara wrote:
> > > > And anyway, I see a *dual* USB-A socket on the pictures online, in
> > > > addition to the USB-OTG port. So where does the third USB come from? The
> > > > A133 only supports one host USB port plus the one OTG port. So is there
> > > > an USB hub chip on the board?
> > >
> > > There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
> >
> > What do you mean with OTG side hub, exactly? Is there a hub on USB0? How
> > does this work, then?
>
> the upstream port of this hub is wired to the USB-C connector, one port has
> CH340E USB-UART on it for the console, the other port goes to the SoC usbphy 0.
> So it would be "peripheral" only, I suppose.
Yes like I explained in my other email there used to be a USB0 ID pin in
earlier revisions of the board but it was reassigned and USB0 is now
sitting behind the hub so it should be peripheral only.
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Paul Kocialkowski @ 2026-05-18 11:52 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sunxi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Andre Przywara,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260510201644.4143710-4-alexander.sverdlin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 11951 bytes --]
Hi Alexander,
Le Sun 10 May 26, 22:16, Alexander Sverdlin a écrit :
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
Just in case you missed it, there was a previous submission for this
board which wasn't followed up on.
I also have one of this board and wanted to respin support, but it looks
like you beat me to it :)
Thanks for working on this!
Please change the naming to "Baijie HelperBoard A133" and "Baijie A133
HelperBoard Core" to align with the vendor terminology and rename the
files as:
- sun50i-a133-helperboard.dts
- sun50i-a133-helperboard-core.dtsi
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - Gigabit Ethernet
> - Bluetooth
> - WiFi
>
> Add initial support for both the Helper and Core boards, including UART,
> PMU, eMMC, USB, Ethernet.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
>
> Changelog:
> v2:
> - introduced baijie,helper-a133-core compatible for the Core (SoM) board
>
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-a133-baije-core.dtsi | 162 ++++++++++++++++++
> .../allwinner/sun50i-a133-baijie-helper.dts | 94 ++++++++++
> 3 files changed, 257 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index d116864b6c2b..926dfa851100 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -18,6 +18,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h64-remix-mini-pc.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a133-baijie-helper.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a133-liontron-h-a133l.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus-v1.2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> new file mode 100644
> index 000000000000..65b094f30bf5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> @@ -0,0 +1,162 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2025 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a100.dtsi"
> +#include "sun50i-a100-cpu-opp.dtsi"
> +
> +/{
You could add a model here while at it, even though it would generally
be overwritten.
> + compatible = "baijie,helper-a133-core",
> + "allwinner,sun50i-a100";
> +
> + aliases {
> + serial1 = &uart1; /* BT module */
Not sure this is reallyt useful.
> + };
You should add:
chosen {
stdout-path = "serial0:115200n8";
};
As well as the incoming 5v regulator:
reg_vcc5v: vcc5v {
compatible = "regulator-fixed";
regulator-name = "vcc-5v";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
regulator-always-on;
};
> +};
> +
> +&cpu0 {
> + cpu-supply = <®_dcdc2>;
> +};
> +
> +&pio {
> + vcc-pb-supply = <®_dcdc1>;
> + vcc-pc-supply = <®_eldo1>;
> + vcc-pd-supply = <®_dcdc1>;
> + vcc-pe-supply = <®_dldo2>;
> + vcc-pf-supply = <®_dcdc1>;
> + vcc-pg-supply = <®_dldo1>;
> + vcc-ph-supply = <®_dcdc1>;
> +};
> +
> +&mmc2 {
mmc2 goes before pio (alphanum sorting).
> + vmmc-supply = <®_dcdc1>;
> + vqmmc-supply = <®_eldo1>;
> + cap-mmc-hw-reset;
> + non-removable;
> + bus-width = <8>;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + status = "okay";
You can add:
max-frequency = <100000000>;
cap-mmc-highspeed;
> +};
> +
> +&r_i2c0 {
> + status = "okay";
> +
> + axp803: pmic@34 {
> + compatible = "x-powers,axp803";
> + reg = <0x34>;
> + interrupt-parent = <&r_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
You can also add:
x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
aldoin-supply = <®_vcc5v>;
dldoin-supply = <®_vcc5v>;
eldoin-supply = <®_vcc5v>;
fldoin-supply = <®_dcdc5>;
vin1-supply = <®_vcc5v>;
vin2-supply = <®_vcc5v>;
vin3-supply = <®_vcc5v>;
vin4-supply = <®_vcc5v>;
vin5-supply = <®_vcc5v>;
vin6-supply = <®_vcc5v>;
> + };
> +};
> +
> +#include "axp803.dtsi"
> +
> +&ac_power_supply {
> + status = "okay";
> +};
> +
> +®_aldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-pll-avcc";
> +};
> +
> +®_aldo2 {
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-dram-lpddr";
> +};
> +
> +®_aldo3 {
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-pl";
> +};
> +
> +®_dcdc1 {
> + regulator-always-on;
> + regulator-min-microvolt = <1600000>;
> + regulator-max-microvolt = <3400000>;
> + regulator-name = "vcc-3v3";
Should be:
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-name = "vcc-io-usb-pd-nand-3v3";
> +};
> +
> +®_dcdc2 {
> + regulator-always-on;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1300000>;
Should be:
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1300000>;
> + regulator-name = "vdd-cpu";
> +};
> +
> +®_dcdc3 {
> + regulator-always-on;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1300000>;
> +};
DCDC3 is polyphased with DCDC2, so remove this one and add:
/* DCDC3 is polyphased with DCDC2 */
> +
> +®_dcdc4 {
> + regulator-always-on;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-name = "vdd-sys";
Should be:
regulator-min-microvolt = <810000>;
regulator-max-microvolt = <990000>;
regulator-name = "vcc-usb-sys";
> +};
> +
> +®_dcdc5 {
> + regulator-always-on;
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1840000>;
> + regulator-name = "vcc-dram";
Should be:
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-name = "vcc-dram-2";
ALDO2 is the main DRAM supply, this is the second one.
> +};
> +
> +/* DCDC6 unused */
> +
> +®_dldo1 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-pg";
> +};
> +
> +®_dldo2 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3400000>;
> + regulator-enable-ramp-delay = <1000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-csi-pe";
> +};
> +
> +®_dldo3 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-name = "avdd-csi";
Should be:
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-name = "ldo-avdd-csi";
> +};
> +
> +®_dldo4 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
Should be:
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-name = "ldo-avdd-csi";
> +};
You can add:
®_drivevbus {
regulator-name = "usb0-vbus";
status = "okay";
};
> +
> +®_eldo1 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-enable-ramp-delay = <1000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-pc-efuse-lvds-cpvin-mcsi";
> +};
> +
> +®_eldo2 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1900000>;
Should be:
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-name = "dvdd-csi";
> +};
> +
> +/* ELDO3 unused */
> +
> +®_fldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vdd-cpus-usb";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
> new file mode 100644
> index 000000000000..ccbca5d0a40c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2025 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a133-baije-core.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/{
> + model = "HelperBoard A133";
> + compatible = "baijie,helper-a133",
> + "baijie,helper-a133-core",
> + "allwinner,sun50i-a100";
> +
> + aliases {
> + serial0 = &uart0;
The is best added to the core dtsi.
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
Ditto.
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led {
> + function = LED_FUNCTION_INDICATOR;
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&pio 7 13 GPIO_ACTIVE_LOW>; /* PH13 */
> + };
> + };
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dcdc1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
You can add:
disable-wp;
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pb_pins>;
> + status = "okay";
> +};
> +
> +&rgmii0_pins {
> + drive-strength = <30>;
> +};
Sorting is also incorrect throughout the file, please use alphanum
sorting for phandle-based overwrites.
> +
> +&emac0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii0_pins>;
> + phy-handle = <ð_phy>;
> + phy-mode = "rgmii-id";
> + allwinner,rx-delay-ps = <200>;
> + allwinner,tx-delay-ps = <200>;
> + status = "okay";
> +};
> +
> +&mdio0 {
> + reset-gpios = <&pio 7 11 GPIO_ACTIVE_LOW>; /* PH11 */
> + reset-delay-us = <10000>;
> + reset-post-delay-us = <150000>;
> +
> + eth_phy: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +};
> +
> +&usbphy {
> + status = "okay";
You can add:
usb0_vbus-supply = <®_dcdc1>;
usb1_vbus-supply = <®_dcdc4>;
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
AFAIK there is no ID pin so ehci0/ohci0 will not be used.
It seems that version 1.7 of the board used PH0 as USB0 ID pin but
version 2.5 has reassigned PH8 to LCD reset.
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> --
> 2.54.0
>
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] media: s5p-jpeg: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-18 11:52 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, Jacek Anaszewski, Sylwester Nawrocki,
Mauro Carvalho Chehab, linux-arm-kernel, linux-media,
linux-kernel
Cc: Guangshuo Li
s5p_jpeg_probe() allocates encoder and decoder video_devices with
video_device_alloc() and releases them if video_register_device() fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
s5p_jpeg_probe()
-> video_device_release(jpeg->vfd_encoder)
The same issue exists for jpeg->vfd_decoder.
Use video_device_release_empty() while registering the devices so that
registration failure paths do not free them through vdev->release().
s5p_jpeg_probe() then releases the failed video_device exactly once.
Restore video_device_release() after successful registration so the
registered devices keep their normal lifetime handling.
This issue was found by a static analysis tool I am developing.
Fixes: 7a1d4e7c064c ("[media] s5p-jpeg: Eliminate double kfree()")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/samsung/s5p-jpeg/jpeg-core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/samsung/s5p-jpeg/jpeg-core.c b/drivers/media/platform/samsung/s5p-jpeg/jpeg-core.c
index fdc9d7e0be66..046ad555c5fc 100644
--- a/drivers/media/platform/samsung/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/samsung/s5p-jpeg/jpeg-core.c
@@ -2915,7 +2915,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
jpeg->vfd_encoder->fops = &s5p_jpeg_fops;
jpeg->vfd_encoder->ioctl_ops = &s5p_jpeg_ioctl_ops;
jpeg->vfd_encoder->minor = -1;
- jpeg->vfd_encoder->release = video_device_release;
+ jpeg->vfd_encoder->release = video_device_release_empty;
jpeg->vfd_encoder->lock = &jpeg->lock;
jpeg->vfd_encoder->v4l2_dev = &jpeg->v4l2_dev;
jpeg->vfd_encoder->vfl_dir = VFL_DIR_M2M;
@@ -2927,6 +2927,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
video_device_release(jpeg->vfd_encoder);
goto m2m_init_rollback;
}
+ jpeg->vfd_encoder->release = video_device_release;
video_set_drvdata(jpeg->vfd_encoder, jpeg);
v4l2_info(&jpeg->v4l2_dev,
@@ -2945,7 +2946,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
jpeg->vfd_decoder->fops = &s5p_jpeg_fops;
jpeg->vfd_decoder->ioctl_ops = &s5p_jpeg_ioctl_ops;
jpeg->vfd_decoder->minor = -1;
- jpeg->vfd_decoder->release = video_device_release;
+ jpeg->vfd_decoder->release = video_device_release_empty;
jpeg->vfd_decoder->lock = &jpeg->lock;
jpeg->vfd_decoder->v4l2_dev = &jpeg->v4l2_dev;
jpeg->vfd_decoder->vfl_dir = VFL_DIR_M2M;
@@ -2957,6 +2958,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
video_device_release(jpeg->vfd_decoder);
goto enc_vdev_register_rollback;
}
+ jpeg->vfd_decoder->release = video_device_release;
video_set_drvdata(jpeg->vfd_decoder, jpeg);
v4l2_info(&jpeg->v4l2_dev,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] ARM: dts: aspeed: anacapa: add interrupt properties for PDB PCA9555
From: Andrew Jeffery @ 2026-05-18 11:48 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Rex Fu
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260417-anacapa-pca9555-irq-v1-1-9a6d28b1b656@amd.com>
On Fri, 17 Apr 2026 14:41:49 +0800, Rex Fu wrote:
> Add interrupt-parent and interrupts properties to the PDB PCA9555
> nodes in the anacapa DTS.
Thanks, I've applied this to the BMC tree.
--
Andrew Jeffery <andrew@codeconstruct.com.au>
^ permalink raw reply
* Re: [PATCH v1 2/7] ARM: dts: aspeed: system1: Enable video engine
From: Andrew Jeffery @ 2026-05-18 11:38 UTC (permalink / raw)
To: Ninad Palsule, eajames, robh, krzk+dt, conor+dt, joel, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Manojkiran Eda
In-Reply-To: <20260421224551.1611818-3-ninad@linux.ibm.com>
On Tue, 2026-04-21 at 17:45 -0500, Ninad Palsule wrote:
> From: Manojkiran Eda <manojkiran.eda@gmail.com>
>
> This patch enables the aspeed video engine support in ASPEED BMC for
> IBM System1. It is crucial for facilitating the BMC's video capture
> and redirection capabilities, which are integral to remote management
> and KVM (Keyboard-Video-Mouse) over IP functionality.
This is a real nitpick, but: The commit message seems a bit too
grandiose for my tastes. Can you make it more succinct? Writing in
imperative mood to avoid "this patch" is generally recommended too:
https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
Andrew
>
> Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>
> Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
> ---
> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> index 488d0b3916a1..0ca799893791 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> @@ -531,6 +531,10 @@ &lpc_snoop {
> snoop-ports = <0x80>, <0x81>;
> };
>
> +&video {
> + status = "okay";
> +};
> +
> &i2c0 {
> status = "okay";
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd.
From: Paul Kocialkowski @ 2026-05-18 11:36 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sunxi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Andre Przywara,
devicetree, linux-arm-kernel, linux-kernel, Conor Dooley
In-Reply-To: <20260510201644.4143710-2-alexander.sverdlin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]
Hi,
Le Sun 10 May 26, 22:16, Alexander Sverdlin a écrit :
> Shenzhen Baijie Technology Co., Ltd. focuses on R&D and production of
> embedded products as well as customization of embedded solutions.
>
> Link: https://szbaijie.com/
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
All the best,
Paul
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 28784d66ae7b..095cf654787f 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -229,6 +229,8 @@ patternProperties:
> description: Azoteq (Pty) Ltd
> "^azw,.*":
> description: Shenzhen AZW Technology Co., Ltd.
> + "^baijie,.*":
> + description: Shenzhen Baijie Technology Co., Ltd.
> "^baikal,.*":
> description: BAIKAL ELECTRONICS, JSC
> "^bananapi,.*":
> --
> 2.54.0
>
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible
From: Paul Kocialkowski @ 2026-05-18 11:35 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sunxi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Andre Przywara,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260510201644.4143710-3-alexander.sverdlin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
Hi Alexander,
Le Sun 10 May 26, 22:16, Alexander Sverdlin a écrit :
> Baijie HelperBoard A133 is a development board around their A133 Core
> board. Introduce a compatible for both the Core and the development
> boards.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
>
> Changelog:
> v2:
> - introduced baijie,helper-a133-core compatible for the Core (SoM) board
>
> Documentation/devicetree/bindings/arm/sunxi.yaml | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index e6443c266fa1..d7b9dec81165 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -96,6 +96,17 @@ properties:
> - const: allwinner,ba10-tvbox
> - const: allwinner,sun4i-a10
>
> + - description: Baijie Helper A133
Please use the correct naming from the vendor, which is: "Baijie
A133 HelperBoard"
> + items:
> + - const: baijie,helper-a133
Please make this: "baijie,helperboard-a133"
> + - const: baijie,helper-a133-core
Please make this: "baijie,helperboard-a133-core"
Thanks!
> + - const: allwinner,sun50i-a100
> +
> + - description: HelperBoardA133 Core
> + items:
> + - const: baijie,helper-a133-core
> + - const: allwinner,sun50i-a100
> +
> - description: BananaPi
> items:
> - const: lemaker,bananapi
> --
> 2.54.0
>
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1 7/7] ARM: dts: aspeed: system1: DTS updates
From: Andrew Jeffery @ 2026-05-18 11:34 UTC (permalink / raw)
To: Ninad Palsule, eajames, robh, krzk+dt, conor+dt, joel, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260421224551.1611818-8-ninad@linux.ibm.com>
Hi Ninad,
On Tue, 2026-04-21 at 17:45 -0500, Ninad Palsule wrote:
> - Removed SGPIO node as not in use anymore.
> - Updated chassis power related pins as per the new hardware design
Can you please take a look at the discussion in the thread linked
below, and consider some of the approaches outlined there?
https://lore.kernel.org/all/d7794f74b26bbc1ee0a70e39c5671acc018f80eb.camel@codeconstruct.com.au/
I'd like to avoid a stream of backwards-incompatible changes due to
platform design changes where we can.
Andrew
>
> Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
> ---
> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> index 91c317267d6b..d7a934fe5860 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> @@ -424,7 +424,7 @@ &pinctrl_gpiol6_unbiased
> /*E0-E7*/ "","","","","","","","",
> /*F0-F7*/ "","","","","","","","",
> /*G0-G7*/ "","","","","","","","",
> - /*H0-H7*/ "","","","","","","","",
> + /*H0-H7*/ "power-chassis-good","power-chassis-reboot","","","","","","",
> /*I0-I7*/ "","","","","","","","",
> /*J0-J7*/ "","","","","","","","",
> /*K0-K7*/ "","","","","","","","",
> @@ -440,7 +440,7 @@ &pinctrl_gpiol6_unbiased
> /*U0-U7*/ "","","","","","","","",
> /*V0-V7*/ "","rtc-battery-voltage-read-enable","","power-chassis-control","","","","",
> /*W0-W7*/ "","","","","","","","",
> - /*X0-X7*/ "fpga-pgood","power-chassis-good","pch-pgood","","","","","",
> + /*X0-X7*/ "fpga-pgood","","pch-pgood","","","","","",
> /*Y0-Y7*/ "","","","","","","","",
> /*Z0-Z7*/ "","","","","","","","";
>
> @@ -486,12 +486,6 @@ &emmc {
> clk-phase-mmc-hs200 = <180>, <180>;
> };
>
> -&sgpiom0 {
> - status = "okay";
> - ngpios = <128>;
> - bus-frequency = <500000>;
> -};
> -
> &ibt {
> status = "okay";
> };
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: rockchip: inno-hdmi: Add configure() and validate() ops
From: Jonas Karlman @ 2026-05-18 11:19 UTC (permalink / raw)
To: Vinod Koul
Cc: Neil Armstrong, Heiko Stuebner, linux-phy, linux-rockchip,
linux-arm-kernel, linux-kernel
In-Reply-To: <agny1ER5j6om9hIT@vaman>
On 5/17/2026 6:54 PM, Vinod Koul wrote:
> On 15-05-26, 23:04, Jonas Karlman wrote:
>> Hi,
>>
>> On 5/15/2026 9:55 PM, Jonas Karlman wrote:
>>> The commit 10ed34d6eaaf ("phy: Add HDMI configuration options")
>>> introduced a way for HDMI PHYs to be configured through the generic
>>> phy_configure() function.
>>>
>>> This driver derives the TMDS character rate from the pixel clock and the
>>> PHY bus width setting. However, no in-tree consumer of this PHY has ever
>>> called phy_set_bus_width() to change the TMDS character rate as only
>>> 8-bit RGB output is supported by the HDMI display driver.
>>>
>>> Add configure() and validate() ops to allow consumers to configure the
>>> TMDS character rate using phy_configure(). Fallback to the deprecated
>>> way of using the PHY bus width to configure the TMDS character rate.
>>>
>>> A typical call chain during DRM modeset on a RK3328 device:
>>>
>>> dw_hdmi_rockchip_encoder_atomic_check():
>>> - inno_hdmi_phy_validate(): pixclock 148500000 tmdsclock 594000000
>>>
>>> dw_hdmi_rockchip_encoder_atomic_mode_set():
>>> - inno_hdmi_phy_configure(): pixclock 148500000
>>> - inno_hdmi_phy_validate(): pixclock 148500000 tmdsclock 594000000
>>>
>>> vop_crtc_atomic_enable():
>>> - inno_hdmi_phy_rk3328_clk_set_rate(): rate 594000000 tmdsclk 594000000
>>> - inno_hdmi_phy_rk3328_clk_set_rate(): pixclock 594000000 tmdsclock 594000000
>>> - inno_hdmi_phy_rk3328_clk_recalc_rate(): pixclock 594000000 vco 594000000
>>>
>>> dw_hdmi_rockchip_encoder_enable():
>>> - inno_hdmi_phy_power_on(): Inno HDMI PHY Power On
>>> - inno_hdmi_phy_rk3328_clk_set_rate(): rate 594000000 tmdsclk 594000000
>>>
>>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
>>> ---
>>> Changes in v3:
>>> - Change validate() ops to only validate tmdsclock
>>> - Add comments about expected consumer usage
>>> - Update commit message with a typical call chain
>>> Changes in v2:
>>> - Add validate() ops to validate that the TMDS rate is supported
>>> - Split out parts that remove the old workaround into a separate patch
>>>
>>> Patch "drm/rockchip: dw_hdmi: Configure HDMI PHY in atomic_mode_set()"
>>> at [1] adds phy_validate() and phy_configure() calls for this HDMI PHY.
>>>
>>> [1] https://lore.kernel.org/dri-devel/20260510183114.1248840-10-jonas@kwiboo.se/
>>> ---
>>> drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 60 ++++++++++++++++++-
>>> 1 file changed, 59 insertions(+), 1 deletion(-)
>>
>> [snip]
>>
>>> +static int inno_hdmi_phy_validate(struct phy *phy, enum phy_mode mode,
>>> + int submode, union phy_configure_opts *opts)
>>> +{
>>> + const struct pre_pll_config *cfg = pre_pll_cfg_table;
>>> + unsigned long tmdsclock;
>>> +
>>> + if (!(mode == PHY_MODE_HDMI && submode == PHY_HDMI_MODE_TMDS))
>>> + return -EINVAL;
>>> +
>>> + if (!opts->hdmi.tmds_char_rate || opts->hdmi.tmds_char_rate > 594000000)
>>> + return -EINVAL;
>>
>> Sashiko reasoning log pointed out that a consumer of phy_validate() or
>> phy_configure() can make a call with opts=NULL, so I may likely send a
>> v4 of this series to fix such possible NULL pointer dereference here.
>
> Yes please
I will send a v4 that includes a NULL check, thanks.
>
>>
>> Or is that something that possible should be checked before phy core
>> calls the .validate()/.configure() ops?
>
> The opts is an optional argument depending upon the mode to be valid. So
> we cant do that in the core...
>
>>
>> Multiple other phy .configure() ops seem to dereference opts members
>> without any type of opts NULL check. (next-20260508)
>
> We should fix these
>
>
> PS: Any reason why you are sending encypted emails?
Hopefully you find a way to read this :-)
My email provider tries to be smart and encrypts any outgoing mail when
there is a PGP key published for a recipient in a Web Key Directory,
something that kernel.org has [2].
I raised an issue with the provider and was hoping that the change they
made [3] would fix the issue, and it looks like your published PGP key
is not sign-only and is in fact encryption-capable.
Will open a new issue and ask them to add some way to fully disable use
of automatic encryption on outgoing mails.
[2] https://www.kernel.org/category/signatures.html
[3] https://github.com/forwardemail/forwardemail.net/commit/88def5438a8da678252c234e876d3cdd469a8202
Regards,
Jonas
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: firmware: google,gs101-acpm-ipc: document Exynos850 compatible
From: Alexey Klimov @ 2026-05-18 11:30 UTC (permalink / raw)
To: Tudor Ambarus, Sam Protsenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Alim Akhtar
Cc: Peter Griffin, linux-samsung-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <e91496f2-3b7a-4982-992a-91e8326367be@linaro.org>
On Thu May 14, 2026 at 3:46 PM BST, Tudor Ambarus wrote:
> Hi, Alexey,
>
> Please check sashiko's review from:
> https://sashiko.dev/#/patchset/20260513-exynos850-acpm-firmware-support-v1-0-3858d097e433%40linaro.org
>
> does the gs101 pmic constraints apply to e850?
Thanks for the heads-up! Yes, sashiko-bot@kernel.org sends reports and
I received it. The "To:" field there includes lesser email addresses and
only device tree mail list.
I need to check pmic thingy for e850 but probably yes. Obviously, it
needs updating.
Thanks,
Alexey
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Alexander Sverdlin @ 2026-05-18 11:29 UTC (permalink / raw)
To: Andre Przywara, linux-sunxi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <256b1cd8-b143-4f71-91cc-8513be04ce4c@arm.com>
Hi Andre,
On Mon, 2026-05-18 at 13:16 +0200, Andre Przywara wrote:
> > > And anyway, I see a *dual* USB-A socket on the pictures online, in
> > > addition to the USB-OTG port. So where does the third USB come from? The
> > > A133 only supports one host USB port plus the one OTG port. So is there
> > > an USB hub chip on the board?
> >
> > There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
>
> What do you mean with OTG side hub, exactly? Is there a hub on USB0? How
> does this work, then?
the upstream port of this hub is wired to the USB-C connector, one port has
CH340E USB-UART on it for the console, the other port goes to the SoC usbphy 0.
So it would be "peripheral" only, I suppose.
--
Alexander Sverdlin.
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-18 11:25 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Matthew Wilcox, surenb, akpm, linux-mm, david, liam, vbabka, rppt,
mhocko, jack, pfalcato, wanglian, chentao, lianux.mm, kunwu.chan,
liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <agrWuDNGddNmvMFD@lucifer>
On Mon, May 18, 2026 at 5:47 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
>
> On Sun, May 17, 2026 at 04:45:15PM +0800, Barry Song wrote:
> > On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:
> > > > On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > > >
> > > > > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:
> > > > > > 1. There is no deterministic latency for I/O completion. It depends on
> > > > > > both the hardware and the software stack (bio/request queues and the
> > > > > > block scheduler). Sometimes the latency is short; at other times it can
> > > > > > be quite long. In such cases, a high-priority thread performing operations
> > > > > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait
> > > > > > for an unpredictable amount of time.
> > > > >
> > > > > But does that actually happen? I find it hard to believe that thread A
> > > > > unmaps a VMA while thread B is in the middle of taking a page fault in
> > > > > that same VMA. mprotect() and madvise() are more likely to happen, but
> > > > > it still seems really unlikely to me.
> > > >
> > > > It doesn’t have to involve unmapping or applying mprotect to
> > > > the entire VMA—just a portion of it is sufficient.
> > >
> > > Yes, but that still fails to answer "does this actually happen". How much
> > > performance is all this complexity in the page fault handler buying us?
> > > If you don't answer this question, I'm just going to go in and rip it
> > > all out.
> > >
> >
> > Hi Matthew (and Lorenzo, Jan, and anyone else who may be
> > waiting for answers),
> >
> > As promised during LSF/MM/BPF, we conducted thorough
> > testing on Android phones to determine whether performing
> > I/O in `filemap_fault()` can block `vma_start_write()`.
> > I wanted to give a quick update on this question.
> >
> > Nanzhe at Xiaomi created tracing scripts and ran various
> > applications on Android devices with I/O performed under
> > the VMA lock in `filemap_fault()`. We found that:
> >
> > 1. There are very few cases where unmap() is blocked by
> > page faults. I assume this is due to buggy user code
> > or poor synchronization between reads and unmap().
> > So I assume it is not a problem.
> >
> > 2. We observed many cases where `vma_start_write()`
> > is blocked by page-fault I/O in some applications.
> > The blocking occurs in the `dup_mmap()` path during
> > fork().
> >
> > With Suren's commit fb49c455323ff ("fork: lock VMAs of
> > the parent process when forking"), we now always hold
> > `vma_write_lock()` for each VMA. Note that the
> > `mmap_lock` write lock is also held, which could lead to
> > chained waiting if page-fault I/O is performed without
> > releasing the VMA lock.
>
> Hm but did you observe this 'chained waiting'? And what were the latencies?
We have clearly observed that the `fork()` operations of many
popular Android apps, such as iQiyi, Baidu Tieba, and 10086,
end up waiting on page-fault (PF) I/O when the VMA lock is
held during I/O operations. This has already become a
practical issue. I also believe this can lead to chained
waiting, since the global `mmap_lock` blocks all threads that
need to acquire it.
>
> >
> > My gut feeling is that Suren's commit may be overshooting,
> > so my rough idea is that we might want to do something like
> > the following (we haven't tested it yet and it might be
> > wrong):
>
> Yeah I'm really not sure about that.
>
> Prior to the VMA locks, the mmap write lock would have guaranteed no concurrent
> page faults, which is really what fb49c455323ff is about.
>
> So Suren's patch was essentially restoring the _existing_ forking behaviour, and
> now you're saying 'let's change the forking behaviour that's been like that for
> forever'.
I am afraid not. Before we introduced the per-VMA lock, we
were not performing I/O while holding `mmap_lock`. A page fault
that needed I/O would drop the `mmap_lock` read lock and allow
`fork()` to proceed.
Now, you are suggesting performing I/O while holding the VMA
lock, which changes the requirements and introduces this
problem.
>
> I think you would _really_ have to be sure that's safe. And forking is a very
> dangerous time in terms of complexity and sensitivity and 'weird stuff'
> happening so I'd tread _very_ carefully here.
Yep. I think my original proposal did not require any changes
to `fork()`, since it simply preserved the current behavior of
dropping the VMA lock before performing I/O. In that model,
`fork()` would not end up waiting on I/O at all.
What you are suggesting now appears to be performing I/O while
holding the VMA lock, which in turn introduces the need to
change `fork()`.
>
> >
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 2311ae7c2ff4..5ddaf297f31a 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct
> > *mm, struct mm_struct *oldmm)
> > for_each_vma(vmi, mpnt) {
> > struct file *file;
> >
> > - retval = vma_start_write_killable(mpnt);
> > + /*
> > + * For anonymous or writable private VMAs, prevent
> > + * concurrent CoW faults.
> > + */
>
> To nit pick I think the comment's confusing but also tells you you don't need to
> specific anon check - writable private is sufficient. And it's not really just
> CoW that's the issue, it's anon_vma population _at all_ as well as CoW.
>
> > + if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) &&
> > + (mpnt->vm_flags & VM_WRITE)))
> > + retval = vma_start_write_killable(mpnt);
>
> I think this has to be VM_MAYWRITE, because somebody could otherwise mprotect()
> it R/W.
>
> I also don't understand why !mpnt->vm_file for a read-only anon mapping (more
> likely PROT_NONE) is here, just do the second check?
>
> (Also please use the new interface, so !vma_test(mpnt, VMA_SHARED_BIT) &&
> vma_test(mpnt, VMA_MAYWRITE_BIT))
Yep, I can definitely refine the check further. But before
doing that, I'd first like to confirm that we are aligned on
the direction.
If you still intend to hold the VMA lock while performing I/O,
then I think we should fix `fork()` to avoid taking
`vma_start_write()`.
>
> > if (retval < 0)
> > goto loop_out;
> > if (mpnt->vm_flags & VM_DONTCOPY) {
> >
> > Based on the above, we may want to re-check whether fork()
> > can be blocked by page faults. At the same time, if Suren,
> > you, or anyone else has any comments, please feel free to
> > share them.
> >
> > Best Regards
> > Barry
>
> Technical commentary above is sort of 'just cos' :) because I really question
> doing this honestly.
I think we either need to fix `fork()`, or keep the current
behavior of dropping the VMA lock before performing I/O.
>
> I'd also like to get Suren's input, however.
Yes. of course.
>
> Thanks, Lorenzo
Best Regards
Barry
^ permalink raw reply
* Re: [PATCH 5/6] firmware: samsung: acpm: Add TMU protocol support
From: Alexey Klimov @ 2026-05-18 11:24 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Krzysztof Kozlowski, Michael Turquette, Stephen Boyd, Lee Jones,
Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, jyescas, kernel-team, Krzysztof Kozlowski
In-Reply-To: <a55690fc-7727-401d-9b3c-06bf3c2852d0@linaro.org>
On Fri May 15, 2026 at 8:56 AM BST, Tudor Ambarus wrote:
>
>
> On 5/11/26 4:17 PM, Alexey Klimov wrote:
>> On Thu May 7, 2026 at 9:31 AM BST, Tudor Ambarus wrote:
>>> On 5/6/26 6:13 PM, Alexey Klimov wrote:
>>>> On Wed May 6, 2026 at 12:39 PM BST, Tudor Ambarus wrote:
>>
>> [..]
>>
>>>>> new file mode 100644
>>>>> index 000000000000..c68d60b4c0b3
>>>>> --- /dev/null
>>>>> +++ b/drivers/firmware/samsung/exynos-acpm-tmu.c
>>>>
>>>> [..]
>>>>
>>>>> +static int acpm_tmu_to_linux_err(s8 fw_err)
>>>>> +{
>>>>> + /*
>>>>> + * ACPM_TMU_INIT uses BIT(0) and BIT(1) of msg.rx.ret to flag APM
>>>>> + * capabilities. Treat zero and all positive values as success.
>>>>
>>>> ACPM_TMU_INIT returns capabilities inside designated error field?
>>>
>>> yes
>>
>> Heh. Okay.
>>
>>>> What about other messages/commands? They just return error code there?
>>>
>>> all the other commands either return -1 for errors, regardless of the error
>>> type, or 0 for success.
>>>>
>>>>> + */
>>>>> + if (fw_err >= 0)
>>>>> + return 0;
>>>>> +
>>>>> + if (fw_err == -1)
>>>>> + return -EACCES;
>>>>> +
>>>>> + return -EIO;
>>>>> +}
>>>>
>>>> Could we map these return values with better granularity instead of
>>>> returning -EIO for everything else that is not minus one?
>>>
>>> I think we're good as we are now. The firmware returns either -1 for errors,
>>> zero for success, or BIT(0) and BIT(1) for TMU_INIT to flag some capabilities.
>>> I can't tell if there are other commands that return capabilities as well,
>>> or if there are other capabilities for TMU_INIT, I don't have access to the
>>> firmware code.
>>
>> On Exynos850 I see more than just one returned error codes. I definitely
>> see 0xfe and 0xfd at least. I don't have any data to confirm that ff
>> maps to -1 and fd-s, fe-s to -2,-3 though and what they mean. From my
>
> for these error codes we will return -EIO which is alright. We can have
> a more granular approach depending on the SoC if you want.
>
> For GS101 above is alright, it matches the info I got from the firmware guys.
*sigh*
>> experiments I suspect that 0xfe means that call/msg type is not
>> implemented or not accessible and 0xfd means that passed parameter is
>> wrong or incorrect or not found.
>>
>> I am also not sure that I saw 0xff-s but, well, maybe that needs more
>> experimenting.
>>
> fe and ff will be covered as well by -EIO.
Of course. But it is about propagating the correct error (meaning
exactly "what went wrong") to the other levels and to a user.
My debugging of tmu for e850 would be a bit easier when sending messages
to acpm if I knew that:
-- something went completely bad;
-- specific acpm call is not implemented/not allowed
(but acpm machinery is working);
-- passed argument for acpm call is not correct/not found
(but acpm machinery is working);
Instead all of that I get only -EIO. Couldn't say if it will be helpful
for any other platforms.
> Let's keep this as it is for now, and if you need a more granular approach
> we can differentiate that for e850.
It's quite sad that even on that level ACPM on gs101 differs from ACPM
on E850.
Thinking further about this I'd humbly suggest that even
if (fw_err >= 0)
return 0;
pr_debug_ratelimited("ACPM tmu call returned: %x\n", fw_err);
or pr_debug(...);
if (fw_err == -1)
return -EACCES;
some debug message would do.
Perhaps we need some convertation, for instance as it is done in scmi
code (scmi_to_linux_errno(), scmi_linux_errmap[]). But I don't have any
data for mapping acpm errors to some human meanings.
Up to you.
Thanks,
Alexey
^ permalink raw reply
* Re: [PATCH v2 1/1] ARM: dts: aspeed: santabarbara: Add system monitoring GPIOs
From: Andrew Jeffery @ 2026-05-18 11:22 UTC (permalink / raw)
To: Fred Chen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20260421130344.2751662-2-fredchen.openbmc@gmail.com>
Hi Fred,
On Tue, 2026-04-21 at 21:03 +0800, Fred Chen wrote:
> Add several GPIO expanders to the Santabarbara platform, with ioexp0
> (0x20) configured to aggregate interrupt signals from downstream
> expanders to optimize sideband pin usage.
Can you provide a bit more context? Is this the result of a broader
design change? Or is it a case of adding descriptions of hardware that
was already present in the design?
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Andre Przywara @ 2026-05-18 11:16 UTC (permalink / raw)
To: Alexander Sverdlin, linux-sunxi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <14a7e289ff5ffed8fcd6dcb9b2e8455a1b2c9420.camel@gmail.com>
Hi Alexander,
On 5/17/26 22:38, Alexander Sverdlin wrote:
> Hi Andre,
>
> thanks for the quick feedback!
>
> On Mon, 2026-05-11 at 13:44 +0200, Andre Przywara wrote:
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
>>> @@ -0,0 +1,162 @@
>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>> +/*
>>> + * Copyright (c) 2025 Arm Ltd.
>>
>> Please put your own copyright here, even if that has been largely copied
>> from an existing file.
>>
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "sun50i-a100.dtsi"
>>> +#include "sun50i-a100-cpu-opp.dtsi"
>>> +
>>> +/{
>>> + compatible = "baijie,helper-a133-core",
>>> + "allwinner,sun50i-a100";
>>> +
>>> + aliases {
>>> + serial1 = &uart1; /* BT module */
>>
>> Do we really need an alias for the BT UART? And is the BT module
>> supported already? Then please add a child node to the UART node.
>
> That's the only thing I can do currently regarding BT: stabilize the
> serial enumeration, because UART1 cannot be used for anything else
> except BT module, because this is soldered inside "core" module.
> We can avoid different tty enumeration, should the support for
> BT be implemented in the future...
>
>> Isn't the WiFi/BT module on the SoM? Then please mention and enable MMC1
>> here. Provide the child node for the WiFi chip, even if there is no
>> upstream support in the kernel for it yet.
>
> So both the above BT and the WiFi is AW869A/AIC8800 combo chip, which
> has neither upstream driver, nor [upstream] DT bindings. Even github
> driver for AIC8800 doesn't seem to use DT, therefore it looks quite
> pointless to me at this point to specify anything in the DT for the
> chip which doesn't have the bindings idea even theoretically.
>
> Nothing in the current DT shall block any future work on the AW869A
> support though and the above "aliases" entry shall even guarantee
> unchanged serial enumeration shall such support arise.
Fair enough for not providing DT nodes for those unsupported chips, but
why do we need to force enumeration? For the eventual Bluetooth usage,
the driver will find the respective serial interface by just looking at
its parent interface. IIUC there is nothing referring to ttyS1
explicitly. So we wouldn't really need an alias, would we?
I see that some boards do define an alias, but others with Bluetooth
don't, which I think is the right thing to do. Which name the kernel
comes up with for UART1 shouldn't matter in any way.
>>> +®_aldo1 {
>>
>> What is aldo1 used for, actually? I don't see this referenced anywhere.
>> I guess the kernel turns that off after booting?
>> If you have access to the schematic, please check that. If that's for
>> some peripheral not yet supported, please note the user anyway, ideally
>> by an explaining regulator-name, or by a comment. Also if it's used for
>> any of the required SoC VDD pins. See the Liontron .dts for comparison.
>>
>>> + regulator-always-on;
> ^^^^^^^^^^^^^^^^^^^
> I suppose it's not being switcdhed of because of the above.
> It's used for both PLL supply for the whole SoC + as analog voltage reference
> for LRADC (the buttons you've noticed on the board are connected to
> this ADC via a resistor ladder).
Ah, yeah, somehow missed that line. So as stated below, please use a
descriptive regulator name.
Look at sun55i-a527-cubie-a5e.dts, I think is a more modern example of
how to handle regulators best.
>
>>
>>> +®_aldo2 {
>>> + regulator-always-on;
>>
>> For always-on regulators we definitely need an explanation. Does the
>> board stop booting if you remove this line?
>> Maybe it's for DRAM? Can you say what voltage it is, either from the
>> reset default, or set by the bootloader?
>
> Thanks for the hint! I'll put proper voltages into all regulators +
> comment all the always-on regulators.
Thanks!
>
>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>>> new file mode 100644
>>> index 000000000000..ccbca5d0a40c
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>
>> And you should provide a top level 5V regulator here, to be the root of
>> the regulator tree. Look at reg_vcc5v in the Liontron .dts.
>
> It doesn't look to me as if Liontron had reg_vcc5v as its 5V "root" regulator.
> It seems to be only used for reg_usb1_vbus, while HelperBoard A133 doesn't
> have USB power control. The second issue with Helper/Core split is that
> all PMIC story is inside Core board which has 5V input rail, while HelperBoard
> around it has indeed 12V->5V DCDC regulator (similar to Liontron), but
> putting it in the DT would introduce wierd dependency of the core to the
> HelperBoard which carries it. Do you think it would make sense?
Ah yeah, the Liontron is not the best example, we don't have the full
description there, because this board misses schematics.
So look at sun55i-a527-cubie-a5e.dts instead, which uses the top level
regulator correctly. We didn't traditionally do this with the A64 boards
using the AXP803, and just learned to live with those dummy supplies
created by the kernel, but for new boards we should do better.
Regarding the board/SoM split: You should have a fixed regulator in the
SoM .dtsi reflecting the 5V input pin(s), and then using that as the VIN
supply for the various PMIC rails, as the Cubie A5E does. This would
mimic some barrel connector on a standard board: the voltage is applied
"by the user", externally.
So in this SoM .dtsi node, there is no vin-supply property, but you add
that in the board .dts:
®_vcc5v {
vin-supply = <®_vcc12v5v>;
};
Please come up with some better names than I just did ;-) Maybe
something like reg_vcc5v_som to make this clearer.
And then you have that 12V->5V regulator described in the board .dts,
along with a parent-less 12V regulator, check sun55i-t527-avaota-a1.dts
for an example.
That should work cleanly, I think.
>> So from the pictures I found online it looks like there is an USB-C port
>> labelled "OTG", so can you please add an &usbotg reference here and
>> describe that port.
>
> Nice catch! I've missed the fact usbphy 0 has to be in peripheral mode,
> not host mode. Will rework!
I guess that's the same situation as in the other recent boards using
USB-C: they hardwired it to peripheral mode, although you can use this
as a host port with some tricks, check sun50i-h616-orangepi-zero.dtsi,
and copy this comment, should it apply.
>>> +&usbphy {
>>
>> Are the two USB ports always powered?
>>
>> And anyway, I see a *dual* USB-A socket on the pictures online, in
>> addition to the USB-OTG port. So where does the third USB come from? The
>> A133 only supports one host USB port plus the one OTG port. So is there
>> an USB hub chip on the board?
>
> There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
What do you mean with OTG side hub, exactly? Is there a hub on USB0? How
does this work, then?
Cheers,
Andre
> two USB-A ports are always powered from the board's 12V->5V DCDC, no USB
> load switches.
>>
>
^ permalink raw reply
* Re: [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support
From: Niyas Sait @ 2026-05-18 11:14 UTC (permalink / raw)
To: andre.przywara
Cc: ben.horgan, catalin.marinas, fenghuay, guohanjun, james.morse,
jic23, lenb, linux-acpi, linux-arm-kernel, linux-kernel,
lpieralisi, rafael, reinette.chatre, sudeep.holla, will
In-Reply-To: <20260429141339.3171205-6-andre.przywara@arm.com>
Hi Andre,
On Wed, Apr 29, 2026 at 04:13:39PM +0200, Andre Przywara wrote:
> + msc->pcc_chan = pcc_mbox_request_channel(&msc->pcc_cl,
> + pcc_subspace_id);
> + if (IS_ERR(msc->pcc_chan)) {
> + pr_err("Failed to request MSC PCC channel\n");
> + return (void *)msc->pcc_chan;
> + }
> +
> + if (msc->pcc_chan->shmem_size < MPAM_FB_MAX_MSG_SIZE) {
> + pr_err("MPAM-Fb PCC channel size too small.\n");
> + pcc_mbox_free_channel(msc->pcc_chan);
> + return ERR_PTR(-ENOMEM);
> + }
I think this allocates one PCC channel per MSC instance.
MPAM-Fb spec. allows MPAM manager to support multiple MSCs and does not
require seperate channels per MSC. Each MSC is targeted via its msc_id
in the MPAM_MSC_READ/WRITE commands.
So for systems where multiple MSC nodes point to the same PCC subspace,
should we share one pcc_mbox_chan and serialize requests through it?
Thanks,
Niyas
^ permalink raw reply
* Re: [PATCH 2/2] firmware: samsung: acpm: add Exynos850 support
From: Tudor Ambarus @ 2026-05-18 11:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alexey Klimov, Sam Protsenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar
Cc: Peter Griffin, linux-samsung-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <b1631f32-aafb-46fc-86c8-daff0d6dc2f7@kernel.org>
On 5/18/26 1:46 PM, Krzysztof Kozlowski wrote:
> On 18/05/2026 12:27, Tudor Ambarus wrote:
>>
>>
>> On 5/13/26 2:12 AM, Alexey Klimov wrote:
>>> The Exynos850 SoC contains an APM co-processor. Communication
>>> with this hardware block is established using the ACPM protocol,
>>> which handles IPC messages for clocks, power, thermal management,
>>> and PMIC control.
>>>
>>> Add the "samsung,exynos850-acpm-ipc" compatible string along with
>>> its associated match data. This includes the specific initialisation
>>
>> s/initialisation/initialization
>
> Hoho, careful, that's a quite hot topic :)
:)
> I think we do not have kernel-wide preference here and even if there
> was, no need to resend just for that.
I wasn't aware of the British term (thanks Alexey!) and I already gave
my R-b. No hot topic for me, thought that it's just a typo.
Cheers,
ta
^ permalink raw reply
* [PATCH] usb: typec: Use named initializers for arrays of i2c_device_data
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-18 11:01 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman
Cc: Hans de Goede, Badhri Jagan Sridharan, Maxime Coquelin,
Alexandre Torgue, Sebastian Reichel, Yongbo Zhang,
Thomas Gleixner, Alexey Charkov, Sebastian Andrzej Siewior,
André Draszik, Amit Sunil Dhamne, Yuanshen Cao, Sven Peter,
Neal Gompa, Hector Martin, Ethan Tidmore, Peter Korsgaard,
Andrew Morton, Johan Hovold, Randy Dunlap, Pooja Katiyar,
Dmitry Baryshkov, Thorsten Blum, linux-usb, linux-kernel,
linux-stm32, linux-arm-kernel
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
The mentioned robustness is relevant for a planned change to struct
i2c_device_id that replaces .driver_data by an anonymous union.
While touching all these arrays, unify usage of whitespace in the list
terminator.
This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
the mentioned change to i2c_device_id is the following:
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 23ff24080dfd..aebd3a5e90af 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -477,7 +477,11 @@ struct rpmsg_device_id {
struct i2c_device_id {
char name[I2C_NAME_SIZE];
- kernel_ulong_t driver_data; /* Data private to the driver */
+ union {
+ /* Data private to the driver */
+ kernel_ulong_t driver_data;
+ const void *driver_data_ptr;
+ };
};
/* pci_epf */
and this requires that .driver_data is assigned via a named initializer
for static data. This requirement isn't a bad one because named
initializers are also much better readable than list initializers.
The union added to struct i2c_device_id enables further cleanups like:
diff --git a/drivers/regulator/ad5398.c b/drivers/regulator/ad5398.c
index 0123ca8157a8..dfb0b07500a7 100644
--- a/drivers/regulator/ad5398.c
+++ b/drivers/regulator/ad5398.c
@@ -207,8 +207,8 @@ struct ad5398_current_data_format {
static const struct ad5398_current_data_format df_10_4_120 = {10, 4, 0, 120000};
static const struct i2c_device_id ad5398_id[] = {
- { .name = "ad5398", .driver_data = (kernel_ulong_t)&df_10_4_120 },
- { .name = "ad5821", .driver_data = (kernel_ulong_t)&df_10_4_120 },
+ { .name = "ad5398", .driver_data_ptr = &df_10_4_120 },
+ { .name = "ad5821", .driver_data_ptr = &df_10_4_120 },
{ }
};
MODULE_DEVICE_TABLE(i2c, ad5398_id);
@@ -219,8 +219,7 @@ static int ad5398_probe(struct i2c_client *client)
struct regulator_init_data *init_data = dev_get_platdata(&client->dev);
struct regulator_config config = { };
struct ad5398_chip_info *chip;
- const struct ad5398_current_data_format *df =
- (struct ad5398_current_data_format *)id->driver_data;
+ const struct ad5398_current_data_format *df = id->driver_data;
chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
that are an improvement for readability (again!) and it keeps some
properties of the pointers (here: being const) without having to pay
attention for that. (I didn't find a usb driver that benefits, so this
is "only" a regulator driver example.)
My additional motivation for this effort is CHERI[1]. This is a hardware
extension that uses 128 bit pointers but unsigned long is still 64 bit.
So with CHERI you cannot store pointers in unsigned long variables.
Best regards
Uwe
[1] https://cheri-alliance.org/discover-cheri/
https://lwn.net/Articles/1037974/
drivers/usb/typec/anx7411.c | 4 ++--
drivers/usb/typec/mux/fsa4480.c | 2 +-
drivers/usb/typec/mux/it5205.c | 2 +-
drivers/usb/typec/mux/nb7vpq904m.c | 2 +-
drivers/usb/typec/mux/pi3usb30532.c | 2 +-
drivers/usb/typec/mux/ptn36502.c | 2 +-
drivers/usb/typec/mux/wcd939x-usbss.c | 2 +-
drivers/usb/typec/tcpm/fusb302.c | 4 ++--
drivers/usb/typec/tcpm/tcpci.c | 2 +-
drivers/usb/typec/tcpm/tcpci_maxim_core.c | 2 +-
drivers/usb/typec/tcpm/tcpci_rt1711h.c | 8 ++++----
drivers/usb/typec/tipd/core.c | 2 +-
drivers/usb/typec/ucsi/ucsi_ccg.c | 4 ++--
drivers/usb/typec/ucsi/ucsi_stm32g0.c | 4 ++--
14 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/typec/anx7411.c b/drivers/usb/typec/anx7411.c
index 2e8ae1d2faf9..604868ebf422 100644
--- a/drivers/usb/typec/anx7411.c
+++ b/drivers/usb/typec/anx7411.c
@@ -1577,8 +1577,8 @@ static void anx7411_i2c_remove(struct i2c_client *client)
}
static const struct i2c_device_id anx7411_id[] = {
- { "anx7411" },
- {}
+ { .name = "anx7411" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, anx7411_id);
diff --git a/drivers/usb/typec/mux/fsa4480.c b/drivers/usb/typec/mux/fsa4480.c
index c54e42c7e6a1..bea0c1deec94 100644
--- a/drivers/usb/typec/mux/fsa4480.c
+++ b/drivers/usb/typec/mux/fsa4480.c
@@ -336,7 +336,7 @@ static void fsa4480_remove(struct i2c_client *client)
}
static const struct i2c_device_id fsa4480_table[] = {
- { "fsa4480" },
+ { .name = "fsa4480" },
{ }
};
MODULE_DEVICE_TABLE(i2c, fsa4480_table);
diff --git a/drivers/usb/typec/mux/it5205.c b/drivers/usb/typec/mux/it5205.c
index 4357cc67a867..5e1a120b2e3b 100644
--- a/drivers/usb/typec/mux/it5205.c
+++ b/drivers/usb/typec/mux/it5205.c
@@ -266,7 +266,7 @@ static void it5205_remove(struct i2c_client *client)
}
static const struct i2c_device_id it5205_table[] = {
- { "it5205" },
+ { .name = "it5205" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(i2c, it5205_table);
diff --git a/drivers/usb/typec/mux/nb7vpq904m.c b/drivers/usb/typec/mux/nb7vpq904m.c
index b57b6c9c40fe..d1fa26ff442c 100644
--- a/drivers/usb/typec/mux/nb7vpq904m.c
+++ b/drivers/usb/typec/mux/nb7vpq904m.c
@@ -499,7 +499,7 @@ static void nb7vpq904m_remove(struct i2c_client *client)
}
static const struct i2c_device_id nb7vpq904m_table[] = {
- { "nb7vpq904m" },
+ { .name = "nb7vpq904m" },
{ }
};
MODULE_DEVICE_TABLE(i2c, nb7vpq904m_table);
diff --git a/drivers/usb/typec/mux/pi3usb30532.c b/drivers/usb/typec/mux/pi3usb30532.c
index 8eeec135dcdb..985683fe49e9 100644
--- a/drivers/usb/typec/mux/pi3usb30532.c
+++ b/drivers/usb/typec/mux/pi3usb30532.c
@@ -169,7 +169,7 @@ static void pi3usb30532_remove(struct i2c_client *client)
}
static const struct i2c_device_id pi3usb30532_table[] = {
- { "pi3usb30532" },
+ { .name = "pi3usb30532" },
{ }
};
MODULE_DEVICE_TABLE(i2c, pi3usb30532_table);
diff --git a/drivers/usb/typec/mux/ptn36502.c b/drivers/usb/typec/mux/ptn36502.c
index 129d9d24b932..afd16775dbaf 100644
--- a/drivers/usb/typec/mux/ptn36502.c
+++ b/drivers/usb/typec/mux/ptn36502.c
@@ -404,7 +404,7 @@ static void ptn36502_remove(struct i2c_client *client)
}
static const struct i2c_device_id ptn36502_table[] = {
- { "ptn36502" },
+ { .name = "ptn36502" },
{ }
};
MODULE_DEVICE_TABLE(i2c, ptn36502_table);
diff --git a/drivers/usb/typec/mux/wcd939x-usbss.c b/drivers/usb/typec/mux/wcd939x-usbss.c
index d46c353dfaf2..73db3aa3cec4 100644
--- a/drivers/usb/typec/mux/wcd939x-usbss.c
+++ b/drivers/usb/typec/mux/wcd939x-usbss.c
@@ -753,7 +753,7 @@ static void wcd939x_usbss_remove(struct i2c_client *client)
}
static const struct i2c_device_id wcd939x_usbss_table[] = {
- { "wcd9390-usbss" },
+ { .name = "wcd9390-usbss" },
{ }
};
MODULE_DEVICE_TABLE(i2c, wcd939x_usbss_table);
diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c
index 889c4c29c1b8..6560da0c523b 100644
--- a/drivers/usb/typec/tcpm/fusb302.c
+++ b/drivers/usb/typec/tcpm/fusb302.c
@@ -1841,8 +1841,8 @@ static const struct of_device_id fusb302_dt_match[] __maybe_unused = {
MODULE_DEVICE_TABLE(of, fusb302_dt_match);
static const struct i2c_device_id fusb302_i2c_device_id[] = {
- { "typec_fusb302" },
- {}
+ { .name = "typec_fusb302" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, fusb302_i2c_device_id);
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index 0148b8f50412..8841a94df153 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -1020,7 +1020,7 @@ static int tcpci_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(tcpci_pm_ops, tcpci_suspend, tcpci_resume);
static const struct i2c_device_id tcpci_id[] = {
- { "tcpci" },
+ { .name = "tcpci" },
{ }
};
MODULE_DEVICE_TABLE(i2c, tcpci_id);
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim_core.c b/drivers/usb/typec/tcpm/tcpci_maxim_core.c
index c0ee7e6959ed..6ceb25e5bdd0 100644
--- a/drivers/usb/typec/tcpm/tcpci_maxim_core.c
+++ b/drivers/usb/typec/tcpm/tcpci_maxim_core.c
@@ -570,7 +570,7 @@ static int max_tcpci_suspend(struct device *dev)
static SIMPLE_DEV_PM_OPS(max_tcpci_pm_ops, max_tcpci_suspend, max_tcpci_resume);
static const struct i2c_device_id max_tcpci_id[] = {
- { "maxtcpc" },
+ { .name = "maxtcpc" },
{ }
};
MODULE_DEVICE_TABLE(i2c, max_tcpci_id);
diff --git a/drivers/usb/typec/tcpm/tcpci_rt1711h.c b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
index 4b3e4e22a82e..a8726da6fc71 100644
--- a/drivers/usb/typec/tcpm/tcpci_rt1711h.c
+++ b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
@@ -373,10 +373,10 @@ static const struct rt1711h_chip_info rt1715 = {
};
static const struct i2c_device_id rt1711h_id[] = {
- { "et7304", (kernel_ulong_t)&rt1715 },
- { "rt1711h", (kernel_ulong_t)&rt1711h },
- { "rt1715", (kernel_ulong_t)&rt1715 },
- {}
+ { .name = "et7304", .driver_data = (kernel_ulong_t)&rt1715 },
+ { .name = "rt1711h", .driver_data = (kernel_ulong_t)&rt1711h },
+ { .name = "rt1715", .driver_data = (kernel_ulong_t)&rt1715 },
+ { }
};
MODULE_DEVICE_TABLE(i2c, rt1711h_id);
diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c
index 43faec794b95..f560606c588c 100644
--- a/drivers/usb/typec/tipd/core.c
+++ b/drivers/usb/typec/tipd/core.c
@@ -2027,7 +2027,7 @@ static const struct of_device_id tps6598x_of_match[] = {
MODULE_DEVICE_TABLE(of, tps6598x_of_match);
static const struct i2c_device_id tps6598x_id[] = {
- { "tps6598x", (kernel_ulong_t)&tps6598x_data },
+ { .name = "tps6598x", .driver_data = (kernel_ulong_t)&tps6598x_data },
{ }
};
MODULE_DEVICE_TABLE(i2c, tps6598x_id);
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c b/drivers/usb/typec/ucsi/ucsi_ccg.c
index 199799b319c2..ddde0a7702f0 100644
--- a/drivers/usb/typec/ucsi/ucsi_ccg.c
+++ b/drivers/usb/typec/ucsi/ucsi_ccg.c
@@ -1525,8 +1525,8 @@ static const struct of_device_id ucsi_ccg_of_match_table[] = {
MODULE_DEVICE_TABLE(of, ucsi_ccg_of_match_table);
static const struct i2c_device_id ucsi_ccg_device_id[] = {
- { "ccgx-ucsi" },
- {}
+ { .name = "ccgx-ucsi" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, ucsi_ccg_device_id);
diff --git a/drivers/usb/typec/ucsi/ucsi_stm32g0.c b/drivers/usb/typec/ucsi/ucsi_stm32g0.c
index 838ac0185082..848ed459a6de 100644
--- a/drivers/usb/typec/ucsi/ucsi_stm32g0.c
+++ b/drivers/usb/typec/ucsi/ucsi_stm32g0.c
@@ -737,8 +737,8 @@ static const struct of_device_id __maybe_unused ucsi_stm32g0_typec_of_match[] =
MODULE_DEVICE_TABLE(of, ucsi_stm32g0_typec_of_match);
static const struct i2c_device_id ucsi_stm32g0_typec_i2c_devid[] = {
- { "stm32g0-typec" },
- {}
+ { .name = "stm32g0-typec" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, ucsi_stm32g0_typec_i2c_devid);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 4/5] arm_mpam: prevent MPAM-Fb accesses inside IRQ handler
From: Niyas Sait @ 2026-05-18 10:57 UTC (permalink / raw)
To: andre.przywara
Cc: ben.horgan, catalin.marinas, fenghuay, guohanjun, james.morse,
jic23, lenb, linux-acpi, linux-arm-kernel, linux-kernel,
lpieralisi, rafael, reinette.chatre, sudeep.holla, will
In-Reply-To: <20260429141339.3171205-5-andre.przywara@arm.com>
Hi Andre,
On Wed, Apr 29, 2026 at 04:13:38PM +0200, Andre Przywara wrote:
> This error report relies on reading the MSC's error status register
> (ESR) in the IRQ handler, which is not possible for MPAM-Fb based
> MSC accesses, since they involve mailbox routines that might sleep.
I think there are a few other places where we may still end up invoking
the MPAM-Fb path from atomic/IRQ context.
For example, _msmon_read() uses smp_call_function_any(), which runs
__ris_msmon_read() in callback/atomic context
static int _msmon_read(struct mpam_component *comp, struct mon_read *arg)
{
...
err = smp_call_function_any(&msc->accessibility,
__ris_msmon_read, arg,
true);
...
}
For MPAM-Fb, I think we could potentially avoid the smp_call_function_any() path entirely
and invoke directly from the current CPU. Since PCC accesses are effectively CPU agnostic,
I think that should be fine for the MPAM-Fb case.
Thanks,
Niyas
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: arm: aspeed: Add ASRock Rack B650D4U
From: Krzysztof Kozlowski @ 2026-05-18 10:57 UTC (permalink / raw)
To: Prasanth Kumar Padarthi
Cc: joel, andrew, robh, krzk+dt, conor+dt, andrew+netdev, devicetree,
linux-aspeed, linux-arm-kernel
In-Reply-To: <20260518033440.17569-2-prasanth.padarthi10@gmail.com>
On Mon, May 18, 2026 at 09:04:39AM +0530, Prasanth Kumar Padarthi wrote:
> Add the compatible string for the ASRock Rack B650D4U BMC,
> which is an AST2600-based server motherboard.
>
> Signed-off-by: Prasanth Kumar Padarthi <prasanth.padarthi10@gmail.com>
> ---
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here. However, there's no
need to repost patches *only* to add the tags. The upstream maintainer
will do that for tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state in the patch changelog
or cover letter why and what changed.
</form letter>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] media: rkvdec: fix PM runtime teardown ordering in remove
From: Francesco Saverio Pavone @ 2026-05-18 10:54 UTC (permalink / raw)
To: jonas, detlev.casanova, nicolas.dufresne, hverkuil, mchehab
Cc: ezequiel, heiko, linux-media, linux-rockchip, linux-arm-kernel,
linux-kernel
From: Jonas Karlman <jonas@kwiboo.se>
The current remove() path calls rkvdec_v4l2_cleanup() and
pm_runtime_disable() before pm_runtime_dont_use_autosuspend(), and
frees the empty IOMMU domain after that. With autosuspend still
armed when the domain goes away, the VDPU381 can be left in a dirty
state across module reload and suspend/resume cycles.
On RK3588 this surfaces as a VP9 inter-prediction bug: from the
second ALTREF frame onward, motion blocks decode with U=V=0 (BT.709
green), while intra and static blocks stay correct. Reordering the
teardown to dont_use_autosuspend() -> iommu_domain_free() ->
pm_runtime_disable() -> v4l2_cleanup() makes the symptom go away.
Tested on a Radxa Rock 5B+ (RK3588, 8 GB LPDDR5) with both the
libva-v4l2-request mpv pipeline and Chromium's V4L2 stateless
decoder. With the fix, 300 random pixel samples on VP9 Profile 0
clips at 1080p and 1440p match a libvpx software reference exactly
(worst delta 0). Without it, the same 1080p sample at frame 4,
pixel (960, 270) reads HW=(0,112,0) vs SW=(204,147,116). HEVC and
H.264 stateless decoding via mpv keep running on hardware with no
fallback.
Fixes: ff8c5622f9f7 ("media: rkvdec: Restore iommu addresses on errors")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com>
Signed-off-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com>
---
drivers/media/platform/rockchip/rkvdec/rkvdec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
index 6f5f0422d317..bb95b090a25b 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
@@ -2066,12 +2066,13 @@ static void rkvdec_remove(struct platform_device *pdev)
cancel_delayed_work_sync(&rkvdec->watchdog_work);
- rkvdec_v4l2_cleanup(rkvdec);
- pm_runtime_disable(&pdev->dev);
pm_runtime_dont_use_autosuspend(&pdev->dev);
if (rkvdec->empty_domain)
iommu_domain_free(rkvdec->empty_domain);
+
+ pm_runtime_disable(&pdev->dev);
+ rkvdec_v4l2_cleanup(rkvdec);
}
#ifdef CONFIG_PM
--
2.45.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox