The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Arnd Bergmann" <arnd@arndb.de>,
	"Rafał Miłecki" <zajec5@gmail.com>, "Michael Büsch" <m@bues.ch>,
	"Hauke Mehrtens" <hauke@hauke-m.de>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Waldemar Brodkorb" <wbx@openadk.org>,
	"Bartosz Golaszewski" <brgl@kernel.org>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	"Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Subject: Re: [PATCH v2 0/3] MIPS: BCM47XX: convert buttons to software nodes
Date: Tue, 14 Jul 2026 23:09:09 -0700	[thread overview]
Message-ID: <alci_45CzdVznaN2@google.com> (raw)
In-Reply-To: <ala9C6XMB3-ywpph@waldemar-brodkorb.de>

Hi Waldemar,

On Wed, Jul 15, 2026 at 12:49:47AM +0200, Waldemar Brodkorb wrote:
> Hi,
> Arnd Bergmann wrote,
> 
> > On Mon, Jul 13, 2026, at 23:58, Dmitry Torokhov wrote:
> > > This series converts the legacy gpio-keys platform device on BCM47XX
> > > boards to use software nodes and static properties.
> > >
> > > To do this properly without relying on legacy name-based matching
> > > (which is being removed from gpiolib), we introduce and register
> > > software nodes for the underlying GPIO controllers (BCMA and SSB)
> > > and reference them in the button properties.
> > >
> > > The first two patches add the software nodes to bcma-gpio and
> > > ssb-gpio respectively. The third patch performs the conversion
> > > for the BCM47XX buttons.
> > >
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > ---
> > > As Johannes mentioned on v1 this best should go through MIPS tree.
> > 
> > Adding Waldemar to Cc. He has recently done some work to
> > get this platform working again in FreeWRT and should
> > be able to test your patches on hardware.
> 
> I normally use LTS kernel on the hardware (Linksys WRT54GS v1.0).
> But for testing I updated to 7.1.3. Attached is the dmesg without
> Dmitry's patches.  Button works, I can go into failsafe mode after
> pressing the reset button on bootup.
> 
> With Dmitry's three patches applied I directly getting into failsafe
> mode without pressing any button. Dmesg looks similar, but I get
> following kernel message:
> platform gpio-keys.0: deferred probe pending: gpio-keys: failed to get gpio
> 
> Looking at /dev I see no /dev/input/event0 device node anymore.
> 
> Attached is the small failsafe script I use on bootup.
> Hope this helps.
> 
> Do I need to change my failsafe script for the new stuff or is
> something else broken now? Do I miss some new kernel config option?
> Or is the patch only for latest Linus git repo.

Thank you very much for testing. I think 7.1 should work. Could you
please apply the test patch below and send me new dmesg? Hopefully I'll
be able to figure out where I messed up.


diff --git a/arch/mips/bcm47xx/buttons.c b/arch/mips/bcm47xx/buttons.c
index 151a4ee2803f..72524dc390dd 100644
--- a/arch/mips/bcm47xx/buttons.c
+++ b/arch/mips/bcm47xx/buttons.c
@@ -521,6 +521,9 @@ bcm47xx_buttons_add(const struct bcm47xx_gpio_key *buttons, int nbuttons)
 		return -ENODEV;
 	}
 
+	pr_info("XXX: bcm47xx_buttons_add called, bus_type=%d, gpio_swnode=%p (&ssb_gpio_swnode=%p)\n",
+		bcm47xx_bus_type, gpio_swnode, &ssb_gpio_swnode);
+
 	/* 1 node for gpio-keys device, 1 node for each button, 1 terminator */
 	const struct software_node **node_group __free(kfree) =
 		kcalloc(1 + nbuttons + 1, sizeof(*node_group), GFP_KERNEL);
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 869228a65cb3..20f89e6a57f6 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -561,8 +561,11 @@ software_node_get_reference_args(const struct fwnode_handle *fwnode,
 	else
 		return -EINVAL;
 
-	if (!refnode)
+	if (!refnode) {
+		pr_info("XXX: software_node_get_reference_args: refnode is NULL for swnode=%p (%s), fwnode=%p\n",
+			ref->swnode, ref->swnode ? ref->swnode->name : "none", ref->fwnode);
 		return -ENOTCONN;
+	}
 
 	if (nargs_prop) {
 		error = fwnode_property_read_u32(refnode, nargs_prop, &nargs_prop_val);
diff --git a/drivers/ssb/driver_gpio.c b/drivers/ssb/driver_gpio.c
index 87922479946c..28de62a42140 100644
--- a/drivers/ssb/driver_gpio.c
+++ b/drivers/ssb/driver_gpio.c
@@ -238,8 +238,10 @@ static int ssb_gpio_chipco_init(struct ssb_bus *bus)
 	chip->to_irq		= ssb_gpio_to_irq;
 #endif
 	chip->ngpio		= 16;
-	if (bus->bustype == SSB_BUSTYPE_SSB)
+	if (bus->bustype == SSB_BUSTYPE_SSB) {
 		chip->fwnode	= software_node_fwnode(&ssb_gpio_swnode);
+		pr_info("XXX: chipcommon chip->fwnode set to %p\n", chip->fwnode);
+	}
 	/* There is just one SoC in one device and its GPIO addresses should be
 	 * deterministic to address them more easily. The other buses could get
 	 * a random base number.
@@ -444,6 +446,7 @@ static int ssb_gpio_extif_init(struct ssb_bus *bus)
 	if (bus->bustype == SSB_BUSTYPE_SSB) {
 		chip->base	= 0;
 		chip->fwnode	= software_node_fwnode(&ssb_gpio_swnode);
+		pr_info("XXX: extif chip->fwnode set to %p\n", chip->fwnode);
 	} else {
 		chip->base	= -1;
 	}
@@ -481,8 +484,10 @@ int ssb_gpio_init(struct ssb_bus *bus)
 	 * one SoC instance in the system, so there are no concerns with
 	 * registration conflicts.
 	 */
+	pr_info("XXX: ssb_gpio_init called, bustype=%d\n", bus->bustype);
 	if (bus->bustype == SSB_BUSTYPE_SSB) {
 		err = software_node_register(&ssb_gpio_swnode);
+		pr_info("XXX: software_node_register(&ssb_gpio_swnode) returned %d\n", err);
 		if (err)
 			return err;
 	}


Thanks.

-- 
Dmitry

  reply	other threads:[~2026-07-15  6:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-13 21:58 [PATCH v2 0/3] MIPS: BCM47XX: convert buttons to software nodes Dmitry Torokhov
2026-07-13 21:58 ` [PATCH v2 1/3] bcma: gpio: Add and register software node for GPIO controller Dmitry Torokhov
2026-07-13 21:58 ` [PATCH v2 2/3] ssb: " Dmitry Torokhov
2026-07-13 21:58 ` [PATCH v2 3/3] MIPS: BCM47XX: Convert buttons to software nodes Dmitry Torokhov
2026-07-14  7:12 ` [PATCH v2 0/3] MIPS: BCM47XX: convert " Arnd Bergmann
2026-07-14 22:49   ` Waldemar Brodkorb
2026-07-15  6:09     ` Dmitry Torokhov [this message]
2026-07-15 10:16       ` Waldemar Brodkorb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alci_45CzdVznaN2@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=brgl@kernel.org \
    --cc=hauke@hauke-m.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=m@bues.ch \
    --cc=tsbogend@alpha.franken.de \
    --cc=wbx@openadk.org \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox