* Re: [PATCH v8 6/9] input: keyboard: mtk-pmic-keys: Add MT6392 support
From: sashiko-bot @ 2026-06-20 20:16 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: devicetree, robh, dmitry.torokhov, linux-input, conor+dt
In-Reply-To: <20260620200032.334192-7-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Incorrect reset bitmask used for MT6357 home key, causing register corruption.
--
commit 1b3cefe34c0ab03bf79d61642de046924d4afa84
Author: Val Packett <val@packett.cool>
input: keyboard: mtk-pmic-keys: Add MT6392 support
Add support for the MT6392 PMIC to the keys driver.
> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
> index c78d9f6d97c4f..8b4a89fce4fb1 100644
> --- a/drivers/input/keyboard/mtk-pmic-keys.c
> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
[ ... ]
> @@ -69,6 +70,19 @@ static const struct mtk_pmic_regs mt6397_regs = {
> .rst_lprst_mask = MTK_PMIC_RST_DU_MASK,
> };
>
> +static const struct mtk_pmic_regs mt6392_regs = {
> + .keys_regs[MTK_PMIC_PWRKEY_INDEX] =
> + MTK_PMIC_KEYS_REGS(MT6392_CHRSTATUS, 0x2,
> + MT6392_INT_MISC_CON, 0x10,
> + MTK_PMIC_PWRKEY_RST),
> + .keys_regs[MTK_PMIC_HOMEKEY_INDEX] =
> + MTK_PMIC_KEYS_REGS(MT6392_CHRSTATUS, 0x4,
> + MT6392_INT_MISC_CON, 0x8,
> + MTK_PMIC_HOMEKEY_RST),
[Severity: High]
This is a pre-existing issue, but while reviewing these new register
configurations I noticed a copy-paste typo in the mt6357_regs struct.
In mt6357_regs, the home key reset mask is initialized like this:
.keys_regs[MTK_PMIC_HOMEKEY_INDEX] =
MTK_PMIC_KEYS_REGS(MT6357_TOPSTATUS,
0x8, MT6357_PSC_TOP_INT_CON0, 0xa,
MTK_PMIC_HOMEKEY_INDEX),
Does this incorrectly use the array index MTK_PMIC_HOMEKEY_INDEX instead of
the reset bitmask MTK_PMIC_HOMEKEY_RST?
When mtk_pmic_keys_lp_reset_setup() is called during probe for an MT6357
device, wouldn't this inadvertently modify bit 0 of the MT6357_TOP_RST_MISC
register instead of bit 5?
It looks like this might corrupt an unrelated control bit in the PMIC register
state, while also failing to manage the long-press reset functionality for the
home key.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260620200032.334192-1-l.scorcia@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v8 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: sashiko-bot @ 2026-06-20 20:19 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-input, dmitry.torokhov, robh, conor+dt, devicetree
In-Reply-To: <20260620200032.334192-10-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `pmic` node lacks an upstream `interrupts` or `interrupts-extended` property, causing the MT6397/MT6392 PMIC driver to fail probing.
--
commit fc85085e7df96d6b701cb80ab653d3bbb4392af1
Author: Val Packett <val@packett.cool>
arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
Add the dtsi to be included by all boards using the MT6392 PMIC,
providing support for regulator, keys, pinctrl and RTC. Import the new
file in the shared device tree for the Pumpkin boards.
> diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> new file mode 100644
> index 0000000000000..19321ae010bba
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> @@ -0,0 +1,148 @@
[ ... ]
> +&pwrap {
> + pmic: pmic {
> + compatible = "mediatek,mt6392", "mediatek,mt6323";
> + interrupt-controller;
> + #interrupt-cells = <2>;
[ ... ]
> diff --git a/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi b/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
> index 805fb82138a80..6bc80924cb6cf 100644
> --- a/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
> @@ -6,6 +6,8 @@
>
> #include <dt-bindings/gpio/gpio.h>
>
> +#include "mt6392.dtsi"
> +
[Severity: High]
Does this inclusion miss the board-specific interrupts definition for the PMIC?
The new mt6392.dtsi defines the pmic node but omits the interrupts property,
as expected for a generic include. However, pumpkin-common.dtsi doesn't appear
to override the &pmic node to provide the board-specific interrupt routing.
Since the MT6397 PMIC core driver aborts probing completely if it cannot find
an interrupt via platform_get_irq(pdev, 0), will this cause the PMIC driver to
fail probing, leaving all PMIC sub-devices unavailable?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260620200032.334192-1-l.scorcia@gmail.com?part=9
^ permalink raw reply
* Re: [PATCH v8 5/9] mfd: mt6397: Add support for MT6392 PMIC
From: sashiko-bot @ 2026-06-20 20:20 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: conor+dt, devicetree, linux-input, dmitry.torokhov, robh
In-Reply-To: <20260620200032.334192-6-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing unregister_pm_notifier() causes Use-After-Free of PM notifier block on probe error and driver unbind.
- [High] The IRQ domain is created with a hardcoded size of MT6397_IRQ_NR (32), which breaks PMICs like MT6328 that use a third interrupt register (hwirqs 32-47).
- [High] `mt6397_irq_pm_notifier` modifies IRQ mask registers concurrently with running tasks, causing race conditions.
--
commit 15d5fe2891c82970874377c126d0244fd87f5699
Author: Fabien Parent <parent.f@gmail.com>
mfd: mt6397: Add support for MT6392 PMIC
Align the MT6397 PMIC driver to other MFD drivers by passing only an
identifier through mt6397_of_match[*].data and add support for the MT6392
PMIC and its regulator, RTC, keys and pinctrl devices.
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index ccd97d66d7f1c..f683e878543e1 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
[ ... ]
> @@ -278,6 +311,7 @@ static int mt6397_probe(struct platform_device *pdev)
> unsigned int id = 0;
> struct mt6397_chip *pmic;
> const struct chip_data *pmic_core;
> + int chip_variant;
>
> pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
> if (!pmic)
> @@ -293,9 +327,36 @@ static int mt6397_probe(struct platform_device *pdev)
> if (!pmic->regmap)
> return -ENODEV;
>
> - pmic_core = of_device_get_match_data(&pdev->dev);
> - if (!pmic_core)
> + chip_variant = (unsigned int)(uintptr_t)device_get_match_data(&pdev->dev);
> + switch (chip_variant) {
[ ... ]
> + case MT6392_CHIP_ID:
> + pmic_core = &mt6392_core;
> + break;
[ ... ]
[Severity: High]
This isn't a bug introduced by this patch, but looking at the error path of
mt6397_probe() in drivers/mfd/mt6397-core.c:
ret = pmic_core->irq_init(pmic);
if (ret)
return ret;
ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE,
pmic_core->cells, pmic_core->cell_size,
NULL, 0, pmic->irq_domain);
if (ret) {
irq_domain_remove(pmic->irq_domain);
dev_err(&pdev->dev, "failed to add child devices: %d\n", ret);
}
return ret;
Since mt6397_irq_init() registers a PM notifier with register_pm_notifier(),
if devm_mfd_add_devices() fails (or when the driver is unbound), the devres
cleanup will automatically free the pmic structure containing the pm_nb
notifier block.
Because unregister_pm_notifier() is never called in this error path or in a
remove callback, will this leave a dangling pointer in the PM subsystem that
causes a Use-After-Free during the next suspend/resume cycle?
> diff --git a/drivers/mfd/mt6397-irq.c b/drivers/mfd/mt6397-irq.c
> index 5d2e5459f7444..80ea5b92d232f 100644
> --- a/drivers/mfd/mt6397-irq.c
> +++ b/drivers/mfd/mt6397-irq.c
[ ... ]
> @@ -203,6 +205,12 @@ int mt6397_irq_init(struct mt6397_chip *chip)
> chip->int_status[0] = MT6397_INT_STATUS0;
> chip->int_status[1] = MT6397_INT_STATUS1;
> break;
> + case MT6392_CHIP_ID:
> + chip->int_con[0] = MT6392_INT_CON0;
> + chip->int_con[1] = MT6392_INT_CON1;
> + chip->int_status[0] = MT6392_INT_STATUS0;
> + chip->int_status[1] = MT6392_INT_STATUS1;
> + break;
>
> default:
> dev_err(chip->dev, "unsupported chip: 0x%x\n", chip->chip_id);
[Severity: High]
This is a pre-existing issue, but further down in mt6397_irq_init() in
drivers/mfd/mt6397-irq.c, the linear IRQ domain is allocated with a hardcoded
size:
chip->irq_domain = irq_domain_create_linear(dev_fwnode(chip->dev), MT6397_IRQ_NR,
&mt6397_irq_domain_ops, chip);
Since MT6397_IRQ_NR is 32, but PMICs like MT6328 use a third interrupt
status register for hardware IRQs 32-47:
if (mt6397->int_status[2])
mt6397_irq_handle_reg(mt6397, mt6397->int_status[2], 32);
Won't irq_find_mapping() silently fail to find a mapping for any interrupts
at index 32 or higher, breaking functionality for those higher-numbered
interrupts?
[Severity: High]
This is also a pre-existing issue, but mt6397_irq_pm_notifier() in
drivers/mfd/mt6397-irq.c writes directly to the PMIC's interrupt control
registers without locking:
case PM_SUSPEND_PREPARE:
regmap_write(chip->regmap,
chip->int_con[0], chip->wake_mask[0]);
Because PM_SUSPEND_PREPARE runs before user tasks are frozen, running tasks
can concurrently request or enable an IRQ. When this happens,
mt6397_irq_sync_unlock() will acquire irqlock and write irq_masks_cur
to the same registers:
regmap_write(mt6397->regmap, mt6397->int_con[0],
mt6397->irq_masks_cur[0]);
Could this concurrent modification overwrite the suspend configuration
established by the notifier, leading to lost wakeup sources or spurious
interrupts?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260620200032.334192-1-l.scorcia@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v6 14/21] RISC-V: perf: Skip PMU SBI extension when not implemented
From: Atish Patra @ 2026-06-20 23:15 UTC (permalink / raw)
To: sashiko-reviews; +Cc: devicetree, linux-perf-users, robh, conor+dt, linux-riscv
In-Reply-To: <20260609063329.66D801F00893@smtp.kernel.org>
On 6/8/26 11:33 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> Pre-existing issues:
> - [Critical] Missing perf_pmu_unregister() on error paths leads to Use-After-Free of the pmu struct.
> - [High] Unconditional cpuhp_state_remove_instance() on an uninitialized hlist_node causes a kernel panic.
> --
>
> commit bd51c5655be0902a2fc1fd90b8d692c299e7265b
> Author: Charlie Jenkins <charlie@rivosinc.com>
>
> RISC-V: perf: Skip PMU SBI extension when not implemented
>
> When the PMU SBI extension is not implemented, sbi_v2_available should
> not be set to true. The SBI implementation for counter config matching
> and firmware counter read should also be skipped when the SBI extension
> is not implemented.
+linux-riscv
>> diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
>> index 1f16df9d0dd00..5bfcd3821f572 100644
>> --- a/drivers/perf/riscv_pmu_sbi.c
>> +++ b/drivers/perf/riscv_pmu_sbi.c
> [ ... ]
>> @@ -2045,12 +2052,13 @@ static int __init rvpmu_devinit(void)
>> int ret;
>> struct platform_device *pdev;
>>
>> - if (sbi_spec_version >= sbi_mk_version(0, 3) &&
>> - sbi_probe_extension(SBI_EXT_PMU))
>> - static_branch_enable(&riscv_pmu_sbi_available);
>> + if (sbi_probe_extension(SBI_EXT_PMU)) {
>> + if (sbi_spec_version >= sbi_mk_version(0, 3))
>> + static_branch_enable(&riscv_pmu_sbi_available);
>> + if (sbi_spec_version >= sbi_mk_version(2, 0))
>> + sbi_v2_available = true;
>> + }
>>
>> - if (sbi_spec_version >= sbi_mk_version(2, 0))
>> - sbi_v2_available = true;
>> /*
>> * We need all three extensions to be present to access the counters
>> * in S-mode via Supervisor Counter delegation.
> [Severity: Critical]
> This is a pre-existing issue, but I noticed a potential use-after-free in the
> error handling path of rvpmu_device_probe() when allocating or registering
> fails after perf_pmu_register() succeeds.
>
> If an error occurs, such as pmu_sbi_snapshot_alloc() failing, the code jumps
> to out_unregister:
>
> out_unregister:
> riscv_pmu_destroy(pmu);
>
> out_free:
> kfree(pmu);
> return ret;
>
> However, neither the error path nor riscv_pmu_destroy() calls
> perf_pmu_unregister(&pmu->pmu).
>
> This leaves the PMU registered in the perf core subsystem while its backing
> memory is freed via kfree(). Any subsequent access to the PMU could result
> in a use-after-free.
>
> Should perf_pmu_unregister() be called during teardown to avoid memory
> corruption?
Yes. Same comment as other patches. Fixed.
> [Severity: High]
> This is a pre-existing issue, but the error teardown path in
> rvpmu_device_probe() seems to have a bug that could trigger a kernel panic.
>
> If rvpmu_device_probe() fails before successfully calling
> cpuhp_state_add_instance(), it jumps to out_unregister and calls
> riscv_pmu_destroy(pmu).
>
> Inside riscv_pmu_destroy(), it unconditionally removes the hotplug instance:
>
> static void riscv_pmu_destroy(struct riscv_pmu *pmu)
> {
> ...
> cpuhp_state_remove_instance(CPUHP_AP_PERF_RISCV_STARTING, &pmu->node);
> }
>
> Because the pmu struct is allocated with kzalloc() and the node hasn't been
> added to the hotplug list yet, its hlist_node is zero-initialized.
>
> When hlist_del() is called internally by cpuhp_state_remove_instance(), it
> attempts to dereference node->pprev (which is NULL), causing a NULL pointer
> dereference.
>
> Would it be better to check if the node is actually hashed before attempting
> to remove the hotplug instance?
Fixed in v7.
^ permalink raw reply
* Re: [PATCH v6 13/21] RISC-V: perf: Implement supervisor counter delegation support
From: Atish Patra @ 2026-06-20 23:25 UTC (permalink / raw)
To: sashiko-reviews; +Cc: devicetree, robh, conor+dt, linux-perf-users, linux-riscv
In-Reply-To: <20260609062339.F223A1F00893@smtp.kernel.org>
On 6/8/26 11:23 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> - [High] Bitwise shift of signed 32-bit integer causes overflow and corrupts SCOUNTINHIBIT on 64-bit systems.
> - [High] Non-sampling events are permanently inhibited from counting because HPMEVENT_OF is unconditionally set but never cleared.
> - [High] On 32-bit architectures, `rvpmu_deleg_ctr_enable_irq` writes modified event configuration to the wrong CSR (`CSR_SIREG4` instead of `CSR_SIREG5`).
> - [High] SBI PMU snapshot logic breaks supervisor counter delegation by unconditionally bypassing S-mode CSR writes and reading stale shared memory.
> --
>
> commit ff1e171673cfe94a12c443765bd5b68dacf3b687
> Author: Atish Patra <atishp@rivosinc.com>
>
> RISC-V: perf: Implement supervisor counter delegation support
>
> This patch adds support for RISC-V ISA extensions (ssccfg, sscsrind,
> smcntrpmf) that allow programming hpmcounters directly from S-mode.
> It falls back to the SBI PMU extension if the hardware extensions are
> unavailable or for firmware counters.
>
>> diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
>> index 46a25979e95e9..1f16df9d0dd00 100644
>> --- a/drivers/perf/riscv_pmu_sbi.c
>> +++ b/drivers/perf/riscv_pmu_sbi.c
> [ ... ]
>
>> -static u64 rvpmu_sbi_ctr_read(struct perf_event *event)
>> +static u64 rvpmu_ctr_read(struct perf_event *event)
>> {
>> struct hw_perf_event *hwc = &event->hw;
>> int idx = hwc->idx;
> [Severity: High]
> Does this function still read stale data from the SBI shared memory when
> using supervisor counter delegation?
>
> If a platform supports both SBI PMU snapshots and S-mode counter delegation,
That's not a likely scenario as S-mode counter delegation is not
available for VS mode.
> the code unconditionally reads from the SBI shared memory for stopped
> hardware counters. Since S-mode counters are stopped via direct CSR writes,
> the SBI firmware is bypassed and the shared memory is never updated.
>
> [ ... ]
>
>> +static void rvpmu_deleg_ctr_enable_irq(struct perf_event *event)
>> +{
>> + unsigned long hpmevent_curr;
>> + unsigned long of_mask;
>> + struct hw_perf_event *hwc = &event->hw;
>> + int counter_idx = hwc->idx;
>> + unsigned long sip_val = csr_read(CSR_SIP);
>> +
>> + if (!is_sampling_event(event) || (sip_val & SIP_LCOFIP))
>> + return;
> [Severity: High]
> Will this early return cause non-sampling events to never be counted?
>
> In update_deleg_hpmevent(), the HPMEVENT_OF bit is unconditionally set for
> all events. The Sscofpmf specification states a counter does not increment
> while its OF bit is 1. If we return early here for non-sampling events
> (like perf stat), the OF bit is never cleared, which would leave these
> counters permanently inhibited.
N/A. Incorrect spec understanding.
Sscofpmf's OF bit gates the LCOFI interrupt only. it does NOT stop the
counter.
>>
>> - /* Reinitialize and start all the counter that overflowed */
>> - while (ctr_ovf_mask) {
>> - if (ctr_ovf_mask & 0x01) {
>> - event = cpu_hw_evt->events[idx];
>> - hwc = &event->hw;
>> - max_period = riscv_pmu_ctr_get_width_mask(event);
>> - init_val = local64_read(&hwc->prev_count) & max_period;
>> #if defined(CONFIG_32BIT)
>> - sbi_ecall(SBI_EXT_PMU, SBI_EXT_PMU_COUNTER_START, idx, 1,
>> - flag, init_val, init_val >> 32, 0);
>> + hpmevent_curr = csr_ind_read(CSR_SIREG5, SISELECT_SSCCFG_BASE, counter_idx);
>> + of_mask = (u32)~HPMEVENTH_OF;
>> #else
>> - sbi_ecall(SBI_EXT_PMU, SBI_EXT_PMU_COUNTER_START, idx, 1,
>> - flag, init_val, 0, 0);
>> + hpmevent_curr = csr_ind_read(CSR_SIREG2, SISELECT_SSCCFG_BASE, counter_idx);
>> + of_mask = ~HPMEVENT_OF;
>> #endif
>> - perf_event_update_userpage(event);
>> - }
>> - ctr_ovf_mask = ctr_ovf_mask >> 1;
>> - idx++;
>> - }
>> +
>> + hpmevent_curr &= of_mask;
>> +#if defined(CONFIG_32BIT)
>> + csr_ind_write(CSR_SIREG4, SISELECT_SSCCFG_BASE, counter_idx, hpmevent_curr);
> [Severity: High]
> Is this writing the event configuration to the wrong CSR?
>
> The code reads the high 32 bits of the event configuration from CSR_SIREG5
> and clears the HPMEVENTH_OF bit, but it writes the modified value back to
> CSR_SIREG4. Since CSR_SIREG4 maps to hpmcounterh, this might overwrite the
> running counter's upper 32 bits with the event configuration value instead
> of clearing the OF bit in the hpmevent register.
Good catch. Fixed it in v7.
>> +#else
>> + csr_ind_write(CSR_SIREG2, SISELECT_SSCCFG_BASE, counter_idx, hpmevent_curr);
>> +#endif
>> +}
>> +
>> +static void rvpmu_deleg_ctr_start(struct perf_event *event, u64 ival)
>> +{
>> + unsigned long scountinhibit_val = 0;
>> + struct hw_perf_event *hwc = &event->hw;
>> +
>> +#if defined(CONFIG_32BIT)
>> + csr_ind_write(CSR_SIREG, SISELECT_SSCCFG_BASE, hwc->idx, ival & 0xFFFFFFFF);
>> + csr_ind_write(CSR_SIREG4, SISELECT_SSCCFG_BASE, hwc->idx, ival >> BITS_PER_LONG);
>> +#else
>> + csr_ind_write(CSR_SIREG, SISELECT_SSCCFG_BASE, hwc->idx, ival);
>> +#endif
>> +
>> + rvpmu_deleg_ctr_enable_irq(event);
>> +
>> + scountinhibit_val = csr_read(CSR_SCOUNTINHIBIT);
>> + scountinhibit_val &= ~(1 << hwc->idx);
> [Severity: High]
> Could this bitwise shift result in sign-extension and corrupt SCOUNTINHIBIT
> on 64-bit systems?
>
> Because 1 is a signed 32-bit integer, (1 << 31) results in -2147483648.
> When this is negated by a bitwise NOT or cast to an unsigned long on a
> 64-bit architecture, it gets sign-extended (e.g., 0x000000007FFFFFFF).
> This could erroneously clear bits 32-63 of the SCOUNTINHIBIT CSR.
There are only 32 bit counters defined by architecture.
> Should this use 1UL << hwc->idx or the BIT() macro instead?
It's better coding standard to use BIT anyways. Fixed in v7.
> [ ... ]
>
>> -static void rvpmu_sbi_start_overflow_mask(struct riscv_pmu *pmu,
>> - u64 ctr_ovf_mask)
>> +/*
>> + * This function starts all the used counters in two step approach.
>> + * Any counter that did not overflow can be start in a single step
>> + * while the overflowed counters need to be started with updated initialization
>> + * value.
>> + */
>> +static void rvpmu_start_overflow_mask(struct riscv_pmu *pmu, u64 ctr_ovf_mask)
>> {
>> + int idx = 0, i;
>> + struct perf_event *event;
>> + unsigned long ctr_start_mask = 0;
>> + u64 max_period, init_val = 0;
>> + struct hw_perf_event *hwc;
>> struct cpu_hw_events *cpu_hw_evt = this_cpu_ptr(pmu->hw_events);
>>
>> if (sbi_pmu_snapshot_available())
>> - rvpmu_sbi_start_ovf_ctrs_snapshot(cpu_hw_evt, ctr_ovf_mask);
>> - else
>> - rvpmu_sbi_start_ovf_ctrs_sbi(cpu_hw_evt, ctr_ovf_mask);
>> + return rvpmu_sbi_start_ovf_ctrs_snapshot(cpu_hw_evt, ctr_ovf_mask);
> [Severity: High]
> Does this check bypass S-mode delegation when both snapshot and delegation
> are available?
N/A. Not a likely scenario.
> If a platform supports both, this unconditionally calls
> rvpmu_sbi_start_ovf_ctrs_snapshot(), which starts S-mode delegated hardware
> counters using SBI ECALLs rather than direct S-mode CSR writes.
>
> [ ... ]
>
>> +static void update_deleg_hpmevent(int counter_idx, uint64_t event_value, uint64_t filter_bits)
>> +{
>> + u64 hpmevent_value = 0;
>> +
>> + /* OF bit should be enable during the start if sampling is requested */
>> + hpmevent_value = (event_value & ~HPMEVENT_MASK) | filter_bits | HPMEVENT_OF;
> [Severity: High]
> Are we unconditionally setting the HPMEVENT_OF bit here?
>
> Although the comment states it should be enabled if sampling is requested,
> the bit is added for all events. Combined with the early return in
> rvpmu_deleg_ctr_enable_irq(), this causes non-sampling events to remain
> inhibited permanently.
N/A OF bit is for IRQ overflow not for inhibition.
> [ ... ]
>
>> static void rvpmu_ctr_stop(struct perf_event *event, unsigned long flag)
>> {
>> - rvpmu_sbi_ctr_stop(event, flag);
>> - /* TODO: Counter delegation implementation */
>> + struct hw_perf_event *hwc = &event->hw;
>> +
>> + if ((hwc->flags & PERF_EVENT_FLAG_USER_ACCESS) &&
>> + (hwc->flags & PERF_EVENT_FLAG_USER_READ_CNT))
>> + rvpmu_reset_scounteren((void *)event);
>> +
>> + if (riscv_pmu_cdeleg_available() && !pmu_sbi_is_fw_event(event)) {
>> + /*
>> + * The counter is already stopped. No need to stop again. Counter
>> + * mapping will be reset in clear_idx function.
>> + */
>> + if (flag != RISCV_PMU_STOP_FLAG_RESET)
>> + rvpmu_deleg_ctr_stop_mask((1 << hwc->idx));
> [Severity: High]
> Can this 32-bit shift overflow and corrupt the upper 32 bits of SCOUNTINHIBIT?
>
> Passing (1 << 31) will sign-extend to 0xFFFFFFFF80000000 on 64-bit systems.
> When passed to rvpmu_deleg_ctr_stop_mask, it ORs this mask into SCOUNTINHIBIT,
> which erroneously sets bits 32-63 to 1.
>
> Consider using 1UL << hwc->idx or the BIT() macro to prevent overflow.
Yes. Changed to use BIT macro.
^ permalink raw reply
* [PATCH v2 0/2] iio: temperature: Add support for the STS30 temperature sensor
From: Maxwell Doose @ 2026-06-21 0:46 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Hi all,
This patch series adds support for the Sensirion STS30 temperature
sensor family. This driver currently supports non clock stretched single
shot measurements.
Given there were very little issues found with the v1 submission, I've
decided to make this a regular patch series rather than an RFC patch.
Changes since v1:
* whole series:
- Squashed MAINTAINERS updates into both the dt-bindings commit and the
driver commit.
* dt-bindings:
- Added ALERT pin as an interrupt and in the examples.
* driver:
- Fixed a mixup between the clock-stretched and non-clock stretched
commands.
- Fixed an issue where the return value of sts30_reset() was ignored.
- Removed redundant "Author" line at the top.
- Added comment at the top for the formula used to calculate the
temperature in Celsius alongside a macro.
- Added a dedicated macro for the temperature reading size.
- Separated the generic linux headers from the iio specific headers.
- Removed kernel.h from includes.
- Removed unneeded comments.
- Used named initializers for sts30_id and moved above _probe().
Maxwell Doose (2):
dt-bindings: iio: temperature: Add STS30 devicetree bindings
iio: temperature: Add STS30 temperature sensor driver
.../iio/temperature/sensirion,sts30.yaml | 55 +++
MAINTAINERS | 6 +
drivers/iio/temperature/Kconfig | 11 +
drivers/iio/temperature/Makefile | 1 +
drivers/iio/temperature/sts30.c | 329 ++++++++++++++++++
5 files changed, 402 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
create mode 100644 drivers/iio/temperature/sts30.c
--
2.54.0
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: iio: temperature: Add STS30 devicetree bindings
From: Maxwell Doose @ 2026-06-21 0:46 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20260621004626.66629-1-m32285159@gmail.com>
Add the devicetree bindings for the STS30 family of temperature sensors.
The STS30 family of sensors includes the STS30, STS31, and STS35.
All devices in the STS30 family share the same commands, timings, etc.
The only difference between them is their measurement accuracy and
tolerance.
Additionally add MAINTAINERS entry for the driver.
Signed-off-by: Maxwell Doose <m32285159@gmail.com>
---
Changes since v1:
- Squashed parts of the MAINTAINERS commit into this commit.
- Added ALERT pin as an interrupt and in the examples.
.../iio/temperature/sensirion,sts30.yaml | 55 +++++++++++++++++++
MAINTAINERS | 5 ++
2 files changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
diff --git a/Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml b/Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
new file mode 100644
index 000000000000..9bb0f04795d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/sensirion,sts30.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STS30, STS31, and STS35 temperature iio sensors
+
+maintainers:
+ - Maxwell Doose <m32285159@gmail.com>
+
+description: |
+ Family of digital temperature sensors from Sensirion with I2C interface.
+ All devices are compatible with each other, their only differences are
+ their levels of accuracy.
+
+ Datasheet available at:
+ https://sensirion.com/media/documents/1DA31AFD/65D613A8/Datasheet_STS3x_DIS.pdf
+
+properties:
+ compatible:
+ enum:
+ - sensirion,sts30
+ - sensirion,sts31
+ - sensirion,sts35
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature@4a {
+ compatible = "sensirion,sts30";
+ reg = <0x4a>;
+ vdd-supply = <®_3v3>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index d95d3ef77773..7f94b8cac3e2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24487,6 +24487,11 @@ F: drivers/iio/chemical/sps30.c
F: drivers/iio/chemical/sps30_i2c.c
F: drivers/iio/chemical/sps30_serial.c
+SENSIRION STS30 TEMPERATURE SENSOR DRIVER
+M: Maxwell Doose <m32285159@gmail.com>
+S: Maintained
+F: Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
+
SERIAL DEVICE BUS
M: Rob Herring <robh@kernel.org>
L: linux-serial@vger.kernel.org
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/2] iio: temperature: Add STS30 temperature sensor driver
From: Maxwell Doose @ 2026-06-21 0:46 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20260621004626.66629-1-m32285159@gmail.com>
Add a driver for the Sensirion STS30 family of temperature sensor
drivers over I2C. The STS30 family of sensors includes the STS30, STS31,
and STS35, all of which are supported by this driver, since they all
share the same commands, etc. and only differ in accuracy and tolerance.
The driver currently supports single-shot non-clock stretched readings,
by using a specified delay based on the repeatability/delay specified
by the user. The repeatability/delay can be changed at any time through
sysfs.
Additionally add Kconfig and Makefile entries for the driver as well as
a MAINTAINERS entry.
Signed-off-by: Maxwell Doose <m32285159@gmail.com>
---
Changes since v1:
- Squashed parts of the MAINTAINERS commit into this commit.
- Fixed a mixup between the clock-stretched and non-clock stretched
commands.
- Fixed an issue where the return value of sts30_reset() was ignored.
- Removed redundant "Author" line at the top.
- Added comment at the top for the formula used to calculate the
temperature in Celsius alongside a macro.
- Added a dedicated macro for the temperature reading size.
- Separated the generic linux headers from the iio specific headers.
- Removed kernel.h from includes.
- Removed unneeded comments.
- Used named initializers for sts30_id and moved above _probe().
MAINTAINERS | 1 +
drivers/iio/temperature/Kconfig | 11 ++
drivers/iio/temperature/Makefile | 1 +
drivers/iio/temperature/sts30.c | 329 +++++++++++++++++++++++++++++++
4 files changed, 342 insertions(+)
create mode 100644 drivers/iio/temperature/sts30.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7f94b8cac3e2..6bb361ac213f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24491,6 +24491,7 @@ SENSIRION STS30 TEMPERATURE SENSOR DRIVER
M: Maxwell Doose <m32285159@gmail.com>
S: Maintained
F: Documentation/devicetree/bindings/iio/temperature/sensirion,sts30.yaml
+F: drivers/iio/temperature/sts30.c
SERIAL DEVICE BUS
M: Rob Herring <robh@kernel.org>
diff --git a/drivers/iio/temperature/Kconfig b/drivers/iio/temperature/Kconfig
index 9328b2250ace..c23a9c40c725 100644
--- a/drivers/iio/temperature/Kconfig
+++ b/drivers/iio/temperature/Kconfig
@@ -88,6 +88,17 @@ config MLX90635
This driver can also be built as a module. If so, the module will
be called mlx90635.
+config STS30
+ tristate "STS30/STS31/STS35 temperature sensor"
+ depends on I2C
+ select CRC8
+ help
+ If you say yes here you get support for the Sensirion STS30,
+ STS31, and STS35 temperature sensors over I2C.
+
+ This driver can also be built as a module. If so, the module will
+ be called sts30.
+
config TMP006
tristate "TMP006 infrared thermopile sensor"
depends on I2C
diff --git a/drivers/iio/temperature/Makefile b/drivers/iio/temperature/Makefile
index 07d6e65709f7..9c9bf8d1b70e 100644
--- a/drivers/iio/temperature/Makefile
+++ b/drivers/iio/temperature/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_MCP9600) += mcp9600.o
obj-$(CONFIG_MLX90614) += mlx90614.o
obj-$(CONFIG_MLX90632) += mlx90632.o
obj-$(CONFIG_MLX90632) += mlx90635.o
+obj-$(CONFIG_STS30) += sts30.o
obj-$(CONFIG_TMP006) += tmp006.o
obj-$(CONFIG_TMP007) += tmp007.o
obj-$(CONFIG_TMP117) += tmp117.o
diff --git a/drivers/iio/temperature/sts30.c b/drivers/iio/temperature/sts30.c
new file mode 100644
index 000000000000..dcfe3435ae5a
--- /dev/null
+++ b/drivers/iio/temperature/sts30.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Maxwell Doose
+ *
+ * Sensirion STS30 temperature sensor driver
+ *
+ * Datasheet: https://sensirion.com/media/documents/1DA31AFD/65D613A8/Datasheet_STS3x_DIS.pdf
+ */
+
+#include <linux/array_size.h>
+#include <linux/bits.h>
+#include <linux/cleanup.h>
+#include <linux/crc8.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/export.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/types.h>
+#include <linux/unaligned.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/types.h>
+
+/*
+ * STS30 measurement to Celsius conversion formula:
+ *
+ * T = -45 + 175(S[T]/(2^16 - 1)
+ *
+ * Where S[T] is the raw sensor output. We use this formula to calculate the offset.
+ * Using this we can calculate the offset to be -16852.
+ *
+ * See section 4.12 in the datasheet for more info.
+ */
+#define STS30_TEMP_OFFSET -16852
+
+/* Amount of bytes received from the STS30 after a read command */
+#define STS30_MEAS_SIZE 3
+
+/* Size of the temperature measurement data received after a read command */
+#define STS30_TEMP_MEAS_SIZE 2
+
+#define STS30_COMMAND_READ_HIGH_REPEAT 0x2400
+#define STS30_COMMAND_READ_MED_REPEAT 0x240B
+#define STS30_COMMAND_READ_LOW_REPEAT 0x2416
+
+#define STS30_COMMAND_RESET 0x30A2
+
+/*
+ * sts30 includes a CRC8 checksum at the end of its i2c responses. The polynomial
+ * is used to generate the CRC8 table and the seed is the starting value.
+ */
+#define STS30_CRC8_POLYNOMIAL 0x31
+#define STS30_CRC8_SEED 0xFF
+
+DECLARE_CRC8_TABLE(sts30_crc_table);
+
+enum sts30_read_delays {
+ STS30_REPEAT_LOW = 4500,
+ STS30_REPEAT_MED = 6000,
+ STS30_REPEAT_HIGH = 15000
+};
+
+struct sts30_data {
+ struct i2c_client *client;
+ struct mutex lock; /* Mutex for serialized communication on the i2c bus */
+ /*
+ * sts30 has three potential repeatability/measurement durations. We need to
+ * account for them while reading the i2c bus.
+ *
+ * See section 2.2 in the datasheet for more info on processing times.
+ */
+ enum sts30_read_delays delay;
+};
+
+static int sts30_verify_crc8(struct sts30_data *data, u8 buf[STS30_MEAS_SIZE])
+{
+ int crc;
+
+ crc = crc8(sts30_crc_table, buf, STS30_TEMP_MEAS_SIZE, STS30_CRC8_SEED);
+ if (crc != buf[2]) {
+ dev_err(&data->client->dev, "Expected CRC8 value of 0x%02x, got 0x%02x\n",
+ buf[2], crc);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int sts30_read(struct sts30_data *data, u16 command, u16 *val)
+{
+ u8 buf[STS30_MEAS_SIZE];
+ u8 tmp[2];
+ int ret;
+
+ put_unaligned_be16(command, tmp);
+
+ ret = i2c_master_send(data->client, tmp, sizeof(tmp));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(tmp))
+ return -EIO;
+
+ fsleep(data->delay);
+
+ ret = i2c_master_recv(data->client, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(buf))
+ return -EIO;
+
+ *val = get_unaligned_be16(buf);
+
+ ret = sts30_verify_crc8(data, buf);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int sts30_write(struct sts30_data *data, u16 command)
+{
+ u8 buf[2];
+ int ret;
+
+ put_unaligned_be16(command, buf);
+
+ ret = i2c_master_send(data->client, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(buf))
+ return -EIO;
+
+ return 0;
+}
+
+static int sts30_reset(struct sts30_data *data)
+{
+ int ret;
+
+ guard(mutex)(&data->lock);
+
+ ret = sts30_write(data, STS30_COMMAND_RESET);
+ if (ret)
+ return ret;
+
+ /*
+ * Datasheet dictates that the maximum time for a soft reset is 1.5ms.
+ *
+ * See section 2.2 for more info on timing.
+ */
+ fsleep(1500);
+
+ return 0;
+}
+
+static int sts30_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val, int *val2,
+ long mask)
+{
+ struct sts30_data *data = iio_priv(indio_dev);
+ int ret;
+ u16 tmp;
+
+ guard(mutex)(&data->lock);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ switch (data->delay) {
+ case STS30_REPEAT_LOW:
+ ret = sts30_read(data, STS30_COMMAND_READ_LOW_REPEAT, &tmp);
+ break;
+ case STS30_REPEAT_MED:
+ ret = sts30_read(data, STS30_COMMAND_READ_MED_REPEAT, &tmp);
+ break;
+ case STS30_REPEAT_HIGH:
+ ret = sts30_read(data, STS30_COMMAND_READ_HIGH_REPEAT, &tmp);
+ break;
+ default:
+ dev_warn(&data->client->dev, "Repeatability state corrupted, got: %d\n",
+ data->delay);
+ return -EINVAL;
+ }
+
+ if (ret)
+ return ret;
+
+ *val = tmp;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_OFFSET:
+ *val = STS30_TEMP_OFFSET;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ *val = 175000;
+ *val2 = 65535;
+ return IIO_VAL_FRACTIONAL;
+ case IIO_CHAN_INFO_INT_TIME:
+ *val = 0;
+ *val2 = data->delay;
+ return IIO_VAL_INT_PLUS_MICRO;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int sts30_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int val, int val2,
+ long mask)
+{
+ struct sts30_data *data = iio_priv(indio_dev);
+
+ if (val)
+ return -EINVAL;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_INT_TIME: {
+ guard(mutex)(&data->lock);
+
+ switch (val2) {
+ case STS30_REPEAT_LOW:
+ data->delay = STS30_REPEAT_LOW;
+ break;
+ case STS30_REPEAT_MED:
+ data->delay = STS30_REPEAT_MED;
+ break;
+ case STS30_REPEAT_HIGH:
+ data->delay = STS30_REPEAT_HIGH;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info sts30_info = {
+ .read_raw = sts30_read_raw,
+ .write_raw = sts30_write_raw
+};
+
+static const struct iio_chan_spec sts30_channels[] = {
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_OFFSET) |
+ BIT(IIO_CHAN_INFO_SCALE) | BIT(IIO_CHAN_INFO_INT_TIME)
+ },
+};
+
+static int sts30_probe(struct i2c_client *client)
+{
+ struct iio_dev *indio_dev;
+ struct sts30_data *data;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ indio_dev->name = client->name;
+ indio_dev->info = &sts30_info;
+ indio_dev->channels = sts30_channels;
+ indio_dev->num_channels = ARRAY_SIZE(sts30_channels);
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ data = iio_priv(indio_dev);
+ data->client = client;
+ data->delay = STS30_REPEAT_HIGH;
+
+ ret = devm_mutex_init(&client->dev, &data->lock);
+ if (ret)
+ return ret;
+
+ i2c_set_clientdata(client, indio_dev);
+
+ ret = sts30_reset(data);
+ if (ret)
+ return ret;
+
+ return devm_iio_device_register(&client->dev, indio_dev);
+}
+
+static const struct i2c_device_id sts30_id[] = {
+ { .name = "sts30" },
+ { .name = "sts31" },
+ { .name = "sts35" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, sts30_id);
+
+static const struct of_device_id sts30_of_match[] = {
+ { .compatible = "sensirion,sts30" },
+ { .compatible = "sensirion,sts31" },
+ { .compatible = "sensirion,sts35" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sts30_of_match);
+
+static struct i2c_driver sts30_driver = {
+ .driver = {
+ .name = "sts30",
+ .of_match_table = sts30_of_match,
+ },
+ .probe = sts30_probe,
+ .id_table = sts30_id,
+};
+
+static int __init sts30_init(void)
+{
+ crc8_populate_msb(sts30_crc_table, STS30_CRC8_POLYNOMIAL);
+
+ return i2c_add_driver(&sts30_driver);
+}
+module_init(sts30_init);
+
+static void __exit sts30_exit(void)
+{
+ i2c_del_driver(&sts30_driver);
+}
+module_exit(sts30_exit);
+
+MODULE_AUTHOR("Maxwell Doose <m32285159@gmail.com>");
+MODULE_DESCRIPTION("Sensirion STS30 temperature sensor driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH 1/9] arm64: dts: renesas: r8a774a1: Add soc: label to soc node
From: Marek Vasut @ 2026-06-21 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
which already has that soc: label. The soc: label is useful in U-Boot
where it is used in U-Boot extras DT fragments.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 36675f5bcdeaf..e66d86db6e6c4 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -262,7 +262,7 @@ scif_clk: scif {
clock-frequency = <0>;
};
- soc {
+ soc: soc {
compatible = "simple-bus";
bootph-all;
--
2.53.0
^ permalink raw reply related
* [PATCH 2/9] arm64: dts: renesas: r8a774b1: Add soc: label to soc node
From: Marek Vasut @ 2026-06-21 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260621025052.406507-1-marek.vasut+renesas@mailbox.org>
Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
which already has that soc: label. The soc: label is useful in U-Boot
where it is used in U-Boot extras DT fragments.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index ceef0104f75e8..62c6703917db4 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -146,7 +146,7 @@ scif_clk: scif {
clock-frequency = <0>;
};
- soc {
+ soc: soc {
compatible = "simple-bus";
bootph-all;
--
2.53.0
^ permalink raw reply related
* [PATCH 3/9] arm64: dts: renesas: r8a774e1: Add soc: label to soc node
From: Marek Vasut @ 2026-06-21 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260621025052.406507-1-marek.vasut+renesas@mailbox.org>
Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
which already has that soc: label. The soc: label is useful in U-Boot
where it is used in U-Boot extras DT fragments.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
index 9df5f1a424004..0ae9bb72d2dda 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
@@ -326,7 +326,7 @@ scif_clk: scif {
clock-frequency = <0>;
};
- soc {
+ soc: soc {
compatible = "simple-bus";
bootph-all;
--
2.53.0
^ permalink raw reply related
* [PATCH 4/9] arm64: dts: renesas: r8a77960: Add soc: label to soc node
From: Marek Vasut @ 2026-06-21 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260621025052.406507-1-marek.vasut+renesas@mailbox.org>
Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
which already has that soc: label. The soc: label is useful in U-Boot
where it is used in U-Boot extras DT fragments.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a77960.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77960.dtsi b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
index ad36aa8e75435..4f9989b5e77a8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
@@ -311,7 +311,7 @@ scif_clk: scif {
clock-frequency = <0>;
};
- soc {
+ soc: soc {
compatible = "simple-bus";
bootph-all;
--
2.53.0
^ permalink raw reply related
* [PATCH 6/9] arm64: dts: renesas: r8a77965: Add soc: label to soc node
From: Marek Vasut @ 2026-06-21 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260621025052.406507-1-marek.vasut+renesas@mailbox.org>
Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
which already has that soc: label. The soc: label is useful in U-Boot
where it is used in U-Boot extras DT fragments.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 611a9335c63ad..70708f5cf7467 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -182,7 +182,7 @@ scif_clk: scif {
clock-frequency = <0>;
};
- soc {
+ soc: soc {
compatible = "simple-bus";
bootph-all;
--
2.53.0
^ permalink raw reply related
* [PATCH 7/9] arm64: dts: renesas: r8a77970: Add soc: label to soc node
From: Marek Vasut @ 2026-06-21 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260621025052.406507-1-marek.vasut+renesas@mailbox.org>
Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
which already has that soc: label. The soc: label is useful in U-Boot
where it is used in U-Boot extras DT fragments.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 1f6676e2795a4..f7f1f280fa0b6 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -91,7 +91,7 @@ scif_clk: scif {
clock-frequency = <0>;
};
- soc {
+ soc: soc {
compatible = "simple-bus";
bootph-all;
--
2.53.0
^ permalink raw reply related
* [PATCH 5/9] arm64: dts: renesas: r8a77961: Add soc: label to soc node
From: Marek Vasut @ 2026-06-21 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260621025052.406507-1-marek.vasut+renesas@mailbox.org>
Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
which already has that soc: label. The soc: label is useful in U-Boot
where it is used in U-Boot extras DT fragments.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a77961.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
index 9d76e39eab72e..ad4491ba948f2 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
@@ -311,7 +311,7 @@ scif_clk: scif {
clock-frequency = <0>;
};
- soc {
+ soc: soc {
compatible = "simple-bus";
bootph-all;
--
2.53.0
^ permalink raw reply related
* [PATCH 8/9] arm64: dts: renesas: r8a77980: Add soc: label to soc node
From: Marek Vasut @ 2026-06-21 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260621025052.406507-1-marek.vasut+renesas@mailbox.org>
Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
which already has that soc: label. The soc: label is useful in U-Boot
where it is used in U-Boot extras DT fragments.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77980.dtsi b/arch/arm64/boot/dts/renesas/r8a77980.dtsi
index 86b7792d68fac..514dafe344786 100644
--- a/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -120,7 +120,7 @@ scif_clk: scif {
clock-frequency = <0>;
};
- soc {
+ soc: soc {
compatible = "simple-bus";
bootph-all;
--
2.53.0
^ permalink raw reply related
* [PATCH 9/9] arm64: dts: renesas: r8a77995: Add soc: label to soc node
From: Marek Vasut @ 2026-06-21 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260621025052.406507-1-marek.vasut+renesas@mailbox.org>
Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
which already has that soc: label. The soc: label is useful in U-Boot
where it is used in U-Boot extras DT fragments.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 5f3fcef7560cb..522a49db02587 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -85,7 +85,7 @@ scif_clk: scif {
clock-frequency = <0>;
};
- soc {
+ soc: soc {
compatible = "simple-bus";
bootph-all;
--
2.53.0
^ permalink raw reply related
* [PATCH 0/3] X2 Elite HP EliteBook X G2q support
From: Jason Pettit @ 2026-06-21 4:50 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Akhil P Oommen,
Mahadevan P, Sibi Sankar, Jingyi Wang, Ananthu C V, Jason Pettit
This series adds initial device-tree support for the HP EliteBook X G2q
14" Next Gen AI PC (product SKU C4JG0AV, board 8E91), a Snapdragon X2
Elite (Glymur) laptop.
The board was brought up and validated on real hardware. The electrical
description (PMIC rails, PHY supplies, the HDMI bridge wiring) was
verified against the live unit rather than copied from a Glymur CRD.
Working on this laptop with this series applied:
- Internal eDP panel (samsung,atna33xc20)
- 2x USB Type-C with DisplayPort alt-mode and USB
- Chassis HDMI output
- Chassis USB-A host port
- Fingerprint reader
- NVMe SSD on PCIe5
- Wi-Fi, Bluetooth
- Keyboard, touchpad, touchscreen, lid switch
- Adreno GPU and GMU (Freedreno GL on Mesa)
- Audio playback and capture
This patch series builds upon the recent work of Qualcomm engineers to
enable another Glymur-based laptop.
Like its peer submissions, the camera support is missing today.
This has the same known dependencies as other boards on this
platform (audio, GPU, SoCCP series).
The GPU device-tree patches come from the partially merged Glymur GPU DT
v5 series at
https://lore.kernel.org/all/20260522-glymur-gpu-dt-v5-0-562c406b210c@oss.qualcomm.com/
SCMI on this configuration needs CONFIG_QCOM_CPUCP_MBOX built in (=y).
The bindings patch is independent and can be reviewed/applied on its own.
The board patch can be reviewed in parallel with the GPU, LPASS and SoCCP
SoC series. Until those land in the target tree, it will trip the expected
"Label or path ... not found" dtc error. As with the X2 Elite Lenovo Yoga
Slim 7x submission, this v1 is expected to trigger some dt-bindings warnings
that come from the in-flight dependency series, not from the board patch
itself.
Signed-off-by: Jason Pettit <jason.pettit@oss.qualcomm.com>
---
Jason Pettit (3):
dt-bindings: arm: qcom: Add HP EliteBook X G2q 14 AI
arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
firmware: qcom: scm: Allow QSEECOM on HP EliteBook X G2q 14 AI
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/glymur-hp-elitebook-x-g2q.dts | 977 +++++++++++++++++++++
drivers/firmware/qcom/qcom_scm.c | 1 +
4 files changed, 980 insertions(+)
---
base-commit: c52dce2340e79e98cf4aa05606edc8db1759e026
change-id: 20260619-glymur-send-1136d243a120
prerequisite-patch-id: 36f4bb7740fd65d808fa6685bce4b03798a547ff
prerequisite-patch-id: 054631082c45d3ab3117f541f0d4d90b660dac73
prerequisite-patch-id: af18aef027c45213c11b436746fa31b3b6ebe46b
prerequisite-message-id: <20260419-glymur_dp-v1-1-ad1067a8e8ae@oss.qualcomm.com>
prerequisite-patch-id: 7cb9a168c33491bf91ece900a2218aa7b4b68ddd
prerequisite-message-id: <20260523085511.2532669-1-sibi.sankar@oss.qualcomm.com>
prerequisite-patch-id: 43e96d8a5063f51e2b5ee75fc8c9e10682e5670c
prerequisite-patch-id: 2e71d345f84a821d89da2a6064954409fdb1277d
prerequisite-patch-id: 0b9f5995044bb3d3ffda227ac986b755fa118c63
prerequisite-message-id: <20260519-knp-soccp-v6-0-cf5d0e194b5f@oss.qualcomm.com>
prerequisite-patch-id: 8459bcae98ac156f6576657fe9233badcd385218
prerequisite-patch-id: 9ab2b37c0a11c3a9590be921fefc8709ebebf6a3
prerequisite-patch-id: 21440dddcc340d35558010fe88bad9265e43c6ac
prerequisite-patch-id: 162f8b373ead5344ae0f29c92432db57a0d75f39
prerequisite-patch-id: bf5532cd5c8b66127e20be0677adbbbb3bd9578f
prerequisite-patch-id: fa7954f6fd2d27a6f0e805c9643b70e7e201c503
prerequisite-message-id: <20260403-glymur-soccp-v3-1-f0e8d57f11ba@oss.qualcomm.com>
prerequisite-patch-id: 48c26c428cbeaa674a615704d1abeb87e4e965c8
Best regards,
--
Jason Pettit <jason.pettit@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: arm: qcom: Add HP EliteBook X G2q 14 AI
From: Jason Pettit @ 2026-06-21 4:50 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Akhil P Oommen,
Mahadevan P, Sibi Sankar, Jingyi Wang, Ananthu C V, Jason Pettit
In-Reply-To: <20260620-glymur-send-v1-0-fc4a2cfd107c@oss.qualcomm.com>
The HP EliteBook X G2q 14 AI is a Snapdragon X2 Elite (Glymur) laptop.
Document its top-level "hp,elitebook-x-g2q" compatible, falling back to
the existing "qcom,glymur" SoC compatible.
Signed-off-by: Jason Pettit <jason.pettit@oss.qualcomm.com>
Assisted-by: Claude:claude-opus-4-8
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..934f62407b86 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -68,6 +68,7 @@ properties:
- items:
- enum:
+ - hp,elitebook-x-g2q
- qcom,glymur-crd
- const: qcom,glymur
--
2.50.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
From: Jason Pettit @ 2026-06-21 4:50 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Akhil P Oommen,
Mahadevan P, Sibi Sankar, Jingyi Wang, Ananthu C V, Jason Pettit
In-Reply-To: <20260620-glymur-send-v1-0-fc4a2cfd107c@oss.qualcomm.com>
Add board support for the HP EliteBook X G2q 14" Next Gen AI PC
(product SKU C4JG0AV, board 8E91), a Snapdragon X2 Elite (Glymur)
laptop, using the "hp,elitebook-x-g2q" / "qcom,glymur" compatible.
Enabled by this device tree:
- internal eDP panel (samsung,atna33xc20)
- 2x USB Type-C with DisplayPort alt-mode and USB
- chassis HDMI output
- chassis USB-A host port (usb_mp multiport controller)
- internal eUSB2 host with the Elan fingerprint reader
- NVMe SSD on PCIe5
- Wi-Fi and Bluetooth
- HID-over-I2C keyboard, touchpad, touchscreen; lid switch
- Adreno GPU and GMU (Freedreno GL on Mesa)
- audio playback and capture
The HDMI jack is driven by a power-only DisplayPort-to-HDMI LSPCON on
the usb_2 combo-PHY DP lanes rather than being a third USB-C port; HPD
is on gpio126. The LSPCON is on an I/O sub-board with no I2C/AUX control
path, so it is modelled with the generic simple-bridge "parade,ps185hdm"
compatible used by the in-tree x1e80100 HDMI-bridge boards (the exact
bridge part is unconfirmed) and it needs CONFIG_DRM_SIMPLE_BRIDGE.
The &gpu/&gmu enable, the audio nodes and &remoteproc_soccp opt into
glymur.dtsi SoC nodes that are still in-flight; those series are
declared as prerequisites in the cover letter.
Signed-off-by: Jason Pettit <jason.pettit@oss.qualcomm.com>
Assisted-by: Claude:claude-opus-4-8
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/glymur-hp-elitebook-x-g2q.dts | 977 +++++++++++++++++++++
2 files changed, 978 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 6f33c4e2f09c..b10629808b76 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -16,6 +16,7 @@ dtb-$(CONFIG_ARCH_QCOM) += apq8096sg-db820c.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8096-ifc6640.dtb
dtb-$(CONFIG_ARCH_QCOM) += eliza-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += glymur-crd.dtb
+dtb-$(CONFIG_ARCH_QCOM) += glymur-hp-elitebook-x-g2q.dtb
dtb-$(CONFIG_ARCH_QCOM) += hamoa-iot-evk.dtb
hamoa-iot-evk-el2-dtbs := hamoa-iot-evk.dtb x1-el2.dtbo
diff --git a/arch/arm64/boot/dts/qcom/glymur-hp-elitebook-x-g2q.dts b/arch/arm64/boot/dts/qcom/glymur-hp-elitebook-x-g2q.dts
new file mode 100644
index 000000000000..795940a99946
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/glymur-hp-elitebook-x-g2q.dts
@@ -0,0 +1,977 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+/dts-v1/;
+
+#include "glymur.dtsi"
+
+#include "pmcx0102.dtsi" /* SPMI0: SID-2/3 SPMI1: SID-2/3 */
+#include "pmh0101.dtsi" /* SPMI0: SID-1 */
+#include "pmh0110-glymur.dtsi" /* SPMI0: SID-5/7 SPMI1: SID-5 */
+#include "pmh0104-glymur.dtsi" /* SPMI0: SID-8/9 SPMI1: SID-11 */
+#include "pmk8850.dtsi" /* SPMI0: SID-0 */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/gpio-keys.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
+
+/ {
+ model = "HP EliteBook X G2q 14 AI";
+ compatible = "hp,elitebook-x-g2q", "qcom,glymur";
+
+ aliases {
+ serial1 = &uart14;
+ };
+
+ clocks {
+ xo_board: xo-board {
+ compatible = "fixed-clock";
+ clock-frequency = <38400000>;
+ #clock-cells = <0>;
+ };
+
+ sleep_clk: sleep-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <32000>;
+ #clock-cells = <0>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&lid_default>;
+ pinctrl-names = "default";
+
+ switch-lid {
+ label = "lid";
+ gpios = <&tlmm 92 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_LID>;
+ wakeup-source;
+ wakeup-event-action = <EV_ACT_DEASSERTED>;
+ };
+ };
+
+ hdmi-bridge {
+ compatible = "parade,ps185hdm";
+
+ pinctrl-0 = <&usb2_dp_hot_plug_detect>;
+ pinctrl-names = "default";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ hdmi_bridge_in: endpoint {
+ remote-endpoint = <&usb_2_qmpphy_out_dp>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ hdmi_bridge_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&hdmi_bridge_out>;
+ };
+ };
+ };
+
+ pmic-glink {
+ compatible = "qcom,glymur-pmic-glink",
+ "qcom,pmic-glink";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Left side display-adjacent port */
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in: endpoint {
+ remote-endpoint = <&usb_0_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss_in: endpoint {
+ remote-endpoint = <&usb_0_qmpphy_out>;
+ };
+ };
+ };
+ };
+
+ /* Left side user-adjacent port */
+ connector@1 {
+ compatible = "usb-c-connector";
+ reg = <1>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in1: endpoint {
+ remote-endpoint = <&usb_1_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss_in1: endpoint {
+ remote-endpoint = <&usb_1_qmpphy_out>;
+ };
+ };
+ };
+ };
+ };
+
+ vreg_edp_3p3: regulator-edp-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_EDP_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&edp_reg_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
+ vreg_nvme: regulator-nvme {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_NVME_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&pmh0101_gpios 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&nvme_reg_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
+ vreg_wcn_0p95: regulator-wcn-0p95 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_WCN_0P95";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <950000>;
+
+ vin-supply = <&vreg_wcn_3p3>;
+ };
+
+ vreg_wcn_3p3: regulator-wcn-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_WCN_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 94 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&wcn_sw_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
+ sound {
+ compatible = "qcom,glymur-sndcard";
+ model = "GLYMUR-HP-EliteBook-X-G2q";
+
+ audio-routing = "WooferLeft IN", "WSA WSA_SPK1 OUT",
+ "TweeterLeft IN", "WSA WSA_SPK2 OUT",
+ "WooferRight IN", "WSA2 WSA_SPK1 OUT",
+ "TweeterRight IN", "WSA2 WSA_SPK2 OUT",
+ "VA DMIC0", "vdd-micb",
+ "VA DMIC1", "vdd-micb",
+ "VA DMIC2", "vdd-micb",
+ "VA DMIC3", "vdd-micb";
+
+ va-dai-link {
+ link-name = "VA Capture";
+
+ codec {
+ sound-dai = <&lpass_vamacro 0>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai VA_CODEC_DMA_TX_0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ wsa-dai-link {
+ link-name = "WSA Playback";
+
+ codec {
+ sound-dai = <&left_woofer>, <&left_tweeter>,
+ <&swr0 0>, <&lpass_wsamacro 0>,
+ <&right_woofer>, <&right_tweeter>,
+ <&swr3 0>, <&lpass_wsa2macro 0>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+ };
+
+ wcn7850-pmu {
+ compatible = "qcom,wcn7850-pmu";
+
+ vdd-supply = <&vreg_wcn_0p95>;
+ vddio-supply = <&vreg_l15b_e0_1p8>;
+ vddaon-supply = <&vreg_l15b_e0_1p8>;
+ vdddig-supply = <&vreg_l15b_e0_1p8>;
+ vddrfa1p2-supply = <&vreg_l15b_e0_1p8>;
+ vddrfa1p8-supply = <&vreg_l15b_e0_1p8>;
+
+ wlan-enable-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
+ bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&wcn_wlan_bt_en>;
+ pinctrl-names = "default";
+
+ regulators {
+ vreg_pmu_rfa_cmn: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn";
+ };
+
+ vreg_pmu_aon_0p59: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p59";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p85: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p85";
+ };
+
+ vreg_pmu_btcmx_0p85: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p85";
+ };
+
+ vreg_pmu_rfa_0p8: ldo5 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo6 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p8: ldo7 {
+ regulator-name = "vreg_pmu_rfa_1p8";
+ };
+
+ vreg_pmu_pcie_0p9: ldo8 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_pcie_1p8: ldo9 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pmh0101-rpmh-regulators";
+ qcom,pmic-id = "B_E0";
+
+ vreg_l1b_e0_1p8: ldo1 {
+ regulator-name = "vreg_l1b_e0_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_e0_1p8: ldo15 {
+ regulator-name = "vreg_l15b_e0_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l18b_e0_1p2: ldo18 {
+ regulator-name = "vreg_l18b_e0_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pmcx0102-rpmh-regulators";
+ qcom,pmic-id = "C_E1";
+
+ vreg_l1c_e1_0p91: ldo1 {
+ regulator-name = "vreg_l1c_e1_0p91";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-2 {
+ compatible = "qcom,pmh0110-rpmh-regulators";
+ qcom,pmic-id = "F_E0";
+
+ vreg_l2f_e0_0p94: ldo2 {
+ regulator-name = "vreg_l2f_e0_0p94";
+ regulator-min-microvolt = <936000>;
+ regulator-max-microvolt = <936000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3f_e0_0p91: ldo3 {
+ regulator-name = "vreg_l3f_e0_0p91";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-3 {
+ compatible = "qcom,pmh0110-rpmh-regulators";
+ qcom,pmic-id = "F_E1";
+
+ vreg_l2f_e1_0p88: ldo2 {
+ regulator-name = "vreg_l2f_e1_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <880000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4f_e1_1p2: ldo4 {
+ regulator-name = "vreg_l4f_e1_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-4 {
+ compatible = "qcom,pmh0110-rpmh-regulators";
+ qcom,pmic-id = "H_E0";
+
+ vreg_l1h_e0_0p94: ldo1 {
+ regulator-name = "vreg_l1h_e0_0p94";
+ regulator-min-microvolt = <936000>;
+ regulator-max-microvolt = <936000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2h_e0_0p88: ldo2 {
+ regulator-name = "vreg_l2h_e0_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <880000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4h_e0_1p2: ldo4 {
+ regulator-name = "vreg_l4h_e0_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&gmu {
+ status = "okay";
+};
+
+&gpu {
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ keyboard@3a {
+ compatible = "hid-over-i2c";
+ reg = <0x3a>;
+
+ hid-descr-addr = <0x1>;
+ interrupts-extended = <&tlmm 67 IRQ_TYPE_LEVEL_LOW>;
+
+ pinctrl-0 = <&kybd_default>;
+ pinctrl-names = "default";
+
+ wakeup-source;
+ };
+
+ touchpad@2c {
+ compatible = "hid-over-i2c";
+ reg = <0x2c>;
+
+ hid-descr-addr = <0x20>;
+ interrupts-extended = <&tlmm 66 IRQ_TYPE_LEVEL_LOW>;
+
+ pinctrl-0 = <&tpad_default>;
+ pinctrl-names = "default";
+
+ wakeup-source;
+ };
+};
+
+&i2c8 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ touchscreen@10 {
+ compatible = "hid-over-i2c";
+ reg = <0x10>;
+
+ hid-descr-addr = <0x1>;
+ interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>;
+
+ post-power-on-delay-ms = <200>;
+
+ pinctrl-0 = <&ts0_default>;
+ pinctrl-names = "default";
+ };
+};
+
+&lpass_vamacro {
+ vdd-micb-supply = <&vreg_l1b_e0_1p8>;
+
+ pinctrl-0 = <&dmic01_default>, <&dmic23_default>;
+ pinctrl-names = "default";
+
+ qcom,dmic-sample-rate = <4800000>;
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_dp0 {
+ status = "okay";
+};
+
+&mdss_dp0_out {
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
+&mdss_dp1 {
+ status = "okay";
+};
+
+&mdss_dp1_out {
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
+&mdss_dp2 {
+ status = "okay";
+};
+
+&mdss_dp2_out {
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
+&mdss_dp3 {
+ /delete-property/ #sound-dai-cells;
+
+ status = "okay";
+
+ aux-bus {
+ panel {
+ compatible = "samsung,atna33xc20";
+ enable-gpios = <&tlmm 18 GPIO_ACTIVE_HIGH>;
+ power-supply = <&vreg_edp_3p3>;
+
+ pinctrl-0 = <&edp_bl_en>;
+ pinctrl-names = "default";
+
+ port {
+ edp_panel_in: endpoint {
+ remote-endpoint = <&mdss_dp3_out>;
+ };
+ };
+ };
+ };
+};
+
+&mdss_dp3_out {
+ data-lanes = <0 1 2 3>;
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+
+ remote-endpoint = <&edp_panel_in>;
+};
+
+&mdss_dp3_phy {
+ vdda-phy-supply = <&vreg_l2f_e1_0p88>;
+ vdda-pll-supply = <&vreg_l4f_e1_1p2>;
+
+ status = "okay";
+};
+
+&pcie4 {
+ pinctrl-0 = <&pcie4_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie4_phy {
+ vdda-phy-supply = <&vreg_l1c_e1_0p91>;
+ vdda-pll-supply = <&vreg_l4f_e1_1p2>;
+
+ status = "okay";
+};
+
+&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
+ wifi@0 {
+ compatible = "pci17cb,1107";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+ vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+ vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+ };
+};
+
+&pcie5 {
+ vddpe-3v3-supply = <&vreg_nvme>;
+
+ pinctrl-0 = <&pcie5_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie5_phy {
+ vdda-phy-supply = <&vreg_l2f_e0_0p94>;
+ vdda-pll-supply = <&vreg_l4h_e0_1p2>;
+
+ status = "okay";
+};
+
+&pcie5_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+};
+
+&pmh0101_gpios {
+ nvme_reg_en: nvme-reg-en-state {
+ pins = "gpio14";
+ function = "normal";
+ bias-disable;
+ };
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/glymur/hp/elitebook-x-g2q/adsp.mbn",
+ "qcom/glymur/hp/elitebook-x-g2q/adsp_dtb.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_soccp {
+ status = "okay";
+};
+
+&swr0 {
+ status = "okay";
+
+ /* WSA8845, left woofer */
+ left_woofer: speaker@0,0 {
+ compatible = "sdw20217020400";
+ reg = <0 0>;
+ reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "WooferLeft";
+ vdd-1p8-supply = <&vreg_l15b_e0_1p8>;
+ vdd-io-supply = <&vreg_l18b_e0_1p2>;
+ qcom,port-mapping = <1 2 3 7 12 14>;
+ };
+
+ /* WSA8845, left tweeter */
+ left_tweeter: speaker@0,1 {
+ compatible = "sdw20217020400";
+ reg = <0 1>;
+ reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "TweeterLeft";
+ vdd-1p8-supply = <&vreg_l15b_e0_1p8>;
+ vdd-io-supply = <&vreg_l18b_e0_1p2>;
+ qcom,port-mapping = <4 5 6 7 13 15>;
+ };
+};
+
+&swr3 {
+ status = "okay";
+
+ /* WSA8845, right woofer */
+ right_woofer: speaker@0,0 {
+ compatible = "sdw20217020400";
+ reg = <0 0>;
+ reset-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "WooferRight";
+ vdd-1p8-supply = <&vreg_l15b_e0_1p8>;
+ vdd-io-supply = <&vreg_l18b_e0_1p2>;
+ qcom,port-mapping = <1 2 3 7 12 14>;
+ };
+
+ /* WSA8845, right tweeter */
+ right_tweeter: speaker@0,1 {
+ compatible = "sdw20217020400";
+ reg = <0 1>;
+ reset-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "TweeterRight";
+ vdd-1p8-supply = <&vreg_l15b_e0_1p8>;
+ vdd-io-supply = <&vreg_l18b_e0_1p2>;
+ qcom,port-mapping = <4 5 6 7 13 15>;
+ };
+};
+
+&tlmm {
+ gpio-reserved-ranges = <4 4>, /* EC TZ Secure I3C */
+ <10 2>, /* OOB UART */
+ <44 4>, /* Security SPI (TPM) */
+ <65 1>; /* EC reset */
+
+ edp_bl_en: edp-bl-en-state {
+ pins = "gpio18";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ ts0_default: ts0-default-state {
+ pins = "gpio51";
+ function = "gpio";
+ bias-disable;
+ };
+
+ tpad_default: tpad-default-state {
+ pins = "gpio66";
+ function = "gpio";
+ bias-disable;
+ };
+
+ kybd_default: kybd-default-state {
+ pins = "gpio67";
+ function = "gpio";
+ bias-disable;
+ };
+
+ edp_reg_en: edp-reg-en-state {
+ pins = "gpio70";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ lid_default: lid-default-state {
+ pins = "gpio92";
+ function = "gpio";
+ bias-disable;
+ };
+
+ wcn_sw_en: wcn-sw-en-state {
+ pins = "gpio94";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wcn_wlan_bt_en: wcn-wlan-bt-en-state {
+ pins = "gpio116", "gpio117";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ usb2_dp_hot_plug_detect: usb2-dp-hot-plug-detect-state {
+ pins = "gpio126";
+ function = "usb2_dp";
+ bias-disable;
+ };
+
+ pcie4_default: pcie4-default-state {
+ clkreq-n-pins {
+ pins = "gpio147";
+ function = "pcie4_clk_req_n";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-n-pins {
+ pins = "gpio146";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wake-n-pins {
+ pins = "gpio148";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ pcie5_default: pcie5-default-state {
+ clkreq-n-pins {
+ pins = "gpio153";
+ function = "pcie5_clk_req_n";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-n-pins {
+ pins = "gpio152";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wake-n-pins {
+ pins = "gpio154";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+};
+
+&uart14 {
+ status = "okay";
+
+ bluetooth {
+ compatible = "qcom,wcn7850-bt";
+ max-speed = <3200000>;
+
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+ };
+};
+
+&usb_0 {
+ status = "okay";
+};
+
+&usb_0_dwc3_hs {
+ remote-endpoint = <&pmic_glink_hs_in>;
+};
+
+&usb_0_hsphy {
+ vdd-supply = <&vreg_l3f_e0_0p91>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ status = "okay";
+};
+
+&usb_0_qmpphy {
+ vdda-phy-supply = <&vreg_l4h_e0_1p2>;
+ vdda-pll-supply = <&vreg_l3f_e0_0p91>;
+ refgen-supply = <&vreg_l2f_e0_0p94>;
+
+ status = "okay";
+};
+
+&usb_0_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss_in>;
+};
+
+&usb_1 {
+ status = "okay";
+};
+
+&usb_1_dwc3_hs {
+ remote-endpoint = <&pmic_glink_hs_in1>;
+};
+
+&usb_1_hsphy {
+ vdd-supply = <&vreg_l3f_e0_0p91>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ status = "okay";
+};
+
+&usb_1_qmpphy {
+ vdda-phy-supply = <&vreg_l4h_e0_1p2>;
+ vdda-pll-supply = <&vreg_l1h_e0_0p94>;
+ refgen-supply = <&vreg_l2f_e0_0p94>;
+
+ status = "okay";
+};
+
+&usb_1_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss_in1>;
+};
+
+/*
+ * usb_2 is not exposed as a connector; its combo-PHY's DP lanes drive the
+ * chassis HDMI bridge (see hdmi-bridge).
+ */
+&usb_2 {
+ maximum-speed = "high-speed";
+
+ phys = <&usb_2_hsphy>;
+ phy-names = "usb2-phy";
+
+ status = "okay";
+};
+
+&usb_2_hsphy {
+ vdd-supply = <&vreg_l3f_e0_0p91>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ status = "okay";
+};
+
+&usb_2_qmpphy {
+ vdda-phy-supply = <&vreg_l4h_e0_1p2>;
+ vdda-pll-supply = <&vreg_l3f_e0_0p91>;
+ refgen-supply = <&vreg_l2f_e0_0p94>;
+
+ /delete-property/ mode-switch;
+ /delete-property/ orientation-switch;
+
+ status = "okay";
+
+ ports {
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /delete-node/ endpoint;
+
+ usb_2_qmpphy_out_dp: endpoint@0 {
+ reg = <0>;
+
+ data-lanes = <3 2 1 0>;
+ remote-endpoint = <&hdmi_bridge_in>;
+ };
+ };
+ };
+};
+
+/* Internal USB2 host for the Elan fingerprint reader (usb 04f3:0ca8). */
+&usb_hs {
+ status = "okay";
+};
+
+&usb_hs_phy {
+ vdd-supply = <&vreg_l2h_e0_0p88>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ status = "okay";
+};
+
+/*
+ * Multiport USB host: port 0 is the chassis USB-A port; port 1 is an
+ * internal USB HID device.
+ */
+&usb_mp {
+ status = "okay";
+};
+
+&usb_mp_hsphy0 {
+ vdd-supply = <&vreg_l2h_e0_0p88>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ status = "okay";
+};
+
+&usb_mp_hsphy1 {
+ vdd-supply = <&vreg_l2h_e0_0p88>;
+ vdda12-supply = <&vreg_l4h_e0_1p2>;
+
+ status = "okay";
+};
+
+&usb_mp_qmpphy0 {
+ vdda-phy-supply = <&vreg_l4h_e0_1p2>;
+ vdda-pll-supply = <&vreg_l2h_e0_0p88>;
+ refgen-supply = <&vreg_l4f_e1_1p2>;
+
+ status = "okay";
+};
+
+&usb_mp_qmpphy1 {
+ vdda-phy-supply = <&vreg_l4h_e0_1p2>;
+ vdda-pll-supply = <&vreg_l2h_e0_0p88>;
+ refgen-supply = <&vreg_l4f_e1_1p2>;
+
+ status = "okay";
+};
--
2.50.1
^ permalink raw reply related
* [PATCH 3/3] firmware: qcom: scm: Allow QSEECOM on HP EliteBook X G2q 14 AI
From: Jason Pettit @ 2026-06-21 4:50 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Akhil P Oommen,
Mahadevan P, Sibi Sankar, Jingyi Wang, Ananthu C V, Jason Pettit
In-Reply-To: <20260620-glymur-send-v1-0-fc4a2cfd107c@oss.qualcomm.com>
The HP EliteBook X G2q 14" Next Gen AI PC is a Snapdragon X2 Elite
(Glymur) laptop whose firmware exposes EFI variables through QSEECOM.
Add its board compatible to the QSEECOM allowlist so that EFI variable
access (efivarfs) works on this machine.
Without it the kernel reports "qseecom: untested machine, skipping" and
efivarfs is empty.
Signed-off-by: Jason Pettit <jason.pettit@oss.qualcomm.com>
Assisted-by: Claude:claude-opus-4-8
---
drivers/firmware/qcom/qcom_scm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 6b601a4b89db..618437f5aac8 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2296,6 +2296,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
{ .compatible = "dell,xps13-9345" },
{ .compatible = "ecs,liva-qc710" },
{ .compatible = "hp,elitebook-ultra-g1q" },
+ { .compatible = "hp,elitebook-x-g2q" },
{ .compatible = "hp,omnibook-x14" },
{ .compatible = "huawei,gaokun3" },
{ .compatible = "lenovo,flex-5g" },
--
2.50.1
^ permalink raw reply related
* Re: [PATCH 2/3] arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
From: sashiko-bot @ 2026-06-21 5:08 UTC (permalink / raw)
To: Jason Pettit; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260620-glymur-send-v1-2-fc4a2cfd107c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing `port@2` (SBU mux) in `pmic-glink` Type-C connectors, breaking DisplayPort alt-mode AUX routing on cable flip.
--
commit e810bc690ae1ce5520333f631dcdd9b455aa35d1
Author: Jason Pettit <jason.pettit@oss.qualcomm.com>
arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
This commit adds the device tree for the HP EliteBook X G2q 14" Next Gen AI PC
based on the Snapdragon X2 Elite (Glymur) platform.
> diff --git a/arch/arm64/boot/dts/qcom/glymur-hp-elitebook-x-g2q.dts b/arch/arm64/boot/dts/qcom/glymur-hp-elitebook-x-g2q.dts
> new file mode 100644
> index 0000000000000..795940a999466
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/glymur-hp-elitebook-x-g2q.dts
[ ... ]
> + pmic-glink {
> + compatible = "qcom,glymur-pmic-glink",
> + "qcom,pmic-glink";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* Left side display-adjacent port */
> + connector@0 {
> + compatible = "usb-c-connector";
> + reg = <0>;
> + power-role = "dual";
> + data-role = "dual";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + pmic_glink_hs_in: endpoint {
> + remote-endpoint = <&usb_0_dwc3_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + pmic_glink_ss_in: endpoint {
> + remote-endpoint = <&usb_0_qmpphy_out>;
> + };
> + };
> + };
> + };
[Severity: Medium]
The commit message mentions "2x USB Type-C with DisplayPort alt-mode", but
are connector@0 and connector@1 missing port@2 and an SBU mux (e.g.,
gpio-sbu-mux) here for the DisplayPort AUX channel?
Without the SBU mux defined in the graph, the pmic_glink_altmode driver
cannot locate it to flip the SBU lines when the Type-C cable is inserted
upside-down. Does this cause DisplayPort alt-mode to fail link training in
one of the cable orientations?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260620-glymur-send-v1-0-fc4a2cfd107c@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [PATCH v4 4/6] arm64: dts: qcom: shikra: Add pin configuration for mclks
From: Nihal Kumar Gupta @ 2026-06-21 6:00 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robert Foss, Andi Shyti,
Bryan O'Donoghue, Bjorn Andersson, Konrad Dybcio, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <6e760884-87b1-4ec8-9ae1-e53901451b65@oss.qualcomm.com>
On 19-06-2026 21:06, Konrad Dybcio wrote:
>> + cam_mclk3_default: cam-mclk3-default-state {
>> + pins = "gpio98";
>> + function = "cam_mclk";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
> Please try to keep the entries roughly sorted by the pin index
>
> For the entries themselves:
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
ACK, will fix pin ordering in v5 - qup_uart0 (gpio0/1/...) first,
then cci_i2c(gpio36/37/41/42), then mclk0-3(gpio34/35/96/98).
Could you please review the other DTS patches too?
--
Regards,
Nihal Kumar Gupta
^ permalink raw reply
* Re: [PATCH v8 0/9] Add support for MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-06-21 7:55 UTC (permalink / raw)
To: linux-mediatek
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown,
Linus Walleij, Louis-Alexis Eyraud, Val Packett, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260620200032.334192-1-l.scorcia@gmail.com>
Sashiko review of v8 pointed out some easy-to-fix but real issues.
Please ignore this series as I have fixed them and I will send out v9.
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
^ permalink raw reply
* [PATCH v9 0/9] Add support for MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-06-21 8:13 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown,
Linus Walleij, Louis-Alexis Eyraud, Val Packett, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
The MediaTek MT6392 PMIC is usually found on devices powered by
the MT8516/MT8167 SoC and is yet another MT6323/MT6397 variant.
This series is mostly based around patches submitted a couple
years ago by Fabien Parent and not merged and from Val Packett's
submission from Jan 2025 that included extra cleanups, fixes, and a
new dtsi file similar to ones that exist for other PMICs. Some
comments weren't addressed and the series was ultimately not merged.
These patches enable four functions: keys, regulator, pinctrl and RTC.
Mono speaker amp will follow later as I need to work further on the
audio codec.
I added a handful of device tree improvements to fix some dtbs_check
errors, added support for the pinctrl device and addressed the comments
from last year's reviews.
Please note that patch 0006 and 0008 depend on patch 0005 as they need the
registers.h file, but belong to different driver areas. I'm not sure if
I'm supposed to squash them even if they belong to different driver
areas of if it's fine like this. Any advice is welcome.
Patch 0009 also depends on patch 0003 because of mt6392-regulator.h.
The series has been tested on Xiaomi Mi Smart Clock X04G and on the
Lenovo Smart Clock 2 CD-24502F.
Changes in v9:
- Correct binding for vrtc as it does not support mode setting.
From sashiko:
- Added missing include in MFD documentation example.
- Fixed constraints for regulator-initial-mode in regulator binding.
- Fixed wrong register write while setting LDO standby mode.
- Added missing pmic interrupt definition in the pumpkin-common include.
Changes in v8 [9]:
From reviewers:
- Added example code to the MFD device binding, removed it from the
regulators docs.
- Added minItems/maxItems constraints on the regulator mode definitions,
improved the mode constants.
- Fixed formatting issues in the regulator binding.
- Import the mt6392.dtsi file in pumpkin-common.dtsi, as it was originally
meant in [8].
From sashiko:
- Added more explicit constraints on the regulator modes definitions.
- Use the appropriate modeget register for LDO regulators, Buck registers
don't have the corresponding register according to the data sheet.
- Added the missing of_map_mode function.
- Removed some debugging code that had no use and masked error codes.
Changes in v7 [7]:
- Removed patch 0008 dependency on patch 0003.
- Reintroduced the regulator driver. In earlier revisions of this series,
it was proposed to remove the dedicated compatible for the regulator
device [3]. The driver does not use actually it, but it is not possible
at this time to remove it from the bindings since it's a required
property.
Making the regulator-required property conditional was NACKed in [5],
with the suggestion to create a separate binding altogether for devices
that do not require the compatible property. I tried implementing this,
but since the parent device needs to be declared as compatible with
mt6323, it leads to a warning in dt_binding_check since mt6323 would
be declared as a compatible in both mt6392 and mt6397.
In the end the only regulator driver from the mt6397 documentation that
still declares an of_match is mt6397-regulator and it does not seem
to be necessary, so it should be possible to remove it and make the
regulator compatible optional for all regulators, but that change would
probably deserve its own separate patch series.
Changes in v6 [6]:
- Dropped the regulators driver for the moment
- Explained the FCHR key name origin in the commit message
- Introduced the MFD_CELL_* macro in the sub-devices definitions.
A separate, independent commit introduced MFD_CELL_* to all the
subdevices in the mt6397-core.c file for consistency
- Replaced of_device_get_match_data with device_get_match_data
- Removed the mfd_match_data enum in favor of the preexisting
chip_id enum
- Adjusted the error message if the device is unsupported
Changes in v5 [5]:
- Double checked regulator driver with data sheet and Android sources.
The data sheet I have misses a lot of register descriptions, but
Android sources have been helpful to fill the gaps
- Reintroduced the required attribute for the regulator compatible
in the bindings
- Fixed the missing reference to the MT6392 schema
- Fixed casts/unused vars reported by kernel test robot
- Removed Reviewed-by tags from the regulator patches as they have been
modified in this version
Changes in v4 [4]:
- Dropped usage of the regulator compatible
- Fixed commit messages text to properly reference the target subsystem
- Added supply rails to the regulator
- Reworked the regulator schema and PMIC dtsi. Now all supplies are
documented and the schema no longer includes voltage information
- Removed redundant ldo- / buck- prefixes
- Renamed the pinfunc header to mediatek,mt6392-pinfunc.h
- Modified the MFD driver to use a simple identifier in the of_match
data properties
Changes in v3 [3]:
- Added pinctrl device
- Changed mt6397-rtc fallback to mt6323-rtc
- Added schema for regulators
- Fixed checkpatch issues
Changes in v2 [2]:
- Replaced explicit compatibles with fallbacks
Initial version: [1]
[1] https://lore.kernel.org/linux-mediatek/cover.1771865014.git.l.scorcia@gmail.com/
[2] https://lore.kernel.org/linux-mediatek/20260306120521.163654-1-l.scorcia@gmail.com/
[3] https://lore.kernel.org/linux-mediatek/20260317184507.523060-1-l.scorcia@gmail.com/
[4] https://lore.kernel.org/linux-mediatek/20260330083429.359819-1-l.scorcia@gmail.com/
[5] https://lore.kernel.org/linux-mediatek/20260420213529.1645560-1-l.scorcia@gmail.com/
[6] https://lore.kernel.org/linux-mediatek/20260612200717.361018-1-l.scorcia@gmail.com/
[7] https://lore.kernel.org/linux-mediatek/20260615071836.362883-1-l.scorcia@gmail.com/
[8] https://lore.kernel.org/linux-mediatek/20190323211612.860-25-fparent@baylibre.com/
[9] https://lore.kernel.org/linux-mediatek/20260620200032.334192-1-l.scorcia@gmail.com/
Fabien Parent (3):
dt-bindings: input: mtk-pmic-keys: Add MT6392 PMIC keys
mfd: mt6397: Add support for MT6392 PMIC
regulator: Add MediaTek MT6392 regulator
Luca Leonardo Scorcia (4):
dt-bindings: mfd: mt6397: Add MT6392 PMIC
regulator: dt-bindings: Add MediaTek MT6392 PMIC
mfd: mt6397: Use MFD_CELL_* to describe sub-devices
pinctrl: mediatek: mt6397: Add MediaTek MT6392
Val Packett (2):
input: keyboard: mtk-pmic-keys: Add MT6392 support
arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
.../bindings/input/mediatek,pmic-keys.yaml | 1 +
.../bindings/mfd/mediatek,mt6397.yaml | 75 ++
.../regulator/mediatek,mt6392-regulator.yaml | 112 +++
arch/arm64/boot/dts/mediatek/mt6392.dtsi | 145 ++++
.../boot/dts/mediatek/pumpkin-common.dtsi | 7 +
drivers/input/keyboard/mtk-pmic-keys.c | 17 +
drivers/mfd/mt6397-core.c | 295 ++++---
drivers/mfd/mt6397-irq.c | 8 +
drivers/pinctrl/mediatek/pinctrl-mt6397.c | 37 +-
drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h | 64 ++
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/mt6392-regulator.c | 764 ++++++++++++++++++
.../regulator/mediatek,mt6392-regulator.h | 23 +
include/linux/mfd/mt6392/core.h | 43 +
include/linux/mfd/mt6392/registers.h | 488 +++++++++++
include/linux/mfd/mt6397/core.h | 1 +
include/linux/regulator/mt6392-regulator.h | 42 +
18 files changed, 1970 insertions(+), 162 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h
create mode 100644 drivers/regulator/mt6392-regulator.c
create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
create mode 100644 include/linux/mfd/mt6392/core.h
create mode 100644 include/linux/mfd/mt6392/registers.h
create mode 100644 include/linux/regulator/mt6392-regulator.h
--
2.43.0
^ permalink raw reply
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