* [PATCH 0/3] ASoC: use scoped OF node handling in manual cleanup paths
From: Cássio Gabriel @ 2026-06-08 13:39 UTC (permalink / raw)
To: Srinivas Kandagatla, Mark Brown, Takashi Iwai, Liam Girdwood,
Jaroslav Kysela, Herve Codina, Shengjiu Wang, Xiubo Li,
Fabio Estevam, Nicolin Chen, Ray Jui, Scott Branden,
Broadcom internal kernel review list
Cc: linux-sound, linux-arm-msm, linux-kernel, linuxppc-dev,
linux-arm-kernel, notify, Cássio Gabriel
Some ASoC drivers still manually release child OF nodes
when leaving child-node iteration loops early.
Convert these focused cases to scoped OF node cleanup
so early returns and normal loop exits keep the same node
lifetime handling without explicit of_node_put() calls.
- Patch 1 updates qcom_snd_parse_of() to use
for_each_available_child_of_node_scoped() for link nodes and
__free(device_node) for temporary cpu/platform/codec child nodes.
- Patch 2 updates fsl_qmc_audio to use
for_each_available_child_of_node_scoped() for DAI child-node parsing.
- Patch 3 updates cygnus-ssp to use
for_each_available_child_of_node_scoped() for SSP child-node parsing.
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
---
Cássio Gabriel (3):
ASoC: qcom: common: use scoped OF node handling
ASoC: fsl: fsl_qmc_audio: use scoped child node loop
ASoC: bcm: cygnus: use scoped child node loop
sound/soc/bcm/cygnus-ssp.c | 10 ++++-----
sound/soc/fsl/fsl_qmc_audio.c | 7 ++-----
sound/soc/qcom/common.c | 47 ++++++++++++++-----------------------------
3 files changed, 21 insertions(+), 43 deletions(-)
---
base-commit: 112b3b39550d94f94eb7e44fd865716835d9aab2
Best regards,
--
Cássio Gabriel <cassiogabrielcontato@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro @ 2026-06-08 13:29 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260526-smmu_interconnect_addition-v2-2-2a6d8ca30d63@oss.qualcomm.com>
...
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
> 2 files changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -53,6 +53,11 @@
> #define MSI_IOVA_BASE 0x8000000
> #define MSI_IOVA_LENGTH 0x100000
>
> +/* Interconnect bandwidth vote values for the SMMU register access path */
> +#define ARM_SMMU_ICC_AVG_BW 0
> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
> +#define ARM_SMMU_ICC_PEAK_BW_LOW 0
> +
> static int force_stage;
> module_param(force_stage, int, S_IRUGO);
> MODULE_PARM_DESC(force_stage,
> @@ -86,6 +91,36 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
> }
> }
>
> +static int arm_smmu_icc_get(struct arm_smmu_device *smmu)
> +{
> + smmu->icc_path = devm_of_icc_get(smmu->dev, NULL);
> + if (IS_ERR(smmu->icc_path)) {
> + int err = PTR_ERR(smmu->icc_path);
> +
> + if (err == -ENODEV) {
> + smmu->icc_path = NULL;
> + return 0;
> + }
> + return dev_err_probe(smmu->dev, err,
> + "failed to get interconnect path\n");
> + }
> + return 0;
> +}
> +
> +static void arm_smmu_icc_enable(struct arm_smmu_device *smmu)
> +{
> + if (smmu->icc_path)
> + WARN_ON(icc_set_bw(smmu->icc_path, ARM_SMMU_ICC_AVG_BW,
> + ARM_SMMU_ICC_PEAK_BW_HIGH));
> +}
> +
> +static void arm_smmu_icc_disable(struct arm_smmu_device *smmu)
> +{
> + if (smmu->icc_path)
> + WARN_ON(icc_set_bw(smmu->icc_path, ARM_SMMU_ICC_AVG_BW,
> + ARM_SMMU_ICC_PEAK_BW_LOW));
> +}
> +
> static void arm_smmu_rpm_use_autosuspend(struct arm_smmu_device *smmu)
> {
> /*
> @@ -2189,6 +2224,17 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> if (err)
> return err;
>
> + /*
> + * Acquire and vote the interconnect path before accessing any SMMU
> + * registers (including ARM_SMMU_GR0_ID0 in arm_smmu_device_cfg_probe).
> + */
> + err = arm_smmu_icc_get(smmu);
> + if (err) {
> + clk_bulk_disable_unprepare(smmu->num_clks, smmu->clks);
> + return err;
> + }
> + arm_smmu_icc_enable(smmu);
> +
> err = arm_smmu_device_cfg_probe(smmu);
> if (err)
> return err;
> @@ -2273,8 +2319,10 @@ static void arm_smmu_device_shutdown(struct platform_device *pdev)
>
> if (pm_runtime_enabled(smmu->dev))
> pm_runtime_force_suspend(smmu->dev);
> - else
> + else {
> clk_bulk_disable(smmu->num_clks, smmu->clks);
> + arm_smmu_icc_disable(smmu);
> + }
>
> clk_bulk_unprepare(smmu->num_clks, smmu->clks);
> }
> @@ -2294,9 +2342,13 @@ static int __maybe_unused arm_smmu_runtime_resume(struct device *dev)
> struct arm_smmu_device *smmu = dev_get_drvdata(dev);
> int ret;
>
> + arm_smmu_icc_enable(smmu);
> +
> ret = clk_bulk_enable(smmu->num_clks, smmu->clks);
> - if (ret)
> + if (ret) {
> + arm_smmu_icc_disable(smmu);
> return ret;
> + }
>
> arm_smmu_device_reset(smmu);
>
> @@ -2308,6 +2360,7 @@ static int __maybe_unused arm_smmu_runtime_suspend(struct device *dev)
> struct arm_smmu_device *smmu = dev_get_drvdata(dev);
>
> clk_bulk_disable(smmu->num_clks, smmu->clks);
> + arm_smmu_icc_disable(smmu);
>
> return 0;
> }
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index 26d2e33cd328b8278888585fc07a31485d9397e2..c00606a416b2f4bb44a35e5d67f6ef801df68e1c 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -15,6 +15,7 @@
> #include <linux/bits.h>
> #include <linux/clk.h>
> #include <linux/device.h>
> +#include <linux/interconnect.h>
> #include <linux/io-64-nonatomic-hi-lo.h>
> #include <linux/io-pgtable.h>
> #include <linux/iommu.h>
> @@ -335,6 +336,7 @@ struct arm_smmu_device {
> int num_clks;
> unsigned int *irqs;
> struct clk_bulk_data *clks;
> + struct icc_path *icc_path;
>
> spinlock_t global_sync_lock;
>
>
Any feedback or concerns on the interconnect voting approach proposed here?
This helps to address the kernel panic issue [1] reported for one of
Qualcomm platforms.
[1]: https://github.com/qualcomm-linux/kernel/issues/297
Thanks,
Bibek
^ permalink raw reply
* Re: [PATCH RFC 1/4] printk: remove BOOT_PRINTK_DELAY config option
From: Petr Mladek @ 2026-06-08 13:22 UTC (permalink / raw)
To: Andrew Murray
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <20260601-deprecate_boot_delay-v1-1-c34c187142a6@thegoodpenguin.co.uk>
On Mon 2026-06-01 00:17:37, Andrew Murray wrote:
> The boot_delay (BOOT_PRINTK_DELAY) kernel parameter and printk_delay sysctl
> are two distinct mechanisms for providing similar functionality which add a
> delay prior to each printed printk message.
>
> In preparation of combining them into a single configurable feature, let's
> first remove the kconfig option BOOT_PRINTK_DELAY.
>
> Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
The option allowed to reduce a bit the vmlinux size when people were
not interested into the functionality. I am not sure if it is worth
it though. I am personally fine with this change.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v5 1/6] optee: ffa: Add NULL check in optee_ffa_lend_protmem
From: Jens Wiklander @ 2026-06-08 13:16 UTC (permalink / raw)
To: Sebastian Ene
Cc: Mostafa Saleh, op-tee, linux-kernel, kvmarm, linux-arm-kernel,
maz, oupton, joey.gouly, suzuki.poulose, catalin.marinas,
sumit.garg, vdonnefort, sudeep.holla
In-Reply-To: <aiK6lgW5YFWSMTxf@google.com>
On Fri, Jun 5, 2026 at 2:01 PM Sebastian Ene <sebastianene@google.com> wrote:
>
> On Tue, May 26, 2026 at 03:19:29PM +0000, Mostafa Saleh wrote:
> > Sashiko (locally) reports a possible null dereference under memory
> > pressure due to the lack of validation of the allocated pointer.
> >
> > Fix that by adding the missing check.
> >
> > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > ---
> > drivers/tee/optee/ffa_abi.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c
> > index b4372fa268d0..633715b98625 100644
> > --- a/drivers/tee/optee/ffa_abi.c
> > +++ b/drivers/tee/optee/ffa_abi.c
> > @@ -698,6 +698,9 @@ static int optee_ffa_lend_protmem(struct optee *optee, struct tee_shm *protmem,
> > int rc;
> >
> > mem_attr = kzalloc_objs(*mem_attr, ma_count);
> > + if (!mem_attr)
> > + return -ENOMEM;
> > +
> > for (n = 0; n < ma_count; n++) {
> > mem_attr[n].receiver = mem_attrs[n] & U16_MAX;
> > mem_attr[n].attrs = mem_attrs[n] >> 16;
> > --
> > 2.54.0.746.g67dd491aae-goog
> >
>
> Thanks for fixing this and for including my other patches in the series
> Reviewed-by: Sebastian Ene <sebastianene@google.com>
Please add a Fixes: tag. This patch is independent of the others in
the patch set, so if you send it alone with the Fixes: tag I'll pick
it up.
Cheers,
Jens
^ permalink raw reply
* Re: [PATCH v6 6/8] perf cs-etm: Filter synthesized branch samples
From: Leo Yan @ 2026-06-08 13:09 UTC (permalink / raw)
To: James Clark
Cc: linux-arm-kernel, coresight, linux-perf-users, Leo Yan,
Arnaldo Carvalho de Melo, John Garry, Will Deacon, Mike Leach,
Suzuki K Poulose, Namhyung Kim, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov
In-Reply-To: <b122283d-f3a7-4174-8c13-2ae9f6d1e79b@linaro.org>
On Mon, Jun 08, 2026 at 01:35:24PM +0100, James Clark wrote:
[...]
> Ah I missed that. In that case maybe it makes sense to break it and treat it
> as a bug fix. 'c' is quite clearly documented as calls only, and the
> workaround you suggested above makes it impossible to get only calls so it
> makes separate options for call and return a bit useless.
Okay, I'll change this as the first patch and include a Fixes tag.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v14 29/44] arm64: RMI: Runtime faulting of memory
From: Suzuki K Poulose @ 2026-06-08 12:58 UTC (permalink / raw)
To: Steven Price, Gavin Shan, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Shanker Donthineni, Alper Gun,
Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve, WeiLin.Chang,
Lorenzo.Pieralisi2
In-Reply-To: <21abf014-a68c-49b6-a113-4ec59c520a30@arm.com>
On 08/06/2026 11:56, Steven Price wrote:
> On 08/06/2026 10:30, Suzuki K Poulose wrote:
>> On 05/06/2026 07:23, Gavin Shan wrote:
>>> Hi Steve,
>>>
>>> On 5/13/26 11:17 PM, Steven Price wrote:
>>>> At runtime if the realm guest accesses memory which hasn't yet been
>>>> mapped then KVM needs to either populate the region or fault the guest.
>>>>
>>>> For memory in the lower (protected) region of IPA a fresh page is
>>>> provided to the RMM which will zero the contents. For memory in the
>>>> upper (shared) region of IPA, the memory from the memslot is mapped
>>>> into the realm VM non secure.
>>>>
>>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>>> ---
>>>> Changes since v13:
>>>> * Numerous changes due to rebasing.
>>>> * Fix addr_range_desc() to encode the correct block size.
>>>> Changes since v12:
>>>> * Switch to RMM v2.0 range based APIs.
>>>> Changes since v11:
>>>> * Adapt to upstream changes.
>>>> Changes since v10:
>>>> * RME->RMI renaming.
>>>> * Adapt to upstream gmem changes.
>>>> Changes since v9:
>>>> * Fix call to kvm_stage2_unmap_range() in kvm_free_stage2_pgd() to set
>>>> may_block to avoid stall warnings.
>>>> * Minor coding style fixes.
>>>> Changes since v8:
>>>> * Propagate the may_block flag.
>>>> * Minor comments and coding style changes.
>>>> Changes since v7:
>>>> * Remove redundant WARN_ONs for realm_create_rtt_levels() - it will
>>>> internally WARN when necessary.
>>>> Changes since v6:
>>>> * Handle PAGE_SIZE being larger than RMM granule size.
>>>> * Some minor renaming following review comments.
>>>> Changes since v5:
>>>> * Reduce use of struct page in preparation for supporting the RMM
>>>> having a different page size to the host.
>>>> * Handle a race when delegating a page where another CPU has
>>>> faulted on
>>>> a the same page (and already delegated the physical page) but not
>>>> yet
>>>> mapped it. In this case simply return to the guest to either use the
>>>> mapping from the other CPU (or refault if the race is lost).
>>>> * The changes to populate_par_region() are moved into the previous
>>>> patch where they belong.
>>>> Changes since v4:
>>>> * Code cleanup following review feedback.
>>>> * Drop the PTE_SHARED bit when creating unprotected page table
>>>> entries.
>>>> This is now set by the RMM and the host has no control of it and the
>>>> spec requires the bit to be set to zero.
>>>> Changes since v2:
>>>> * Avoid leaking memory if failing to map it in the realm.
>>>> * Correctly mask RTT based on LPA2 flag (see rtt_get_phys()).
>>>> * Adapt to changes in previous patches.
>>>> ---
>>>> arch/arm64/include/asm/kvm_emulate.h | 8 ++
>>>> arch/arm64/include/asm/kvm_rmi.h | 12 ++
>>>> arch/arm64/kvm/mmu.c | 128 ++++++++++++++++----
>>>> arch/arm64/kvm/rmi.c | 173 +++++++++++++++++++++++++++
>>>> 4 files changed, 301 insertions(+), 20 deletions(-)
>>>>
>
> [...]
>
>>>> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
>>>> index cae29fd3353c..761b38a4071c 100644
>>>> --- a/arch/arm64/kvm/rmi.c
>>>> +++ b/arch/arm64/kvm/rmi.c
>>>> @@ -597,6 +597,179 @@ static int realm_data_map_init(struct kvm *kvm,
>>>> unsigned long ipa,
>>>> return ret;
>>>> }
>>>> +static unsigned long addr_range_desc(unsigned long phys, unsigned
>>>> long size)
>>>> +{
>>>> + unsigned long out = 0;
>>>> +
>>>> + switch (size) {
>>>> + case P4D_SIZE:
>>>> + out = 3 | (1 << 2);
>>>> + break;
>>>> + case PUD_SIZE:
>>>> + out = 2 | (1 << 2);
>>>> + break;
>>>> + case PMD_SIZE:
>>>> + out = 1 | (1 << 2);
>>>> + break;
>>>> + case PAGE_SIZE:
>>>> + out = 0 | (1 << 2);
>>>> + break;
>>>> + default:
>>>> + /*
>>>> + * Only support mapping at the page level granulatity when
>>>> + * it's an unusual length. This should get us back onto a
>>>> larger
>>>> + * block size for the subsequent mappings.
>>>> + */
>>>> + out = 0 | ((MIN(size >> PAGE_SHIFT, PTRS_PER_PTE - 1)) << 2);
>>>> + break;
>>>> + }
>>>> +
>>>> + WARN_ON(phys & ~PAGE_MASK);
>>>> +
>>>> + out |= phys & PAGE_MASK;
>>>> +
>>>> + return out;
>>>> +}
>>>> +
>>>> +int realm_map_protected(struct kvm *kvm,
>>>> + unsigned long ipa,
>>>> + kvm_pfn_t pfn,
>>>> + unsigned long map_size,
>>>> + struct kvm_mmu_memory_cache *memcache)
>>>> +{
>>>> + struct realm *realm = &kvm->arch.realm;
>>>> + phys_addr_t phys = __pfn_to_phys(pfn);
>>>> + phys_addr_t base_phys = phys;
>>>> + phys_addr_t rd = virt_to_phys(realm->rd);
>>>> + unsigned long base_ipa = ipa;
>>>> + unsigned long ipa_top = ipa + map_size;
>>>> + int ret = 0;
>>>> +
>>>> + if (WARN_ON(!IS_ALIGNED(map_size, PAGE_SIZE) ||
>>>> + !IS_ALIGNED(ipa, map_size)))
>>>> + return -EINVAL;
>>>> +
>>>> + if (rmi_delegate_range(phys, map_size)) {
>>>> + /*
>>>> + * It's likely we raced with another VCPU on the same
>>>> + * fault. Assume the other VCPU has handled the fault
>>>> + * and return to the guest.
>>>> + */
>>>> + return 0;
>>>> + }
>>>> +
>>>> + while (ipa < ipa_top) {
>>>> + unsigned long flags = RMI_ADDR_TYPE_SINGLE;
>>>> + unsigned long range_desc = addr_range_desc(phys, ipa_top -
>>>> ipa);
>>>> + unsigned long out_top;
>>>> +
>>>> + ret = rmi_rtt_data_map(rd, ipa, ipa_top, flags, range_desc,
>>>> + &out_top);
>>>> +
>>>> + if (RMI_RETURN_STATUS(ret) == RMI_ERROR_RTT) {
>>>> + /* Create missing RTTs and retry */
>>>> + int level = RMI_RETURN_INDEX(ret);
>>>> +
>>>> + WARN_ON(level == KVM_PGTABLE_LAST_LEVEL);
>>>> + ret = realm_create_rtt_levels(realm, ipa, level,
>>>> + KVM_PGTABLE_LAST_LEVEL,
>>>> + memcache);
>>
>> Could we give the RMM a chance to make use of the Block mappings by
>> creating the Missing RTTs to the level that may work for the current
>> range_desc ? i.e., if the range_desc is a 2M block size, we could create
>> tables upto L2 in the first go and if the RMM still needs RTT, we could
>> go further down to the KVM_PGTABLE_LAST_LEVEL. I understand this is
>> kind of an optimisation, so may be we could defer it. (Same applies for
>> the non_secure map below).
>
> A simple change would be just to create one level at a time like this:
>
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index b79b96f7dffb..3f3ade1d3895 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -767,15 +767,15 @@ static int realm_map_protected(struct kvm *kvm,
> /* Create missing RTTs and retry */
> int level = RMI_RETURN_INDEX(ret);
>
> - WARN_ON(level == KVM_PGTABLE_LAST_LEVEL);
> + if (WARN_ON(level >= KVM_PGTABLE_LAST_LEVEL))
> + goto err_undelegate;
> ret = realm_create_rtt_levels(realm, ipa, level,
> - KVM_PGTABLE_LAST_LEVEL,
> + level + 1,
> memcache);
> if (ret)
> goto err_undelegate;
>
> - ret = rmi_rtt_data_map(rd, ipa, ipa_top, flags,
> - range_desc, &out_top);
> + continue;
> }
That looks good to me.
Cheers
Suzuki
>
> if (WARN_ON(ret))
>
> Thanks,
> Steve
>
^ permalink raw reply
* [GIT PULL] coresight: Updates for Linux v7.2
From: Suzuki K Poulose @ 2026-06-08 12:54 UTC (permalink / raw)
To: gregkh
Cc: linux-arm-kernel, coresight, james.clark, leo.yan, mike.leach,
Suzuki K Poulose
Hi Greg
Please find the updates for CoreSight self hosted tracing subsystem targeting
Linux v7.2
Kindly pull,
Suzuki
---
The following changes since commit 7fd2df204f342fc17d1a0bfcd474b24232fb0f32:
Linux 7.1-rc2 (2026-05-03 14:21:25 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v7.2
for you to fetch changes up to 98495b5a4d77dd22e106f462b76e1093a55b29a7:
coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer() (2026-06-04 09:56:13 +0100)
----------------------------------------------------------------
coresight: Self-hosted tracing updates for Linux v7.2
Updates for the CoreSight self hosted tracing subsystem includes:
- Better power management for components based on the CPU PM, including
support for components on the trace path for CPUs. Add support for
save/restore for TRBE
- Miscellaneous fixes to the drivers
* Fix overflow when the buffer size is > 2GB for tmc-etr
* Ultrasoc SMB Perf buffer OOB access
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
----------------------------------------------------------------
James Clark (1):
coresight: ete: Always save state on power down
Jie Gan (3):
coresight: fix missing error code when trace ID is invalid
coresight: Fix source not disabled on idr_alloc_u32 failure
coresight: platform: defer connection counter increment until alloc succeeds
Junrui Luo (1):
coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()
Leo Yan (28):
coresight: tmc: Fix overflow when calculating is bigger than 2GiB
coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore
coresight: Handle helper enable failure properly
coresight: Extract device init into coresight_init_device()
coresight: Populate CPU ID into coresight_device
coresight: Remove .cpu_id() callback from source ops
coresight: Take hotplug lock in enable_source_store() for Sysfs mode
coresight: perf: Retrieve path and source from event data
coresight: Take a reference on csdev
coresight: Move per-CPU source pointer to core layer
coresight: Take per-CPU source reference during AUX setup
coresight: Register CPU PM notifier in core layer
coresight: etm4x: Hook CPU PM callbacks
coresight: etm4x: Remove redundant checks in PM save and restore
coresight: syscfg: Use IRQ-safe spinlock to protect active variables
coresight: Disable source helpers in coresight_disable_path()
coresight: Control path with range
coresight: Use helpers to fetch first and last nodes
coresight: Introduce coresight_enable_source() helper
coresight: Save active path for system tracers
coresight: etm4x: Set active path on target CPU
coresight: etm3x: Set active path on target CPU
coresight: sysfs: Use source's path pointer for path control
coresight: Control path during CPU idle
coresight: Add PM callbacks for sink device
coresight: sysfs: Increment refcount only for software source
coresight: Move CPU hotplug callbacks to core layer
coresight: sysfs: Validate CPU online status for per-CPU sources
Runyu Xiao (1):
coresight: etb10: restore atomic_t for shared reading state
Yabin Cui (1):
coresight: trbe: Save and restore state across CPU low power state
Yingchao Deng (1):
coresight: cti: Fix DT filter signals silently ignored
drivers/hwtracing/coresight/coresight-catu.c | 2 +-
drivers/hwtracing/coresight/coresight-core.c | 574 ++++++++++++++++++---
drivers/hwtracing/coresight/coresight-cti-core.c | 9 +-
.../hwtracing/coresight/coresight-cti-platform.c | 1 +
drivers/hwtracing/coresight/coresight-etb10.c | 6 +-
drivers/hwtracing/coresight/coresight-etm-perf.c | 289 ++++++-----
drivers/hwtracing/coresight/coresight-etm3x-core.c | 73 +--
drivers/hwtracing/coresight/coresight-etm4x-core.c | 216 +++-----
drivers/hwtracing/coresight/coresight-platform.c | 12 +-
drivers/hwtracing/coresight/coresight-priv.h | 8 +-
drivers/hwtracing/coresight/coresight-syscfg.c | 38 +-
drivers/hwtracing/coresight/coresight-syscfg.h | 2 +
drivers/hwtracing/coresight/coresight-sysfs.c | 135 ++---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 4 +-
drivers/hwtracing/coresight/coresight-trbe.c | 61 ++-
drivers/hwtracing/coresight/ultrasoc-smb.c | 1 +
include/linux/coresight.h | 27 +-
include/linux/cpuhotplug.h | 2 +-
18 files changed, 939 insertions(+), 521 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 5/6] ACPI/IORT: Implement ACPI infrastructure to enable GICv5 IWB probe deferral
From: Rafael J. Wysocki @ 2026-06-08 12:50 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <20260603-gic-v5-acpi-iwb-probe-deferral-v2-5-23ffa16b6ebb@kernel.org>
On Wed, Jun 3, 2026 at 10:21 AM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> Implement an IORT ACPI hook to retrieve the acpi_handle of the interrupt
> controller handling a specific GSI (if any, on GICv5 systems only the IWB
> is represented in firmware with an ACPI device object) and add the IWB to
> the list of devices whose dependencies can be detected (and cleared) in
> ACPI core to guarantee that probe dependencies for the IWB can be
> satisfied.
>
> Enable autodep detection for arm64 by adding the arch_acpi_add_auto_dep()
> callback in the ACPI IORT driver.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Hanjun Guo <guohanjun@huawei.com>
> Cc: Sudeep Holla <sudeep.holla@kernel.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Acked-by: "Rafael J. Wysocki" (Intel) <rafael@kernel.org> # ACPI: scan.c
The rest of the series is kind of outside my scope and all of the
previous patches would at least require an ACK from the RISC-V people.
> ---
> drivers/acpi/arm64/iort.c | 22 +++++++++++++++++++---
> drivers/acpi/scan.c | 1 +
> include/linux/acpi_iort.h | 3 ++-
> 3 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index af7a9b2fd5bc..34412cd697d8 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -789,11 +789,9 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 id,
> return irq_find_matching_fwnode(handle, bus_token);
> }
>
> -struct fwnode_handle *iort_iwb_handle(u32 iwb_id)
> +acpi_handle iort_iwb_handle(u32 iwb_id)
> {
> - struct fwnode_handle *fwnode;
> struct acpi_iort_node *node;
> - struct acpi_device *device;
> struct acpi_iort_iwb *iwb;
> acpi_status status;
> acpi_handle handle;
> @@ -808,6 +806,19 @@ struct fwnode_handle *iort_iwb_handle(u32 iwb_id)
> if (ACPI_FAILURE(status))
> return NULL;
>
> + return handle;
> +}
> +
> +struct fwnode_handle *iort_iwb_handle_fwnode(u32 iwb_id)
> +{
> + struct fwnode_handle *fwnode;
> + struct acpi_device *device;
> + acpi_handle handle;
> +
> + handle = iort_iwb_handle(iwb_id);
> + if (!handle)
> + return NULL;
> +
> device = acpi_get_acpi_dev(handle);
> if (!device)
> return NULL;
> @@ -2090,6 +2101,11 @@ static void __init iort_init_platform_devices(void)
> }
> }
>
> +u32 arch_acpi_add_auto_dep(acpi_handle handle)
> +{
> + return acpi_irq_add_auto_dep(handle);
> +}
> +
> void __init acpi_iort_init(void)
> {
> acpi_status status;
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 530547cda8b2..ba15da9058dc 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -856,6 +856,7 @@ static const char * const acpi_ignore_dep_ids[] = {
>
> /* List of HIDs for which we honor deps of matching ACPI devs, when checking _DEP lists. */
> static const char * const acpi_honor_dep_ids[] = {
> + "ARMH0003", /* ARM GICv5 IWB */
> "INT3472", /* Camera sensor PMIC / clk and regulator info */
> "INTC1059", /* IVSC (TGL) driver must be loaded to allow i2c access to camera sensors */
> "INTC1095", /* IVSC (ADL) driver must be loaded to allow i2c access to camera sensors */
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 17bb3374f4ca..931eaa7bbf6a 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -27,7 +27,8 @@ int iort_register_domain_token(int trans_id, phys_addr_t base,
> struct fwnode_handle *fw_node);
> void iort_deregister_domain_token(int trans_id);
> struct fwnode_handle *iort_find_domain_token(int trans_id);
> -struct fwnode_handle *iort_iwb_handle(u32 iwb_id);
> +acpi_handle iort_iwb_handle(u32 iwb_id);
> +struct fwnode_handle *iort_iwb_handle_fwnode(u32 iwb_id);
>
> #ifdef CONFIG_ACPI_IORT
> u32 iort_msi_map_id(struct device *dev, u32 id);
>
> --
> 2.54.0
>
^ permalink raw reply
* [PATCH v3] drm/rockchip: Remove dependency on DRM simple helpers
From: Diogo Silva @ 2026-06-08 12:40 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, dri-devel, linux-arm-kernel, linux-rockchip,
linux-kernel, Diogo Silva
Simple KMS helper are deprecated since they only add an intermediate
layer between drivers and the atomic modesetting.
This patch removes the dependency on drm simple helpers from rockchip
DRM drivers.
Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
---
v3:
- rebase on drm-tip tree
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 ++++++---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 ++++++---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 9 +++++++--
drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c | 8 ++++++--
drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 1 -
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 1 -
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8 ++++++--
drivers/gpu/drm/rockchip/rockchip_lvds.c | 9 +++++++--
drivers/gpu/drm/rockchip/rockchip_rgb.c | 8 ++++++--
10 files changed, 44 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 776954c7d052..46c245e35d21 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -30,7 +30,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
@@ -303,6 +302,10 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs rockchip_dp_encoder_helper_funcs = {
.mode_fixup = rockchip_dp_drm_encoder_mode_fixup,
.mode_set = rockchip_dp_drm_encoder_mode_set,
@@ -361,8 +364,8 @@ static int rockchip_dp_drm_create_encoder(struct rockchip_dp_device *dp)
dev->of_node);
DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
- ret = drm_simple_encoder_init(drm_dev, encoder,
- DRM_MODE_ENCODER_TMDS);
+ ret = drm_encoder_init(drm_dev, encoder, &rockchip_dp_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
if (ret) {
DRM_ERROR("failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 190cce9530c8..c3f41a4449f5 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -23,7 +23,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "cdn-dp-core.h"
#include "cdn-dp-reg.h"
@@ -671,6 +670,10 @@ static int cdn_dp_encoder_atomic_check(struct drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs cdn_dp_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs cdn_dp_encoder_helper_funcs = {
.atomic_check = cdn_dp_encoder_atomic_check,
};
@@ -988,8 +991,8 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
dev->of_node);
DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
- ret = drm_simple_encoder_init(drm_dev, encoder,
- DRM_MODE_ENCODER_TMDS);
+ ret = drm_encoder_init(drm_dev, encoder, &cdn_dp_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
if (ret) {
DRM_ERROR("failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 3547d91b25d3..a09b382d208e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -25,7 +25,6 @@
#include <drm/drm_mipi_dsi.h>
#include <drm/drm_of.h>
#include <drm/drm_print.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
@@ -825,6 +824,10 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
clk_disable_unprepare(dsi->grf_clk);
}
+static const struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs
dw_mipi_dsi_encoder_helper_funcs = {
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
@@ -840,7 +843,9 @@ static int rockchip_dsi_drm_create_encoder(struct dw_mipi_dsi_rockchip *dsi,
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dsi->dev->of_node);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_DSI);
+ ret = drm_encoder_init(drm_dev, encoder,
+ &dw_mipi_dsi_encoder_funcs,
+ DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
DRM_ERROR("Failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
index d2e76d36d724..9dc207c2d20d 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
@@ -23,7 +23,6 @@
#include <drm/bridge/dw_mipi_dsi2.h>
#include <drm/drm_mipi_dsi.h>
#include <drm/drm_of.h>
-#include <drm/drm_simple_kms_helper.h>
#include <uapi/linux/videodev2.h>
@@ -275,6 +274,10 @@ dw_mipi_dsi2_encoder_atomic_check(struct drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs dw_mipi_dsi2_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs
dw_mipi_dsi2_encoder_helper_funcs = {
.atomic_enable = dw_mipi_dsi2_encoder_atomic_enable,
@@ -290,7 +293,8 @@ static int rockchip_dsi2_drm_create_encoder(struct dw_mipi_dsi2_rockchip *dsi2,
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dsi2->dev->of_node);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_DSI);
+ ret = drm_encoder_init(drm_dev, encoder, &dw_mipi_dsi2_encoder_funcs,
+ DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
dev_err(dsi2->dev, "Failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
index 0de822360c8d..b23efb153c9e 100644
--- a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
@@ -20,7 +20,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index cffc0af5190f..b6e154c35e7c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -18,7 +18,6 @@
#include <drm/drm_managed.h>
#include <drm/drm_of.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
index f35484715c2d..af34062685cd 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
@@ -24,7 +24,6 @@
#include <drm/drm_managed.h>
#include <drm/drm_of.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 1996f8656612..b4ba9f894360 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -12,7 +12,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include <linux/clk.h>
#include <linux/mfd/syscon.h>
@@ -454,6 +453,10 @@ rk3066_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs rk3066_hdmi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const
struct drm_encoder_helper_funcs rk3066_hdmi_encoder_helper_funcs = {
.atomic_check = rk3066_hdmi_encoder_atomic_check,
@@ -696,7 +699,8 @@ rk3066_hdmi_register(struct drm_device *drm, struct rk3066_hdmi *hdmi)
return -EPROBE_DEFER;
drm_encoder_helper_add(encoder, &rk3066_hdmi_encoder_helper_funcs);
- drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
+ drm_encoder_init(drm, encoder, &rk3066_hdmi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
hdmi->bridge.driver_private = hdmi;
hdmi->bridge.funcs = &rk3066_hdmi_bridge_funcs;
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 7a0c4fa29f2f..f3be2c91d147 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -24,7 +24,6 @@
#include <drm/drm_panel.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
#include "rockchip_lvds.h"
@@ -427,6 +426,10 @@ static void px30_lvds_encoder_disable(struct drm_encoder *encoder)
drm_panel_unprepare(lvds->panel);
}
+static const struct drm_encoder_funcs rockchip_lvds_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const
struct drm_encoder_helper_funcs rk3288_lvds_encoder_helper_funcs = {
.enable = rk3288_lvds_encoder_enable,
@@ -594,7 +597,9 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dev->of_node);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_LVDS);
+ ret = drm_encoder_init(drm_dev, encoder,
+ &rockchip_lvds_encoder_funcs,
+ DRM_MODE_ENCODER_LVDS, NULL);
if (ret < 0) {
drm_err(drm_dev,
"failed to initialize encoder: %d\n", ret);
diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c b/drivers/gpu/drm/rockchip/rockchip_rgb.c
index add3123e5ce7..2ad24b914989 100644
--- a/drivers/gpu/drm/rockchip/rockchip_rgb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
@@ -17,7 +17,6 @@
#include <drm/drm_panel.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
#include "rockchip_rgb.h"
@@ -65,6 +64,10 @@ rockchip_rgb_encoder_atomic_check(struct drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs rockchip_rgb_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const
struct drm_encoder_helper_funcs rockchip_rgb_encoder_helper_funcs = {
.atomic_check = rockchip_rgb_encoder_atomic_check,
@@ -127,7 +130,8 @@ struct rockchip_rgb *rockchip_rgb_init(struct device *dev,
encoder = &rgb->encoder.encoder;
encoder->possible_crtcs = drm_crtc_mask(crtc);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_NONE);
+ ret = drm_encoder_init(drm_dev, encoder, &rockchip_rgb_encoder_funcs,
+ DRM_MODE_ENCODER_NONE, NULL);
if (ret < 0) {
DRM_DEV_ERROR(drm_dev->dev,
"failed to initialize encoder: %d\n", ret);
--
2.51.2
^ permalink raw reply related
* Re: [PATCH v6 3/8] perf cs-etm: Use thread-stack for last branch entries
From: Leo Yan @ 2026-06-08 12:38 UTC (permalink / raw)
To: James Clark
Cc: linux-arm-kernel, coresight, linux-perf-users,
Arnaldo Carvalho de Melo, John Garry, Will Deacon, Mike Leach,
Suzuki K Poulose, Namhyung Kim, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov
In-Reply-To: <9d1e0448-27d7-42d3-aaa3-2d09489f18d9@linaro.org>
On Thu, Jun 04, 2026 at 03:09:26PM +0100, James Clark wrote:
[...]
> > @@ -1798,14 +1746,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
> > tidq->period_instructions += tidq->packet->instr_count;
> > - /*
> > - * Record a branch when the last instruction in
> > - * PREV_PACKET is a branch.
> > - */
> > - if (etm->synth_opts.last_branch &&
> > - tidq->prev_packet->sample_type == CS_ETM_RANGE &&
> > - tidq->prev_packet->last_instr_taken_branch)
> > - cs_etm__update_last_branch_rb(etmq, tidq);
> > + cs_etm__add_stack_event(etmq, tidq);
>
> Would it be cleaner to call this whenever a branch sample is generated?
We should not couple stack event and generating branch samples.
The reason is the stack event can be used separately by instruction
samples, e.g., the option "--itrace=i100il64g16". And the branch stack
and call chain must get ready before synthesing samples.
> Seems like the conditions for calling thread_stack__event() and
> cs_etm__synth_branch_sample() are slightly different (ignoring the fact that
> branches are only generated when the user asks for them).
>
> Maybe the conditions should be different, but maybe a comment why or if
> they're the same, a shared function for the conditions would help.
I can add a helper to check if a packet is taken branch and it can be
used by cs_etm__add_stack_event() and generating samples.
bool cs_etm__packet_is_taken_branch(struct cs_etm_packet *packet)
{
if (packet->sample_type == CS_ETM_RANGE &&
packet->last_instr_taken_branch)
return true;
return false;
}
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v6 6/8] perf cs-etm: Filter synthesized branch samples
From: James Clark @ 2026-06-08 12:35 UTC (permalink / raw)
To: Leo Yan
Cc: linux-arm-kernel, coresight, linux-perf-users, Leo Yan,
Arnaldo Carvalho de Melo, John Garry, Will Deacon, Mike Leach,
Suzuki K Poulose, Namhyung Kim, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov
In-Reply-To: <20260608112834.GM101133@e132581.arm.com>
On 08/06/2026 12:28 pm, Leo Yan wrote:
> On Thu, Jun 04, 2026 at 03:42:32PM +0100, James Clark wrote:
>
> [...]
>
>>> @@ -3442,6 +3447,16 @@ int cs_etm__process_auxtrace_info_full(union perf_event *event,
>>> etm->synth_opts.thread_stack = session->itrace_synth_opts->thread_stack;
>>> }
>>> + if (etm->synth_opts.calls)
>>> + etm->branches_filter |= PERF_IP_FLAG_CALL |
>>> + PERF_IP_FLAG_TRACE_BEGIN |
>>> + PERF_IP_FLAG_TRACE_END;
>>> +
>>> + if (etm->synth_opts.returns)
>>> + etm->branches_filter |= PERF_IP_FLAG_RETURN |
>>> + PERF_IP_FLAG_TRACE_BEGIN |
>>> + PERF_IP_FLAG_TRACE_END;
>>> +
>>
>> This changes the default "perf script" output quite significantly and will
>> possibly break people's workflows. synth_opts.calls is true by default but
>> synth_opts.returns is false so we lose all the returns that we used to have.
>> Not sure if the new behavior is more consistent with other tools so we can
>> justify changing it? Personally I think including returns by default made
>> more sense, and it's a more literal representation of the flow.
>
> Makes sense. I will add below chunk to enable return events for default
> option:
>
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index ab3aa76dddb3..bd9eb794cc07 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -3541,6 +3541,14 @@ int cs_etm__process_auxtrace_info_full(union perf_event *event,
> session->itrace_synth_opts->default_no_sample);
> etm->synth_opts.callchain = false;
> etm->synth_opts.thread_stack = session->itrace_synth_opts->thread_stack;
> +
> + /*
> + * By default, only call events are enabled but no return
> + * events. Enable return events to better represent the
> + * execution flow.
> + */
> + if (etm->synth_opts.calls)
> + etm->synth_opts.returns = true;
> }
>
>>
>> itrace.txt says the default is "all events i.e. the same as
>> --itrace=iybxwpe", but I thought the default was branches? At least for
>> Coresight it is, so I'm a bit confused.
>
> "--itrace=iybxwpe" would be used for "perf report" command, the doc also
> mentions "--itrace=ce" for "perf script" specific.
>
> Thanks,
> Leo
Ah I missed that. In that case maybe it makes sense to break it and
treat it as a bug fix. 'c' is quite clearly documented as calls only,
and the workaround you suggested above makes it impossible to get only
calls so it makes separate options for call and return a bit useless.
^ permalink raw reply
* Re: [PATCH 30/37] drm/bridge: add drm_bridge_is_tail() to know whether a bridge completes the pipeline
From: Maxime Ripard @ 2026-06-08 12:34 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260519-drm-bridge-hotplug-v1-30-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 4618 bytes --]
On Tue, May 19, 2026 at 12:37:47PM +0200, Luca Ceresoli wrote:
> For bridge hotplug we need to successfully probe a card with an incomplete
> bridge chain, i.e. a chain whose last bridge currently in bridge_chain
> needs a next_bridge to work. Such a card would have no connector, and be
> able to add one as soon as the followong bridges are added up to the tail
> bridge (e.g. a panel_bridge or a connector_bridge).
>
> Currently common DRM code is unable to tell whether the last bridge
> currently in the chain is the tail bridge (= the pipeline is complete) or
> not.
>
> Add drm_bridge_is_tail(), and a .is_tail func for it to rely on, so common
> code can know whether a bridge is a tail bridge or needs a next_bridge.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> drivers/gpu/drm/drm_bridge.c | 28 ++++++++++++++++++++++++++++
> include/drm/drm_bridge.h | 19 +++++++++++++++++++
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index c62d17e84d4f..2b539c9749a6 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -646,6 +646,34 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> drm_bridge_put(bridge);
> }
>
> +/**
> + * drm_bridge_is_tail - check whether the bridge is the last required to
> + * have a full pipeline
> + * @bridge: the bridge to check
> + *
> + * Tell whether this is a tail bridge, i.e. a bridge that does not need a
> + * next bridge to work. E.g. a panel_bridge is final, a DSI-to-LVDS bridge
> + * is not.
> + *
> + * In case of hotplug the last bridge currently in the chain (as in
> + * drm_bridge_chain_get_last_bridge()) might not be final, and be waiting
> + * for a pipeline tail to be connected.
> + *
> + * Return: true if this bridge does not need a next bridge to work, false
> + * otherwise
> + */
> +bool drm_bridge_is_tail(struct drm_bridge *bridge)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_IS_TAIL)) {
> + drm_warn_once(bridge->dev, "is_tail func not implemented by bridge %ps!",
> + bridge->funcs);
> + return false;
> + }
> +
> + return bridge->funcs->is_tail(bridge);
> +}
> +EXPORT_SYMBOL(drm_bridge_is_tail);
> +
> /**
> * DOC: bridge operations
> *
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 4ba3a5deef9a..d783a6fb93a0 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -78,6 +78,19 @@ struct drm_bridge_funcs {
> int (*attach)(struct drm_bridge *bridge, struct drm_encoder *encoder,
> enum drm_bridge_attach_flags flags);
>
> + /**
> + * @is_tail:
> + *
> + * Returns true if this is a tail bridge, i.e. it does not need a
> + * next bridge to work. E.g. a panel_bridge is a tail bridge, a
> + * DSI-to-LVDS bridge is not a tail bridge (no matter whether the
> + * next bridge is present or not).
Why a DSI-to-LDVS bridge isn't a tail bridge? It only needs a panel
next, right?
> + * The @is_tail callback is optional but it is required if the
> + * bridge is part of a pipeline with hot-pluggable components.
> + */
> + bool (*is_tail)(struct drm_bridge *bridge);
> +
I don't think that's the right way to think about it, if only because
you never really know at the driver level if you're supposed to be last
or not. A DSI-to-LVDS bridge might just as well be chained with an
LVDS-to-eDP bridge, or feed the panel directly without any additional
bridge.
I *think* that what you're trying to find out here is whether the chain
is complete or not. I think you can get the same information by checking
whether you have a connector for that bridge chain. If you don't, you
know the chain isn't complete, and if you do, it's supposed to be.
DRM_BRIDGE_ATTACH_NO_CONNECTOR could be useful too, because if all you
bridges support it but there's no connector, there's something wrong.
Anyway.
Maxime
> /**
> * @destroy:
> *
> @@ -1092,6 +1105,11 @@ enum drm_bridge_ops {
> * &drm_bridge_funcs->hdmi_clear_spd_infoframe callbacks.
> */
> DRM_BRIDGE_OP_HDMI_SPD_INFOFRAME = BIT(10),
> + /**
> + * @DRM_BRIDGE_OP_IS_TAIL: The bridge implements the
> + * &drm_bridge_funcs->is_tail callback.
> + */
> + DRM_BRIDGE_OP_IS_TAIL = BIT(11),
> };
That part is confusing to me. This is meant for drm_bridge_connector,
but since we need to handle the case where we don't have a connector
(and thus no drm_bridge_connector) I don't think this should be used at
all?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Sudeep Holla @ 2026-06-08 12:32 UTC (permalink / raw)
To: Aneesh Kumar K.V, Suzuki K Poulose
Cc: linux-coco, Sudeep Holla, linux-arm-kernel, linux-kernel,
Catalin Marinas, Greg KH, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Will Deacon, Steven Price
In-Reply-To: <yq5aldcpz316.fsf@kernel.org>
On Mon, Jun 08, 2026 at 04:56:29PM +0530, Aneesh Kumar K.V wrote:
> Suzuki K Poulose <suzuki.poulose@arm.com> writes:
>
> > On 08/06/2026 09:19, Aneesh Kumar K.V wrote:
> >> Sudeep Holla <sudeep.holla@kernel.org> writes:
> >>
> >>> On Thu, Jun 04, 2026 at 06:56:28PM +0530, Aneesh Kumar K.V wrote:
> >>>> Sudeep Holla <sudeep.holla@kernel.org> writes:
> >>>>
> >>>> ...
>
> ...
>
> >>> I was trying to avoid conditional compilation altogether and hence the
> >>> reason for keeping it as simple as possible. Also IS_ENABLED(CONFIG_ARM64)
> >>> in above snippet must come as some condition to this generic probe.
> >>>
> >>> Adding any more logic or callback defeats the bus idea here if we need
> >>> to rely/depend on multiple conditional compilation or callbacks IMO.
> >>>
> >>> Let's find see if it can work with what we are adding now and may add in
> >>> near future and then decide.
> >>>
> >>
> >> If we move all the conditional checks to the driver probe path, then I
> >> think this can work. Something like the below:
> >>
> >> struct smccc_device_info {
> >> u32 func_id;
> >> bool requires_smc;
> >> const char *device_name;
> >> };
> >>
> >> static const struct smccc_device_info smccc_devices[] __initconst = {
> >> {
> >> .func_id = ARM_SMCCC_TRNG_VERSION,
> >> .requires_smc = false,
> >> .device_name = "arm-smccc-trng",
> >> },
> >>
> >> {
> >> .func_id = RSI_ABI_VERSION,
> >
> > Don't we need parameters passed to this (Requested Interface version for
> > e.g.) ? See more below.
> >
>
> The idea is that we only check whether the function ID is supported. All
> other conditional logic should be handled in the driver probe path, as
> demonstrated by the changes in drivers/char/hw_random/arm_smccc_trng.c.
>
+1. Yes, we just want to know whether the firmware is aware of that feature
before creating the `smccc_device` for it. The device probe can then perform a
more thorough, feature-specific check to determine whether the device/feature
is usable.
That is the main idea behind the approach I suggested. Please let me know if
you still see any issues or think this may not work.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] arm64/hw_breakpoint: reject unaligned watchpoints that would truncate BAS
From: Breno Leitao @ 2026-06-08 12:14 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Catalin Marinas, Pratyush Anand, linux-arm-kernel,
linux-perf-users, linux-kernel, clm, leo.bras, kernel-team
In-Reply-To: <ahmohv6vQGxY-asL@willie-the-truck>
On Fri, May 29, 2026 at 03:53:58PM +0100, Will Deacon wrote:
> Hi Breno,
>
> Thanks for sending this out.
>
> On Thu, Apr 30, 2026 at 02:40:10AM -0700, Breno Leitao wrote:
> > hw_breakpoint_arch_parse() positions the BAS bit pattern in
> > hw->ctrl.len with
> >
> > offset = hw->address & alignment_mask; /* 0..7 */
> > hw->ctrl.len <<= offset;
> >
> > ctrl.len is an 8-bit bitfield (struct arch_hw_breakpoint_ctrl::len is
> > u32 :8), so the shift silently drops any bits past bit 7. For
> > non-compat AArch64 watchpoints the offset is unbounded relative to
> > ctrl.len: a perf_event_open(PERF_TYPE_BREAKPOINT) caller asking for
> > HW_BREAKPOINT_W with bp_addr=page+1 and bp_len=HW_BREAKPOINT_LEN_8
> > ends up with 0xff << 1 = 0x1fe, stored as 0xfe. The kernel programs
> > WCR.BAS=0xfe and the hardware watches bytes [1..7] instead of the
> > requested [1..8] -- the eighth byte is silently dropped. The
> > syscall still returns success, leaving userspace to discover the
> > gap by empirical probing.
> >
> > The same class affects HW_BREAKPOINT_LEN_{2,4} when offset pushes the
> > high BAS bit past bit 7 (e.g. LEN_4 with offset=5 yields 0xe0
> > instead of 0x1e0). No memory-safety impact -- the value is masked
> > into 8 bits before encoding -- but debuggers and perf users observe
> > missed events on bytes they thought they were watching.
> >
> > The AArch32 branch immediately above already rejects unrepresentable
> > (offset, len) combinations via an explicit switch. Mirror that for
> > the non-compat branch by checking that the shifted pattern fits in
> > the BAS field, returning -EINVAL when it does not.
> >
> > Reproducer:
> >
> > struct perf_event_attr a = {
> > .type = PERF_TYPE_BREAKPOINT, .size = sizeof(a),
> > .bp_type = HW_BREAKPOINT_W,
> > .bp_addr = (uintptr_t)(buf + 1),
> > .bp_len = HW_BREAKPOINT_LEN_8,
> > .exclude_kernel = 1, .exclude_hv = 1,
> > };
> > int fd = perf_event_open(&a, 0, -1, -1, 0);
> > /* before this fix: succeeds, watches 7 bytes (buf+1..buf+7) */
> > /* after this fix: fails with EINVAL */
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > Fixes: b08fb180bb88 ("arm64: Allow hw watchpoint at varied offset from base address")
>
> Oh man, this has been broken for nearly a decade :/
>
> I think we probably should've stuck with the old behaviour of rejecting
> unaligned base addresses, but it's too late now. Damn.
>
> > arch/arm64/kernel/hw_breakpoint.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
> > index ab76b36dce820..b8a1402119f3a 100644
> > --- a/arch/arm64/kernel/hw_breakpoint.c
> > +++ b/arch/arm64/kernel/hw_breakpoint.c
> > @@ -559,6 +559,15 @@ int hw_breakpoint_arch_parse(struct perf_event *bp,
> > else
> > alignment_mask = 0x7;
> > offset = hw->address & alignment_mask;
> > +
> > + /*
> > + * BAS is an 8-bit field in WCR/BCR; the shift below would
> > + * silently drop the high bits of ctrl.len when offset + len
> > + * exceeds 8, programming hardware to watch fewer bytes than
> > + * the user requested.
> > + */
> > + if (((u32)hw->ctrl.len << offset) > 0xff)
>
> nit: Use ARM_BREAKPOINT_LEN_8 instead of 0xff
>
> > + return -EINVAL;
> > }
>
> I must confess, I'm very nervous about breaking userspace here. If GDB
> is triggering this path, then this patch will change an unreliable
> watchpoint into a hard error (which probably means GDB exits). Have you
> looked to see what GDB and/or any other debuggers do?
>
> I had a quick peek and found the bugzilla entry which motivated the
> buggy change in the first place:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=20207
>
> and it looks like the aarch64_align_watchpoint() function does try to
> spill into multiple watchpoints, so perhaps your patch is ok. I'd
> appreciate your opinion, though.
It won't, for two independent reasons.
The new -EINVAL is unreachable from GDB; only a raw perf_event_open() passing
an unaligned base with an oversized bp_len hits it, which is the bug.
Second, even if a debugger did hand the kernel such a request, GDB
already treats EINVAL on NT_ARM_HW_WATCH as a downgrade signal, not a
fatal error. aarch64_linux_set_debug_regs() catches it, clears
kernel_supports_any_contiguous_range, calls aarch64_downgrade_regs()
(which rounds the BAS up to a legacy 0x01/03/0f/ff mask and aligns the
base down), and retries. That fallback is exactly the PR-20207 path.
Confirmed on a Grace box: with the patch applied (under virtme-ng), the
reproducer's unaligned LEN_8 now returns -EINVAL while aligned LEN_8
still succeeds, and GDB still inserts the watchpoint and it still fires
on every write.
GDB in fact downgrades on the current kernel independently of this patch, so
behaviour is unchanged for it.
^ permalink raw reply
* Re: [PATCH 26/37] drm: event-notifier: add mechanism to notify about hotplug events
From: Maxime Ripard @ 2026-06-08 12:13 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260519-drm-bridge-hotplug-v1-26-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
On Tue, May 19, 2026 at 12:37:43PM +0200, Luca Ceresoli wrote:
> In preparation for supporting DRM bridge hotplug, add an event notifier to
> allow interested parties to be notified about events they need to react to.
>
> For the initial implementation of bridge hotplug, two events are needed:
> bridge detach (happening in drm_bridge.c) and MIPI device attach to MIPI
> host (happening in drm_mipi_dsi.c).
>
> For this reason implement the event notifier in a new common file that
> event producers can easily use to send events.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
So, you claim in the commit message that it's about a hotplug event, but
the only events are the bridge being attached and detached, so not a
hotplug event?
And why a bridge would want to be notified that itself (or another?)
bridge is being attached or detached?
You need documentation, and a more descriptive commit message.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH] dma: iop32x-adma: Remove a leftover header file
From: Vinod Koul @ 2026-06-08 12:13 UTC (permalink / raw)
To: Arnd Bergmann, Vladimir Zapolskiy; +Cc: linux-arm-kernel, dmaengine
In-Reply-To: <20260114051508.3908807-1-vz@mleia.com>
On Wed, 14 Jan 2026 07:14:58 +0200, Vladimir Zapolskiy wrote:
> The Intel IOPx3xx platform was completely removed in commit b91a69d162aa
> ("ARM: iop32x: remove the platform"), and it'd be safe to remove an unused
> and leftover platform data specific header file dma-iop32x.h also.
>
>
Applied, thanks!
[1/1] dma: iop32x-adma: Remove a leftover header file
commit: b2d44b3ea95e10315559d8deedd8af2977c7f534
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCHv3] dmaengine: ste_dma40: turn d40_base phy_chans into a flexible array
From: Vinod Koul @ 2026-06-08 12:12 UTC (permalink / raw)
To: dmaengine, Rosen Penev
Cc: Linus Walleij, Frank Li, linux-arm-kernel, linux-kernel
In-Reply-To: <20260531020843.594892-1-rosenp@gmail.com>
On Sat, 30 May 2026 19:08:43 -0700, Rosen Penev wrote:
> Convert the separately-offset phy_chans pointer to a C99 flexible array
> member at the end of struct d40_base, and switch the allocation to
> struct_size(). The log_chans and memcpy_chans slots continue to live
> in the same allocation immediately after phy_chans, indexed via
> base->log_chans. This removes the hand-rolled pointer fixup that
> recomputed phy_chans from base + ALIGN(sizeof(struct d40_base), 4).
>
> [...]
Applied, thanks!
[1/1] dmaengine: ste_dma40: turn d40_base phy_chans into a flexible array
commit: cc4fea19daeb0460fe3569e0a2d523f427b2bac1
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH 23/37] drm/encoder: add drm_encoder_cleanup_from()
From: Maxime Ripard @ 2026-06-08 12:10 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260519-drm-bridge-hotplug-v1-23-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 3761 bytes --]
On Tue, May 19, 2026 at 12:37:40PM +0200, Luca Ceresoli wrote:
> Supporting hardware whose final part of the DRM pipeline can be physically
> removed requires the ability to detach all bridges from a given point to
> the end of the pipeline.
>
> Introduce a variant of drm_encoder_cleanup() for this.
>
> Take care to not try detaching non-attached bridges. This is needed because
> when two or more bridges are removed not in the backwards order,
> drm_encoder_cleanup_from() is called more than once for bridges closer to
> the panel.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> Note: in theory drm_encoder_cleanup() is now a superset of
> drm_encoder_cleanup_from() and may be simplified to just call
> drm_encoder_cleanup_from() and then do the extra actions. However the
> common code is subtly different in terms of locking and checks, so this
> would complicate the code in this patch and has thus been kept separate for
> the time being to make reviewing sompler. Reimplementing
> drm_encoder_cleanup() by using drm_encoder_cleanup_from() cvacn be done
> later on.
>
> A much simpler and now obsolete version of this patch (missing locking and
> checks) previously appeared in
> https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-13-9d6f2c9c3058@bootlin.com/
> ---
> drivers/gpu/drm/drm_encoder.c | 38 ++++++++++++++++++++++++++++++++++++++
> include/drm/drm_encoder.h | 1 +
> 2 files changed, 39 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index 0d5dbed06db4..40ece477b302 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -179,6 +179,44 @@ int drm_encoder_init(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_encoder_init);
>
> +/**
> + * drm_encoder_cleanup_from - remove a given bridge and all the following
> + * @encoder: encoder whole list of bridges shall be pruned
> + * @bridge: first bridge to remove
> + *
> + * Removes from an encoder all the bridges starting with a given bridge
> + * and until the end of the chain.
> + *
> + * Does nothing if the bridge is not attached to an encoder chain.
> + *
> + * This should not be used in "normal" DRM pipelines. It is only useful for
> + * devices whose final part of the DRM chain can be physically removed and
> + * later reconnected (possibly with different hardware).
> + */
> +void drm_encoder_cleanup_from(struct drm_encoder *encoder, struct drm_bridge *bridge)
> +{
> + struct drm_bridge *next;
> + LIST_HEAD(tmplist);
> +
> + /*
> + * We need the bridge_chain_mutex to modify the chain, but
> + * drm_bridge_detach() will call DRM_MODESET_LOCK_ALL_BEGIN() (in
> + * drm_modeset_lock_fini()), resulting in a possible ABBA circular
> + * deadlock. Avoid it by first moving all the bridges to a
> + * temporary list holding the lock, and then calling
> + * drm_bridge_detach() without the lock.
> + */
> + mutex_lock(&encoder->bridge_chain_mutex);
> + if (!list_empty(&bridge->chain_node))
> + list_for_each_entry_safe_from(bridge, next, &encoder->bridge_chain, chain_node)
> + list_move_tail(&bridge->chain_node, &tmplist);
> + mutex_unlock(&encoder->bridge_chain_mutex);
> +
> + while (!list_empty(&tmplist))
> + drm_bridge_detach(list_first_entry(&tmplist, struct drm_bridge, chain_node));
> +}
> +EXPORT_SYMBOL(drm_encoder_cleanup_from);
> +
The name is super confusing, because it doesn't clean up anything.
drm_encoder_cleanup is called that way because it cleans up the encoder.
This function doesn't.
Unlike what's being documented, it doesn't remove any bridge either. It
just detaches bridge, so let's just call it that way?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v1 15/26] s390: Add functions to query arm guest time
From: Nico Boehr @ 2026-06-08 12:08 UTC (permalink / raw)
To: Oliver Upton, Andreas Grapentin
Cc: Steffen Eiden, kvm, kvmarm, linux-arm-kernel, linux-kernel,
linux-s390, Alexander Gordeev, Arnd Bergmann, Catalin Marinas,
Christian Borntraeger, Claudio Imbrenda, David Hildenbrand,
Friedrich Welter, Gautam Gala, Hariharan Mari, Heiko Carstens,
Hendrik Brueckner, Ilya Leoshkevich, Janosch Frank, Joey Gouly,
Marc Zyngier, Nico Boehr, Nina Schoetterl-Glausch, Paolo Bonzini,
Suzuki K Poulose, Sven Schnelle, Ulrich Weigand, Vasily Gorbik,
Will Deacon, Zenghui Yu
In-Reply-To: <ah9MFEq09ISAu9cb@kernel.org>
On Tue Jun 2, 2026 at 11:33 PM CEST, Oliver Upton wrote:
> I was trying to figure out how these functions
> apply to the virtual and "physical" views of the counter inside the VM.
I think conceptually these functions affect what is returned by
PhysicalCountInt() in ARM pseudocode and thus they apply to both virtual and
"physical" views inside the VM.
^ permalink raw reply
* Re: [PATCH 25/37] drm/bridge: shutdown and cleanup on bridge unplug
From: Maxime Ripard @ 2026-06-08 12:07 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260519-drm-bridge-hotplug-v1-25-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]
Hi,
On Tue, May 19, 2026 at 12:37:42PM +0200, Luca Ceresoli wrote:
> With the upcoming support for DRM bridge hot(un)plugging, bridges can be
> removed at any time withotu tearing down the entire card. When this
> happens, shutdown the pipeline and detach from the encoder chain the bridge
> being removed along with all the following ones.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> drivers/gpu/drm/drm_bridge.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 7f2d1a81d730..d45fb74ec8c2 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -462,9 +462,17 @@ EXPORT_SYMBOL(devm_drm_bridge_add);
> * it won't be found by users via of_drm_find_and_get_bridge(), and add it
> * to the lingering bridge list, to keep track of it until its allocated
> * memory is eventually freed.
> + *
> + * If the bridge is attached, also disable the active output and detach
> + * this bridge and the following ones.
> */
> void drm_bridge_remove(struct drm_bridge *bridge)
> {
> + if (bridge->encoder) {
> + drm_atomic_shutdown(bridge->dev);
> + drm_encoder_cleanup_from(bridge->encoder, bridge);
> + }
> +
> mutex_lock(&bridge_lock);
> list_move_tail(&bridge->list, &bridge_lingering_list);
> mutex_unlock(&bridge_lock);
I don't think this makes a lot of sense to disable the whole device at
once. The connector, encoder, and the CRTC might, but the whole device
doesn't.
Even then, I'm not sure we should disable anything. How does DP-MST
handles removal?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 bpf-next] arm64: mm: Complete the PTE store in ptep_try_set()
From: patchwork-bot+netdevbpf @ 2026-06-08 12:00 UTC (permalink / raw)
To: Tejun Heo
Cc: catalin.marinas, will, ast, david, arighi, memxor, akpm, rppt,
andrii, daniel, martin.lau, eddyz87, yonghong.song, emil, void,
changwoo, linux-arm-kernel, linux-mm, bpf, linux-kernel
In-Reply-To: <7f5f7c94601312c1a401fb18998291cc@kernel.org>
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Kumar Kartikeya Dwivedi <memxor@gmail.com>:
On Sun, 07 Jun 2026 21:25:47 -1000 you wrote:
> ptep_try_set() installs a kernel PTE with try_cmpxchg() but, unlike
> __set_pte(), skips the barriers that arm64 requires after writing a valid
> kernel PTE. Without them a subsequent access can fault instead of seeing
> the new mapping.
>
> Issue them with emit_pte_barriers() rather than __set_pte_complete().
> ptep_try_set() must finish the store before it returns, but
> __set_pte_complete() would defer the barriers when the calling context is in
> lazy MMU mode.
>
> [...]
Here is the summary with links:
- [v2,bpf-next] arm64: mm: Complete the PTE store in ptep_try_set()
https://git.kernel.org/bpf/bpf-next/c/71385b78dbc2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 19/37] drm/bridge: samsung-dsim: move drm_bridge_add() call to probe
From: Maxime Ripard @ 2026-06-08 11:58 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260519-drm-bridge-hotplug-v1-19-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]
On Tue, May 19, 2026 at 12:37:36PM +0200, Luca Ceresoli wrote:
> This bridge driver calls drm_bridge_add() in the DSI host .attach callback
> instead of in the probe function.
>
> This works for current use cases but is problematic for supporting hotplug
> of DRM bridges. The problematic case is when this DSI host is always
> present while its DSI device is hot-pluggable. In such case with the
> current code the DRM card will not be populated until after the DSI device
> attaches to the host, which could happen a very long time after booting, or
> even not happen at all.
>
> The reason is that the previous pipeline component (the encoder in this
> case) when probing cannot find the samsung-dsim bridge. What happens is:
>
> [1 and 2 can happen in any order, same result]
> 1) samsung-dsim probes (does not drm_bridge_add() itself)
> 2) The lcdif starts probing multiple times, but
> lcdif_probe
> -> lcdif_load
> -> lcdif_attach_bridge
> -> devm_drm_of_get_bridge() returns -EPROBE_DEFER because
> the samsung-dsim is not in the global bridge_list
> (deferred probe pending: imx-lcdif: Cannot connect bridge)
>
> The samsung-dsim will not drm_bridge_add() itself until a DSI device will
> try to mipi_dsi_attach() to the DSI Host, which can happen arbitratily late
> on hot-pluggable hardware.
>
> As a preliminary step to supporting hotplug move drm_bridge_add() at probe
> time, so that the samsung-dsim DSI host bridge is available during boot,
> even without a connected DSI device. This results in:
>
> 1) samsung-dsim probes (and adds to drm_bridge_add() itself)
> 2) The lcdif starts probing multiple times, but
> lcdif_probe
> -> lcdif_load
> -> lcdif_attach_bridge
> -> devm_drm_of_get_bridge() --> OK, returns samsung-dsim ptr
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
We should probably amend
https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges
To mention this use case here
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH 18/37] drm/bridge: samsung-dsim: remove the panel_bridge on host_detach
From: Maxime Ripard @ 2026-06-08 11:53 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260519-drm-bridge-hotplug-v1-18-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 4581 bytes --]
On Tue, May 19, 2026 at 12:37:35PM +0200, Luca Ceresoli wrote:
> In preparation for DRM bridge hot-plugging, we need to handle the dynamic
> lifetime of the following bridge in case the samsung-dsim is always present
> and the following bridge (next_bridge) is hot-unplugged.
>
> Based on the 'if (!IS_ERR(panel))' check in samsung_dsim_host_attach(), the
> next_bridge could be A) a panel bridge created by this driver via
> devm_drm_panel_bridge_add() or B) a pre-existing bridge obtained via
> of_drm_find_and_get_bridge().
>
> For case B) we need to put that reference when the next_bridge is removed,
> which is already handled by calling drm_bridge_clear_and_put() in
> samsung_dsim_host_detach() and in the samsung_dsim_host_attach() error
> management code.
>
> In case A) we additionally have to remove the panel bridge. Currently it is
> created by devm_drm_panel_bridge_add(), which adds two devm actions with
> the refcounted panel bridge:
>
> - drm_bridge_put_void() via devm_drm_bridge_alloc() on panel->dev
> - devm_drm_panel_bridge_release() via devm_drm_panel_bridge_add_typed()
> on the consumer device (samsung-dsim)
>
> The first action is OK: being tied to panel->dev it will happen when the
> panel is unplugged.
>
> The second action is bound to the consumer device, so the devm semantics is
> not useful here when introducing hotplug. Indeed we need to drop the
> next_bridge in samsung_dsim_host_detach() anyway, before the driver .remove
> function, in order to support {add, {attach, detach} x N, remove} hotplug
> event sequences.
>
> Thus move to the non-devm drm_panel_bridge_add() along with the matching
> drm_panel_bridge_remove(), so the lifetime of the panel-bridge is tied to
> the host_attach/host_detach cycle and not the whole samsung-dsim device
> lifetime.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> In a previous discussion with Maxime he mentioned a plan to make every
> drm_panel always have a wrapping bridge. With that done, all the code
> handling the panel and adding the panel_bridge would become useless here
> (and in many other places) and could be entirely removed. This patch is a
> temporary solution until that happens. The best pointer I could find to
> that discussion is [0], but there might be more recent material I could not
> find at the moment.
>
> [0] https://lore.kernel.org/lkml/20250218-faithful-white-magpie-da9ac9@houat/
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 17 ++++++++++++++---
> include/drm/bridge/samsung-dsim.h | 2 ++
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 5b799619e07e..2af287221e22 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1951,14 +1951,16 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
> if (!remote)
> return -ENODEV;
>
> + dsi->panel_bridge_added = false;
> panel = of_drm_find_panel(remote);
> if (!IS_ERR(panel)) {
> - next_bridge = devm_drm_panel_bridge_add(dev, panel);
> + next_bridge = drm_panel_bridge_add(panel);
> if (IS_ERR(next_bridge)) {
> ret = PTR_ERR(next_bridge);
> next_bridge = NULL; // Inhibit the cleanup action on an ERR_PTR
> } else {
> drm_bridge_get(next_bridge);
> + dsi->panel_bridge_added = true;
> }
> } else {
> next_bridge = of_drm_find_and_get_bridge(remote);
> @@ -1989,7 +1991,7 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
> if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO)) {
> ret = samsung_dsim_register_te_irq(dsi, &device->dev);
> if (ret)
> - goto err_remove_bridge;
> + goto err_remove_panel_bridge;
> }
>
> // The next bridge can be used by host_ops->attach
> @@ -2011,8 +2013,12 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
> drm_bridge_clear_and_put(&dsi->bridge.next_bridge);
> if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO))
> samsung_dsim_unregister_te_irq(dsi);
> -err_remove_bridge:
> +err_remove_panel_bridge:
> drm_bridge_remove(&dsi->bridge);
> + if (dsi->panel_bridge_added) {
> + drm_panel_bridge_remove(next_bridge);
> + dsi->panel_bridge_added = false;
> + }
This is a pretty big abstraction leak. We don't want to have that in
everything driver. The removal path should be the same for both cases,
and it's not something the driver should take care of.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 12/14] gpio: tc956x: add TC956x/QPS615 support
From: Bartosz Golaszewski @ 2026-06-08 11:52 UTC (permalink / raw)
To: Alex Elder
Cc: daniel, mohd.anwar, a0987203069, alexandre.torgue, ast,
boon.khai.ng, chenchuangyu, chenhuacai, daniel, hawk, hkallweit1,
inochiama, john.fastabend, julianbraha, livelycarpet87,
mcoquelin.stm32, me, prabhakar.mahadev-lad.rj, richardcochran,
rohan.g.thomas, sdf, siyanteng, weishangjuan, wens, netdev, bpf,
linux-arm-msm, devicetree, linux-gpio, linux-stm32,
linux-arm-kernel, linux-kernel, andrew+netdev, davem, edumazet,
kuba, pabeni, maxime.chevallier, rmk+kernel, andersson,
konradybcio, robh, krzk+dt, conor+dt, linusw, brgl, arnd, gregkh
In-Reply-To: <20260605010022.968612-13-elder@riscstar.com>
On Fri, 5 Jun 2026 03:00:19 +0200, Alex Elder <elder@riscstar.com> said:
> Toshiba TC956x is an Ethernet-AVB/TSN bridge and is essentially
> a small and highly-specialized SoC. TC956x includes a GPIO block that
> can be accessed, alongside several other peripherals, via two PCIe
> endpoint functions. The PCIe function driver creates an auxiliary
> device for the GPIO block, and that device gets bound to this auxiliary
> device driver.
>
> This driver is implemented using the generic regmap-based GPIO driver.
>
> Co-developed-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> ---
> MAINTAINERS | 1 +
> drivers/gpio/Kconfig | 12 ++++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-tc956x.c | 130 +++++++++++++++++++++++++++++++++++++
> 4 files changed, 144 insertions(+)
> create mode 100644 drivers/gpio/gpio-tc956x.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0924f7ec43cb0..0439607d1155f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -27057,6 +27057,7 @@ M: Alex Elder <elder@kernel.org>
> M: Daniel Thompson <danielt@kernel.org>
> S: Maintained
> F: Documentation/devicetree/bindings/net/toshiba,tc956x-dwmac.yaml
> +F: drivers/gpio/gpio-tc956x.c
> F: drivers/misc/tc956x_pci.c
>
> TOSHIBA WMI HOTKEYS DRIVER
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 020e51e30317a..36631ca722fa3 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -743,6 +743,18 @@ config GPIO_TB10X
> select GPIO_GENERIC
> select GENERIC_IRQ_CHIP
>
> +config GPIO_TC956X
> + tristate "Toshiba TC956X GPIO support"
> + depends on TOSHIBA_TC956X_PCI
> + select GPIO_REGMAP
> + default m
> + help
> + This enables support for the GPIO controller embedded in the Toshiba
> + TC956X (and Qualcomm QPS615). This device connects to the host
> + via PCIe port, which is the upstream port on an internal PCIe
> + switch. On some platforms, a few of the GPIO lines are used to
> + manage external resets.
> +
> config GPIO_TEGRA
> tristate "NVIDIA Tegra GPIO support"
> default ARCH_TEGRA
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index b267598b517de..c3584e7cba9b4 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -178,6 +178,7 @@ obj-$(CONFIG_GPIO_SYSCON) += gpio-syscon.o
> obj-$(CONFIG_GPIO_TANGIER) += gpio-tangier.o
> obj-$(CONFIG_GPIO_TB10X) += gpio-tb10x.o
> obj-$(CONFIG_GPIO_TC3589X) += gpio-tc3589x.o
> +obj-$(CONFIG_GPIO_TC956X) += gpio-tc956x.o
> obj-$(CONFIG_GPIO_TEGRA186) += gpio-tegra186.o
> obj-$(CONFIG_GPIO_TEGRA) += gpio-tegra.o
> obj-$(CONFIG_GPIO_THUNDERX) += gpio-thunderx.o
> diff --git a/drivers/gpio/gpio-tc956x.c b/drivers/gpio/gpio-tc956x.c
> new file mode 100644
> index 0000000000000..0dc6b1028d970
> --- /dev/null
> +++ b/drivers/gpio/gpio-tc956x.c
> @@ -0,0 +1,130 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Copyright (C) 2026 by RISCstar Solutions Corporation. All rights reserved.
> + */
> +
> +/*
> + * The Toshiba TC956X implements a PCIe Gen 3 switch that connects an
> + * upstream x4 port to two downstream PCIe x2 ports. It incorporates
> + * an internal endpoint on a internal PCIe port that implements two
> + * Synopsys XGMAC Ethernet interfaces.
> + *
> + * 35 GPIOs are also implemented by an embedded GPIO controller. Three
> + * registers control the first 32 GPIOs (other than 20 and 21, which are
> + * reserved). Three other registers control GPIOs 32 through 36. GPIOs
> + * 22-24, 27-28, 31, and 34 are treated as "input only".
> + *
> + * There is a TC956X PCI power controller driver that accesses the
> + * direction and output value registers for GPIOs 2 and 3. These
> + * GPIOs control the reset signal for the two downstream PCIe ports.
> + * Their values will never change during operation of this driver, and
> + * this driver reserves these two GPIOS.
> + */
> +
> +#include <linux/auxiliary_bus.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/gpio/regmap.h>
> +
> +#define DRIVER_NAME "tc956x-gpio"
> +
> +#define TC956X_GPIO_COUNT 37 /* Number of GPIOs (20-21 reserved) */
> +
> +/* The GPIO offsets are relative to 0x1200 in TC956X SFR space. */
> +#define GPIO_IN0_OFFSET 0x00 /* Input value (0-31) */
> +#define GPIO_EN0_OFFSET 0x08 /* 0: out; 1: in (0-31) */
> +#define GPIO_OUT0_OFFSET 0x10 /* Output value (0-31) */
> +
> +/*
> + * There are two sets of registers, each representing (up to) 32 GPIOs with a
> + * stride of 4 bytes (IN1 is 4 bytes past IN0, EN1 is 4 bytes past EN0, etc.).
> + */
> +#define GPIO_PER_REG 32
> +#define GPIO_REG_STRIDE 4
> +
> +static int tc956x_gpio_init_valid_mask(struct gpio_chip *gc,
> + unsigned long *valid_mask,
> + unsigned int ngpios)
> +{
> + /*
> + * GPIOs 2 and 3 are used by the PCI power control driver, and
> + * we don't allow them to be used. GPIOs 20 and 21 are reserved
> + * (and not usable).
> + */
> + bitmap_fill(valid_mask, ngpios);
> + bitmap_clear(valid_mask, 2, 2);
> + bitmap_clear(valid_mask, 20, 2);
> +
> + return 0;
> +}
> +
> +static int tc956x_gpio_probe(struct auxiliary_device *adev,
> + const struct auxiliary_device_id *id)
> +{
> + DECLARE_BITMAP(zeroes, TC956X_GPIO_COUNT);
> + DECLARE_BITMAP(fixed, TC956X_GPIO_COUNT);
> + struct gpio_regmap_config config = { };
> + struct gpio_regmap *gpio_regmap;
> + struct device *dev = &adev->dev;
> +
> + /* We need the regmap pointer, stored in our platform data */
> + if (!dev->platform_data)
> + return -EINVAL;
Please use the standardized accessor: dev_get_platdata().
> +
> + /*
> + * Only some of our GPIOs are fixed direction:
> + * 22, 23, 24, 27, 28, 31, and 34 (all input-only)
> + * Set up the fixed bitmap to indicate which are fixed.
> + */
> + bitmap_zero(fixed, TC956X_GPIO_COUNT);
> + bitmap_set(fixed, 22, 3);
> + bitmap_set(fixed, 27, 2);
> + set_bit(31, fixed);
> + set_bit(34, fixed);
> +
> + /* All fixed GPIOs are input; the zeroes bitmap indicates that. */
> + bitmap_zero(zeroes, TC956X_GPIO_COUNT);
> +
> + config.parent = dev;
> + config.regmap = dev->platform_data;
> + config.label = DRIVER_NAME;
> + config.ngpio = TC956X_GPIO_COUNT;
> + config.reg_dat_base = GPIO_REGMAP_ADDR(GPIO_IN0_OFFSET);
> + config.reg_set_base = GPIO_REGMAP_ADDR(GPIO_OUT0_OFFSET);
> + config.reg_dir_in_base = GPIO_REGMAP_ADDR(GPIO_EN0_OFFSET);
> + config.reg_stride = GPIO_REG_STRIDE;
> + config.ngpio_per_reg = GPIO_PER_REG;
> + config.init_valid_mask = tc956x_gpio_init_valid_mask;
> + config.fixed_direction_mask = fixed;
> + config.fixed_direction_output = zeroes;
May I suggest using a compound literal here like:
config = (struct gpio_regmap_config){
...
};
?
> +
> + gpio_regmap = devm_gpio_regmap_register(dev, &config);
> + if (IS_ERR(gpio_regmap))
> + return PTR_ERR(gpio_regmap);
> +
> + return 0;
You can do:
return PTR_ERR_OR_ZERO(devm_gpio_regmap_register(dev, &config));
and save a few lines.
> +}
> +
> +static const struct auxiliary_device_id tc956x_gpio_ids[] = {
> + { .name = "tc956x_pci.tc9564-gpio", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(auxiliary, tc956x_gpio_ids);
> +
> +static struct auxiliary_driver tc956x_gpio_driver = {
> + .name = DRIVER_NAME,
> + .probe = tc956x_gpio_probe,
> + .id_table = tc956x_gpio_ids,
> + .driver = {
> + .name = DRIVER_NAME,
> + .owner = THIS_MODULE,
> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> + },
> +};
> +module_auxiliary_driver(tc956x_gpio_driver);
> +
> +MODULE_DESCRIPTION("Toshiba TC956X PCIe GPIO Driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("auxiliary:" DRIVER_NAME);
> --
> 2.51.0
>
>
Bart
^ permalink raw reply
* Re: [PATCH v4 13/14] arm64: dts: imx8mp-var-som-symphony: add second Ethernet port
From: Fabio Estevam @ 2026-06-08 11:50 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team
In-Reply-To: <302638ba16d4684c5b0bf8660a42615dad67f3eb.1780912893.git.stefano.r@variscite.com>
On Mon, Jun 8, 2026 at 7:09 AM Stefano Radaelli
<stefano.radaelli21@gmail.com> wrote:
> + reg_fec_phy: regulator-fec-phy {
> + compatible = "regulator-fixed";
> + regulator-name = "fec-phy";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <20000>;
> + gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-always-on;
There is no need to mark it as regulator-always-on, as reg_fec_phy has
a consumer.
Please check globally.
^ 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