[PATCH v3 0/2] device property: fix child iteration issues with secondary fwnodes

[PATCH v3 0/2] device property: fix child iteration issues with secondary fwnodes

[Xu Yang]

This series fixes two issues in the fwnode child iteration logic when
a secondary fwnode is present.

The first issue is  a refcount imbalance in software_node_get_next_child().
When a software node is used as a secondary fwnode, the iteration code may
incorrectly decrement the refcount of child nodes that do not belong to the
software node hierarchy. This results in refcount underflow and possible
use-after-free.

The second issue is an infinite loop in fwnode_for_each_child_node(), caused
by improper handling of iteration state across primary and secondary fwnodes.
When iterating over children from both primary and secondary fwnodes, the code
may incorrectly resume iteration from the primary fwnode even when the current
child belongs to the secondary, leading to repeated traversal and a loop.

Both issues are triggered when mixing different fwnode types through the
secondary mechanism, and stem from incorrect assumptions about ownership
and traversal context of child nodes.

---
Changes in v3:
- remove software node patch 
- add a kunit test case suggested by Andy Shevchenko
- Link to v2: https://patch.msgid.link/20260603-fixes_fwnode_iteration-v2-0-0ae381f8b7b9@nxp.com

Changes in v2:
- use __free() to cleanup parent fwnode
- Link to v1: https://lore.kernel.org/r/20260525-fixes_fwnode_iteration-v1-0-a12903fb2919@nxp.com

To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Daniel Scally <djrscally@gmail.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
To: Danilo Krummrich <dakr@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: driver-core@lists.linux.dev
Cc: linux-kernel@vger.kernel.org

---
Xu Yang (2):
      device property: fix infinite loop in fwnode_for_each_child_node()
      drivers: base: test: add test cases for fwnode_for_each_child_node()

 drivers/base/property.c                 |  18 ++++-
 drivers/base/test/Kconfig               |   1 +
 drivers/base/test/property-entry-test.c | 136 ++++++++++++++++++++++++++++++++
 3 files changed, 152 insertions(+), 3 deletions(-)
---
base-commit: b7bee4ca5688e30ca50fbc87b1b8f7eed7006c17
change-id: 20260525-fixes_fwnode_iteration-baf62d861305

Best regards,
--  
Xu Yang <xu.yang_2@nxp.com>

[PATCH v3 1/2] device property: fix infinite loop in fwnode_for_each_child_node()

[Xu Yang]

From: Xu Yang <xu.yang_2@nxp.com>

When iterate over children of a fwnode that has a secondary fwnode,
fwnode_get_next_child_node() can enter an infinite loop if the secondary
fwnode has more than one child.

                       Parent        Child
      (Primary fwnode)   FWa:   {FWa1, FWa2, FWa3}
    (Secondary fwnode)   FWb:   {FWb1, FWb2}

In this case:

 ┌─> fwnode_get_next_child_node(FWa, FWa1)
 │    - fwnode_call_ptr_op(FWa, get_next_child_node, FWa1) returns FWa2
 │
 │   ...
 │
 │   fwnode_get_next_child_node(FWa, FWa3)
 │    - fwnode_call_ptr_op(FWa, get_next_child_node, FWa3) returns NULL
 │    - fwnode_call_ptr_op(FWb, get_next_child_node, FWa3) returns FWb1
 │
 │   fwnode_get_next_child_node(FWa, FWb1)
 │    - fwnode_call_ptr_op(FWa, get_next_child_node, FWb1) returns FWa1
 └────┘

This cause fwnode_for_each_child_node() to loop indefinitely, reapeatedly
output {FWa1, FWa2, FWa3, FWb1, FWa1, ...}.

The root cause is that when the current child (FWb1) belongs to the
secondary fwnode, calling get_next_child_node() on the parimary fwnode
incorrectly returns the first child (FWa1) again instead of NULL.

Fix this by dynamically checking the parent fwnode of the current child
before calling get_next_child_node(). This approach follows the pattern
established in commit b5b41ab6b0c1 ("device property: Check
fwnode->secondary in fwnode_graph_get_next_endpoint()").

Fixes: 2692c614f8f0 ("device property: Allow secondary lookup in fwnode_get_next_child_node()")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

---
Changes in v3:
 - remove previous softnode patch as the refcount leak issue can be
   fixed by this one
Changes in v2:
 - use __free() to put parent fwnode
---
 drivers/base/property.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index e08eadd66f4f..f51087065bf6 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -808,17 +808,29 @@ fwnode_get_next_child_node(const struct fwnode_handle *fwnode,
 			   struct fwnode_handle *child)
 {
 	struct fwnode_handle *next;
+	const struct fwnode_handle *parent;
+	struct fwnode_handle *child_parent __free(fwnode_handle) = NULL;
 
 	if (IS_ERR_OR_NULL(fwnode))
 		return NULL;
+	/*
+	 * If this function is in a loop and the previous iteration returned
+	 * an child from fwnode->secondary, then we need to use the secondary
+	 * as parent rather than @fwnode.
+	 */
+	if (child) {
+		child_parent = fwnode_get_parent(child);
+		parent = child_parent;
+	} else {
+		parent = fwnode;
+	}
 
-	/* Try to find a child in primary fwnode */
-	next = fwnode_call_ptr_op(fwnode, get_next_child_node, child);
+	next = fwnode_call_ptr_op(parent, get_next_child_node, child);
 	if (next)
 		return next;
 
 	/* When no more children in primary, continue with secondary */
-	return fwnode_call_ptr_op(fwnode->secondary, get_next_child_node, child);
+	return fwnode_call_ptr_op(parent->secondary, get_next_child_node, NULL);
 }
 EXPORT_SYMBOL_GPL(fwnode_get_next_child_node);
 

-- 
2.34.1

[PATCH v3 2/2] drivers: base: test: add test cases for fwnode_for_each_child_node()

[Xu Yang]

From: Xu Yang <xu.yang_2@nxp.com>

Add test cases for fwnode_for_each_child_node() API.

Test command:
$ ./tools/testing/kunit/kunit.py run property-entry

Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

---
Changes in v3:
 - new patch
---
 drivers/base/test/Kconfig               |   1 +
 drivers/base/test/property-entry-test.c | 136 ++++++++++++++++++++++++++++++++
 2 files changed, 137 insertions(+)

diff --git a/drivers/base/test/Kconfig b/drivers/base/test/Kconfig
index 2756870615cc..95fc42e91564 100644
--- a/drivers/base/test/Kconfig
+++ b/drivers/base/test/Kconfig
@@ -17,4 +17,5 @@ config DM_KUNIT_TEST
 config DRIVER_PE_KUNIT_TEST
 	tristate "KUnit Tests for property entry API" if !KUNIT_ALL_TESTS
 	depends on KUNIT
+	select OF
 	default KUNIT_ALL_TESTS
diff --git a/drivers/base/test/property-entry-test.c b/drivers/base/test/property-entry-test.c
index a8657eb06f94..d100cd6c17e8 100644
--- a/drivers/base/test/property-entry-test.c
+++ b/drivers/base/test/property-entry-test.c
@@ -6,6 +6,7 @@
 #include <kunit/test.h>
 #include <linux/property.h>
 #include <linux/types.h>
+#include <linux/of.h>
 
 static void pe_test_uints(struct kunit *test)
 {
@@ -489,6 +490,140 @@ static void pe_test_reference(struct kunit *test)
 	software_node_unregister_node_group(group);
 }
 
+static struct fwnode_handle *create_device_node(struct kunit *test,
+						const char *name,
+						const char *full_name,
+						struct device_node *parent)
+{
+	struct device_node *node;
+
+	node = kunit_kzalloc(test, sizeof(*node), GFP_KERNEL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, node);
+
+	node->name = kunit_kstrdup(test, name, GFP_KERNEL);
+	node->full_name = kunit_kstrdup(test, full_name, GFP_KERNEL);
+
+	if (parent) {
+		node->sibling = parent->child;
+		/* set the node as the first child of the parent */
+		parent->child = node;
+		node->parent = parent;
+	}
+
+	of_node_init(node);
+	return of_fwnode_handle(node);
+}
+
+/* Verifies that fwnode_for_each_child_node() can output correct children */
+static void pe_test_child_iteration(struct kunit *test)
+{
+	struct fwnode_handle *of_node, *of_node1;
+	struct fwnode_handle *sw_node, *sw_node1;
+	struct fwnode_handle *child;
+	int error, i, num;
+
+	static const struct software_node node = { .name = "sw" };
+	static const struct software_node node1 = { .name = "sw-1", .parent = &node};
+	static const struct software_node node2 = { .name = "sw-2", .parent = &node};
+	static const struct software_node node3 = { .name = "sw-3", .parent = &node};
+	static const struct software_node *group[] = { &node, &node1, &node2, &node3, NULL };
+
+	static const char * const of_child_array[] = { "of-1", "of-2", "of-3" };
+	static const char * const sw_child_array[] = { "sw-1", "sw-2", "sw-3" };
+	static const char * const of_sw_child_array[] = { "of-1", "of-2", "of-3",
+							  "sw-1", "sw-2", "sw-3" };
+	static const char * const sw_of_child_array[] = { "sw-1", "sw-2", "sw-3",
+							  "of-1", "of-2", "of-3" };
+
+	/* 1. Test OF node child iteration */
+
+	of_node = create_device_node(test, "of", "of", NULL);
+	create_device_node(test, "of", "of-3", to_of_node(of_node));
+	create_device_node(test, "of", "of-2", to_of_node(of_node));
+	of_node1 = create_device_node(test, "of", "of-1", to_of_node(of_node));
+
+	i = 0;
+	num = ARRAY_SIZE(of_child_array);
+	fwnode_for_each_child_node(of_node, child) {
+		KUNIT_ASSERT_LT(test, i, num);
+		KUNIT_EXPECT_STREQ(test, of_child_array[i++], fwnode_get_name(child));
+	}
+	KUNIT_EXPECT_PTR_EQ(test, child, NULL);
+
+	/* 2. Test SW node child iteration */
+
+	error = software_node_register_node_group(group);
+	KUNIT_ASSERT_EQ(test, error, 0);
+
+	sw_node = software_node_fwnode(&node);
+
+	i = 0;
+	num = ARRAY_SIZE(sw_child_array);
+	fwnode_for_each_child_node(sw_node, child) {
+		KUNIT_ASSERT_LT(test, i, num);
+		KUNIT_EXPECT_STREQ(test, sw_child_array[i++], fwnode_get_name(child));
+	}
+	KUNIT_EXPECT_PTR_EQ(test, child, NULL);
+
+	/* 3. Test OF (primary) + SW (secondary) node child iteration */
+
+	of_node->secondary = sw_node;
+
+	i = 0;
+	num = ARRAY_SIZE(of_sw_child_array);
+	fwnode_for_each_child_node(of_node, child) {
+		KUNIT_ASSERT_LT(test, i, num);
+		KUNIT_EXPECT_STREQ(test, of_sw_child_array[i++], fwnode_get_name(child));
+	}
+	KUNIT_EXPECT_PTR_EQ(test, child, NULL);
+
+	of_node->secondary = NULL;
+
+	/* 4. Test SW (primary) + OF (secondary) node child iteration */
+
+	sw_node->secondary = of_node;
+
+	i = 0;
+	num = ARRAY_SIZE(sw_of_child_array);
+	fwnode_for_each_child_node(sw_node, child) {
+		KUNIT_ASSERT_LT(test, i, num);
+		KUNIT_EXPECT_STREQ(test, sw_of_child_array[i++], fwnode_get_name(child));
+	}
+	KUNIT_EXPECT_PTR_EQ(test, child, NULL);
+
+	sw_node->secondary = NULL;
+
+	/* 5. Test OF (primary) + SW (secondary, but no children) node child iteration */
+
+	sw_node1 = software_node_fwnode(&node1);
+	of_node->secondary = sw_node1;
+
+	i = 0;
+	num = ARRAY_SIZE(of_child_array);
+	fwnode_for_each_child_node(of_node, child) {
+		KUNIT_ASSERT_LT(test, i, num);
+		KUNIT_EXPECT_STREQ(test, of_child_array[i++], fwnode_get_name(child));
+	}
+	KUNIT_EXPECT_PTR_EQ(test, child, NULL);
+
+	of_node->secondary = NULL;
+
+	/* 6. Test SW (primary) + OF (secondary, but no children) node child iteration */
+
+	sw_node->secondary = of_node1;
+
+	i = 0;
+	num = ARRAY_SIZE(sw_child_array);
+	fwnode_for_each_child_node(sw_node, child) {
+		KUNIT_ASSERT_LT(test, i, num);
+		KUNIT_EXPECT_STREQ(test, sw_child_array[i++], fwnode_get_name(child));
+	}
+	KUNIT_EXPECT_PTR_EQ(test, child, NULL);
+
+	sw_node->secondary = NULL;
+	software_node_unregister_node_group(group);
+}
+
 static struct kunit_case property_entry_test_cases[] = {
 	KUNIT_CASE(pe_test_uints),
 	KUNIT_CASE(pe_test_uint_arrays),
@@ -497,6 +632,7 @@ static struct kunit_case property_entry_test_cases[] = {
 	KUNIT_CASE(pe_test_move_inline_u8),
 	KUNIT_CASE(pe_test_move_inline_str),
 	KUNIT_CASE(pe_test_reference),
+	KUNIT_CASE(pe_test_child_iteration),
 	{ }
 };
 

-- 
2.34.1

Re: [PATCH v3 0/2] device property: fix child iteration issues with secondary fwnodes

[Andy Shevchenko]

On Fri, Jun 05, 2026 at 06:31:16PM +0800, Xu Yang wrote:
> This series fixes two issues in the fwnode child iteration logic when
> a secondary fwnode is present.
> 
> The first issue is  a refcount imbalance in software_node_get_next_child().
> When a software node is used as a secondary fwnode, the iteration code may
> incorrectly decrement the refcount of child nodes that do not belong to the
> software node hierarchy. This results in refcount underflow and possible
> use-after-free.
> 
> The second issue is an infinite loop in fwnode_for_each_child_node(), caused
> by improper handling of iteration state across primary and secondary fwnodes.
> When iterating over children from both primary and secondary fwnodes, the code
> may incorrectly resume iteration from the primary fwnode even when the current
> child belongs to the secondary, leading to repeated traversal and a loop.
> 
> Both issues are triggered when mixing different fwnode types through the
> secondary mechanism, and stem from incorrect assumptions about ownership
> and traversal context of child nodes.

> ---
> Changes in v3:
> - remove software node patch 

Hmm... Maybe I was unclear. My question was to investigate the way to actually
move software node to use the swnode APIs (and not fwnode ones) and be on par
with what OF code does. This series does the opposite and adds a hack to the
next_child implementation.

> - add a kunit test case suggested by Andy Shevchenko

But thanks for the test case!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 0/2] device property: fix child iteration issues with secondary fwnodes

[Andy Shevchenko]

On Fri, Jun 05, 2026 at 06:07:41PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 05, 2026 at 06:31:16PM +0800, Xu Yang wrote:
> > This series fixes two issues in the fwnode child iteration logic when
> > a secondary fwnode is present.
> > 
> > The first issue is  a refcount imbalance in software_node_get_next_child().
> > When a software node is used as a secondary fwnode, the iteration code may
> > incorrectly decrement the refcount of child nodes that do not belong to the
> > software node hierarchy. This results in refcount underflow and possible
> > use-after-free.
> > 
> > The second issue is an infinite loop in fwnode_for_each_child_node(), caused
> > by improper handling of iteration state across primary and secondary fwnodes.
> > When iterating over children from both primary and secondary fwnodes, the code
> > may incorrectly resume iteration from the primary fwnode even when the current
> > child belongs to the secondary, leading to repeated traversal and a loop.
> > 
> > Both issues are triggered when mixing different fwnode types through the
> > secondary mechanism, and stem from incorrect assumptions about ownership
> > and traversal context of child nodes.
> 
> > ---
> > Changes in v3:
> > - remove software node patch 
> 
> Hmm... Maybe I was unclear. My question was to investigate the way to actually
> move software node to use the swnode APIs (and not fwnode ones) and be on par
> with what OF code does. This series does the opposite and adds a hack to the
> next_child implementation.
> 
> > - add a kunit test case suggested by Andy Shevchenko
> 
> But thanks for the test case!

I'm preparing another patch (just a clean up) and I see that your test cases
indeed fail without any other patch being applied. Also noticed that the test
cases are not fully compliant with the requirement of the "primary"/"secondary"
fwnode flavours. But this doesn't affect the execution.

I will play more with this to understand the problem better.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 0/2] device property: fix child iteration issues with secondary fwnodes

[Xu Yang]

On Fri, Jun 05, 2026 at 06:52:49PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 05, 2026 at 06:07:41PM +0300, Andy Shevchenko wrote:
> > On Fri, Jun 05, 2026 at 06:31:16PM +0800, Xu Yang wrote:
> > > This series fixes two issues in the fwnode child iteration logic when
> > > a secondary fwnode is present.
> > > 
> > > The first issue is  a refcount imbalance in software_node_get_next_child().
> > > When a software node is used as a secondary fwnode, the iteration code may
> > > incorrectly decrement the refcount of child nodes that do not belong to the
> > > software node hierarchy. This results in refcount underflow and possible
> > > use-after-free.
> > > 
> > > The second issue is an infinite loop in fwnode_for_each_child_node(), caused
> > > by improper handling of iteration state across primary and secondary fwnodes.
> > > When iterating over children from both primary and secondary fwnodes, the code
> > > may incorrectly resume iteration from the primary fwnode even when the current
> > > child belongs to the secondary, leading to repeated traversal and a loop.
> > > 
> > > Both issues are triggered when mixing different fwnode types through the
> > > secondary mechanism, and stem from incorrect assumptions about ownership
> > > and traversal context of child nodes.
> > 
> > > ---
> > > Changes in v3:
> > > - remove software node patch 
> > 
> > Hmm... Maybe I was unclear. My question was to investigate the way to actually
> > move software node to use the swnode APIs (and not fwnode ones) and be on par
> > with what OF code does. This series does the opposite and adds a hack to the
> > next_child implementation.
> > 
> > > - add a kunit test case suggested by Andy Shevchenko
> > 
> > But thanks for the test case!
> 
> I'm preparing another patch (just a clean up) and I see that your test cases
> indeed fail without any other patch being applied. Also noticed that the test
> cases are not fully compliant with the requirement of the "primary"/"secondary"
> fwnode flavours. But this doesn't affect the execution.
> 
> I will play more with this to understand the problem better.

OK. Suggestions on the fwnode flavours would be appreciated :)

Thanks,
Xu Yang

Re: [PATCH v3 0/2] device property: fix child iteration issues with secondary fwnodes

[Andy Shevchenko]

On Mon, Jun 08, 2026 at 10:41:45AM +0800, Xu Yang wrote:
> On Fri, Jun 05, 2026 at 06:52:49PM +0300, Andy Shevchenko wrote:
> > On Fri, Jun 05, 2026 at 06:07:41PM +0300, Andy Shevchenko wrote:
> > > On Fri, Jun 05, 2026 at 06:31:16PM +0800, Xu Yang wrote:
> > > > This series fixes two issues in the fwnode child iteration logic when
> > > > a secondary fwnode is present.
> > > > 
> > > > The first issue is  a refcount imbalance in software_node_get_next_child().
> > > > When a software node is used as a secondary fwnode, the iteration code may
> > > > incorrectly decrement the refcount of child nodes that do not belong to the
> > > > software node hierarchy. This results in refcount underflow and possible
> > > > use-after-free.
> > > > 
> > > > The second issue is an infinite loop in fwnode_for_each_child_node(), caused
> > > > by improper handling of iteration state across primary and secondary fwnodes.
> > > > When iterating over children from both primary and secondary fwnodes, the code
> > > > may incorrectly resume iteration from the primary fwnode even when the current
> > > > child belongs to the secondary, leading to repeated traversal and a loop.
> > > > 
> > > > Both issues are triggered when mixing different fwnode types through the
> > > > secondary mechanism, and stem from incorrect assumptions about ownership
> > > > and traversal context of child nodes.
> > > 
> > > > ---
> > > > Changes in v3:
> > > > - remove software node patch 
> > > 
> > > Hmm... Maybe I was unclear. My question was to investigate the way to actually
> > > move software node to use the swnode APIs (and not fwnode ones) and be on par
> > > with what OF code does. This series does the opposite and adds a hack to the
> > > next_child implementation.
> > > 
> > > > - add a kunit test case suggested by Andy Shevchenko
> > > 
> > > But thanks for the test case!
> > 
> > I'm preparing another patch (just a clean up) and I see that your test cases
> > indeed fail without any other patch being applied. Also noticed that the test
> > cases are not fully compliant with the requirement of the "primary"/"secondary"
> > fwnode flavours. But this doesn't affect the execution.
> > 
> > I will play more with this to understand the problem better.
> 
> OK. Suggestions on the fwnode flavours would be appreciated :)

I think your approach is what we should go with. I will send a v4 with my tags
and some amendments.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 0/2] device property: fix child iteration issues with secondary fwnodes

[Andy Shevchenko]

On Thu, Jun 11, 2026 at 11:04:25AM +0300, Andy Shevchenko wrote:
> On Mon, Jun 08, 2026 at 10:41:45AM +0800, Xu Yang wrote:
> > On Fri, Jun 05, 2026 at 06:52:49PM +0300, Andy Shevchenko wrote:
> > > On Fri, Jun 05, 2026 at 06:07:41PM +0300, Andy Shevchenko wrote:
> > > > On Fri, Jun 05, 2026 at 06:31:16PM +0800, Xu Yang wrote:
> > > > > This series fixes two issues in the fwnode child iteration logic when
> > > > > a secondary fwnode is present.
> > > > > 
> > > > > The first issue is  a refcount imbalance in software_node_get_next_child().
> > > > > When a software node is used as a secondary fwnode, the iteration code may
> > > > > incorrectly decrement the refcount of child nodes that do not belong to the
> > > > > software node hierarchy. This results in refcount underflow and possible
> > > > > use-after-free.
> > > > > 
> > > > > The second issue is an infinite loop in fwnode_for_each_child_node(), caused
> > > > > by improper handling of iteration state across primary and secondary fwnodes.
> > > > > When iterating over children from both primary and secondary fwnodes, the code
> > > > > may incorrectly resume iteration from the primary fwnode even when the current
> > > > > child belongs to the secondary, leading to repeated traversal and a loop.
> > > > > 
> > > > > Both issues are triggered when mixing different fwnode types through the
> > > > > secondary mechanism, and stem from incorrect assumptions about ownership
> > > > > and traversal context of child nodes.
> > > > 
> > > > > ---
> > > > > Changes in v3:
> > > > > - remove software node patch 
> > > > 
> > > > Hmm... Maybe I was unclear. My question was to investigate the way to actually
> > > > move software node to use the swnode APIs (and not fwnode ones) and be on par
> > > > with what OF code does. This series does the opposite and adds a hack to the
> > > > next_child implementation.
> > > > 
> > > > > - add a kunit test case suggested by Andy Shevchenko
> > > > 
> > > > But thanks for the test case!
> > > 
> > > I'm preparing another patch (just a clean up) and I see that your test cases
> > > indeed fail without any other patch being applied. Also noticed that the test
> > > cases are not fully compliant with the requirement of the "primary"/"secondary"
> > > fwnode flavours. But this doesn't affect the execution.
> > > 
> > > I will play more with this to understand the problem better.
> > 
> > OK. Suggestions on the fwnode flavours would be appreciated :)
> 
> I think your approach is what we should go with. I will send a v4 with my tags
> and some amendments.

I sent a v4 here:
20260611203537.1786399-1-andriy.shevchenko@linux.intel.com
Please, test and confirm it also works for you as expected.

-- 
With Best Regards,
Andy Shevchenko