[PATCH 0/2] x86/platform/geode: enable real fwnode GPIO lookup

[PATCH 0/2] x86/platform/geode: enable real fwnode GPIO lookup

[Bartosz Golaszewski]

GPIO software node lookup should rely exclusively on matching the
addresses of the referenced firmware nodes. I tried to enforce it with
commit e5d527be7e69 ("gpio: swnode: don't use the swnode's name as the
key for GPIO lookup") but it broke existing users who abuse the software
node mechanism by creating "dummy" software nodes named after the device
they want to get GPIOs from but never attaching them to the actual GPIO
devices. They rely on the current behavior of GPIOLIB where it will match
the label of the GPIO controller against the name of the software node
and does not require a true link.

In order to un-revert e5d527be7e69, we need to convert all existing
users to real firmware node lookup for software nodes.

This series exposes the software node associated with the GPIO
controller cell of the cs5535 MFD device and uses it in the geode board
setup for LEDs.

Merging strategy: there's not much development going on for the geode
board file so this could go through the MFD tree with an ack from the
x86 maintainers.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Bartosz Golaszewski (2):
      mfd: cs5535: add, assign and expose the software node for the GPIO cell
      x86/platform/geode: reference the real node of the cs5535 GPIO controller

 arch/x86/Kconfig                       | 10 +++++-----
 arch/x86/platform/geode/geode-common.c | 12 +++++-------
 drivers/mfd/cs5535-mfd.c               |  9 +++++++++
 include/linux/mfd/cs5535.h             |  8 ++++++++
 4 files changed, 27 insertions(+), 12 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260429-cs5535-swnode-0f731d2bbe10

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

[PATCH 1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell

[Bartosz Golaszewski]

There are board files in-tree that want to request GPIOs from this chip.
They currently rely on the GPIO core's mechanism of matching software
nodes' labels against GPIO controller names. We want to remove this
behavior from the kernel and to this end, we need to associate the
referenced GPIO controller with its target software node.

Create a dedicated GPIO software node for cs5535, assign it to the GPIO
cell and expose its address in a new header.

We only expose a single software node instance but that's alright: all
existing hardware only contains a single cs5535 companion and the geode
board file for which we expose this is legacy anyway.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/mfd/cs5535-mfd.c   | 9 +++++++++
 include/linux/mfd/cs5535.h | 8 ++++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/mfd/cs5535-mfd.c b/drivers/mfd/cs5535-mfd.c
index d0fb2e52ee76a82ab18f668f41b10ac3f4e01ed3..f3becbef19f5dac1905660df1ac6cbc4f7f4d867 100644
--- a/drivers/mfd/cs5535-mfd.c
+++ b/drivers/mfd/cs5535-mfd.c
@@ -12,8 +12,11 @@
 
 #include <linux/kernel.h>
 #include <linux/mfd/core.h>
+#include <linux/mfd/cs5535.h>
 #include <linux/module.h>
 #include <linux/pci.h>
+#include <linux/property.h>
+
 #include <asm/olpc.h>
 
 #define DRV_NAME "cs5535-mfd"
@@ -29,6 +32,11 @@ enum cs5535_mfd_bars {
 
 static struct resource cs5535_mfd_resources[NR_BARS];
 
+const struct software_node cs5535_gpio_swnode = {
+	.name = "cs5535-gpio",
+};
+EXPORT_SYMBOL_NS(cs5535_gpio_swnode, "CS5535");
+
 static struct mfd_cell cs5535_mfd_cells[] = {
 	{
 		.name = "cs5535-smb",
@@ -39,6 +47,7 @@ static struct mfd_cell cs5535_mfd_cells[] = {
 		.name = "cs5535-gpio",
 		.num_resources = 1,
 		.resources = &cs5535_mfd_resources[GPIO_BAR],
+		.swnode = &cs5535_gpio_swnode,
 	},
 	{
 		.name = "cs5535-mfgpt",
diff --git a/include/linux/mfd/cs5535.h b/include/linux/mfd/cs5535.h
new file mode 100644
index 0000000000000000000000000000000000000000..2e4ebf5d06af7453c417b3b5dda14572fb5e1ab2
--- /dev/null
+++ b/include/linux/mfd/cs5535.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __MFD_CS5535_H__
+#define __MFD_CS5535_H__
+
+extern const struct software_node cs5535_gpio_swnode;
+
+#endif /* __MFD_CS5535_H__ */

-- 
2.47.3

[PATCH 2/2] x86/platform/geode: reference the real node of the cs5535 GPIO controller

[Bartosz Golaszewski]

We now can access the address of the software node associated with the
GPIO controller cell of the cs5535 MFD device. Make it the target of the
GPIO software node references in geode-common.c. Make sure the cs5535
driver is built-in for all boards selecting GEODE_COMMON.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 arch/x86/Kconfig                       | 10 +++++-----
 arch/x86/platform/geode/geode-common.c | 12 +++++-------
 2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f3f7cb01d69d022538d283f6c7049ba8bd4c3792..1b3cb3d92bdeb0e02f249e1b4801f06fb5fd8648 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -3072,7 +3072,7 @@ config GEODE_COMMON
 
 config ALIX
 	bool "PCEngines ALIX System Support (LED setup)"
-	select GPIOLIB
+	depends on GPIO_CS5535=y
 	select GEODE_COMMON
 	help
 	  This option enables system support for the PCEngines ALIX.
@@ -3080,21 +3080,21 @@ config ALIX
 	  ALIX2/3/6 boards.  However, other system specific setup should
 	  get added here.
 
-	  Note: You must still enable the drivers for GPIO and LED support
-	  (GPIO_CS5535 & LEDS_GPIO) to actually use the LEDs
+	  Note: You must still enable the drivers for LED support (LEDS_GPIO)
+	  to actually use the LEDs
 
 	  Note: You have to set alix.force=1 for boards with Award BIOS.
 
 config NET5501
 	bool "Soekris Engineering net5501 System Support (LEDS, GPIO, etc)"
-	select GPIOLIB
+	depends on GPIO_CS5535=y
 	select GEODE_COMMON
 	help
 	  This option enables system support for the Soekris Engineering net5501.
 
 config GEOS
 	bool "Traverse Technologies GEOS System Support (LEDS, GPIO, etc)"
-	select GPIOLIB
+	depends on GPIO_CS5535=y
 	select GEODE_COMMON
 	depends on DMI
 	help
diff --git a/arch/x86/platform/geode/geode-common.c b/arch/x86/platform/geode/geode-common.c
index 1843ae385e2dc038fde6fb02f6de0b818e22d8dd..679b4b07b790db3ce1c06bd6639bba7516ca3f71 100644
--- a/arch/x86/platform/geode/geode-common.c
+++ b/arch/x86/platform/geode/geode-common.c
@@ -9,15 +9,12 @@
 #include <linux/gpio/property.h>
 #include <linux/input.h>
 #include <linux/leds.h>
+#include <linux/mfd/cs5535.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
 #include "geode-common.h"
 
-static const struct software_node geode_gpiochip_node = {
-	.name = "cs5535-gpio",
-};
-
 static const struct property_entry geode_gpio_keys_props[] = {
 	PROPERTY_ENTRY_U32("poll-interval", 20),
 	{ }
@@ -44,7 +41,6 @@ static const struct software_node geode_restart_key_node = {
 };
 
 static const struct software_node *geode_gpio_keys_swnodes[] __initconst = {
-	&geode_gpiochip_node,
 	&geode_gpio_keys_node,
 	&geode_restart_key_node,
 	NULL
@@ -66,7 +62,7 @@ int __init geode_create_restart_key(unsigned int pin)
 	struct platform_device *pd;
 	int err;
 
-	geode_restart_gpio_ref = SOFTWARE_NODE_REFERENCE(&geode_gpiochip_node,
+	geode_restart_gpio_ref = SOFTWARE_NODE_REFERENCE(&cs5535_gpio_swnode,
 							 pin, GPIO_ACTIVE_LOW);
 
 	err = software_node_register_node_group(geode_gpio_keys_swnodes);
@@ -143,7 +139,7 @@ int __init geode_create_leds(const char *label, const struct geode_led *leds,
 			goto err_free_names;
 		}
 
-		gpio_refs[i] = SOFTWARE_NODE_REFERENCE(&geode_gpiochip_node,
+		gpio_refs[i] = SOFTWARE_NODE_REFERENCE(&cs5535_gpio_swnode,
 						       leds[i].pin,
 						       GPIO_ACTIVE_LOW);
 		props[i * 3 + 0] =
@@ -188,3 +184,5 @@ int __init geode_create_leds(const char *label, const struct geode_led *leds,
 	kfree(swnodes);
 	return err;
 }
+
+MODULE_IMPORT_NS("CS5535");

-- 
2.47.3

Re: [PATCH 2/2] x86/platform/geode: reference the real node of the cs5535 GPIO controller

[Dmitry Torokhov]

On Wed, Apr 29, 2026 at 02:23:31PM +0200, Bartosz Golaszewski wrote:
> We now can access the address of the software node associated with the
> GPIO controller cell of the cs5535 MFD device. Make it the target of the
> GPIO software node references in geode-common.c. Make sure the cs5535
> driver is built-in for all boards selecting GEODE_COMMON.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
>  arch/x86/Kconfig                       | 10 +++++-----
>  arch/x86/platform/geode/geode-common.c | 12 +++++-------
>  2 files changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f3f7cb01d69d022538d283f6c7049ba8bd4c3792..1b3cb3d92bdeb0e02f249e1b4801f06fb5fd8648 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -3072,7 +3072,7 @@ config GEODE_COMMON
>  
>  config ALIX
>  	bool "PCEngines ALIX System Support (LED setup)"
> -	select GPIOLIB
> +	depends on GPIO_CS5535=y

This is really too bad... Did you abandon the work to implement
notifiers to allow attaching nodes after gpiochip driver loads?

Thanks.

-- 
Dmitry

Re: [PATCH 2/2] x86/platform/geode: reference the real node of the cs5535 GPIO controller

[Bartosz Golaszewski]

On Wed, Apr 29, 2026 at 9:06 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Wed, Apr 29, 2026 at 02:23:31PM +0200, Bartosz Golaszewski wrote:
> > We now can access the address of the software node associated with the
> > GPIO controller cell of the cs5535 MFD device. Make it the target of the
> > GPIO software node references in geode-common.c. Make sure the cs5535
> > driver is built-in for all boards selecting GEODE_COMMON.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > ---
> >  arch/x86/Kconfig                       | 10 +++++-----
> >  arch/x86/platform/geode/geode-common.c | 12 +++++-------
> >  2 files changed, 10 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index f3f7cb01d69d022538d283f6c7049ba8bd4c3792..1b3cb3d92bdeb0e02f249e1b4801f06fb5fd8648 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -3072,7 +3072,7 @@ config GEODE_COMMON
> >
> >  config ALIX
> >       bool "PCEngines ALIX System Support (LED setup)"
> > -     select GPIOLIB
> > +     depends on GPIO_CS5535=y
>
> This is really too bad... Did you abandon the work to implement
> notifiers to allow attaching nodes after gpiochip driver loads?
>

Yes, because it turned out, the notifiers are not really needed in the
android tablets driver as per Hans' comment and that was the only
potential user. Why is it bad? Other entries in this very Kconfig
already do depend on the same driver, see OLPC_XO1_SCI.

Bart

Re: (subset) [PATCH 1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell

[Lee Jones]

On Wed, 29 Apr 2026 14:23:30 +0200, Bartosz Golaszewski wrote:
> There are board files in-tree that want to request GPIOs from this chip.
> They currently rely on the GPIO core's mechanism of matching software
> nodes' labels against GPIO controller names. We want to remove this
> behavior from the kernel and to this end, we need to associate the
> referenced GPIO controller with its target software node.
> 
> Create a dedicated GPIO software node for cs5535, assign it to the GPIO
> cell and expose its address in a new header.
> 
> [...]

Applied, thanks!

[1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell
      commit: 2b640932f661c2fafde4cc9e38dbbfa9a79bc057

--
Lee Jones [李琼斯]

Re: (subset) [PATCH 1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell

[Bartosz Golaszewski]

On Thu, May 7, 2026 at 5:21 PM Lee Jones <lee@kernel.org> wrote:
>
> On Wed, 29 Apr 2026 14:23:30 +0200, Bartosz Golaszewski wrote:
> > There are board files in-tree that want to request GPIOs from this chip.
> > They currently rely on the GPIO core's mechanism of matching software
> > nodes' labels against GPIO controller names. We want to remove this
> > behavior from the kernel and to this end, we need to associate the
> > referenced GPIO controller with its target software node.
> >
> > Create a dedicated GPIO software node for cs5535, assign it to the GPIO
> > cell and expose its address in a new header.
> >
> > [...]
>
> Applied, thanks!
>
> [1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell
>       commit: 2b640932f661c2fafde4cc9e38dbbfa9a79bc057
>
> --
> Lee Jones [李琼斯]
>

Lee,

Can you please pick up both patches from this series or provide an
immutable branch for the x86 tree to be able to queue patch 2/2 from
this series?

Thanks in advance,
Bartosz

Re: (subset) [PATCH 1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell

[Lee Jones]

On Mon, 11 May 2026, Bartosz Golaszewski wrote:

> On Thu, May 7, 2026 at 5:21 PM Lee Jones <lee@kernel.org> wrote:
> >
> > On Wed, 29 Apr 2026 14:23:30 +0200, Bartosz Golaszewski wrote:
> > > There are board files in-tree that want to request GPIOs from this chip.
> > > They currently rely on the GPIO core's mechanism of matching software
> > > nodes' labels against GPIO controller names. We want to remove this
> > > behavior from the kernel and to this end, we need to associate the
> > > referenced GPIO controller with its target software node.
> > >
> > > Create a dedicated GPIO software node for cs5535, assign it to the GPIO
> > > cell and expose its address in a new header.
> > >
> > > [...]
> >
> > Applied, thanks!
> >
> > [1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell
> >       commit: 2b640932f661c2fafde4cc9e38dbbfa9a79bc057
> >
> > --
> > Lee Jones [李琼斯]
> >
> 
> Lee,
> 
> Can you please pick up both patches from this series or provide an
> immutable branch for the x86 tree to be able to queue patch 2/2 from
> this series?

What is the dependency?

-- 
Lee Jones

Re: (subset) [PATCH 1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell

[Bartosz Golaszewski]

On Wed, May 13, 2026 at 3:28 PM Lee Jones <lee@kernel.org> wrote:
>
> On Mon, 11 May 2026, Bartosz Golaszewski wrote:
>
> > On Thu, May 7, 2026 at 5:21 PM Lee Jones <lee@kernel.org> wrote:
> > >
> > > On Wed, 29 Apr 2026 14:23:30 +0200, Bartosz Golaszewski wrote:
> > > > There are board files in-tree that want to request GPIOs from this chip.
> > > > They currently rely on the GPIO core's mechanism of matching software
> > > > nodes' labels against GPIO controller names. We want to remove this
> > > > behavior from the kernel and to this end, we need to associate the
> > > > referenced GPIO controller with its target software node.
> > > >
> > > > Create a dedicated GPIO software node for cs5535, assign it to the GPIO
> > > > cell and expose its address in a new header.
> > > >
> > > > [...]
> > >
> > > Applied, thanks!
> > >
> > > [1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell
> > >       commit: 2b640932f661c2fafde4cc9e38dbbfa9a79bc057
> > >
> > > --
> > > Lee Jones [李琼斯]
> > >
> >
> > Lee,
> >
> > Can you please pick up both patches from this series or provide an
> > immutable branch for the x86 tree to be able to queue patch 2/2 from
> > this series?
>
> What is the dependency?
>

There's a build dependency: the geode board file needs to access the
variable from the cs5355.h header.

Bartosz

Re: (subset) [PATCH 1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell

[Bartosz Golaszewski]

On Wed, May 13, 2026 at 3:38 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Wed, May 13, 2026 at 3:28 PM Lee Jones <lee@kernel.org> wrote:
> >
> > On Mon, 11 May 2026, Bartosz Golaszewski wrote:
> >
> > > On Thu, May 7, 2026 at 5:21 PM Lee Jones <lee@kernel.org> wrote:
> > > >
> > > > On Wed, 29 Apr 2026 14:23:30 +0200, Bartosz Golaszewski wrote:
> > > > > There are board files in-tree that want to request GPIOs from this chip.
> > > > > They currently rely on the GPIO core's mechanism of matching software
> > > > > nodes' labels against GPIO controller names. We want to remove this
> > > > > behavior from the kernel and to this end, we need to associate the
> > > > > referenced GPIO controller with its target software node.
> > > > >
> > > > > Create a dedicated GPIO software node for cs5535, assign it to the GPIO
> > > > > cell and expose its address in a new header.
> > > > >
> > > > > [...]
> > > >
> > > > Applied, thanks!
> > > >
> > > > [1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell
> > > >       commit: 2b640932f661c2fafde4cc9e38dbbfa9a79bc057
> > > >
> > > > --
> > > > Lee Jones [李琼斯]
> > > >
> > >
> > > Lee,
> > >
> > > Can you please pick up both patches from this series or provide an
> > > immutable branch for the x86 tree to be able to queue patch 2/2 from
> > > this series?
> >
> > What is the dependency?
> >
>
> There's a build dependency: the geode board file needs to access the
> variable from the cs5355.h header.
>

Hi! Can you please queue this too then? Otherwise it'll delay the
removal of swnode name lookup from GPIO core by another cycle. We're
on track to have everything ready after v7.2-rc1.

Bart

Re: (subset) [PATCH 1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell

[Lee Jones]

On Tue, 19 May 2026, Bartosz Golaszewski wrote:

> On Wed, May 13, 2026 at 3:38 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
> >
> > On Wed, May 13, 2026 at 3:28 PM Lee Jones <lee@kernel.org> wrote:
> > >
> > > On Mon, 11 May 2026, Bartosz Golaszewski wrote:
> > >
> > > > On Thu, May 7, 2026 at 5:21 PM Lee Jones <lee@kernel.org> wrote:
> > > > >
> > > > > On Wed, 29 Apr 2026 14:23:30 +0200, Bartosz Golaszewski wrote:
> > > > > > There are board files in-tree that want to request GPIOs from this chip.
> > > > > > They currently rely on the GPIO core's mechanism of matching software
> > > > > > nodes' labels against GPIO controller names. We want to remove this
> > > > > > behavior from the kernel and to this end, we need to associate the
> > > > > > referenced GPIO controller with its target software node.
> > > > > >
> > > > > > Create a dedicated GPIO software node for cs5535, assign it to the GPIO
> > > > > > cell and expose its address in a new header.
> > > > > >
> > > > > > [...]
> > > > >
> > > > > Applied, thanks!
> > > > >
> > > > > [1/2] mfd: cs5535: add, assign and expose the software node for the GPIO cell
> > > > >       commit: 2b640932f661c2fafde4cc9e38dbbfa9a79bc057
> > > > >
> > > > > --
> > > > > Lee Jones [李琼斯]
> > > > >
> > > >
> > > > Lee,
> > > >
> > > > Can you please pick up both patches from this series or provide an
> > > > immutable branch for the x86 tree to be able to queue patch 2/2 from
> > > > this series?
> > >
> > > What is the dependency?
> > >
> >
> > There's a build dependency: the geode board file needs to access the
> > variable from the cs5355.h header.
> >
> 
> Hi! Can you please queue this too then? Otherwise it'll delay the
> removal of swnode name lookup from GPIO core by another cycle. We're
> on track to have everything ready after v7.2-rc1.

Does it have all of the Acks?

-- 
Lee Jones

Re: [PATCH 2/2] x86/platform/geode: reference the real node of the cs5535 GPIO controller

[Bartosz Golaszewski]

On Wed, Apr 29, 2026 at 2:23 PM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
>
> We now can access the address of the software node associated with the
> GPIO controller cell of the cs5535 MFD device. Make it the target of the
> GPIO software node references in geode-common.c. Make sure the cs5535
> driver is built-in for all boards selecting GEODE_COMMON.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---

Hi x86 maintainers!

Any chance of getting an Ack on this patch allowing Lee to queue it
for v7.2 through the MFD tree?

Thanks,
Bartosz

Re: [PATCH 2/2] x86/platform/geode: reference the real node of the cs5535 GPIO controller

[Dave Hansen]

On 4/29/26 05:23, Bartosz Golaszewski wrote:
> We now can access the address of the software node associated with the
> GPIO controller cell of the cs5535 MFD device. Make it the target of the
> GPIO software node references in geode-common.c. Make sure the cs5535
> driver is built-in for all boards selecting GEODE_COMMON.

This looks like a good cleanup, but the changelog has me scratching my
head a bit.

I'm not quite sure what problem this is solving. It's also a bit unusual
to have a driver depend on another not being built as a module. There's
also not really a mention of the:

	+MODULE_IMPORT_NS("CS5535");

in the changelog.

Oh, and on a minor note, it might all be more clear if the changelog was
written in imperative voice and removed the "We".

Honestly, this is old hardware so I don't want to fret about this too
much. I'd be happy to ack this, but I don't really know what I'm acking. ;)

Re: [PATCH 2/2] x86/platform/geode: reference the real node of the cs5535 GPIO controller

[Bartosz Golaszewski]

On Thu, May 21, 2026 at 4:19 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 4/29/26 05:23, Bartosz Golaszewski wrote:
> > We now can access the address of the software node associated with the
> > GPIO controller cell of the cs5535 MFD device. Make it the target of the
> > GPIO software node references in geode-common.c. Make sure the cs5535
> > driver is built-in for all boards selecting GEODE_COMMON.
>
> This looks like a good cleanup, but the changelog has me scratching my
> head a bit.
>
> I'm not quite sure what problem this is solving. It's also a bit unusual

I thought the cover letter explains it pretty well? The software node
representing the GPIO chip we're referencing from the software node
attached to the GPIO consumer here is not attached to the GPIO
controller device. This means that the lookup happens based on the
GPIO controller's label matched against the name of the software node.
I want to remove this behavior in favor of matching actual firmware
nodes. This is being done for many reasons: string matching is wonky
at best and I'm working on adding fw_devlink support for software
nodes but that requires real references between devices.

> to have a driver depend on another not being built as a module. There's

This is not a driver, this is a board file that's always built-in. And
I agree it's not optimal but it's already being done for other files
for this platform and it's legacy anyway so I think we can live with
that.

> also not really a mention of the:
>
>         +MODULE_IMPORT_NS("CS5535");
>
> in the changelog.
>

Ok, I'll add it.

> Oh, and on a minor note, it might all be more clear if the changelog was
> written in imperative voice and removed the "We".
>
> Honestly, this is old hardware so I don't want to fret about this too
> much. I'd be happy to ack this, but I don't really know what I'm acking. ;)

Thanks,
Bartosz