* Re: [PATCH v2 11/20] drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()
From: Dmitry Baryshkov @ 2026-04-21 15:50 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-11-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:18PM +0100, Maxime Ripard wrote:
> __drm_atomic_helper_connector_state_reset() is used to initialize a
> newly allocated drm_connector_state, and is being typically called by
> the drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_state_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_state_reset() to
> __drm_atomic_helper_connector_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 10 +++++-----
> include/drm/drm_atomic_state_helper.h | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 12/20] drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()
From: Dmitry Baryshkov @ 2026-04-21 15:50 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-12-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:19PM +0100, Maxime Ripard wrote:
> __drm_atomic_helper_connector_hdmi_reset() is typically used to
> initialize a newly allocated drm_connector_state when the connector is
> using the HDMI helpers, and is being called by the
> drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_hdmi_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_hdmi_reset() to
> __drm_atomic_helper_connector_hdmi_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/display/drm_bridge_connector.c | 4 ++--
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 14 ++++++++------
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
> drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> include/drm/display/drm_hdmi_state_helper.h | 4 ++--
> 6 files changed, 15 insertions(+), 13 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: mediatek: Convert mtk-btcvsd-snd to DT Schema
From: Luca Leonardo Scorcia @ 2026-04-21 15:46 UTC (permalink / raw)
To: linux-sound
Cc: Luca Leonardo Scorcia, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
Convert the mtk-btcvsd-snd.txt DT binding to DT Schema format.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
Changes in v2:
- Fixed issues from make dt_binding_check
- Set myself as maintainer for the binding
.../sound/mediatek,mtk-btcvsd-snd.yaml | 60 +++++++++++++++++++
.../bindings/sound/mtk-btcvsd-snd.txt | 24 --------
2 files changed, 60 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml b/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
new file mode 100644
index 000000000000..1ec50c7611df
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mtk-btcvsd-snd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek ALSA BT SCO CVSD/MSBC Driver
+
+maintainers:
+ - Luca Leonardo Scorcia <l.scorcia@gmail.com>
+
+properties:
+ compatible:
+ const: mediatek,mtk-btcvsd-snd
+
+ reg:
+ items:
+ - description: Register location and size of PKV
+ - description: Register location and size of SRAM_BANK2
+
+ interrupts:
+ items:
+ - description: BT-SCO interrupt
+
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the infracfg controller
+
+ mediatek,offset:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: Array of register offsets and masks
+ items:
+ - description: infra_misc_offset
+ - description: infra_conn_bt_cvsd_mask
+ - description: cvsd_mcu_read_offset
+ - description: cvsd_mcu_write_offset
+ - description: cvsd_packet_indicator_offset
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - mediatek,infracfg
+ - mediatek,offset
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ mtk-btcvsd-snd@18000000 {
+ compatible = "mediatek,mtk-btcvsd-snd";
+ reg = <0x18000000 0x1000>,
+ <0x18080000 0x8000>;
+ interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_LOW>;
+ mediatek,infracfg = <&infrasys>;
+ mediatek,offset = <0xf00 0x800 0xfd0 0xfd4 0xfd8>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt b/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
deleted file mode 100644
index 679e44839b48..000000000000
--- a/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Mediatek ALSA BT SCO CVSD/MSBC Driver
-
-Required properties:
-- compatible = "mediatek,mtk-btcvsd-snd";
-- reg: register location and size of PKV and SRAM_BANK2
-- interrupts: should contain BTSCO interrupt
-- mediatek,infracfg: the phandles of INFRASYS
-- mediatek,offset: Array contains of register offset and mask
- infra_misc_offset,
- infra_conn_bt_cvsd_mask,
- cvsd_mcu_read_offset,
- cvsd_mcu_write_offset,
- cvsd_packet_indicator_offset
-
-Example:
-
- mtk-btcvsd-snd@18000000 {
- compatible = "mediatek,mtk-btcvsd-snd";
- reg=<0 0x18000000 0 0x1000>,
- <0 0x18080000 0 0x8000>;
- interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_LOW>;
- mediatek,infracfg = <&infrasys>;
- mediatek,offset = <0xf00 0x800 0xfd0 0xfd4 0xfd8>;
- };
--
2.43.0
^ permalink raw reply related
* [PATCH v2] mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
From: David Hildenbrand (Arm) @ 2026-04-21 15:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Andrew Morton, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Zi Yan, Lance Yang, Ryan Roberts, Mark Brown,
Dev Jain, linux-kernel, linux-mm, stable, David Hildenbrand (Arm)
__GFP_ZEROTAGS semantics are currently a bit weird, but effectively this
flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.
If we run with init_on_free, we will zero out pages during
__free_pages_prepare(), to skip zeroing on the allocation path.
However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will
consequently not only skip clearing page content, but also skip
clearing tag memory.
Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that
will get mapped to user space through set_pte_at() later: set_pte_at() and
friends will detect that the tags have not been initialized yet
(PG_mte_tagged not set), and initialize them.
However, for the huge zero folio, which will be mapped through a PMD
marked as special, this initialization will not be performed, ending up
exposing whatever tags were still set for the pages.
The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state
that allocation tags are set to 0 when a page is first mapped to user
space. That no longer holds with the huge zero folio when init_on_free
is enabled.
Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to
tag_clear_highpages() whether we want to also clear page content.
Invert the meaning of the tag_clear_highpages() return value to have
clearer semantics.
Reproduced with the huge zero folio by modifying the check_buffer_fill
arm64/mte selftest to use a 2 MiB area, after making sure that pages have
a non-0 tag set when freeing (note that, during boot, we will not
actually initialize tags, but only set KASAN_TAG_KERNEL in the page
flags).
$ ./check_buffer_fill
1..20
...
not ok 17 Check initial tags with private mapping, sync error mode and mmap memory
not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory
...
This code needs more cleanups; we'll tackle that next, like
decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN.
Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio")
Cc: stable@vger.kernel.org
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
Changes in v2:
- Drop kasan_hw_tags_enabled() handling, as it missed the case of
user-space MTE without KASAN.
- Keep letting_clear_highpages() return a bool and re-instantiate
system_supports_mte() handling in the arm64 variant.
- Rephrase __GFP_ZEROTAGS comment, making it clearer that this is not
just a performance improvement.
- Retested and more excessively build tested
- Using a new b4 template, hopefully that doesn't mess things up
- Link to v1: https://lore.kernel.org/r/20260420-zerotags-v1-1-3edc93e95bb4@kernel.org
---
arch/arm64/include/asm/page.h | 2 +-
arch/arm64/mm/fault.c | 11 +++++++----
include/linux/gfp_types.h | 10 +++++-----
include/linux/highmem.h | 7 ++++---
mm/page_alloc.c | 8 ++++----
5 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index e25d0d18f6d7..58200de8a221 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -33,7 +33,7 @@ struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
unsigned long vaddr);
#define vma_alloc_zeroed_movable_folio vma_alloc_zeroed_movable_folio
-bool tag_clear_highpages(struct page *to, int numpages);
+bool tag_clear_highpages(struct page *to, int numpages, bool clear_pages);
#define __HAVE_ARCH_TAG_CLEAR_HIGHPAGES
#define copy_user_page(to, from, vaddr, pg) copy_page(to, from)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 0f3c5c7ca054..739800835920 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -1018,7 +1018,7 @@ struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
return vma_alloc_folio(flags, 0, vma, vaddr);
}
-bool tag_clear_highpages(struct page *page, int numpages)
+bool tag_clear_highpages(struct page *page, int numpages, bool clear_pages)
{
/*
* Check if MTE is supported and fall back to clear_highpage().
@@ -1026,13 +1026,16 @@ bool tag_clear_highpages(struct page *page, int numpages)
* post_alloc_hook() will invoke tag_clear_highpages().
*/
if (!system_supports_mte())
- return false;
+ return clear_pages;
/* Newly allocated pages, shouldn't have been tagged yet */
for (int i = 0; i < numpages; i++, page++) {
WARN_ON_ONCE(!try_page_mte_tagging(page));
- mte_zero_clear_page_tags(page_address(page));
+ if (clear_pages)
+ mte_zero_clear_page_tags(page_address(page));
+ else
+ mte_clear_page_tags(page_address(page));
set_page_mte_tagged(page);
}
- return true;
+ return false;
}
diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
index 6c75df30a281..d79049291b1a 100644
--- a/include/linux/gfp_types.h
+++ b/include/linux/gfp_types.h
@@ -273,11 +273,11 @@ enum {
*
* %__GFP_ZERO returns a zeroed page on success.
*
- * %__GFP_ZEROTAGS zeroes memory tags at allocation time if the memory itself
- * is being zeroed (either via __GFP_ZERO or via init_on_alloc, provided that
- * __GFP_SKIP_ZERO is not set). This flag is intended for optimization: setting
- * memory tags at the same time as zeroing memory has minimal additional
- * performance impact.
+ * %__GFP_ZEROTAGS zeroes memory tags at allocation time. Setting memory tags at
+ * the same time as zeroing memory (e.g., with __GPF_ZERO) has minimal
+ * additional performance impact. However, __GFP_ZEROTAGS also zeroes the tags
+ * even if memory is not getting zeroed at allocation time (e.g.,
+ * with init_on_free).
*
* %__GFP_SKIP_KASAN makes KASAN skip unpoisoning on page allocation.
* Used for userspace and vmalloc pages; the latter are unpoisoned by
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index af03db851a1d..d7aac9de1c8a 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -347,10 +347,11 @@ static inline void clear_highpage_kasan_tagged(struct page *page)
#ifndef __HAVE_ARCH_TAG_CLEAR_HIGHPAGES
-/* Return false to let people know we did not initialize the pages */
-static inline bool tag_clear_highpages(struct page *page, int numpages)
+/* Returns true if the caller has to initialize the pages */
+static inline bool tag_clear_highpages(struct page *page, int numpages,
+ bool clear_pages)
{
- return false;
+ return clear_pages;
}
#endif
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 65e205111553..71859993dd54 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1808,9 +1808,9 @@ static inline bool should_skip_init(gfp_t flags)
inline void post_alloc_hook(struct page *page, unsigned int order,
gfp_t gfp_flags)
{
+ const bool zero_tags = gfp_flags & __GFP_ZEROTAGS;
bool init = !want_init_on_free() && want_init_on_alloc(gfp_flags) &&
!should_skip_init(gfp_flags);
- bool zero_tags = init && (gfp_flags & __GFP_ZEROTAGS);
int i;
set_page_private(page, 0);
@@ -1832,11 +1832,11 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
*/
/*
- * If memory tags should be zeroed
- * (which happens only when memory should be initialized as well).
+ * Clearing tags can efficiently clear the memory for us as well, if
+ * required.
*/
if (zero_tags)
- init = !tag_clear_highpages(page, 1 << order);
+ init = tag_clear_highpages(page, 1 << order, /* clear_pages= */init);
if (!should_skip_kasan_unpoison(gfp_flags) &&
kasan_unpoison_pages(page, order, init)) {
---
base-commit: f1541b40cd422d7e22273be9b7e9edfc9ea4f0d7
change-id: 20260417-zerotags-343a3673e18d
--
Cheers,
David
^ permalink raw reply related
* Re: [PATCH v2 15/20] drm/drv: Call drm_mode_config_create_state() by default
From: Thomas Zimmermann @ 2026-04-21 15:33 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <79cc30d5-80b5-4d87-a3ad-36d6fad98853@suse.de>
Am 21.04.26 um 15:38 schrieb Thomas Zimmermann:
> Hi
>
> Am 20.03.26 um 17:27 schrieb Maxime Ripard:
>> Almost all drivers, and our documented skeleton, call
>> drm_mode_config_reset() prior to calling drm_dev_register() to
>> initialize its DRM object states.
>>
>> Now that we have drm_mode_config_create_state() to create that initial
>> state if it doesn't exist, we can call it directly in
>> drm_dev_register(). That way, we know that the initial atomic state will
>> always be allocated without any boilerplate.
>>
>> Signed-off-by: Maxime Ripard <mripard@kernel.org>
>> ---
>> drivers/gpu/drm/drm_drv.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index
>> 2915118436ce8a6640cfb0c59936031990727ed1..820106d56ab399a39cac56d98662b5ddbcae8ded
>> 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -1097,10 +1097,14 @@ int drm_dev_register(struct drm_device *dev,
>> unsigned long flags)
>> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>> ret = drm_modeset_register_all(dev);
>> if (ret)
>> goto err_unload;
>> +
>> + ret = drm_mode_config_create_state(dev);
>> + if (ret)
>> + goto err_unload;
>
> Way too late. Lets rather go through drivers and call this where they
> currently call drm_mode_config_reset() for initialization. This can be
> a single-patch mass conversion IMHO.
On a second thought, can't we modify the suspend code and leave the
reset as-is for now? I'd still be interested to use reset as a means of
initializing the hardware or loading state on probe. So keeping the
_reset() calls in place might be helpful for that.
What's the long-term plan here?
Best regards
Thomas
>
> Best regards
> Thomas
>
>> }
>> drm_panic_register(dev);
>> drm_client_sysrq_register(dev);
>> DRM_INFO("Initialized %s %d.%d.%d for %s on minor %d\n",
>>
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE
From: Will Deacon @ 2026-04-21 15:26 UTC (permalink / raw)
To: leo.jiang1224; +Cc: robin.murphy, joro, iommu, linux-arm-kernel
In-Reply-To: <tencent_F6E384A40D990A279B460A0CDE1927FDF509@qq.com>
On Sat, Apr 18, 2026 at 01:31:43PM +0800, leo.jiang1224@foxmail.com wrote:
> From: LoserJL <leo.jiang1224@foxmail.com>
>
> In arm_smmu_init_one_queue(), the loop reduces max_n_shift if
> dmam_alloc_coherent() fails. However, since dmam_alloc_coherent()
> allocates at least PAGE_SIZE, retrying with a smaller size after
> a PAGE_SIZE failure is logically redundant.
>
> Moreover, if a sub-page retry were to succeed due to concurrent memory
> release, the hardware would be configured with a smaller queue depth
> despite a full page being allocated. This leads to inefficient memory
> usage and unnecessary hardware performance limitation.
>
> Terminate the loop once qsz reaches PAGE_SIZE to ensure logical
> consistency and optimal hardware configuration.
>
> Signed-off-by: LoserJL <leo.jiang1224@foxmail.com>
No pseudonyms, please.
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e8d7dbe495f0..e0ec118ff560 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -4418,7 +4418,14 @@ int arm_smmu_init_one_queue(struct arm_smmu_device *smmu,
> qsz = ((1 << q->llq.max_n_shift) * dwords) << 3;
> q->base = dmam_alloc_coherent(smmu->dev, qsz, &q->base_dma,
> GFP_KERNEL);
> - if (q->base || qsz < PAGE_SIZE)
> + /*
> + * If allocation succeeds, we're done. If it fails, only retry
> + * if the requested size is still larger than a page. Since
> + * dmam_alloc_coherent() allocates at least PAGE_SIZE, retrying
> + * with a sub-page size is logically redundant and could lead
> + * to sub-optimal hardware configuration.
What do you mean by "sub-optimal hardware configuration"? I think you can
probably just drop this comment.
> + */
> + if (q->base || qsz <= PAGE_SIZE)
> break;
I think this part is fine.
Will
^ permalink raw reply
* Re: [PATCH 06/18] KVM: arm64: vgic: Consolidate vgic_allocate_private_irqs_locked()
From: Joey Gouly @ 2026-04-21 15:22 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260415115559.2227718-7-maz@kernel.org>
On Wed, Apr 15, 2026 at 12:55:47PM +0100, Marc Zyngier wrote:
> vgic_allocate_private_irqs_locked() calls two helpers, oddly named
> vgic_{,v5_}allocate_private_irq().
>
> Not only these helpers don't allocate anything, but they also
> contain duplicate init code that would be better placed in the
> caller.
>
> Consolidate the common init code in the caller, rename the helpers
> to vgic_{,v5_}setup_private_irq(), and pass the irq pointer around
> instead of the index of the interrupt.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/vgic/vgic-init.c | 45 +++++++++++++--------------------
> 1 file changed, 18 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
> index 933983bb20052..907057881b26a 100644
> --- a/arch/arm64/kvm/vgic/vgic-init.c
> +++ b/arch/arm64/kvm/vgic/vgic-init.c
> @@ -271,18 +271,12 @@ int kvm_vgic_vcpu_nv_init(struct kvm_vcpu *vcpu)
> return ret;
> }
>
> -static void vgic_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
> +static void vgic_setup_private_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> + u32 type)
> {
> - struct vgic_irq *irq = &vcpu->arch.vgic_cpu.private_irqs[i];
> + irq->intid = irq - &vcpu->arch.vgic_cpu.private_irqs[0];
These are allocated in one block with kzalloc_objs(), so this pointer offsetting is fine!
>
> - INIT_LIST_HEAD(&irq->ap_list);
> - raw_spin_lock_init(&irq->irq_lock);
> - irq->vcpu = NULL;
> - irq->target_vcpu = vcpu;
> - refcount_set(&irq->refcount, 0);
> -
> - irq->intid = i;
> - if (vgic_irq_is_sgi(i)) {
> + if (vgic_irq_is_sgi(irq->intid)) {
> /* SGIs */
> irq->enabled = 1;
> irq->config = VGIC_CONFIG_EDGE;
> @@ -303,18 +297,11 @@ static void vgic_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
> }
> }
>
> -static void vgic_v5_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
> +static void vgic_v5_setup_private_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq)
> {
> - struct vgic_irq *irq = &vcpu->arch.vgic_cpu.private_irqs[i];
> - u32 intid = vgic_v5_make_ppi(i);
> -
> - INIT_LIST_HEAD(&irq->ap_list);
> - raw_spin_lock_init(&irq->irq_lock);
> - irq->vcpu = NULL;
> - irq->target_vcpu = vcpu;
> - refcount_set(&irq->refcount, 0);
> + int i = irq - &vcpu->arch.vgic_cpu.private_irqs[0];
>
> - irq->intid = intid;
> + irq->intid = vgic_v5_make_ppi(i);
>
> /* The only Edge architected PPI is the SW_PPI */
> if (i == GICV5_ARCH_PPI_SW_PPI)
> @@ -323,7 +310,7 @@ static void vgic_v5_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
> irq->config = VGIC_CONFIG_LEVEL;
>
> /* Register the GICv5-specific PPI ops */
> - vgic_v5_set_ppi_ops(vcpu, intid);
> + vgic_v5_set_ppi_ops(vcpu, irq->intid);
> }
>
> static int vgic_allocate_private_irqs_locked(struct kvm_vcpu *vcpu, u32 type)
> @@ -349,15 +336,19 @@ static int vgic_allocate_private_irqs_locked(struct kvm_vcpu *vcpu, u32 type)
> if (!vgic_cpu->private_irqs)
> return -ENOMEM;
>
> - /*
> - * Enable and configure all SGIs to be edge-triggered and
> - * configure all PPIs as level-triggered.
> - */
> for (i = 0; i < num_private_irqs; i++) {
> + struct vgic_irq *irq = &vcpu->arch.vgic_cpu.private_irqs[i];
> +
> + INIT_LIST_HEAD(&irq->ap_list);
> + raw_spin_lock_init(&irq->irq_lock);
> + irq->vcpu = NULL;
> + irq->target_vcpu = vcpu;
> + refcount_set(&irq->refcount, 0);
> +
> if (vgic_is_v5(vcpu->kvm))
> - vgic_v5_allocate_private_irq(vcpu, i, type);
> + vgic_v5_setup_private_irq(vcpu, irq);
> else
> - vgic_allocate_private_irq(vcpu, i, type);
> + vgic_setup_private_irq(vcpu, irq, type);
> }
>
> return 0;
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Thanks,
Joey
^ permalink raw reply
* Re: [PATCH v2 1/2] kernel: param: handle NULL module_kset in lookup_or_create_module_kobject()
From: Greg Kroah-Hartman @ 2026-04-21 15:20 UTC (permalink / raw)
To: Shashank Balaji
Cc: Kay Sievers, Rafael J. Wysocki, Danilo Krummrich,
Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
Shuah Khan, Rahul Bukte, Daniel Palmer, Tim Bird, linux-kernel,
driver-core, coresight, linux-arm-kernel, rust-for-linux,
linux-doc
In-Reply-To: <aeeQ5x1uMKT6cyxp@JPC00244420>
On Tue, Apr 21, 2026 at 11:59:51PM +0900, Shashank Balaji wrote:
> Hi Greg,
>
> Thanks for the quick feedback!
>
> On Tue, Apr 21, 2026 at 08:27:10AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 21, 2026 at 03:02:34PM +0900, Shashank Balaji wrote:
> > > module_kset is initialized in a subsys_initcall. If a built-in driver tries to
> > > register before subsys_initcall with its struct device_driver's mod_name set,
> > > then a null module_kset is dereferenced via this call trace:
> > >
> > > [ 0.095865] Call trace:
> > > [ 0.095999] _raw_spin_lock+0x4c/0x6c (P)
> > > [ 0.096150] kset_find_obj+0x24/0x104
> > > [ 0.096209] lookup_or_create_module_kobject+0x2c/0xd8
> > > [ 0.096274] module_add_driver+0xd4/0x138
> > > [ 0.096328] bus_add_driver+0x16c/0x268
> > > [ 0.096380] driver_register+0x68/0x100
> > > [ 0.096428] __platform_driver_register+0x24/0x30
> > > [ 0.096486] tegra194_cbb_init+0x24/0x30
> > > [ 0.096540] do_one_initcall+0xdc/0x250
> > > [ 0.096608] do_initcall_level+0x9c/0xd0
> > > [ 0.096660] do_initcalls+0x54/0x94
> > > [ 0.096706] do_basic_setup+0x20/0x2c
> > > [ 0.096753] kernel_init_freeable+0xc8/0x154
> > > [ 0.096807] kernel_init+0x20/0x1a0
> > > [ 0.096851] ret_from_fork+0x10/0x20
> > >
> > > So, return null in lookup_or_create_module_kobject() if module_kset is null.
> > > Existing callers handle null already.
> > >
> > > Fixes: f30c53a873d0 ("MODULES: add the module name for built in kernel drivers")
> >
> > This isn't a bugfix.
>
> I'll drop it in the next version.
>
> > > Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> > > Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> > > Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> > > ---
> > > This bug is triggered by the next patch on arm64 defconfig: tegra194-cbb tries
> > > to register from a pure_initcall, and with the next patch adding mod_name, this
> > > null deref is hit.
> >
> > So this isn't a bug, it's a "don't do that" type of thing :)
> >
> > > ---
> > > kernel/params.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/kernel/params.c b/kernel/params.c
> > > index 74d620bc2521..881c7328c059 100644
> > > --- a/kernel/params.c
> > > +++ b/kernel/params.c
> > > @@ -752,6 +752,9 @@ lookup_or_create_module_kobject(const char *name)
> > > struct kobject *kobj;
> > > int err;
> > >
> > > + if (!module_kset)
> > > + return NULL;
> >
> > Are you sure that making this change is going to be ok?
> > mod_sysfs_init() should have been called first as the module has to be
> > created before it can be looked up.
> >
> > As you are wanting "built in" drivers to show up here, you are going to
> > beat the call to param_sysfs_init(), so don't do that. Make sure that
> > the drivers are NOT called before then.
>
> The reason lookup_or_create_module_kobject() can be reached with module_kset == NULL
> is that some platform drivers register before subsys_initcall: tegra194_cbb and
> tegra234_cbb at pure_initcall, plus roughly 375 others at core_initcall/arch_initcall
> (208 arch, 154 core, plus 2 pure and 13 _sync variants). These are dominated by
> pinctrl, clk, interconnect, gpio, and mailbox drivers across six SoC vendor trees
> (Qualcomm, MediaTek, Freescale, Samsung, Tegra, HiSilicon).
That's not good, everyone wants to be first. It's amazing it works at
all sometimes...
> Given that, three ways forward:
>
> 1. Move module_kset creation out of param_sysfs_init() (currently
> subsys_initcall) and call it directly from do_basic_setup()
> before do_initcalls(). This is the cleanest fix from a
> correctness angle: every initcall level sees a live
> module_kset. But it touches init/main.c and kernel/params.c,
> crosses two subsystem trees. I haven't fully audited
> dependencies at do_basic_setup() time.
That's one way, OR dynamically create the kset the first time it is
asked for.
> 2. Demote the ~377 early-initcall platform drivers to
> subsys_initcall or later. Impractical at scale given coordination
> across six vendor trees, and many of these levels seem to be
> architecturally required.
Ick, yeah, that is sure to be a nightmare as there will be regressions.
> 3. (This patch) Guard lookup_or_create_module_kobject() against
> NULL module_kset. Drivers registered before subsys_initcall
> don't get the /sys/.../module symlink, but they don't get it
> today either (drv->mod_name is NULL pre-patch, so the
> else-if (drv->mod_name) branch in module_add_driver() isn't
> taken). Verified on arm64: /sys/module/tegra194_cbb/ does not
> exist on a booted defconfig with or without my series. The
> guard preserves that exact state while letting the
> device_initcall majority get their symlinks as designed.
THat's going to confuse people as to why some have the link and others
do not. How about moving it earlier OR creating it dynamically when
first needed?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/4] kselftest/arm64: Add POE helpers to test_signals_utils.h
From: Mark Brown @ 2026-04-21 15:00 UTC (permalink / raw)
To: Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, Catalin Marinas, Joey Gouly,
Shuah Khan, Will Deacon, linux-kselftest
In-Reply-To: <20260421144252.1440365-4-kevin.brodsky@arm.com>
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
On Tue, Apr 21, 2026 at 03:42:51PM +0100, Kevin Brodsky wrote:
> In preparation to adding further POE signal tests, move
> get_por_el0() to test_signals_utils.h and add set_por_el0().
Subject line should probably also say move if there's a v2 but otherwise
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] kernel: param: handle NULL module_kset in lookup_or_create_module_kobject()
From: Shashank Balaji @ 2026-04-21 14:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Kay Sievers, Rafael J. Wysocki, Danilo Krummrich,
Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
Shuah Khan, Rahul Bukte, Daniel Palmer, Tim Bird, linux-kernel,
driver-core, coresight, linux-arm-kernel, rust-for-linux,
linux-doc
In-Reply-To: <2026042126-majesty-skyline-b76f@gregkh>
Hi Greg,
Thanks for the quick feedback!
On Tue, Apr 21, 2026 at 08:27:10AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 21, 2026 at 03:02:34PM +0900, Shashank Balaji wrote:
> > module_kset is initialized in a subsys_initcall. If a built-in driver tries to
> > register before subsys_initcall with its struct device_driver's mod_name set,
> > then a null module_kset is dereferenced via this call trace:
> >
> > [ 0.095865] Call trace:
> > [ 0.095999] _raw_spin_lock+0x4c/0x6c (P)
> > [ 0.096150] kset_find_obj+0x24/0x104
> > [ 0.096209] lookup_or_create_module_kobject+0x2c/0xd8
> > [ 0.096274] module_add_driver+0xd4/0x138
> > [ 0.096328] bus_add_driver+0x16c/0x268
> > [ 0.096380] driver_register+0x68/0x100
> > [ 0.096428] __platform_driver_register+0x24/0x30
> > [ 0.096486] tegra194_cbb_init+0x24/0x30
> > [ 0.096540] do_one_initcall+0xdc/0x250
> > [ 0.096608] do_initcall_level+0x9c/0xd0
> > [ 0.096660] do_initcalls+0x54/0x94
> > [ 0.096706] do_basic_setup+0x20/0x2c
> > [ 0.096753] kernel_init_freeable+0xc8/0x154
> > [ 0.096807] kernel_init+0x20/0x1a0
> > [ 0.096851] ret_from_fork+0x10/0x20
> >
> > So, return null in lookup_or_create_module_kobject() if module_kset is null.
> > Existing callers handle null already.
> >
> > Fixes: f30c53a873d0 ("MODULES: add the module name for built in kernel drivers")
>
> This isn't a bugfix.
I'll drop it in the next version.
> > Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> > Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> > Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> > ---
> > This bug is triggered by the next patch on arm64 defconfig: tegra194-cbb tries
> > to register from a pure_initcall, and with the next patch adding mod_name, this
> > null deref is hit.
>
> So this isn't a bug, it's a "don't do that" type of thing :)
>
> > ---
> > kernel/params.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/kernel/params.c b/kernel/params.c
> > index 74d620bc2521..881c7328c059 100644
> > --- a/kernel/params.c
> > +++ b/kernel/params.c
> > @@ -752,6 +752,9 @@ lookup_or_create_module_kobject(const char *name)
> > struct kobject *kobj;
> > int err;
> >
> > + if (!module_kset)
> > + return NULL;
>
> Are you sure that making this change is going to be ok?
> mod_sysfs_init() should have been called first as the module has to be
> created before it can be looked up.
>
> As you are wanting "built in" drivers to show up here, you are going to
> beat the call to param_sysfs_init(), so don't do that. Make sure that
> the drivers are NOT called before then.
The reason lookup_or_create_module_kobject() can be reached with module_kset == NULL
is that some platform drivers register before subsys_initcall: tegra194_cbb and
tegra234_cbb at pure_initcall, plus roughly 375 others at core_initcall/arch_initcall
(208 arch, 154 core, plus 2 pure and 13 _sync variants). These are dominated by
pinctrl, clk, interconnect, gpio, and mailbox drivers across six SoC vendor trees
(Qualcomm, MediaTek, Freescale, Samsung, Tegra, HiSilicon).
Given that, three ways forward:
1. Move module_kset creation out of param_sysfs_init() (currently
subsys_initcall) and call it directly from do_basic_setup()
before do_initcalls(). This is the cleanest fix from a
correctness angle: every initcall level sees a live
module_kset. But it touches init/main.c and kernel/params.c,
crosses two subsystem trees. I haven't fully audited
dependencies at do_basic_setup() time.
2. Demote the ~377 early-initcall platform drivers to
subsys_initcall or later. Impractical at scale given coordination
across six vendor trees, and many of these levels seem to be
architecturally required.
3. (This patch) Guard lookup_or_create_module_kobject() against
NULL module_kset. Drivers registered before subsys_initcall
don't get the /sys/.../module symlink, but they don't get it
today either (drv->mod_name is NULL pre-patch, so the
else-if (drv->mod_name) branch in module_add_driver() isn't
taken). Verified on arm64: /sys/module/tegra194_cbb/ does not
exist on a booted defconfig with or without my series. The
guard preserves that exact state while letting the
device_initcall majority get their symlinks as designed.
I went with option 3 because it preserves observable behaviour
everywhere and keeps the series scoped to driver-core. If you'd
rather I do option 1 instead, I'm happy to.
Thanks,
Shashank
^ permalink raw reply
* Re: [PATCH 2/4] kselftest/arm64: Add POE as a feature in the signal tests
From: Mark Brown @ 2026-04-21 14:58 UTC (permalink / raw)
To: Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, Catalin Marinas, Joey Gouly,
Shuah Khan, Will Deacon, linux-kselftest
In-Reply-To: <20260421144252.1440365-3-kevin.brodsky@arm.com>
[-- Attachment #1: Type: text/plain, Size: 194 bytes --]
On Tue, Apr 21, 2026 at 03:42:50PM +0100, Kevin Brodsky wrote:
> Add the POE feature to the signal tests framework, to allow tests to
> require it.
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: power: Add power-domains-child-ids property
From: Kevin Hilman @ 2026-04-21 14:57 UTC (permalink / raw)
To: Rob Herring
Cc: Ulf Hansson, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <20260421134949.GA1045294-robh@kernel.org>
Rob Herring <robh@kernel.org> writes:
> On Mon, Apr 20, 2026 at 04:51:17PM -0700, Kevin Hilman (TI) wrote:
>> Add binding documentation for the new power-domains-child-ids property,
>> which works in conjunction with the existing power-domains property to
>> establish parent-child relationships between a multi-domain power domain
>> provider and external parent domains.
>>
>> Each element in the uint32 array identifies the child domain
>> ID (index) within the provider that should be made a child domain of
>> the corresponding phandle entry in power-domains. The two arrays must
>> have the same number of elements.
>>
>> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
>
> Missing my Reviewed-by.
Oops, I thought I had grabbed it with b4, but I didn't. Sorry.
Kevin
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-21 14:50 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
In-Reply-To: <aeZUAaQkHGqBL8st@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 3719 bytes --]
Hello Andrea,
On Mon, Apr 20, 2026 at 06:27:45PM +0200, Andrea della Porta wrote:
> On 12:50 Fri 17 Apr , Uwe Kleine-König wrote:
> > What happens if sync is asserted while a disabled channel didn't
> > complete the last period yet?
>
> The output stops immediately without waiting for the current period to finish.
This is a good info for the Limitations block.
> > Maybe it's worth to test the following procedure for updating duty and
> > period:
> >
> > disable channel
> > configure duty
> > configure period
> > enable
> > set update flag
> >
> > Assumint disable is delayed until the end of the currently running
> > period, the effect of this procedure might be that no glitch happens if
> > the update flag is asserted before the currently running period ends and
> > the anormality is reduced to a longer inactive state if the updates are
> > not that lucky (in contrast to more severe glitches).
>
> The disable isn't delayed as explained above. Setting just the new period/duty
> (which do not depend on the sync bit) correctly waits for the end of the current
> period without noticeable glitches (tested with a scope).
So if you happen to change both and one is done before the end of the
current period and the other shortly afterwards (which might happen as
those are configured in two different registers and the update trigger
isn't used), you get a mixed output for one cycle, right? If yes, please
also mention that in the Limitations paragraph.
> > > Let's say that teh user want 10 tick period, we have to use
> > > 9 instead to account for the extra tick at the end, so that the complete period
> > > contains that extra tick?
> >
> > I would describe that a bit differently, but in general: yes.
> >
> > The more straight forward description is that setting
> >
> > RP1_PWM_RANGE(pwm->hwpwm) := x
> >
> > results in a period of x + 1 ticks.
>
> Exactly. So whatever the user request I have to subtract one from the value
> to be written to the RANGE register.
Unless the calculation is already rounded to 0, in that case don't
subtract 1 and let the tohw callback return 1.
> > > This also means that if we ask for 100% duty cycle, the output waveform will
> > > have the high part of the signal lasting one tick less than expected.a I guess
> > > this is the accepted compromise.
> >
> > I assume you considered something like:
> >
> > RP1_PWM_RANGE(pwm->hwpwm) := 17
> > RP1_PWM_DUTY(pwm->hwpwm) := 18
> >
> > to get a 100% relative duty?
>
> Ah right! It's working fine and I've got 100% duty. So at hw register level
> the duty can be greater that the period.
In that case please make sure to not use the maximal value for
RP1_PWM_RANGE(pwm->hwpwm) to ensure that for each (possible) period
length a 100% relative duty cycle can be configured.
> > My (not so well articulated) point is: Please be stringent about clock
> > handling to not bank up technical dept more than necessary and such that
> > the driver can be made unbindable if and when syscons grow
> > that feature. Optionally wail at the syscon guys :-)
>
> Hmmm not sure I've understood your point: is it a requirement that the driver
> must be unbindable? In this case I should avoid registering the syscon. Or
> should I just provide a .remove callback in case there will be a way to
> unregister the syscon (even if this callback will not be called as of now)?
It's a requirement to properly manage the resources you allocate. If a
driver isn't unbindable due to restrictions of other subsystems that's
unfortunate and I don't like it, but I wouldn't block a patch because of
that.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: add tqma9596la-mba95xxca
From: Daniel Baluta @ 2026-04-21 14:48 UTC (permalink / raw)
To: Alexander Stein, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Markus Niebel, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260326111803.1248934-2-alexander.stein@ew.tq-group.com>
[..]
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + linux_cma: linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + size = <0 0x28000000>;
> + alloc-ranges = <0 0x80000000 0 0x80000000>;
> + linux,cma-default;
> + };
> +
> + vpu_boot: vpu_boot@a0000000 {
Should this be memory@a0000000 ?
^ permalink raw reply
* [PATCH 4/4] kselftest/arm64: Add tests for POR_EL0 save/reset/restore
From: Kevin Brodsky @ 2026-04-21 14:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Kevin Brodsky, Catalin Marinas, Joey Gouly,
Mark Brown, Shuah Khan, Will Deacon, linux-kselftest
In-Reply-To: <20260421144252.1440365-1-kevin.brodsky@arm.com>
POR_EL0 is expected to be:
- Saved in the poe_context record
- Reset to POR_EL0_INIT when invoking the signal handler
- Restored from poe_context when returning from the signal handler
Add a new test, poe_restore, to check that the save/reset/restore
mechanism is working as intended. See commit 2e8a1acea859 ("arm64:
signal: Improve POR_EL0 handling to avoid uaccess failures") for
more details.
This commit did not handle the case where poe_context is missing
correctly. This was recently fixed; add a new test,
poe_missing_poe_context, to check this case.
Note: td->pass is only set to true at the very end, as an unexpected
signal may occur in case of failure (especially in
poe_missing_poe_context if POR_EL0 is restored to an invalid value).
Failures are tracked with a global, failed_check.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
.../testcases/poe_missing_poe_context.c | 73 +++++++++++++++++++
.../arm64/signal/testcases/poe_restore.c | 64 ++++++++++++++++
2 files changed, 137 insertions(+)
create mode 100644 tools/testing/selftests/arm64/signal/testcases/poe_missing_poe_context.c
create mode 100644 tools/testing/selftests/arm64/signal/testcases/poe_restore.c
diff --git a/tools/testing/selftests/arm64/signal/testcases/poe_missing_poe_context.c b/tools/testing/selftests/arm64/signal/testcases/poe_missing_poe_context.c
new file mode 100644
index 000000000000..abab7400d9df
--- /dev/null
+++ b/tools/testing/selftests/arm64/signal/testcases/poe_missing_poe_context.c
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026 Arm Ltd
+ *
+ * Verify that the POR_EL0 register is left untouched on sigreturn if the
+ * POE frame record is missing.
+ */
+
+#include <asm/sigcontext.h>
+
+#include "test_signals_utils.h"
+#include "testcases.h"
+
+#define POR_EL0_INIT 0x07ul
+#define POR_EL0_CUSTOM 0x77ul
+
+static bool failed_check;
+
+static bool modify_por_el0(struct tdescr *td)
+{
+ set_por_el0(POR_EL0_CUSTOM);
+
+ return true;
+}
+
+static int signal_remove_poe_context(struct tdescr *td, siginfo_t *si,
+ ucontext_t *uc)
+{
+ struct _aarch64_ctx *ctx = GET_UC_RESV_HEAD(uc);
+ struct _aarch64_ctx *poe_ctx_head;
+
+ poe_ctx_head = get_header(ctx, POE_MAGIC, sizeof(uc->uc_mcontext),
+ NULL);
+ if (!poe_ctx_head) {
+ fprintf(stderr, "Missing poe_context record\n");
+ failed_check = true;
+ return 0;
+ }
+
+ /*
+ * Actually removing the record would require moving down the next
+ * records. An easier option is to turn it into an ESR record, which is
+ * ignored by sigreturn().
+ */
+ poe_ctx_head->magic = ESR_MAGIC;
+
+ return 0;
+}
+
+static void check_por_el0_preserved(struct tdescr *td)
+{
+ uint64_t por_el0 = get_por_el0();
+
+ if (por_el0 == POR_EL0_INIT) {
+ fprintf(stderr, "POR_EL0 preserved\n");
+ } else {
+ fprintf(stderr, "POR_EL0 unexpectedly set to %lx\n", por_el0);
+ failed_check = true;
+ }
+
+ td->pass = !failed_check;
+}
+
+struct tdescr tde = {
+ .name = "POR_EL0 missing poe_context",
+ .descr = "Remove poe_context record and check POR_EL0 is preserved",
+ .feats_required = FEAT_POE,
+ .timeout = 3,
+ .sig_trig = SIGUSR1,
+ .init = modify_por_el0,
+ .run = signal_remove_poe_context,
+ .check_result = check_por_el0_preserved,
+};
diff --git a/tools/testing/selftests/arm64/signal/testcases/poe_restore.c b/tools/testing/selftests/arm64/signal/testcases/poe_restore.c
new file mode 100644
index 000000000000..9f9a61a4214d
--- /dev/null
+++ b/tools/testing/selftests/arm64/signal/testcases/poe_restore.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026 Arm Ltd
+ *
+ * Verify that the POR_EL0 register is saved and restored as expected on signal
+ * entry/return.
+ */
+
+#include <asm/sigcontext.h>
+
+#include "test_signals_utils.h"
+#include "testcases.h"
+
+#define POR_EL0_INIT 0x07ul
+#define POR_EL0_CUSTOM 0x77ul
+
+static bool failed_check;
+
+static bool modify_por_el0(struct tdescr *td)
+{
+ set_por_el0(POR_EL0_CUSTOM);
+
+ return true;
+}
+
+static int signal_check_por_el0_reset(struct tdescr *td, siginfo_t *si,
+ ucontext_t *uc)
+{
+ uint64_t signal_por_el0 = get_por_el0();
+
+ if (signal_por_el0 != POR_EL0_INIT) {
+ fprintf(stderr, "POR_EL0 is %lx in signal handler (expected %lx)\n",
+ signal_por_el0, POR_EL0_INIT);
+ failed_check = true;
+ }
+
+ return 0;
+}
+
+static void check_por_el0_restored(struct tdescr *td)
+{
+ uint64_t por_el0 = get_por_el0();
+
+ if (por_el0 == POR_EL0_CUSTOM) {
+ fprintf(stderr, "POR_EL0 restored\n");
+ } else {
+ fprintf(stderr, "POR_EL0 was %lx but is now %lx\n",
+ POR_EL0_CUSTOM, por_el0);
+ failed_check = true;
+ }
+
+ td->pass = !failed_check;
+}
+
+struct tdescr tde = {
+ .name = "POR_EL0 restore",
+ .descr = "Validate that POR_EL0 is saved/restored on signal entry/return",
+ .feats_required = FEAT_POE,
+ .timeout = 3,
+ .sig_trig = SIGUSR1,
+ .init = modify_por_el0,
+ .run = signal_check_por_el0_reset,
+ .check_result = check_por_el0_restored,
+};
--
2.51.2
^ permalink raw reply related
* [PATCH 2/4] kselftest/arm64: Add POE as a feature in the signal tests
From: Kevin Brodsky @ 2026-04-21 14:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Kevin Brodsky, Catalin Marinas, Joey Gouly,
Mark Brown, Shuah Khan, Will Deacon, linux-kselftest
In-Reply-To: <20260421144252.1440365-1-kevin.brodsky@arm.com>
Add the POE feature to the signal tests framework, to allow tests to
require it.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
tools/testing/selftests/arm64/signal/test_signals.h | 2 ++
tools/testing/selftests/arm64/signal/test_signals_utils.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/tools/testing/selftests/arm64/signal/test_signals.h b/tools/testing/selftests/arm64/signal/test_signals.h
index ee75a2c25ce7..c7c343494cb8 100644
--- a/tools/testing/selftests/arm64/signal/test_signals.h
+++ b/tools/testing/selftests/arm64/signal/test_signals.h
@@ -36,6 +36,7 @@ enum {
FSME_FA64_BIT,
FSME2_BIT,
FGCS_BIT,
+ FPOE_BIT,
FMAX_END
};
@@ -45,6 +46,7 @@ enum {
#define FEAT_SME_FA64 (1UL << FSME_FA64_BIT)
#define FEAT_SME2 (1UL << FSME2_BIT)
#define FEAT_GCS (1UL << FGCS_BIT)
+#define FEAT_POE (1UL << FPOE_BIT)
/*
* A descriptor used to describe and configure a test case.
diff --git a/tools/testing/selftests/arm64/signal/test_signals_utils.c b/tools/testing/selftests/arm64/signal/test_signals_utils.c
index 5d3621921cfe..4b12dbd7669d 100644
--- a/tools/testing/selftests/arm64/signal/test_signals_utils.c
+++ b/tools/testing/selftests/arm64/signal/test_signals_utils.c
@@ -31,6 +31,7 @@ static char const *const feats_names[FMAX_END] = {
" FA64 ",
" SME2 ",
" GCS ",
+ " POE ",
};
#define MAX_FEATS_SZ 128
@@ -341,6 +342,8 @@ int test_init(struct tdescr *td)
td->feats_supported |= FEAT_SME2;
if (getauxval(AT_HWCAP) & HWCAP_GCS)
td->feats_supported |= FEAT_GCS;
+ if (getauxval(AT_HWCAP2) & HWCAP2_POE)
+ td->feats_supported |= FEAT_POE;
if (feats_ok(td)) {
if (td->feats_required & td->feats_supported)
fprintf(stderr,
--
2.51.2
^ permalink raw reply related
* [PATCH 3/4] kselftest/arm64: Add POE helpers to test_signals_utils.h
From: Kevin Brodsky @ 2026-04-21 14:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Kevin Brodsky, Catalin Marinas, Joey Gouly,
Mark Brown, Shuah Khan, Will Deacon, linux-kselftest
In-Reply-To: <20260421144252.1440365-1-kevin.brodsky@arm.com>
In preparation to adding further POE signal tests, move
get_por_el0() to test_signals_utils.h and add set_por_el0().
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
.../selftests/arm64/signal/test_signals_utils.h | 16 ++++++++++++++++
.../arm64/signal/testcases/poe_siginfo.c | 15 ---------------
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/tools/testing/selftests/arm64/signal/test_signals_utils.h b/tools/testing/selftests/arm64/signal/test_signals_utils.h
index 36fc12b3cd60..2c7b8c64a35a 100644
--- a/tools/testing/selftests/arm64/signal/test_signals_utils.h
+++ b/tools/testing/selftests/arm64/signal/test_signals_utils.h
@@ -57,6 +57,22 @@ static inline __attribute__((always_inline)) uint64_t get_gcspr_el0(void)
return val;
}
+#define SYS_POR_EL0 "S3_3_C10_C2_4"
+
+static inline uint64_t get_por_el0(void)
+{
+ uint64_t val;
+
+ asm volatile("mrs %0, " SYS_POR_EL0 "\n" : "=r"(val));
+
+ return val;
+}
+
+static inline void set_por_el0(uint64_t val)
+{
+ asm volatile("msr " SYS_POR_EL0 ", %0\n" :: "r"(val));
+}
+
static inline bool feats_ok(struct tdescr *td)
{
if (td->feats_incompatible & td->feats_supported)
diff --git a/tools/testing/selftests/arm64/signal/testcases/poe_siginfo.c b/tools/testing/selftests/arm64/signal/testcases/poe_siginfo.c
index 36bd9940ee05..e15fedf4da6e 100644
--- a/tools/testing/selftests/arm64/signal/testcases/poe_siginfo.c
+++ b/tools/testing/selftests/arm64/signal/testcases/poe_siginfo.c
@@ -21,21 +21,6 @@ static union {
char buf[1024 * 128];
} context;
-#define SYS_POR_EL0 "S3_3_C10_C2_4"
-
-static uint64_t get_por_el0(void)
-{
- uint64_t val;
-
- asm volatile(
- "mrs %0, " SYS_POR_EL0 "\n"
- : "=r"(val)
- :
- : );
-
- return val;
-}
-
int poe_present(struct tdescr *td, siginfo_t *si, ucontext_t *uc)
{
struct _aarch64_ctx *head = GET_BUF_RESV_HEAD(context);
--
2.51.2
^ permalink raw reply related
* [PATCH 1/4] arm64: signal: Preserve POR_EL0 if poe_context is missing
From: Kevin Brodsky @ 2026-04-21 14:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Kevin Brodsky, Catalin Marinas, Joey Gouly,
Mark Brown, Shuah Khan, Will Deacon, linux-kselftest
In-Reply-To: <20260421144252.1440365-1-kevin.brodsky@arm.com>
Commit 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to
avoid uaccess failures") delayed the write to POR_EL0 in
rt_sigreturn to avoid spurious uaccess failures. This change however
relies on the poe_context frame record being present: on a system
supporting POE, calling sigreturn without a poe_context record now
results in writing arbitrary data from the kernel stack into POR_EL0.
Fix this by adding a valid_fields member to struct
user_access_state, and zeroing the struct on allocation.
restore_poe_context() then indicates that the por_el0 field is valid
by setting the corresponding bit in valid_fields, and
restore_user_access_state() only touches POR_EL0 if there is a valid
value to set it to. This is in line with how POR_EL0 was originally
handled; all frame records are currently optional, except
fpsimd_context.
restore_user_access_state() is also called if setting up the signal
frame fails, so we also initialise valid_fields in that case. For
consistency, setup_sigframe() now also checks valid_fields to decide
whether to write a poe_context record, avoiding another call to
system_supports_poe().
Fixes: 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to avoid uaccess failures")
Reported-by: Will Deacon <will@kernel.org>
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
arch/arm64/kernel/signal.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 08ffc5a5aea4..3f17aed5b4f0 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -67,6 +67,8 @@ struct rt_sigframe_user_layout {
unsigned long end_offset;
};
+#define UA_STATE_HAS_POR_EL0 BIT(0)
+
/*
* Holds any EL0-controlled state that influences unprivileged memory accesses.
* This includes both accesses done in userspace and uaccess done in the kernel.
@@ -74,8 +76,12 @@ struct rt_sigframe_user_layout {
* This state needs to be carefully managed to ensure that it doesn't cause
* uaccess to fail when setting up the signal frame, and the signal handler
* itself also expects a well-defined state when entered.
+ *
+ * The valid_fields member is a bitfield (see UA_STATE_HAS_*), specifying which
+ * of the remaining fields is valid (has been set to a value).
*/
struct user_access_state {
+ unsigned int valid_fields;
u64 por_el0;
};
@@ -95,6 +101,7 @@ static void save_reset_user_access_state(struct user_access_state *ua_state)
por_enable_all |= POR_ELx_PERM_PREP(pkey, POE_RWX);
ua_state->por_el0 = read_sysreg_s(SYS_POR_EL0);
+ ua_state->valid_fields |= UA_STATE_HAS_POR_EL0;
write_sysreg_s(por_enable_all, SYS_POR_EL0);
/*
* No ISB required as we can tolerate spurious Overlay faults -
@@ -122,7 +129,7 @@ static void set_handler_user_access_state(void)
*/
static void restore_user_access_state(const struct user_access_state *ua_state)
{
- if (system_supports_poe())
+ if (ua_state->valid_fields & UA_STATE_HAS_POR_EL0)
write_sysreg_s(ua_state->por_el0, SYS_POR_EL0);
}
@@ -352,8 +359,10 @@ static int restore_poe_context(struct user_ctxs *user,
return -EINVAL;
__get_user_error(por_el0, &(user->poe->por_el0), err);
- if (!err)
+ if (!err) {
ua_state->por_el0 = por_el0;
+ ua_state->valid_fields |= UA_STATE_HAS_POR_EL0;
+ }
return err;
}
@@ -1095,7 +1104,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
{
struct pt_regs *regs = current_pt_regs();
struct rt_sigframe __user *frame;
- struct user_access_state ua_state;
+ struct user_access_state ua_state = {0};
/* Always make any pending restarted system calls return -EINTR */
current->restart_block.fn = do_no_restart_syscall;
@@ -1302,7 +1311,7 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
err |= preserve_fpmr_context(fpmr_ctx);
}
- if (system_supports_poe() && err == 0) {
+ if ((ua_state->valid_fields & UA_STATE_HAS_POR_EL0) && err == 0) {
struct poe_context __user *poe_ctx =
apply_user_offset(user, user->poe_offset);
@@ -1507,7 +1516,7 @@ static int setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set,
{
struct rt_sigframe_user_layout user;
struct rt_sigframe __user *frame;
- struct user_access_state ua_state;
+ struct user_access_state ua_state = {0};
int err = 0;
fpsimd_save_and_flush_current_state();
--
2.51.2
^ permalink raw reply related
* [PATCH 0/4] POE sigreturn fix and extra tests
From: Kevin Brodsky @ 2026-04-21 14:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Kevin Brodsky, Catalin Marinas, Joey Gouly,
Mark Brown, Shuah Khan, Will Deacon, linux-kselftest
Commit 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to
avoid uaccess failures") introduced special handling for EL0 registers
that impact uaccess. This did not however handle the case where a signal
handler removes the relevant record (poe_context for POE) from the
signal frame; this is clearly not typical behaviour but it is legal.
That commit resulted in arbitrary data from the kernel stack being
written to POR_EL0 in that case.
Patch 1 fixes this by tracking which fields in struct user_access_state
are actually valid. This restores the original behaviour, where POR_EL0
is left untouched if poe_context is removed.
The remaining patches add new tests to the arm64 signal kselftests to
check that POR_EL0 is reset and restored (or preserved) as expected.
---
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Joey Gouly <joey.gouly@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: linux-kselftest@vger.kernel.org
---
Kevin Brodsky (4):
arm64: signal: Preserve POR_EL0 if poe_context is missing
kselftest/arm64: Add POE as a feature in the signal tests
kselftest/arm64: Add POE helpers to test_signals_utils.h
kselftest/arm64: Add tests for POR_EL0 save/reset/restore
arch/arm64/kernel/signal.c | 19 +++--
.../selftests/arm64/signal/test_signals.h | 2 +
.../arm64/signal/test_signals_utils.c | 3 +
.../arm64/signal/test_signals_utils.h | 16 ++++
.../testcases/poe_missing_poe_context.c | 73 +++++++++++++++++++
.../arm64/signal/testcases/poe_restore.c | 64 ++++++++++++++++
.../arm64/signal/testcases/poe_siginfo.c | 15 ----
7 files changed, 172 insertions(+), 20 deletions(-)
create mode 100644 tools/testing/selftests/arm64/signal/testcases/poe_missing_poe_context.c
create mode 100644 tools/testing/selftests/arm64/signal/testcases/poe_restore.c
base-commit: 028ef9c96e96197026887c0f092424679298aae8
--
2.51.2
^ permalink raw reply
* [PATCH] smccc: Replace __ASSEMBLY__ with __ASSEMBLER__
From: Thomas Huth @ 2026-04-21 14:40 UTC (permalink / raw)
To: Mark Rutland, Lorenzo Pieralisi, Sudeep Holla, Will Deacon
Cc: linux-arm-kernel, linux-kernel
From: Thomas Huth <thuth@redhat.com>
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This can be very confusing when switching between userspace
and kernelspace coding, or when dealing with uapi headers that
rather should use __ASSEMBLER__ instead. So let's standardize now
on the __ASSEMBLER__ macro that is provided by the compilers.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
Note: This patch has been split from an earlier patch series of mine
to ease reviewing
include/linux/arm-smccc.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 50b47eba7d015..96d7a61055a70 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -8,7 +8,7 @@
#include <linux/args.h>
#include <linux/init.h>
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <linux/uuid.h>
#endif
@@ -302,7 +302,7 @@
#define SMCCC_RET_NOT_REQUIRED -2
#define SMCCC_RET_INVALID_PARAMETER -3
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <linux/linkage.h>
#include <linux/types.h>
@@ -353,7 +353,7 @@ s32 arm_smccc_get_soc_id_version(void);
*/
s32 arm_smccc_get_soc_id_revision(void);
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
/*
* Returns whether a specific hypervisor UUID is advertised for the
@@ -402,7 +402,7 @@ static inline u32 smccc_uuid_to_reg(const uuid_t *uuid, int reg)
return val;
}
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
/**
* struct arm_smccc_res - Result from SMC/HVC call
@@ -750,5 +750,5 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
})
#endif /*CONFIG_ARM64*/
-#endif /*__ASSEMBLY__*/
+#endif /*__ASSEMBLER__*/
#endif /*__LINUX_ARM_SMCCC_H*/
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 04/12] coresight: etm4x: exclude ss_status from drvdata->config
From: Yeoreum Yun @ 2026-04-21 14:23 UTC (permalink / raw)
To: Mike Leach
Cc: Suzuki K Poulose, Leo Yan, coresight, linux-arm-kernel,
linux-kernel, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <c4d90a5e-d28c-49b3-ad6e-4f045769a44f@arm.com>
Hi Mike,
> Hi,
>
> On 4/21/26 11:30, Yeoreum Yun wrote:
> > > Hi Mike,
> > >
> > > > Hi,
> > > >
> > > > This register [bit 31] indicates if a single shot comparator has matched. So
> > > > read-back provides information to the user post run to determine which if
> > > > any of the comparators set in this way has actually matched.
> > >
> > > Okay. so after disable sysfs session, to check former session
> > > check whether comprator has matched.
> > >
> > > >
> > > > Moreover, the specification states "Software must reset this bit to 0 to
> > > > re-enable single-shot control" and "Reset state is unknown. STATUS must be
> > > > written to set an initial state...."
> > > >
> > > > Therefore this register must be written as part of any configuration so
> > > > should be available in the drvdata->config for both read and write,
> > >
> > > But I don't think this is the reason for locate ss_status into "config"
> > > since its write purpose is not to configure but the "clear" former bit.
> > > That's why I think it's enough to clear when the new sysfs session starts.
> > >
> >
> > IOW, I think it's better to remove ss_status from configfs item
> > and
> > - add field ss_cmp in etm4_cpas
> > - add another field ss_status under "etm4_drvdata" to show "PENDING
> > and STATUS" bits to sysfs after finishing session.
> >
> > Is is valid for you?
> >
>
> No. Why two different locations for a single register read? If I have the
> ETMv4 hardware manual I am going to look for a something that is
> recognizable as being related to the single shot comparator status
> register(s).
>
> So in sysfs I would expect to see all the bits from the register, displayed,
> without masking off the STATUS and PENDING bits as happens now.
>
> In the code I would expect to see a single location with a sensible name -
> ss_cmp doesn't really correlate terribly well with TRCSSCSR. If you do not
> like the original ss_status, then ss_cmp_status may actually be better,
> ss_cmp could be either the ss comparator status or control register.
Fine. But I'm still we don't need consider ss_status as configfs item.
So it's enough to move ss_status under etm4_drvdata from etm4_config and
use it.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v3 4/5] KVM: arm64: Enable HDBSS support and handle HDBSSF events
From: Leonardo Bras @ 2026-04-21 14:18 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
will, yuzenghui, wangzhou1, liuyonglong, Jonathan.Cameron,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <acpfD3YjMpEdL5KZ@devkitleo>
On Mon, Mar 30, 2026 at 12:31:28PM +0100, Leonardo Bras wrote:
> On Sat, Mar 28, 2026 at 02:05:25PM +0800, Tian Zheng wrote:
> >
> > On 3/27/2026 11:00 PM, Leonardo Bras wrote:
> > > On Fri, Mar 27, 2026 at 03:35:29PM +0800, Tian Zheng wrote:
> > > > On 3/26/2026 2:05 AM, Leonardo Bras wrote:
> > > > > Hello Tian,
> > > > >
> > > > > I am currently working on HACDBS enablement(which will be rebased on top of
> > > > > this patchset) and due to the fact HACDBS and HDBSS are kind of
> > > > > complementary I will sometimes come with some questions for issues I have
> > > > > faced myself on that part. :)
> > > > >
> > > > > (see below)
> > > >
> > > > Of course! Happy to exchange ideas and learn together.
> > > :)
Hello Tian,
On the above, HACDBS depends on HACDBSIRQ which can be announced by either
device-tree or ACPI.
Do you think it's ok for it to be ACPI only, for now?
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v5 04/12] coresight: etm4x: exclude ss_status from drvdata->config
From: Mike Leach @ 2026-04-21 14:16 UTC (permalink / raw)
To: Yeoreum Yun
Cc: Suzuki K Poulose, Leo Yan, coresight, linux-arm-kernel,
linux-kernel, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <aedRqhC1JcoeV+R2@e129823.arm.com>
Hi,
On 4/21/26 11:30, Yeoreum Yun wrote:
>> Hi Mike,
>>
>>> Hi,
>>>
>>> This register [bit 31] indicates if a single shot comparator has matched. So
>>> read-back provides information to the user post run to determine which if
>>> any of the comparators set in this way has actually matched.
>>
>> Okay. so after disable sysfs session, to check former session
>> check whether comprator has matched.
>>
>>>
>>> Moreover, the specification states "Software must reset this bit to 0 to
>>> re-enable single-shot control" and "Reset state is unknown. STATUS must be
>>> written to set an initial state...."
>>>
>>> Therefore this register must be written as part of any configuration so
>>> should be available in the drvdata->config for both read and write,
>>
>> But I don't think this is the reason for locate ss_status into "config"
>> since its write purpose is not to configure but the "clear" former bit.
>> That's why I think it's enough to clear when the new sysfs session starts.
>>
>
> IOW, I think it's better to remove ss_status from configfs item
> and
> - add field ss_cmp in etm4_cpas
> - add another field ss_status under "etm4_drvdata" to show "PENDING
> and STATUS" bits to sysfs after finishing session.
>
> Is is valid for you?
>
No. Why two different locations for a single register read? If I have
the ETMv4 hardware manual I am going to look for a something that is
recognizable as being related to the single shot comparator status
register(s).
So in sysfs I would expect to see all the bits from the register,
displayed, without masking off the STATUS and PENDING bits as happens now.
In the code I would expect to see a single location with a sensible name
- ss_cmp doesn't really correlate terribly well with TRCSSCSR. If you do
not like the original ss_status, then ss_cmp_status may actually be
better, ss_cmp could be either the ss comparator status or control
register.
Regards
Mike
>> --
>> Sincerely,
>> Yeoreum Yun
>>
>
> --
> Sincerely,
> Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 1/4] security: ima: move ima_init into late_initcall_sync
From: Yeoreum Yun @ 2026-04-21 14:09 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko, jgg,
sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <d6bcc9ef98a1e86887c5a79ff2822e70b5534343.camel@linux.ibm.com>
Hi Mimi,
> On Tue, 2026-04-21 at 13:50 +0100, Yeoreum Yun wrote:
> > Hi Mimi,
> >
> > > On Fri, 2026-04-17 at 18:57 +0100, Yeoreum Yun wrote:
> > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > the TPM driver must be built as built-in and
> > > > must be probed before the IMA subsystem is initialized.
> > > >
> > > > However, when the TPM device operates over the FF-A protocol using
> > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > interface to the tpm_crb driver — has not yet been probed.
> > > >
> > > > To ensure the TPM device operating over the FF-A protocol with
> > > > the CRB interface is probed before IMA initialization,
> > > > the following conditions must be met:
> > > >
> > > > 1. The corresponding ffa_device must be registered,
> > > > which is done via ffa_init().
> > > >
> > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > tpm_crb_ffa_init().
> > > >
> > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > be probed successfully. (See crb_acpi_add() and
> > > > tpm_crb_ffa_init() for reference.)
> > > >
> > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > >
> > > > When this occurs, probing the TPM device is deferred.
> > > > However, the deferred probe can happen after the IMA subsystem
> > > > has already been initialized, since IMA initialization is performed
> > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > at the same level.
> > > >
> > > > To resolve this, move ima_init() into late_inicall_sync level
> > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > log though TPM device presents in the system.
> > > >
> > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > >
> > > IMA should be initialized as early as possible. I'm really hesitant to defer
> > > ima_init() to late_initcall_sync() for systems that the TPM is currently
> > > initialized in time. For these systems, continue initializing IMA at
> > > late_initcall(). As a compromise for those systems that the TPM isn't properly
> > > initialized in time, define and instantiate the late_initcall_sync().
> > >
> > > ima_init() would need to differentiate between the late_initcall and
> > > late_initcall_sync. On late_initcall(), instead of saying "No TPM chip found,
> > > activating TPM-bypass!", it should say "No TPM chip found, deferring to
> > > late_initcall_sync" or something similar.
> >
> > But can we really move those initialisations to be called again?
> >
> > I am referring to functions such as ima_init_crypto(),
> > ima_add_boot_aggregate(), and ima_measure_critical_data() in ima_init()—
> > first without TPM, and then a second time once TPM becomes available.
> > I don’t think that approach would work.
> >
> > In other words, unless tpm_default_chip() can differentiate between a TPM
> > device that is deferred and one that does not exist, we cannot distinguish
> > between the “defer” case and “-EEXIST”.
> >
> > It might be possible if the TPM core tracked the state when a driver returns
> > -EPROBE_DEFER, but I am not sure that is the right approach.
> > For deferred probe cases, the “device initialised in time” check should
> > likely be done at late_initcall_sync, rather than late_initcall.
> >
> > This implies that any such check performed before late_initcall_sync
> > does not reflect a valid state, as it cannot distinguish between “not
> > present” and “deferred”.
> >
> > Therefore, I think the TPM check in IMA should be performed at
> > late_initcall_sync.
> >
> >
> > Am I missing something?
>
> In ima_init() you short circuit out, when called by late_initcall(), if the TPM
> hasn't been initialized. So the rest of the ima_init() isn't called. Roughly
> something like this (needs some cleanup):
>
> int __init ima_init(void)
> {
> static int first = 1;
> int rc;
>
> if (ima_tpm_chip)
> return 0;
>
> ima_tpm_chip = tpm_default_chip();
> if (!ima_tpm_chip && first) {
> pr_info("No TPM chip found, deferring te late_initcall_sync()\n");
> first = 0;
> return 0;
> }
I see. then I'll respin in v2.
Thanks!
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: add tqma9596la-mba95xxca
From: Alexander Stein @ 2026-04-21 14:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Markus Niebel, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260326111803.1248934-2-alexander.stein@ew.tq-group.com>
Hi,
Am Donnerstag, 26. März 2026, 12:03:30 CEST schrieb Alexander Stein:
> From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
>
> This adds support for TQMa95xxLA modules, designed to be soldered
> on a carrier board. MBa95xxCA is a carrier reference board / starter kit
> design.
>
> There is a common device tree for all variants with e.g. reduced
> CPU core / feature count.
>
> Enable the external accessible PCIe controllers as host,
> add clocking and reset GPIO. While at it, add hogs for GPIO
> lines from the M.2 slots until M.2 connector driver is available.
>
> Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Any feedback on this? Patch 1 is already picked in commit d44627c13049e
("dt-bindings: arm: add bindings for TQMa95xxLA")
Thank and best regards,
Alexander
> ---
> Changes in v2:
> * removed useless regulator
> * added USB PD source configuration
> * Removed unused uart-has-rtscts properties (unused by LPUART)
> * Fixed RTS/CTS pullups in pinctrl
> * Added thermalzone on module
>
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../freescale/imx95-tqma9596la-mba95xxca.dts | 947 ++++++++++++++++++
> .../boot/dts/freescale/imx95-tqma9596la.dtsi | 297 ++++++
> 3 files changed, 1245 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> create mode 100644 arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 2879d567dede0..df79e56771319 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -554,6 +554,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596la-mba95xxca.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-var-dart-sonata.dtb
>
> diff --git a/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> new file mode 100644
> index 0000000000000..f75580bb91e3e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> @@ -0,0 +1,947 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> +/*
> + * Copyright (c) 2024-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
> + * D-82229 Seefeld, Germany.
> + * Author: Alexander Stein
> + * Author: Markus Niebel
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/net/ti-dp83867.h>
> +#include <dt-bindings/pwm/pwm.h>
> +#include <dt-bindings/usb/pd.h>
> +#include "imx95-tqma9596la.dtsi"
> +
> +/ {
> + model = "TQ-Systems i.MX95 TQMa95xxLA on MBa95xxCA";
> + compatible = "tq,imx95-tqma9596la-mba95xxca", "tq,imx95-tqma9596la", "fsl,imx95";
> + chassis-type = "embedded";
> +
> + aliases {
> + ethernet0 = &enetc_port0;
> + ethernet1 = &enetc_port1;
> + ethernet2 = &enetc_port2;
> + gpio0 = &gpio1;
> + gpio1 = &gpio2;
> + gpio2 = &gpio3;
> + gpio3 = &gpio4;
> + i2c0 = &lpi2c1;
> + i2c1 = &lpi2c2;
> + i2c2 = &lpi2c3;
> + i2c3 = &lpi2c4;
> + i2c4 = &lpi2c5;
> + i2c5 = &lpi2c6;
> + i2c6 = &lpi2c7;
> + i2c7 = &lpi2c8;
> + mmc0 = &usdhc1;
> + mmc1 = &usdhc2;
> + rtc0 = &pcf85063;
> + rtc1 = &scmi_bbm;
> + serial0 = &lpuart1;
> + serial1 = &lpuart2;
> + serial2 = &lpuart3;
> + serial3 = &lpuart4;
> + serial4 = &lpuart5;
> + serial5 = &lpuart6;
> + serial6 = &lpuart7;
> + serial7 = &lpuart8;
> + spi0 = &flexspi1;
> + };
> +
> + chosen {
> + stdout-path = &lpuart1;
> + };
> +
> + backlight_lvds: backlight-lvds {
> + compatible = "pwm-backlight";
> + pwms = <&tpm5 2 100000 0>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <7>;
> + enable-gpios = <&expander2 6 GPIO_ACTIVE_HIGH>;
> + power-supply = <®_12v0>;
> + status = "disabled";
> + };
> +
> + clk_eth: clk-eth {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <156250000>;
> + };
> +
> + /*
> + * TODO: gate is disabled for now and GPIO are hogged
> + * ENETC driver switches the clock far too late for ENETC2 + SFP
> + */
> + clk_eth_gate: clk-eth-gate {
> + compatible = "gpio-gate-clock";
> + enable-gpios = <&expander2 0 GPIO_ACTIVE_HIGH>;
> + clocks = <&clk_eth>;
> + #clock-cells = <0>;
> + status = "disabled";
> + };
> +
> + clk_xtal25: clk-xtal25 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <25000000>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> +
> + button-b {
> + label = "BUTTON_B#";
> + linux,code = <BTN_1>;
> + gpios = <&expander1 0 GPIO_ACTIVE_LOW>;
> + wakeup-source;
> + };
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + led-1 {
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_STATUS;
> + gpios = <&expander2 13 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "default-on";
> + };
> +
> + led-2 {
> + color = <LED_COLOR_ID_AMBER>;
> + function = LED_FUNCTION_HEARTBEAT;
> + gpios = <&expander2 14 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +
> + iio-hwmon {
> + compatible = "iio-hwmon";
> + io-channels = <&adc1 0>, <&adc1 1>, <&adc1 2>, <&adc1 3>,
> + <&adc1 4>, <&adc1 5>, <&adc1 6>, <&adc1 7>;
> + };
> +
> + reg_v1v8_mb: regulator-v1v8-mb {
> + compatible = "regulator-fixed";
> + regulator-name = "V_1V8_MB";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + reg_v3v3_mb: regulator-v3v3-mb {
> + compatible = "regulator-fixed";
> + regulator-name = "V_3V3_MB";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + reg_3v3a_10g: regulator-3v3a-10g {
> + compatible = "regulator-fixed";
> + regulator-name = "3V3A_10G";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&expander2 15 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <2000>;
> + enable-active-high;
> + };
> +
> + reg_12v0: regulator-12v0 {
> + compatible = "regulator-fixed";
> + regulator-name = "12V0";
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + gpio = <&expander1 15 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + reg_pwm_fan: regulator-pwm-fan {
> + compatible = "regulator-fixed";
> + regulator-name = "FAN_PWR";
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + gpio = <&expander3 15 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + vin-supply = <®_12v0>;
> + };
> +
> + reg_lvds: regulator-lvds {
> + compatible = "regulator-fixed";
> + regulator-name = "LCD_PWR_EN";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&expander2 7 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + /* USB NC limitations, RM 162.1.2 VBUS limitations */
> + reg_vbus_usb3: regulator-vbus-usb3 {
> + compatible = "regulator-fixed";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-name = "USB3_VBUS";
> + gpio = <&gpio4 1 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + sfp_xfi: sfp-xfi {
> + compatible = "sff,sfp";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sfp>;
> + i2c-bus = <&lpi2c7>;
> + maximum-power-milliwatt = <2000>;
> + mod-def0-gpios = <&expander1 3 GPIO_ACTIVE_LOW>;
> + tx-fault-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
> + los-gpios = <&gpio2 31 GPIO_ACTIVE_HIGH>;
> + tx-disable-gpios = <&expander2 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + sound {
> + compatible = "fsl,imx-audio-tlv320aic32x4";
> + model = "tqm-tlv320aic32";
> + audio-codec = <&tlv320aic3x04>;
> + audio-cpu = <&sai3>;
> + audio-routing =
> + "IN3_L", "Mic Jack",
> + "Mic Jack", "Mic Bias",
> + "Headphone Jack", "HPL",
> + "Headphone Jack", "HPR",
> + "IN1_L", "Line In Jack",
> + "IN1_R", "Line In Jack",
> + "Line Out Jack", "LOL",
> + "Line Out Jack", "LOR";
> + };
> +};
> +
> +&adc1 {
> + status = "okay";
> +};
> +
> +&enetc_port0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enetc0>;
> + phy-handle = <ðphy0>;
> + phy-mode = "rgmii-id";
> + status = "okay";
> +};
> +
> +&enetc_port1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enetc1>;
> + phy-handle = <ðphy1>;
> + phy-mode = "rgmii-id";
> + status = "okay";
> +};
> +
> +/* No support for XFI yet */
> +&enetc_port2 {
> + sfp = <&sfp_xfi>;
> + phy-mode = "10gbase-r";
> + clocks = <&clk_eth>;
> + clock-names = "enet_ref_clk";
> + managed = "in-band-status";
> + status = "disabled";
> +};
> +
> +&flexcan1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan1>;
> + status = "okay";
> +};
> +
> +&flexcan2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan2>;
> + status = "okay";
> +};
> +
> +&lpi2c2 {
> + tlv320aic3x04: audio-codec@18 {
> + compatible = "ti,tlv320aic32x4";
> + reg = <0x18>;
> + clocks = <&scmi_clk IMX95_CLK_SAI3>;
> + clock-names = "mclk";
> + reset-gpios = <&expander1 14 GPIO_ACTIVE_LOW>;
> + iov-supply = <®_v3v3_mb>;
> + ldoin-supply = <®_v3v3_mb>;
> + };
> +
> + fan_controller: fan-controller@2f {
> + compatible = "microchip,emc2301", "microchip,emc2305";
> + reg = <0x2f>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #pwm-cells = <3>;
> + status = "okay";
> +
> + fan: fan@0 {
> + reg = <0x0>;
> + pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED 1>;
> + #cooling-cells = <2>;
> + fan-supply = <®_pwm_fan>;
> + };
> + };
> +
> + ptn5110: usb-typec@50 {
> + compatible = "nxp,ptn5110", "tcpci";
> + reg = <0x50>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_typec>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
> +
> + typec_con: connector {
> + compatible = "usb-c-connector";
> + label = "X9";
> + power-role = "source";
> + data-role = "dual";
> + source-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)>;
> + self-powered;
> +
> + port {
> + typec_con_hs: endpoint {
> + remote-endpoint = <&typec_hs>;
> + };
> + };
> + };
> + };
> +
> + sensor_mb: temperature-sensor@1e {
> + compatible = "nxp,se97b", "jedec,jc-42.4-temp";
> + reg = <0x1e>;
> + };
> +
> + eeprom_mb: eeprom@56 {
> + compatible = "nxp,se97b", "atmel,24c02";
> + reg = <0x56>;
> + pagesize = <16>;
> + vcc-supply = <®_v3v3_mb>;
> + };
> +
> + pcieclk: clock-generator@68 {
> + compatible = "renesas,9fgv0441";
> + reg = <0x68>;
> + clocks = <&clk_xtal25>;
> + #clock-cells = <1>;
> + };
> +
> + /* D39 IN/OUT 3V3 */
> + expander1: gpio@74 {
> + compatible = "ti,tca9539";
> + reg = <0x74>;
> + vcc-supply = <®_v3v3_mb>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_expander1>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
> +
> + gpio-line-names =
> + /* 00 */ "BUTTON_B#", "CAM0_SYNC_3V3",
> + /* 02 */ "CAM1_SYNC_3V3", "SFP_MOD_ABS",
> + /* 04 */ "DIG_IN1", "DIG_IN2",
> + /* 06 */ "DIG_IN3", "DIG_IN4",
> + /* 08 */ "DIG_OUT_1_2_STATE", "DIG_OUT_3_4_STATE",
> + /* 10 */ "DIG_OUT_1_EN", "DIG_OUT_2_EN",
> + /* 12 */ "DIG_OUT_3_EN", "DIG_OUT_4_EN",
> + /* 14 */ "AUDIO_RST#", "12V_EN";
> + };
> +
> + /* D40 OUT 3V3 */
> + expander2: gpio@75 {
> + compatible = "ti,tca9539";
> + reg = <0x75>;
> + vcc-supply = <®_3v3>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + gpio-line-names =
> + /* 00 */ "ETH10G_REFCLK_EN", "ETH10G_REFCLK_RST#",
> + /* 02 */ "SFP_TX_DIS", "USB3_RESET#",
> + /* 04 */ "USB2_RESET#", "LCD_RESET#",
> + /* 06 */ "LCD_BLT_EN", "LCD_PWR_EN",
> + /* 08 */ "M2_KEYE_PERST#", "M2_KEYE_WDISABLE1#",
> + /* 10 */ "M2_KEYE_WDISABLE2#", "M2_KEYB_PERST#",
> + /* 12 */ "M2_KEYB_WDISABLE1#", "USER_LED1",
> + /* 14 */ "USER_LED2", "3V3A_10G_EN";
> +
> + eth10g-refclk-en-hog {
> + gpio-hog;
> + gpios = <0 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "ETH10G_REFCLK_EN";
> + };
> +
> + eth10g-refclk-rst-hog {
> + gpio-hog;
> + gpios = <1 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "ETH10G_REFCLK_RST#";
> + };
> +
> + m2_keye_wdisable1_hog: m2-keye-wdisable1-hog {
> + gpio-hog;
> + gpios = <9 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYE_WDISABLE1#";
> + };
> +
> + m2_keye_wdisable2_hog: m2-keye-wdisable2-hog {
> + gpio-hog;
> + gpios = <10 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYE_WDISABLE2#";
> + };
> +
> + m2-keyb-wdisable1-hog {
> + gpio-hog;
> + gpios = <12 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYB_WDISABLE1#";
> + };
> + };
> +
> + /* D41 OUT 1V8 */
> + expander3: gpio@76 {
> + compatible = "ti,tca9539";
> + reg = <0x76>;
> + vcc-supply = <®_v1v8_mb>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + gpio-line-names =
> + /* 00 */ "ENET1_RESET#", "ENET2_RESET#",
> + /* 02 */ "M2_KEYE_SDIO_RST#", "M2_KEYE_DEV_WLAN_WAKE#",
> + /* 04 */ "M2_KEYE_DEV_BT_WAKE", "M2_KEYB_W_DISABLE2#",
> + /* 06 */ "M2_KEYB_RST#", "M2_KEYB_FULL_CARD_PWR_OFF#",
> + /* 08 */ "M2_KEYB_DPR", "CAM0_PWR#",
> + /* 10 */ "CAM1_PWR#", "CAM0_RST#",
> + /* 12 */ "CAM1_RST#", "CAM0_TRIGGER",
> + /* 14 */ "CAM1_TRIGGER", "FAN_PWR_EN";
> +
> + m2-keye-sdio-rst-hog {
> + gpio-hog;
> + gpios = <2 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYE_SDIO_RST#";
> + };
> +
> + m2-keye-dev_wlan-wake-hog {
> + gpio-hog;
> + gpios = <3 GPIO_ACTIVE_LOW>;
> + input;
> + line-name = "M2_KEYE_DEV_WLAN_WAKE#";
> + };
> +
> + m2-keye-dev_bt-wake-hog {
> + gpio-hog;
> + gpios = <4 GPIO_ACTIVE_LOW>;
> + input;
> + line-name = "M2_KEYE_DEV_BT_WAKE#";
> + };
> +
> + m2-keyb-wdisable2-hog {
> + gpio-hog;
> + gpios = <5 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYB_WDISABLE1#";
> + };
> +
> + m2-keyb-rst-hog {
> + gpio-hog;
> + gpios = <6 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYB_RST#";
> + };
> +
> + m2-keyb-full-card-pwr-off-hog {
> + gpio-hog;
> + gpios = <7 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYB_FULL_CARD_PWR_OFF#";
> + };
> + };
> +};
> +
> +/* X4 + XFP */
> +&lpi2c7 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default", "gpio";
> + pinctrl-0 = <&pinctrl_lpi2c7>;
> + pinctrl-1 = <&pinctrl_lpi2c7_recovery>;
> + scl-gpios = <&gpio2 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + sda-gpios = <&gpio2 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + status = "okay";
> +
> + /* TODO: 0x19: retimer */
> +
> + /* 0x50 / 0x51: SFP EEPROM */
> +};
> +
> +/* X4 */
> +&lpspi4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpspi4>;
> + cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>, <&gpio5 14 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> +&lpuart1 {
> + /* console */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart1>;
> + status = "okay";
> +};
> +
> +&lpuart2 {
> + /* SM */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart2>;
> + status = "reserved";
> +};
> +
> +&lpuart5 {
> + /* X16 M.2 KEY E */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart5>;
> + status = "okay";
> +};
> +
> +&lpuart7 {
> + /* X5 */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart7>;
> + status = "okay";
> +};
> +
> +&lpuart8 {
> + /* X15 */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart8>;
> + linux,rs485-enabled-at-boot-time;
> + status = "okay";
> +};
> +
> +&netc_blk_ctrl {
> + status = "okay";
> +};
> +
> +&netc_emdio {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_emdio>;
> + status = "okay";
> +
> + /* IRQ pin is AON GPIO, not usable */
> + ethphy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + reset-gpios = <&expander3 0 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <500000>;
> + reset-deassert-us = <50000>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> + ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> + ti,dp83867-rxctrl-strap-quirk;
> + ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
> + };
> +
> + ethphy1: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ethphy1>;
> + reset-gpios = <&expander3 1 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <500000>;
> + reset-deassert-us = <50000>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> + ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> + ti,dp83867-rxctrl-strap-quirk;
> + ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
> + };
> +};
> +
> +&netc_timer {
> + status = "okay";
> +};
> +
> +&netcmix_blk_ctrl {
> + status = "okay";
> +};
> +
> +/* X16 M2 / E-Key mPCIe */
> +&pcie0 {
> + pinctrl-0 = <&pinctrl_pcie0>;
> + pinctrl-names = "default";
> + clocks = <&scmi_clk IMX95_CLK_HSIO>,
> + <&scmi_clk IMX95_CLK_HSIOPLL>,
> + <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
> + <&scmi_clk IMX95_CLK_HSIOPCIEAUX>,
> + <&pcieclk 1>;
> + clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux", "ref";
> + reset-gpios = <&expander2 8 GPIO_ACTIVE_LOW>;
> + /* Not supported on REV.0100 */
> + /* supports-clkreq; */
> + status = "okay";
> +};
> +
> +/* X17 M2 / B-Key PCIe */
> +&pcie1 {
> + pinctrl-0 = <&pinctrl_pcie1>;
> + pinctrl-names = "default";
> + clocks = <&scmi_clk IMX95_CLK_HSIO>,
> + <&scmi_clk IMX95_CLK_HSIOPLL>,
> + <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
> + <&scmi_clk IMX95_CLK_HSIOPCIEAUX>,
> + <&pcieclk 0>;
> + clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux", "ref";
> + reset-gpios = <&expander2 11 GPIO_ACTIVE_LOW>;
> + /* Not supported on REV.0100 */
> + /* supports-clkreq; */
> + status = "okay";
> +};
> +
> +®_sdvmmc {
> + status = "okay";
> +};
> +
> +&sai3 {
> + #sound-dai-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sai3>;
> + assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
> + <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
> + <&scmi_clk IMX95_CLK_AUDIOPLL1>,
> + <&scmi_clk IMX95_CLK_AUDIOPLL2>,
> + <&scmi_clk IMX95_CLK_SAI3>;
> + assigned-clock-parents = <0>, <0>, <0>, <0>,
> + <&scmi_clk IMX95_CLK_AUDIOPLL1>;
> + assigned-clock-rates = <3932160000>,
> + <3612672000>, <393216000>,
> + <361267200>, <12288000>;
> + fsl,sai-mclk-direction-output;
> + status = "okay";
> +};
> +
> +&scmi_bbm {
> + linux,code = <KEY_POWER>;
> +};
> +
> +&thermal_zones {
> + a55-thermal {
> + trips {
> + cpu_active0: trip-active0 {
> + temperature = <40000>;
> + hysteresis = <5000>;
> + type = "active";
> + };
> +
> + cpu_active1: trip-active1 {
> + temperature = <48000>;
> + hysteresis = <3000>;
> + type = "active";
> + };
> +
> + cpu_active2: trip-active2 {
> + temperature = <60000>;
> + hysteresis = <10000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map1 {
> + trip = <&cpu_active0>;
> + cooling-device = <&fan 0 2>;
> + };
> +
> + map2 {
> + trip = <&cpu_active1>;
> + cooling-device = <&fan 3 5>;
> + };
> +
> + map3 {
> + trip = <&cpu_active2>;
> + cooling-device = <&fan 6 10>;
> + };
> + };
> + };
> +};
> +
> +&tpm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tpm3>;
> + status = "okay";
> +};
> +
> +&tpm5 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tpm5>;
> +};
> +
> +&usb2 {
> + dr_mode = "otg";
> + hnp-disable;
> + srp-disable;
> + adp-disable;
> + usb-role-switch;
> + disable-over-current;
> + samsung,picophy-pre-emp-curr-control = <3>;
> + samsung,picophy-dc-vol-level-adjust = <7>;
> + status = "okay";
> +
> + port {
> + typec_hs: endpoint {
> + remote-endpoint = <&typec_con_hs>;
> + };
> + };
> +};
> +
> +&usb3 {
> + status = "okay";
> +};
> +
> +&usb3_dwc3 {
> + dr_mode = "host";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + hub_2_0: hub@1 {
> + compatible = "usb451,8142";
> + reg = <1>;
> + peer-hub = <&hub_3_0>;
> + reset-gpios = <&expander2 3 GPIO_ACTIVE_LOW>;
> + vdd-supply = <®_v3v3_mb>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hub_2_1: hub@1 {
> + compatible = "usb424,2514";
> + reg = <1>;
> + reset-gpios = <&expander2 4 GPIO_ACTIVE_LOW>;
> + vdd-supply = <®_v3v3_mb>;
> + vdda-supply = <®_v3v3_mb>;
> + };
> + };
> +
> + hub_3_0: hub@2 {
> + compatible = "usb451,8140";
> + reg = <2>;
> + peer-hub = <&hub_2_0>;
> + reset-gpios = <&expander2 3 GPIO_ACTIVE_LOW>;
> + vdd-supply = <®_v3v3_mb>;
> + };
> +};
> +
> +&usb3_phy {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usb3>;
> + vbus-supply = <®_vbus_usb3>;
> + status = "okay";
> +};
> +
> +/* X7 µSD */
> +&usdhc2 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
> + vmmc-supply = <®_sdvmmc>;
> + cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> + no-mmc;
> + no-sdio;
> + disable-wp;
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&scmi_iomuxc {
> + pinctrl_enetc0: enetc0grp {
> + fsl,pins = <IMX95_PAD_ENET1_RD0__NETCMIX_TOP_ETH0_RGMII_RD0 0x1100>,
> + <IMX95_PAD_ENET1_RD1__NETCMIX_TOP_ETH0_RGMII_RD1 0x1100>,
> + <IMX95_PAD_ENET1_RD2__NETCMIX_TOP_ETH0_RGMII_RD2 0x1100>,
> + <IMX95_PAD_ENET1_RD3__NETCMIX_TOP_ETH0_RGMII_RD3 0x1100>,
> + <IMX95_PAD_ENET1_RXC__NETCMIX_TOP_ETH0_RGMII_RX_CLK 0x1100>,
> + <IMX95_PAD_ENET1_RX_CTL__NETCMIX_TOP_ETH0_RGMII_RX_CTL 0x1100>,
> + <IMX95_PAD_ENET1_TD0__NETCMIX_TOP_ETH0_RGMII_TD0 0x11e>,
> + <IMX95_PAD_ENET1_TD1__NETCMIX_TOP_ETH0_RGMII_TD1 0x11e>,
> + <IMX95_PAD_ENET1_TD2__NETCMIX_TOP_ETH0_RGMII_TD2 0x11e>,
> + <IMX95_PAD_ENET1_TD3__NETCMIX_TOP_ETH0_RGMII_TD3 0x11e>,
> + <IMX95_PAD_ENET1_TXC__NETCMIX_TOP_ETH0_RGMII_TX_CLK 0x11e>,
> + <IMX95_PAD_ENET1_TX_CTL__NETCMIX_TOP_ETH0_RGMII_TX_CTL 0x11e>;
> + };
> +
> + pinctrl_enetc1: enetc1grp {
> + fsl,pins = <IMX95_PAD_ENET2_RD0__NETCMIX_TOP_ETH1_RGMII_RD0 0x1100>,
> + <IMX95_PAD_ENET2_RD1__NETCMIX_TOP_ETH1_RGMII_RD1 0x1100>,
> + <IMX95_PAD_ENET2_RD2__NETCMIX_TOP_ETH1_RGMII_RD2 0x1100>,
> + <IMX95_PAD_ENET2_RD3__NETCMIX_TOP_ETH1_RGMII_RD3 0x1100>,
> + <IMX95_PAD_ENET2_RXC__NETCMIX_TOP_ETH1_RGMII_RX_CLK 0x1100>,
> + <IMX95_PAD_ENET2_RX_CTL__NETCMIX_TOP_ETH1_RGMII_RX_CTL 0x1100>,
> + <IMX95_PAD_ENET2_TD0__NETCMIX_TOP_ETH1_RGMII_TD0 0x11e>,
> + <IMX95_PAD_ENET2_TD1__NETCMIX_TOP_ETH1_RGMII_TD1 0x11e>,
> + <IMX95_PAD_ENET2_TD2__NETCMIX_TOP_ETH1_RGMII_TD2 0x11e>,
> + <IMX95_PAD_ENET2_TD3__NETCMIX_TOP_ETH1_RGMII_TD3 0x11e>,
> + <IMX95_PAD_ENET2_TXC__NETCMIX_TOP_ETH1_RGMII_TX_CLK 0x11e>,
> + <IMX95_PAD_ENET2_TX_CTL__NETCMIX_TOP_ETH1_RGMII_TX_CTL 0x11e>;
> + };
> +
> + pinctrl_ethphy0: ethphy0grp {
> + fsl,pins = <IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x1100>;
> + };
> +
> + pinctrl_ethphy1: ethphy1grp {
> + fsl,pins = <IMX95_PAD_ENET1_MDC__GPIO4_IO_BIT0 0x1100>;
> + };
> +
> + pinctrl_expander1: expander1grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO14__GPIO2_IO_BIT14 0x1100>;
> + };
> +
> + pinctrl_flexcan1: flexcan1grp {
> + fsl,pins = <IMX95_PAD_SAI1_TXC__AONMIX_TOP_CAN1_RX 0x1300>,
> + <IMX95_PAD_SAI1_TXD0__AONMIX_TOP_CAN1_TX 0x31e>;
> + };
> +
> + pinctrl_flexcan2: flexcan2grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO25__CAN2_TX 0x31e>,
> + <IMX95_PAD_GPIO_IO27__CAN2_RX 0x1300>;
> + };
> +
> + pinctrl_lpi2c7: lpi2c7grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO07__LPI2C7_SCL 0x40001b1e>,
> + <IMX95_PAD_GPIO_IO06__LPI2C7_SDA 0x40001b1e>;
> + };
> +
> + pinctrl_lpi2c7_recovery: lpi2c7recoverygrp {
> + fsl,pins = <IMX95_PAD_GPIO_IO07__GPIO2_IO_BIT7 0x40001b1e>,
> + <IMX95_PAD_GPIO_IO06__GPIO2_IO_BIT6 0x40001b1e>;
> + };
> +
> + pinctrl_lpspi4: lpspi4grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO37__LPSPI4_SCK 0x91e>,
> + <IMX95_PAD_GPIO_IO19__LPSPI5_SIN 0x191e>,
> + <IMX95_PAD_GPIO_IO36__LPSPI4_SOUT 0x91e>,
> + <IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14 0x91e>,
> + <IMX95_PAD_GPIO_IO33__GPIO5_IO_BIT13 0x91e>;
> + };
> +
> + pinctrl_lpuart1: lpuart1grp {
> + fsl,pins = <IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX 0x31e>,
> + <IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX 0x1300>;
> + };
> +
> + pinctrl_lpuart2: lpuart2grp {
> + fsl,pins = <IMX95_PAD_UART2_TXD__AONMIX_TOP_LPUART2_TX 0x31e>,
> + <IMX95_PAD_UART2_RXD__AONMIX_TOP_LPUART2_RX 0x1300>;
> + };
> +
> + pinctrl_lpuart5: lpuart5grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO00__LPUART5_TX 0x31e>,
> + <IMX95_PAD_GPIO_IO01__LPUART5_RX 0x1300>,
> + <IMX95_PAD_GPIO_IO02__LPUART5_CTS_B 0x1300>,
> + <IMX95_PAD_GPIO_IO03__LPUART5_RTS_B 0x31e>;
> + };
> +
> + pinctrl_lpuart7: lpuart7grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO08__LPUART7_TX 0x31e>,
> + <IMX95_PAD_GPIO_IO09__LPUART7_RX 0x1300>,
> + <IMX95_PAD_GPIO_IO10__LPUART7_CTS_B 0x1300>,
> + <IMX95_PAD_GPIO_IO11__LPUART7_RTS_B 0x31e>;
> + };
> +
> + pinctrl_lpuart8: lpuart8grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO12__LPUART8_TX 0x31e>,
> + <IMX95_PAD_GPIO_IO13__LPUART8_RX 0x1300>,
> + <IMX95_PAD_GPIO_IO15__LPUART8_RTS_B 0x31e>;
> + };
> +
> + pinctrl_emdio: emdiogrp {
> + fsl,pins = <IMX95_PAD_ENET2_MDC__NETCMIX_TOP_NETC_MDC 0x51e>,
> + <IMX95_PAD_ENET2_MDIO__NETCMIX_TOP_NETC_MDIO 0x51e>;
> + };
> +
> + pinctrl_pcie0: pcie0grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO32__HSIOMIX_TOP_PCIE1_CLKREQ_B 0x111e>;
> + };
> +
> + pinctrl_pcie1: pcie1grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x111e>;
> + };
> +
> + pinctrl_sai3: sai3grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO16__SAI3_TX_BCLK 0x51e>,
> + <IMX95_PAD_GPIO_IO17__SAI3_MCLK 0x51e>,
> + <IMX95_PAD_GPIO_IO20__SAI3_RX_DATA_BIT0 0x1300>,
> + <IMX95_PAD_GPIO_IO21__SAI3_TX_DATA_BIT0 0x51e>,
> + <IMX95_PAD_GPIO_IO26__SAI3_TX_SYNC 0x51e>;
> + };
> +
> + pinctrl_retimer: retirmergrp {
> + fsl,pins = <IMX95_PAD_GPIO_IO29__GPIO2_IO_BIT29 0x1100>;
> + };
> +
> + pinctrl_sfp: sfpgrp {
> + fsl,pins = <IMX95_PAD_GPIO_IO30__GPIO2_IO_BIT30 0x1100>,
> + <IMX95_PAD_GPIO_IO31__GPIO2_IO_BIT31 0x1100>;
> + };
> +
> + pinctrl_tpm3: tpm3grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO24__TPM3_CH3 0x51e>;
> + };
> +
> + pinctrl_tpm5: tpm5grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO18__TPM5_CH2 0x51e>;
> + };
> +
> + pinctrl_typec: typcegrp {
> + fsl,pins = <IMX95_PAD_GPIO_IO28__GPIO2_IO_BIT28 0x1100>;
> + };
> +
> + pinctrl_usb3: usb3grp {
> + fsl,pins = <IMX95_PAD_ENET1_MDIO__GPIO4_IO_BIT1 0x31e>;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
> + <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x51e>,
> + <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x31e>,
> + <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x131e>,
> + <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x131e>,
> + <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x131e>,
> + <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x131e>,
> + <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
> + };
> +
> + pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
> + fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
> + <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x58e>,
> + <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x38e>,
> + <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e>,
> + <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e>,
> + <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e>,
> + <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e>,
> + <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
> + };
> +
> + pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
> + fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
> + <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x5fe>,
> + <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x3fe>,
> + <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x13fe>,
> + <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x13fe>,
> + <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x13fe>,
> + <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x13fe>,
> + <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi b/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
> new file mode 100644
> index 0000000000000..cc572171bf253
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
> @@ -0,0 +1,297 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> +/*
> + * Copyright (c) 2024-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
> + * D-82229 Seefeld, Germany.
> + * Author: Alexander Stein
> + * Author: Markus Niebel
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include "imx95.dtsi"
> +
> +/ {
> + memory@80000000 {
> + device_type = "memory";
> + /*
> + * DRAM base addr, size : 2048 MiB DRAM
> + * should be corrected by bootloader
> + */
> + reg = <0 0x80000000 0 0x80000000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + linux_cma: linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + size = <0 0x28000000>;
> + alloc-ranges = <0 0x80000000 0 0x80000000>;
> + linux,cma-default;
> + };
> +
> + vpu_boot: vpu_boot@a0000000 {
> + reg = <0 0xa0000000 0 0x100000>;
> + no-map;
> + };
> + };
> +
> + reg_1v8: regulator-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "V_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + reg_3v3: regulator-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "V_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + reg_sdvmmc: regulator-sdvmmc {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sdvmmc>;
> + regulator-name = "SD_PWR_EN";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
> + off-on-delay-us = <12000>;
> + enable-active-high;
> + /* can be enabled by mainboard with SD-Card support */
> + status = "disabled";
> + };
> +};
> +
> +&adc1 {
> + vref-supply = <®_1v8>;
> +};
> +
> +&flexspi1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexspi1>;
> + status = "okay";
> +
> + flash0: flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <66000000>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + vcc-supply = <®_1v8>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> + };
> +};
> +
> +/* System Manager */
> +&gpio1 {
> + status = "reserved";
> +};
> +
> +/* System Manager */
> +&lpi2c1 {
> + status = "reserved";
> +};
> +
> +&lpi2c2 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpi2c2>;
> + status = "okay";
> +
> + pcf85063: rtc@51 {
> + compatible = "nxp,pcf85063a";
> + reg = <0x51>;
> + quartz-load-femtofarads = <7000>;
> + };
> +
> + m24c64: eeprom@54 {
> + compatible = "atmel,24c64";
> + reg = <0x54>;
> + pagesize = <32>;
> + vcc-supply = <®_3v3>;
> + };
> +
> + /* protectable identification memory (part of M24C64-D @54) */
> + eeprom@5c {
> + compatible = "atmel,24c64d-wl";
> + reg = <0x5c>;
> + pagesize = <32>;
> + vcc-supply = <®_3v3>;
> + };
> +
> + imu@6b {
> + compatible = "st,ism330dhcx";
> + reg = <0x6b>;
> + vdd-supply = <®_3v3>;
> + vddio-supply = <®_3v3>;
> + };
> +};
> +
> +&thermal_zones {
> + pf09-thermal {
> + polling-delay = <2000>;
> + polling-delay-passive = <250>;
> + thermal-sensors = <&scmi_sensor 2>;
> +
> + trips {
> + pf09_alert: trip0 {
> + hysteresis = <2000>;
> + temperature = <140000>;
> + type = "passive";
> + };
> +
> + pf09_crit: trip1 {
> + hysteresis = <2000>;
> + temperature = <155000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + pf53arm-thermal {
> + polling-delay = <2000>;
> + polling-delay-passive = <250>;
> + thermal-sensors = <&scmi_sensor 4>;
> +
> + cooling-maps {
> + map0 {
> + trip = <&pf5301_alert>;
> + cooling-device =
> + <&A55_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A55_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A55_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A55_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A55_4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A55_5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> +
> + trips {
> + pf5301_alert: trip0 {
> + hysteresis = <2000>;
> + temperature = <140000>;
> + type = "passive";
> + };
> +
> + pf5301_crit: trip1 {
> + hysteresis = <2000>;
> + temperature = <155000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + pf53soc-thermal {
> + polling-delay = <2000>;
> + polling-delay-passive = <250>;
> + thermal-sensors = <&scmi_sensor 3>;
> +
> + trips {
> + pf5302_alert: trip0 {
> + hysteresis = <2000>;
> + temperature = <140000>;
> + type = "passive";
> + };
> +
> + pf5302_crit: trip1 {
> + hysteresis = <2000>;
> + temperature = <155000>;
> + type = "critical";
> + };
> + };
> + };
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
> + bus-width = <8>;
> + non-removable;
> + no-sdio;
> + no-sd;
> + status = "okay";
> +};
> +
> +&wdog3 {
> + status = "okay";
> +};
> +
> +&scmi_iomuxc {
> + pinctrl_flexspi1: flexspi1grp {
> + fsl,pins = <IMX95_PAD_XSPI1_SS0_B__FLEXSPI1_A_SS0_B 0x19e>,
> + <IMX95_PAD_XSPI1_DATA0__FLEXSPI1_A_DATA_BIT0 0x19e>,
> + <IMX95_PAD_XSPI1_DATA1__FLEXSPI1_A_DATA_BIT1 0x19e>,
> + <IMX95_PAD_XSPI1_DATA2__FLEXSPI1_A_DATA_BIT2 0x19e>,
> + <IMX95_PAD_XSPI1_DATA3__FLEXSPI1_A_DATA_BIT3 0x19e>,
> + /* SION to allow clock loopback from pad */
> + <IMX95_PAD_XSPI1_SCLK__FLEXSPI1_A_SCLK 0x4000019e>,
> + <IMX95_PAD_XSPI1_DQS__FLEXSPI1_A_DQS 0x4000019e>;
> + };
> +
> + pinctrl_lpi2c2: lpi2c2grp {
> + fsl,pins = <IMX95_PAD_I2C2_SCL__AONMIX_TOP_LPI2C2_SCL 0x4000191e>,
> + <IMX95_PAD_I2C2_SDA__AONMIX_TOP_LPI2C2_SDA 0x4000191e>;
> + };
> +
> + pinctrl_sdvmmc: sdvmmcgrp {
> + fsl,pins = <IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7 0x11e>;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>,
> + <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>,
> + <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>,
> + <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>,
> + <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>,
> + <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>,
> + <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>,
> + <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>,
> + <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>,
> + <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>,
> + <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>;
> + };
> +
> + pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
> + fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>,
> + <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>,
> + <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>,
> + <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>,
> + <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>,
> + <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>,
> + <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>,
> + <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>,
> + <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>,
> + <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>,
> + <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>;
> + };
> +
> + pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
> + fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x15fe>,
> + <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x13fe>,
> + <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe>,
> + <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe>,
> + <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe>,
> + <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe>,
> + <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe>,
> + <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe>,
> + <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe>,
> + <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe>,
> + <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe>;
> + };
> +};
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ 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