Hey, Am Freitag, 18. Oktober 2024, 11:35:51 CEST schrieb Diederik de Haas: > Hi Heiko, > > On Wed Oct 16, 2024 at 2:35 PM CEST, Diederik de Haas wrote: > > On Wed Oct 16, 2024 at 11:41 AM CEST, Diederik de Haas wrote: > > > On Tue Oct 8, 2024 at 9:28 PM CEST, Heiko Stuebner wrote: > > > > On Tue, 8 Oct 2024 13:15:35 +0200, Diederik de Haas wrote: > > > > > This is a set of 4 small device-tree validation fixes. > > > > > > > > > > Patch 1 adds the power-domains property to the csi dphy node on rk356x. > > > > > Patch 2 removes the 2nd interrupt from the hdmi node on rk3328. > > > > > Patch 3 replaces 'wake' with 'wakeup' on PineNote BT node. > > > > > Patch 4 replaces 'reset-gpios' with 'shutdown-gpios' on brcm BT nodes. > > > > > > > > Applied, thanks! > > > > > > > > [2/4] arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328 > > > > commit: de50a7e3681771c6b990238af82bf1dea9b11b21 > > > > [3/4] arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node > > > > commit: 87299d6ee95a37d2d576dd8077ea6860f77ad8e2 > > > > [4/4] arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes > > > > commit: 2b6a3f857550e52b1cd4872ebb13cb3e3cf12f5f > > > > > > Please revert the 4th patch. > > > > > > I must have messed up my testing previously, but BT does not work on the > > > PineNote with the 4th patch applied and does work with it reverted. > > > > FWIW, I figured out what went wrong. > > My testing was correct, but redo-ing the implementation to make it ready > > for submission wasn't very smart. > > > > With ``shutdown-gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;`` > > it does work correctly, but I forgot to change GPIO_ACTIVE_LOW to > > GPIO_ACTIVE_HIGH before submitting. > > > > I'll first figure out a better procedure before making a new submission, > > so the revert is still the best approach IMO. > > I've now done a new submission: > https://lore.kernel.org/linux-rockchip/20241018092237.6774-1-didi.debian@xxxxxxxxx/ > > So please don't revert the 4th patch now. hehe ok :-) . I meant to ask if the fix wasn't simply toggling the gpio polarity, and I guess with your patch you were faster than my question. Heiko
