Minor device-tree additions for C.H.I.P

The C.H.I.P has an rtl8723bs device with the bluetooth interface hooked up on UART3. Support for this didn't exist in mainline when the DTS was initially added, but it does now, so enable it.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/boot/dts/sun5i-r8-chip.dts +0 -0

index fd37bd1f3920..4d72a181d8aa 100644

arch/arm/boot/dts/sun5i-r8-chip.dts +0 -0

 };
 
 &usb_otg {

Quoted 18 lines · On Sat, 15 Apr 2023 18:46:03 +0100 Jonathan McDowell <[email protected]> wrote:

The C.H.I.P has an rtl8723bs device with the bluetooth interface hooked up on UART3. Support for this didn't exist in mainline when the DTS was initially added, but it does now, so enable it.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/boot/dts/sun5i-r8-chip.dts +1 -0

index fd37bd1f3920..4d72a181d8aa 100644
@@ -255,6 +255,10 @@ &uart3 {
 	pinctrl-0 = <&uart3_pg_pins>,
 		    <&uart3_cts_rts_pg_pins>;
 	status = "okay";
+

arch/arm/boot/dts/sun5i-r8-chip.dts &uart3 { · line 261

Quoted 3 lines

arch/arm/boot/dts/sun5i-r8-chip.dts +3 -0

+	bluetooth {
+		compatible = "realtek,rtl8723bs-bt";
+	}

As the kernel test robot already pointed out, there is a semicolon missing here.
Otherwise looks good (dt-validate passes), but don't know if there are any wakeup GPIOs connected (can't seem to find a schematic?).

arch/arm/boot/dts/sun5i-r8-chip.dts &uart3 { · line 264

Quoted 3 lines

arch/arm/boot/dts/sun5i-r8-chip.dts +0 -0

 };
 
 &usb_otg {

Quoted 21 lines · Andre Przywara

Quoted 18 lines · On Sat, 15 Apr 2023 18:46:03 +0100 Jonathan McDowell <[email protected]> wrote:

The C.H.I.P has an rtl8723bs device with the bluetooth interface hooked up on UART3. Support for this didn't exist in mainline when the DTS was initially added, but it does now, so enable it.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/boot/dts/sun5i-r8-chip.dts +1 -0

index fd37bd1f3920..4d72a181d8aa 100644
@@ -255,6 +255,10 @@ &uart3 {
    pinctrl-0 = <&uart3_pg_pins>,
                <&uart3_cts_rts_pg_pins>;
    status = "okay";
+

Quoted 8 lines

arch/arm/boot/dts/sun5i-r8-chip.dts &uart3 { · line 261

Quoted 3 lines

arch/arm/boot/dts/sun5i-r8-chip.dts +3 -0

+   bluetooth {
+           compatible = "realtek,rtl8723bs-bt";
+   }

As the kernel test robot already pointed out, there is a semicolon missing here.
Otherwise looks good (dt-validate passes), but don't know if there are any wakeup GPIOs connected (can't seem to find a schematic?).

So there are wakeups, but if I add:

        device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_LOW>;
        host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */

then some odd sort of dependency issue happens where the serial port load is deferred waiting for the GPIO to appear, and then the device doesn't work.

Error in dmesg is:

serial serial0-0: deferred probe pending

on 6.3-rc and on 6.1 I get:

dw-apb-uart 1c28c00.serial: Failed to create device link (0x180) with axp20x-gpio

I'm not clear why it's trying to link the serial port to the GPIO; it seems that it should be the bluetooth device that depends on both the UART and the GPIO,

and that the GPIO is actually optional so shouldn't hold up loading, but I can't see how that should be represented.

Adding Greg + Saravana in the hope they can tell me what I've done wrong here. The LED driver using a different GPIO line on the axp209 works fine, so the device is definitely loaded and working ok.

Quoted 33 lines · Jonathan McDowell

Quoted 21 lines · Andre Przywara

Quoted 18 lines · On Sat, 15 Apr 2023 18:46:03 +0100 Jonathan McDowell <[email protected]> wrote:

The C.H.I.P has an rtl8723bs device with the bluetooth interface hooked up on UART3. Support for this didn't exist in mainline when the DTS was initially added, but it does now, so enable it.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/boot/dts/sun5i-r8-chip.dts +1 -0

index fd37bd1f3920..4d72a181d8aa 100644
@@ -255,6 +255,10 @@ &uart3 {
    pinctrl-0 = <&uart3_pg_pins>,
                <&uart3_cts_rts_pg_pins>;
    status = "okay";
+

Quoted 8 lines

arch/arm/boot/dts/sun5i-r8-chip.dts &uart3 { · line 261

Quoted 3 lines

arch/arm/boot/dts/sun5i-r8-chip.dts +3 -0

+   bluetooth {
+           compatible = "realtek,rtl8723bs-bt";
+   }

As the kernel test robot already pointed out, there is a semicolon missing here.
Otherwise looks good (dt-validate passes), but don't know if there are any wakeup GPIOs connected (can't seem to find a schematic?).

So there are wakeups, but if I add:

Quoted 6 lines

        device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_LOW>;
        host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */

then some odd sort of dependency issue happens where the serial port load is deferred waiting for the GPIO to appear, and then the device doesn't work.

When you say your device doesn't work, are you saying it never probes?

<debugfs>/devices_deferred should tell you what devices have deferred and why.

Quoted 7 lines

Error in dmesg is:

serial serial0-0: deferred probe pending

on 6.3-rc and on 6.1 I get:

dw-apb-uart 1c28c00.serial: Failed to create device link (0x180) with axp20x-gpio

This error message doesn't block anything. So I don't think this is the cause of your blocking issue. But I still want to understand why this error message is showing up.

Quoted 3 lines

I'm not clear why it's trying to link the serial port to the GPIO; it seems that it should be the bluetooth device that depends on both the UART and the GPIO,

A fix for the device link error message went in on v6.3-rc3. Is that the 6.3 version you tested this on?

Also, I tried looking into the UART driver (drivers/tty/serial/8250/8250_dw.c) but it wasn't clear how it ends up populating the bluetooth serial device. If you can point that out, that'd be helpful (assuming 6.3-rc3 still shows that error message).

Quoted 2 lines

and that the GPIO is actually optional so shouldn't hold up loading, but I can't see how that should be represented.

Optional dependencies should get ignored after the default deferred_probe_timeout runs out and the supplier driver hasn't been loaded yet.

Quoted 34 lines · Saravana Kannan

Quoted 33 lines · Jonathan McDowell

Quoted 21 lines · Andre Przywara

Quoted 18 lines · On Sat, 15 Apr 2023 18:46:03 +0100 Jonathan McDowell <[email protected]> wrote:

The C.H.I.P has an rtl8723bs device with the bluetooth interface hooked up on UART3. Support for this didn't exist in mainline when the DTS was initially added, but it does now, so enable it.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/boot/dts/sun5i-r8-chip.dts +1 -0

index fd37bd1f3920..4d72a181d8aa 100644
@@ -255,6 +255,10 @@ &uart3 {
    pinctrl-0 = <&uart3_pg_pins>,
                <&uart3_cts_rts_pg_pins>;
    status = "okay";
+

Quoted 8 lines

arch/arm/boot/dts/sun5i-r8-chip.dts &uart3 { · line 261

Quoted 3 lines

arch/arm/boot/dts/sun5i-r8-chip.dts +3 -0

+   bluetooth {
+           compatible = "realtek,rtl8723bs-bt";
+   }

As the kernel test robot already pointed out, there is a semicolon missing here.
Otherwise looks good (dt-validate passes), but don't know if there are any wakeup GPIOs connected (can't seem to find a schematic?).

So there are wakeups, but if I add:

Quoted 8 lines

Quoted 6 lines

        device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_LOW>;
        host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */

then some odd sort of dependency issue happens where the serial port load is deferred waiting for the GPIO to appear, and then the device doesn't work.

When you say your device doesn't work, are you saying it never probes?

The bluetooth device (realtek,rtl8723bs-bt) never appears, apparently because the UART it's attached to never loads - it doesn't even try to load the firmware.

Quoted 1 line

<debugfs>/devices_deferred should tell you what devices have deferred and why.

root@chip:~# cat /sys/kernel/debug/devices_deferred
serial0-0

Quoted 16 lines

Quoted 7 lines

Error in dmesg is:

serial serial0-0: deferred probe pending

on 6.3-rc and on 6.1 I get:

dw-apb-uart 1c28c00.serial: Failed to create device link (0x180) with axp20x-gpio

This error message doesn't block anything. So I don't think this is the cause of your blocking issue. But I still want to understand why this error message is showing up.

Quoted 3 lines

I'm not clear why it's trying to link the serial port to the GPIO; it seems that it should be the bluetooth device that depends on both the UART and the GPIO,

Quoted 2 lines

A fix for the device link error message went in on v6.3-rc3. Is that the 6.3 version you tested this on?

I originally tried on 6.1.21, which is where I got the "Failed to create device link" message. I then moved to 6.3-rc7 as I saw there had been further changes recently. There I just get the:

serial serial0-0: deferred probe pending

message.

Quoted 4 lines

Also, I tried looking into the UART driver (drivers/tty/serial/8250/8250_dw.c) but it wasn't clear how it ends up populating the bluetooth serial device. If you can point that out, that'd be helpful (assuming 6.3-rc3 still shows that error message).

I have the following in my device tree:

&uart3 {
        pinctrl-names = "default";
        pinctrl-0 = <&uart3_pg_pins>,
                    <&uart3_cts_rts_pg_pins>;
        status = "okay";

        bluetooth {
                compatible = "realtek,rtl8723bs-bt";
                device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_LOW>;
                host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
        };
};

uart3 is a snps,dw-apb-uart, defined in arch/arm/boot/dts/sun5i.dtsi

The UART and AXP209 device drivers are compiled into the kernel:

CONFIG_PINCTRL_AXP209=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DW=y

The bluetooth bits are modules (btrtl, hci_uart).

If I remove the device-wake-gpios line then the Bluetooth device works fine, and /sys/kernel/debug/devices_deferred is empty.

Somehow it seems like the GPIO is being parsed as a dependency for the serial port, even though the serial port + GPIO are both dependencies for the bluetooth device.

Even with that, given both are built-in I
don't understand why the serial port never completes setup.

Quoted 6 lines

Quoted 2 lines

and that the GPIO is actually optional so shouldn't hold up loading, but I can't see how that should be represented.

Optional dependencies should get ignored after the default deferred_probe_timeout runs out and the supplier driver hasn't been loaded yet.

When I say it's optional I mean if it's not listed everything works fine, but I don't believe there's anyway to express that in the DTS. It's certainly not required for the serial port, just the bluetooth device.

J.

--
Web [ Don't be a stranger. ]
site: https:// [ ] Made by
www.earth.li/~noodles/ [ ] HuggieTag 0.0.24

Quoted 39 lines · Jonathan McDowell

Quoted 37 lines · Saravana Kannan

Quoted 36 lines · Jonathan McDowell

Quoted 21 lines · Andre Przywara

Quoted 18 lines · On Sat, 15 Apr 2023 18:46:03 +0100 Jonathan McDowell <[email protected]> wrote:

The C.H.I.P has an rtl8723bs device with the bluetooth interface hooked up on UART3. Support for this didn't exist in mainline when the DTS was initially added, but it does now, so enable it.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/boot/dts/sun5i-r8-chip.dts +1 -0

index fd37bd1f3920..4d72a181d8aa 100644
@@ -255,6 +255,10 @@ &uart3 {
    pinctrl-0 = <&uart3_pg_pins>,
                <&uart3_cts_rts_pg_pins>;
    status = "okay";
+

Quoted 8 lines

arch/arm/boot/dts/sun5i-r8-chip.dts &uart3 { · line 261

Quoted 3 lines

arch/arm/boot/dts/sun5i-r8-chip.dts +3 -0

+   bluetooth {
+           compatible = "realtek,rtl8723bs-bt";
+   }

As the kernel test robot already pointed out, there is a semicolon missing here.
Otherwise looks good (dt-validate passes), but don't know if there are any wakeup GPIOs connected (can't seem to find a schematic?).

So there are wakeups, but if I add:

        device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_LOW>;
        host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */

Quoted 5 lines

Quoted 5 lines

Quoted 3 lines

then some odd sort of dependency issue happens where the serial port load is deferred waiting for the GPIO to appear, and then the device doesn't work.

When you say your device doesn't work, are you saying it never probes?

Read your whole email and it's a strange issue. Also, going forward to avoid confusion, only reply to questions with respect to 6.3-rc7.

Quoted 8 lines

The bluetooth device (realtek,rtl8723bs-bt) never appears, apparently because the UART it's attached to never loads - it doesn't even try to load the firmware.

Quoted 1 line

<debugfs>/devices_deferred should tell you what devices have deferred and why.

root@chip:~# cat /sys/kernel/debug/devices_deferred
serial0-0

Do you see this in 6.3-rc7 too?

Quoted 23 lines

Quoted 12 lines

Quoted 7 lines

Error in dmesg is:

serial serial0-0: deferred probe pending

on 6.3-rc and on 6.1 I get:

dw-apb-uart 1c28c00.serial: Failed to create device link (0x180) with axp20x-gpio

This error message doesn't block anything. So I don't think this is the cause of your blocking issue. But I still want to understand why this error message is showing up.

Quoted 6 lines

Quoted 3 lines

I'm not clear why it's trying to link the serial port to the GPIO; it seems that it should be the bluetooth device that depends on both the UART and the GPIO,

A fix for the device link error message went in on v6.3-rc3. Is that the 6.3 version you tested this on?

I originally tried on 6.1.21, which is where I got the "Failed to create device link" message. I then moved to 6.3-rc7 as I saw there had been further changes recently. There I just get the:

Quoted 1 line

serial serial0-0: deferred probe pending

If the deferral is related to fw_devlink, you should see the reason for deferring in the devices_deferred file. So I don't think the issue is related to fw_devlink.

Quoted 35 lines

message.

Quoted 4 lines

Also, I tried looking into the UART driver (drivers/tty/serial/8250/8250_dw.c) but it wasn't clear how it ends up populating the bluetooth serial device. If you can point that out, that'd be helpful (assuming 6.3-rc3 still shows that error message).

I have the following in my device tree:

&uart3 {
        pinctrl-names = "default";
        pinctrl-0 = <&uart3_pg_pins>,
                    <&uart3_cts_rts_pg_pins>;
        status = "okay";

        bluetooth {
                compatible = "realtek,rtl8723bs-bt";
                device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_LOW>;
                host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
        };
};

uart3 is a snps,dw-apb-uart, defined in arch/arm/boot/dts/sun5i.dtsi

The UART and AXP209 device drivers are compiled into the kernel:

CONFIG_PINCTRL_AXP209=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DW=y

The bluetooth bits are modules (btrtl, hci_uart).

If I remove the device-wake-gpios line then the Bluetooth device works fine, and /sys/kernel/debug/devices_deferred is empty.

Quoted 3 lines

Somehow it seems like the GPIO is being parsed as a dependency for the serial port, even though the serial port + GPIO are both dependencies for the bluetooth device.

I'm fairly sure that fw_devlink isn't causing that. Because even without bluetooth, fw_devlink doesn't consider any suppliers listed in child DT nodes as mandatory suppliers. That has been the case since the beginning.

Quoted 2 lines

Even with that, given both are built-in I
don't understand why the serial port never completes setup.

My guess is that the driver itself has some bug that's sensitive to device probe order even though it shouldn't.

Can you add #define DEBUG 1 to the top of drivers/base/core.c and share the boot log? I can try and help debug it.

Quoted 40 lines · Saravana Kannan

Quoted 39 lines · Jonathan McDowell

Quoted 37 lines · Saravana Kannan

Quoted 36 lines · Jonathan McDowell

Quoted 21 lines · Andre Przywara

Quoted 18 lines · On Sat, 15 Apr 2023 18:46:03 +0100 Jonathan McDowell <[email protected]> wrote:

The C.H.I.P has an rtl8723bs device with the bluetooth interface hooked up on UART3. Support for this didn't exist in mainline when the DTS was initially added, but it does now, so enable it.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/boot/dts/sun5i-r8-chip.dts +1 -0

index fd37bd1f3920..4d72a181d8aa 100644
@@ -255,6 +255,10 @@ &uart3 {
    pinctrl-0 = <&uart3_pg_pins>,
                <&uart3_cts_rts_pg_pins>;
    status = "okay";
+

Quoted 8 lines

arch/arm/boot/dts/sun5i-r8-chip.dts &uart3 { · line 261

Quoted 3 lines

arch/arm/boot/dts/sun5i-r8-chip.dts +3 -0

+   bluetooth {
+           compatible = "realtek,rtl8723bs-bt";
+   }

As the kernel test robot already pointed out, there is a semicolon missing here.
Otherwise looks good (dt-validate passes), but don't know if there are any wakeup GPIOs connected (can't seem to find a schematic?).

So there are wakeups, but if I add:

        device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_LOW>;
        host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Quoted 3 lines

then some odd sort of dependency issue happens where the serial port load is deferred waiting for the GPIO to appear, and then the device doesn't work.

When you say your device doesn't work, are you saying it never probes?

Read your whole email and it's a strange issue. Also, going forward to avoid confusion, only reply to questions with respect to 6.3-rc7.

Just to be clear, in my initial mail I referred to 6.1.21 as that's where I started, but in my reply to you all output was quoted from 6.3-rc7. 6.3 has been released since, so all details below are based on that.

Quoted 9 lines

Quoted 8 lines

The bluetooth device (realtek,rtl8723bs-bt) never appears, apparently because the UART it's attached to never loads - it doesn't even try to load the firmware.

Quoted 1 line

<debugfs>/devices_deferred should tell you what devices have deferred and why.

root@chip:~# cat /sys/kernel/debug/devices_deferred
serial0-0

Quoted 1 line

Do you see this in 6.3-rc7 too?

That was under 6.3-rc7. I see it on 6.3 too:

root@chip:~# cat /sys/kernel/debug/devices_deferred
serial0-0

Without the device-wake-gpios line in the device tree it's empty.

Quoted 24 lines

Quoted 24 lines

Quoted 13 lines

Quoted 8 lines

Error in dmesg is:

serial serial0-0: deferred probe pending

on 6.3-rc and on 6.1 I get:

dw-apb-uart 1c28c00.serial: Failed to create device link (0x180) with axp20x-gpio

This error message doesn't block anything. So I don't think this is the cause of your blocking issue. But I still want to understand why this error message is showing up.

Quoted 6 lines

Quoted 3 lines

I'm not clear why it's trying to link the serial port to the GPIO; it seems that it should be the bluetooth device that depends on both the UART and the GPIO,

A fix for the device link error message went in on v6.3-rc3. Is that the 6.3 version you tested this on?

I originally tried on 6.1.21, which is where I got the "Failed to create device link" message. I then moved to 6.3-rc7 as I saw there had been further changes recently. There I just get the:

Quoted 5 lines

Quoted 1 line

serial serial0-0: deferred probe pending

If the deferral is related to fw_devlink, you should see the reason for deferring in the devices_deferred file. So I don't think the issue is related to fw_devlink.

Ok.

Quoted 35 lines

Quoted 35 lines

message.

Quoted 4 lines

Also, I tried looking into the UART driver (drivers/tty/serial/8250/8250_dw.c) but it wasn't clear how it ends up populating the bluetooth serial device. If you can point that out, that'd be helpful (assuming 6.3-rc3 still shows that error message).

I have the following in my device tree:

&uart3 {
        pinctrl-names = "default";
        pinctrl-0 = <&uart3_pg_pins>,
                    <&uart3_cts_rts_pg_pins>;
        status = "okay";

        bluetooth {
                compatible = "realtek,rtl8723bs-bt";
                device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_LOW>;
                host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
        };
};

uart3 is a snps,dw-apb-uart, defined in arch/arm/boot/dts/sun5i.dtsi

The UART and AXP209 device drivers are compiled into the kernel:

CONFIG_PINCTRL_AXP209=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DW=y

The bluetooth bits are modules (btrtl, hci_uart).

If I remove the device-wake-gpios line then the Bluetooth device works fine, and /sys/kernel/debug/devices_deferred is empty.

Quoted 8 lines

Quoted 3 lines

Somehow it seems like the GPIO is being parsed as a dependency for the serial port, even though the serial port + GPIO are both dependencies for the bluetooth device.

I'm fairly sure that fw_devlink isn't causing that. Because even without bluetooth, fw_devlink doesn't consider any suppliers listed in child DT nodes as mandatory suppliers. That has been the case since the beginning.

Ok, I just got confused with the 6.1 message about the device link and thought that might be the rough area.

Quoted 8 lines

Quoted 2 lines

Even with that, given both are built-in I
don't understand why the serial port never completes setup.

My guess is that the driver itself has some bug that's sensitive to device probe order even though it shouldn't.

Can you add #define DEBUG 1 to the top of drivers/base/core.c and share the boot log? I can try and help debug it.

Thanks for any input you're able to provide. dmesg from 6.3 with a failure to complete the probe:

https://the.earth.li/~noodles/chip-bluetooth/6.3-not-working

and just for completeness, without the device-wake-gpios line:

https://the.earth.li/~noodles/chip-bluetooth/6.3-working

J.

--
Most people are descended from apes. Redheads are descended from cats.

Quoted 46 lines · Jonathan McDowell

Quoted 44 lines · Saravana Kannan

Quoted 43 lines · Jonathan McDowell

Quoted 41 lines · Saravana Kannan

Quoted 39 lines · Jonathan McDowell

Quoted 21 lines · Andre Przywara

Quoted 18 lines · On Sat, 15 Apr 2023 18:46:03 +0100 Jonathan McDowell <[email protected]> wrote:

The C.H.I.P has an rtl8723bs device with the bluetooth interface hooked up on UART3. Support for this didn't exist in mainline when the DTS was initially added, but it does now, so enable it.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/boot/dts/sun5i-r8-chip.dts +1 -0

index fd37bd1f3920..4d72a181d8aa 100644
@@ -255,6 +255,10 @@ &uart3 {
    pinctrl-0 = <&uart3_pg_pins>,
                <&uart3_cts_rts_pg_pins>;
    status = "okay";
+

Quoted 8 lines

arch/arm/boot/dts/sun5i-r8-chip.dts &uart3 { · line 261

Quoted 3 lines

arch/arm/boot/dts/sun5i-r8-chip.dts +3 -0

+   bluetooth {
+           compatible = "realtek,rtl8723bs-bt";
+   }

As the kernel test robot already pointed out, there is a semicolon missing here.
Otherwise looks good (dt-validate passes), but don't know if there are any wakeup GPIOs connected (can't seem to find a schematic?).

So there are wakeups, but if I add:

        device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_LOW>;
        host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */

then some odd sort of dependency issue happens where the serial port load is deferred waiting for the GPIO to appear, and then the device doesn't work.

Quoted 4 lines

Quoted 4 lines

Quoted 1 line

Quoted 1 line

When you say your device doesn't work, are you saying it never probes?

Read your whole email and it's a strange issue. Also, going forward to avoid confusion, only reply to questions with respect to 6.3-rc7.

Sorry it took a while to respond. Life got busy.

Quoted 14 lines

Just to be clear, in my initial mail I referred to 6.1.21 as that's where I started, but in my reply to you all output was quoted from 6.3-rc7. 6.3 has been released since, so all details below are based on that.

Quoted 9 lines

Quoted 8 lines

The bluetooth device (realtek,rtl8723bs-bt) never appears, apparently because the UART it's attached to never loads - it doesn't even try to load the firmware.

Quoted 1 line

<debugfs>/devices_deferred should tell you what devices have deferred and why.

root@chip:~# cat /sys/kernel/debug/devices_deferred
serial0-0

Quoted 6 lines

Quoted 1 line

Do you see this in 6.3-rc7 too?

That was under 6.3-rc7. I see it on 6.3 too:

root@chip:~# cat /sys/kernel/debug/devices_deferred
serial0-0

I somehow didn't connect the dots earlier... but serial0-0 is NOT the uart/serial device. It's the child device of serial0 and in this case, it's the bluetooth device.

So adding those gpios in DT is not breaking serial. It's just preventing the BT device from probing.

Looking at the logs in the non-working case:

[    0.715083] 1c28c00.serial: ttyS1 at MMIO 0x1c28c00 (irq = 53,
base_baud = 1500000) is a U6_16550A
[    0.724132] device: 'serial0': device_add

I don't know why all of the ttySx are showing up as serial0, but this is the serial port. As you can see 1c28c00 is already probing.

[    0.724228] device: 'serial0-0': device_add

This is the child devices getting populated. In this case this is the BT device.

[    0.724311] device: 'platform:1c20800.pinctrl--serial:serial0-0': device_add

I can tell it's the BT device because we see a device link being created between pinctrl and serial:serial0-0. So it's a device sitting on the serial bus.

[    0.724378] devices_kset: Moving serial0-0 to end of list
[    0.724390] serial serial0-0: Linked as a consumer to 1c20800.pinctrl
[    0.724401] /soc/serial@1c28c00/bluetooth Dropping the fwnode link

to /soc/pinctrl@1c20800

And the fwnode like that was converted to device link clearly shows that the serial0-0 corresponds to the bluetooth node.

[    0.724441] serial serial0: tty port ttyS1 registered

Serial port works.

Quoted 2 lines

Without the device-wake-gpios line in the device tree it's empty.

I think the issue is at the BT driver level or some other framework.

Add a print at the start of the BT driver to see if the probe() is actually getting called. I'm guessing it is and it's returning an error from within.

If you don't see that print, then debug the really_probe() function to see how far within it the BT device goes through before it errors out. It's possible pinctrl_bind_pins() in really_probe() fails for the BT device because of how the GPIO pins are configured in your DT.

These alternate pins for mmc2 are brought out to the 40 pin U14 header on the C.H.I.P and can be used to add an external MMC device with a 4 bit interface. See

https://byteporter.com/ntc-chip-micro-sd-slot/

for further details on how.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/sun5i.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

arch/arm/boot/dts/sun5i.dtsi +0 -0

index 250d6b87ab4d..e4922506ce22 100644

arch/arm/boot/dts/sun5i.dtsi +8 -0

+			mmc2_4bit_pe_pins: mmc2-4bit-pe-pins {
+				pins = "PE4", "PE5", "PE6", "PE7",
+				       "PE8", "PE9";
+				function = "mmc2";
+				drive-strength = <30>;
+				bias-pull-up;
+			};
+
 			mmc2_8bit_pins: mmc2-8bit-pins {
 				pins = "PC6", "PC7", "PC8", "PC9",
 				       "PC10", "PC11", "PC12", "PC13",

On Sat, 15 Apr 2023 18:46:24 +0100
Jonathan McDowell <[email protected]> wrote:

Hi,

Quoted 18 lines

These alternate pins for mmc2 are brought out to the 40 pin U14 header on the C.H.I.P and can be used to add an external MMC device with a 4 bit interface. See

https://byteporter.com/ntc-chip-micro-sd-slot/

for further details on how.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/sun5i.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

arch/arm/boot/dts/sun5i.dtsi +0 -0

index 250d6b87ab4d..e4922506ce22 100644

arch/arm/boot/dts/sun5i.dtsi mmc2_4bit_pc_pins: mmc2-4bit-pc-pins { · line 519

Quoted 3 lines

arch/arm/boot/dts/sun5i.dtsi +0 -0

@@ -517,6 +517,14 @@ mmc2_4bit_pc_pins: mmc2-4bit-pc-pins {
 				bias-pull-up;
 			};
 

As this seems to be a highly non-standard and rare modification, that doesn't even get used in the mainline DT, please add a:

			/omit-if-no-ref/

line, so we don't get this into every sun5i board.

Otherwise looks good, though I don't know if that should belong into the same DT overlay that is probably used to also enable the MMC2 node.

arch/arm/boot/dts/sun5i.dtsi mmc2_4bit_pc_pins: mmc2-4bit-pc-pins { · line 530

Quoted 11 lines

arch/arm/boot/dts/sun5i.dtsi +8 -0

+			mmc2_4bit_pe_pins: mmc2-4bit-pe-pins {
+				pins = "PE4", "PE5", "PE6", "PE7",
+				       "PE8", "PE9";
+				function = "mmc2";
+				drive-strength = <30>;
+				bias-pull-up;
+			};
+
 			mmc2_8bit_pins: mmc2-8bit-pins {
 				pins = "PC6", "PC7", "PC8", "PC9",
 				       "PC10", "PC11", "PC12", "PC13",

This adds a DT node to hook up the internal temperature ADC to the

iio-hwmon driver. The various voltage + current ADCs are consumed and exposed by their respective drivers, but this is not and is always available. Naming chosen to match the axp20x_ prefix the power sensors use.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/axp209.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

arch/arm/boot/dts/axp209.dtsi +0 -0

index ca240cd6f6c3..f00b5a7ec106 100644

Quoted 1 line · Jonathan McDowell

This adds a DT node to hook up the internal temperature ADC to the

Do not use "This commit/patch", but imperative mood. See:
https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95

Quoted 4 lines

iio-hwmon driver. The various voltage + current ADCs are consumed and exposed by their respective drivers, but this is not and is always available. Naming chosen to match the axp20x_ prefix the power sensors use.

Weird choice.

Quoted 10 lines

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/axp209.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

arch/arm/boot/dts/axp209.dtsi +0 -0

index ca240cd6f6c3..f00b5a7ec106 100644

arch/arm/boot/dts/axp209.dtsi line 52

Quoted 5 lines

arch/arm/boot/dts/axp209.dtsi +2 -0

@@ -48,6 +48,13 @@
  * http://dl.linux-sunxi.org/AXP/AXP209%20Datasheet%20v1.0_cn.pdf
  */
 
+/ {
+	axp20x_temp {

No underscores in node names.

Node names should be generic.
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation

arch/arm/boot/dts/axp209.dtsi line 60

Quoted 8 lines

arch/arm/boot/dts/axp209.dtsi +5 -0

+		compatible = "iio-hwmon";
+		io-channels = <&axp_adc 4>; /* Internal temperature */
+	};
+};
+
 &axp209 {
 	compatible = "x-powers,axp209";
 	interrupt-controller;

The AXP209 has a 4th GPIO, so add it in preparation for support in the driver.

Signed-off-by Jonathan McDowell <[email protected]>

The AXP209 has a 4th GPIO, so add it in preparation for support in the driver.

Signed-off-by Jonathan McDowell <[email protected]>

The AXP209 device has a 4th GPIO which has a slightly different register setup, where the control + status bits are held in a single register rather than sharing AXP20X_GPIO20_SS with GPIOs 0-2.

+#define AXP20X_GPIO3_FUNCTIONS (BIT(2) | BIT(1))

drivers/pinctrl/pinctrl-axp209.c +2 -0

+			return GPIO_LINE_DIRECTION_OUT;
+	}

The AXP209 device has a 4th GPIO which has a slightly different register setup, where the control + status bits are held in a single register rather than sharing AXP20X_GPIO20_SS with GPIOs 0-2.

Signed-off-by Jonathan McDowell <[email protected]>

Quoted 4 lines · Jonathan McDowell

The AXP209 device has a 4th GPIO which has a slightly different register setup, where the control + status bits are held in a single register rather than sharing AXP20X_GPIO20_SS with GPIOs 0-2.

Quoted 1 line

Signed-off-by Jonathan McDowell <[email protected]>

This patch 2/5 applied to the pinctrl tree.

I just assume it is fine to apply this one patch, Bartosz already applied the binding patch.

Tell me if this works.

The C.H.I.P has an rtl8723bs device with the bluetooth interface hooked up on UART3. Support for this didn't exist in mainline when the DTS was initially added, but it does now, so enable it.

Signed-off-by Jonathan McDowell <[email protected]>

These alternate pins for mmc2 are brought out to the 40 pin U14 header on the C.H.I.P and can be used to add an external MMC device with a 4 bit interface. See

https://byteporter.com/ntc-chip-micro-sd-slot/

for further details on how.

Signed-off-by Jonathan McDowell <[email protected]>

This adds a DT node to hook up the internal temperature ADC to the iio-hwmon driver. The various voltage + current ADCs are consumed and exposed by their respective drivers, but this is not and is always available. Naming chosen to match the axp20x_ prefix the power sensors use.

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/axp209.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

arch/arm/boot/dts/axp209.dtsi +7 -0

index ca240cd6f6c3..469d0f7d5185 100644
@@ -48,6 +48,13 @@
  * http://dl.linux-sunxi.org/AXP/AXP209%20Datasheet%20v1.0_cn.pdf
  */
 
+/ {
+	pmic-temp {
+		compatible = "iio-hwmon";
+		io-channels = <&axp_adc 4>; /* Internal temperature */
+	};
+};
+
 &axp209 {
 	compatible = "x-powers,axp209";
 	interrupt-controller;

Dne sreda, 10. maj 2023 ob 14:02:28 CEST je Jonathan McDowell napisal(a):

Quoted 5 lines

This adds a DT node to hook up the internal temperature ADC to the iio-hwmon driver. The various voltage + current ADCs are consumed and exposed by their respective drivers, but this is not and is always available. Naming chosen to match the axp20x_ prefix the power sensors use.

Sorry for maybe obvious thing, but where are other ADC channels exposed?

Quoted 13 lines

Signed-off-by Jonathan McDowell <[email protected]>

---
 arch/arm/boot/dts/axp209.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

arch/arm/boot/dts/axp209.dtsi +0 -0

index ca240cd6f6c3..469d0f7d5185 100644
@@ -48,6 +48,13 @@
  * http://dl.linux-sunxi.org/AXP/AXP209%20Datasheet%20v1.0_cn.pdf
  */
 

arch/arm/boot/dts/axp209.dtsi line 60

Quoted 10 lines

arch/arm/boot/dts/axp209.dtsi +7 -0

+/ {
+	pmic-temp {
+		compatible = "iio-hwmon";
+		io-channels = <&axp_adc 4>; /* Internal temperature */
+	};
+};
+
 &axp209 {
 	compatible = "x-powers,axp209";
 	interrupt-controller;

Quoted 8 lines

Dne sreda, 10. maj 2023 ob 14:02:28 CEST je Jonathan McDowell napisal(a):

Quoted 5 lines

This adds a DT node to hook up the internal temperature ADC to the iio-hwmon driver. The various voltage + current ADCs are consumed and exposed by their respective drivers, but this is not and is always available. Naming chosen to match the axp20x_ prefix the power sensors use.

Sorry for maybe obvious thing, but where are other ADC channels exposed?

In the associated power drivers; e.g. axp20x_ac_power, axp20x_usb_power
+ axp20x_battery. The internal temperature is the only one that logically belongs to the chip as a whole rather than one of the subfunctions.

root@chip:~# sensors
axp20x_battery-isa-0000
Adapter: ISA adapter
in0:           0.00 V
curr1:         0.00 A

pmic_temp-isa-0000
Adapter: ISA adapter
temp1: +42.5°C

axp20x_ac-isa-0000

Adapter: ISA adapter
in0:           0.00 V
curr1:         0.00 A

axp20x_usb-isa-0000

Adapter: ISA adapter
in0:           4.93 V  (min =  +4.00 V)
curr1:       330.00 mA (max =  +0.00 A)

Quoted 25 lines

Quoted 25 lines

Signed-off-by Jonathan McDowell <[email protected]>

---

 arch/arm/boot/dts/axp209.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

arch/arm/boot/dts/axp209.dtsi +7 -0

index ca240cd6f6c3..469d0f7d5185 100644
@@ -48,6 +48,13 @@
 
  * http://dl.linux-sunxi.org/AXP/AXP209%20Datasheet%20v1.0_cn.pdf
  */
 
+/ {
+	pmic-temp {
+		compatible = "iio-hwmon";
+		io-channels = <&axp_adc 4>; /* Internal temperature */
+	};
+};
+
 

Quoted 4 lines

arch/arm/boot/dts/axp209.dtsi line 60

Quoted 4 lines

arch/arm/boot/dts/axp209.dtsi +0 -0

 &axp209 {

arch/arm/boot/dts/axp209.dtsi +0 -0

 	compatible = "x-powers,axp209";
 	interrupt-controller;

J.

The AXP209 has a 4th GPIO, so add it in preparation for support in the driver.

Signed-off-by Jonathan McDowell <[email protected]>

Acked-by Jernej Skrabec <[email protected]>

Acked-by Conor Dooley <[email protected]>

The AXP209 has a 4th GPIO, so add it in preparation for support in the driver.

Signed-off-by Jonathan McDowell <[email protected]>

Acked-by Jernej Skrabec <[email protected]>

Acked-by Conor Dooley <[email protected]>

---
 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml | 1 +
 1 file changed, 1 insertion(+)

Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml +1 -1

index 31906c253940..1638cfe90f1c 100644
@@ -44,6 +44,7 @@ patternProperties:
             - GPIO0
             - GPIO1
             - GPIO2
+            - GPIO3
 
       function:
         enum:
--

2.39.2

The AXP209 device has a 4th GPIO which has a slightly different register setup, where the control + status bits are held in a single register rather than sharing AXP20X_GPIO20_SS with GPIOs 0-2.

Signed-off-by Jonathan McDowell <[email protected]>

---
 drivers/pinctrl/pinctrl-axp209.c | 42 ++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

drivers/pinctrl/pinctrl-axp209.c +42 -1

index 0bc1b381a2b8..b3ba25435c34 100644
@@ -30,6 +30,11 @@
 #define AXP20X_GPIO_FUNCTION_OUT_HIGH  1
 #define AXP20X_GPIO_FUNCTION_INPUT     2
 
+#define AXP20X_GPIO3_FUNCTIONS         GENMASK(2, 1)
+#define AXP20X_GPIO3_FUNCTION_OUT_LOW  0
+#define AXP20X_GPIO3_FUNCTION_OUT_HIGH 2
+#define AXP20X_GPIO3_FUNCTION_INPUT    4
+
 #define AXP20X_FUNC_GPIO_OUT           0
 #define AXP20X_FUNC_GPIO_IN            1
 #define AXP20X_FUNC_LDO                        2

@@ -73,6 +78,7 @@ static const struct pinctrl_pin_desc axp209_pins[] = {
        PINCTRL_PIN(0, "GPIO0"),
        PINCTRL_PIN(1, "GPIO1"),
        PINCTRL_PIN(2, "GPIO2"),
+       PINCTRL_PIN(3, "GPIO3"),
 };
 
 static const struct pinctrl_pin_desc axp22x_pins[] = {

@@ -130,6 +136,14 @@ static int axp20x_gpio_get(struct gpio_chip *chip, unsigned int offset)
        unsigned int val;
        int ret;
 
+       /* AXP209 has GPIO3 status sharing the settings register */
+       if (offset == 3) {
+               ret = regmap_read(pctl->regmap, AXP20X_GPIO3_CTRL, &val);
+               if (ret)
+                       return ret;
+               return !!(val & BIT(0));
+       }
+
        ret = regmap_read(pctl->regmap, AXP20X_GPIO20_SS, &val);
        if (ret)
                return ret;

@@ -144,6 +158,17 @@ static int axp20x_gpio_get_direction(struct gpio_chip *chip,
        unsigned int val;
        int reg, ret;
 
+       /* AXP209 GPIO3 settings have a different layout */
+       if (offset == 3) {
+               ret = regmap_read(pctl->regmap, AXP20X_GPIO3_CTRL, &val);
+               if (ret)
+                       return ret;
+               if (val & AXP20X_GPIO3_FUNCTION_INPUT)
+                       return GPIO_LINE_DIRECTION_IN;
+
+               return GPIO_LINE_DIRECTION_OUT;
+       }
+
        reg = axp20x_gpio_get_reg(offset);
        if (reg < 0)
                return reg;

@@ -184,6 +209,15 @@ static void axp20x_gpio_set(struct gpio_chip *chip, unsigned int offset,
        struct axp20x_pctl *pctl = gpiochip_get_data(chip);
        int reg;
 
+       /* AXP209 has GPIO3 status sharing the settings register */
+       if (offset == 3) {
+               regmap_update_bits(pctl->regmap, AXP20X_GPIO3_CTRL,
+                                  AXP20X_GPIO3_FUNCTIONS,
+                                  value ? AXP20X_GPIO3_FUNCTION_OUT_HIGH :
+                                  AXP20X_GPIO3_FUNCTION_OUT_LOW);
+               return;
+       }
+
        reg = axp20x_gpio_get_reg(offset);
        if (reg < 0)
                return;

@@ -200,6 +234,14 @@ static int axp20x_pmx_set(struct pinctrl_dev *pctldev, unsigned int offset,
        struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
        int reg;
 
+       /* AXP209 GPIO3 settings have a different layout */
+       if (offset == 3) {
+               return regmap_update_bits(pctl->regmap, AXP20X_GPIO3_CTRL,
+                                  AXP20X_GPIO3_FUNCTIONS,
+                                  config == AXP20X_MUX_GPIO_OUT ? AXP20X_GPIO3_FUNCTION_OUT_LOW :
+                                  AXP20X_GPIO3_FUNCTION_INPUT);
+       }
+
        reg = axp20x_gpio_get_reg(offset);
        if (reg < 0)
                return reg;
--

2.39.2

The AXP209 device has a 4th GPIO which has a slightly different register setup, where the control + status bits are held in a single register rather than sharing AXP20X_GPIO20_SS with GPIOs 0-2.

Signed-off-by Jonathan McDowell <[email protected]>

---
 drivers/pinctrl/pinctrl-axp209.c | 42 ++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

drivers/pinctrl/pinctrl-axp209.c +42 -0

index 0bc1b381a2b8..b3ba25435c34 100644
@@ -30,6 +30,11 @@
 #define AXP20X_GPIO_FUNCTION_OUT_HIGH	1
 #define AXP20X_GPIO_FUNCTION_INPUT	2
 
+#define AXP20X_GPIO3_FUNCTIONS		GENMASK(2, 1)
+#define AXP20X_GPIO3_FUNCTION_OUT_LOW	0
+#define AXP20X_GPIO3_FUNCTION_OUT_HIGH	2
+#define AXP20X_GPIO3_FUNCTION_INPUT	4
+
 #define AXP20X_FUNC_GPIO_OUT		0
 #define AXP20X_FUNC_GPIO_IN		1
 #define AXP20X_FUNC_LDO			2

@@ -73,6 +78,7 @@ static const struct pinctrl_pin_desc axp209_pins[] = {
 	PINCTRL_PIN(0, "GPIO0"),
 	PINCTRL_PIN(1, "GPIO1"),
 	PINCTRL_PIN(2, "GPIO2"),
+	PINCTRL_PIN(3, "GPIO3"),
 };
 
 static const struct pinctrl_pin_desc axp22x_pins[] = {

@@ -130,6 +136,14 @@ static int axp20x_gpio_get(struct gpio_chip *chip, unsigned int offset)
 	unsigned int val;
 	int ret;
 
+	/* AXP209 has GPIO3 status sharing the settings register */
+	if (offset == 3) {
+		ret = regmap_read(pctl->regmap, AXP20X_GPIO3_CTRL, &val);
+		if (ret)
+			return ret;
+		return !!(val & BIT(0));
+	}
+
 	ret = regmap_read(pctl->regmap, AXP20X_GPIO20_SS, &val);
 	if (ret)
 		return ret;

@@ -144,6 +158,17 @@ static int axp20x_gpio_get_direction(struct gpio_chip *chip,
 	unsigned int val;
 	int reg, ret;
 
+	/* AXP209 GPIO3 settings have a different layout */
+	if (offset == 3) {
+		ret = regmap_read(pctl->regmap, AXP20X_GPIO3_CTRL, &val);
+		if (ret)
+			return ret;
+		if (val & AXP20X_GPIO3_FUNCTION_INPUT)
+			return GPIO_LINE_DIRECTION_IN;
+
+		return GPIO_LINE_DIRECTION_OUT;
+	}
+
 	reg = axp20x_gpio_get_reg(offset);
 	if (reg < 0)
 		return reg;

@@ -184,6 +209,15 @@ static void axp20x_gpio_set(struct gpio_chip *chip, unsigned int offset,
 	struct axp20x_pctl *pctl = gpiochip_get_data(chip);
 	int reg;
 
+	/* AXP209 has GPIO3 status sharing the settings register */
+	if (offset == 3) {
+		regmap_update_bits(pctl->regmap, AXP20X_GPIO3_CTRL,
+				   AXP20X_GPIO3_FUNCTIONS,
+				   value ? AXP20X_GPIO3_FUNCTION_OUT_HIGH :
+				   AXP20X_GPIO3_FUNCTION_OUT_LOW);
+		return;
+	}
+
 	reg = axp20x_gpio_get_reg(offset);
 	if (reg < 0)
 		return;

@@ -200,6 +234,14 @@ static int axp20x_pmx_set(struct pinctrl_dev *pctldev, unsigned int offset,
 	struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
 	int reg;
 
+	/* AXP209 GPIO3 settings have a different layout */
+	if (offset == 3) {
+		return regmap_update_bits(pctl->regmap, AXP20X_GPIO3_CTRL,
+				   AXP20X_GPIO3_FUNCTIONS,
+				   config == AXP20X_MUX_GPIO_OUT ? AXP20X_GPIO3_FUNCTION_OUT_LOW :
+				   AXP20X_GPIO3_FUNCTION_INPUT);
+	}
+
 	reg = axp20x_gpio_get_reg(offset);
 	if (reg < 0)
 		return reg;

This small patch series adds some improvements for the C.H.I.P DTS, enabling bluetooth, exporting the PMIC temperature details via iio-hwmon and finally adding the appropriate base pinmux info for an external MMC card. As a pre-requisite for the Bluetooth it also adds support to the AXP209 driver for GPIO3, which is the Bluetooth device wakeup line.

v3:
- Add Reviewed-By/Acked-Bys
- Drop redundant else
- Switch to GENMASK/decimal values for GPIO3 function defs v2:
- Fix missing ; on bluetooth stanza in DTS
- Add device/host wake GPIOs for Bluetooth device
- Add omit-if-no-ref on the port E pinmux stanza
- Rename axp20x_temp to pmic-temp
- Add AXP209 GPIO3 support

Jonathan McDowell (5):
dt-bindings: gpio: Add GPIO3 for AXP209 GPIO binding schema
pinctrl: axp209: Add support for GPIO3 on the AXP209
ARM: dts: sun5i: chip: Enable bluetooth
ARM: dts: sun5i: Add port E pinmux settings for mmc2
ARM: dts: axp209: Add iio-hwmon node for internal temperature

 .../bindings/gpio/x-powers,axp209-gpio.yaml   |  1 +
 arch/arm/boot/dts/axp209.dtsi                 |  7 ++++
 arch/arm/boot/dts/sun5i-r8-chip.dts           |  6 +++
 arch/arm/boot/dts/sun5i.dtsi                  |  9 ++++
 drivers/pinctrl/pinctrl-axp209.c              | 42 +++++++++++++++++++
 5 files changed, 65 insertions(+)