Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v1] ARM: l2x0: Fix OF node reference leak in l2x0_of_init
From: Yuho Choi @ 2026-06-08  4:23 UTC (permalink / raw)
  To: Russell King; +Cc: Kuninori Morimoto, linux-arm-kernel, linux-kernel, Yuho Choi

l2x0_of_init() gets the cache controller node with
of_find_matching_node(), which returns the node with a reference held.
The node is only needed while parsing the cache controller resources and
properties, but the function returns without dropping that reference on
the resource/ioremap failure paths or after __l2c_init() returns.

Use a single exit path after the node lookup and put the node before
returning.

Fixes: 8c369264b6de ("ARM: 7009/1: l2x0: Add OF based initialization")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
 arch/arm/mm/cache-l2x0.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 470867160076..e20ac79dd500 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1767,17 +1767,22 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
 	u32 cache_id, old_aux;
 	u32 cache_level = 2;
 	bool nosync = false;
+	int ret;
 
 	np = of_find_matching_node(NULL, l2x0_ids);
 	if (!np)
 		return -ENODEV;
 
-	if (of_address_to_resource(np, 0, &res))
-		return -ENODEV;
+	if (of_address_to_resource(np, 0, &res)) {
+		ret = -ENODEV;
+		goto out_put_node;
+	}
 
 	l2x0_base = ioremap(res.start, resource_size(&res));
-	if (!l2x0_base)
-		return -ENOMEM;
+	if (!l2x0_base) {
+		ret = -ENOMEM;
+		goto out_put_node;
+	}
 
 	l2x0_saved_regs.phy_base = res.start;
 
@@ -1821,6 +1826,10 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
 	else
 		cache_id = readl_relaxed(l2x0_base + L2X0_CACHE_ID);
 
-	return __l2c_init(data, aux_val, aux_mask, cache_id, nosync);
+	ret = __l2c_init(data, aux_val, aux_mask, cache_id, nosync);
+
+out_put_node:
+	of_node_put(np);
+	return ret;
 }
 #endif
-- 
2.43.0



^ permalink raw reply related

* Re: [PATCH] arm_mpam: Fix MPAMCFG_MBW_PBM register setting
From: Gavin Shan @ 2026-06-08  4:46 UTC (permalink / raw)
  To: Fenghua Yu, Ben Horgan, James Morse, Reinette Chatre,
	Catalin Marinas, Shaopeng Tan, Jesse Chick
  Cc: linux-kernel, linux-arm-kernel, Matt Ochs
In-Reply-To: <20260607050925.252475-1-fenghuay@nvidia.com>

Hi Fenghua,

On 6/7/26 3:09 PM, Fenghua Yu wrote:
> MPAMCFG_MBW_PBM is written from cfg if cfg has the MBW partition feature.
> It is reset when cfg does not have the MBW partition feature.
> 
> But the register handling is reversed. This may cause an incorrect
> register setting. For example, during an MPAM reset, reset_cfg is
> empty (no MBW partition feature set), and cfg->mbw_pbm is 0. Instead of
> resetting MPAMCFG_MBW_PBM to all 1's, the current logic will set it to
> cfg->mbw_pbm, which is 0.
> 
> Fix the issue by swapping the if/else branches.
> 
> Fixes: a1cb6577f575 ("arm_mpam: Reset when feature configuration bit unset")
> Reported-by: Matt Ochs <mochs@nvidia.com>
> Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
> ---
>   drivers/resctrl/mpam_devices.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 

The fix itself looks reasonable to me, but two questions below.

Reviewed-by: Gavin Shan <gshan@redhat.com>

> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index 4b93e89c2678..d8b0383cee92 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -1570,9 +1570,9 @@ static void mpam_reprogram_ris_partid(struct mpam_msc_ris *ris, u16 partid,
>   
>   	if (mpam_has_feature(mpam_feat_mbw_part, rprops)) {
>   		if (mpam_has_feature(mpam_feat_mbw_part, cfg))
> -			mpam_reset_msc_bitmap(msc, MPAMCFG_MBW_PBM, rprops->mbw_pbm_bits);
> -		else
>   			mpam_write_partsel_reg(msc, MBW_PBM, cfg->mbw_pbm);
> +		else
> +			mpam_reset_msc_bitmap(msc, MPAMCFG_MBW_PBM, rprops->mbw_pbm_bits);
>   	}
>   
>   	if (mpam_has_feature(mpam_feat_mbw_min, rprops)) {

Which machine or system where mpam_feat_mbw_part is set on RIS? As I can
remember, this feature isn't available on grace-hopper.

Besides, I don't think this feature is well handled at present because
mpam_config::mbw_pbm is only 32-bits in length, which doesn't match with
the maximal length of the bit map (4096) as documented in the spec.

Thanks,
Gavin



^ permalink raw reply

* Re: [PATCH v2 1/9] mailbox: imx: Add a channel shutdown field
From: Peng Fan @ 2026-06-08  5:01 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
	linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
	Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260603-imx_mbox_rproc-v2-1-a0059dc3b69a@linutronix.de>

On Wed, Jun 03, 2026 at 03:05:04PM +0200, Sebastian Andrzej Siewior wrote:
>sashiko complained about possible teardown problem. The scenario
>
> CPU 0                              CPU 1
>  imx_mu_isr()                   imx_mu_shutdown()
>                                   imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));
>    imx_mu_specific_rx()
>      imx_mu_xcr_rmw(priv, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, 0), 0);
>                                   free_irq()
>
>The RX event remains enabled because in this short window the RX event
>was disabled in ->shutdown() while the interrupt was active and then
>enabled again by the ISR while ->shutdown waited in free_irq().
>
>This race requires timing and if happens can be problematic on shared
>handlers if the "removed" channel triggers an interrupt. In this case
>the irq-core will shutdown the interrupt with the "nobody cared"
>message.
>
>Introduce imx_mu_con_priv::shutdown to signal that the channel is
>shutting down. This flag is set with the lock held (by
>imx_mu_xcr_clr_shut()). The unmask side uses imx_mu_xcr_set_act() which
>only enables the event if the channel has not been shutdown and
>serialises on the same lock.
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Reviewed-by: Peng Fan <peng.fan@nxp.com>


^ permalink raw reply

* Re: [PATCH v2 3/9] mailbox: imx: use devm_of_platform_populate()
From: Peng Fan @ 2026-06-08  5:05 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
	linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
	Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260603-imx_mbox_rproc-v2-3-a0059dc3b69a@linutronix.de>

On Wed, Jun 03, 2026 at 03:05:06PM +0200, Sebastian Andrzej Siewior wrote:
>The driver uses of_platform_populate() but does not remove the added
>devices on removal. This can lead to "double devices" on module removal
>followed by adding the module again.
>
>Use devm_of_platform_populate() to remove the populated devices once the
>parent device is removed.
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Reviewed-by: Peng Fan <peng.fan@nxp.com>


^ permalink raw reply

* Re: [PATCH v2 2/9] mailbox: imx: Use devm_pm_runtime_enable()
From: Peng Fan @ 2026-06-08  5:06 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
	linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
	Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260603-imx_mbox_rproc-v2-2-a0059dc3b69a@linutronix.de>

On Wed, Jun 03, 2026 at 03:05:05PM +0200, Sebastian Andrzej Siewior wrote:
>sashiko complained about early usage of the device while probe isn't
>completed. This can be mitigated by delaying the pm_runtime_enable()
>into the removal path instead doing it early. This ensures that in an
>error case the device is removed (and imx_mu_shutdown()) before
>pm_runtime_disable() so we don't have to do this manually.
>
>For the order to work, lets move devm_mbox_controller_register() until
>after the pm-runtime part. So the reverse order will be mbox-controller
>removal followed by disabling pm runtime.
>
>Use devm_pm_runtime_enable(), remove manual pm_runtime_disable()
>invocations and move the pm_runtime handling in probe before
>devm_mbox_controller_register().
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Reviewed-by: Peng Fan <peng.fan@nxp.com>


^ permalink raw reply

* [PATCH] firmware: arm_scmi: simplify some allocations
From: Rosen Penev @ 2026-06-08  5:07 UTC (permalink / raw)
  To: arm-scmi
  Cc: Sudeep Holla, Cristian Marussi, Kees Cook, Gustavo A. R. Silva,
	linux-arm-kernel@lists.infradead.org (moderated list:SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE (SC...), linux-kernel@vger.kernel.org (open list), linux-hardening@vger.kernel.org (open list:KERNEL HARDENING (not covered by other areas):Keyword:\b__counted_by(_le|_be|_ptr)?\b)

Use flexible array members to combine allocations and remove kcalloc
usage.

Add __counted_by where appropriate for extra runtime analysis. Move
counting variable assignment after allocation before any potential array
access.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/firmware/arm_scmi/notify.c | 42 ++++++++++++------------------
 1 file changed, 16 insertions(+), 26 deletions(-)

diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c
index 40ec184eedae..45cbb3d2d684 100644
--- a/drivers/firmware/arm_scmi/notify.c
+++ b/drivers/firmware/arm_scmi/notify.c
@@ -209,11 +209,11 @@ struct scmi_registered_events_desc;
  * @init_work: A work item to perform final initializations of pending handlers
  * @notify_wq: A reference to the allocated Kernel cmwq
  * @pending_mtx: A mutex to protect @pending_events_handlers
+ * @pending_events_handlers: An hashtable containing all pending events'
+ *			     handlers descriptors
  * @registered_protocols: A statically allocated array containing pointers to
  *			  all the registered protocol-level specific information
  *			  related to events' handling
- * @pending_events_handlers: An hashtable containing all pending events'
- *			     handlers descriptors
  *
  * Each platform instance, represented by a handle, has its own instance of
  * the notification subsystem represented by this structure.
@@ -225,8 +225,8 @@ struct scmi_notify_instance {
 	struct workqueue_struct	*notify_wq;
 	/* lock to protect pending_events_handlers */
 	struct mutex		pending_mtx;
-	struct scmi_registered_events_desc	**registered_protocols;
 	DECLARE_HASHTABLE(pending_events_handlers, SCMI_PENDING_HASH_SZ);
+	struct scmi_registered_events_desc	*registered_protocols[];
 };

 /**
@@ -276,13 +276,13 @@ struct scmi_registered_event;
  * @eh_sz: Size of the pre-allocated buffer @eh
  * @in_flight: A reference to an in flight &struct scmi_registered_event
  * @num_events: Number of events in @registered_events
- * @registered_events: A dynamically allocated array holding all the registered
- *		       events' descriptors, whose fixed-size is determined at
- *		       compile time.
  * @registered_mtx: A mutex to protect @registered_events_handlers
  * @ph: SCMI protocol handle reference
  * @registered_events_handlers: An hashtable containing all events' handlers
  *				descriptors registered for this protocol
+ * @registered_events: A dynamically allocated array holding all the registered
+ *		       events' descriptors, whose fixed-size is determined at
+ *		       compile time.
  *
  * All protocols that register at least one event have their protocol-specific
  * information stored here, together with the embedded allocated events_queue.
@@ -302,11 +302,11 @@ struct scmi_registered_events_desc {
 	size_t				eh_sz;
 	void				*in_flight;
 	int				num_events;
-	struct scmi_registered_event	**registered_events;
 	/* mutex to protect registered_events_handlers */
 	struct mutex			registered_mtx;
 	const struct scmi_protocol_handle	*ph;
 	DECLARE_HASHTABLE(registered_events_handlers, SCMI_REGISTERED_HASH_SZ);
+	struct scmi_registered_event	*registered_events[] __counted_by(num_events);
 };

 /**
@@ -338,9 +338,9 @@ struct scmi_registered_event {
 	void		*report;
 	u32		num_sources;
 	bool		not_supported_by_platform;
-	refcount_t	*sources;
 	/* locking to serialize the access to sources */
 	struct mutex	sources_mtx;
+	refcount_t	sources[] __counted_by(num_sources);
 };

 /**
@@ -706,9 +706,12 @@ scmi_allocate_registered_events_desc(struct scmi_notify_instance *ni,
 	if (WARN_ON(ni->registered_protocols[proto_id]))
 		return ERR_PTR(-EINVAL);

-	pd = devm_kzalloc(ni->handle->dev, sizeof(*pd), GFP_KERNEL);
+	pd = devm_kzalloc(ni->handle->dev, struct_size(pd, registered_events, num_events),
+			GFP_KERNEL);
 	if (!pd)
 		return ERR_PTR(-ENOMEM);
+
+	pd->num_events = num_events;
 	pd->id = proto_id;
 	pd->ops = ops;
 	pd->ni = ni;
@@ -722,12 +725,6 @@ scmi_allocate_registered_events_desc(struct scmi_notify_instance *ni,
 		return ERR_PTR(-ENOMEM);
 	pd->eh_sz = eh_sz;

-	pd->registered_events = devm_kcalloc(ni->handle->dev, num_events,
-					     sizeof(char *), GFP_KERNEL);
-	if (!pd->registered_events)
-		return ERR_PTR(-ENOMEM);
-	pd->num_events = num_events;
-
 	/* Initialize per protocol handlers table */
 	mutex_init(&pd->registered_mtx);
 	hash_init(pd->registered_events_handlers);
@@ -800,14 +797,11 @@ int scmi_register_protocol_events(const struct scmi_handle *handle, u8 proto_id,
 				     GFP_KERNEL);
 		if (!r_evt)
 			return -ENOMEM;
+
+		r_evt->num_sources = num_sources;
 		r_evt->proto = pd;
 		r_evt->evt = evt;

-		r_evt->sources = devm_kcalloc(ni->handle->dev, num_sources,
-					      sizeof(refcount_t), GFP_KERNEL);
-		if (!r_evt->sources)
-			return -ENOMEM;
-		r_evt->num_sources = num_sources;
 		mutex_init(&r_evt->sources_mtx);

 		r_evt->report = devm_kzalloc(ni->handle->dev,
@@ -1666,18 +1660,14 @@ int scmi_notification_init(struct scmi_handle *handle)
 	if (!gid)
 		return -ENOMEM;

-	ni = devm_kzalloc(handle->dev, sizeof(*ni), GFP_KERNEL);
+	ni = devm_kzalloc(handle->dev, struct_size(ni, registered_protocols, SCMI_MAX_PROTO),
+			GFP_KERNEL);
 	if (!ni)
 		goto err;

 	ni->gid = gid;
 	ni->handle = handle;

-	ni->registered_protocols = devm_kcalloc(handle->dev, SCMI_MAX_PROTO,
-						sizeof(char *), GFP_KERNEL);
-	if (!ni->registered_protocols)
-		goto err;
-
 	ni->notify_wq = alloc_workqueue(dev_name(handle->dev),
 					WQ_UNBOUND | WQ_FREEZABLE | WQ_SYSFS,
 					0);
--
2.54.0



^ permalink raw reply related

* Re: [PATCH v2 4/9] mailbox: imx: Use channel index instead of zero in imx_mu_specific_rx()
From: Peng Fan @ 2026-06-08  5:11 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
	linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
	Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260603-imx_mbox_rproc-v2-4-a0059dc3b69a@linutronix.de>

On Wed, Jun 03, 2026 at 03:05:07PM +0200, Sebastian Andrzej Siewior wrote:
>imx_mu_specific_rx() masks channel 0 and unmasks it again at the end of
>the function. Given that at startup the channel index got unmasked it
>should do the right job.
>
>This here either unmasks the actual channel or another one but should
>have no impact given that it reverses its doing at the end.
>
>Use the channel index instead of zero.
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> drivers/mailbox/imx-mailbox.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>index 1dda1437b87f6..d1de07cc0ed62 100644
>--- a/drivers/mailbox/imx-mailbox.c
>+++ b/drivers/mailbox/imx-mailbox.c
>@@ -380,7 +380,7 @@ static int imx_mu_specific_rx(struct imx_mu_priv *priv, struct imx_mu_con_priv *
> 
> 	data = (u32 *)priv->msg;
> 
>-	imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(priv->dcfg->type, 0));
>+	imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));
> 	*data++ = imx_mu_read(priv, priv->dcfg->xRR);
> 
> 	if (priv->dcfg->type & IMX_MU_V2_S4) {
>@@ -407,7 +407,7 @@ static int imx_mu_specific_rx(struct imx_mu_priv *priv, struct imx_mu_con_priv *
> 		*data++ = imx_mu_read(priv, priv->dcfg->xRR + (i % num_rr) * 4);
> 	}
> 
>-	imx_mu_xcr_set_act(priv, cp, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, 0));
>+	imx_mu_xcr_set_act(priv, cp, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));
> 	mbox_chan_received_data(cp->chan, (void *)priv->msg);

For specific rx channel, whether it is i.MX8 SCU or i.MX ELE, actually there is
only 1 channel as of now, but it seems better to use cp->idx in case more
channels in future.

Reviewed-by: Peng Fan <peng.fan@nxp.com>

> 
> 	return 0;
>
>-- 
>2.53.0
>


^ permalink raw reply

* [PATCH] ARM: arch/arm/kernel/signal.c: resolve set-but-not-used warning
From: Ethan Nelson-Moore @ 2026-06-08  5:09 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel
  Cc: Ethan Nelson-Moore, Russell King, Arnd Bergmann,
	Thomas Weißschuh

If neither CONFIG_IWMMXT nor CONFIG_VFP are enabled (which is the case,
for example, in rpc_defconfig), the variable "aux" is set but not used,
which generates a warning during W=1 builds. Resolve this issue by only
defining the variable if it will be used.

Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
 arch/arm/kernel/signal.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index 7be9188d83d9..1d015b696a76 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -140,7 +140,9 @@ static int restore_vfp_context(char __user **auxp)
 static int restore_sigframe(struct pt_regs *regs, struct sigframe __user *sf)
 {
 	struct sigcontext context;
+#if defined(CONFIG_IWMMXT) || defined(CONFIG_VFP)
 	char __user *aux;
+#endif
 	sigset_t set;
 	int err;
 
@@ -171,6 +173,7 @@ static int restore_sigframe(struct pt_regs *regs, struct sigframe __user *sf)
 
 	err |= !valid_user_regs(regs);
 
+#if defined(CONFIG_IWMMXT) || defined(CONFIG_VFP)
 	aux = (char __user *) sf->uc.uc_regspace;
 #ifdef CONFIG_IWMMXT
 	if (err == 0)
@@ -180,6 +183,7 @@ static int restore_sigframe(struct pt_regs *regs, struct sigframe __user *sf)
 	if (err == 0)
 		err |= restore_vfp_context(&aux);
 #endif
+#endif /* defined(CONFIG_IWMMXT) || defined(CONFIG_VFP) */
 
 	return err;
 }
-- 
2.43.0



^ permalink raw reply related

* Re: [PATCH v2 5/9] mailbox: imx: Start splitting the IRQ handler in primary and threaded handler
From: Peng Fan @ 2026-06-08  5:14 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
	linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
	Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260603-imx_mbox_rproc-v2-5-a0059dc3b69a@linutronix.de>

On Wed, Jun 03, 2026 at 03:05:08PM +0200, Sebastian Andrzej Siewior wrote:
>Split the mailbox irq handling into a primary handler (imx_mu_isr()) and
>a threaded handler (imx_mu_isr_th()). The primary handler masks the
>interrupt event so the threaded handler can run without raising the
>interrupt again. The threaded handler can invoke the actuall callback in
>preemtible context.
>
>As a first step, prepare the logic and move TX handling part.
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Reviewed-by: Peng Fan <peng.fan@nxp.com>


^ permalink raw reply

* Re: [EXT] Re: [PATCH] arm64: dts: imx93-11x11-frdm: enable additional devices
From: Joseph Guo @ 2026-06-08  5:14 UTC (permalink / raw)
  To: Francesco Valla
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
	Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
	Daniel Baluta, devicetree, imx, linux-arm-kernel, linux-kernel,
	steven.yang
In-Reply-To: <_j4Ik3AsS5yfKb4Y7cSB1w@valla.it>

On 6/5/2026 7:36 PM, Francesco Valla wrote:
> Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button
> 
> 
> Hi Joseph,
> 
> On venerdì 5 giugno 2026 10:59:08 Ora legale dell’Europa centrale Joseph Guo
> wrote:
>> On Thu, Jan 15, 2026 at 06:11:34PM +0100, Francesco Valla wrote:
>>> Enable additional devices on the i.MX93 FRDM board:
>>>   - CAN port and associated transceiver
>>>   - Bluetooth portion of the IW612 chipset
>>>   - WiFi SDIO port
>>>   - user buttons
>>>
>>> The WiFi portion of the on-board IW612 chipset is still not supported
>>> upstream, but since SDIO is a discoverable bus it will be probed once it
>>> is.
>>>
>>> Signed-off-by: Francesco Valla <francesco@valla.it>
>>> ---
> [...]
> 
>>
>> Hi Francesco,
>>
>> Do you ever tried bluetooth feature? The bluetooth failed to scan with
>> 'device-wakeup-gpios' property.
>>
>> Regards,
>> Joseph
>>
> 
> Yes, Bluetooth was tested using bluetoothctl, I just briefly re-tested it
> with latest master branch (7.1.0-rc6).
> 
> Can you clarify what you mean with "The bluetooth failed to scan
> with 'device-wakeup-gpios' property."?
> 

Hi Francesco,

If 'device-wakeup-gpios' property is set. The bluetoothctl can work, but errors will show up if try to scan the bluetooth devices.

[bluetoothctl]> scan on
SetDiscoveryFilter success
Failed to start discovery: org.bluez.Error.InProgress
hci0 class of device changed: 0x000000
hci0 new_settings: bondable ssp br/edr le secure-conn cis-central cis-peripheral iso-broadcaster sync-receiver ll-privacy past-sender past-receiver
[CHG] Controller 20:BA:36:5C:B0:D8 Class: 0x00000000 (0)
[CHG] Controller 20:BA:36:5C:B0:D8 Powered: no
[CHG] Controller 20:BA:36:5C:B0:D8 Discovering: no
[CHG] Controller 20:BA:36:5C:B0:D8 PowerState: on
[bluetoothctl]> discoverable on
Failed to set discoverable on: org.bluez.Error.Failed

After remove the 'device-wakeup-gpios' node. The bluetooth can work normally.

> Thank you
> 
> Regards,
> 
> Francesco
> 
> 

-- 
Best Regards,
Joseph


^ permalink raw reply

* [PATCHv3] clk: kirkwood: use kzalloc_flex
From: Rosen Penev @ 2026-06-08  5:16 UTC (permalink / raw)
  To: linux-clk
  Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Michael Turquette, Stephen Boyd, Brian Masney, Kees Cook,
	Gustavo A. R. Silva,
	moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
	open list,
	open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be|_ptr)?b

Simplify allocation by using a flexible array member and kzalloc_flex to
combine allocations.

Add __counted_by for extra runtime analysis. Move counting variable
assignment to right after allocation. kzalloc_flex does this
automatically with GCC >= 15.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
---
 v3: change description slightly.
 v2: remove unused goto.
 drivers/clk/mvebu/kirkwood.c | 21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/clk/mvebu/kirkwood.c b/drivers/clk/mvebu/kirkwood.c
index ed061d82fb65..f4f62b241193 100644
--- a/drivers/clk/mvebu/kirkwood.c
+++ b/drivers/clk/mvebu/kirkwood.c
@@ -253,8 +253,8 @@ struct clk_muxing_soc_desc {

 struct clk_muxing_ctrl {
 	spinlock_t *lock;
-	struct clk **muxes;
 	int num_muxes;
+	struct clk *muxes[] __counted_by(num_muxes);
 };

 static const char *powersave_parents[] = {
@@ -297,21 +297,18 @@ static void __init kirkwood_clk_muxing_setup(struct device_node *np,
 	if (WARN_ON(!base))
 		return;

-	ctrl = kzalloc_obj(*ctrl);
-	if (WARN_ON(!ctrl))
-		goto ctrl_out;
-
-	/* lock must already be initialized */
-	ctrl->lock = &ctrl_gating_lock;
-
 	/* Count, allocate, and register clock muxes */
 	for (n = 0; desc[n].name;)
 		n++;

+	ctrl = kzalloc_flex(*ctrl, muxes, n);
+	if (WARN_ON(!ctrl))
+		goto ctrl_out;
+
 	ctrl->num_muxes = n;
-	ctrl->muxes = kzalloc_objs(struct clk *, ctrl->num_muxes);
-	if (WARN_ON(!ctrl->muxes))
-		goto muxes_out;
+
+	/* lock must already be initialized */
+	ctrl->lock = &ctrl_gating_lock;

 	for (n = 0; n < ctrl->num_muxes; n++) {
 		ctrl->muxes[n] = clk_register_mux(NULL, desc[n].name,
@@ -324,8 +321,6 @@ static void __init kirkwood_clk_muxing_setup(struct device_node *np,
 	of_clk_add_provider(np, clk_muxing_get_src, ctrl);

 	return;
-muxes_out:
-	kfree(ctrl);
 ctrl_out:
 	iounmap(base);
 }
--
2.54.0



^ permalink raw reply related

* [PATCHv2] dmaengine: st_fdma: simplify allocation
From: Rosen Penev @ 2026-06-08  5:18 UTC (permalink / raw)
  To: dmaengine
  Cc: Patrice Chotard, Vinod Koul, Frank Li, Kees Cook,
	Gustavo A. R. Silva, moderated list:ARM/STI ARCHITECTURE,
	open list,
	open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be|_ptr)?b

Use a flexible array member to combine kzalloc and kcalloc to a single
allocation.

Add __counted_by for extra runtime analysis. Assign counting variable
after allocation before any array accesses.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 v2: update description.
 drivers/dma/st_fdma.c | 27 ++++++++-------------------
 drivers/dma/st_fdma.h |  4 ++--
 2 files changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index d9547017f3bd..3ec0d6731b8d 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -710,16 +710,6 @@ static const struct of_device_id st_fdma_match[] = {
 };
 MODULE_DEVICE_TABLE(of, st_fdma_match);

-static int st_fdma_parse_dt(struct platform_device *pdev,
-			const struct st_fdma_driverdata *drvdata,
-			struct st_fdma_dev *fdev)
-{
-	snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
-		drvdata->name, drvdata->id);
-
-	return of_property_read_u32(pdev->dev.of_node, "dma-channels",
-				    &fdev->nr_channels);
-}
 #define FDMA_DMA_BUSWIDTHS	(BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
 				 BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
 				 BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
@@ -742,27 +732,26 @@ static int st_fdma_probe(struct platform_device *pdev)
 	struct st_fdma_dev *fdev;
 	struct device_node *np = pdev->dev.of_node;
 	const struct st_fdma_driverdata *drvdata;
+	u32 nr_channels;
 	int ret, i;

 	drvdata = device_get_match_data(&pdev->dev);

-	fdev = devm_kzalloc(&pdev->dev, sizeof(*fdev), GFP_KERNEL);
-	if (!fdev)
-		return -ENOMEM;
-
-	ret = st_fdma_parse_dt(pdev, drvdata, fdev);
+	ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", &nr_channels);
 	if (ret) {
 		dev_err(&pdev->dev, "unable to find platform data\n");
-		goto err;
+		return ret;
 	}

-	fdev->chans = devm_kcalloc(&pdev->dev, fdev->nr_channels,
-				   sizeof(struct st_fdma_chan), GFP_KERNEL);
-	if (!fdev->chans)
+	fdev = devm_kzalloc(&pdev->dev, struct_size(fdev, chans, nr_channels), GFP_KERNEL);
+	if (!fdev)
 		return -ENOMEM;

+	fdev->nr_channels = nr_channels;
 	fdev->dev = &pdev->dev;
 	fdev->drvdata = drvdata;
+	snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf", drvdata->name, drvdata->id);
+
 	platform_set_drvdata(pdev, fdev);

 	fdev->irq = platform_get_irq(pdev, 0);
diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
index f1e746f7bc7d..27ded555879f 100644
--- a/drivers/dma/st_fdma.h
+++ b/drivers/dma/st_fdma.h
@@ -136,13 +136,13 @@ struct st_fdma_dev {

 	int irq;

-	struct st_fdma_chan *chans;
-
 	spinlock_t dreq_lock;
 	unsigned long dreq_mask;

 	u32 nr_channels;
 	char fw_name[FW_NAME_SIZE];
+
+	struct st_fdma_chan chans[] __counted_by(nr_channels);
 };

 /* Peripheral Registers*/
--
2.54.0



^ permalink raw reply related

* [PATCH] scsi: acornscsi: resolve set-but-not-used variable warning
From: Ethan Nelson-Moore @ 2026-06-08  5:19 UTC (permalink / raw)
  To: linux-arm-kernel, linux-scsi
  Cc: Ethan Nelson-Moore, Russell King, James E.J. Bottomley,
	Martin K. Petersen

The variable "p" in the acornscsi_info() function is set but not used,
which causes a warning with W=1 builds. Remove it to resolve this issue.

Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
 drivers/scsi/arm/acornscsi.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/arm/acornscsi.c b/drivers/scsi/arm/acornscsi.c
index 79d7d7336b6a..ebf09b787dfd 100644
--- a/drivers/scsi/arm/acornscsi.c
+++ b/drivers/scsi/arm/acornscsi.c
@@ -2681,11 +2681,9 @@ static int acornscsi_host_reset(struct scsi_cmnd *SCpnt)
  */
 static const char *acornscsi_info(struct Scsi_Host *host)
 {
-    static char string[100], *p;
+    static char string[100];
 
-    p = string;
-    
-    p += sprintf(string, "%s at port %08lX irq %d v%d.%d.%d"
+    sprintf(string, "%s at port %08lX irq %d v%d.%d.%d"
 #ifdef CONFIG_SCSI_ACORNSCSI_SYNC
     " SYNC"
 #endif
-- 
2.43.0



^ permalink raw reply related

* Re: [PATCH] ARM: arch/arm/kernel/signal.c: resolve set-but-not-used warning
From: Arnd Bergmann @ 2026-06-08  5:29 UTC (permalink / raw)
  To: Ethan Nelson-Moore, linux-arm-kernel, linux-kernel
  Cc: Russell King, Thomas Weißschuh
In-Reply-To: <20260608050926.88446-1-enelsonmoore@gmail.com>

On Mon, Jun 8, 2026, at 07:09, Ethan Nelson-Moore wrote:
> If neither CONFIG_IWMMXT nor CONFIG_VFP are enabled (which is the case,
> for example, in rpc_defconfig), the variable "aux" is set but not used,
> which generates a warning during W=1 builds. Resolve this issue by only
> defining the variable if it will be used.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>


^ permalink raw reply

* Re: [PATCH v2 5/9] mailbox: imx: Start splitting the IRQ handler in primary and threaded handler
From: Peng Fan @ 2026-06-08  5:32 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
	linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
	Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260603-imx_mbox_rproc-v2-5-a0059dc3b69a@linutronix.de>

On Wed, Jun 03, 2026 at 03:05:08PM +0200, Sebastian Andrzej Siewior wrote:
>Split the mailbox irq handling into a primary handler (imx_mu_isr()) and
>a threaded handler (imx_mu_isr_th()). The primary handler masks the
>interrupt event so the threaded handler can run without raising the
>interrupt again. The threaded handler can invoke the actuall callback in
>preemtible context.
>
>As a first step, prepare the logic and move TX handling part.
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> drivers/mailbox/imx-mailbox.c | 33 ++++++++++++++++++++++++++++++---
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>index d1de07cc0ed62..006aa76b74b62 100644
>--- a/drivers/mailbox/imx-mailbox.c
>+++ b/drivers/mailbox/imx-mailbox.c
>@@ -81,6 +81,7 @@ struct imx_mu_con_priv {
> 	struct mbox_chan	*chan;
> 	struct work_struct 	txdb_work;
> 	bool			shutdown;
>+	bool			pending;
> };
> 
> struct imx_mu_priv {
>@@ -539,11 +540,35 @@ static void imx_mu_txdb_work(struct work_struct *t)
> 	mbox_chan_txdone(cp->chan, 0);
> }
> 
>+static irqreturn_t imx_mu_isr_th(int irq, void *p)
>+{
>+	struct mbox_chan *chan = p;
>+	struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
>+	struct imx_mu_con_priv *cp = chan->con_priv;
>+
>+	if (!cp->pending)
>+		return IRQ_NONE;

Is there a chance that cp->pending could be false here?

Regards
Peng

>+
>+	switch (cp->type) {
>+	case IMX_MU_TYPE_TX:
>+		cp->pending = false;
>+		mbox_chan_txdone(chan, 0);
>+		break;
>+
>+	default:
>+		dev_warn_ratelimited(priv->dev, "Unhandled channel type %d\n",
>+				     cp->type);
>+		return IRQ_NONE;
>+	}
>+	return IRQ_HANDLED;
>+}
>+
> static irqreturn_t imx_mu_isr(int irq, void *p)
> {
> 	struct mbox_chan *chan = p;
> 	struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> 	struct imx_mu_con_priv *cp = chan->con_priv;
>+	irqreturn_t ret = IRQ_HANDLED;
> 	u32 val, ctrl;
> 
> 	switch (cp->type) {
>@@ -579,7 +604,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
> 	if ((val == IMX_MU_xSR_TEn(priv->dcfg->type, cp->idx)) &&
> 	    (cp->type == IMX_MU_TYPE_TX)) {
> 		imx_mu_xcr_rmw(priv, IMX_MU_TCR, 0, IMX_MU_xCR_TIEn(priv->dcfg->type, cp->idx));
>-		mbox_chan_txdone(chan, 0);
>+		cp->pending = true;
>+		ret = IRQ_WAKE_THREAD;
> 	} else if ((val == IMX_MU_xSR_RFn(priv->dcfg->type, cp->idx)) &&
> 		   (cp->type == IMX_MU_TYPE_RX)) {
> 		priv->dcfg->rx(priv, cp);
>@@ -594,7 +620,7 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
> 	if (priv->suspend)
> 		pm_system_wakeup();
> 
>-	return IRQ_HANDLED;
>+	return ret;
> }
> 
> static int imx_mu_send_data(struct mbox_chan *chan, void *data)
>@@ -629,7 +655,8 @@ static int imx_mu_startup(struct mbox_chan *chan)
> 	if (!(priv->dcfg->type & IMX_MU_V2_IRQ))
> 		irq_flag |= IRQF_SHARED;
> 
>-	ret = request_irq(priv->irq[cp->type], imx_mu_isr, irq_flag, cp->irq_desc, chan);
>+	ret = request_threaded_irq(priv->irq[cp->type], imx_mu_isr, imx_mu_isr_th,
>+				   irq_flag, cp->irq_desc, chan);
> 	if (ret) {
> 		dev_err(priv->dev, "Unable to acquire IRQ %d\n", priv->irq[cp->type]);
> 		return ret;
>
>-- 
>2.53.0
>


^ permalink raw reply

* [PATCH] phy: apple: atc: remove stale kernel-doc for removed struct members
From: Rosen Penev @ 2026-06-08  5:35 UTC (permalink / raw)
  To: linux-phy
  Cc: Sven Peter, Janne Grunau, Neal Gompa, Vinod Koul, Neil Armstrong,
	open list:ARM/APPLE MACHINE SUPPORT,
	moderated list:ARM/APPLE MACHINE SUPPORT, open list

The @sw and @mux members were removed from struct apple_atcphy but their kernel-doc entries remained, causing kernel-doc warnings.

Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/phy/apple/atc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/phy/apple/atc.c b/drivers/phy/apple/atc.c
index 4156fabad742..f09305dd76d1 100644
--- a/drivers/phy/apple/atc.c
+++ b/drivers/phy/apple/atc.c
@@ -585,8 +585,6 @@ struct atcphy_mode_configuration {
  * @phys.dp: DisplayPort PHY instance
  * @phy_provider: PHY provider instance
  * @rcdev: Reset controller device
- * @sw: Type-C switch instance
- * @mux: Type-C mux instance
  * @lock: Mutex for synchronizing register access across PHY, Type-C switch/mux and reset controller
  */
 struct apple_atcphy {
-- 
2.54.0



^ permalink raw reply related

* Re: [PATCH v2 6/9] mailbox: imx: Move the RX part of the mailbox into the threaded handler
From: Peng Fan @ 2026-06-08  5:48 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
	linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
	Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260603-imx_mbox_rproc-v2-6-a0059dc3b69a@linutronix.de>

On Wed, Jun 03, 2026 at 03:05:09PM +0200, Sebastian Andrzej Siewior wrote:
>Move RX callback handling into the threaded handler. This is similar to
>the TX side except that we explicitly mask the source interrupt in the
>primary handler and unmask it in the threaded handler again after
>success. This was done automatically in the TX part.
>
>The masking/ unmasking can be removed from imx_mu_specific_rx() since it
>already happens in the primary/ threaded handler before invoking the
>channel specific callback.
>
>Move RX channel handling into threaded handler.
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Reviewed-by: Peng Fan <peng.fan@nxp.com>


^ permalink raw reply

* Re: [PATCH v2 7/9] mailbox: imx: Move the RXDB part of the mailbox into the threaded handler
From: Peng Fan @ 2026-06-08  5:48 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
	linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
	Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260603-imx_mbox_rproc-v2-7-a0059dc3b69a@linutronix.de>

On Wed, Jun 03, 2026 at 03:05:10PM +0200, Sebastian Andrzej Siewior wrote:
>Move RXDB callback handling into the threaded handler. This similar to
>the RX side except that we unmask it unconditionally in threaded
>handler.
>
>Move RXDB callback handling into the threaded handler.
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Reviewed-by: Peng Fan <peng.fan@nxp.com>


^ permalink raw reply

* Re: [PATCH v2 8/9] mailbox: imx: Don't force-thread the primary handler
From: Peng Fan @ 2026-06-08  5:50 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
	linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
	Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260603-imx_mbox_rproc-v2-8-a0059dc3b69a@linutronix.de>

On Wed, Jun 03, 2026 at 03:05:11PM +0200, Sebastian Andrzej Siewior wrote:
>The primary interrupt handler (imx_mu_isr()) no longer invokes any
>callbacks it only masks the interrupt source and returns. In a
>forced-threaded environment the IRQ-core will force-thread the primary
>handler which can be avoided.
>
>The primary handler uses a spinlock_t to protect the RMW operation in
>imx_mu_xcr_rmw() - nothing that may introduce long latencies.
>
>The lock can be turned into a raw_spinlock_t and then the primary
>handler can run in hardirq context even on PREEMPT_RT skipping one
>thread.
>
>Make struct imx_mu_priv::xcr_lock a raw_spinlock_t and skip
>force-threading the primrary handler by marking it IRQF_NO_THREAD.
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Reviewed-by: Peng Fan <peng.fan@nxp.com>


^ permalink raw reply

* Re: [PATCH v2 9/9] remoteproc: imx_rproc: Invoke the callback directly
From: Peng Fan @ 2026-06-08  5:52 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: linux-kernel, imx, linux-arm-kernel, linux-remoteproc,
	linux-rt-devel, Bjorn Andersson, Clark Williams, Fabio Estevam,
	Frank Li, Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
	Sascha Hauer, Steven Rostedt
In-Reply-To: <20260603-imx_mbox_rproc-v2-9-a0059dc3b69a@linutronix.de>

On Wed, Jun 03, 2026 at 03:05:12PM +0200, Sebastian Andrzej Siewior wrote:
>The imx-mailbox driver moved the callback invocation into the threaded
>IRQ handler. This means the callback is invoked in preemptible context
>and there is no need to schedule the kworker for the
>imx_rproc_notified_idr_cb() invocation.
>
>This was tested with the rpmsg-tty driver on imx93.
>
>Remove the workqueue handling and invoke the imx_rproc_notified_idr_cb()
>callback directly.
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Reviewed-by: Peng Fan <peng.fan@nxp.com>


^ permalink raw reply

* Re: [PATCH] ARM: arch/arm/kernel/signal.c: resolve set-but-not-used warning
From: Baruch Siach @ 2026-06-08  5:36 UTC (permalink / raw)
  To: Ethan Nelson-Moore
  Cc: linux-arm-kernel, linux-kernel, Russell King, Arnd Bergmann,
	Thomas Weißschuh
In-Reply-To: <20260608050926.88446-1-enelsonmoore@gmail.com>

Hi Ethan,

On Sun, Jun 07 2026, Ethan Nelson-Moore wrote:

> If neither CONFIG_IWMMXT nor CONFIG_VFP are enabled (which is the case,
> for example, in rpc_defconfig), the variable "aux" is set but not used,
> which generates a warning during W=1 builds. Resolve this issue by only
> defining the variable if it will be used.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
>  arch/arm/kernel/signal.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
> index 7be9188d83d9..1d015b696a76 100644
> --- a/arch/arm/kernel/signal.c
> +++ b/arch/arm/kernel/signal.c
> @@ -140,7 +140,9 @@ static int restore_vfp_context(char __user **auxp)
>  static int restore_sigframe(struct pt_regs *regs, struct sigframe __user *sf)
>  {
>  	struct sigcontext context;
> +#if defined(CONFIG_IWMMXT) || defined(CONFIG_VFP)
>  	char __user *aux;

__maybe_unused is a common attribute marking local variables that are not
always used. I find it nicer than another layer of #ifdef.

baruch

> +#endif
>  	sigset_t set;
>  	int err;
>  
> @@ -171,6 +173,7 @@ static int restore_sigframe(struct pt_regs *regs, struct sigframe __user *sf)
>  
>  	err |= !valid_user_regs(regs);
>  
> +#if defined(CONFIG_IWMMXT) || defined(CONFIG_VFP)
>  	aux = (char __user *) sf->uc.uc_regspace;
>  #ifdef CONFIG_IWMMXT
>  	if (err == 0)
> @@ -180,6 +183,7 @@ static int restore_sigframe(struct pt_regs *regs, struct sigframe __user *sf)
>  	if (err == 0)
>  		err |= restore_vfp_context(&aux);
>  #endif
> +#endif /* defined(CONFIG_IWMMXT) || defined(CONFIG_VFP) */
>  
>  	return err;
>  }

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -


^ permalink raw reply

* Re: [PATCH v2] dmaengine: imx-sdma: Refine spba bus searching in probe
From: Vinod Koul @ 2026-06-08  5:55 UTC (permalink / raw)
  To: Frank.Li, s.hauer, kernel, festevam, dmaengine, imx,
	linux-arm-kernel, linux-kernel, Shengjiu Wang
In-Reply-To: <20260407032755.2758049-1-shengjiu.wang@nxp.com>


On Tue, 07 Apr 2026 11:27:55 +0800, Shengjiu Wang wrote:
> There are multi spba-busses for i.MX8M* platforms, if only search for
> the first spba-bus in DT, the found spba-bus may not the real bus of
> audio devices, which cause issue for sdma p2p case, as the sdma p2p
> script presently does not deal with the transactions involving two devices
> connected to the AIPS bus.
> 
> Search the SDMA parent node first, which should be the AIPS bus, then
> search the child node whose compatible string is spba-bus under that AIPS
> bus for the above multi spba-busses case.
> 
> [...]

Applied, thanks!

[1/1] dmaengine: imx-sdma: Refine spba bus searching in probe
      commit: d52d42e2e5d9f13166e81ac837ebb023d1306e61

Best regards,
-- 
~Vinod




^ permalink raw reply

* [PATCH v7 0/2] arm64: dts: rockchip: add Vicharak Axon board support
From: Hrushiraj Gandhi @ 2026-06-08  6:09 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: Krzysztof Kozlowski, Rob Herring, Conor Dooley, devicetree,
	linux-arm-kernel, linux-rockchip, linux-kernel, Hrushiraj Gandhi

This series adds initial device tree support for the Vicharak Axon
single-board computer, which is based on the Rockchip RK3588 SoC.

The Vicharak Axon is a feature-rich SBC targeting developer and embedded
use cases. It ships with:

  - Rockchip RK3588 (4x Cortex-A76 + 4x Cortex-A55)
  - RK806 PMIC providing all SoC power domains
  - eMMC 5.1 (on-board) and microSD slot
  - Gigabit Ethernet via RGMII (RTL8211F)
  - Dual HDMI 2.1 output and one HDMI 2.0 input (receiver)
  - PCIe 3.0 x4 and two PCIe 2.0 slots
  - SATA 3.0
  - USB 2.0 host ports (EHCI/OHCI)
  - NXP PCA9554 I/O expander for status LEDs
  - Haoyu HYM8563 RTC

Changes since v6:
- Dropped vendor-prefixes patch; the vicharak prefix was already
  submitted upstream by another contributor.
- Added Acked-by from Krzysztof Kozlowski to the binding patch.
- Removed redundant status = okay from newly-defined nodes (leds,
  hym8563, pca9554) as noted by Krzysztof Kozlowski.
- Removed stale mmc2 = &sdio alias (sdio was removed in v4).
- Removed leftover #include <dt-bindings/usb/pd.h> (TypeC removed).
- Removed unused fixed regulators: pcie20_avdd0v85, pcie20_avdd1v8,
  pcie30_avdd0v75, pcie30_avdd1v8, sata_vcc_5v0, vcc0_4v0/vcc4v0_sys.

Changes since v5:
- Enabled i2s5_8ch and i2s6_8ch CPU DAIs to resolve probe deferral
  for hdmi0_sound and hdmi1_sound.

Changes since v4:
- Re-enabled combphy2_psu, required PHY for pcie2x1l1.
- Fixed alphabetical sorting of rk3588-vicharak-axon.dtb in Makefile.

Changes since v3:
- Removed sdio_pwrseq and wireless-wlan pinctrl nodes (Wi-Fi removed).
- Removed unused u2phy0, u2phy0_otg, u2phy1, u2phy1_otg nodes.

Changes since v2:
- Split the dt-bindings patch into separate patches as requested.
- Removed invalid enable-gpios from HDMI nodes.
- Fixed copy-paste error in rk806_dvs1_null pinctrl node.

Changes since v1:
- Renamed rk3588-axon.dts to rk3588-vicharak-axon.dts.
- Added binding patch for board (rockchip.yaml).
- Renamed regulator nodes to the standard regulator-name pattern.
- Removed mem-supply properties from cpu nodes.
- Fixed pcie20_avdd0v85 vin-supply mismatch.
- Removed obsolete regulator-compatible property.
- Removed invalid regulator-init-microvolt property.
- Removed dangling enable-active-high from fixed regulators.
- Cleaned up unneeded i2c3 / es8388 nodes.
- Added missing vpcie3v3-supply properties to PCIe nodes.

Hrushiraj Gandhi (2):
  dt-bindings: arm: rockchip: add Vicharak Axon board
  arm64: dts: rockchip: add Vicharak Axon board

 .../devicetree/bindings/arm/rockchip.yaml     |   5 +
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../dts/rockchip/rk3588-vicharak-axon.dts     | 926 ++++++++++++++++++
 3 files changed, 932 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-axon.dts

-- 
2.47.3



^ permalink raw reply

* [PATCH v7 1/2] dt-bindings: arm: rockchip: add Vicharak Axon board
From: Hrushiraj Gandhi @ 2026-06-08  6:09 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: Krzysztof Kozlowski, Rob Herring, Conor Dooley, devicetree,
	linux-arm-kernel, linux-rockchip, linux-kernel, Hrushiraj Gandhi,
	Krzysztof Kozlowski
In-Reply-To: <20260608060940.52549-1-hrushirajg23@gmail.com>

Add the device tree binding for the Vicharak Axon single-board
computer based on the Rockchip RK3588 SoC.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1a9dde18626d..b023d4cc9842 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1306,6 +1306,11 @@ properties:
           - const: turing,rk1
           - const: rockchip,rk3588
 
+      - description: Vicharak Axon
+        items:
+          - const: vicharak,axon
+          - const: rockchip,rk3588
+
       - description: WolfVision PF5 mainboard
         items:
           - const: wolfvision,rk3568-pf5
-- 
2.47.3



^ permalink raw reply related

* [PATCH v7 2/2] arm64: dts: rockchip: add Vicharak Axon board
From: Hrushiraj Gandhi @ 2026-06-08  6:09 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: Krzysztof Kozlowski, Rob Herring, Conor Dooley, devicetree,
	linux-arm-kernel, linux-rockchip, linux-kernel, Hrushiraj Gandhi
In-Reply-To: <20260608060940.52549-1-hrushirajg23@gmail.com>

Add initial support for the Vicharak Axon single-board computer based on
the Rockchip RK3588 SoC.

The board supports:

- eMMC storage
- microSD card
- Gigabit Ethernet
- HDMI output (dual HDMI)
- HDMI input
- USB 2.0 host ports
- PCIe 2.0 slots
- PCIe 3.0 x4 slot
- SATA
- RTC
- Status LEDs

The board uses an RK806 PMIC and provides the regulators required by
the RK3588 SoC.

Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
---
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../dts/rockchip/rk3588-vicharak-axon.dts     | 926 ++++++++++++++++++
 2 files changed, 927 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-vicharak-axon.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index cb55c6b70d0e..b10c6d80c5cc 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -211,6 +211,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou-video-demo.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-toybrick-x0.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-turing-rk1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-vicharak-axon.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-coolpi-4b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-evb1-v10.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-gameforce-ace.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-vicharak-axon.dts b/arch/arm64/boot/dts/rockchip/rk3588-vicharak-axon.dts
new file mode 100644
index 000000000000..b4e33922cfba
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-vicharak-axon.dts
@@ -0,0 +1,926 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3588.dtsi"
+
+/ {
+	model = "Vicharak Axon";
+	compatible = "vicharak,axon", "rockchip,rk3588";
+
+	aliases {
+		mmc0 = &sdmmc;
+		mmc1 = &sdhci;
+		serial2 = &uart2;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	hdmi0-con {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi0_con_in: endpoint {
+				remote-endpoint = <&hdmi0_out_con>;
+			};
+		};
+	};
+
+	hdmi1-con {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi1_con_in: endpoint {
+				remote-endpoint = <&hdmi1_out_con>;
+			};
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		power_led: power-led {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&pca9554 0 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		status_led: status-led {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&pca9554 1 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "none";
+		};
+	};
+
+	vcc12v_dcin: regulator-vcc12v-dcin {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc3v3_io_expander: regulator-vcc3v3-io-expander {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_io_expander";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
+	vcc3v3_pcie20_sata30: regulator-vcc3v3-pcie20-sata30 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_pcie20_sata30";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_pcie30: regulator-vcc3v3-pcie30 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_pcie30";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_HIGH>;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_sys: regulator-vcc5v0-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usb20_host: regulator-vcc5v0-usb20-host {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb20_host";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+};
+
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy1_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&gmac1 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-rxid";
+	phy-supply = <&vcc_3v3_s3>;
+	pinctrl-0 = <&gmac1_rgmii_bus
+				&gmac1_rgmii_clk
+				&gmac1_rx_bus2
+				&gmac1_tx_bus2
+				&gmac1_miim>;
+	pinctrl-names = "default";
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 20000 100000>;
+	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	rx_delay = <0x00>;
+	tx_delay = <0x43>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu_s0>;
+	status = "okay";
+};
+
+&hdmi0 {
+	status = "okay";
+};
+
+&hdmi0_in {
+	hdmi0_in_vp0: endpoint {
+		remote-endpoint = <&vp0_out_hdmi0>;
+	};
+};
+
+&hdmi0_out {
+	hdmi0_out_con: endpoint {
+		remote-endpoint = <&hdmi0_con_in>;
+	};
+};
+
+&hdmi0_sound {
+	status = "okay";
+};
+
+&hdmi1 {
+	status = "okay";
+};
+
+&hdmi1_in {
+	hdmi1_in_vp1: endpoint {
+		remote-endpoint = <&vp1_out_hdmi1>;
+	};
+};
+
+&hdmi1_out {
+	hdmi1_out_con: endpoint {
+		remote-endpoint = <&hdmi1_con_in>;
+	};
+};
+
+&hdmi1_sound {
+	status = "okay";
+};
+
+&hdmi_receiver {
+	pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_hpd>;
+	pinctrl-names = "default";
+	hpd-gpios = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&hdmi_receiver_cma {
+	status = "okay";
+};
+
+&hdptxphy0 {
+	status = "okay";
+};
+
+&hdptxphy1 {
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-0 = <&i2c0m2_xfer>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator@42 {
+		compatible = "rockchip,rk8602";
+		fcs,suspend-voltage-selector = <1>;
+		reg = <0x42>;
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-max-microvolt = <1050000>;
+		regulator-min-microvolt = <550000>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator@43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		fcs,suspend-voltage-selector = <1>;
+		reg = <0x43>;
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-max-microvolt = <1050000>;
+		regulator-min-microvolt = <550000>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	hym8563: rtc@51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-output-names = "hym8563";
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtc_int>;
+		wakeup-source;
+	};
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1m2_xfer>;
+	status = "okay";
+
+	vdd_npu_s0: regulator@42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-boot-on;
+		regulator-enable-ramp-delay = <500>;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c6 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c6m0_xfer>;
+	status = "okay";
+
+	pca9554: gpio@24 {
+		compatible = "nxp,pca9554";
+		#gpio-cells = <2>;
+		gpio-controller;
+		reg = <0x24>;
+		vcc-supply = <&vcc3v3_io_expander>;
+	};
+};
+
+&i2s5_8ch {
+	status = "okay";
+};
+
+&i2s6_8ch {
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	full-pwr-cycle-in-suspend;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	no-sd;
+	no-sdio;
+	non-removable;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vcc_1v8_s3>;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	max-frequency = <200000000>;
+	no-mmc;
+	no-sdio;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	assigned-clock-rates = <200000000>;
+	assigned-clocks = <&cru CLK_SPI2>;
+	num-cs = <1>;
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	pmic@0 {
+		reg = <0>;
+		compatible = "rockchip,rk806";
+		#gpio-cells = <2>;
+		gpio-controller;
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default", "pmic-power-off";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+					<&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		pinctrl-1 = <&rk806_dvs1_pwrdn>;
+		spi-max-frequency = <1000000>;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		rk806_dvs1_null: rk806_dvs1_null {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs1_slp: rk806_dvs1_slp {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun1";
+		};
+
+		rk806_dvs1_pwrdn: rk806_dvs1_pwrdn {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun2";
+		};
+
+		rk806_dvs1_rst: rk806_dvs1_rst {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun3";
+		};
+
+		rk806_dvs2_null: rk806_dvs2_null {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_slp: rk806_dvs2_slp {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun1";
+		};
+
+		rk806_dvs2_pwrdn: rk806_dvs2_pwrdn {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun2";
+		};
+
+		rk806_dvs2_rst: rk806_dvs2_rst {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun3";
+		};
+
+		rk806_dvs2_dvs: rk806_dvs2_dvs {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun4";
+		};
+
+		rk806_dvs2_gpio: rk806_dvs2_gpio {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun5";
+		};
+
+		rk806_dvs3_null: rk806_dvs3_null {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_slp: rk806_dvs3_slp {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun1";
+		};
+
+		rk806_dvs3_pwrdn: rk806_dvs3_pwrdn {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun2";
+		};
+
+		rk806_dvs3_rst: rk806_dvs3_rst {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun3";
+		};
+
+		rk806_dvs3_dvs: rk806_dvs3_dvs {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun4";
+		};
+
+		rk806_dvs3_gpio: rk806_dvs3_gpio {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun5";
+		};
+
+		regulators {
+			vdd_gpu_s0: dcdc-reg1 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: dcdc-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_lit_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_log_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: dcdc-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_vdenc_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vdd2_ddr_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-name = "vdd_2v0_pldo_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_3v3_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vddq_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "avcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "avdd_1v2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3_s0: pldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vccio_sd_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "pldo6_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_ddr_pll_s0: nldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_ddr_pll_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <837500>;
+				regulator-max-microvolt = <837500>;
+				regulator-name = "avdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v85_s0: nldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_0v85_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&mdio1 {
+	rgmii_phy: phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x1>;
+	};
+};
+
+&pcie2x1l0 {
+	reset-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie2_0_rst>;
+	vpcie3v3-supply = <&vcc3v3_pcie20_sata30>;
+	status = "okay";
+};
+
+&pcie2x1l1 {
+	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie2_1_rst>;
+	vpcie3v3-supply = <&vcc3v3_pcie20_sata30>;
+	status = "okay";
+};
+
+&pcie2x1l2 {
+	status = "disabled";
+};
+
+&pcie30phy {
+	status = "okay";
+};
+
+&pcie3x4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie3_reset>;
+	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_pcie30>;
+	status = "okay";
+};
+
+&pinctrl {
+
+	hdmirx {
+		hdmirx_hpd: hdmirx-5v-detection {
+			rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+
+	hym8563 {
+		rtc_int: rtc-int {
+			rockchip,pins =
+				<0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pcie2 {
+		pcie2_0_rst: pcie2-0-rst {
+			rockchip,pins =
+				<4 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		pcie2_1_rst: pcie2-1-rst {
+			rockchip,pins =
+				<4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pcie3 {
+		pcie3_reset: pcie3-reset {
+			rockchip,pins =
+				<4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+};
+
+&saradc {
+	vref-supply = <&avcc_1v8_s0>;
+	status = "okay";
+};
+
+&sata0 {
+	status = "okay";
+};
+
+&tsadc {
+	status = "okay";
+};
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_usb20_host>;
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy3_host {
+	phy-supply = <&vcc5v0_usb20_host>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&vop {
+	status = "okay";
+};
+
+&vop_mmu {
+	status = "okay";
+};
+
+&vp0 {
+	vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+		remote-endpoint = <&hdmi0_in_vp0>;
+	};
+};
+
+&vp1 {
+	vp1_out_hdmi1: endpoint@ROCKCHIP_VOP2_EP_HDMI1 {
+		reg = <ROCKCHIP_VOP2_EP_HDMI1>;
+		remote-endpoint = <&hdmi1_in_vp1>;
+	};
+};
-- 
2.47.3



^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox