[PATCH 0/3] corenet: Add power/reset support to Cyrus

Cyrus has gpio pins for power and reset, so we should support them

Andy Fleming (3):
  cyrus: Add poweroff/reset support
  corenet: Support gpio power/reset for corenet
  Cyrus: create a defconfig

 arch/powerpc/Makefile                         |  5 +++++
 arch/powerpc/boot/dts/fsl/cyrus_p5020.dts     | 11 +++++++++++
 arch/powerpc/configs/cyrus_basic_defconfig    |  9 +++++++++
 arch/powerpc/platforms/85xx/corenet_generic.c | 18 ++++++++++++++++++
 4 files changed, 43 insertions(+)
 create mode 100644 arch/powerpc/configs/cyrus_basic_defconfig

-- 
1.9.1

Cyrus uses GPIOs to complete board shutdown/reset.
Add nodes to indicate that support to the device tree.

Signed-off-by: Andy Fleming <redacted>
---
 arch/powerpc/boot/dts/fsl/cyrus_p5020.dts | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/powerpc/boot/dts/fsl/cyrus_p5020.dts b/arch/powerpc/boot/dts/fsl/cyrus_p5020.dts
index c603390..e417aaa 100644
--- a/arch/powerpc/boot/dts/fsl/cyrus_p5020.dts
+++ b/arch/powerpc/boot/dts/fsl/cyrus_p5020.dts

@@ -150,6 +150,17 @@
 				  0 0x00010000>;
 		};
 	};
+
+        gpio-poweroff {
+                compatible = "gpio-poweroff";
+                gpios = <&gpio0 3 1>;
+        };
+
+        gpio-restart {
+                compatible = "gpio-restart";
+                gpios = <&gpio0 2 1>;
+        };
+
 };
 
 /include/ "p5020si-post.dtsi"

-- 
1.9.1

Boards can implement power and reset functionality over gpio using
these drivers:
  drivers/power/reset/gpio-poweroff.c
  drivers/power/reset/gpio-restart.c

While not all corenet boards use gpio for power/reset, this
support can be added without interfering with boards that do not
use this functionality.

If a board's device tree has the related nodes, they are now probed.
Also, gpio-poweroff uses the global pm_power_off callback to implement
the shutdown. However, pm_power_off was not invoked when the kernel
halted, although that is usually the desired behavior. If the board
provides gpio power and reset support, it is reasonable to assume that
halting should also power down the system, unless it has chosen to
pass those calls on to hypervisor.

Signed-off-by: Andy Fleming <redacted>
---
 arch/powerpc/platforms/85xx/corenet_generic.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index 3a6a84f..17b8ebb 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c

@@ -59,6 +59,16 @@ void __init corenet_gen_pic_init(void)
 	}
 }
 
+/* If someone has registered a poweroff callback, invoke it */
+static void __noreturn corenet_generic_halt(void)
+{
+	if (pm_power_off)
+		pm_power_off();
+
+	/* Should not return */
+	for(;;);
+}
+
 /*
  * Setup the architecture
  */

@@ -127,6 +137,12 @@ static const struct of_device_id of_device_ids[] = {
 	{
 		.name		= "handles",
 	},
+	{
+		.name		= "gpio-poweroff",
+	},
+	{
+		.name		= "gpio-restart",
+	},
 	{}
 };
 

@@ -176,6 +192,8 @@ static int __init corenet_generic_probe(void)
 	extern struct smp_ops_t smp_85xx_ops;
 #endif
 
+	ppc_md.halt = corenet_generic_halt;
+
 	if (of_device_compatible_match(of_root, boards))
 		return 1;
 

-- 
1.9.1

This sets up the proper config elements for Power and Reset to work
properly (using the gpio pins).

Signed-off-by: Andy Fleming <redacted>
---
 arch/powerpc/Makefile                      | 5 +++++
 arch/powerpc/configs/cyrus_basic_defconfig | 9 +++++++++
 2 files changed, 14 insertions(+)
 create mode 100644 arch/powerpc/configs/cyrus_basic_defconfig

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 1934707..83f257e 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile

@@ -332,6 +332,11 @@ corenet64_smp_defconfig:
 	$(call merge_into_defconfig,corenet_basic_defconfig,\
 		85xx-64bit 85xx-smp altivec 85xx-hw fsl-emb-nonhw)
 
+PHONY += cyrus_defconfig
+cyrus_defconfig:
+	$(call merge_into_defconfig,cyrus_basic_defconfig,\
+		85xx-64bit 85xx-smp altivec 85xx-hw fsl-emb-nonhw)
+
 PHONY += mpc86xx_defconfig
 mpc86xx_defconfig:
 	$(call merge_into_defconfig,mpc86xx_basic_defconfig,\

diff --git a/arch/powerpc/configs/cyrus_basic_defconfig b/arch/powerpc/configs/cyrus_basic_defconfig
new file mode 100644
index 0000000..975150c
--- /dev/null
+++ b/arch/powerpc/configs/cyrus_basic_defconfig

@@ -0,0 +1,9 @@
+CONFIG_CORENET_GENERIC=y
+CONFIG_USERLIB=y
+CONFIG_GPIO_GENERIC_PLATFORM=y
+CONFIG_POWER_SUPPLY=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO=y
+CONFIG_POWER_RESET_GPIO_RESTART=y
+CONFIG_RESET_CONTROLLER=y
+CONFIG_EXT3_FS=y

-- 
1.9.1

On 09/06/2016 02:12 PM, Andy Fleming wrote:=0A=

This sets up the proper config elements for Power and Reset to work=0A=
properly (using the gpio pins).=0A=
=0A=
Signed-off-by: Andy Fleming <redacted>=0A=
---=0A=
 arch/powerpc/Makefile                      | 5 +++++=0A=
 arch/powerpc/configs/cyrus_basic_defconfig | 9 +++++++++=0A=
 2 files changed, 14 insertions(+)=0A=
 create mode 100644 arch/powerpc/configs/cyrus_basic_defconfig=0A=

=0A=
Why does cyrus need its own defconfig?  Just enable the power/reset=0A=
stuff in 85xx-hw.config.=0A=
=0A=

+CONFIG_EXT3_FS=3Dy=0A=

=0A=
This has nothing to do with power/reset, and is already present in=0A=
fsl-emb-nonhw.config.=0A=
=0A=
-Scott=0A=
=0A=

On 09/06/2016 02:12 PM, Andy Fleming wrote:=0A=

Boards can implement power and reset functionality over gpio using=0A=
these drivers:=0A=
  drivers/power/reset/gpio-poweroff.c=0A=
  drivers/power/reset/gpio-restart.c=0A=
=0A=
While not all corenet boards use gpio for power/reset, this=0A=
support can be added without interfering with boards that do not=0A=
use this functionality.=0A=
=0A=
If a board's device tree has the related nodes, they are now probed.=0A=
Also, gpio-poweroff uses the global pm_power_off callback to implement=0A=
the shutdown. However, pm_power_off was not invoked when the kernel=0A=
halted, although that is usually the desired behavior. If the board=0A=
provides gpio power and reset support, it is reasonable to assume that=0A=
halting should also power down the system, unless it has chosen to=0A=
pass those calls on to hypervisor.=0A=

=0A=
Halt and poweroff are not the same thing.  If userspace requests a=0A=
poweroff, then kernel_power_off() will call machine_power_off() which=0A=
will call pm_power_off().=0A=
=0A=
Why do we need anything corenet-specific here?=0A=
=0A=

 {=0A=

 	{=0A=
 		.name		=3D "handles",=0A=
 	},=0A=
+	{=0A=
+		.name		=3D "gpio-poweroff",=0A=
+	},=0A=
+	{=0A=
+		.name		=3D "gpio-restart",=0A=
+	},=0A=
 	{}=0A=
 };=0A=
 =0A=

=0A=
I don't see any other platforms doing this.  How do the nodes get probed=0A=
for them?=0A=
=0A=
-Scott=0A=
=0A=

On Tuesday, September 6, 2016, Scott Wood [off-list ref] wrote:

On 09/06/2016 02:12 PM, Andy Fleming wrote:

quoted

Boards can implement power and reset functionality over gpio using
these drivers:
  drivers/power/reset/gpio-poweroff.c
  drivers/power/reset/gpio-restart.c

While not all corenet boards use gpio for power/reset, this
support can be added without interfering with boards that do not
use this functionality.

If a board's device tree has the related nodes, they are now probed.
Also, gpio-poweroff uses the global pm_power_off callback to implement
the shutdown. However, pm_power_off was not invoked when the kernel
halted, although that is usually the desired behavior. If the board
provides gpio power and reset support, it is reasonable to assume that
halting should also power down the system, unless it has chosen to
pass those calls on to hypervisor.

Halt and poweroff are not the same thing.  If userspace requests a
poweroff, then kernel_power_off() will call machine_power_off() which
will call pm_power_off().

Why do we need anything corenet-specific here?

We don't, but then the board will halt instead of power off when you type
shutdown -h now. Or if you type poweroff without a high enough run level,
apparently. I'm amenable to removing the halt code, but there are concerns
that this will cause the systems to behave unintentionally as intended, in
that most systems that users interact with shut down when you call shutdown
-h now. There may be scripts that depend on that behavior (or at least
assume it). Perhaps I could add a config option?
CONFIG_TREAT_HALT_AS_POWEROFF? CONFIG_POWEROFF_ON_HALT?

I'll note that there is one other board that is doing the same thing, but
they've implemented their own gpio poweroff driver. See
commit 5611fe48c545a22e62273428ed74c9bfae4a9406. That commit also points
vaguely in the direction of an answer to your second question...

quoted

@@ -127,6 +137,12 @@ static const struct of_device_id of_device_ids[] = {
      {
              .name           = "handles",
      },
+     {
+             .name           = "gpio-poweroff",
+     },
+     {
+             .name           = "gpio-restart",
+     },
      {}
 };

I don't see any other platforms doing this.  How do the nodes get probed
for them?

The answer is I don't know, but this is a common issue with adding new
devices to the device tree in embedded powerpc. The only other platforms
which have gpio-poweroff nodes in their trees are in arch/arm, and none of
those platforms call the probing function of_platform_bus_probe. I suspect
they either probe every root node, or they somehow construct the match_id.
As noted in the above-referenced commit, putting the nodes under the gpio
bus does not cause them to get probed. This seemed like the best way under
the current corenet code.

-Scott

On Tuesday, September 6, 2016, Scott Wood [off-list ref] wrote:

On 09/06/2016 02:12 PM, Andy Fleming wrote:

quoted

This sets up the proper config elements for Power and Reset to work
properly (using the gpio pins).

Signed-off-by: Andy Fleming <afleming@gmail.com <javascript:;>>
---
 arch/powerpc/Makefile                      | 5 +++++
 arch/powerpc/configs/cyrus_basic_defconfig | 9 +++++++++
 2 files changed, 14 insertions(+)
 create mode 100644 arch/powerpc/configs/cyrus_basic_defconfig

Why does cyrus need its own defconfig?  Just enable the power/reset
stuff in 85xx-hw.config.

Ok.

quoted

+CONFIG_EXT3_FS=y

This has nothing to do with power/reset, and is already present in
fsl-emb-nonhw.config.

Ok, weird. Are you sure? I see:

# CONFIG_EXT3_FS is not set

CONFIG_EXT4_FS=y

quoted

On 09/10/2016 05:12 PM, Andy Fleming wrote:=0A=

=0A=
=0A=
On Tuesday, September 6, 2016, Scott Wood <scott.wood@nxp.com=0A=
<mailto:scott.wood@nxp.com>> wrote:=0A=
=0A=
    On 09/06/2016 02:12 PM, Andy Fleming wrote:=0A=
    > This sets up the proper config elements for Power and Reset to work=

=0A=

    > properly (using the gpio pins).=0A=
    >=0A=
    > Signed-off-by: Andy Fleming <afleming@gmail.com <javascript:;>>=0A=
    > ---=0A=
    >  arch/powerpc/Makefile                      | 5 +++++=0A=
    >  arch/powerpc/configs/cyrus_basic_defconfig | 9 +++++++++=0A=
    >  2 files changed, 14 insertions(+)=0A=
    >  create mode 100644 arch/powerpc/configs/cyrus_basic_defconfig=0A=
=0A=
    Why does cyrus need its own defconfig?  Just enable the power/reset=

=0A=

    stuff in 85xx-hw.config.=0A=
=0A=
=0A=
=0A=
    Ok.=0A=

=0A=
Please send non-HTML mail with proper quote markers.  It's hard to read=0A=
when it looks like someone is talking to themself.=0A=
=0A=

    > +CONFIG_EXT3_FS=3Dy=0A=
=0A=
    This has nothing to do with power/reset, and is already present in=0A=
    fsl-emb-nonhw.config.=0A=
=0A=
=0A=
    Ok, weird. Are you sure? I see:=0A=
=0A=
=0A=
        # CONFIG_EXT3_FS is not set=0A=
=0A=
        CONFIG_EXT4_FS=3Dy=0A=

=0A=
Apparently it was just removed by commit=0A=
bdd910017c6a4 ("powerpc/configs: Remove old symbols from defconfigs").=0A=
=0A=
Andrew Donnellan, why was ext3 support removed?=0A=
=0A=
-Scott=0A=
=0A=

On 09/10/2016 05:05 PM, Andy Fleming wrote:=0A=

=0A=
=0A=
On Tuesday, September 6, 2016, Scott Wood <scott.wood@nxp.com=0A=
<mailto:scott.wood@nxp.com>> wrote:=0A=
=0A=
    On 09/06/2016 02:12 PM, Andy Fleming wrote:=0A=
    > Boards can implement power and reset functionality over gpio using=

=0A=

    > these drivers:=0A=
    >   drivers/power/reset/gpio-poweroff.c=0A=
    >   drivers/power/reset/gpio-restart.c=0A=
    >=0A=
    > While not all corenet boards use gpio for power/reset, this=0A=
    > support can be added without interfering with boards that do not=0A=
    > use this functionality.=0A=
    >=0A=
    > If a board's device tree has the related nodes, they are now probed=

.=0A=

    > Also, gpio-poweroff uses the global pm_power_off callback to implem=

ent=0A=

    > the shutdown. However, pm_power_off was not invoked when the kernel=

=0A=

    > halted, although that is usually the desired behavior. If the board=

=0A=

    > provides gpio power and reset support, it is reasonable to assume t=

hat=0A=

    > halting should also power down the system, unless it has chosen to=

=0A=

    > pass those calls on to hypervisor.=0A=
=0A=
    Halt and poweroff are not the same thing.  If userspace requests a=0A=
    poweroff, then kernel_power_off() will call machine_power_off() which=

=0A=

    will call pm_power_off().=0A=
=0A=
    Why do we need anything corenet-specific here?=0A=
=0A=
=0A=
=0A=
    We don't, but then the board will halt instead of power off when you=

=0A=

    type shutdown -h now.=0A=

=0A=
Isn't that what it's supposed to do?  If you want poweroff then ask for=0A=
poweroff.=0A=
=0A=

    Or if you type poweroff without a high enough=0A=
    run level, apparently.=0A=

=0A=
Hmm?=0A=
=0A=
In any case, run levels have nothing to do with the kernel.  The kernel=0A=
implements LINUX_REBOOT_CMD_HALT and LINUX_REBOOT_CMD_POWER_OFF, and=0A=
they should do what they're advertised to do.=0A=
=0A=

    I'm amenable to removing the halt code, but=0A=
    there are concerns that this will cause the systems to behave=0A=
    unintentionally as intended, in that most systems that users=0A=
    interact with shut down when you call shutdown -h now. There may be=

=0A=

    scripts that depend on that behavior (or at least assume it).=0A=

=0A=
When did the behavior you're seeking ever exist?=0A=
=0A=

    I don't see any other platforms doing this.  How do the nodes get pro=

bed=0A=

    for them?=0A=
=0A=
=0A=
    The answer is I don't know, but this is a common issue with adding=0A=
    new devices to the device tree in embedded powerpc. The only other=0A=
    platforms which have gpio-poweroff nodes in their trees are in=0A=
    arch/arm, and none of those platforms call the probing=0A=
    function of_platform_bus_probe. I suspect they either probe every=0A=
    root node, or they somehow construct the match_id. As noted in the=0A=
    above-referenced commit, putting the nodes under the gpio bus does=0A=
    not cause them to get probed. This seemed like the best way under=0A=
    the current corenet code.=0A=

=0A=
Well, let's figure out what it is that PPC should be doing to have=0A=
things work the way it does on ARM.=0A=
=0A=
-Scott=0A=
=0A=

Scott Wood [off-list ref] writes:

On 09/10/2016 05:12 PM, Andy Fleming wrote:

quoted

On Tuesday, September 6, 2016, Scott Wood <scott.wood@nxp.com
<mailto:scott.wood@nxp.com>> wrote:
    On 09/06/2016 02:12 PM, Andy Fleming wrote:
    > +CONFIG_EXT3_FS=y

    This has nothing to do with power/reset, and is already present in
    fsl-emb-nonhw.config.


    Ok, weird. Are you sure? I see:


        # CONFIG_EXT3_FS is not set

        CONFIG_EXT4_FS=y

Apparently it was just removed by commit
bdd910017c6a4 ("powerpc/configs: Remove old symbols from defconfigs").

Andrew Donnellan, why was ext3 support removed?

Because ext3 was removed, ext4 handles it now.

The EXT3 Kconfig symbols still exist but they are just for backward
compat with old configs (like this one), and they just turn on EXT4.

So AFAICS Andrew's patch was correct, and you should be getting ext3
support from ext4.

cheers

On Sep 12, 2016, at 23:47, Scott Wood [off-list ref] wrote:
=20

quoted

On 09/10/2016 05:05 PM, Andy Fleming wrote:
=20
=20
On Tuesday, September 6, 2016, Scott Wood <scott.wood@nxp.com
<mailto:scott.wood@nxp.com>> wrote:
=20

quoted

   On 09/06/2016 02:12 PM, Andy Fleming wrote:
Boards can implement power and reset functionality over gpio using
these drivers:
 drivers/power/reset/gpio-poweroff.c
 drivers/power/reset/gpio-restart.c
=20
While not all corenet boards use gpio for power/reset, this
support can be added without interfering with boards that do not
use this functionality.
=20
If a board's device tree has the related nodes, they are now probed.
Also, gpio-poweroff uses the global pm_power_off callback to implement
the shutdown. However, pm_power_off was not invoked when the kernel
halted, although that is usually the desired behavior. If the board
provides gpio power and reset support, it is reasonable to assume that
halting should also power down the system, unless it has chosen to
pass those calls on to hypervisor.

=20
   Halt and poweroff are not the same thing.  If userspace requests a
   poweroff, then kernel_power_off() will call machine_power_off() which
   will call pm_power_off().
=20
   Why do we need anything corenet-specific here?
=20
=20
=20
   We don't, but then the board will halt instead of power off when you
   type shutdown -h now.

=20
Isn't that what it's supposed to do?  If you want poweroff then ask for
poweroff.
=20

quoted

   Or if you type poweroff without a high enough
   run level, apparently.

=20
Hmm?
=20
In any case, run levels have nothing to do with the kernel.  The kernel
implements LINUX_REBOOT_CMD_HALT and LINUX_REBOOT_CMD_POWER_OFF, and
they should do what they're advertised to do.
=20

quoted

   I'm amenable to removing the halt code, but
   there are concerns that this will cause the systems to behave
   unintentionally as intended, in that most systems that users
   interact with shut down when you call shutdown -h now. There may be
   scripts that depend on that behavior (or at least assume it).

=20
When did the behavior you're seeking ever exist?

Well, for one, on that Servergy board. I agree that halt and power off mean a=
nd have always meant different things to the kernel. The problem is that mos=
t desktop systems, having halted, pass control to the BIOS which--usually--s=
huts off the power. Am I wrong about this? I've been using shutdown -h now t=
o turn off my Linux systems for nearly 2 decades now, but I admit that I don=
't do it often, and I tend to stick with whatever works.

=20

quoted

   I don't see any other platforms doing this.  How do the nodes get prob=

ed

quoted

   for them?
=20
=20
   The answer is I don't know, but this is a common issue with adding
   new devices to the device tree in embedded powerpc. The only other
   platforms which have gpio-poweroff nodes in their trees are in
   arch/arm, and none of those platforms call the probing
   function of_platform_bus_probe. I suspect they either probe every
   root node, or they somehow construct the match_id. As noted in the
   above-referenced commit, putting the nodes under the gpio bus does
   not cause them to get probed. This seemed like the best way under
   the current corenet code.

=20
Well, let's figure out what it is that PPC should be doing to have
things work the way it does on ARM.

For all of the devices? Or just these two?

Andy

On Sep 12, 2016, at 18:54, Scott Wood [off-list ref] wrote:
=20

quoted

On 09/10/2016 05:12 PM, Andy Fleming wrote:
=20
=20
On Tuesday, September 6, 2016, Scott Wood <scott.wood@nxp.com
<mailto:scott.wood@nxp.com>> wrote:
=20

quoted

   On 09/06/2016 02:12 PM, Andy Fleming wrote:
This sets up the proper config elements for Power and Reset to work
properly (using the gpio pins).
=20
Signed-off-by: Andy Fleming <afleming@gmail.com <javascript:;>>
---
arch/powerpc/Makefile                      | 5 +++++
arch/powerpc/configs/cyrus_basic_defconfig | 9 +++++++++
2 files changed, 14 insertions(+)
create mode 100644 arch/powerpc/configs/cyrus_basic_defconfig

=20
   Why does cyrus need its own defconfig?  Just enable the power/reset
   stuff in 85xx-hw.config.
=20
=20
=20
   Ok.

=20
Please send non-HTML mail with proper quote markers.  It's hard to read
when it looks like someone is talking to themself.

Argh, sorry. gmail iPhone client did that very subtly. I've flipped it over t=
o Mail, and hopefully that fixes it...

Andy=

On 09/15/2016 03:03 AM, Andy Fleming wrote:=0A=

I agree that halt and power off mean and have always meant different=0A=
things to the kernel. The problem is that most desktop systems,=0A=
having halted, pass control to the BIOS which--usually--shuts off the=0A=
power. Am I wrong about this? I've been using shutdown -h now to turn=0A=
off my Linux systems for nearly 2 decades now, but I admit that I=0A=
don't do it often, and I tend to stick with whatever works.=0A=

=0A=

From the shutdown man page:=0A=

=0A=
     -h=0A=
           Equivalent to --poweroff, unless --halt is specified.=0A=
=0A=
Again, let's talk in terms of the kernel API rather than quirky=0A=
userspace commands.=0A=
=0A=
FWIW, I've always used "halt -p" and recall the system not powering off=0A=
on PCs when I use plain "halt", though it's been many years since I've=0A=
tried.=0A=
=0A=

quoted

quoted

   I don't see any other platforms doing this.  How do the nodes get pr=

obed=0A=

quoted

quoted

   for them?=0A=
=0A=
=0A=
   The answer is I don't know, but this is a common issue with adding=

=0A=

quoted

quoted

   new devices to the device tree in embedded powerpc. The only other=

=0A=

quoted

quoted

   platforms which have gpio-poweroff nodes in their trees are in=0A=
   arch/arm, and none of those platforms call the probing=0A=
   function of_platform_bus_probe. I suspect they either probe every=0A=
   root node, or they somehow construct the match_id. As noted in the=

=0A=

quoted

quoted

   above-referenced commit, putting the nodes under the gpio bus does=

=0A=

quoted

quoted

   not cause them to get probed. This seemed like the best way under=0A=
   the current corenet code.=0A=

=0A=
Well, let's figure out what it is that PPC should be doing to have=0A=
things work the way it does on ARM.=0A=

=0A=
For all of the devices? Or just these two?=0A=

=0A=
All of them.  If ARM isn't maintaining these annoying lists why should=0A=
we have to? :-P=0A=
=0A=
-Scott=0A=
=0A=

On 09/16/2016 04:05 PM, Scott Wood wrote:=0A=

quoted

quoted

quoted

   I don't see any other platforms doing this.  How do the nodes get p=

robed=0A=

quoted

quoted

quoted

   for them?=0A=
=0A=
=0A=
   The answer is I don't know, but this is a common issue with adding=

=0A=

quoted

quoted

quoted

   new devices to the device tree in embedded powerpc. The only other=

=0A=

quoted

quoted

quoted

   platforms which have gpio-poweroff nodes in their trees are in=0A=
   arch/arm, and none of those platforms call the probing=0A=
   function of_platform_bus_probe. I suspect they either probe every=

=0A=

quoted

quoted

quoted

   root node, or they somehow construct the match_id. As noted in the=

=0A=

quoted

quoted

quoted

   above-referenced commit, putting the nodes under the gpio bus does=

=0A=

quoted

quoted

quoted

   not cause them to get probed. This seemed like the best way under=

=0A=

quoted

quoted

quoted

   the current corenet code.=0A=

=0A=
Well, let's figure out what it is that PPC should be doing to have=0A=
things work the way it does on ARM.=0A=

=0A=
For all of the devices? Or just these two?=0A=

=0A=
All of them.  If ARM isn't maintaining these annoying lists why should=0A=
we have to? :-P=0A=

=0A=
The answer seems to be using of_platform_populate() rather than=0A=
of_platform_bus_probe().=0A=
=0A=
-Scott=0A=
=0A=

On Tue, Sep 06, 2016 at 02:11:57PM -0500, Andy Fleming wrote:

Whitespace

-Scott