mfd: core: Preserve OF node when ACPI handle is present
Subsystems (2)
PATCH v2 1/1 mfd: core: Preserve OF node when ACPI handle is present
Switch device_set_node to set_primary_fwnode, so that the ACPI fwnode does not overwrite the of_node with NULL.
This allows MFD children with both OF nodes and ACPI handles to have OF nodes again.
--- drivers/mfd/mfd-core.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
drivers/mfd/mfd-core.c +14 -1
@@ -88,7 +88,20 @@ static void mfd_acpi_add_device(const struct mfd_cell *cell, } } -device_set_node (&pdev->dev,acpi_fwnode_handle (adev ?: parent)); +/* +* FIXME: The fwnode design doesn't allow proper stacking/sharing. This +* should eventually turn into a device fwnode API call that will allow +* prepending to a list of fwnodes (with ACPI taking precedence). +* +* set_primary_fwnode() is used here, instead of device_set_node(), as +* device_set_node() will overwrite the existing fwnode, which may be an +* OF node that was populated earlier. To support a use case where ACPI +* and OF is used in conjunction, we call set_primary_fwnode() instead. +*/ +if (adev) +set_primary_fwnode (&pdev->dev,acpi_fwnode_handle (adev)); +else +set_primary_fwnode (&pdev->dev,acpi_fwnode_handle (parent)); }#else static inline void mfd_acpi_add_device(const struct mfd_cell *cell,
base-commit: d9d32e5bd5a4e57675f2b70ddf73c3dc5cf44fc2
Signature · 1 line
2.25.1
Quoted 5 lines · Brian Mak
Switch
device_set_nodetoset_primary_fwnode, so that the ACPI fwnode does not overwrite theof_nodewith NULL.This allows MFD children with both OF nodes and ACPI handles to have OF nodes again.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Lee Jones
maintainerQuoted 18 lines · Brian Mak
Switch
device_set_nodetoset_primary_fwnode, so that the ACPI fwnode does not overwrite theof_nodewith NULL.This allows MFD children with both OF nodes and ACPI handles to have OF nodes again.
Fixes 51e3b257099d ("mfd: core: Make use of device_set_node()")Signed-off-by Brian Mak <[email protected]>--- drivers/mfd/mfd-core.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)drivers/mfd/mfd-core.c +0
-0
drivers/mfd/mfd-core.c static void mfd_acpi_add_device(const struct mfd_cell *cell, · line 92
Quoted 6 lines
drivers/mfd/mfd-core.c +2
-1@@ -88,7 +88,20 @@ static void mfd_acpi_add_device(const struct mfd_cell *cell, } } -device_set_node (&pdev->dev,acpi_fwnode_handle (adev ?: parent)); +/* +* FIXME: The fwnode design doesn't allow proper stacking/sharing. This
So when will this be fixed exactly?
Quoted 20 lines
drivers/mfd/mfd-core.c +12
-0+* should eventually turn into a device fwnode API call that will allow +* prepending to a list of fwnodes (with ACPI taking precedence). +* +* set_primary_fwnode() is used here, instead of device_set_node(), as +* device_set_node() will overwrite the existing fwnode, which may be an +* OF node that was populated earlier. To support a use case where ACPI +* and OF is used in conjunction, we call set_primary_fwnode() instead. +*/ +if (adev) +set_primary_fwnode (&pdev->dev,acpi_fwnode_handle (adev)); +else +set_primary_fwnode (&pdev->dev,acpi_fwnode_handle (parent)); }#else static inline void mfd_acpi_add_device(const struct mfd_cell *cell,base-commit:
d9d32e5bd5a4e57675f2b70ddf73c3dc5cf44fc2Signature · 1 line
2.25.1
Signature · 1 line
Lee Jones [李琼斯]
Quoted 1 line · Lee Jones
On Thu, 26 Feb 2026, Brian Mak wrote:
...
Quoted 4 lines
drivers/mfd/mfd-core.c static void mfd_acpi_add_device(const struct mfd_cell *cell, · line 92
Quoted 2 lines
drivers/mfd/mfd-core.c +2
-0+/* +* FIXME: The fwnode design doesn't allow proper stacking/sharing. This So when will this be fixed exactly?
I don't know, it's a huge task that requires of redesigning how struct fwnode_handle looks like and how it cohabits with struct device. Do you you think that NOTE will be more appropriate, because it may span several releases.
Quoted 13 lines
Quoted 13 lines
drivers/mfd/mfd-core.c +12
-0+* should eventually turn into a device fwnode API call that will allow +* prepending to a list of fwnodes (with ACPI taking precedence). +* +* set_primary_fwnode() is used here, instead of device_set_node(), as +* device_set_node() will overwrite the existing fwnode, which may be an +* OF node that was populated earlier. To support a use case where ACPI +* and OF is used in conjunction, we call set_primary_fwnode() instead. +*/ +if (adev) +set_primary_fwnode (&pdev->dev,acpi_fwnode_handle (adev)); +else +set_primary_fwnode (&pdev->dev,acpi_fwnode_handle (parent)); }
Signature · 2 lines
With Best Regards, Andy Shevchenko
Lee Jones
maintainerQuoted 10 lines · Andy Shevchenko
Quoted 1 line · Lee Jones
On Thu, 26 Feb 2026, Brian Mak wrote:
...
Quoted 4 lines
drivers/mfd/mfd-core.c static void mfd_acpi_add_device(const struct mfd_cell *cell, · line 92
Quoted 2 lines
drivers/mfd/mfd-core.c +2
-0+/* +* FIXME: The fwnode design doesn't allow proper stacking/sharing. This So when will this be fixed exactly?
Quoted 4 lines
I don't know, it's a huge task that requires of redesigning how struct
fwnode_handlelooks like and how it cohabits with struct device. Do you you think that NOTE will be more appropriate, because it may span several releases.
If someone is going to do the work sometime in the near future, it can stay as FIXME. A few releases isn't going to offend anyone. However, if we're just going to sit on it and this is likely to be here for an elongated period, it should be changed.
Any idea who is planning on working on it?
Signature · 1 line
Lee Jones [李琼斯]
Quoted 3 lines · Lee Jones
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Lee Jones
On Thu, 26 Feb 2026, Brian Mak wrote:
...
Quoted 10 lines
Quoted 9 lines
Quoted 4 lines
drivers/mfd/mfd-core.c static void mfd_acpi_add_device(const struct mfd_cell *cell, · line 92
Quoted 2 lines
drivers/mfd/mfd-core.c +2
-0+/* +* FIXME: The fwnode design doesn't allow proper stacking/sharing. This So when will this be fixed exactly?
I don't know, it's a huge task that requires of redesigning how struct
fwnode_handlelooks like and how it cohabits with struct device. Do you you think that NOTE will be more appropriate, because it may span several releases.
Quoted 4 lines
If someone is going to do the work sometime in the near future, it can stay as FIXME. A few releases isn't going to offend anyone. However, if we're just going to sit on it and this is likely to be here for an elongated period, it should be changed.
Then better to be just a NOTE:.
Quoted 1 line
Any idea who is planning on working on it?
I am not sure anyone is planning on working on this in the near future. We see the problem, but it hasn't hit someone's work too much to become a showstopper (some workarounds, or not fully correct, but acceptable behaviour was a way out so far).
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 9 lines · Andy Shevchenko
Quoted 1 line · Lee Jones
On Fri, 06 Mar 2026, Andy Shevchenko wrote:
...
Quoted 4 lines
If someone is going to do the work sometime in the near future, it can stay as FIXME. A few releases isn't going to offend anyone. However, if we're just going to sit on it and this is likely to be here for an elongated period, it should be changed.
Then better to be just a NOTE:.
Ok, should I raise a v3 patch, or can this just be changed when applied? I'm okay either way.
Thanks,
Brian
Quoted 3 lines · Brian Mak
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Lee Jones
On Fri, 06 Mar 2026, Andy Shevchenko wrote:
...
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
If someone is going to do the work sometime in the near future, it can stay as FIXME. A few releases isn't going to offend anyone. However, if we're just going to sit on it and this is likely to be here for an elongated period, it should be changed.
Then better to be just a NOTE:.
Ok, should I raise a v3 patch, or can this just be changed when applied? I'm okay either way.
It's better to have a v3 with a clear changelog why it has been changed (changelog, not part a commit message).
Signature · 2 lines
With Best Regards, Andy Shevchenko