* Re: [PATCH v2 3/4] media: rkisp1: use fwnode_graph_for_each_endpoint_scoped() to simplify code
From: Laurent Pinchart @ 2026-06-24 19:16 UTC (permalink / raw)
To: Frank.Li
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li
In-Reply-To: <20260624-fw_scoped-v2-3-0a8db472af4a@nxp.com>
On Wed, Jun 24, 2026 at 01:00:11PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Use fwnode_graph_for_each_endpoint_scoped() to simplify code.
>
> No functional changes.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Andy: Keep original code because too much break. and I am working on more
> generally solution, so the whole function can be replaced.
> ---
> drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index 1791c02a40ae1..f90e01301943c 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -187,7 +187,6 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
> {
> struct v4l2_async_notifier *ntf = &rkisp1->notifier;
> struct fwnode_handle *fwnode = dev_fwnode(rkisp1->dev);
> - struct fwnode_handle *ep;
> unsigned int index = 0;
> int ret = 0;
>
> @@ -195,7 +194,7 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
>
> ntf->ops = &rkisp1_subdev_notifier_ops;
>
> - fwnode_graph_for_each_endpoint(fwnode, ep) {
> + fwnode_graph_for_each_endpoint_scoped(fwnode, ep) {
> struct fwnode_handle *port;
> struct v4l2_fwnode_endpoint vep = { };
> struct rkisp1_sensor_async *rk_asd;
> @@ -286,7 +285,6 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
> }
>
> if (ret) {
> - fwnode_handle_put(ep);
> v4l2_async_nf_cleanup(ntf);
> return ret;
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 2/4] media: mc: use fwnode_graph_for_each_endpoint_scoped() to simpilfy code
From: Laurent Pinchart @ 2026-06-24 19:14 UTC (permalink / raw)
To: Frank.Li
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624-fw_scoped-v2-2-0a8db472af4a@nxp.com>
On Wed, Jun 24, 2026 at 01:00:10PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Use cleanup helper fwnode_graph_for_each_endpoint_scoped() to simpilfy
> code.
>
> Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/media/v4l2-core/v4l2-mc.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-mc.c b/drivers/media/v4l2-core/v4l2-mc.c
> index 937d358697e19..5d7fcd67dc42e 100644
> --- a/drivers/media/v4l2-core/v4l2-mc.c
> +++ b/drivers/media/v4l2-core/v4l2-mc.c
> @@ -324,12 +324,10 @@ EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
> int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
> struct media_pad *sink, u32 flags)
> {
> - struct fwnode_handle *endpoint;
> -
> if (!(sink->flags & MEDIA_PAD_FL_SINK))
> return -EINVAL;
>
> - fwnode_graph_for_each_endpoint(src_sd->fwnode, endpoint) {
> + fwnode_graph_for_each_endpoint_scoped(src_sd->fwnode, endpoint) {
> struct fwnode_handle *remote_ep;
> int src_idx, sink_idx, ret;
> struct media_pad *src;
> @@ -397,7 +395,6 @@ int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
> src_sd->entity.name, src_idx,
> sink->entity->name, sink_idx, ret);
>
> - fwnode_handle_put(endpoint);
> return ret;
> }
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 1/4] device property: Introduce fwnode_graph_for_each_endpoint_scoped()
From: Laurent Pinchart @ 2026-06-24 19:13 UTC (permalink / raw)
To: Frank.Li
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624-fw_scoped-v2-1-0a8db472af4a@nxp.com>
Hi Frank,
Thank you for the patch.
On Wed, Jun 24, 2026 at 01:00:09PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Similar to recently propose for_each_child_of_node_scoped() this new
> version of the loop macro instantiates a new local struct fwnode_handle *
> that uses the __free(fwnode_handle) auto cleanup handling so that if a
> reference to a node is held on early exit from the loop the reference will
> be released. If the loop runs to completion, the child pointer will be NULL
> and no action will be taken.
>
> The reason this is useful is that it removes the need for
> fwnode_handle_put() on early loop exits. If there is a need to retain the
> reference, then return_ptr(child) or no_free_ptr(child) may be used to
> safely disable the auto cleanup.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Nice idea.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> change in v2
> - collect Andy and Guoniu's reviewed-by tags
> - fix indention
> - remove extra space in commit message
> ---
> include/linux/property.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/property.h b/include/linux/property.h
> index 14c304db46648..d51824c13d2cc 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -545,6 +545,11 @@ unsigned int fwnode_graph_get_endpoint_count(const struct fwnode_handle *fwnode,
> for (child = fwnode_graph_get_next_endpoint(fwnode, NULL); child; \
> child = fwnode_graph_get_next_endpoint(fwnode, child))
>
> +#define fwnode_graph_for_each_endpoint_scoped(fwnode, child) \
> + for (struct fwnode_handle *child __free(fwnode_handle) = \
> + fwnode_graph_get_next_endpoint(fwnode, NULL); \
> + child; child = fwnode_graph_get_next_endpoint(fwnode, child))
> +
> int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
> struct fwnode_endpoint *endpoint);
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] misc: xilinx_sdfec: validate LDPC code register offsets
From: Yousef Alhouseen @ 2026-06-24 19:08 UTC (permalink / raw)
To: Derek Kiernan, Dragan Cvetic
Cc: Arnd Bergmann, Greg Kroah-Hartman, Michal Simek, linux-arm-kernel,
linux-kernel, Yousef Alhouseen
The LDPC code register helpers check the target MMIO address after adding
code_id * XSDFEC_LDPC_REG_JUMP to the register base. code_id is supplied
through the ioctl path, so the multiplication and addition can wrap before
the bounds check.
Validate the code_id against the register window size before computing
the final address, then write using the checked address.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
drivers/misc/xilinx_sdfec.c | 72 +++++++++++++++++--------------------
1 file changed, 32 insertions(+), 40 deletions(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 3135ba3a5..63f0eb2bd 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -456,10 +456,23 @@ static int xsdfec_get_turbo(struct xsdfec_dev *xsdfec, void __user *arg)
return err;
}
+static int xsdfec_ldpc_reg_addr(struct xsdfec_dev *xsdfec, u32 base, u32 high,
+ u32 offset, u32 *addr)
+{
+ if (offset > (high - base) / XSDFEC_LDPC_REG_JUMP) {
+ dev_dbg(xsdfec->dev, "Writing outside of LDPC register space");
+ return -EINVAL;
+ }
+
+ *addr = base + offset * XSDFEC_LDPC_REG_JUMP;
+ return 0;
+}
+
static int xsdfec_reg0_write(struct xsdfec_dev *xsdfec, u32 n, u32 k, u32 psize,
u32 offset)
{
u32 wdata;
+ u32 addr;
if (n < XSDFEC_REG0_N_MIN || n > XSDFEC_REG0_N_MAX || psize == 0 ||
(n > XSDFEC_REG0_N_MUL_P * psize) || n <= k || ((n % psize) != 0)) {
@@ -476,17 +489,11 @@ static int xsdfec_reg0_write(struct xsdfec_dev *xsdfec, u32 n, u32 k, u32 psize,
k = k << XSDFEC_REG0_K_LSB;
wdata = k | n;
- if (XSDFEC_LDPC_CODE_REG0_ADDR_BASE + (offset * XSDFEC_LDPC_REG_JUMP) >
- XSDFEC_LDPC_CODE_REG0_ADDR_HIGH) {
- dev_dbg(xsdfec->dev, "Writing outside of LDPC reg0 space 0x%x",
- XSDFEC_LDPC_CODE_REG0_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP));
+ if (xsdfec_ldpc_reg_addr(xsdfec, XSDFEC_LDPC_CODE_REG0_ADDR_BASE,
+ XSDFEC_LDPC_CODE_REG0_ADDR_HIGH, offset,
+ &addr))
return -EINVAL;
- }
- xsdfec_regwrite(xsdfec,
- XSDFEC_LDPC_CODE_REG0_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP),
- wdata);
+ xsdfec_regwrite(xsdfec, addr, wdata);
return 0;
}
@@ -494,6 +501,7 @@ static int xsdfec_reg1_write(struct xsdfec_dev *xsdfec, u32 psize,
u32 no_packing, u32 nm, u32 offset)
{
u32 wdata;
+ u32 addr;
if (psize < XSDFEC_REG1_PSIZE_MIN || psize > XSDFEC_REG1_PSIZE_MAX) {
dev_dbg(xsdfec->dev, "Psize is not in range");
@@ -510,17 +518,11 @@ static int xsdfec_reg1_write(struct xsdfec_dev *xsdfec, u32 psize,
nm = (nm << XSDFEC_REG1_NM_LSB) & XSDFEC_REG1_NM_MASK;
wdata = nm | no_packing | psize;
- if (XSDFEC_LDPC_CODE_REG1_ADDR_BASE + (offset * XSDFEC_LDPC_REG_JUMP) >
- XSDFEC_LDPC_CODE_REG1_ADDR_HIGH) {
- dev_dbg(xsdfec->dev, "Writing outside of LDPC reg1 space 0x%x",
- XSDFEC_LDPC_CODE_REG1_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP));
+ if (xsdfec_ldpc_reg_addr(xsdfec, XSDFEC_LDPC_CODE_REG1_ADDR_BASE,
+ XSDFEC_LDPC_CODE_REG1_ADDR_HIGH, offset,
+ &addr))
return -EINVAL;
- }
- xsdfec_regwrite(xsdfec,
- XSDFEC_LDPC_CODE_REG1_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP),
- wdata);
+ xsdfec_regwrite(xsdfec, addr, wdata);
return 0;
}
@@ -529,6 +531,7 @@ static int xsdfec_reg2_write(struct xsdfec_dev *xsdfec, u32 nlayers, u32 nmqc,
u32 max_schedule, u32 offset)
{
u32 wdata;
+ u32 addr;
if (nlayers < XSDFEC_REG2_NLAYERS_MIN ||
nlayers > XSDFEC_REG2_NLAYERS_MAX) {
@@ -563,17 +566,11 @@ static int xsdfec_reg2_write(struct xsdfec_dev *xsdfec, u32 nlayers, u32 nmqc,
wdata = (max_schedule | no_final_parity | special_qc | norm_type |
nmqc | nlayers);
- if (XSDFEC_LDPC_CODE_REG2_ADDR_BASE + (offset * XSDFEC_LDPC_REG_JUMP) >
- XSDFEC_LDPC_CODE_REG2_ADDR_HIGH) {
- dev_dbg(xsdfec->dev, "Writing outside of LDPC reg2 space 0x%x",
- XSDFEC_LDPC_CODE_REG2_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP));
+ if (xsdfec_ldpc_reg_addr(xsdfec, XSDFEC_LDPC_CODE_REG2_ADDR_BASE,
+ XSDFEC_LDPC_CODE_REG2_ADDR_HIGH, offset,
+ &addr))
return -EINVAL;
- }
- xsdfec_regwrite(xsdfec,
- XSDFEC_LDPC_CODE_REG2_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP),
- wdata);
+ xsdfec_regwrite(xsdfec, addr, wdata);
return 0;
}
@@ -581,20 +578,15 @@ static int xsdfec_reg3_write(struct xsdfec_dev *xsdfec, u8 sc_off, u8 la_off,
u16 qc_off, u32 offset)
{
u32 wdata;
+ u32 addr;
wdata = ((qc_off << XSDFEC_REG3_QC_OFF_LSB) |
(la_off << XSDFEC_REG3_LA_OFF_LSB) | sc_off);
- if (XSDFEC_LDPC_CODE_REG3_ADDR_BASE + (offset * XSDFEC_LDPC_REG_JUMP) >
- XSDFEC_LDPC_CODE_REG3_ADDR_HIGH) {
- dev_dbg(xsdfec->dev, "Writing outside of LDPC reg3 space 0x%x",
- XSDFEC_LDPC_CODE_REG3_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP));
+ if (xsdfec_ldpc_reg_addr(xsdfec, XSDFEC_LDPC_CODE_REG3_ADDR_BASE,
+ XSDFEC_LDPC_CODE_REG3_ADDR_HIGH, offset,
+ &addr))
return -EINVAL;
- }
- xsdfec_regwrite(xsdfec,
- XSDFEC_LDPC_CODE_REG3_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP),
- wdata);
+ xsdfec_regwrite(xsdfec, addr, wdata);
return 0;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 3/3] KVM: arm64: top up stage 2 memcache for dirty logging faults
From: Bradley Morgan @ 2026-06-24 18:37 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, Gavin Shan, Alexandru Elisei,
linux-arm-kernel, kvmarm, linux-kernel, stable
In-Reply-To: <86ik77re2n.wl-maz@kernel.org>
On June 24, 2026 7:25:04 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
>On Wed, 24 Jun 2026 18:46:10 +0100,
>Bradley Morgan <include@grrlz.net> wrote:
>>
>> On June 24, 2026 6:39:16 PM GMT+01:00, Bradley Morgan
><include@grrlz.net>
>> wrote:
>> >
>> >Note: Patch 3 seems to conflict because of patch 2 (the comments)
>> >
>> >
>> >Oops! :(
>> >
>> >V4 (after people have their review go), will contain one commit (patch
>> >3) with the updated comments.
>> >
>> >Patch 1 and 2 applies as usual.
>> >
>> >Apologies for my messup.
>> >
>> >Thanks!
>>
>>
>> Actually. Hmm.
>>
>> I'll just drop patches 2 and 3, I'll do them at a later date, please
>> disregard patches 2 and 3, patch 1 doesn't rely on 2 and 3..
>>
>> If you guys wanna have a look feel free! :)
>
>As I suggested in my reply to your hasty v2, taking a few *days*
>between versions is generally a good thing. it gives the reviewers
>time to chime in, and gives you the opportunity to reflect on what
>you've just written (reading your own patches after a few days is a
>sure way to go and rewrite them).
welp, I guess I learned the hard way with the hastiness of my V3, (that's
kinda why I dropped p2 and p3)
>Actually, by posting more often, you are guaranteeing that people
>*avoid* reviewing your stuff, since odds are that there is a new
>version coming in the next 10 minutes, so why bother...
I'm not planning on posting another version, until fuller review concludes
>But hey, that's free advice, so it's probably worthless.
advice from someone with experience isn't worthless.
just stupid me decided to unpark my V3 and send it :(
Sorry about that..
> M.
>
>
Thanks!
^ permalink raw reply
* Re: [PATCH v3 3/3] KVM: arm64: top up stage 2 memcache for dirty logging faults
From: Marc Zyngier @ 2026-06-24 18:25 UTC (permalink / raw)
To: Bradley Morgan
Cc: Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, Gavin Shan, Alexandru Elisei,
linux-arm-kernel, kvmarm, linux-kernel, stable
In-Reply-To: <6FBA06E8-B0C4-444C-B226-0B756C0172A7@grrlz.net>
On Wed, 24 Jun 2026 18:46:10 +0100,
Bradley Morgan <include@grrlz.net> wrote:
>
> On June 24, 2026 6:39:16 PM GMT+01:00, Bradley Morgan <include@grrlz.net>
> wrote:
> >
> >Note: Patch 3 seems to conflict because of patch 2 (the comments)
> >
> >
> >Oops! :(
> >
> >V4 (after people have their review go), will contain one commit (patch
> >3) with the updated comments.
> >
> >Patch 1 and 2 applies as usual.
> >
> >Apologies for my messup.
> >
> >Thanks!
>
>
> Actually. Hmm.
>
> I'll just drop patches 2 and 3, I'll do them at a later date, please
> disregard patches 2 and 3, patch 1 doesn't rely on 2 and 3..
>
> If you guys wanna have a look feel free! :)
As I suggested in my reply to your hasty v2, taking a few *days*
between versions is generally a good thing. it gives the reviewers
time to chime in, and gives you the opportunity to reflect on what
you've just written (reading your own patches after a few days is a
sure way to go and rewrite them).
Actually, by posting more often, you are guaranteeing that people
*avoid* reviewing your stuff, since odds are that there is a new
version coming in the next 10 minutes, so why bother...
But hey, that's free advice, so it's probably worthless.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] dt-bindings: mediatek: hdmi-ddc: Correct the compatibles for mt7623-mt8167
From: Krzysztof Kozlowski @ 2026-06-24 18:20 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, CK Hu, Jitao shi, dri-devel,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260624173514.19752-1-l.scorcia@gmail.com>
On 24/06/2026 19:34, Luca Leonardo Scorcia wrote:
> The HDMI DDC driver for both mt7623 and mt8167 is actually the same as
> mt8173-hdmi-ddc and the mt7623n.dtsi board include file already uses
> mt8173-hdmi-ddc compatible as a fallback, but the documentation lists
> them as separate entries. Correct the binding by adding the correct
> fallback.
>
> This change fixes the following dtbs_check errors:
>
> DTC [C] arch/arm/boot/dts/mediatek/mt7623n-rfb-emmc.dtb
This you can drop, not relevant and such redundant logs only make it
more difficult to understand the error message. I asked only to paste
here the error.
Anyway,
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] net: sparx5: unregister blocking notifier on init failure
From: Simon Horman @ 2026-06-24 18:16 UTC (permalink / raw)
To: Haoxiang Li
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, kees, bjarni.jonasson,
lars.povlsen, netdev, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260623115714.2192074-1-haoxiang_li2024@163.com>
On Tue, Jun 23, 2026 at 07:57:14PM +0800, Haoxiang Li wrote:
> sparx5_register_notifier_blocks() registers the switchdev blocking
> notifier before allocating the ordered workqueue. If the workqueue
> allocation fails, the error path unregisters the switchdev and netdevice
> notifiers, but leaves the blocking notifier registered.
>
> Add a separate error label for the workqueue allocation failure path and
> unregister the switchdev blocking notifier there.
>
> Fixes: d6fce5141929 ("net: sparx5: add switching support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 3/3] KVM: arm64: top up stage 2 memcache for dirty logging faults
From: Bradley Morgan @ 2026-06-24 17:46 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Quentin Perret,
Vincent Donnefort, Gavin Shan, Alexandru Elisei, linux-arm-kernel,
kvmarm, linux-kernel, stable
In-Reply-To: <9FCEC7E9-DE50-443F-8E82-9FA22CA15ED6@grrlz.net>
On June 24, 2026 6:39:16 PM GMT+01:00, Bradley Morgan <include@grrlz.net>
wrote:
>On June 24, 2026 5:00:28 PM GMT+01:00, Bradley Morgan <include@grrlz.net>
>wrote:
>>Dirty logging forces new stage 2 mappings down to page size, but
>>it does not always remove an existing block mapping before the next
>>fault. Eager splitting is best effort and is disabled by default.
>>
>>A permission fault on such a block can still need a page table page
>>to install the smaller mapping. Top up the memcache for any permission
>>fault while dirty logging is active, not only for write faults.
>>
>>The issue was discovered [1] by Sashiko.
>>
>>Link:
>https://lore.kernel.org/all/59984F6D-06F2-4302-BDD7-92DF334E8FA0@grrlz.net/T/#t
>[1]
>>
>>Fixes: 6f745f1bb5bf ("KVM: arm64: Convert user_mem_abort() to generic
>page-table API")
>>Cc: stable@vger.kernel.org
>>Signed-off-by: Bradley Morgan <include@grrlz.net>
>>---
>> arch/arm64/kvm/mmu.c | 9 ++++-----
>> 1 file changed, 4 insertions(+), 5 deletions(-)
>>
>>diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>index 3f57f6825a33..8911e319e6fa 100644
>>--- a/arch/arm64/kvm/mmu.c
>>+++ b/arch/arm64/kvm/mmu.c
>>@@ -2122,13 +2122,12 @@ static int user_mem_abort(const struct
>kvm_s2_fault_desc *s2fd)
>> * Permission faults just need to update the existing leaf entry,
>> * and so normally don't require allocations from the memcache. The
>> * only exception to this is when dirty logging is enabled at runtime
>>- * and a write fault needs to collapse a block entry into a table. With
>>- * pKVM, they may still need a fresh mapping object if the fault turns
>>- * page entries into a block entry.
>>+ * and a fault needs to collapse a block entry into a table. With pKVM,
>>+ * they may still need a fresh mapping object if the fault turns page
>>+ * entries into a block entry.
>> */
>> memcache = get_mmu_memcache(s2fd->vcpu);
>>- if (!perm_fault || (memslot_is_logging(s2fd->memslot) &&
>>- kvm_is_write_fault(s2fd->vcpu))) {
>>+ if (!perm_fault || memslot_is_logging(s2fd->memslot)) {
>> ret = topup_mmu_memcache(s2fd->vcpu, memcache);
>> if (ret)
>> return ret;
>>
>
>Note: Patch 3 seems to conflict because of patch 2 (the comments)
>
>
>Oops! :(
>
>V4 (after people have their review go), will contain one commit (patch
>3) with the updated comments.
>
>Patch 1 and 2 applies as usual.
>
>Apologies for my messup.
>
>Thanks!
Actually. Hmm.
I'll just drop patches 2 and 3, I'll do them at a later date, please
disregard patches 2 and 3, patch 1 doesn't rely on 2 and 3..
If you guys wanna have a look feel free! :)
Thanks!
^ permalink raw reply
* Re: [PATCH v3 3/3] KVM: arm64: top up stage 2 memcache for dirty logging faults
From: Bradley Morgan @ 2026-06-24 17:39 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Quentin Perret,
Vincent Donnefort, Gavin Shan, Alexandru Elisei, linux-arm-kernel,
kvmarm, linux-kernel, stable
In-Reply-To: <20260624160028.15591-4-include@grrlz.net>
On June 24, 2026 5:00:28 PM GMT+01:00, Bradley Morgan <include@grrlz.net>
wrote:
>Dirty logging forces new stage 2 mappings down to page size, but
>it does not always remove an existing block mapping before the next
>fault. Eager splitting is best effort and is disabled by default.
>
>A permission fault on such a block can still need a page table page
>to install the smaller mapping. Top up the memcache for any permission
>fault while dirty logging is active, not only for write faults.
>
>The issue was discovered [1] by Sashiko.
>
>Link: https://lore.kernel.org/all/59984F6D-06F2-4302-BDD7-92DF334E8FA0@grrlz.net/T/#t [1]
>
>Fixes: 6f745f1bb5bf ("KVM: arm64: Convert user_mem_abort() to generic page-table API")
>Cc: stable@vger.kernel.org
>Signed-off-by: Bradley Morgan <include@grrlz.net>
>---
> arch/arm64/kvm/mmu.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
>diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>index 3f57f6825a33..8911e319e6fa 100644
>--- a/arch/arm64/kvm/mmu.c
>+++ b/arch/arm64/kvm/mmu.c
>@@ -2122,13 +2122,12 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
> * Permission faults just need to update the existing leaf entry,
> * and so normally don't require allocations from the memcache. The
> * only exception to this is when dirty logging is enabled at runtime
>- * and a write fault needs to collapse a block entry into a table. With
>- * pKVM, they may still need a fresh mapping object if the fault turns
>- * page entries into a block entry.
>+ * and a fault needs to collapse a block entry into a table. With pKVM,
>+ * they may still need a fresh mapping object if the fault turns page
>+ * entries into a block entry.
> */
> memcache = get_mmu_memcache(s2fd->vcpu);
>- if (!perm_fault || (memslot_is_logging(s2fd->memslot) &&
>- kvm_is_write_fault(s2fd->vcpu))) {
>+ if (!perm_fault || memslot_is_logging(s2fd->memslot)) {
> ret = topup_mmu_memcache(s2fd->vcpu, memcache);
> if (ret)
> return ret;
>
Note: Patch 3 seems to conflict because of patch 2 (the comments)
Oops! :(
V4 (after people have their review go), will contain one commit (patch
3) with the updated comments.
Patch 1 and 2 applies as usual.
Apologies for my messup.
Thanks!
^ permalink raw reply
* [PATCH v2] dt-bindings: mediatek: cec: Correct the compatibles for mt7623-mt8167
From: Luca Leonardo Scorcia @ 2026-06-24 17:36 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, CK Hu, Jitao shi,
dri-devel, devicetree, linux-kernel, linux-arm-kernel
The HDMI CEC driver for both mt7623 and mt8167 is actually the same as
mt8173-cec and the mt7623n.dtsi board include file already uses mt8173-cec
compatible as a fallback, but the documentation lists them as separate
entries. Correct the binding by adding the correct fallback.
This change fixes the following dtbs_check errors:
DTC [C] arch/arm/boot/dts/mediatek/mt7623n-rfb-emmc.dtb
cec@10012000 (mediatek,mt7623-cec): compatible: ['mediatek,mt7623-cec',
'mediatek,mt8173-cec'] is too long
DTC [C] arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dtb
cec@10012000 (mediatek,mt7623-cec): compatible: ['mediatek,mt7623-cec',
'mediatek,mt8173-cec'] is too long
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
Changes in v2:
* Fixed yaml indent (sorry about that, I ran checks multiple times but
it did not show anything - I had to clean everything and run them again
to get them to show...).
* Added details about the errors that are fixed with this patch.
Initial version: [1]
[1] https://lore.kernel.org/linux-mediatek/20260623135757.5111-1-l.scorcia@gmail.com/
.../bindings/display/mediatek/mediatek,cec.yaml | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
index 080cf321209e..bc288b1c6f07 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -15,10 +15,13 @@ description: |
properties:
compatible:
- enum:
- - mediatek,mt7623-cec
- - mediatek,mt8167-cec
- - mediatek,mt8173-cec
+ oneOf:
+ - const: mediatek,mt8173-cec
+ - items:
+ - enum:
+ - mediatek,mt7623-cec
+ - mediatek,mt8167-cec
+ - const: mediatek,mt8173-cec
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH] dt-bindings: mediatek: hdmi-ddc: Correct the compatibles for mt7623-mt8167
From: Luca Leonardo Scorcia @ 2026-06-24 17:34 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Chun-Kuang Hu, Philipp Zabel,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, CK Hu, Jitao shi,
dri-devel, devicetree, linux-kernel, linux-arm-kernel
The HDMI DDC driver for both mt7623 and mt8167 is actually the same as
mt8173-hdmi-ddc and the mt7623n.dtsi board include file already uses
mt8173-hdmi-ddc compatible as a fallback, but the documentation lists
them as separate entries. Correct the binding by adding the correct
fallback.
This change fixes the following dtbs_check errors:
DTC [C] arch/arm/boot/dts/mediatek/mt7623n-rfb-emmc.dtb
i2c@11013000 (mediatek,mt7623-hdmi-ddc): compatible:
['mediatek,mt7623-hdmi-ddc', 'mediatek,mt8173-hdmi-ddc'] is too long
DTC [C] arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dtb
i2c@11013000 (mediatek,mt7623-hdmi-ddc): compatible:
['mediatek,mt7623-hdmi-ddc', 'mediatek,mt8173-hdmi-ddc'] is too long
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../bindings/display/mediatek/mediatek,hdmi-ddc.yaml | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
index bd8f7b8ae0ff..966127e1ee63 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -15,10 +15,13 @@ description: |
properties:
compatible:
- enum:
- - mediatek,mt7623-hdmi-ddc
- - mediatek,mt8167-hdmi-ddc
- - mediatek,mt8173-hdmi-ddc
+ oneOf:
+ - const: mediatek,mt8173-hdmi-ddc
+ - items:
+ - enum:
+ - mediatek,mt7623-hdmi-ddc
+ - mediatek,mt8167-hdmi-ddc
+ - const: mediatek,mt8173-hdmi-ddc
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v15 01/11] entry: Fix potential syscall truncation in syscall_trace_enter()
From: Thomas Gleixner @ 2026-06-24 17:34 UTC (permalink / raw)
To: Jinjie Ruan, catalin.marinas, will, oleg, peterz, luto, kees, wad,
ruanjinjie, mark.rutland, yeoreum.yun, linusw, kevin.brodsky, ldv,
thuth, james.morse, song, ada.coupriediaz, anshuman.khandual,
broonie, ryan.roberts, pengcan, liqiang01, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260511092103.1974980-2-ruanjinjie@huawei.com>
On Mon, May 11 2026 at 17:20, Jinjie Ruan wrote:
> In syscall_trace_enter(), the current logic returns "ret ? : syscall".
> While __secure_computing() currently only returns 0 (allow) or -1 (kill),
> this "ret ? : syscall" pattern is conceptually flawed.
>
> If __secure_computing() were to return a non-zero value that isn't -1, it
> would unintentionally override the actual system call number. This logic
> is redundant because if seccomp denies the syscall, the execution path
> should already be handled by the caller based on the error return, rather
> than conflating the return code with the syscall number.
>
> Fix it by explicitly returning the syscall number. This ensures
> the syscall register remains untainted by the trace return values and
> aligns with the expectation that seccomp-related interceptions are
> handled via the -1 return status.
>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality")
What's fixed here?
A potential future change of the __secure_computing() return value
requires that _ALL_ callsites of that function have to be audited
and fixed up, no?
So the change is not a fix it's an optimization to get rid of the extra
conditional.
If you really want to sanitize this, then change the
__secure_computing() return type to boolean (true = allow, false =
fail) and fixup the two dozen or so call sites.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v17 01/28] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
From: Harry Wentland @ 2026-06-24 17:15 UTC (permalink / raw)
To: Nicolas Frattaroli, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Werner Sembach, Andri Yngvason
In-Reply-To: <20260609-color-format-v17-1-35739b5782cc@collabora.com>
On 2026-06-09 08:43, Nicolas Frattaroli wrote:
> From: Werner Sembach <wse@tuxedocomputers.com>
>
> Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
> drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
> force_yuv420_output case.
>
> Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
> there is no reason to use RGB when the display
> reports drm_mode_is_420_only() even on a non HDMI connection.
>
> This patch also moves both checks in the same if-case. This eliminates an
> extra else-if-case.
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Signed-off-by: Andri Yngvason <andri@yngvason.is>
> Tested-by: Andri Yngvason <andri@yngvason.is>
> Reviewed-by: Daniel Stone <daniel@fooishbar.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index ba7f98a87808..dfe97897127c 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6917,12 +6917,9 @@ static void fill_stream_properties_from_drm_display_mode(
> timing_out->v_border_top = 0;
> timing_out->v_border_bottom = 0;
> /* TODO: un-hardcode */
> - if (drm_mode_is_420_only(info, mode_in)
> - && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
> - timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
> - else if (drm_mode_is_420_also(info, mode_in)
> - && aconnector
> - && aconnector->force_yuv420_output)
> + if (drm_mode_is_420_only(info, mode_in) ||
> + (aconnector && aconnector->force_yuv420_output &&
> + drm_mode_is_420_also(info, mode_in)))
> timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
> else if ((connector->display_info.color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
> && aconnector
>
^ permalink raw reply
* [PATCH v2 0/4] media: add and use fwnode_graph_for_each_endpoint_scoped()
From: Frank.Li @ 2026-06-24 17:00 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Laurent Pinchart,
Heiko Stuebner, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain
Cc: driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
Add new helper macro fwnode_graph_for_each_endpoint_scoped() and use it
simplify media code.
Typical example should qualcomm's driver (camss.c), the v4l2_mc.c and
rkisp1-dev.c only silience improvement.
Anyways, *_for_each_*_scoped() already use widely and make code clean.
Build test only.
Sakari Ailus:
when I try to improve the patch
"Add common helper library for 1-to-1 subdev registration", I found need
camss.c pattern, so I create this small improvement firstly.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v2:
- colllect review by tags
- fix typo and indent.
- see each patch's change log.
- Link to v1: https://patch.msgid.link/20260622-fw_scoped-v1-0-a37d0aac0a68@nxp.com
---
Frank Li (4):
device property: Introduce fwnode_graph_for_each_endpoint_scoped()
media: mc: use fwnode_graph_for_each_endpoint_scoped() to simpilfy code
media: rkisp1: use fwnode_graph_for_each_endpoint_scoped() to simplify code
media: qcom: camss: use fwnode_graph_for_each_endpoint_scoped() to simplify code
drivers/media/platform/qcom/camss/camss.c | 17 +++++------------
drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4 +---
drivers/media/v4l2-core/v4l2-mc.c | 5 +----
include/linux/property.h | 5 +++++
4 files changed, 12 insertions(+), 19 deletions(-)
---
base-commit: 3ce97bd3c4f18608335e709c24d6a40e7036cab8
change-id: 20260620-fw_scoped-5dab644510a1
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Frank Li @ 2026-06-24 17:07 UTC (permalink / raw)
To: Sherry Sun
Cc: Sherry Sun (OSS), robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Amitkumar Karwar,
Neeraj Sanjay Kale, marcel@holtmann.org, luiz.dentz@gmail.com,
Hongxing Zhu, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <VI0PR04MB121147C305022511469FB603A92ED2@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Wed, Jun 24, 2026 at 07:09:26AM +0000, Sherry Sun wrote:
> > Subject: Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
> >
> > On Tue, Jun 23, 2026 at 11:07:28AM +0800, Sherry Sun (OSS) wrote:
> > > From: Sherry Sun <sherry.sun@nxp.com>
> > >
> > > Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> > > suspend to preserve wakeup capability of the devices and also not to
> > > power on the devices in the init path.
> > > This allows controller power-off to be skipped when some devices(e.g.
> > > M.2 cards key E without auxiliary power) required to support PCIe L2
> > > link state and wake-up mechanisms.
> > >
> > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 36
> > > +++++++++++++++++----------
> > > 1 file changed, 23 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 0fa716d1ed75..ff5a9565dbbf 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -1382,16 +1382,20 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> > *pp)
> > > }
> > > }
> > >
> > > - ret = pci_pwrctrl_create_devices(dev);
> > > - if (ret) {
> > > - dev_err(dev, "failed to create pwrctrl devices\n");
> > > - goto err_reg_disable;
> > > + if (!pci->suspended) {
> > > + ret = pci_pwrctrl_create_devices(dev);
> >
> > Is possible move pci_pwrctrl_create_devices() of pci_pwrctrl_create_devices
> >
> > and call it direct at probe() function, like other regulator_get function.
> >
>
> Hi Frank,
> That makes sense. However, if we move pci_pwrctrl_create_devices () to
> probe(), we may need to add the following goto err_pwrctrl_destroy path
> in imx_pcie_probe() to properly handle errors from
> pci_pwrctrl_power_on_devices(), is that acceptable?
Can you add a API devm_pci_pwrctrl_create_devices() ?
Frank
>
> @@ -1960,11 +1949,15 @@ static int imx_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = pci_pwrctrl_create_devices(dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to create pwrctrl devices\n");
> +
> pci->use_parent_dt_ranges = true;
> if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> ret = imx_add_pcie_ep(imx_pcie, pdev);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> /*
> * FIXME: Only single Device (EPF) is supported due to the
> @@ -1979,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device *pdev)
> pci->pp.use_atu_msg = true;
> ret = dw_pcie_host_init(&pci->pp);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> if (pci_msi_enabled()) {
> u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
> @@ -1991,6 +1984,11 @@ static int imx_pcie_probe(struct platform_device *pdev)
> }
>
> return 0;
> +
> +err_pwrctrl_destroy:
> + if (ret != -EPROBE_DEFER)
> + pci_pwrctrl_destroy_devices(dev);
> + return ret;
> }
>
> Best Regards
> Sherry
>
> >
> > > + if (ret) {
> > > + dev_err(dev, "failed to create pwrctrl devices\n");
> > > + goto err_reg_disable;
> > > + }
> > > }
> > >
> > > - ret = pci_pwrctrl_power_on_devices(dev);
> > > - if (ret) {
> > > - dev_err(dev, "failed to power on pwrctrl devices\n");
> > > - goto err_pwrctrl_destroy;
> > > + if (!pp->skip_pwrctrl_off) {
> > > + ret = pci_pwrctrl_power_on_devices(dev);
> > > + if (ret) {
> > > + dev_err(dev, "failed to power on pwrctrl devices\n");
> > > + goto err_pwrctrl_destroy;
> > > + }
> > > }
> > >
> > > ret = imx_pcie_clk_enable(imx_pcie); @@ -1460,9 +1464,10 @@
> > static
> > > int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > > err_clk_disable:
> > > imx_pcie_clk_disable(imx_pcie);
> > > err_pwrctrl_power_off:
> > > - pci_pwrctrl_power_off_devices(dev);
> > > + if (!pp->skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(dev);
> > > err_pwrctrl_destroy:
> > > - if (ret != -EPROBE_DEFER)
> > > + if (ret != -EPROBE_DEFER && !pci->suspended)
> > > pci_pwrctrl_destroy_devices(dev);
> > > err_reg_disable:
> > > if (imx_pcie->vpcie)
> > > @@ -1482,7 +1487,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp
> > *pp)
> > > }
> > > imx_pcie_clk_disable(imx_pcie);
> > >
> > > - pci_pwrctrl_power_off_devices(pci->dev);
> > > + if (!pci->pp.skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(pci->dev);
> > > if (imx_pcie->vpcie)
> > > regulator_disable(imx_pcie->vpcie);
> > > }
> > > @@ -1990,12 +1996,16 @@ static int imx_pcie_probe(struct
> > > platform_device *pdev) static void imx_pcie_shutdown(struct
> > > platform_device *pdev) {
> > > struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> > > + struct dw_pcie *pci = imx_pcie->pci;
> > > + struct dw_pcie_rp *pp = &pci->pp;
> > >
> > > /* bring down link, so bootloader gets clean state in case of reboot */
> > > imx_pcie_assert_core_reset(imx_pcie);
> > > imx_pcie_assert_perst(imx_pcie, true);
> > > - pci_pwrctrl_power_off_devices(&pdev->dev);
> > > - pci_pwrctrl_destroy_devices(&pdev->dev);
> > > + if (!pp->skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(&pdev->dev);
> > > + if (!pci->suspended)
> > > + pci_pwrctrl_destroy_devices(&pdev->dev);
> > > }
> > >
> > > static const struct imx_pcie_drvdata drvdata[] = {
> > > --
> > > 2.50.1
> > >
> > >
^ permalink raw reply
* [PATCH v2 4/4] media: qcom: camss: use fwnode_graph_for_each_endpoint_scoped() to simplify code
From: Frank.Li @ 2026-06-24 17:00 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Laurent Pinchart,
Heiko Stuebner, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain
Cc: driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624-fw_scoped-v2-0-0a8db472af4a@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use fwnode_graph_for_each_endpoint_scoped() to simplify code.
No functional changes.
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- fix typo simplify
- collect andy, gouniou and loic's review tags
---
drivers/media/platform/qcom/camss/camss.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 2123f6388e3d7..23f3cc30a15a5 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -4793,30 +4793,23 @@ static int camss_parse_endpoint_node(struct device *dev,
static int camss_parse_ports(struct camss *camss)
{
struct device *dev = camss->dev;
- struct fwnode_handle *fwnode = dev_fwnode(dev), *ep;
+ struct fwnode_handle *fwnode = dev_fwnode(dev);
int ret;
- fwnode_graph_for_each_endpoint(fwnode, ep) {
+ fwnode_graph_for_each_endpoint_scoped(fwnode, ep) {
struct camss_async_subdev *csd;
csd = v4l2_async_nf_add_fwnode_remote(&camss->notifier, ep,
typeof(*csd));
- if (IS_ERR(csd)) {
- ret = PTR_ERR(csd);
- goto err_cleanup;
- }
+ if (IS_ERR(csd))
+ return PTR_ERR(csd);
ret = camss_parse_endpoint_node(dev, ep, csd);
if (ret < 0)
- goto err_cleanup;
+ return ret;
}
return 0;
-
-err_cleanup:
- fwnode_handle_put(ep);
-
- return ret;
}
/*
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] media: rkisp1: use fwnode_graph_for_each_endpoint_scoped() to simplify code
From: Frank.Li @ 2026-06-24 17:00 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Laurent Pinchart,
Heiko Stuebner, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain
Cc: driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li
In-Reply-To: <20260624-fw_scoped-v2-0-0a8db472af4a@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use fwnode_graph_for_each_endpoint_scoped() to simplify code.
No functional changes.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Andy: Keep original code because too much break. and I am working on more
generally solution, so the whole function can be replaced.
---
drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index 1791c02a40ae1..f90e01301943c 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -187,7 +187,6 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
{
struct v4l2_async_notifier *ntf = &rkisp1->notifier;
struct fwnode_handle *fwnode = dev_fwnode(rkisp1->dev);
- struct fwnode_handle *ep;
unsigned int index = 0;
int ret = 0;
@@ -195,7 +194,7 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
ntf->ops = &rkisp1_subdev_notifier_ops;
- fwnode_graph_for_each_endpoint(fwnode, ep) {
+ fwnode_graph_for_each_endpoint_scoped(fwnode, ep) {
struct fwnode_handle *port;
struct v4l2_fwnode_endpoint vep = { };
struct rkisp1_sensor_async *rk_asd;
@@ -286,7 +285,6 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
}
if (ret) {
- fwnode_handle_put(ep);
v4l2_async_nf_cleanup(ntf);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] media: mc: use fwnode_graph_for_each_endpoint_scoped() to simpilfy code
From: Frank.Li @ 2026-06-24 17:00 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Laurent Pinchart,
Heiko Stuebner, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain
Cc: driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624-fw_scoped-v2-0-0a8db472af4a@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use cleanup helper fwnode_graph_for_each_endpoint_scoped() to simpilfy
code.
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
drivers/media/v4l2-core/v4l2-mc.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mc.c b/drivers/media/v4l2-core/v4l2-mc.c
index 937d358697e19..5d7fcd67dc42e 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -324,12 +324,10 @@ EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
struct media_pad *sink, u32 flags)
{
- struct fwnode_handle *endpoint;
-
if (!(sink->flags & MEDIA_PAD_FL_SINK))
return -EINVAL;
- fwnode_graph_for_each_endpoint(src_sd->fwnode, endpoint) {
+ fwnode_graph_for_each_endpoint_scoped(src_sd->fwnode, endpoint) {
struct fwnode_handle *remote_ep;
int src_idx, sink_idx, ret;
struct media_pad *src;
@@ -397,7 +395,6 @@ int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
src_sd->entity.name, src_idx,
sink->entity->name, sink_idx, ret);
- fwnode_handle_put(endpoint);
return ret;
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] device property: Introduce fwnode_graph_for_each_endpoint_scoped()
From: Frank.Li @ 2026-06-24 17:00 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Laurent Pinchart,
Heiko Stuebner, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain
Cc: driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624-fw_scoped-v2-0-0a8db472af4a@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Similar to recently propose for_each_child_of_node_scoped() this new
version of the loop macro instantiates a new local struct fwnode_handle *
that uses the __free(fwnode_handle) auto cleanup handling so that if a
reference to a node is held on early exit from the loop the reference will
be released. If the loop runs to completion, the child pointer will be NULL
and no action will be taken.
The reason this is useful is that it removes the need for
fwnode_handle_put() on early loop exits. If there is a need to retain the
reference, then return_ptr(child) or no_free_ptr(child) may be used to
safely disable the auto cleanup.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- collect Andy and Guoniu's reviewed-by tags
- fix indention
- remove extra space in commit message
---
include/linux/property.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/property.h b/include/linux/property.h
index 14c304db46648..d51824c13d2cc 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -545,6 +545,11 @@ unsigned int fwnode_graph_get_endpoint_count(const struct fwnode_handle *fwnode,
for (child = fwnode_graph_get_next_endpoint(fwnode, NULL); child; \
child = fwnode_graph_get_next_endpoint(fwnode, child))
+#define fwnode_graph_for_each_endpoint_scoped(fwnode, child) \
+ for (struct fwnode_handle *child __free(fwnode_handle) = \
+ fwnode_graph_get_next_endpoint(fwnode, NULL); \
+ child; child = fwnode_graph_get_next_endpoint(fwnode, child))
+
int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
struct fwnode_endpoint *endpoint);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Conor Dooley @ 2026-06-24 16:41 UTC (permalink / raw)
To: Nas Chung
Cc: mchehab, hverkuil, robh, krzk+dt, conor+dt, shawnguo, s.hauer,
linux-media, devicetree, linux-kernel, linux-imx,
linux-arm-kernel, jackson.lee, lafley.kim, marek.vasut
In-Reply-To: <20260624072043.238-3-nas.chung@chipsnmedia.com>
[-- Attachment #1: Type: text/plain, Size: 6900 bytes --]
On Wed, Jun 24, 2026 at 04:20:36PM +0900, Nas Chung wrote:
> Add documentation for the Chips&Media Wave6 video codec on NXP i.MX SoCs.
>
> The hardware contains one control register region and four interface
> register regions for a shared video processing engine. The control region
> manages shared resources such as firmware memory, while each interface
> region has its own MMIO range and interrupt.
>
> The control region and each interface region are distinct DMA requesters
> and can be associated with separate IOMMU stream IDs. Represent the
> control region as the parent node and the interface register regions as
> child nodes to describe these resources.
>
> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> ---
> .../bindings/media/nxp,imx95-vpu.yaml | 163 ++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 170 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
> new file mode 100644
> index 000000000000..9a5ca53e15a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
> @@ -0,0 +1,163 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/nxp,imx95-vpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Chips&Media Wave6 Series multi-standard codec IP on NXP i.MX SoCs
> +
> +maintainers:
> + - Nas Chung <nas.chung@chipsnmedia.com>
> + - Jackson Lee <jackson.lee@chipsnmedia.com>
> +
> +description:
> + The Chips&Media Wave6 codec IP is a multi-standard video encoder/decoder.
> + On NXP i.MX SoCs, the Wave6 codec IP exposes one control register region and
> + four interface register regions for a shared video processing engine.
> + The parent node describes the control region, which has its own MMIO range and
> + manages shared resources such as firmware memory. The child nodes describe the
> + interface register regions. Each interface region has its own MMIO range and
> + interrupt.
> + The control region and the interface regions are distinct DMA requesters.
> + The control region and each interface region can be associated with separate
> + IOMMU stream IDs, allowing DMA isolation between them.
> +
> +properties:
> + compatible:
> + enum:
> + - nxp,imx95-vpu
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: VPU core clock
> + - description: VPU associated block clock
> +
> + clock-names:
> + items:
> + - const: core
> + - const: vpublk
> +
> + power-domains:
> + items:
> + - description: Main VPU power domain
> + - description: Performance power domain
> +
> + power-domain-names:
> + items:
> + - const: vpu
> + - const: perf
> +
> + memory-region:
> + maxItems: 1
> +
> + sram:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + phandle to the SRAM node used to store reference data, reducing DMA
> + memory bandwidth.
> +
> + iommus:
> + maxItems: 1
> +
> + "#cooling-cells":
> + const: 2
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 2
> +
> + ranges: true
> +
> +patternProperties:
> + "^interface@[0-9a-f]+$":
I have to wonder if this interface business is required at all.
Why can this not go into the parent, with each region fetchable via
reg-names, interrupt-names and iommu-names?
Cheers,
Conor.
> + type: object
> + description:
> + An interface register region within the Chips&Media Wave6 codec IP.
> + Each region has its own MMIO range and interrupt and can be associated
> + with a separate IOMMU stream ID for DMA isolation.
> + additionalProperties: false
> +
> + properties:
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + iommus:
> + maxItems: 1
> +
> + required:
> + - reg
> + - interrupts
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - power-domains
> + - power-domain-names
> + - memory-region
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/nxp,imx95-clock.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + video-codec@4c4c0000 {
> + compatible = "nxp,imx95-vpu";
> + reg = <0x0 0x4c4c0000 0x0 0x10000>;
> + clocks = <&scmi_clk 115>,
> + <&vpu_blk_ctrl IMX95_CLK_VPUBLK_WAVE>;
> + clock-names = "core", "vpublk";
> + power-domains = <&scmi_devpd 21>,
> + <&scmi_perf 10>;
> + power-domain-names = "vpu", "perf";
> + memory-region = <&vpu_boot>;
> + sram = <&sram1>;
> + iommus = <&smmu 0x32>;
> + #cooling-cells = <2>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + interface@4c480000 {
> + reg = <0x0 0x4c480000 0x0 0x10000>;
> + interrupts = <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&smmu 0x33>;
> + };
> +
> + interface@4c490000 {
> + reg = <0x0 0x4c490000 0x0 0x10000>;
> + interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&smmu 0x34>;
> + };
> +
> + interface@4c4a0000 {
> + reg = <0x0 0x4c4a0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 301 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&smmu 0x35>;
> + };
> +
> + interface@4c4b0000 {
> + reg = <0x0 0x4c4b0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&smmu 0x36>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index efbf808063e5..77ea3a1a966b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -28688,6 +28688,13 @@ S: Maintained
> F: Documentation/devicetree/bindings/media/cnm,wave521c.yaml
> F: drivers/media/platform/chips-media/wave5/
>
> +WAVE6 VPU CODEC DRIVER
> +M: Nas Chung <nas.chung@chipsnmedia.com>
> +M: Jackson Lee <jackson.lee@chipsnmedia.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
> +
> WHISKEYCOVE PMIC GPIO DRIVER
> M: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> L: linux-gpio@vger.kernel.org
> --
> 2.31.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: vendor-prefixes: add alientek
From: Conor Dooley @ 2026-06-24 16:38 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-1-5aef608a3f64@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: arm: rockchip: Add Alientek DLRV1126
From: Conor Dooley @ 2026-06-24 16:37 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-2-5aef608a3f64@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: net: rockchip-dwmac: Allow 9 clocks
From: Conor Dooley @ 2026-06-24 16:37 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-3-5aef608a3f64@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 64 bytes --]
Per Heiko's comments,
pw-bot: changes-requested
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: axiado: add AX3005 EVK
From: Conor Dooley @ 2026-06-24 16:36 UTC (permalink / raw)
To: Swark Yang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260624-upstream-axiado-ax3005-upstream-v1-1-c05bd0bc9124@axiado.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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