This patch set adds syscon reboot/poweroff device nodes to support reboot and
poweroff features on X-Gene platform.
Tai Nguyen (2):
power: reset: Add syscon reboot device node for APM X-Gene platform
power: reset: Add syscon poweroff device node for APM X-Gene Mustang platform
arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
arch/arm64/boot/dts/apm/apm-storm.dtsi | 12 ++++++++++++
2 files changed, 24 insertions(+)
--
1.7.9.5
This patch adds syscon reboot device node to support reboot feature on APM X-Gene platform
Signed-off-by: Feng Kan <[email protected]>
Signed-off-by: Tai Nguyen <[email protected]>
---
arch/arm64/boot/dts/apm/apm-storm.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index c8d3e0e..16efcf7 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -710,5 +710,17 @@
dma-coherent;
clocks = <&dmaclk 0>;
};
+
+ scu: system-clk-controller@17000000 {
+ compatible = "apm,xgene-scu","syscon";
+ reg = <0x0 0x17000000 0x0 0x400>;
+ };
+
+ reboot: reboot@17000014 {
+ compatible = "syscon-reboot";
+ regmap = <&scu>;
+ offset = <0x14>;
+ mask = <0x1>;
+ };
};
};
--
1.7.9.5
This patch adds syscon poweroff device node to support poweroff feature
on APM X-Gene Mustang platform
Signed-off-by: Tai Nguyen <[email protected]>
---
arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts b/arch/arm64/boot/dts/apm/apm-mustang.dts
index 83578e7..910d561 100644
--- a/arch/arm64/boot/dts/apm/apm-mustang.dts
+++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
@@ -23,6 +23,18 @@
device_type = "memory";
reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
};
+
+ poweroff_mbox: poweroff_mbox@10548000 {
+ compatible = "syscon";
+ reg = <0x0 0x10548000 0x0 0x30>;
+ };
+
+ poweroff: poweroff@10548010 {
+ compatible = "syscon-poweroff";
+ regmap = <&poweroff_mbox>;
+ offset = <0x10>;
+ mask = <0x1>;
+ };
};
&pcie0clk {
--
1.7.9.5
On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen <[email protected]> wrote:
> This patch adds syscon poweroff device node to support poweroff feature
> on APM X-Gene Mustang platform
hey Tai,
The reboot changes work just fine for me, but poweroff does not:
[ OK ] Reached target Final Step.
Starting Power-Off...
reboot: Power down
Unable to poweroff system
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G W 4.1.0-rc7+ #1
Hardware name: APM X-Gene Mustang board (DT)
Call trace:
[<ffffffc00008990c>] dump_backtrace+0x0/0x11c
[<ffffffc000089a38>] show_stack+0x10/0x1c
[<ffffffc0005b447c>] dump_stack+0x88/0xc8
[<ffffffc0005b3374>] panic+0xe0/0x220
[<ffffffc0000b5f24>] do_exit+0x990/0x994
[<ffffffc0000d06bc>] SyS_reboot+0x14c/0x208
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
-dann
> Signed-off-by: Tai Nguyen <[email protected]>
> ---
> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts b/arch/arm64/boot/dts/apm/apm-mustang.dts
> index 83578e7..910d561 100644
> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
> @@ -23,6 +23,18 @@
> device_type = "memory";
> reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
> };
> +
> + poweroff_mbox: poweroff_mbox@10548000 {
> + compatible = "syscon";
> + reg = <0x0 0x10548000 0x0 0x30>;
> + };
> +
> + poweroff: poweroff@10548010 {
> + compatible = "syscon-poweroff";
> + regmap = <&poweroff_mbox>;
> + offset = <0x10>;
> + mask = <0x1>;
> + };
> };
>
> &pcie0clk {
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Dann,
On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier <[email protected]> wrote:
> On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen <[email protected]> wrote:
>> This patch adds syscon poweroff device node to support poweroff feature
>> on APM X-Gene Mustang platform
>
> hey Tai,
> The reboot changes work just fine for me, but poweroff does not:
>
> [ OK ] Reached target Final Step.
> Starting Power-Off...
> reboot: Power down
> Unable to poweroff system
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>
> CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G W 4.1.0-rc7+ #1
> Hardware name: APM X-Gene Mustang board (DT)
> Call trace:
> [<ffffffc00008990c>] dump_backtrace+0x0/0x11c
> [<ffffffc000089a38>] show_stack+0x10/0x1c
> [<ffffffc0005b447c>] dump_stack+0x88/0xc8
> [<ffffffc0005b3374>] panic+0xe0/0x220
> [<ffffffc0000b5f24>] do_exit+0x990/0x994
> [<ffffffc0000d06bc>] SyS_reboot+0x14c/0x208
> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>
> -dann
>
Thanks for testing my patches.
On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
It requires a firmware update to support power off feature.
May I ask what firmware version you're running on?
Tai
>> Signed-off-by: Tai Nguyen <[email protected]>
>> ---
>> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts b/arch/arm64/boot/dts/apm/apm-mustang.dts
>> index 83578e7..910d561 100644
>> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
>> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
>> @@ -23,6 +23,18 @@
>> device_type = "memory";
>> reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
>> };
>> +
>> + poweroff_mbox: poweroff_mbox@10548000 {
>> + compatible = "syscon";
>> + reg = <0x0 0x10548000 0x0 0x30>;
>> + };
>> +
>> + poweroff: poweroff@10548010 {
>> + compatible = "syscon-poweroff";
>> + regmap = <&poweroff_mbox>;
>> + offset = <0x10>;
>> + mask = <0x1>;
>> + };
>> };
>>
>> &pcie0clk {
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Tai
On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen <[email protected]> wrote:
> Hi Dann,
>
> On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier <[email protected]> wrote:
>> On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen <[email protected]> wrote:
>>> This patch adds syscon poweroff device node to support poweroff feature
>>> on APM X-Gene Mustang platform
>>
>> hey Tai,
>> The reboot changes work just fine for me, but poweroff does not:
>>
>> [ OK ] Reached target Final Step.
>> Starting Power-Off...
>> reboot: Power down
>> Unable to poweroff system
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>>
>> CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G W 4.1.0-rc7+ #1
>> Hardware name: APM X-Gene Mustang board (DT)
>> Call trace:
>> [<ffffffc00008990c>] dump_backtrace+0x0/0x11c
>> [<ffffffc000089a38>] show_stack+0x10/0x1c
>> [<ffffffc0005b447c>] dump_stack+0x88/0xc8
>> [<ffffffc0005b3374>] panic+0xe0/0x220
>> [<ffffffc0000b5f24>] do_exit+0x990/0x994
>> [<ffffffc0000d06bc>] SyS_reboot+0x14c/0x208
>> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>>
>> -dann
>>
>
> Thanks for testing my patches.
> On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
> It requires a firmware update to support power off feature.
> May I ask what firmware version you're running on?
Sure, 1.15.12.
-dann
> Tai
>
>
>>> Signed-off-by: Tai Nguyen <[email protected]>
>>> ---
>>> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>> index 83578e7..910d561 100644
>>> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
>>> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>> @@ -23,6 +23,18 @@
>>> device_type = "memory";
>>> reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
>>> };
>>> +
>>> + poweroff_mbox: poweroff_mbox@10548000 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0x10548000 0x0 0x30>;
>>> + };
>>> +
>>> + poweroff: poweroff@10548010 {
>>> + compatible = "syscon-poweroff";
>>> + regmap = <&poweroff_mbox>;
>>> + offset = <0x10>;
>>> + mask = <0x1>;
>>> + };
>>> };
>>>
>>> &pcie0clk {
>>> --
>>> 1.7.9.5
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> [email protected]
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Tai
On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen <[email protected]> wrote:
> This patch adds syscon reboot device node to support reboot feature on APM X-Gene platform
Tested-by: dann frazier <[email protected]>
> Signed-off-by: Feng Kan <[email protected]>
> Signed-off-by: Tai Nguyen <[email protected]>
> ---
> arch/arm64/boot/dts/apm/apm-storm.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> index c8d3e0e..16efcf7 100644
> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> @@ -710,5 +710,17 @@
> dma-coherent;
> clocks = <&dmaclk 0>;
> };
> +
> + scu: system-clk-controller@17000000 {
> + compatible = "apm,xgene-scu","syscon";
> + reg = <0x0 0x17000000 0x0 0x400>;
> + };
> +
> + reboot: reboot@17000014 {
> + compatible = "syscon-reboot";
> + regmap = <&scu>;
> + offset = <0x14>;
> + mask = <0x1>;
> + };
> };
> };
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Dann,
On Tue, Jun 9, 2015 at 8:31 AM, Dann Frazier <[email protected]> wrote:
> On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen <[email protected]> wrote:
>> Hi Dann,
>>
>> On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier <[email protected]> wrote:
>>> On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen <[email protected]> wrote:
>>>> This patch adds syscon poweroff device node to support poweroff feature
>>>> on APM X-Gene Mustang platform
>>>
>>> hey Tai,
>>> The reboot changes work just fine for me, but poweroff does not:
>>>
>>> [ OK ] Reached target Final Step.
>>> Starting Power-Off...
>>> reboot: Power down
>>> Unable to poweroff system
>>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>>>
>>> CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G W 4.1.0-rc7+ #1
>>> Hardware name: APM X-Gene Mustang board (DT)
>>> Call trace:
>>> [<ffffffc00008990c>] dump_backtrace+0x0/0x11c
>>> [<ffffffc000089a38>] show_stack+0x10/0x1c
>>> [<ffffffc0005b447c>] dump_stack+0x88/0xc8
>>> [<ffffffc0005b3374>] panic+0xe0/0x220
>>> [<ffffffc0000b5f24>] do_exit+0x990/0x994
>>> [<ffffffc0000d06bc>] SyS_reboot+0x14c/0x208
>>> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>>>
>>> -dann
>>>
>>
>> Thanks for testing my patches.
>> On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
>> It requires a firmware update to support power off feature.
>> May I ask what firmware version you're running on?
>
> Sure, 1.15.12.
>
> -dann
>
Just want to confirm you are booting in boot strap mode and had
SLIMpro firmware updated to 1.15.12 as well.
To check this, you should see this message in boot loader.
Slimpro FW:
Ver: 2.4 (build 01.15.12.00 2015/05/20)
I tested on a Mustang A3, this works just fine.
- Tai
>> Tai
>>
>>
>>>> Signed-off-by: Tai Nguyen <[email protected]>
>>>> ---
>>>> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
>>>> 1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>> index 83578e7..910d561 100644
>>>> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>> @@ -23,6 +23,18 @@
>>>> device_type = "memory";
>>>> reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
>>>> };
>>>> +
>>>> + poweroff_mbox: poweroff_mbox@10548000 {
>>>> + compatible = "syscon";
>>>> + reg = <0x0 0x10548000 0x0 0x30>;
>>>> + };
>>>> +
>>>> + poweroff: poweroff@10548010 {
>>>> + compatible = "syscon-poweroff";
>>>> + regmap = <&poweroff_mbox>;
>>>> + offset = <0x10>;
>>>> + mask = <0x1>;
>>>> + };
>>>> };
>>>>
>>>> &pcie0clk {
>>>> --
>>>> 1.7.9.5
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> [email protected]
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>> --
>> Tai
--
Tai
On Tue, Jun 9, 2015 at 9:31 AM, Dann Frazier <[email protected]> wrote:
> On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen <[email protected]> wrote:
>> Hi Dann,
>>
>> On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier <[email protected]> wrote:
>>> On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen <[email protected]> wrote:
>>>> This patch adds syscon poweroff device node to support poweroff feature
>>>> on APM X-Gene Mustang platform
>>>
>>> hey Tai,
>>> The reboot changes work just fine for me, but poweroff does not:
>>>
>>> [ OK ] Reached target Final Step.
>>> Starting Power-Off...
>>> reboot: Power down
>>> Unable to poweroff system
>>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>>>
>>> CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G W 4.1.0-rc7+ #1
>>> Hardware name: APM X-Gene Mustang board (DT)
>>> Call trace:
>>> [<ffffffc00008990c>] dump_backtrace+0x0/0x11c
>>> [<ffffffc000089a38>] show_stack+0x10/0x1c
>>> [<ffffffc0005b447c>] dump_stack+0x88/0xc8
>>> [<ffffffc0005b3374>] panic+0xe0/0x220
>>> [<ffffffc0000b5f24>] do_exit+0x990/0x994
>>> [<ffffffc0000d06bc>] SyS_reboot+0x14c/0x208
>>> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>>>
>>> -dann
>>>
>>
>> Thanks for testing my patches.
>> On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
>> It requires a firmware update to support power off feature.
>> May I ask what firmware version you're running on?
>
> Sure, 1.15.12.
Tai worked with me offline. For reference, this requires an updated
SlimPro firmware in addition to the u-boot update. Verified it works
for me after the update, so:
Tested-by: dann frazier <[email protected]>
> -dann
>
>> Tai
>>
>>
>>>> Signed-off-by: Tai Nguyen <[email protected]>
>>>> ---
>>>> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
>>>> 1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>> index 83578e7..910d561 100644
>>>> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>> @@ -23,6 +23,18 @@
>>>> device_type = "memory";
>>>> reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
>>>> };
>>>> +
>>>> + poweroff_mbox: poweroff_mbox@10548000 {
>>>> + compatible = "syscon";
>>>> + reg = <0x0 0x10548000 0x0 0x30>;
>>>> + };
>>>> +
>>>> + poweroff: poweroff@10548010 {
>>>> + compatible = "syscon-poweroff";
>>>> + regmap = <&poweroff_mbox>;
>>>> + offset = <0x10>;
>>>> + mask = <0x1>;
>>>> + };
>>>> };
>>>>
>>>> &pcie0clk {
>>>> --
>>>> 1.7.9.5
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> [email protected]
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>> --
>> Tai
On Wed, Jun 10, 2015 at 12:13 PM, Dann Frazier
<[email protected]> wrote:
> On Tue, Jun 9, 2015 at 9:31 AM, Dann Frazier <[email protected]> wrote:
>> On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen <[email protected]> wrote:
>>> Hi Dann,
>>>
>>> On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier <[email protected]> wrote:
>>>> On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen <[email protected]> wrote:
>>>>> This patch adds syscon poweroff device node to support poweroff feature
>>>>> on APM X-Gene Mustang platform
>>>>
>>>> hey Tai,
>>>> The reboot changes work just fine for me, but poweroff does not:
>>>>
>>>> [ OK ] Reached target Final Step.
>>>> Starting Power-Off...
>>>> reboot: Power down
>>>> Unable to poweroff system
>>>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>>>>
>>>> CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G W 4.1.0-rc7+ #1
>>>> Hardware name: APM X-Gene Mustang board (DT)
>>>> Call trace:
>>>> [<ffffffc00008990c>] dump_backtrace+0x0/0x11c
>>>> [<ffffffc000089a38>] show_stack+0x10/0x1c
>>>> [<ffffffc0005b447c>] dump_stack+0x88/0xc8
>>>> [<ffffffc0005b3374>] panic+0xe0/0x220
>>>> [<ffffffc0000b5f24>] do_exit+0x990/0x994
>>>> [<ffffffc0000d06bc>] SyS_reboot+0x14c/0x208
>>>> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>>>>
>>>> -dann
>>>>
>>>
>>> Thanks for testing my patches.
>>> On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
>>> It requires a firmware update to support power off feature.
>>> May I ask what firmware version you're running on?
>>
>> Sure, 1.15.12.
>
> Tai worked with me offline. For reference, this requires an updated
> SlimPro firmware in addition to the u-boot update. Verified it works
> for me after the update, so:
>
> Tested-by: dann frazier <[email protected]>
Looks good.
Acked-by: Moritz Fischer <[email protected]>
>
>> -dann
>>
>>> Tai
>>>
>>>
>>>>> Signed-off-by: Tai Nguyen <[email protected]>
>>>>> ---
>>>>> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
>>>>> 1 file changed, 12 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>>> index 83578e7..910d561 100644
>>>>> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>>> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>>> @@ -23,6 +23,18 @@
>>>>> device_type = "memory";
>>>>> reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
>>>>> };
>>>>> +
>>>>> + poweroff_mbox: poweroff_mbox@10548000 {
>>>>> + compatible = "syscon";
>>>>> + reg = <0x0 0x10548000 0x0 0x30>;
>>>>> + };
>>>>> +
>>>>> + poweroff: poweroff@10548010 {
>>>>> + compatible = "syscon-poweroff";
>>>>> + regmap = <&poweroff_mbox>;
>>>>> + offset = <0x10>;
>>>>> + mask = <0x1>;
>>>>> + };
>>>>> };
>>>>>
>>>>> &pcie0clk {
>>>>> --
>>>>> 1.7.9.5
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> linux-arm-kernel mailing list
>>>>> [email protected]
>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>>
>>>
>>> --
>>> Tai
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, Jun 02, 2015 at 12:19:05PM -0700, Tai Nguyen wrote:
> This patch set adds syscon reboot/poweroff device nodes to support reboot and
> poweroff features on X-Gene platform.
>
> Tai Nguyen (2):
> power: reset: Add syscon reboot device node for APM X-Gene platform
> power: reset: Add syscon poweroff device node for APM X-Gene Mustang platform
>
> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
> arch/arm64/boot/dts/apm/apm-storm.dtsi | 12 ++++++++++++
> 2 files changed, 24 insertions(+)
Hi,
It's unclear to me what you want to happen to these patches. They are
sent to a long list of to-recipients, one of which is [email protected]. In
general, specify the person you want to take action on the patch in to
with the rest on cc.
We generally ask that patches first go to the subarch maintainers,
and they in turn send it on to us (either through a pull request or
by sending the patches to be applied). In the case of X-Gene, there is
no general platform maintainer so we keep getting patches from various
engineers at APM and it's unclear to us what your intentions are.
I'd prefer to see one (to start with) person in charge of these (i.e. one
maintainer from the APM side). Please add that person to the MAINTAINERS
file as well.
Thanks!
-Olof
Hi Olof,
>> This patch set adds syscon reboot/poweroff device nodes to support reboot and
>> poweroff features on X-Gene platform.
>>
>> Tai Nguyen (2):
>> power: reset: Add syscon reboot device node for APM X-Gene platform
>> power: reset: Add syscon poweroff device node for APM X-Gene Mustang platform
>>
>> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
>> arch/arm64/boot/dts/apm/apm-storm.dtsi | 12 ++++++++++++
>> 2 files changed, 24 insertions(+)
>
> Hi,
>
> It's unclear to me what you want to happen to these patches. They are
> sent to a long list of to-recipients, one of which is [email protected]. In
> general, specify the person you want to take action on the patch in to
> with the rest on cc.
Is there an owner for all DT node files? Is that Catalina as he is
owner for ARM64 arch folder?
>
> We generally ask that patches first go to the subarch maintainers,
> and they in turn send it on to us (either through a pull request or
> by sending the patches to be applied). In the case of X-Gene, there is
> no general platform maintainer so we keep getting patches from various
> engineers at APM and it's unclear to us what your intentions are.
>
> I'd prefer to see one (to start with) person in charge of these (i.e. one
> maintainer from the APM side). Please add that person to the MAINTAINERS
> file as well.
Are you suggesting that we have one person to start an GIT with
kernel.org to keep all these misc ack'ed patches for X-Gene (APM) that
don't seems to have an maintainer/home. Then request an pull by you?
Thanks,
Loc
Hi,
On Wed, Jul 22, 2015 at 10:46 AM, Loc Ho <[email protected]> wrote:
> Hi Olof,
>
>>> This patch set adds syscon reboot/poweroff device nodes to support reboot and
>>> poweroff features on X-Gene platform.
>>>
>>> Tai Nguyen (2):
>>> power: reset: Add syscon reboot device node for APM X-Gene platform
>>> power: reset: Add syscon poweroff device node for APM X-Gene Mustang platform
>>>
>>> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
>>> arch/arm64/boot/dts/apm/apm-storm.dtsi | 12 ++++++++++++
>>> 2 files changed, 24 insertions(+)
>>
>> Hi,
>>
>> It's unclear to me what you want to happen to these patches. They are
>> sent to a long list of to-recipients, one of which is [email protected]. In
>> general, specify the person you want to take action on the patch in to
>> with the rest on cc.
>
> Is there an owner for all DT node files? Is that Catalina as he is
> owner for ARM64 arch folder?
The ARM64 DT changes get merged through arm-soc, i.e. they get sent to
[email protected] by the platform maintainers and picked up by us from
there (Arnd, Kevin or myself).
>> We generally ask that patches first go to the subarch maintainers,
>> and they in turn send it on to us (either through a pull request or
>> by sending the patches to be applied). In the case of X-Gene, there is
>> no general platform maintainer so we keep getting patches from various
>> engineers at APM and it's unclear to us what your intentions are.
>>
>> I'd prefer to see one (to start with) person in charge of these (i.e. one
>> maintainer from the APM side). Please add that person to the MAINTAINERS
>> file as well.
>
> Are you suggesting that we have one person to start an GIT with
> kernel.org to keep all these misc ack'ed patches for X-Gene (APM) that
> don't seems to have an maintainer/home. Then request an pull by you?
Pull requests are convenient for us, but if it's just a patch or two,
sending them directly in email is fine as well.
What I want to avoid is a large number of people sending us patches
directly, which is why we ask for platform maintainers to coordinate
and aggregate patches to send on to us. That way we have one person
down the chain that we knows how we want the code delivered, and that
can do a round of reviews before we get it.
Thanks!
-Olof
Hi Olof,,
>>
>>>> This patch set adds syscon reboot/poweroff device nodes to support reboot and
>>>> poweroff features on X-Gene platform.
>>>>
>>>> Tai Nguyen (2):
>>>> power: reset: Add syscon reboot device node for APM X-Gene platform
>>>> power: reset: Add syscon poweroff device node for APM X-Gene Mustang platform
>>>>
>>>> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
>>>> arch/arm64/boot/dts/apm/apm-storm.dtsi | 12 ++++++++++++
>>>> 2 files changed, 24 insertions(+)
>>>
>>> Hi,
>>>
>>> It's unclear to me what you want to happen to these patches. They are
>>> sent to a long list of to-recipients, one of which is [email protected]. In
>>> general, specify the person you want to take action on the patch in to
>>> with the rest on cc.
>>
>> Is there an owner for all DT node files? Is that Catalina as he is
>> owner for ARM64 arch folder?
>
> The ARM64 DT changes get merged through arm-soc, i.e. they get sent to
> [email protected] by the platform maintainers and picked up by us from
> there (Arnd, Kevin or myself).
>
>>> We generally ask that patches first go to the subarch maintainers,
>>> and they in turn send it on to us (either through a pull request or
>>> by sending the patches to be applied). In the case of X-Gene, there is
>>> no general platform maintainer so we keep getting patches from various
>>> engineers at APM and it's unclear to us what your intentions are.
>>>
>>> I'd prefer to see one (to start with) person in charge of these (i.e. one
>>> maintainer from the APM side). Please add that person to the MAINTAINERS
>>> file as well.
>>
>> Are you suggesting that we have one person to start an GIT with
>> kernel.org to keep all these misc ack'ed patches for X-Gene (APM) that
>> don't seems to have an maintainer/home. Then request an pull by you?
>
> Pull requests are convenient for us, but if it's just a patch or two,
> sending them directly in email is fine as well.
If there is an chance in pulling this power off/reset patches for
4.2-rc4, can you pull in as patches? Otherwise, we will go the GIT
pull request.
>
> What I want to avoid is a large number of people sending us patches
> directly, which is why we ask for platform maintainers to coordinate
> and aggregate patches to send on to us. That way we have one person
> down the chain that we knows how we want the code delivered, and that
> can do a round of reviews before we get it.
We will get an GIT setup up for this and Duc Dang will contact you for
pull request when ready.
-Loc
On Wed, Jul 22, 2015 at 11:10 AM, Loc Ho <[email protected]> wrote:
> Hi Olof,,
>
>>>
>>>>> This patch set adds syscon reboot/poweroff device nodes to support reboot and
>>>>> poweroff features on X-Gene platform.
>>>>>
>>>>> Tai Nguyen (2):
>>>>> power: reset: Add syscon reboot device node for APM X-Gene platform
>>>>> power: reset: Add syscon poweroff device node for APM X-Gene Mustang platform
>>>>>
>>>>> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
>>>>> arch/arm64/boot/dts/apm/apm-storm.dtsi | 12 ++++++++++++
>>>>> 2 files changed, 24 insertions(+)
>>>>
>>>> Hi,
>>>>
>>>> It's unclear to me what you want to happen to these patches. They are
>>>> sent to a long list of to-recipients, one of which is [email protected]. In
>>>> general, specify the person you want to take action on the patch in to
>>>> with the rest on cc.
>>>
>>> Is there an owner for all DT node files? Is that Catalina as he is
>>> owner for ARM64 arch folder?
>>
>> The ARM64 DT changes get merged through arm-soc, i.e. they get sent to
>> [email protected] by the platform maintainers and picked up by us from
>> there (Arnd, Kevin or myself).
>>
>>>> We generally ask that patches first go to the subarch maintainers,
>>>> and they in turn send it on to us (either through a pull request or
>>>> by sending the patches to be applied). In the case of X-Gene, there is
>>>> no general platform maintainer so we keep getting patches from various
>>>> engineers at APM and it's unclear to us what your intentions are.
>>>>
>>>> I'd prefer to see one (to start with) person in charge of these (i.e. one
>>>> maintainer from the APM side). Please add that person to the MAINTAINERS
>>>> file as well.
>>>
>>> Are you suggesting that we have one person to start an GIT with
>>> kernel.org to keep all these misc ack'ed patches for X-Gene (APM) that
>>> don't seems to have an maintainer/home. Then request an pull by you?
>>
>> Pull requests are convenient for us, but if it's just a patch or two,
>> sending them directly in email is fine as well.
>
> If there is an chance in pulling this power off/reset patches for
> 4.2-rc4, can you pull in as patches? Otherwise, we will go the GIT
> pull request.
We can definitely pick them up and queue them for 4.3 (see below). We
normally want the bulk of patches before -rc4/5, but we take smaller
updates closer to the merge window as well.
>> What I want to avoid is a large number of people sending us patches
>> directly, which is why we ask for platform maintainers to coordinate
>> and aggregate patches to send on to us. That way we have one person
>> down the chain that we knows how we want the code delivered, and that
>> can do a round of reviews before we get it.
>
> We will get an GIT setup up for this and Duc Dang will contact you for
> pull request when ready.
Ok, sounds good. If you have people in the bay area that need PGP keys
signed for this, I'd be happy to help.
As far as the current DT patches, there's been several sent by
different people. Please aggregate them into one patch series and send
that (as git send-email is fine) to us to queue for 4.3.
Thanks!
-Olof
Hi Olof,
On Wed, Jul 22, 2015 at 11:20 AM, Olof Johansson <[email protected]> wrote:
> On Wed, Jul 22, 2015 at 11:10 AM, Loc Ho <[email protected]> wrote:
>> Hi Olof,,
>>
>>>>
>>>>>> This patch set adds syscon reboot/poweroff device nodes to support reboot and
>>>>>> poweroff features on X-Gene platform.
>>>>>>
>>>>>> Tai Nguyen (2):
>>>>>> power: reset: Add syscon reboot device node for APM X-Gene platform
>>>>>> power: reset: Add syscon poweroff device node for APM X-Gene Mustang platform
>>>>>>
>>>>>> arch/arm64/boot/dts/apm/apm-mustang.dts | 12 ++++++++++++
>>>>>> arch/arm64/boot/dts/apm/apm-storm.dtsi | 12 ++++++++++++
>>>>>> 2 files changed, 24 insertions(+)
>>>>>
>>>>> Hi,
>>>>>
>>>>> It's unclear to me what you want to happen to these patches. They are
>>>>> sent to a long list of to-recipients, one of which is [email protected]. In
>>>>> general, specify the person you want to take action on the patch in to
>>>>> with the rest on cc.
>>>>
>>>> Is there an owner for all DT node files? Is that Catalina as he is
>>>> owner for ARM64 arch folder?
>>>
>>> The ARM64 DT changes get merged through arm-soc, i.e. they get sent to
>>> [email protected] by the platform maintainers and picked up by us from
>>> there (Arnd, Kevin or myself).
>>>
>>>>> We generally ask that patches first go to the subarch maintainers,
>>>>> and they in turn send it on to us (either through a pull request or
>>>>> by sending the patches to be applied). In the case of X-Gene, there is
>>>>> no general platform maintainer so we keep getting patches from various
>>>>> engineers at APM and it's unclear to us what your intentions are.
>>>>>
>>>>> I'd prefer to see one (to start with) person in charge of these (i.e. one
>>>>> maintainer from the APM side). Please add that person to the MAINTAINERS
>>>>> file as well.
>>>>
>>>> Are you suggesting that we have one person to start an GIT with
>>>> kernel.org to keep all these misc ack'ed patches for X-Gene (APM) that
>>>> don't seems to have an maintainer/home. Then request an pull by you?
>>>
>>> Pull requests are convenient for us, but if it's just a patch or two,
>>> sending them directly in email is fine as well.
>>
>> If there is an chance in pulling this power off/reset patches for
>> 4.2-rc4, can you pull in as patches? Otherwise, we will go the GIT
>> pull request.
>
> We can definitely pick them up and queue them for 4.3 (see below). We
> normally want the bulk of patches before -rc4/5, but we take smaller
> updates closer to the merge window as well.
>
>>> What I want to avoid is a large number of people sending us patches
>>> directly, which is why we ask for platform maintainers to coordinate
>>> and aggregate patches to send on to us. That way we have one person
>>> down the chain that we knows how we want the code delivered, and that
>>> can do a round of reviews before we get it.
>>
>> We will get an GIT setup up for this and Duc Dang will contact you for
>> pull request when ready.
We are debating whether we should setup a company server (where we can
have full control about storage, user permissions, backup, ...) or
just use github.com to host our X-Gene kernel tree.
Github seems already provide everything we need for a public source
tree. Per your experience, what is your (and probably other
maintainers) reference in git hosting server? Is there any
inconvenience or difficulty for the maintainers to pull/merge code
from Github versus from a company server?
Thanks!
>
> Ok, sounds good. If you have people in the bay area that need PGP keys
> signed for this, I'd be happy to help.
>
> As far as the current DT patches, there's been several sent by
> different people. Please aggregate them into one patch series and send
> that (as git send-email is fine) to us to queue for 4.3.
>
>
> Thanks!
>
>
> -Olof
--
Duc Dang.
On Sat, Jul 25, 2015 at 11:34:42AM -0700, Duc Dang wrote:
> Hi Olof,
>
> We are debating whether we should setup a company server (where we can
> have full control about storage, user permissions, backup, ...) or
> just use github.com to host our X-Gene kernel tree.
>
> Github seems already provide everything we need for a public source
> tree. Per your experience, what is your (and probably other
> maintainers) reference in git hosting server? Is there any
> inconvenience or difficulty for the maintainers to pull/merge code
> from Github versus from a company server?
Hosting on github is fine with us in general. We do prefer to get
signed pull requests in particular when they come from other sources
than kernel.org, mostly because there's another third party involved in
hosting the repo and by using signed tags there's less room for anyone
to do bad stuff with the repository without someone noticing.
If you host on github, please still use native git pull requests and not the
ones that github provides via the web interface.
Note however, that given the total volume of patches there's no strong need for
you to have a public repo just to send code to us -- we're happy applying
patches at the volumes we're currently looking at. I can imagine other reasons
for why you would like to have a public repo though.
Thanks,
-Olof
On Sun, Jul 26, 2015 at 11:37 AM, Olof Johansson <[email protected]> wrote:
> On Sat, Jul 25, 2015 at 11:34:42AM -0700, Duc Dang wrote:
>> Hi Olof,
>>
>> We are debating whether we should setup a company server (where we can
>> have full control about storage, user permissions, backup, ...) or
>> just use github.com to host our X-Gene kernel tree.
>>
>> Github seems already provide everything we need for a public source
>> tree. Per your experience, what is your (and probably other
>> maintainers) reference in git hosting server? Is there any
>> inconvenience or difficulty for the maintainers to pull/merge code
>> from Github versus from a company server?
>
> Hosting on github is fine with us in general. We do prefer to get
> signed pull requests in particular when they come from other sources
> than kernel.org, mostly because there's another third party involved in
> hosting the repo and by using signed tags there's less room for anyone
> to do bad stuff with the repository without someone noticing.
>
> If you host on github, please still use native git pull requests and not the
> ones that github provides via the web interface.
>
> Note however, that given the total volume of patches there's no strong need for
> you to have a public repo just to send code to us -- we're happy applying
> patches at the volumes we're currently looking at. I can imagine other reasons
> for why you would like to have a public repo though.
>
Thanks for the information, Olof.
We are setting up a public repo on Github. I will make sure that
native git pull request is used.
I will need your help in signing the PGP key when the repo is ready.
>
> Thanks,
>
> -Olof
--
Regards,
Duc Dang.
On Sun, Jul 26, 2015 at 11:37 AM, Olof Johansson <[email protected]> wrote:
>
> On Sat, Jul 25, 2015 at 11:34:42AM -0700, Duc Dang wrote:
> > Hi Olof,
> >
> > We are debating whether we should setup a company server (where we can
> > have full control about storage, user permissions, backup, ...) or
> > just use github.com to host our X-Gene kernel tree.
> >
> > Github seems already provide everything we need for a public source
> > tree. Per your experience, what is your (and probably other
> > maintainers) reference in git hosting server? Is there any
> > inconvenience or difficulty for the maintainers to pull/merge code
> > from Github versus from a company server?
>
> Hosting on github is fine with us in general. We do prefer to get
> signed pull requests in particular when they come from other sources
> than kernel.org, mostly because there's another third party involved in
> hosting the repo and by using signed tags there's less room for anyone
> to do bad stuff with the repository without someone noticing.
>
> If you host on github, please still use native git pull requests and not the
> ones that github provides via the web interface.
>
> Note however, that given the total volume of patches there's no strong need for
> you to have a public repo just to send code to us -- we're happy applying
> patches at the volumes we're currently looking at. I can imagine other reasons
> for why you would like to have a public repo though.
Hi Olof,
I have APM X-Gene git ready on github. According to your response
above, I need to
send a signed pull request. I created a PGP key on public server
(https://pgp.mit.edu/pks/lookup?search=duc+dang&op=index) and signed the tag on
APM X-Gene tree with my key.
Please let me know if I need anything else before sending the git pull
request to you.
My key is not signed by any maintainer yet, would you mind to arrange some
time next week to meet and help sign my key as well?
>
>
> Thanks,
>
> -Olof
--
Thanks and regards,
Duc Dang.
Hi,
On Fri, Aug 28, 2015 at 1:00 PM, Duc Dang <[email protected]> wrote:
> On Sun, Jul 26, 2015 at 11:37 AM, Olof Johansson <[email protected]> wrote:
>>
>> On Sat, Jul 25, 2015 at 11:34:42AM -0700, Duc Dang wrote:
>> > Hi Olof,
>> >
>> > We are debating whether we should setup a company server (where we can
>> > have full control about storage, user permissions, backup, ...) or
>> > just use github.com to host our X-Gene kernel tree.
>> >
>> > Github seems already provide everything we need for a public source
>> > tree. Per your experience, what is your (and probably other
>> > maintainers) reference in git hosting server? Is there any
>> > inconvenience or difficulty for the maintainers to pull/merge code
>> > from Github versus from a company server?
>>
>> Hosting on github is fine with us in general. We do prefer to get
>> signed pull requests in particular when they come from other sources
>> than kernel.org, mostly because there's another third party involved in
>> hosting the repo and by using signed tags there's less room for anyone
>> to do bad stuff with the repository without someone noticing.
>>
>> If you host on github, please still use native git pull requests and not the
>> ones that github provides via the web interface.
>>
>> Note however, that given the total volume of patches there's no strong need for
>> you to have a public repo just to send code to us -- we're happy applying
>> patches at the volumes we're currently looking at. I can imagine other reasons
>> for why you would like to have a public repo though.
>
> Hi Olof,
>
> I have APM X-Gene git ready on github. According to your response
> above, I need to
> send a signed pull request. I created a PGP key on public server
> (https://pgp.mit.edu/pks/lookup?search=duc+dang&op=index) and signed the tag on
> APM X-Gene tree with my key.
>
> Please let me know if I need anything else before sending the git pull
> request to you.
> My key is not signed by any maintainer yet, would you mind to arrange some
> time next week to meet and help sign my key as well?
Yeah, I can do that, and you can get more signatures at Linaro Connect
in case you're attending.
(let's sort out details off-list).
-Olof