Linux wireless drivers development
 help / color / mirror / Atom feed
* [PATCH v2 06/13] pinctrl: sunxi: Support I/O bias voltage setting on H6
From: megous @ 2019-04-09  0:24 UTC (permalink / raw)
  To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
	Linus Walleij
  Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
	Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
	Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
	devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>

From: Ondrej Jirman <megous@megous.com>

H6 SoC has a "pio group withstand voltage mode" register (datasheet
description), that needs to be used to select either 1.8V or 3.3V I/O mode,
based on what voltage is powering the respective pin banks and is thus used
for I/O signals.

Add support for configuring this register according to the voltage of the
pin bank regulator (if enabled).

This is similar to the support for I/O bias voltage setting patch for A80
and the same concerns apply. See:

  commit 402bfb3c1352 ("Support I/O bias voltage setting on A80")

Signed-off-by: Ondrej Jirman <megous@megous.com>
---
 drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c |  1 +
 drivers/pinctrl/sunxi/pinctrl-sunxi.c     | 10 ++++++++++
 drivers/pinctrl/sunxi/pinctrl-sunxi.h     |  4 ++++
 3 files changed, 15 insertions(+)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
index ef4268cc6227..30b1befa8ed8 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
@@ -591,6 +591,7 @@ static const struct sunxi_pinctrl_desc h6_pinctrl_data = {
 	.irq_banks = 4,
 	.irq_bank_map = h6_irq_bank_map,
 	.irq_read_needs_mux = true,
+	.io_bias_cfg_variant = IO_BIAS_CFG_V2,
 };
 
 static int h6_pinctrl_probe(struct platform_device *pdev)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index b8dd58ef33b7..0ab50a15a716 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -607,6 +607,8 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
 					 unsigned pin,
 					 struct regulator *supply)
 {
+	unsigned short bank = pin / PINS_PER_BANK;
+	unsigned long flags;
 	u32 val, reg;
 	int uV;
 
@@ -642,6 +644,14 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
 		reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
 		reg &= ~IO_BIAS_MASK;
 		writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
+	} else if (pctl->desc->io_bias_cfg_variant == IO_BIAS_CFG_V2) {
+		val = uV <= 1800000 ? 1 : 0;
+
+		raw_spin_lock_irqsave(&pctl->lock, flags);
+		reg = readl(pctl->membase + PIO_POW_MOD_SEL_REG);
+		reg &= ~(1 << bank);
+		writel(reg | val << bank, pctl->membase + PIO_POW_MOD_SEL_REG);
+		raw_spin_unlock_irqrestore(&pctl->lock, flags);
 	}
 
 	return 0;
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index 642f667e99d2..4044a3cb1819 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -95,8 +95,12 @@
 #define PINCTRL_SUN7I_A20	BIT(7)
 #define PINCTRL_SUN8I_R40	BIT(8)
 
+#define PIO_POW_MOD_SEL_REG	0x340
+
 /* Bias voltage configuration done via Pn_GRP_CONFIG registers. */
 #define IO_BIAS_CFG_V1		1
+/* Bias voltage set in the PIO_POW_MOD_SEL_REG register. */
+#define IO_BIAS_CFG_V2		2
 
 struct sunxi_desc_function {
 	unsigned long	variant;
-- 
2.21.0


^ permalink raw reply related
* [PATCH v2 01/13] dt-bindings: sunxi: Add compatible for OrangePi 3 board
From: megous @ 2019-04-09  0:24 UTC (permalink / raw)
  To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
	Linus Walleij
  Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
	Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
	Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
	devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>

From: Ondrej Jirman <megous@megous.com>

Add new Xunlong Orange Pi 3 board compatible string to the bindings
documentation.

Signed-off-by: Ondrej Jirman <megous@megous.com>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 11563d3f7c65..b82db740125b 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -711,6 +711,11 @@ properties:
           - const: xunlong,orangepi-2
           - const: allwinner,sun8i-h3
 
+      - description: Xunlong OrangePi 3
+        items:
+          - const: xunlong,orangepi-3
+          - const: allwinner,sun50i-h6
+
       - description: Xunlong OrangePi Lite
         items:
           - const: xunlong,orangepi-lite
-- 
2.21.0


^ permalink raw reply related
* [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
From: megous @ 2019-04-09  0:24 UTC (permalink / raw)
  To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
	Linus Walleij
  Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
	Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
	Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
	devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	linux-gpio
In-Reply-To: <20190409002452.14551-1-megous@megous.com>

From: Ondrej Jirman <megous@megous.com>

Orange Pi 3 is a H6 based SBC made by Xulong, released in January 2019. It
has the following features:

- Allwinner H6 quad-core 64-bit ARM Cortex-A53
- GPU Mali-T720
- 1GB or 2GB LPDDR3 RAM
- AXP805 PMIC
- AP6256 Wifi/BT 5.0
- USB 2.0 host port (A)
- USB 2.0 micro usb, OTG
- USB 3.0 Host + 4 port USB hub (GL3510)
- Gigabit Ethernet (Realtek RTL8211E phy)
- HDMI 2.0 port
- soldered eMMC (optional)
- 3x LED (one is on the bottom)
- microphone
- audio jack
- PCIe

Add basic support for the board.

Signed-off-by: Ondrej Jirman <megous@megous.com>
---
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../dts/allwinner/sun50i-h6-orangepi-3.dts    | 216 ++++++++++++++++++
 2 files changed, 217 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index e4dce2f6fa3a..285a7cb5135b 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
new file mode 100644
index 000000000000..5fbc5e410883
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2019 Ondřej Jirman <megous@megous.com>
+ */
+
+/dts-v1/;
+
+#include "sun50i-h6.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	model = "OrangePi 3";
+	compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		power {
+			label = "orangepi:red:power";
+			gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
+			default-state = "on";
+		};
+
+		status {
+			label = "orangepi:green:status";
+			gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
+		};
+	};
+
+	reg_vcc5v: vcc5v {
+		/* board wide 5V supply directly from the DC jack */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-5v";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+};
+
+&cpu0 {
+	cpu-supply = <&reg_dcdca>;
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ehci3 {
+	status = "okay";
+};
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins>;
+	vmmc-supply = <&reg_cldo1>;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+	bus-width = <4>;
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ohci3 {
+	status = "okay";
+};
+
+&pio {
+	vcc-pc-supply = <&reg_bldo2>;
+	vcc-pd-supply = <&reg_cldo1>;
+};
+
+&r_i2c {
+	status = "okay";
+
+	axp805: pmic@36 {
+		compatible = "x-powers,axp805", "x-powers,axp806";
+		reg = <0x36>;
+		interrupt-parent = <&r_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		x-powers,self-working-mode;
+		vina-supply = <&reg_vcc5v>;
+		vinb-supply = <&reg_vcc5v>;
+		vinc-supply = <&reg_vcc5v>;
+		vind-supply = <&reg_vcc5v>;
+		vine-supply = <&reg_vcc5v>;
+		aldoin-supply = <&reg_vcc5v>;
+		bldoin-supply = <&reg_vcc5v>;
+		cldoin-supply = <&reg_vcc5v>;
+
+		regulators {
+			reg_aldo1: aldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc-pl-led-ir";
+			};
+
+			reg_aldo2: aldo2 {
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc33-audio-tv-ephy-mac";
+			};
+
+			/* ALDO3 is shorted to CLDO1 */
+			reg_aldo3: aldo3 {
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc33-io-pd-emmc-sd-usb-uart-1";
+			};
+
+			reg_bldo1: bldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc18-dram-bias-pll";
+			};
+
+			reg_bldo2: bldo2 {
+				regulator-always-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc-efuse-pcie-hdmi-pc";
+			};
+
+			bldo3 {
+				/* unused */
+			};
+
+			bldo4 {
+				/* unused */
+			};
+
+			reg_cldo1: cldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc33-io-pd-emmc-sd-usb-uart-2";
+			};
+
+			cldo2 {
+				/* unused */
+			};
+
+			cldo3 {
+				/* unused */
+			};
+
+			reg_dcdca: dcdca {
+				regulator-always-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1160000>;
+				regulator-name = "vdd-cpu";
+			};
+
+			reg_dcdcc: dcdcc {
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <1080000>;
+				regulator-name = "vdd-gpu";
+			};
+
+			reg_dcdcd: dcdcd {
+				regulator-always-on;
+				regulator-min-microvolt = <960000>;
+				regulator-max-microvolt = <960000>;
+				regulator-name = "vdd-sys";
+			};
+
+			reg_dcdce: dcdce {
+				regulator-always-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "vcc-dram";
+			};
+
+			sw {
+				/* unused */
+			};
+		};
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_ph_pins>;
+	status = "okay";
+};
+
+&usb2otg {
+	/*
+	 * Beware that this board will not automatically disconnect
+	 * VBUS from DCIN, when self-powered and used as a peripheral.
+	 */
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&usb2phy {
+	usb0_id_det-gpios = <&pio 2 15 GPIO_ACTIVE_HIGH>; /* PC15 */
+	usb0_vbus-supply = <&reg_vcc5v>;
+	usb3_vbus-supply = <&reg_vcc5v>;
+	status = "okay";
+};
-- 
2.21.0


^ permalink raw reply related
* [PATCH v2 03/13] net: stmmac: sun8i: add support for Allwinner H6 EMAC
From: megous @ 2019-04-09  0:24 UTC (permalink / raw)
  To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
	Linus Walleij
  Cc: Icenowy Zheng, David Airlie, Daniel Vetter, Mark Rutland,
	Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
	Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
	devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	linux-gpio, Ondrej Jirman
In-Reply-To: <20190409002452.14551-1-megous@megous.com>

From: Icenowy Zheng <icenowy@aosc.io>

The EMAC on Allwinner H6 is just like the one on A64. The "internal PHY" on
H6 is on a co-packaged AC200 chip, and it's not really internal (it's
connected via RMII at PA GPIO bank).

Add support for the Allwinner H6 EMAC in the dwmac-sun8i driver.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c    | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 195669f550f0..20c19afb8316 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -147,6 +147,20 @@ static const struct emac_variant emac_variant_a64 = {
 	.tx_delay_max = 7,
 };
 
+static const struct emac_variant emac_variant_h6 = {
+	.default_syscon_value = 0x50000,
+	.syscon_field = &sun8i_syscon_reg_field,
+	/* The "Internal PHY" of H6 is not on the die. It's on the
+	 * co-packaged AC200 chip instead.
+	 */
+	.soc_has_internal_phy = false,
+	.support_mii = true,
+	.support_rmii = true,
+	.support_rgmii = true,
+	.rx_delay_max = 31,
+	.tx_delay_max = 7,
+};
+
 #define EMAC_BASIC_CTL0 0x00
 #define EMAC_BASIC_CTL1 0x04
 #define EMAC_INT_STA    0x08
@@ -1210,6 +1224,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
 		.data = &emac_variant_r40 },
 	{ .compatible = "allwinner,sun50i-a64-emac",
 		.data = &emac_variant_a64 },
+	{ .compatible = "allwinner,sun50i-h6-emac",
+		.data = &emac_variant_h6 },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
-- 
2.21.0


^ permalink raw reply related
* [PATCH v2 00/13] Add support for Orange Pi 3
From: megous @ 2019-04-09  0:24 UTC (permalink / raw)
  To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
	Linus Walleij
  Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
	Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
	Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
	devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	linux-gpio

From: Ondrej Jirman <megous@megous.com>

This series implements support for Xunlong Orange Pi 3 board.

Unfortunately, this board needs some small driver patches, so I have
split the boards DT patch into chunks that require patches for drivers
in various subsystems.

In v2 of this series I've reordered the patches and I've put less
controversial patches first.

Suggested merging plan/dependencies:

- Basic board dts can work alone. (patches 1-2)
- Pinctrl and stmmac patches are needed for ethernet support.
  (patches 3-7)
- HDMI depends on sorting out how to model DDC voltage shifter
  in DT, which is not clear yet. (patches 8-10)
- WiFi stuff will have to wait for H6 RTC patches, which in turn
  depend on ChenYu's RTC series, to be merged. That will take a
  while yet. I'm just keeping them in the series for completness.
  (patches 11-13)

This patch is also needed to not get segfault on boot (it was already
merged a day ago or so): 
  https://lkml.org/lkml/2019/4/5/856

Changes in v2:
- added dt-bindings documentation for the board's compatible string
  (suggested by Clement)
- addressed checkpatch warnings and code formatting issues (on Maxime's
  suggestions)
- stmmac: dropped useless parenthesis, reworded description of the patch
  (suggested by Sergei)
- drop useles dev_info() about the selected io bias voltage
- docummented io voltage bias selection variant macros
- wifi: marked WiFi DTS patch and realted mmc1_pins as "DO NOT MERGE",
  because wifi depends on H6 RTC support that's not merged yet (suggested
  by Clement)
- added missing signed-of-bys
- changed &usb2otg dr_mode to otg, and added a note about VBUS
- improved wording of HDMI driver's DDC power supply patch

Open questions ATM:
- should mmc1_pins be default pinconf for mmc1?
- how to model DDC IO voltage shifter enable signal for HDMI? (it's not
  really a power supply, but it's modelled as one in the patches for now)


Please take a look.

thank you and regards,
  Ondrej Jirman

Icenowy Zheng (2):
  net: stmmac: sun8i: add support for Allwinner H6 EMAC
  net: stmmac: sun8i: force select external PHY when no internal one

Ondrej Jirman (11):
  dt-bindings: sunxi: Add compatible for OrangePi 3 board
  arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
  pinctrl: sunxi: Prepare for alternative bias voltage setting methods
  pinctrl: sunxi: Support I/O bias voltage setting on H6
  arm64: dts: allwinner: orange-pi-3: Enable ethernet
  drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
  dt-bindings: display: sun4i-drm: Add DDC power supply
  arm64: dts: allwinner: orange-pi-3: Enable HDMI output
  brcmfmac: Loading the correct firmware for brcm43456
  [DO NOT MERGE] arm64: dts: allwinner: h6: Add MMC1 pins
  [DO NOT MERGE] arm64: dts: allwinner: orange-pi-3: Enable WiFi

 .../devicetree/bindings/arm/sunxi.yaml        |   5 +
 .../bindings/display/sunxi/sun4i-drm.txt      |   1 +
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../dts/allwinner/sun50i-h6-orangepi-3.dts    | 343 ++++++++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  |   8 +
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c         |  17 +-
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h         |   1 +
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c |  21 ++
 .../broadcom/brcm80211/brcmfmac/sdio.c        |   4 +-
 drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c     |   2 +-
 drivers/pinctrl/sunxi/pinctrl-sunxi.c         |  49 ++-
 drivers/pinctrl/sunxi/pinctrl-sunxi.h         |   9 +-
 13 files changed, 441 insertions(+), 21 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts

-- 
2.21.0


^ permalink raw reply
* linux-next: manual merge of the mac80211-next tree with the mac80211 tree
From: Stephen Rothwell @ 2019-04-09  1:06 UTC (permalink / raw)
  To: Johannes Berg, Wireless
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Felix Fietkau

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

Hi all,

Today's linux-next merge of the mac80211-next tree got a conflict in:

  net/mac80211/tx.c

between commit:

  eb9b64e3a9f8 ("mac80211: fix memory accounting with A-MSDU aggregation")

from the mac80211 tree and commit:

  dcec1d9bc8a7 ("mac80211: calculate hash for fq without holding fq->lock in itxq enqueue")

from the mac80211-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/tx.c
index 2e816dd67be7,3655aae96df1..000000000000
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@@ -3221,7 -3219,7 +3219,8 @@@ static bool ieee80211_amsdu_aggregate(s
  	u8 max_subframes = sta->sta.max_amsdu_subframes;
  	int max_frags = local->hw.max_tx_fragments;
  	int max_amsdu_len = sta->sta.max_amsdu_len;
 +	int orig_truesize;
+ 	u32 flow_idx;
  	__be16 len;
  	void *data;
  	bool ret = false;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply
* Re: [PATCH RFC] staging: wilc1000: give usleep_range a range
From: Nicholas Mc Guire @ 2019-04-09  1:36 UTC (permalink / raw)
  To: Adham.Abozaeid
  Cc: hofrat, Ajay.Kathat, gregkh, linux-wireless, devel, linux-kernel
In-Reply-To: <d38b17d8-5b0f-5b5e-2933-0626700e8546@microchip.com>

On Mon, Apr 08, 2019 at 09:10:00PM +0000, Adham.Abozaeid@microchip.com wrote:
> Hi Nicholas
> 
> On 4/6/19 5:01 AM, Nicholas Mc Guire wrote:
> > External E-Mail
> >
> >
> > Someone that knows the motivation for setting the time to 2 millisecond
> > might need to check if the 2 milliseconds where seen as tollerable max or
> > min - I'm assuming it was the min so extending.
> 
> 2 msec is the time the chip takes to wake up from sleep.
> 
> Increasing the maximum to 5 msec will impact the throughput since this call is on the transmit path.
> 

ok - would it be tollerable to make it 2 - 2.5 ms ?
even that would allow for the hrtimer subsystem to optimize
a lot. In any case the min==max case gives you very little
if you run a test-case with usleep_range(1000,1000) and
a loop with usleep_range(1000,2000) and look at the distribution
you will have a hard time seeing any difference.

I doubt you would readily see the change from usleep_range(2000,2000)
to usleep_range(2000,3000) in benchmarks - maybe (2000,5000) would
be visible.

My assumption (I have not analyzed it in detail) is that if
you have a high re-use of existing timers that the setup of the timer
is faster and thats why increasing the range > 0 can actually result
in better jitter distribution.

thx!
hofrat

> > diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
> > index c238969..42da533 100644
> > --- a/drivers/staging/wilc1000/wilc_wlan.c
> > +++ b/drivers/staging/wilc1000/wilc_wlan.c
> > @@ -408,7 +408,7 @@ void chip_wakeup(struct wilc *wilc)
> >  			wilc->hif_func->hif_write_reg(wilc, 1, reg & ~BIT(1));
> >  
> >  			do {
> > -				usleep_range(2 * 1000, 2 * 1000);
> > +				usleep_range(2 * 1000, 5 * 1000);
> >  				wilc_get_chipid(wilc, true);
> >  			} while (wilc_get_chipid(wilc, true) == 0);
> >  		} while (wilc_get_chipid(wilc, true) == 0);
> > @@ -423,7 +423,7 @@ void chip_wakeup(struct wilc *wilc)
> >  						     &clk_status_reg);
> >  
> >  			while ((clk_status_reg & 0x1) == 0) {
> > -				usleep_range(2 * 1000, 2 * 1000);
> > +				usleep_range(2 * 1000, 5 * 1000);
> >  
> >  				wilc->hif_func->hif_read_reg(wilc, 0xf1,
> >  							     &clk_status_reg);
> 
> 
> Thanks,
> 
> Adham
> 

^ permalink raw reply
* [PATCH 1/2] NFC: st95hf: use msleep for long delay
From: Nicholas Mc Guire @ 2019-04-09  3:48 UTC (permalink / raw)
  To: Samuel Ortiz; +Cc: Daniel Mack, linux-wireless, linux-kernel, Nicholas Mc Guire

usleep_ranges is backed by hrtimers - for a delay of 50ms
notably in a loop using a hrtimer is of no benefit and
msleep() should be fine  here (see
Documentation/timers/timers-howto.txt).

Signed-off-by: Nicholas Mc Guire <hofrat@opentech.at>
---

Problem located with an experimental coccinelle script

Patch was compile tested with: x86_64_defconfig + SPI=y,
NFC=y, NFC_DIGITAL=y, NFC_ST95HF=m

Patch is against 5.1-rc3 (localversion-next is -next-20190408)

 drivers/nfc/st95hf/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nfc/st95hf/core.c b/drivers/nfc/st95hf/core.c
index a50a95c..34bf1d7 100644
--- a/drivers/nfc/st95hf/core.c
+++ b/drivers/nfc/st95hf/core.c
@@ -535,7 +535,7 @@ static int st95hf_por_sequence(struct st95hf_context *st95context)
 			st95hf_send_spi_reset_sequence(st95context);
 
 		/* delay of 50 milisecond */
-		usleep_range(50000, 51000);
+		msleep(50);
 	} while (nth_attempt++ < 3);
 
 	return -ETIMEDOUT;
-- 
2.1.4


^ permalink raw reply related
* [PATCH 2/2] NFC: st95hf: fix timing factor error
From: Nicholas Mc Guire @ 2019-04-09  3:48 UTC (permalink / raw)
  To: Samuel Ortiz; +Cc: Daniel Mack, linux-wireless, linux-kernel, Nicholas Mc Guire
In-Reply-To: <1554781699-42604-1-git-send-email-hofrat@opentech.at>

The comment suggests that per ISO standard 5-6ms are required
but the code is 50-60ms delay - look like a simple typo - so
set the delay to 5000 to 6000.

Signed-off-by: Nicholas Mc Guire <hofrat@opentech.at>
Fixes: cab47333f0f7 ("NFC: Add STMicroelectronics ST95HF driver")
---

Problem located with an experimental coccinelle script

Note that as I do not have the standard - it could of course
also be a typo in the comment - in which case it should
then probably be using msleep(60) not usleep_ranges(). 

Patch was compile tested with: x86_64_defconfig + SPI=y,
NFC=y, NFC_DIGITAL=y, NFC_ST95HF=m

Patch is against 5.1-rc3 (localversion-next is -next-20190408)

 drivers/nfc/st95hf/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nfc/st95hf/core.c b/drivers/nfc/st95hf/core.c
index 34bf1d7..89e6160 100644
--- a/drivers/nfc/st95hf/core.c
+++ b/drivers/nfc/st95hf/core.c
@@ -430,7 +430,7 @@ static int st95hf_select_protocol(struct st95hf_context *stcontext, int type)
 		 * delay of 5-6 ms is required after select protocol
 		 * command in case of ISO14443 Type B
 		 */
-		usleep_range(50000, 60000);
+		usleep_range(5000, 6000);
 
 		/* secondary config. for 14443Type 4B after protocol select */
 		result = secondary_configuration_type4b(stcontext);
-- 
2.1.4


^ permalink raw reply related
* RE: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in simulate fw crash
From: Wen Gong @ 2019-04-09  5:09 UTC (permalink / raw)
  To: Michał Kazior; +Cc: Wen Gong, linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <CABvG-CWz0rBCXfF7mX9L62=fmdcYhpOaO5JNLtvSE87o_XJFng@mail.gmail.com>

> From: Michał Kazior <kazikcz@gmail.com>
> Sent: Tuesday, April 9, 2019 1:27 AM
> To: Wen Gong <wgong@qti.qualcomm.com>
> Cc: Wen Gong <wgong@codeaurora.org>; linux-wireless <linux-
> wireless@vger.kernel.org>; ath10k@lists.infradead.org
> Subject: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in
> simulate fw crash
> 
> > > Hi Michal,
> > > There have a stress test case for the simulate fw crash, it will simulate fw
> > > crash
> > > in a very short time for each test, this will trigger the stress test fail.
> > > The simulate fw crash process should not be run parallel, after this patch,
> the
> > > Stress test case will pass.
> > > >
> >
> > Hi Michał,
> > Do you have some new comments?
> 
> My original use case was to be able to exercise the driver's
> robustness in handling nested fw crashes, IOW crash-within-a-crash.
> 
> Your test case, as far as I understand, intends to perform
> consecutive, non-nested fw crash simulation stress test.
> 
> Both of these are mutually exclusive and your patch fixes your test
> case at the expense of breaking my original case.
> 
> To satisfy both I would suggest you either expose ar->state via
> debugfs and make your test procedure wait for that to get back into ON
> state before simulating a crash again, or to extend the set of current
> simulate_fw_crash commands (currently just: soft, hard, assert,
> hw-restart) to something that allows expressing the intent whether
> crash-in-crash prevention is intended (your case) or not (my original
> case).
> 
> This could be for example something like this:
>   echo soft wait-ready > simulate_fw_crash
> 
> The "wait-ready" extra keyword would imply crash-in-crash prevention.
> This would keep existing tools working (both behavior and syntax) and
> would allow your test case to be implemented.
> 
Is it easy to change your existing tools?
I want to change it to: echo soft skip-ready > simulate_fw_crash
The "skip-ready" extra keyword would imply crash-in-crash, *not* prevention.
My test tools is hard to change.

> 
> Michał

^ permalink raw reply
* Re: [PATCH v6 11/20] kvm/x86: Emulate MSR IA32_CORE_CAPABILITY
From: Xiaoyao Li @ 2019-04-09  6:03 UTC (permalink / raw)
  To: Thomas Gleixner, Fenghua Yu
  Cc: Ingo Molnar, Borislav Petkov, H Peter Anvin, Dave Hansen,
	Paolo Bonzini, Ashok Raj, Peter Zijlstra, Kalle Valo,
	Michael Chan, Ravi V Shankar, linux-kernel, x86, linux-wireless,
	netdev, kvm
In-Reply-To: <alpine.DEB.2.21.1904051356070.1802@nanos.tec.linutronix.de>

On Fri, 2019-04-05 at 14:00 +0200, Thomas Gleixner wrote:
> On Wed, 3 Apr 2019, Fenghua Yu wrote:
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> >  
> > +u64 kvm_get_core_capability(void)
> > +{
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(kvm_get_core_capability);
> 
> Why is this global and exported? The only users are in this very file.

You're right.
Will remove it in next version.

> Thanks,
> 
> 	tglx


^ permalink raw reply
* [PATCH] ath10k: Fix the wrong value of enums for wmi tlv stats id
From: Surabhi Vishnoi @ 2019-04-09  6:43 UTC (permalink / raw)
  To: ath10k; +Cc: linux-wireless, Surabhi Vishnoi

The enum value for WMI_TLV_STAT_PDEV, WMI_TLV_STAT_VDEV
and WMI_TLV_STAT_PEER is wrong, due to which the vdev stats
are not received from firmware in wmi_update_stats event.

Fix the enum values for above stats to receive all stats
from firmware in WMI_TLV_UPDATE_STATS_EVENTID.

Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1

Fixes: f40a307eb92c ("ath10k: Fill rx duration for each peer in fw_stats for WCN3990)
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/wmi.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index e1c40bb..12f57f9 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4535,9 +4535,10 @@ enum wmi_10_4_stats_id {
 };
 
 enum wmi_tlv_stats_id {
-	WMI_TLV_STAT_PDEV	= BIT(0),
-	WMI_TLV_STAT_VDEV	= BIT(1),
-	WMI_TLV_STAT_PEER	= BIT(2),
+	WMI_TLV_STAT_PEER	= BIT(0),
+	WMI_TLV_STAT_AP		= BIT(1),
+	WMI_TLV_STAT_PDEV	= BIT(2),
+	WMI_TLV_STAT_VDEV	= BIT(3),
 	WMI_TLV_STAT_PEER_EXTD  = BIT(10),
 };
 
-- 
1.9.1


^ permalink raw reply related
* Re: [PATCH 08/12] arm64: dts: allwinner: h6: Add MMC1 pins
From: Maxime Ripard @ 2019-04-09  7:20 UTC (permalink / raw)
  To: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
	David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
	Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
	Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
	linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	linux-gpio
In-Reply-To: <20190408224104.qwhk33qgem7bq5y7@core.my.home>

[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]

Hi,

On Tue, Apr 09, 2019 at 12:41:05AM +0200, Ondřej Jirman wrote:
> On Mon, Apr 08, 2019 at 09:43:27AM +0200, Maxime Ripard wrote:
> > On Sat, Apr 06, 2019 at 01:45:10AM +0200, megous@megous.com wrote:
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > ---
> > >  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > index 91fecab58836..dccad79da90c 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > @@ -238,6 +238,15 @@
> > >  				bias-pull-up;
> > >  			};
> > >
> > > +
> >
> > Extra line
> >
> > > +			mmc1_pins: mmc1-pins {
> > > +				pins = "PG0", "PG1", "PG2", "PG3",
> > > +				       "PG4", "PG5";
> > > +				function = "mmc1";
> > > +				drive-strength = <30>;
> > > +				bias-pull-up;
> > > +			};
> > > +
> >
> > Is that the only muxing option?
>
> I don't think so. I believe someone can use a 1-bit interface (bus-width = <1>),
> and then some data pins will be free. This pinconfig is for 4-bit bus width
> setup.
>
> Though other SoCs (ex. H3, A83T) don't consider this possibility and make the
> 4-bit config the default pinctrl for mmc1. To add to the confusion, on these
> SoCs 4-bit pinconf is the default, but 1bit bus-width is the (implicit) default.
> This led to some confusion in the past.
>
> So we can either:
> - keep consistency with what is done elsewhere, and make this default, despite
>   not being the only option,

What is done elsewhere is that if it's the only option, just call it
$controller_pins and make that the default. If it isn't, then call it
$(controller)_$(bank)_pins, and put it at the board level.

If it's not the only muxing option, then your name should be called
mmc1-pg-pins

> - or perhaps I can rename this to mmc1_bus_width4_pins, or somesuch, to make it
>   more explicit, and keep it non-default.

We haven't encountered a case where the 1-bit bus was actually used,
so there's no need to take care of that.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply
* Re: [PATCH 01/12] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
From: Maxime Ripard @ 2019-04-09  7:22 UTC (permalink / raw)
  To: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
	David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
	Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
	Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
	linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	linux-gpio
In-Reply-To: <20190408225851.svelyf7h3fiw4wjw@core.my.home>

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

On Tue, Apr 09, 2019 at 12:58:51AM +0200, Ondřej Jirman wrote:
> > > +&usb2otg {
> > > +	dr_mode = "host";
> > > +	status = "okay";
> > > +};
> > > +
> > > +&usb2phy {
> > > +	usb0_id_det-gpios = <&pio 2 15 GPIO_ACTIVE_HIGH>; /* PC15 */
> > > +	usb0_vbus-supply = <&reg_vcc5v>;
> > > +	usb3_vbus-supply = <&reg_vcc5v>;
> > > +	status = "okay";
> >
> > If we have an ID pin, then why is the OTG controller set to host?
>
> This board has fixed conenction between VBUS and DCIN, so if it is powered
> from DCIN and someone will try to connect it to the PC as a peripheral,
> they'll get PC's VBUS shorted to the power supply connected to DCIN.
>
> Depending on voltage difference between DCIN and PC's VBUS, you can get
> overcurrent condidion and PC's port shutdown.
>
> The board is not entirely foolproof in this regard.
>
> - It can be host powered when connected via microUSB
> - It can be self-powered and host an device on microUSB
> - It can be self-powered and serve as a peripheral if you modify
>   a cable (cut VBUS) or the host is expecting this and has some
>   VBUS detection logic (most hosts will not have this)
>
> I just didn't want to encourage use as a peripheral, because it's not
> very foolproof. But I guess, DTS file will not stop anyone anyway.
>
> I'll change it to otg, and maybe leave a small note.

Your solution was great actually. I guess making a comment explaining
what you just did would be better though, so that no one is confused.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply
* Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: Maxime Ripard @ 2019-04-09  7:23 UTC (permalink / raw)
  To: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
	David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
	Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
	Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
	linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	linux-gpio
In-Reply-To: <20190408232232.fsl2ddthwo2rr4ql@core.my.home>

[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]

On Tue, Apr 09, 2019 at 01:22:32AM +0200, Ondřej Jirman wrote:
> On Mon, Apr 08, 2019 at 09:40:42AM +0200, Maxime Ripard wrote:
> > On Sat, Apr 06, 2019 at 01:45:09AM +0200, megous@megous.com wrote:
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > Orange Pi 3 has two regulators that power the Realtek RTL8211E.
> > > According to the phy datasheet, both regulators need to be enabled
> > > at the same time, but we can only specify a single phy-supply in
> > > the DT.
> > >
> > > This can be achieved by making one regulator depedning on the
> > > other via vin-supply. While it's not a technically correct
> > > description of the hardware, it achieves the purpose.
> > >
> > > All values of RX/TX delay were tested exhaustively and a middle
> > > one of the working values was chosen.
> > >
> > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > ---
> > >  .../dts/allwinner/sun50i-h6-orangepi-3.dts    | 44 +++++++++++++++++++
> > >  1 file changed, 44 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > index 644946749088..5270142527f5 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > @@ -15,6 +15,7 @@
> > >
> > >  	aliases {
> > >  		serial0 = &uart0;
> > > +		ethernet0 = &emac;
> > >  	};
> > >
> > >  	chosen {
> > > @@ -64,6 +65,27 @@
> > >  		regulator-max-microvolt = <5000000>;
> > >  		regulator-always-on;
> > >  	};
> > > +
> > > +	/*
> > > +	 * The board uses 2.5V RGMII signalling. Power sequence
> > > +	 * to enable the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2)
> > > +	 * power rails at the same time and to wait 100ms.
> > > +	 */
> > > +	reg_gmac_2v5: gmac-2v5 {
> > > +                compatible = "regulator-fixed";
> > > +                regulator-name = "gmac-2v5";
> > > +                regulator-min-microvolt = <2500000>;
> > > +                regulator-max-microvolt = <2500000>;
> > > +                startup-delay-us = <100000>;
> > > +                enable-active-high;
> > > +                gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
> >
> > Is enable-active-high still needed? It's redundant with the
> > GPIO_ACTIVE_HIGH flag.
>
> Looking at the code, use/non-use of enable-active-high inhibits
> flags specified in gpio property. So the GPIO_ACTIVE_HIGH flag
> is ignored here (had GPIO_ACTIVE_LOW been used, the kernel would
> ignore it too and print a warning).
>
> So enable-active-high is still necessary here.

Too bad :/

> See comment in gpiolib-of.c where this is handled:
>
> /*
>  * The regulator GPIO handles are specified such that the
>  * presence or absence of "enable-active-high" solely controls
>  * the polarity of the GPIO line. Any phandle flags must
>  * be actively ignored.
>  */

Thanks for digging this out

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply
* Re: linux-next: manual merge of the mac80211-next tree with the mac80211 tree
From: Johannes Berg @ 2019-04-09  7:27 UTC (permalink / raw)
  To: Stephen Rothwell, Wireless
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Felix Fietkau
In-Reply-To: <20190409110607.29df3cf3@canb.auug.org.au>

Hi Stephen,

> Today's linux-next merge of the mac80211-next tree got a conflict in:
> 
>   net/mac80211/tx.c
> 
> between commit:
> 
>   eb9b64e3a9f8 ("mac80211: fix memory accounting with A-MSDU aggregation")
> 
> from the mac80211 tree and commit:
> 
>   dcec1d9bc8a7 ("mac80211: calculate hash for fq without holding fq->lock in itxq enqueue")
> 
> from the mac80211-next tree.

Thanks for the heads-up!

But yes, I'm aware. It seemed simple enough though that I decided to
keep it like that, I didn't really find a better solution.

johannes


^ permalink raw reply
* Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: Linus Walleij @ 2019-04-09  7:35 UTC (permalink / raw)
  To: Maxime Ripard, linux-sunxi, Chen-Yu Tsai, Rob Herring,
	Linus Walleij, David Airlie, Daniel Vetter, Mark Rutland,
	Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
	Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta,
	open list:DRM PANEL DRIVERS,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Linux ARM, linux-kernel@vger.kernel.org, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	open list:GPIO SUBSYSTEM
In-Reply-To: <20190408232232.fsl2ddthwo2rr4ql@core.my.home>

On Tue, Apr 9, 2019 at 1:22 AM Ondřej Jirman <megous@megous.com> wrote:

> > > +                enable-active-high;
> > > +                gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
> >
> > Is enable-active-high still needed? It's redundant with the
> > GPIO_ACTIVE_HIGH flag.
>
> Looking at the code, use/non-use of enable-active-high inhibits
> flags specified in gpio property. So the GPIO_ACTIVE_HIGH flag
> is ignored here (had GPIO_ACTIVE_LOW been used, the kernel would
> ignore it too and print a warning).
>
> So enable-active-high is still necessary here.
>
> See comment in gpiolib-of.c where this is handled:
>
> /*
>  * The regulator GPIO handles are specified such that the
>  * presence or absence of "enable-active-high" solely controls
>  * the polarity of the GPIO line. Any phandle flags must
>  * be actively ignored.
>  */

Yeah this caused me special headache in the current merge
window because of buggy code on my part.

This is an effect of this flag being defined for powerpc
ages before we properly implemented generic GPIO
bindings. We just have to respect it.

See:
https://marc.info/?l=linux-gpio&m=155417774822532&w=2

Yours,
Linus Walleij

^ permalink raw reply
* [PATCH 1/3] qtnfmac: handle channel switch events for connected stations only
From: Sergey Matyukevich @ 2019-04-09  7:35 UTC (permalink / raw)
  To: linux-wireless@vger.kernel.org; +Cc: Igor Mitsyanko, Sergey Matyukevich
In-Reply-To: <20190409073500.16402-1-sergey.matyukevich.os@quantenna.com>

Channel switch events from firmware should be processed only when STA
is already connected to BSS. On connect this notification is not needed
since full BSS info will be supplied by cfg80211_connect_result.

Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
---
 drivers/net/wireless/quantenna/qtnfmac/event.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/event.c b/drivers/net/wireless/quantenna/qtnfmac/event.c
index 6c1b886339ac..b57c8c18a8d0 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/event.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/event.c
@@ -493,14 +493,20 @@ qtnf_event_handle_freq_change(struct qtnf_wmac *mac,
 
 	for (i = 0; i < QTNF_MAX_INTF; i++) {
 		vif = &mac->iflist[i];
+
 		if (vif->wdev.iftype == NL80211_IFTYPE_UNSPECIFIED)
 			continue;
 
-		if (vif->netdev) {
-			mutex_lock(&vif->wdev.mtx);
-			cfg80211_ch_switch_notify(vif->netdev, &chandef);
-			mutex_unlock(&vif->wdev.mtx);
-		}
+		if (vif->wdev.iftype == NL80211_IFTYPE_STATION &&
+		    !vif->wdev.current_bss)
+			continue;
+
+		if (!vif->netdev)
+			continue;
+
+		mutex_lock(&vif->wdev.mtx);
+		cfg80211_ch_switch_notify(vif->netdev, &chandef);
+		mutex_unlock(&vif->wdev.mtx);
 	}
 
 	return 0;
-- 
2.11.0


^ permalink raw reply related
* [PATCH 0/3] qtnfmac: debugfs update and other misc fixes
From: Sergey Matyukevich @ 2019-04-09  7:35 UTC (permalink / raw)
  To: linux-wireless@vger.kernel.org; +Cc: Igor Mitsyanko, Sergey Matyukevich

Hello Kalle and all,

Here is the patch set with minor fixes and enhancements for qtnfmac driver,
that were not included into the previous larger series.

The major changes include the following items:
- updating debugfs structure to support multiple cards on a single host
- add kernel module param to control DFS slave radar detection behavior

Regards,
Sergey


Igor Mitsyanko (1):
  qtnfmac: allow to control DFS slave radar detection

Sergey Matyukevich (2):
  qtnfmac: handle channel switch events for connected stations only
  qtnfmac: modify debugfs to support multiple cards

 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c |  2 +-
 drivers/net/wireless/quantenna/qtnfmac/commands.c |  4 ++-
 drivers/net/wireless/quantenna/qtnfmac/commands.h |  3 +-
 drivers/net/wireless/quantenna/qtnfmac/core.c     | 35 +++++++++++++++++++++++
 drivers/net/wireless/quantenna/qtnfmac/core.h     |  2 ++
 drivers/net/wireless/quantenna/qtnfmac/debug.c    |  4 ++-
 drivers/net/wireless/quantenna/qtnfmac/event.c    | 16 +++++++----
 drivers/net/wireless/quantenna/qtnfmac/qlink.h    |  4 ++-
 8 files changed, 60 insertions(+), 10 deletions(-)

-- 
2.11.0


^ permalink raw reply
* [PATCH 2/3] qtnfmac: allow to control DFS slave radar detection
From: Sergey Matyukevich @ 2019-04-09  7:35 UTC (permalink / raw)
  To: linux-wireless@vger.kernel.org; +Cc: Igor Mitsyanko, Sergey Matyukevich
In-Reply-To: <20190409073500.16402-1-sergey.matyukevich.os@quantenna.com>

From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>

In ETSI region DFS slave device can operate in two modes on DFS channels:
 - do on-channel radar detection and use higher Tx power
 - don't do radar detection and use lower Tx power as a consequence

Allow user to control that behavior through qtnfmac module parameter.

Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 2 +-
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 4 +++-
 drivers/net/wireless/quantenna/qtnfmac/commands.h | 3 ++-
 drivers/net/wireless/quantenna/qtnfmac/core.c     | 9 +++++++++
 drivers/net/wireless/quantenna/qtnfmac/core.h     | 1 +
 drivers/net/wireless/quantenna/qtnfmac/qlink.h    | 4 +++-
 6 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index c78500bcaa2d..d90016125dfc 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -1008,7 +1008,7 @@ static void qtnf_cfg80211_reg_notifier(struct wiphy *wiphy,
 	pr_debug("MAC%u: initiator=%d alpha=%c%c\n", mac->macid, req->initiator,
 		 req->alpha2[0], req->alpha2[1]);
 
-	ret = qtnf_cmd_reg_notify(mac, req);
+	ret = qtnf_cmd_reg_notify(mac, req, qtnf_mac_slave_radar_get(wiphy));
 	if (ret) {
 		pr_err("MAC%u: failed to update region to %c%c: %d\n",
 		       mac->macid, req->alpha2[0], req->alpha2[1], ret);
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index 22313a46c3ae..459f6b81d2eb 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -2367,7 +2367,8 @@ int qtnf_cmd_send_updown_intf(struct qtnf_vif *vif, bool up)
 	return ret;
 }
 
-int qtnf_cmd_reg_notify(struct qtnf_wmac *mac, struct regulatory_request *req)
+int qtnf_cmd_reg_notify(struct qtnf_wmac *mac, struct regulatory_request *req,
+			bool slave_radar)
 {
 	struct wiphy *wiphy = priv_to_wiphy(mac);
 	struct qtnf_bus *bus = mac->bus;
@@ -2429,6 +2430,7 @@ int qtnf_cmd_reg_notify(struct qtnf_wmac *mac, struct regulatory_request *req)
 		break;
 	}
 
+	cmd->slave_radar = slave_radar;
 	cmd->num_channels = 0;
 
 	for (band = 0; band < NUM_NL80211_BANDS; band++) {
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.h b/drivers/net/wireless/quantenna/qtnfmac/commands.h
index 6406365287fc..88d7a3cd90d2 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.h
@@ -57,7 +57,8 @@ int qtnf_cmd_send_disconnect(struct qtnf_vif *vif,
 			     u16 reason_code);
 int qtnf_cmd_send_updown_intf(struct qtnf_vif *vif,
 			      bool up);
-int qtnf_cmd_reg_notify(struct qtnf_wmac *mac, struct regulatory_request *req);
+int qtnf_cmd_reg_notify(struct qtnf_wmac *mac, struct regulatory_request *req,
+			bool slave_radar);
 int qtnf_cmd_get_chan_stats(struct qtnf_wmac *mac, u16 channel,
 			    struct qtnf_chan_stats *stats);
 int qtnf_cmd_send_chan_switch(struct qtnf_vif *vif,
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.c b/drivers/net/wireless/quantenna/qtnfmac/core.c
index 54ea86ae4959..ad0c9e012056 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.c
@@ -16,6 +16,10 @@
 #define QTNF_DMP_MAX_LEN 48
 #define QTNF_PRIMARY_VIF_IDX	0
 
+static bool slave_radar = true;
+module_param(slave_radar, bool, 0644);
+MODULE_PARM_DESC(slave_radar, "set 0 to disable radar detection in slave mode");
+
 struct qtnf_frame_meta_info {
 	u8 magic_s;
 	u8 ifidx;
@@ -426,6 +430,11 @@ static struct qtnf_wmac *qtnf_core_mac_alloc(struct qtnf_bus *bus,
 	return mac;
 }
 
+bool qtnf_mac_slave_radar_get(struct wiphy *wiphy)
+{
+	return slave_radar;
+}
+
 static const struct ethtool_ops qtnf_ethtool_ops = {
 	.get_drvinfo = cfg80211_get_drvinfo,
 };
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h b/drivers/net/wireless/quantenna/qtnfmac/core.h
index af8372dfb927..d5caff45ac47 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -134,6 +134,7 @@ struct qtnf_vif *qtnf_mac_get_free_vif(struct qtnf_wmac *mac);
 struct qtnf_vif *qtnf_mac_get_base_vif(struct qtnf_wmac *mac);
 void qtnf_mac_iface_comb_free(struct qtnf_wmac *mac);
 void qtnf_mac_ext_caps_free(struct qtnf_wmac *mac);
+bool qtnf_mac_slave_radar_get(struct wiphy *wiphy);
 struct wiphy *qtnf_wiphy_allocate(struct qtnf_bus *bus);
 int qtnf_core_net_attach(struct qtnf_wmac *mac, struct qtnf_vif *priv,
 			 const char *name, unsigned char name_assign_type);
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
index 158c9eba20ef..8a3c6344fa8e 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
@@ -588,6 +588,7 @@ enum qlink_user_reg_hint_type {
  *	of &enum qlink_user_reg_hint_type.
  * @num_channels: number of &struct qlink_tlv_channel in a variable portion of a
  *	payload.
+ * @slave_radar: whether slave device should enable radar detection.
  * @dfs_region: one of &enum qlink_dfs_regions.
  * @info: variable portion of regulatory notifier callback.
  */
@@ -598,7 +599,8 @@ struct qlink_cmd_reg_notify {
 	u8 user_reg_hint_type;
 	u8 num_channels;
 	u8 dfs_region;
-	u8 rsvd[2];
+	u8 slave_radar;
+	u8 rsvd[1];
 	u8 info[0];
 } __packed;
 
-- 
2.11.0


^ permalink raw reply related
* [PATCH 3/3] qtnfmac: modify debugfs to support multiple cards
From: Sergey Matyukevich @ 2019-04-09  7:35 UTC (permalink / raw)
  To: linux-wireless@vger.kernel.org; +Cc: Igor Mitsyanko, Sergey Matyukevich
In-Reply-To: <20190409073500.16402-1-sergey.matyukevich.os@quantenna.com>

This patch modifies location of debugfs entries and their naming
conventions to support multiple wireless cards on pcie host.
Selected approach is to use separate directories for different
wireless cards in top-level qtnfmac debugfs directory.

Here is an example that clarifies the chosen naming conventions:

 $ sudo ls /sys/kernel/debug/qtnfmac/
   qtnfmac_pcie:0000:01:00.0

Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
---
 drivers/net/wireless/quantenna/qtnfmac/core.c  | 26 ++++++++++++++++++++++++++
 drivers/net/wireless/quantenna/qtnfmac/core.h  |  1 +
 drivers/net/wireless/quantenna/qtnfmac/debug.c |  4 +++-
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.c b/drivers/net/wireless/quantenna/qtnfmac/core.c
index ad0c9e012056..8d699cc03d26 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.c
@@ -20,6 +20,8 @@ static bool slave_radar = true;
 module_param(slave_radar, bool, 0644);
 MODULE_PARM_DESC(slave_radar, "set 0 to disable radar detection in slave mode");
 
+static struct dentry *qtnf_debugfs_dir;
+
 struct qtnf_frame_meta_info {
 	u8 magic_s;
 	u8 ifidx;
@@ -848,6 +850,30 @@ void qtnf_packet_send_hi_pri(struct sk_buff *skb)
 }
 EXPORT_SYMBOL_GPL(qtnf_packet_send_hi_pri);
 
+struct dentry *qtnf_get_debugfs_dir(void)
+{
+	return qtnf_debugfs_dir;
+}
+EXPORT_SYMBOL_GPL(qtnf_get_debugfs_dir);
+
+static int __init qtnf_core_register(void)
+{
+	qtnf_debugfs_dir = debugfs_create_dir(KBUILD_MODNAME, NULL);
+
+	if (IS_ERR(qtnf_debugfs_dir))
+		qtnf_debugfs_dir = NULL;
+
+	return 0;
+}
+
+static void __exit qtnf_core_exit(void)
+{
+	debugfs_remove(qtnf_debugfs_dir);
+}
+
+module_init(qtnf_core_register);
+module_exit(qtnf_core_exit);
+
 MODULE_AUTHOR("Quantenna Communications");
 MODULE_DESCRIPTION("Quantenna 802.11 wireless LAN FullMAC driver.");
 MODULE_LICENSE("GPL");
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h b/drivers/net/wireless/quantenna/qtnfmac/core.h
index d5caff45ac47..322858df600c 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -153,6 +153,7 @@ void qtnf_virtual_intf_cleanup(struct net_device *ndev);
 void qtnf_netdev_updown(struct net_device *ndev, bool up);
 void qtnf_scan_done(struct qtnf_wmac *mac, bool aborted);
 void qtnf_packet_send_hi_pri(struct sk_buff *skb);
+struct dentry *qtnf_get_debugfs_dir(void);
 
 static inline struct qtnf_vif *qtnf_netdev_get_priv(struct net_device *dev)
 {
diff --git a/drivers/net/wireless/quantenna/qtnfmac/debug.c b/drivers/net/wireless/quantenna/qtnfmac/debug.c
index 598ece753a4b..2d3574c1f10e 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/debug.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/debug.c
@@ -5,7 +5,9 @@
 
 void qtnf_debugfs_init(struct qtnf_bus *bus, const char *name)
 {
-	bus->dbg_dir = debugfs_create_dir(name, NULL);
+	struct dentry *parent = qtnf_get_debugfs_dir();
+
+	bus->dbg_dir = debugfs_create_dir(name, parent);
 }
 
 void qtnf_debugfs_remove(struct qtnf_bus *bus)
-- 
2.11.0


^ permalink raw reply related
* Re: [linux-sunxi] Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
From: Maxime Ripard @ 2019-04-09  7:45 UTC (permalink / raw)
  To: Chen-Yu Tsai, linux-sunxi, Rob Herring, Linus Walleij,
	David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
	Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
	Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
	linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	open list:GPIO SUBSYSTEM
In-Reply-To: <20190408121727.4vdqdokr6w5thck6@core.my.home>

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

On Mon, Apr 08, 2019 at 02:17:27PM +0200, Ondřej Jirman wrote:
> On Mon, Apr 08, 2019 at 10:47:14AM +0200, Maxime Ripard wrote:
> > On Mon, Apr 08, 2019 at 03:28:24PM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Apr 8, 2019 at 3:23 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > >
> > > > On Sat, Apr 06, 2019 at 01:45:04AM +0200, megous@megous.com wrote:
> > > > > From: Ondrej Jirman <megous@megous.com>
> > > > >
> > > > > Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected
> > > > > transistors, before it can be used. Model this as a power supply for DDC
> > > > > (via regulator framework).
> > > > >
> > > > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > >
> > > > The DDC bus itself is usually attached to the HDMI connector, so it
> > > > would make sense to make the supply also a property of the connector.
> > >
> > > I believe these are separate things. What this patch covers is power for
> > > a voltage shifter between the SoC and HDMI DDC pins. The HDMI connector's
> > > 5V supply to power the remote DDC chip is something else. And on the
> > > Orange Pi 3 they are indeed separate supplies.
> >
> > Then maybe the endpoint link between the two would be the best place
> > to put this?
>
> Interestingly &hdmi node configures the DDC bus pins via pinctrl on the SoC
> side, so I put this there too, because it's related to those pins. I'm not sure
> if that changes anything in the discussion.

It's kind of different though. The DDC controller is within the HDMI
controller, which is inside the SoC. Just like the pin muxer. As far
as the hardware goes, even on your board, you don't need that supply
so that the signal gets out of the SoC.

If the regulator is to power up some component on the path between the
SoC and the connector, then it should be attached there.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply
* Re: [PATCH v2 01/13] dt-bindings: sunxi: Add compatible for OrangePi 3 board
From: Maxime Ripard @ 2019-04-09  8:10 UTC (permalink / raw)
  To: megous
  Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
	David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
	Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
	Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
	linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	linux-gpio
In-Reply-To: <20190409002452.14551-2-megous@megous.com>

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

On Tue, Apr 09, 2019 at 02:24:40AM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> Add new Xunlong Orange Pi 3 board compatible string to the bindings
> documentation.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>

Applied, thanks!
Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply
* Re: linux-next: manual merge of the mac80211-next tree with the mac80211 tree
From: Stephen Rothwell @ 2019-04-09  8:11 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Wireless, Linux Next Mailing List, Linux Kernel Mailing List,
	Felix Fietkau, David Miller
In-Reply-To: <7deebb8e8c82e4455af8fc4963ffc7acca3aab36.camel@sipsolutions.net>

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

Hi Johannes,

On Tue, 09 Apr 2019 09:27:35 +0200 Johannes Berg <johannes@sipsolutions.net> wrote:
>
> But yes, I'm aware. It seemed simple enough though that I decided to
> keep it like that, I didn't really find a better solution.

Yeah, pretty trivial.  I assume both trees will meet in Dave's tree at some point.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply
* Re: [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
From: Maxime Ripard @ 2019-04-09  8:12 UTC (permalink / raw)
  To: megous
  Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
	David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
	Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
	Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
	linux-arm-kernel, linux-kernel, netdev, linux-stm32,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	linux-gpio
In-Reply-To: <20190409002452.14551-3-megous@megous.com>

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

Hi,

On Tue, Apr 09, 2019 at 02:24:41AM +0200, megous@megous.com wrote:
> +&mmc0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc0_pins>;

Since 5 minutes ago, that's now the default.

> +&usb2otg {
> +	/*
> +	 * Beware that this board will not automatically disconnect
> +	 * VBUS from DCIN, when self-powered and used as a peripheral.
> +	 */
> +	dr_mode = "otg";
> +	status = "okay";
> +};

As we were discussing, I guess leaving it as host is the safest
option.

I can fix both issues while applying if that's ok for you.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox