[PATCH 1/2] ARM: dts: rockchip: Split GPIO keys for veyron into multiple devices

[PATCH 1/2] ARM: dts: rockchip: Split GPIO keys for veyron into multiple devices

[Matthias Kaehlcke]

With a single device DT overrides can become messy, especially when
keys are added or removed. Multiple devices also allow to
enable/disable wakeup per key/group.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
 .../boot/dts/rk3288-veyron-chromebook.dtsi    | 26 +++++++------
 arch/arm/boot/dts/rk3288-veyron-minnie.dts    | 38 ++++++++++---------
 arch/arm/boot/dts/rk3288-veyron-pinky.dts     |  2 +-
 arch/arm/boot/dts/rk3288-veyron.dtsi          |  4 +-
 4 files changed, 37 insertions(+), 33 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index fbef34578100..c5f71af84a40 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -70,6 +70,20 @@
 		pinctrl-0 = <&ac_present_ap>;
 	};
 
+	lid_switch: lid-switch {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&ap_lid_int_l>;
+		lid {
+			label = "Lid";
+			gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+			linux,code = <0>; /* SW_LID */
+			linux,input-type = <5>; /* EV_SW */
+			debounce-interval = <1>;
+		};
+	};
+
 	panel: panel {
 		compatible ="innolux,n116bge", "simple-panel";
 		status = "okay";
@@ -149,18 +163,6 @@
 	status = "okay";
 };
 
-&gpio_keys {
-	pinctrl-0 = <&pwr_key_l &ap_lid_int_l>;
-	lid {
-		label = "Lid";
-		gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
-		wakeup-source;
-		linux,code = <0>; /* SW_LID */
-		linux,input-type = <5>; /* EV_SW */
-		debounce-interval = <1>;
-	};
-};
-
 &pwm0 {
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index a65099b4aef1..b2cc70a08554 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -48,6 +48,26 @@
 		regulator-boot-on;
 		vin-supply = <&vcc18_wl>;
 	};
+
+	volume_buttons: volume-buttons {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&volum_down_l &volum_up_l>;
+
+		volum_down {
+			label = "Volum_down";
+			gpios = <&gpio5 RK_PB3 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_VOLUMEDOWN>;
+			debounce-interval = <100>;
+		};
+
+		volum_up {
+			label = "Volum_up";
+			gpios = <&gpio5 RK_PB2 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_VOLUMEUP>;
+			debounce-interval = <100>;
+		};
+	};
 };
 
 &backlight {
@@ -90,24 +110,6 @@
 	pwm-off-delay-ms = <200>;
 };
 
-&gpio_keys {
-	pinctrl-0 = <&pwr_key_l &ap_lid_int_l &volum_down_l &volum_up_l>;
-
-	volum_down {
-		label = "Volum_down";
-		gpios = <&gpio5 RK_PB3 GPIO_ACTIVE_LOW>;
-		linux,code = <KEY_VOLUMEDOWN>;
-		debounce-interval = <100>;
-	};
-
-	volum_up {
-		label = "Volum_up";
-		gpios = <&gpio5 RK_PB2 GPIO_ACTIVE_LOW>;
-		linux,code = <KEY_VOLUMEUP>;
-		debounce-interval = <100>;
-	};
-};
-
 &i2c_tunnel {
 	battery: bq27500@55 {
 		compatible = "ti,bq27500";
diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
index 9645be7b3d8c..9b6f4d9b03b6 100644
--- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
@@ -35,7 +35,7 @@
 	force-hpd;
 };
 
-&gpio_keys {
+&lid_switch {
 	pinctrl-0 = <&pwr_key_h &ap_lid_int_l>;
 
 	power {
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 90c8312d01ff..cc4c3595f145 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -23,11 +23,11 @@
 		reg = <0x0 0x0 0x0 0x80000000>;
 	};
 
-	gpio_keys: gpio-keys {
+	power_button: power-button {
 		compatible = "gpio-keys";
-
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwr_key_l>;
+
 		power {
 			label = "Power";
 			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH 2/2] ARM: dts: rockchip: Configure BT_HOST_WAKE as wake-up signal on veyron

[Matthias Kaehlcke]

This enables wake up on Bluetooth activity when the device is
suspended. The BT_HOST_WAKE signal is only connected on devices
with BT module that are connected through UART.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
 arch/arm/boot/dts/rk3288-veyron.dtsi | 29 ++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index cc4c3595f145..145cac7c0847 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -23,6 +23,31 @@
 		reg = <0x0 0x0 0x0 0x80000000>;
 	};
 
+	bt_activity: bt-activity {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_host_wake>;
+
+		/*
+		 * HACK: until we have an LPM driver, we'll use an
+		 * ugly GPIO key to allow Bluetooth to wake from S3.
+		 * This is expected to only be used by BT modules that
+		 * use UART for comms.  For BT modules that talk over
+		 * SDIO we should use a wakeup mechanism related to SDIO.
+		 *
+		 * Use KEY_RESERVED here since that will work as a wakeup but
+		 * doesn't get reported to higher levels (so doesn't confuse
+		 * Chrome).
+		 */
+		bt-wake {
+			label = "BT Wakeup";
+			gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
+			linux,code = <KEY_RESERVED>;
+			wakeup-source;
+		};
+
+	};
+
 	power_button: power-button {
 		compatible = "gpio-keys";
 		pinctrl-names = "default";
@@ -555,6 +580,10 @@
 			rockchip,pins = <4 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
 
+		bt_host_wake: bt-host-wake {
+			rockchip,pins = <4 31 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
 		/*
 		 * We run sdio0 at max speed; bump up drive strength.
 		 * We also have external pulls, so disable the internal ones.
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

Re: [PATCH 2/2] ARM: dts: rockchip: Configure BT_HOST_WAKE as wake-up signal on veyron

[Heiko Stübner]

Am Mittwoch, 5. Juni 2019, 22:43:20 CEST schrieb Matthias Kaehlcke:
> This enables wake up on Bluetooth activity when the device is
> suspended. The BT_HOST_WAKE signal is only connected on devices
> with BT module that are connected through UART.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

Housekeeping question, with the two Signed-off-by lines, is Doug the
original author, or was this Co-developer-by?

Heiko

> ---
>  arch/arm/boot/dts/rk3288-veyron.dtsi | 29 ++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
> index cc4c3595f145..145cac7c0847 100644
> --- a/arch/arm/boot/dts/rk3288-veyron.dtsi
> +++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
> @@ -23,6 +23,31 @@
>  		reg = <0x0 0x0 0x0 0x80000000>;
>  	};
>  
> +	bt_activity: bt-activity {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bt_host_wake>;
> +
> +		/*
> +		 * HACK: until we have an LPM driver, we'll use an
> +		 * ugly GPIO key to allow Bluetooth to wake from S3.
> +		 * This is expected to only be used by BT modules that
> +		 * use UART for comms.  For BT modules that talk over
> +		 * SDIO we should use a wakeup mechanism related to SDIO.
> +		 *
> +		 * Use KEY_RESERVED here since that will work as a wakeup but
> +		 * doesn't get reported to higher levels (so doesn't confuse
> +		 * Chrome).
> +		 */
> +		bt-wake {
> +			label = "BT Wakeup";
> +			gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
> +			linux,code = <KEY_RESERVED>;
> +			wakeup-source;
> +		};
> +
> +	};
> +
>  	power_button: power-button {
>  		compatible = "gpio-keys";
>  		pinctrl-names = "default";
> @@ -555,6 +580,10 @@
>  			rockchip,pins = <4 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
>  		};
>  
> +		bt_host_wake: bt-host-wake {
> +			rockchip,pins = <4 31 RK_FUNC_GPIO &pcfg_pull_down>;
> +		};
> +
>  		/*
>  		 * We run sdio0 at max speed; bump up drive strength.
>  		 * We also have external pulls, so disable the internal ones.
> 

Re: [PATCH 2/2] ARM: dts: rockchip: Configure BT_HOST_WAKE as wake-up signal on veyron

[Matthias Kaehlcke]

On Wed, Jun 05, 2019 at 11:11:12PM +0200, Heiko Stübner wrote:
> Am Mittwoch, 5. Juni 2019, 22:43:20 CEST schrieb Matthias Kaehlcke:
> > This enables wake up on Bluetooth activity when the device is
> > suspended. The BT_HOST_WAKE signal is only connected on devices
> > with BT module that are connected through UART.
> > 
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> 
> Housekeeping question, with the two Signed-off-by lines, is Doug the
> original author, or was this Co-developer-by?

Good question, it's derived from Doug's patch for CrOS 3.14 and
https://crrev.com/c/1575556 also from Doug. Let's say I did the
porting to upstream, but I'm pretty sure Doug spent more time on it.

Maybe I should resend it with Doug as author and include the original
commit message, which has more information.

Re: [PATCH 2/2] ARM: dts: rockchip: Configure BT_HOST_WAKE as wake-up signal on veyron

[Heiko Stübner]

Am Mittwoch, 5. Juni 2019, 23:24:27 CEST schrieb Matthias Kaehlcke:
> On Wed, Jun 05, 2019 at 11:11:12PM +0200, Heiko Stübner wrote:
> > Am Mittwoch, 5. Juni 2019, 22:43:20 CEST schrieb Matthias Kaehlcke:
> > > This enables wake up on Bluetooth activity when the device is
> > > suspended. The BT_HOST_WAKE signal is only connected on devices
> > > with BT module that are connected through UART.
> > > 
> > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > 
> > Housekeeping question, with the two Signed-off-by lines, is Doug the
> > original author, or was this Co-developer-by?
> 
> Good question, it's derived from Doug's patch for CrOS 3.14 and
> https://crrev.com/c/1575556 also from Doug. Let's say I did the
> porting to upstream, but I'm pretty sure Doug spent more time on it.
> 
> Maybe I should resend it with Doug as author and include the original
> commit message, which has more information.

It's just that the first Signed-off should be from the original author.
(And the sender the second)
In the co-developed-by case (see Kernel documentation) the order
doesn't matter.

Re: [PATCH 1/2] ARM: dts: rockchip: Split GPIO keys for veyron into multiple devices

[Heiko Stuebner]

Am Mittwoch, 5. Juni 2019, 22:43:19 CEST schrieb Matthias Kaehlcke:
> With a single device DT overrides can become messy, especially when
> keys are added or removed. Multiple devices also allow to
> enable/disable wakeup per key/group.
> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

applied for 5.3 with 2 minor changes, detailed below.

> ---
>  .../boot/dts/rk3288-veyron-chromebook.dtsi    | 26 +++++++------
>  arch/arm/boot/dts/rk3288-veyron-minnie.dts    | 38 ++++++++++---------
>  arch/arm/boot/dts/rk3288-veyron-pinky.dts     |  2 +-
>  arch/arm/boot/dts/rk3288-veyron.dtsi          |  4 +-
>  4 files changed, 37 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
> index fbef34578100..c5f71af84a40 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
> +++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
> @@ -70,6 +70,20 @@
>  		pinctrl-0 = <&ac_present_ap>;
>  	};
>  
> +	lid_switch: lid-switch {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&ap_lid_int_l>;

added a blank line here

> +		lid {
> +			label = "Lid";
> +			gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
> +			wakeup-source;
> +			linux,code = <0>; /* SW_LID */
> +			linux,input-type = <5>; /* EV_SW */

actually used the constants in the properties, we have the keycodes as
dt-binding header nowadays.


Heiko

Re: [PATCH 2/2] ARM: dts: rockchip: Configure BT_HOST_WAKE as wake-up signal on veyron

[Heiko Stuebner]

Am Mittwoch, 5. Juni 2019, 23:52:00 CEST schrieb Heiko Stübner:
> Am Mittwoch, 5. Juni 2019, 23:24:27 CEST schrieb Matthias Kaehlcke:
> > On Wed, Jun 05, 2019 at 11:11:12PM +0200, Heiko Stübner wrote:
> > > Am Mittwoch, 5. Juni 2019, 22:43:20 CEST schrieb Matthias Kaehlcke:
> > > > This enables wake up on Bluetooth activity when the device is
> > > > suspended. The BT_HOST_WAKE signal is only connected on devices
> > > > with BT module that are connected through UART.
> > > > 
> > > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > > 
> > > Housekeeping question, with the two Signed-off-by lines, is Doug the
> > > original author, or was this Co-developer-by?
> > 
> > Good question, it's derived from Doug's patch for CrOS 3.14 and
> > https://crrev.com/c/1575556 also from Doug. Let's say I did the
> > porting to upstream, but I'm pretty sure Doug spent more time on it.
> > 
> > Maybe I should resend it with Doug as author and include the original
> > commit message, which has more information.
> 
> It's just that the first Signed-off should be from the original author.
> (And the sender the second)
> In the co-developed-by case (see Kernel documentation) the order
> doesn't matter.

Holding off on this patch till we could clarify the authorship.


Heiko

Re: [PATCH 2/2] ARM: dts: rockchip: Configure BT_HOST_WAKE as wake-up signal on veyron

[Matthias Kaehlcke]

On Thu, Jun 06, 2019 at 12:46:03PM +0200, Heiko Stuebner wrote:
> Am Mittwoch, 5. Juni 2019, 23:52:00 CEST schrieb Heiko Stübner:
> > Am Mittwoch, 5. Juni 2019, 23:24:27 CEST schrieb Matthias Kaehlcke:
> > > On Wed, Jun 05, 2019 at 11:11:12PM +0200, Heiko Stübner wrote:
> > > > Am Mittwoch, 5. Juni 2019, 22:43:20 CEST schrieb Matthias Kaehlcke:
> > > > > This enables wake up on Bluetooth activity when the device is
> > > > > suspended. The BT_HOST_WAKE signal is only connected on devices
> > > > > with BT module that are connected through UART.
> > > > > 
> > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > > > 
> > > > Housekeeping question, with the two Signed-off-by lines, is Doug the
> > > > original author, or was this Co-developer-by?
> > > 
> > > Good question, it's derived from Doug's patch for CrOS 3.14 and
> > > https://crrev.com/c/1575556 also from Doug. Let's say I did the
> > > porting to upstream, but I'm pretty sure Doug spent more time on it.
> > > 
> > > Maybe I should resend it with Doug as author and include the original
> > > commit message, which has more information.
> > 
> > It's just that the first Signed-off should be from the original author.
> > (And the sender the second)
> > In the co-developed-by case (see Kernel documentation) the order
> > doesn't matter.
> 
> Holding off on this patch till we could clarify the authorship.

I'd say let's attribute the authorship to Doug. FTR, the original
downstream Chrome OS patch is https://crrev.com/c/278190.

Not sure if the information in the commit message of the original
patch is relevant for the upstream version, in the end it seems LPM
was never implemented, so it should be sufficient to say what is
actually done today.

In summary, I propose to take the patch with the current commit
message, with Doug as the author. Heiko, can you change the authorship
or should I send a new version?

Doug if you have objections or want updates in the commit message
(yours tend to be more verbose ;-), holler.

Thanks

Matthias

Re: [PATCH 2/2] ARM: dts: rockchip: Configure BT_HOST_WAKE as wake-up signal on veyron

[Doug Anderson]

Hi,

On Wed, Jun 5, 2019 at 1:43 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> This enables wake up on Bluetooth activity when the device is
> suspended. The BT_HOST_WAKE signal is only connected on devices
> with BT module that are connected through UART.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
>  arch/arm/boot/dts/rk3288-veyron.dtsi | 29 ++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
> index cc4c3595f145..145cac7c0847 100644
> --- a/arch/arm/boot/dts/rk3288-veyron.dtsi
> +++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
> @@ -23,6 +23,31 @@
>                 reg = <0x0 0x0 0x0 0x80000000>;
>         };
>
> +       bt_activity: bt-activity {
> +               compatible = "gpio-keys";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&bt_host_wake>;
> +
> +               /*
> +                * HACK: until we have an LPM driver, we'll use an
> +                * ugly GPIO key to allow Bluetooth to wake from S3.
> +                * This is expected to only be used by BT modules that
> +                * use UART for comms.  For BT modules that talk over
> +                * SDIO we should use a wakeup mechanism related to SDIO.
> +                *
> +                * Use KEY_RESERVED here since that will work as a wakeup but
> +                * doesn't get reported to higher levels (so doesn't confuse
> +                * Chrome).
> +                */
> +               bt-wake {
> +                       label = "BT Wakeup";
> +                       gpios = <&gpio4 RK_PD7 GPIO_ACTIVE_HIGH>;
> +                       linux,code = <KEY_RESERVED>;
> +                       wakeup-source;
> +               };
> +
> +       };
> +
>         power_button: power-button {
>                 compatible = "gpio-keys";
>                 pinctrl-names = "default";
> @@ -555,6 +580,10 @@
>                         rockchip,pins = <4 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
>                 };
>
> +               bt_host_wake: bt-host-wake {
> +                       rockchip,pins = <4 31 RK_FUNC_GPIO &pcfg_pull_down>;

nit: s/31/RK_PD7

Other than that, feel free to add my Reviewed-by assuming that this
isn't too hacky for mainline to accept while we wait for someone to
come up with a better solution.

-Doug

Re: [PATCH 2/2] ARM: dts: rockchip: Configure BT_HOST_WAKE as wake-up signal on veyron

[Doug Anderson]

Hi,

On Thu, Jun 6, 2019 at 10:56 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> On Thu, Jun 06, 2019 at 12:46:03PM +0200, Heiko Stuebner wrote:
> > Am Mittwoch, 5. Juni 2019, 23:52:00 CEST schrieb Heiko Stübner:
> > > Am Mittwoch, 5. Juni 2019, 23:24:27 CEST schrieb Matthias Kaehlcke:
> > > > On Wed, Jun 05, 2019 at 11:11:12PM +0200, Heiko Stübner wrote:
> > > > > Am Mittwoch, 5. Juni 2019, 22:43:20 CEST schrieb Matthias Kaehlcke:
> > > > > > This enables wake up on Bluetooth activity when the device is
> > > > > > suspended. The BT_HOST_WAKE signal is only connected on devices
> > > > > > with BT module that are connected through UART.
> > > > > >
> > > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > > > >
> > > > > Housekeeping question, with the two Signed-off-by lines, is Doug the
> > > > > original author, or was this Co-developer-by?
> > > >
> > > > Good question, it's derived from Doug's patch for CrOS 3.14 and
> > > > https://crrev.com/c/1575556 also from Doug. Let's say I did the
> > > > porting to upstream, but I'm pretty sure Doug spent more time on it.
> > > >
> > > > Maybe I should resend it with Doug as author and include the original
> > > > commit message, which has more information.
> > >
> > > It's just that the first Signed-off should be from the original author.
> > > (And the sender the second)
> > > In the co-developed-by case (see Kernel documentation) the order
> > > doesn't matter.
> >
> > Holding off on this patch till we could clarify the authorship.
>
> I'd say let's attribute the authorship to Doug. FTR, the original
> downstream Chrome OS patch is https://crrev.com/c/278190.
>
> Not sure if the information in the commit message of the original
> patch is relevant for the upstream version, in the end it seems LPM
> was never implemented, so it should be sufficient to say what is
> actually done today.
>
> In summary, I propose to take the patch with the current commit
> message, with Doug as the author. Heiko, can you change the authorship
> or should I send a new version?
>
> Doug if you have objections or want updates in the commit message
> (yours tend to be more verbose ;-), holler.

It's fine with me.

-Doug

Re: [PATCH 2/2] ARM: dts: rockchip: Configure BT_HOST_WAKE as wake-up signal on veyron

[Heiko Stuebner]

Am Freitag, 7. Juni 2019, 01:34:32 CEST schrieb Doug Anderson:
> Hi,
> 
> On Thu, Jun 6, 2019 at 10:56 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > On Thu, Jun 06, 2019 at 12:46:03PM +0200, Heiko Stuebner wrote:
> > > Am Mittwoch, 5. Juni 2019, 23:52:00 CEST schrieb Heiko Stübner:
> > > > Am Mittwoch, 5. Juni 2019, 23:24:27 CEST schrieb Matthias Kaehlcke:
> > > > > On Wed, Jun 05, 2019 at 11:11:12PM +0200, Heiko Stübner wrote:
> > > > > > Am Mittwoch, 5. Juni 2019, 22:43:20 CEST schrieb Matthias Kaehlcke:
> > > > > > > This enables wake up on Bluetooth activity when the device is
> > > > > > > suspended. The BT_HOST_WAKE signal is only connected on devices
> > > > > > > with BT module that are connected through UART.
> > > > > > >
> > > > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > > > > >
> > > > > > Housekeeping question, with the two Signed-off-by lines, is Doug the
> > > > > > original author, or was this Co-developer-by?
> > > > >
> > > > > Good question, it's derived from Doug's patch for CrOS 3.14 and
> > > > > https://crrev.com/c/1575556 also from Doug. Let's say I did the
> > > > > porting to upstream, but I'm pretty sure Doug spent more time on it.
> > > > >
> > > > > Maybe I should resend it with Doug as author and include the original
> > > > > commit message, which has more information.
> > > >
> > > > It's just that the first Signed-off should be from the original author.
> > > > (And the sender the second)
> > > > In the co-developed-by case (see Kernel documentation) the order
> > > > doesn't matter.
> > >
> > > Holding off on this patch till we could clarify the authorship.
> >
> > I'd say let's attribute the authorship to Doug. FTR, the original
> > downstream Chrome OS patch is https://crrev.com/c/278190.
> >
> > Not sure if the information in the commit message of the original
> > patch is relevant for the upstream version, in the end it seems LPM
> > was never implemented, so it should be sufficient to say what is
> > actually done today.
> >
> > In summary, I propose to take the patch with the current commit
> > message, with Doug as the author. Heiko, can you change the authorship
> > or should I send a new version?
> >
> > Doug if you have objections or want updates in the commit message
> > (yours tend to be more verbose ;-), holler.
> 
> It's fine with me.

while I did just want to apply this one with the relevant adaptions,
I didn't get to it early enough and Matthias was faster with his v2
fixed patch, so I've applied that one instead ;-)

Heiko