* [PATCH v3 02/11] net: stmmac: sun8i: force select external PHY when no internal one
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-1-megous@megous.com>
From: Icenowy Zheng <icenowy@aosc.io>
The PHY selection bit also exists on SoCs without an internal PHY; if it's
set to 1 (internal PHY, default value) then the MAC will not make use of
any PHY such SoCs.
This problem appears when adapting for H6, which has no real internal PHY
(the "internal PHY" on H6 is not on-die, but on a co-packaged AC200 chip,
connected via RMII interface at GPIO bank A).
Force the PHY selection bit to 0 when the SOC doesn't have an internal PHY,
to address the problem of a wrong default value.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 20c19afb8316..cb7e7f53be7d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -907,6 +907,11 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
* address. No need to mask it again.
*/
reg |= 1 << H3_EPHY_ADDR_SHIFT;
+ } else {
+ /* For SoCs without internal PHY the PHY selection bit should be
+ * set to 0 (external PHY).
+ */
+ reg &= ~H3_EPHY_SELECT;
}
if (!of_property_read_u32(node, "allwinner,tx-delay-ps", &val)) {
--
2.21.0
^ permalink raw reply related
* [PATCH v3 01/11] net: stmmac: sun8i: add support for Allwinner H6 EMAC
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-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 v3 03/11] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
H6 has a different I/O voltage bias setting method than A80. Prepare
existing code for using alternative bias voltage setting methods.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +-
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 47 +++++++++++++----------
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 9 ++++-
3 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
index da37d594a13d..0633a03d5e13 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
@@ -722,7 +722,7 @@ static const struct sunxi_pinctrl_desc sun9i_a80_pinctrl_data = {
.npins = ARRAY_SIZE(sun9i_a80_pins),
.irq_banks = 5,
.disable_strict_mode = true,
- .has_io_bias_cfg = true,
+ .io_bias_cfg_variant = BIAS_VOLTAGE_GRP_CONFIG,
};
static int sun9i_a80_pinctrl_probe(struct platform_device *pdev)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index be04223591d4..98c4de5f4019 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -617,7 +617,7 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
u32 val, reg;
int uV;
- if (!pctl->desc->has_io_bias_cfg)
+ if (!pctl->desc->io_bias_cfg_variant)
return 0;
uV = regulator_get_voltage(supply);
@@ -628,25 +628,32 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
if (uV == 0)
return 0;
- /* Configured value must be equal or greater to actual voltage */
- if (uV <= 1800000)
- val = 0x0; /* 1.8V */
- else if (uV <= 2500000)
- val = 0x6; /* 2.5V */
- else if (uV <= 2800000)
- val = 0x9; /* 2.8V */
- else if (uV <= 3000000)
- val = 0xA; /* 3.0V */
- else
- val = 0xD; /* 3.3V */
-
- pin -= pctl->desc->pin_base;
-
- reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
- reg &= ~IO_BIAS_MASK;
- writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
-
- return 0;
+ switch (pctl->desc->io_bias_cfg_variant) {
+ case BIAS_VOLTAGE_GRP_CONFIG:
+ /*
+ * Configured value must be equal or greater to actual
+ * voltage.
+ */
+ if (uV <= 1800000)
+ val = 0x0; /* 1.8V */
+ else if (uV <= 2500000)
+ val = 0x6; /* 2.5V */
+ else if (uV <= 2800000)
+ val = 0x9; /* 2.8V */
+ else if (uV <= 3000000)
+ val = 0xA; /* 3.0V */
+ else
+ val = 0xD; /* 3.3V */
+
+ pin -= pctl->desc->pin_base;
+
+ reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
+ reg &= ~IO_BIAS_MASK;
+ writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
+ return 0;
+ default:
+ return -EINVAL;
+ }
}
static int sunxi_pmx_get_funcs_cnt(struct pinctrl_dev *pctldev)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index ee15ab067b5f..4bfc8a6d9dce 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -95,6 +95,13 @@
#define PINCTRL_SUN7I_A20 BIT(7)
#define PINCTRL_SUN8I_R40 BIT(8)
+enum sunxi_desc_bias_voltage {
+ BIAS_VOLTAGE_NONE,
+ /* Bias voltage configuration is done through
+ * Pn_GRP_CONFIG registers, as seen on A80 SoC. */
+ BIAS_VOLTAGE_GRP_CONFIG,
+};
+
struct sunxi_desc_function {
unsigned long variant;
const char *name;
@@ -117,7 +124,7 @@ struct sunxi_pinctrl_desc {
const unsigned int *irq_bank_map;
bool irq_read_needs_mux;
bool disable_strict_mode;
- bool has_io_bias_cfg;
+ int io_bias_cfg_variant;
};
struct sunxi_pinctrl_function {
--
2.21.0
^ permalink raw reply related
* [PATCH v3 04/11] pinctrl: sunxi: Support I/O bias voltage setting on H6
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-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 | 11 +++++++++++
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 5 +++++
3 files changed, 17 insertions(+)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
index ef4268cc6227..3cc1121589c9 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 = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
};
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 98c4de5f4019..0cbca30b75dc 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -614,6 +614,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;
@@ -651,6 +653,15 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
reg &= ~IO_BIAS_MASK;
writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
return 0;
+ case BIAS_VOLTAGE_PIO_POW_MODE_SEL:
+ 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;
default:
return -EINVAL;
}
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index 4bfc8a6d9dce..36186906f0a7 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -95,11 +95,16 @@
#define PINCTRL_SUN7I_A20 BIT(7)
#define PINCTRL_SUN8I_R40 BIT(8)
+#define PIO_POW_MOD_SEL_REG 0x340
+
enum sunxi_desc_bias_voltage {
BIAS_VOLTAGE_NONE,
/* Bias voltage configuration is done through
* Pn_GRP_CONFIG registers, as seen on A80 SoC. */
BIAS_VOLTAGE_GRP_CONFIG,
+ /* Bias voltage is set through PIO_POW_MOD_SEL_REG
+ * register, as seen on H6 SoC, for example. */
+ BIAS_VOLTAGE_PIO_POW_MODE_SEL,
};
struct sunxi_desc_function {
--
2.21.0
^ permalink raw reply related
* [PATCH v3 07/11] drm: sun4i: Add support for enabling DDC I2C bus power to dw_hdmi glue
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected
transistors, before the bus can be used.
Model this as a power supply for DDC bus on the HDMI connector connected
to the output port (port 1) of the HDMI controller.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 60 ++++++++++++++++++++++++++-
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 39d8509d96a0..1b6ffba41177 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -98,6 +98,30 @@ static u32 sun8i_dw_hdmi_find_possible_crtcs(struct drm_device *drm,
return crtcs;
}
+static int sun8i_dw_hdmi_find_connector_pdev(struct device *dev,
+ struct platform_device **pdev_out)
+{
+ struct platform_device* pdev;
+ struct device_node *remote;
+
+ remote = of_graph_get_remote_node(dev->of_node, 1, -1);
+ if (!remote)
+ return -ENODEV;
+
+ if (!of_device_is_compatible(remote, "hdmi-connector")) {
+ of_node_put(remote);
+ return -ENODEV;
+ }
+
+ pdev = of_find_device_by_node(remote);
+ of_node_put(remote);
+ if (!pdev)
+ return -ENODEV;
+
+ *pdev_out = pdev;
+ return 0;
+}
+
static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
@@ -151,16 +175,34 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
return PTR_ERR(hdmi->regulator);
}
+ ret = sun8i_dw_hdmi_find_connector_pdev(dev, &hdmi->connector_pdev);
+ if (!ret) {
+ hdmi->ddc_regulator = regulator_get(&hdmi->connector_pdev->dev, "ddc");
+ if (IS_ERR(hdmi->ddc_regulator)) {
+ platform_device_put(hdmi->connector_pdev);
+ dev_err(dev, "Couldn't get ddc regulator\n");
+ return PTR_ERR(hdmi->ddc_regulator);
+ }
+ }
+
ret = regulator_enable(hdmi->regulator);
if (ret) {
dev_err(dev, "Failed to enable regulator\n");
- return ret;
+ goto err_unref_ddc_regulator;
+ }
+
+ if (hdmi->ddc_regulator) {
+ ret = regulator_enable(hdmi->ddc_regulator);
+ if (ret) {
+ dev_err(dev, "Failed to enable ddc regulator\n");
+ goto err_disable_regulator;
+ }
}
ret = reset_control_deassert(hdmi->rst_ctrl);
if (ret) {
dev_err(dev, "Could not deassert ctrl reset control\n");
- goto err_disable_regulator;
+ goto err_disable_ddc_regulator;
}
ret = clk_prepare_enable(hdmi->clk_tmds);
@@ -213,8 +255,15 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
clk_disable_unprepare(hdmi->clk_tmds);
err_assert_ctrl_reset:
reset_control_assert(hdmi->rst_ctrl);
+err_disable_ddc_regulator:
+ if (hdmi->ddc_regulator)
+ regulator_disable(hdmi->ddc_regulator);
err_disable_regulator:
regulator_disable(hdmi->regulator);
+err_unref_ddc_regulator:
+ if (hdmi->ddc_regulator)
+ regulator_put(hdmi->ddc_regulator);
+ platform_device_put(hdmi->connector_pdev);
return ret;
}
@@ -229,6 +278,13 @@ static void sun8i_dw_hdmi_unbind(struct device *dev, struct device *master,
clk_disable_unprepare(hdmi->clk_tmds);
reset_control_assert(hdmi->rst_ctrl);
regulator_disable(hdmi->regulator);
+
+ if (hdmi->ddc_regulator) {
+ regulator_disable(hdmi->ddc_regulator);
+ regulator_put(hdmi->ddc_regulator);
+ }
+
+ platform_device_put(hdmi->connector_pdev);
}
static const struct component_ops sun8i_dw_hdmi_ops = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 720c5aa8adc1..60f5200aee73 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -188,8 +188,10 @@ struct sun8i_dw_hdmi {
struct sun8i_hdmi_phy *phy;
struct dw_hdmi_plat_data plat_data;
struct regulator *regulator;
+ struct regulator *ddc_regulator;
const struct sun8i_dw_hdmi_quirks *quirks;
struct reset_control *rst_ctrl;
+ struct platform_device *connector_pdev;
};
static inline struct sun8i_dw_hdmi *
--
2.21.0
^ permalink raw reply related
* [PATCH v3 06/11] dt-bindings: display: hdmi-connector: Add DDC power supply
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
on-board voltage shifting logic for the DDC bus to be usable. Use
ddc-supply on the hdmi-connector to model this.
Add binding documentation for optional ddc-supply property.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../devicetree/bindings/display/connector/hdmi-connector.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
index 508aee461e0d..33085aeb0bb9 100644
--- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
+++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
@@ -9,6 +9,7 @@ Optional properties:
- label: a symbolic name for the connector
- hpd-gpios: HPD GPIO number
- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing
+- ddc-supply: the power supply for the DDC bus
Required nodes:
- Video port for HDMI input
--
2.21.0
^ permalink raw reply related
* [PATCH v3 05/11] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-1-megous@megous.com>
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 17d496990108..6d6b1f66796d 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 {
@@ -44,6 +45,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 */
+
+ /* The real parent of gmac-2v5 is reg_vcc5v, but we need to
+ * enable two regulators to power the phy. This is one way
+ * to achieve that.
+ */
+ vin-supply = <®_aldo2>; /* GMAC-3V3 */
+ };
};
&cpu0 {
@@ -58,6 +80,28 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ext_rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ phy-supply = <®_gmac_2v5>;
+ allwinner,rx-delay-ps = <1500>;
+ allwinner,tx-delay-ps = <700>;
+ status = "okay";
+};
+
+&mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+
+ reset-gpios = <&pio 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
+ reset-assert-us = <15000>;
+ reset-deassert-us = <40000>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_cldo1>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
--
2.21.0
^ permalink raw reply related
* [PATCH v3 08/11] arm64: dts: allwinner: orange-pi-3: Enable HDMI output
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 35 +++++++++++++++++++
1 file changed, 35 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 6d6b1f66796d..58a6635c909e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -22,6 +22,18 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+ ddc-supply = <®_ddc>;
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -37,6 +49,15 @@
};
};
+ reg_ddc: ddc-io {
+ compatible = "regulator-fixed";
+ regulator-name = "ddc-io";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ gpio = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
+ };
+
reg_vcc5v: vcc5v {
/* board wide 5V supply directly from the DC jack */
compatible = "regulator-fixed";
@@ -72,6 +93,10 @@
cpu-supply = <®_dcdca>;
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -91,6 +116,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mdio {
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.21.0
^ permalink raw reply related
* [PATCH v3 10/11] arm64: dts: allwinner: h6: Add MMC1 pins
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
MMC1 is used on some H6 boards we want to support. Typical use is 4-bit
SDIO interface with a WiFi chip. Add pin definitions for this use case.
As this is the only possible configration for mmc1, make it the default
one, too.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index e0dc4a05c1ba..bd37b849d3b7 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -243,6 +243,15 @@
bias-pull-up;
};
+ /omit-if-no-ref/
+ mmc1_pins: mmc1-pins {
+ pins = "PG0", "PG1", "PG2", "PG3",
+ "PG4", "PG5";
+ function = "mmc1";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
mmc2_pins: mmc2-pins {
pins = "PC1", "PC4", "PC5", "PC6",
"PC7", "PC8", "PC9", "PC10",
@@ -294,6 +303,8 @@
resets = <&ccu RST_BUS_MMC1>;
reset-names = "ahb";
interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
--
2.21.0
^ permalink raw reply related
* [PATCH v3 11/11] [DO NOT MERGE] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is called
bcm43356 and can be used with the brcmfmac driver. The module is powered by
the two always on regulators (not AXP805).
WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
configured so that it sets up an 1.8V input bias on this port. This is done
by the pio driver by reading the vcc-pg-supply voltage.
You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
configuration that can be found in the Xulongs's repository for H6:
https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
Mainline brcmfmac driver expects the firmware and nvram at the following
paths relative to the firmware directory:
brcm/brcmfmac43456-sdio.bin
brcm/brcmfmac43456-sdio.txt
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
1 file changed, 48 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 58a6635c909e..f795362f5b77 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -67,6 +67,26 @@
regulator-always-on;
};
+ reg_vcc33_wifi: vcc33-wifi {
+ /* Always on 3.3V regulator for WiFi and BT */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc33-wifi";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <®_vcc5v>;
+ };
+
+ reg_vcc_wifi_io: vcc-wifi-io {
+ /* Always on 1.8V/300mA regulator for WiFi and BT IO */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-wifi-io";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ vin-supply = <®_vcc33_wifi>;
+ };
+
/*
* The board uses 2.5V RGMII signalling. Power sequence to enable
* the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2) power rails
@@ -87,6 +107,14 @@
*/
vin-supply = <®_aldo2>; /* GMAC-3V3 */
};
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rtc 1>;
+ clock-names = "ext_clock";
+ reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
+ post-power-on-delay-ms = <200>;
+ };
};
&cpu0 {
@@ -144,6 +172,25 @@
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_vcc33_wifi>;
+ vqmmc-supply = <®_vcc_wifi_io>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ brcm: sdio-wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&r_pio>;
+ interrupts = <1 0 IRQ_TYPE_LEVEL_LOW>; /* PM0 */
+ interrupt-names = "host-wake";
+ };
+};
+
&ohci0 {
status = "okay";
};
@@ -155,6 +202,7 @@
&pio {
vcc-pc-supply = <®_bldo2>;
vcc-pd-supply = <®_cldo1>;
+ vcc-pg-supply = <®_vcc_wifi_io>;
};
&r_i2c {
--
2.21.0
^ permalink raw reply related
* [PATCH v3 09/11] brcmfmac: Loading the correct firmware for brcm43456
From: megous @ 2019-04-11 10:19 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: <20190411101951.30223-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
SDIO based brcm43456 is currently misdetected as brcm43455 and the wrong
firmware name is used. Correct the detection and load the correct firmware
file. Chiprev for brcm43456 is "9".
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a06af0cd4a7f..22b73da42822 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -622,6 +622,7 @@ BRCMF_FW_DEF(43430A0, "brcmfmac43430a0-sdio");
/* Note the names are not postfixed with a1 for backward compatibility */
BRCMF_FW_DEF(43430A1, "brcmfmac43430-sdio");
BRCMF_FW_DEF(43455, "brcmfmac43455-sdio");
+BRCMF_FW_DEF(43456, "brcmfmac43456-sdio");
BRCMF_FW_DEF(4354, "brcmfmac4354-sdio");
BRCMF_FW_DEF(4356, "brcmfmac4356-sdio");
BRCMF_FW_DEF(4373, "brcmfmac4373-sdio");
@@ -642,7 +643,8 @@ static const struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_4339_CHIP_ID, 0xFFFFFFFF, 4339),
BRCMF_FW_ENTRY(BRCM_CC_43430_CHIP_ID, 0x00000001, 43430A0),
BRCMF_FW_ENTRY(BRCM_CC_43430_CHIP_ID, 0xFFFFFFFE, 43430A1),
- BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFFFFFC0, 43455),
+ BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0x00000200, 43456),
+ BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFFFFDC0, 43455),
BRCMF_FW_ENTRY(BRCM_CC_4354_CHIP_ID, 0xFFFFFFFF, 4354),
BRCMF_FW_ENTRY(BRCM_CC_4356_CHIP_ID, 0xFFFFFFFF, 4356),
BRCMF_FW_ENTRY(CY_CC_4373_CHIP_ID, 0xFFFFFFFF, 4373),
--
2.21.0
^ permalink raw reply related
* [PATCH v3 00/11] Add support for Orange Pi 3
From: megous @ 2019-04-11 10:19 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.
Suggested merging plan/dependencies:
- Pinctrl and stmmac patches are needed for ethernet support.
(patches 1-5)
- HDMI support was changed, please review. (patches 6-8)
- brcmfmac patch 9, fixing firmware file selection, can be merged
now, after review, as it doesn't depend on anything (please
review :))
- mmc1 pinconf (patch 10) can probably be merged now, too (it will
certainly be used soon by all the other WiFi featuring boards
based on H6)
- WiFi dts patch 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 it in the series for completness.
(patch 11)
This patch is also needed to not get segfault on boot (it was already
merged):
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
Changes in v3:
- dropped already applied patches
- changed pinctrl I/O bias selection constants to enum and renamed
- added /omit-if-no-ref/ to mmc1_pins
- made mmc1_pins default pinconf for mmc1 in H6 dtsi
- move ddc-supply to HDMI connector node, updated patch descriptions,
changed dt-bindings docs
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 (9):
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
dt-bindings: display: hdmi-connector: Add DDC power supply
drm: sun4i: Add support for enabling DDC I2C bus power to dw_hdmi glue
arm64: dts: allwinner: orange-pi-3: Enable HDMI output
brcmfmac: Loading the correct firmware for brcm43456
arm64: dts: allwinner: h6: Add MMC1 pins
[DO NOT MERGE] arm64: dts: allwinner: orange-pi-3: Enable WiFi
.../display/connector/hdmi-connector.txt | 1 +
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 127 ++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 11 ++
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 60 ++++++++-
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +
.../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 | 56 +++++---
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 14 +-
11 files changed, 275 insertions(+), 24 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH] cfg80211: don't pass pointer to pointer unnecessarily
From: Dan Carpenter @ 2019-04-11 8:59 UTC (permalink / raw)
To: Johannes Berg, Sara Sharon; +Cc: linux-wireless, Luca Coelho, kernel-janitors
The cfg80211_merge_profile() and ieee802_11_find_bssid_profile() are
a bit cleaner if we just pass the merged_ie pointer instead of a pointer
to the pointer.
This isn't a functional change, it's just a clean up.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
include/net/cfg80211.h | 2 +-
net/mac80211/util.c | 8 ++++----
net/wireless/scan.c | 8 ++++----
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index e42604533c99..7c01a5fe2300 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -5556,7 +5556,7 @@ bool cfg80211_is_element_inherited(const struct element *element,
size_t cfg80211_merge_profile(const u8 *ie, size_t ielen,
const struct element *mbssid_elem,
const struct element *sub_elem,
- u8 **merged_ie, size_t max_copy_len);
+ u8 *merged_ie, size_t max_copy_len);
/**
* enum cfg80211_bss_frame_type - frame type that the BSS data came from
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index da93f6898bb6..d63b6f4937fb 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1258,7 +1258,7 @@ static size_t ieee802_11_find_bssid_profile(const u8 *start, size_t len,
struct ieee802_11_elems *elems,
u8 *transmitter_bssid,
u8 *bss_bssid,
- u8 **nontransmitted_profile)
+ u8 *nontransmitted_profile)
{
const struct element *elem, *sub;
size_t profile_len = 0;
@@ -1290,7 +1290,7 @@ static size_t ieee802_11_find_bssid_profile(const u8 *start, size_t len,
continue;
}
- memset(*nontransmitted_profile, 0, len);
+ memset(nontransmitted_profile, 0, len);
profile_len = cfg80211_merge_profile(start, len,
elem,
sub,
@@ -1299,7 +1299,7 @@ static size_t ieee802_11_find_bssid_profile(const u8 *start, size_t len,
/* found a Nontransmitted BSSID Profile */
index = cfg80211_find_ie(WLAN_EID_MULTI_BSSID_IDX,
- *nontransmitted_profile,
+ nontransmitted_profile,
profile_len);
if (!index || index[1] < 1 || index[2] == 0) {
/* Invalid MBSSID Index element */
@@ -1341,7 +1341,7 @@ u32 ieee802_11_parse_elems_crc(const u8 *start, size_t len, bool action,
ieee802_11_find_bssid_profile(start, len, elems,
transmitter_bssid,
bss_bssid,
- &nontransmitted_profile);
+ nontransmitted_profile);
non_inherit =
cfg80211_find_ext_elem(WLAN_EID_EXT_NON_INHERITANCE,
nontransmitted_profile,
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 6956eb4bf917..c04f5451f89b 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -1501,7 +1501,7 @@ static const struct element
size_t cfg80211_merge_profile(const u8 *ie, size_t ielen,
const struct element *mbssid_elem,
const struct element *sub_elem,
- u8 **merged_ie, size_t max_copy_len)
+ u8 *merged_ie, size_t max_copy_len)
{
size_t copied_len = sub_elem->datalen;
const struct element *next_mbssid;
@@ -1509,7 +1509,7 @@ size_t cfg80211_merge_profile(const u8 *ie, size_t ielen,
if (sub_elem->datalen > max_copy_len)
return 0;
- memcpy(*merged_ie, sub_elem->data, sub_elem->datalen);
+ memcpy(merged_ie, sub_elem->data, sub_elem->datalen);
while ((next_mbssid = cfg80211_get_profile_continuation(ie, ielen,
mbssid_elem,
@@ -1518,7 +1518,7 @@ size_t cfg80211_merge_profile(const u8 *ie, size_t ielen,
if (copied_len + next_sub->datalen > max_copy_len)
break;
- memcpy(*merged_ie + copied_len, next_sub->data,
+ memcpy(merged_ie + copied_len, next_sub->data,
next_sub->datalen);
copied_len += next_sub->datalen;
}
@@ -1587,7 +1587,7 @@ static void cfg80211_parse_mbssid_data(struct wiphy *wiphy,
profile_len = cfg80211_merge_profile(ie, ielen,
elem,
sub,
- &profile,
+ profile,
ielen);
/* found a Nontransmitted BSSID Profile */
--
2.17.1
^ permalink raw reply related
* [PATCH V2] staging: wilc1000: give usleep_range a range
From: Nicholas Mc Guire @ 2019-04-11 3:31 UTC (permalink / raw)
To: Adham Abozaeid
Cc: Ajay Singh, Greg Kroah-Hartman, linux-wireless, devel,
linux-kernel, Nicholas Mc Guire
From: Nicholas Mc Guire <hofrat@osadl.org>
usleep_range() is called in non-atomic context so there is little point
in setting min==max as the jitter of hrtimer is determined by interruptions
anyway. usleep_range can only perform the intended coalescence if some
room for placing the hrtimer is provided. Given the range of milliseconds
the delay will be 2+ anyway - so make it 2-2.5 ms which gives hrtimers
space to optimize without negatively impacting performance.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---
Problem located with an experimental coccinelle script
./drivers/staging/wilc1000/wilc_wlan.c:411:4-16: WARNING: inefficient usleep_range with range 0 (min==max)
./drivers/staging/wilc1000/wilc_wlan.c:426:4-16: WARNING: inefficient usleep_range with range 0 (min==max)
V2: Based on feedback from Adham Abozaeid <Adham.Abozaeid@microchip.com> that
since this is in the transmit path 5ms could impact throughput but adding
500 microseconds should be tolerable.
Patch was compile tested with: x86_64_defconfig + Staging=y,
WILC1000_SDIO=m, WILC1000_SPI=m, WILC1000=m
Patch is against 5.1-rc4 (localversion-next is -next-20190410)
drivers/staging/wilc1000/wilc_wlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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(2000, 2500);
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(2000, 2500);
wilc->hif_func->hif_read_reg(wilc, 0xf1,
&clk_status_reg);
--
2.1.4
^ permalink raw reply related
* Re: [RFC/RFT] mac80211: Switch to a virtual time-based airtime scheduler
From: Yibo Zhao @ 2019-04-11 3:12 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: make-wifi-fast, linux-wireless, Felix Fietkau, Rajkumar Manoharan,
Kan Yan, linux-wireless-owner
In-Reply-To: <87a7gyw3cu.fsf@toke.dk>
On 2019-04-10 18:40, Toke Høiland-Jørgensen wrote:
> Yibo Zhao <yiboz@codeaurora.org> writes:
>
>> On 2019-04-10 04:41, Toke Høiland-Jørgensen wrote:
>>> Yibo Zhao <yiboz@codeaurora.org> writes:
>>>
>>>> On 2019-04-04 16:31, Toke Høiland-Jørgensen wrote:
>>>>> Yibo Zhao <yiboz@codeaurora.org> writes:
>>>>>
>>>>>> On 2019-02-16 01:05, Toke Høiland-Jørgensen wrote:
>>>>>>> This switches the airtime scheduler in mac80211 to use a virtual
>>>>>>> time-based
>>>>>>> scheduler instead of the round-robin scheduler used before. This
>>>>>>> has
>>>>>>> a
>>>>>>> couple of advantages:
>>>>>>>
>>>>>>> - No need to sync up the round-robin scheduler in
>>>>>>> firmware/hardware
>>>>>>> with
>>>>>>> the round-robin airtime scheduler.
>>>>>>>
>>>>>>> - If several stations are eligible for transmission we can
>>>>>>> schedule
>>>>>>> both of
>>>>>>> them; no need to hard-block the scheduling rotation until the
>>>>>>> head
>>>>>>> of
>>>>>>> the
>>>>>>> queue has used up its quantum.
>>>>>>>
>>>>>>> - The check of whether a station is eligible for transmission
>>>>>>> becomes
>>>>>>> simpler (in ieee80211_txq_may_transmit()).
>>>>>>>
>>>>>>> The drawback is that scheduling becomes slightly more expensive,
>>>>>>> as
>>>>>>> we
>>>>>>> need
>>>>>>> to maintain an rbtree of TXQs sorted by virtual time. This means
>>>>>>> that
>>>>>>> ieee80211_register_airtime() becomes O(logN) in the number of
>>>>>>> currently
>>>>>>> scheduled TXQs. However, hopefully this number rarely grows too
>>>>>>> big
>>>>>>> (it's
>>>>>>> only TXQs currently backlogged, not all associated stations), so
>>>>>>> it
>>>>>>> shouldn't be too big of an issue.
>>>>>>>
>>>>>>> @@ -1831,18 +1830,32 @@ void
>>>>>>> ieee80211_sta_register_airtime(struct
>>>>>>> ieee80211_sta *pubsta, u8 tid,
>>>>>>> {
>>>>>>> struct sta_info *sta = container_of(pubsta, struct sta_info,
>>>>>>> sta);
>>>>>>> struct ieee80211_local *local = sta->sdata->local;
>>>>>>> + struct ieee80211_txq *txq = sta->sta.txq[tid];
>>>>>>> u8 ac = ieee80211_ac_from_tid(tid);
>>>>>>> - u32 airtime = 0;
>>>>>>> + u64 airtime = 0, weight_sum;
>>>>>>> +
>>>>>>> + if (!txq)
>>>>>>> + return;
>>>>>>>
>>>>>>> if (sta->local->airtime_flags & AIRTIME_USE_TX)
>>>>>>> airtime += tx_airtime;
>>>>>>> if (sta->local->airtime_flags & AIRTIME_USE_RX)
>>>>>>> airtime += rx_airtime;
>>>>>>>
>>>>>>> + /* Weights scale so the unit weight is 256 */
>>>>>>> + airtime <<= 8;
>>>>>>> +
>>>>>>> spin_lock_bh(&local->active_txq_lock[ac]);
>>>>>>> +
>>>>>>> sta->airtime[ac].tx_airtime += tx_airtime;
>>>>>>> sta->airtime[ac].rx_airtime += rx_airtime;
>>>>>>> - sta->airtime[ac].deficit -= airtime;
>>>>>>> +
>>>>>>> + weight_sum = local->airtime_weight_sum[ac] ?:
>>>>>>> sta->airtime_weight;
>>>>>>> +
>>>>>>> + local->airtime_v_t[ac] += airtime / weight_sum;
>>>>>> Hi Toke,
>>>>>>
>>>>>> Please ignore the previous two broken emails regarding this new
>>>>>> proposal
>>>>>> from me.
>>>>>>
>>>>>> It looks like local->airtime_v_t acts like a Tx criteria. Only the
>>>>>> stations with less airtime than that are valid for Tx. That means
>>>>>> there
>>>>>> are situations, like 50 clients, that some of the stations can be
>>>>>> used
>>>>>> to Tx when putting next_txq in the loop. Am I right?
>>>>>
>>>>> I'm not sure what you mean here. Are you referring to the case
>>>>> where
>>>>> new
>>>>> stations appear with a very low (zero) airtime_v_t? That is handled
>>>>> when
>>>>> the station is enqueued.
>>>> Hi Toke,
>>>>
>>>> Sorry for the confusion. I am not referring to the case that you
>>>> mentioned though it can be solved by your subtle design, max(local
>>>> vt,
>>>> sta vt). :-)
>>>>
>>>> Actually, my concern is situation about putting next_txq in the
>>>> loop.
>>>> Let me explain a little more and see below.
>>>>
>>>>> @@ -3640,126 +3638,191 @@ EXPORT_SYMBOL(ieee80211_tx_dequeue);
>>>>> struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw,
>>>>> u8
>>>>> ac)
>>>>> {
>>>>> struct ieee80211_local *local = hw_to_local(hw);
>>>>> + struct rb_node *node = local->schedule_pos[ac];
>>>>> struct txq_info *txqi = NULL;
>>>>> + bool first = false;
>>>>>
>>>>> lockdep_assert_held(&local->active_txq_lock[ac]);
>>>>>
>>>>> - begin:
>>>>> - txqi = list_first_entry_or_null(&local->active_txqs[ac],
>>>>> - struct txq_info,
>>>>> - schedule_order);
>>>>> - if (!txqi)
>>>>> + if (!node) {
>>>>> + node = rb_first_cached(&local->active_txqs[ac]);
>>>>> + first = true;
>>>>> + } else
>>>>> + node = rb_next(node);
>>>>
>>>> Consider below piece of code from ath10k_mac_schedule_txq:
>>>>
>>>> ieee80211_txq_schedule_start(hw, ac);
>>>> while ((txq = ieee80211_next_txq(hw, ac))) {
>>>> while (ath10k_mac_tx_can_push(hw, txq)) {
>>>> ret = ath10k_mac_tx_push_txq(hw, txq);
>>>> if (ret < 0)
>>>> break;
>>>> }
>>>> ieee80211_return_txq(hw, txq);
>>>> ath10k_htt_tx_txq_update(hw, txq);
>>>> if (ret == -EBUSY)
>>>> break;
>>>> }
>>>> ieee80211_txq_schedule_end(hw, ac);
>>>>
>>>> If my understanding is right, local->schedule_pos is used to record
>>>> the
>>>> last scheduled node and used for traversal rbtree for valid txq.
>>>> There
>>>> is chance that an empty txq is feeded to return_txq and got removed
>>>> from
>>>> rbtree. The empty txq will always be the rb_first node. Then in the
>>>> following next_txq, local->schedule_pos becomes meaningless since
>>>> its
>>>> rb_next will return NULL and the loop break. Only rb_first get
>>>> dequeued
>>>> during this loop.
>>>>
>>>> if (!node || RB_EMPTY_NODE(node)) {
>>>> node = rb_first_cached(&local->active_txqs[ac]);
>>>> first = true;
>>>> } else
>>>> node = rb_next(node);
>>>
>>> Ah, I see what you mean. Yes, that would indeed be a problem - nice
>>> catch! :)
>>>
>>>> How about this? The nodes on the rbtree will be dequeued and removed
>>>> from rbtree one by one until HW is busy. Please note local vt and
>>>> sta
>>>> vt will not be updated since txq lock is held during this time.
>>>
>>> Insertion and removal from the rbtree are relatively expensive, so
>>> I'd
>>> rather not do that for every txq. I think a better way to solve this
>>> is to just defer the actual removal from the tree until
>>> ieee80211_txq_schedule_end()... Will fix that when I submit this
>>> again.
>>
>> Do you mean we keep the empty txqs in the rbtree until loop finishes
>> and
>> remove them in ieee80211_txq_schedule_end(may be put return_txq in
>> it)?
>> If it is the case, I suppose a list is needed to store the empty txqs
>> so
>> as to dequeue them in ieee80211_txq_schedule_end.
>
> Yeah, return_txq() would just put "to be removed" TXQs on a list, and
> schedule_end() would do the actual removal (after checking whether a
> new
> packet showed up in the meantime).
SGTM
>
>> And one more thing,
>>
>>> + if (sta->airtime[ac].v_t > local->airtime_v_t[ac]) {
>>> + if (first)
>>> + local->airtime_v_t[ac] =
>>> sta->airtime[ac].v_t;
>>> + else
>>> + return NULL;
>>
>> As local->airtime_v_t will not be updated during loop, we don't need
>> to
>> return NULL.
>
> Yes we do; this is actually the break condition. I.e., stations whose
> virtual time are higher than the global time (in local->airtime_v_t)
> are
> not allowed to transmit. And since we are traversing them in order,
> when
> we find the first such station, we are done and can break out of the
> scheduling loop entirely (which is what we do by returning NULL). The
> other branch in the inner if() is just for the case where no stations
> are currently eligible to transmit according to this rule; here we
> don't
> want to stall, so we advance the global timer so the first station
> becomes eligible...
Yes，the inner if() make sure first node always get scheduled no matter
its vt.
To detail my concern, let's assume only two nodes in the tree and empty
nodes will be in tree until schedule_end(). In the loop and in case hw
is not busy, ath10k will drain every node next_txq returned before
asking for another txq again. Then as we are traversing to next rb node,
it is highly possible the second node is not allowed to transmit since
the global time has not been updated yet as the active txq lock is held.
At this time, only second node on the tree has data and hw is capable of
sending more data. I don't think the second node is not valid for
transmission in this situation.
With more nodes in the tree in this situation, I think same thing
happens that all nodes except the first node are not allowed to transmit
since none of their vts are less than the global time which is not
updated in time. The loop breaks when we are checking the second node.
>
> -Toke
--
Yibo
^ permalink raw reply
* Re: [PATCH RFC] staging: wilc1000: give usleep_range a range
From: Nicholas Mc Guire @ 2019-04-11 2:44 UTC (permalink / raw)
To: Adham.Abozaeid
Cc: hofrat, Ajay.Kathat, gregkh, linux-wireless, devel, linux-kernel
In-Reply-To: <0360e5c6-28c8-db9e-1e8d-80445fe433c0@microchip.com>
On Wed, Apr 10, 2019 at 06:31:21PM +0000, Adham.Abozaeid@microchip.com wrote:
> Hi Nicolas
>
> On 4/8/19 6:36 PM, Nicholas Mc Guire wrote:
> > 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.
>
> yes, I believe 2.5 shouldn't be a problem.
>
thanks - will send out a V2 then shortly.
thx!
hofrat
^ permalink raw reply
* Re: [PATCH v3 0/3] wireless: Add support to probe unexercised mesh link
From: Rajkumar Manoharan @ 2019-04-11 0:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1ed09282bb0efb801a29d40eca7a09af077ad1d3.camel@sipsolutions.net>
On 2019-04-09 05:02, Johannes Berg wrote:
> On Wed, 2019-04-03 at 12:14 -0700, Rajkumar Manoharan wrote:
>> Consider below mesh topology.
>>
>> MP1
>> / \
>> / \
>> MP2 --- MP3
>>
>> Assume that even though MP1 & MP3 have direct mesh links, the path was
>> established via MP2. (MP1 <-> MP2 <-> MP3). The 1-hop mesh link MP1
>> <-> MP3
>> never be excercised till the current path is terminated. As of now,
>> there
>> is no option to send data frame to pick other than primary path. So
>> mesh
>> link metric between MP1 & MP3 never be updated. This series allows
>> user
>> to send data to 1-hop mesh peers through unexercised mesh path.
>>
>> -Rajkumar
>>
>> v3: Rebased the changes on TOT
>
> Hmm. Please rebase again, and retest, because I just applied this and
> it
> doesn't even compile ...
>
Sure.. will send next version on top of mac80211-next.
-Rajkumar
^ permalink raw reply
* Re: gsmtap design/extensions?
From: Harald Welte @ 2019-04-10 23:32 UTC (permalink / raw)
To: Johannes Berg
Cc: openbsc, radiotap, linux-wireless, Subash Abhinov Kasiviswanathan,
Dan Williams, Bjørn Mork, netdev, Sean Tranchetti,
Aleksander Morgado
In-Reply-To: <cf07ae24c436f92769f9289d208f01846ebe8826.camel@sipsolutions.net>
Hi Johannes,
On Tue, Apr 09, 2019 at 03:50:45PM +0200, Johannes Berg wrote:
> As I'm looking into adding a generic cell modem framework to the linux
> kernel (to create session netdevs etc.), I started looking for a
> metadata encapsulation, a la Radiotap (I'm a wifi guy :-) ).
Is there any discussion about "session netdevs, etc." anywhere? What exactly
do you have in mind for that "generic cell modem framework"? I'm quite
curious to learn more about it and happy to provide feedback from the
perspective of my cellular protocols/specs/systems knowledge.
> So obviously, I found gsmtap, but for my use case it doesn't really
> address most of the interesting data,
I have no knowledge of your use case, so I don't feel like I can
comment on that :/
> 1) Why the design with encapsulating it in UDP? Radiotap is just a raw
> header without IP etc. in front, and you use it with tcpdump,
> wireshark or similar tools on the local system. What's the value in
> having something "network transparent"?
GSMTAP was designed as a format to encapsulate protocols normally not spoken over IP
(such as classic GSM radio protocols, e.g. the Layer 2 LAPDm over GSM Um)
inside an IP transport.
The existing implementations of such protocols all live outside of the
kernel but in userspace. So you either have
a) a pure SDR software implementation of a GSM phy, whether on the MS/UE
side or on the BTS/network side, or whether in sniffing mode, running
as a userspace process. This could e.g. be airprobe or gr-gsm
b) a OsmocomBB phone attached over serial port running the Osmocom Layer1
firmware on the baseband processor, with some userspace program on a Linux
PC implementing higher layers
c) GSM base station software such as osmo-bts, running in userspace
d) Using an old nokia phone attached via serial cable to a Linux PC running
dct3-gsmtap.
So for any of those, if you want to provide real-time data streams, you have to
somehow transmit those over some kind of network technology. One could have
done raw ethernet frames or raw IP frames, but using UDP seemed straight-forward
as one can create UDP socket from non-privileged processes.
We also have a virtual physical layer between OsmocomBB and OsmoBTS called
virt_phy where the GSMTAP over multicast IP is used to simulate/virtualize
the entire Layer1 / PHY / radio interface between phone and base station.
Once again, all related network elements are implemented in userspace,
and having an
> 2) The format of gsmtap doesn't seem very extensible, but I guess a new
> version could be made that has a TLV-based format or so. I'd have
> argued that a new version isn't even needed, but the length field is
> only 8 bits right now which seems too short.
Yes, it's a known problem. The format was originally designed for GSM,
that is circuit switched common and dedicated channels on the GSM Um interface.
It was later extended for GPRS, TETRA, SIM card protocol traces and many others,
but all of that was an afterthought.
For sure any future version should be more extensible and e.g. use TLVs
> (speaking of versions - the docs say "version, set to 0x01 currently"
> but "#define GSMTAP_VERSION 0x02")
Sorry, it's the usual "developer changes code but not comment". patches
are welcome, we use gerrit.osmocom.org :)
> 3) Does the packet data follow the gsmtap header? It's not really clear
> to me based on reading the wireshark code.
Sure, the packet data follows the GSMTAP header, and the type of data
is defined by the GSMTAP type / sub-type as per the specific use case. As
you can see, there's 18 TYPE by now (each of which has at least one
program/implementation generating the data).
I think the best way to learn about GSMTAP is to use any of the many
programs that support it by now. I think not only the examples above
use it, but meanwhile many others like the independently-developed OpenBTS
project that's unrelated to Osmocom, as are other projects implementing LTE.
> In particular, the data I'm thinking of is higher-level things, like the
> session ID for a frame when it's going through the kernel, or perhaps a
> flow label on RX, etc.
I'm not quite sure how that relates to GSM? GSMTAP so far was intended
to encapsulate ETSI/3GPP messages inside UDP/IP, particularly messages of
protocols that don't traditionally are transported over IP baesd transports.
Having said, we're open to extending the scope - it just all needs to make
sense
> Also, vendor-specific data would be useful, e.g. to encapsulate the
> device-specific headers like QMI, where such metadata is encapsulated in
> a vendor- or device-specific way, which you'd want to see for debugging
> certain things, but for other things the generic "session ID" type
> information - encoded in a vendor-agnostic way - would be better to show
> in wireshark.
I'm really not following you here. What's a "session ID"?
In terms of vendor-specific encapsulations: We do have a GSMTAP sub-type
for Qualcomm DIAG, as well as the osmo-qcdiag program to take DIAG from
Qualcomm chips + put it in GSMTAP and I do have plenty of experimental
wireshark dissectors for various parts of the DIAG protocl in a branch
on git.osmocom.org. This just never went anywhere complete enough that
I'd consider merging it.
> Since it doesn't seem possible to use gsmtap in the current version,
> would it make sense to define a new gsmtap that (say) has version 3 or
> something, followed by an overall length and TLVs?
By all means. Vadim has once presented some ideas/plans about exactly
that at an Osmocom conference, but I don't think any related work
ever started.
> I do note that this
> wouldn't be compatible with the current wireshark code as it doesn't
> check the version, just shows it...
If that's the case that's sad, and I should have paid more attention to
it when originally writing it. We should get a related fix into
wireshark ASAP then. But then, the current dissector would just state
something like unsupported version instead of showing some garbage it
cannot parse. Either way, you will of course need new sources and
sink side implemetations.
> Or would it make more sense to define a new ARPHDR_WWANTAP like
> ARPHDR_IEEE80211_RADIOTAP and just use that instead of encapsulating in
> IP/UDP, and then have a completely new (extensible) protocol inside of
> that?
No userspace source would ever be able to generate such data and stream
it real-time into wireshark, would it? Sure, I can write pcap file with
such ARPHDR_* values, but I could never do this in real-time. For many
but not all use cases, that's really what it is: A vehicle to stream
real-time non-IP protocol traces into wireshark so it can visualize
the protocol traces.
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* Re: gsmtap design/extensions?
From: Harald Welte @ 2019-04-10 23:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Vadim Yanitskiy, OpenBSC Mailing List, Sean Tranchetti, radiotap,
Dan Williams, netdev, linux-wireless, Aleksander Morgado,
Subash Abhinov Kasiviswanathan, Bjørn Mork
In-Reply-To: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net>
Hi Johannes,
On Wed, Apr 10, 2019 at 09:23:13AM +0200, Johannes Berg wrote:
> > but unfortunately, nobody has invested time into this (yet?).
>
> 2012!
Well, Osmocom is a very small community, with probably somewhere less than
25 active developers over the last few years (less than 15 full-time),
with an *incredibly* large scope: Implement virtually any protocol
layer of any protocol stack on any of the 3GPP interfaces and all their
related network elements for 2G/3G as well as even other technologies
like TETRA, GMR-1, ...
And all that in a field of technology that has less free software than
the Operating Systems world had in the mid-1990ies. It really feels a
bit like the Linux community 20 years ago.
So resources are always *extremely* tight, and given those limited
resources, I'm actually very happy with the results by now, having
automatied CI, build verifications, unit tests, functional test suites,
end-to-end testing, and all the code we implemented on git.osmocom.org :)
While current GSMTAPv2 is ugly, it works rather solid for all known
existing use cases, so there was no urgency to introduce a new version
of it.
> Not sure I get this, but I also don't really care all that much.
Well, with all respect, GSMTAP was created for a variety of use cases,
see my other lengthy mail. It's fine if you don't care, but unless you
could explain your use cases with a few paragraphs, neither you nor us
are able to determine if there is common functionality and if it makes
sense to use GSMTAP or not :)
So far I have not seen any explanation about what kind of data you want
to encapsulate at all.
> just a pretty strange design if the kernel were to output this, I'm not
> even sure how I'd do that properly. I don't want to be generating UDP
> packets there...
There are well-established APIs for having sockets in the kernel and for
generating + receiving UDP packets from it. NFS has been doing this for
decades, as do various kernel-side tunneling helpers including the GTP
kernel module.
I'm not saying it's the right approach for your problem, I'm just saying
kernel-side code can for sure use UDP sockets.
> Perhaps we can define something (GSMTAPv3) to not really care how it's
> encapsulated, and for 'native' packet captures like what I want on Linux
> when integrated with the driver, actually use an ARPHDR_GSMTAP, and
> encapsulate in UDP when you create it in an application and want to send
> it elsewhere, rather than just writing it to a pcap file?
Sure, that works. But the real question is, to me: Are there common
GSMTAP payload types that both the existing GSMTAP users carry, as well
as what you would want to carry? If yes, then it makes sense to think
about a common encapsulation like GSMTAP. If the payload types differ,
then it seems rather like there are two distinct use cases that
wouldn't benefit from standardizing on one format.
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* [PATCH] mmc: dw_mmc: Disable SDIO interrupts while suspended to fix suspend/resume
From: Douglas Anderson @ 2019-04-10 22:12 UTC (permalink / raw)
To: Jaehoon Chung, Ulf Hansson, Shawn Lin
Cc: Kalle Valo, heiko, linux-rockchip, briannorris, linux-wireless,
mka, ryandcase, Douglas Anderson, stable, linux-mmc, linux-kernel
Processing SDIO interrupts while dw_mmc is suspended (or partly
suspended) seems like a bad idea. We really don't want to be
processing them until we've gotten ourselves fully powered up.
You might be wondering how it's even possible to become suspended when
an SDIO interrupt is active. As can be seen in
dw_mci_enable_sdio_irq(), we explicitly keep dw_mmc out of runtime
suspend when the SDIO interrupt is enabled. ...but even though we
stop normal runtime suspend transitions when SDIO interrupts are
enabled, the dw_mci_runtime_suspend() can still get called for a full
system suspend.
Let's handle all this by explicitly masking SDIO interrupts in the
suspend call and unmasking them later in the resume call. To do this
cleanly I'll keep track of whether the client requested that SDIO
interrupts be enabled so that we can reliably restore them regardless
of whether we're masking them for one reason or another.
Without this fix it can be seen that rk3288-veyron Chromebooks with
Marvell WiFi would sometimes fail to resume WiFi even after picking my
recent mwifiex patch [1]. Specifically you'd see messages like this:
mwifiex_sdio mmc1:0001:1: Firmware wakeup failed
mwifiex_sdio mmc1:0001:1: PREP_CMD: FW in reset state
...and tracing through the resume code in the failing cases showed
that we were processing a SDIO interrupt really early in the resume
call.
NOTE: downstream in Chrome OS 3.14 and 3.18 kernels (both of which
support the Marvell SDIO WiFi card) we had a patch ("CHROMIUM: sdio:
Defer SDIO interrupt handling until after resume") [2]. Presumably
this is the same problem that was solved by that patch.
[1] https://lkml.kernel.org/r/20190404040106.40519-1-dianders@chromium.org
[2] https://crrev.com/c/230765
Cc: <stable@vger.kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
I didn't put any "Fixes" tag here, but presumably this could be
backported to whichever kernels folks found it useful for. I have at
least confirmed that kernels v4.14 and v4.19 (as well as v5.1-rc2)
show the problem. It is very easy to pick this to v4.19 and it
definitely fixes the problem there.
I haven't spent the time to pick this to 4.14 myself, but presumably
it wouldn't be too hard to backport this as far as v4.13 since that
contains commit 32dba73772f8 ("mmc: dw_mmc: Convert to use
MMC_CAP2_SDIO_IRQ_NOTHREAD for SDIO IRQs"). Prior to that it might
make sense for anyone experiencing this problem to just pick the old
CHROMIUM patch to fix them.
drivers/mmc/host/dw_mmc.c | 24 ++++++++++++++++++++----
drivers/mmc/host/dw_mmc.h | 3 +++
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 80dc2fd6576c..432f6e3ddd43 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1664,7 +1664,8 @@ static void dw_mci_init_card(struct mmc_host *mmc, struct mmc_card *card)
}
}
-static void __dw_mci_enable_sdio_irq(struct dw_mci_slot *slot, int enb)
+static void __dw_mci_enable_sdio_irq(struct dw_mci_slot *slot, bool enb,
+ bool client_requested)
{
struct dw_mci *host = slot->host;
unsigned long irqflags;
@@ -1672,6 +1673,17 @@ static void __dw_mci_enable_sdio_irq(struct dw_mci_slot *slot, int enb)
spin_lock_irqsave(&host->irq_lock, irqflags);
+ /*
+ * If this was requested by the client save the request. If this
+ * wasn't required by the client then logically AND it with the
+ * client request since we want to disable if either the client
+ * disabled OR we have some other reason to disable.
+ */
+ if (client_requested)
+ host->client_sdio_enb = enb;
+ else if (!host->client_sdio_enb)
+ enb = 0;
+
/* Enable/disable Slot Specific SDIO interrupt */
int_mask = mci_readl(host, INTMASK);
if (enb)
@@ -1688,7 +1700,7 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)
struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci *host = slot->host;
- __dw_mci_enable_sdio_irq(slot, enb);
+ __dw_mci_enable_sdio_irq(slot, enb, true);
/* Avoid runtime suspending the device when SDIO IRQ is enabled */
if (enb)
@@ -1701,7 +1713,7 @@ static void dw_mci_ack_sdio_irq(struct mmc_host *mmc)
{
struct dw_mci_slot *slot = mmc_priv(mmc);
- __dw_mci_enable_sdio_irq(slot, 1);
+ __dw_mci_enable_sdio_irq(slot, true, false);
}
static int dw_mci_execute_tuning(struct mmc_host *mmc, u32 opcode)
@@ -2734,7 +2746,7 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
if (pending & SDMMC_INT_SDIO(slot->sdio_id)) {
mci_writel(host, RINTSTS,
SDMMC_INT_SDIO(slot->sdio_id));
- __dw_mci_enable_sdio_irq(slot, 0);
+ __dw_mci_enable_sdio_irq(slot, false, false);
sdio_signal_irq(slot->mmc);
}
@@ -3424,6 +3436,8 @@ int dw_mci_runtime_suspend(struct device *dev)
{
struct dw_mci *host = dev_get_drvdata(dev);
+ __dw_mci_enable_sdio_irq(host->slot, false, false);
+
if (host->use_dma && host->dma_ops->exit)
host->dma_ops->exit(host);
@@ -3490,6 +3504,8 @@ int dw_mci_runtime_resume(struct device *dev)
/* Now that slots are all setup, we can enable card detect */
dw_mci_enable_cd(host);
+ __dw_mci_enable_sdio_irq(host->slot, true, false);
+
return 0;
err:
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 46e9f8ec5398..dfbace0f5043 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -127,6 +127,7 @@ struct dw_mci_dma_slave {
* @cmd11_timer: Timer for SD3.0 voltage switch over scheme.
* @cto_timer: Timer for broken command transfer over scheme.
* @dto_timer: Timer for broken data transfer over scheme.
+ * @client_sdio_enb: The value last passed to enable_sdio_irq.
*
* Locking
* =======
@@ -234,6 +235,8 @@ struct dw_mci {
struct timer_list cmd11_timer;
struct timer_list cto_timer;
struct timer_list dto_timer;
+
+ bool client_sdio_enb;
};
/* DMA ops for Internal/External DMAC interface */
--
2.21.0.392.gf8f6787159e-goog
^ permalink raw reply related
* Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
From: Alexander Wetzel @ 2019-04-10 20:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <ed6e95dad39ef0ac98c62e3acd3f78fd7b3a6d2b.camel@sipsolutions.net>
Am 08.04.19 um 22:10 schrieb Johannes Berg:
> On Sun, 2019-02-24 at 14:04 +0100, Alexander Wetzel wrote:
>
>> Finding a really good sniffer able to also capture A-MPDU frames
>> including control frames would be awesome.
>
> I think the AC-9260 you have should be a decent sniffer. The (yet
> unreleased) follow-up hardware is even better, but this one is fine.
>
> Just remember to load with amsdu_size set to the appropriate (maximum)
> A-MSDU size you want to capture.
I did not do that so far... Thanks for that tip!
>
>> I probably should work on the new AP, but then I always wanted to test
>> coreboot and finding out my notebook is now supported is too alluring to
>> resist;-)
>
> :-)
>
I've got a new test system in the meantime and have it up and running as
a simple test AP with Extended Key ID. I suspect I'll should tune the
antennas (and probably also the card) based on the first test spins, but
it's good enough for the moment.
>>> I think they all should just be made to work in native mode, the
>>> firmware basically supports this as you found, there must be some small
>>> bugs.
>>
>> Agree. And with your statements that it already should work and the
>> option to get ucode updates I like our chances:-) With some luck it
>> could even work and I made some error the first time. I'll give that a
>> second look with what I have at hand soon. But after bombing you with
>> mails for what feels like most of the weekend I'll postpone that for now:-)
>
> I was looking at the firmware now and ... well, I want to really test
> this to understand what's going wrong, because it really *looks* like
> even the recent ones should be supported natively, at least as far as
> I've looked now.
>
my new test AP came with a Intel AC-3168, which seems to use only one
antenna, potentially also explaining my fist impression that it's a
worse card for sniffing than my old Ultimate-N 6300. But it looks like
it's acting exactly the same in my other iwlmvm test. So I actually
started to run some tests and started writing a mail. It's so far
inconclusive and I want to verify the packets on the air next. Something
is off here and I want to look at that again from scratch, including an
external sniffer.
That said here what I've got so far and some fresh captures.
It looks like my (new) Wireless-AC 3168NGW (firmware 29.1044073957.0)
does not have the new key ready for Rx when needed. I have a roughly 5 -
15 ms long window where the card scrambles received packets using the
new key. (Note: I can't replicate that at the moment. May be wrong!)
I first suspected the card "cleared" the new key for usage a bit too
soon and tried to verify that by waiting a bit after installing a key to
the HW. But it looks like it's not so simple...
I've added a 40 ms delay in the mvm driver after the call to
iwl_mvm_set_sta_key() and it first looked like that improved the
situation. So I moved the sleep to iwl_trans_send_cmd() behind
send_cmd() when not being in CMD_ASYNC but I can't see any any
differences any longer. At the moment (with the new test setup) I always
get one corrupted frame when downloading from the AP. Always the first
frame using the new key...
As for the test procedure: I just add a monitor interface in parallel to
the "normal" interface on the AP. With HW encryption enabled we should
only get cleartext packets and don't have to worry about encrypted
packets in our capture at all:
iw phy phy0 interface add mon0 type monitor
ip link set up dev mon0
And start a capture in the interface:
tcpdump -pi mon0 -s0 -w /tmp/AP.cap
I've just uploaded some captures for you to
https://www.awhome.eu/index.php/s/AJJXBLsZmzHdxpX also. I've enabled
swcrypto on the client for the first two and enabled HW crypto on the
client again for the third and forth.
AP-40ms.pcap.gz
delay hack as outlined above on the AP
AP-no-delay.cap.gz
no hack (just some useless printks)
AP-no-delay-client-HW-crypt.cap.gz
same as above, only cleint using HW crypto
AP-upload-no-delay-HW-crypt.cap.gz
same as previous, only uploading instead of downloading.
(and too many broken packets on receive, indicating a bad
reception/sniffer card)
In all captures I have a normal (1s) ping running to the AP from the
cleint and start a download from an internal server after a while.
You can e.g. find the "corrupted" looking frames with the wireshark filter
"(wlan.fc.type_subtype == 0x0028) && !(llc.dsap == 0xaa)"
Each capture here only has exactly one, the very first packet using the
new key.
I'll plane to look deeper here, but that is as far as I got so far.
When you look at the captures keep in mind that both the client and the
AP also have the two not merged patches applied. But I do not see how
that makes a difference here.
>> As mentioned above I'm currently aiming for two or three Intel AC-9260
>> cards for the next development round. It's seems to be the most modern
>> card and the price difference between the cards is irrelevant compared
>> to both efforts and costs to get the cards working in two or three
>> devices. If you thing another card would be better for development I'll
>> just use that one instead...
>
> AC-9260 should be fine, as far as Intel is concerned. Also make for good
> sniffers, in my experience, we use them all the time for that.
Guess I will have to get one for my AP soon at least:-)
Alexander
^ permalink raw reply
* Re: [PATCH RFC] staging: wilc1000: give usleep_range a range
From: Adham.Abozaeid @ 2019-04-10 18:31 UTC (permalink / raw)
To: der.herr; +Cc: hofrat, Ajay.Kathat, gregkh, linux-wireless, devel, linux-kernel
In-Reply-To: <20190409013656.GA22293@osadl.at>
Hi Nicolas
On 4/8/19 6:36 PM, Nicholas Mc Guire wrote:
> 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.
yes, I believe 2.5 shouldn't be a problem.
Thanks,
Adham
^ permalink raw reply
* Re: [PATCH 2/6] netlink: make validation more configurable for future strictness
From: David Ahern @ 2019-04-10 16:55 UTC (permalink / raw)
To: Johannes Berg, linux-wireless, netdev; +Cc: Pablo Neira Ayuso, Johannes Berg
In-Reply-To: <20190404065408.5864-3-johannes@sipsolutions.net>
On 4/3/19 11:54 PM, Johannes Berg wrote:
> @@ -280,6 +287,12 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
> break;
>
> case NLA_UNSPEC:
> + if (validate & NL_VALIDATE_UNSPEC) {
> + NL_SET_ERR_MSG_ATTR(extack, nla,
> + "Attribute not understood");
I found that confusing when I did a trial run for a new route attribute.
How about "Unsupported attribute"?
> + return -EINVAL;
> + }
> + /* fall through */
> case NLA_MIN_LEN:
> if (attrlen < pt->len)
> goto out_err;
^ permalink raw reply
* Re: [RFC V4 2/2] ath10k: add tx hw 802.11 encapusaltion offloading support
From: Kalle Valo @ 2019-04-10 15:31 UTC (permalink / raw)
To: John Crispin
Cc: Johannes Berg, linux-wireless, Srini Kode, Rajkumar Manoharan,
Shashidhar Lakkavalli, Vasanthakumar Thiagarajan
In-Reply-To: <20190410073514.12794-3-john@phrozen.org>
John Crispin <john@phrozen.org> writes:
> From: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
>
> This patch adds support for ethernet rxtx mode to the driver. The feature
> is enabled via a new module parameter. If enabled to driver will enable
> the feature on a per vif basis if all other requirements were met.
>
> Testing on a IPQ4019 based hardware shows a increase in TCP throughput
> of ~20% when the feature is enabled.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
> Signed-off-by: John Crispin <john@phrozen.org>
Looks good to me.
BTW, for ath10k patches (patchsets including ath10k patches) please try
to CC also the ath10k list. Easier to find ath10k patches that way.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 0/4] Extended Key ID support
From: Marcel Holtmann @ 2019-04-10 14:37 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <e8ad598e-a2c4-45be-6923-11fccf80d296@wetzel-home.de>
Ho Alexander,
>>> This patch series adds support for IEEE 802.11-2016 Extended Key ID
>>> support. Compared to the last RFC there are again quite some API
>>> changes, but also some bug fixes. (The bug fixes I remember are outlined
>>> in the different patches.)
>> FWIW, I've applied the first two patches here.
>> I'd really like you to continue with only that for now, and (try to) get
>> hostapd/wpa_supplicant changes upstream, perhaps with corresponding
>> hwsim tests. That way, we can see this working live.
>
> That's splendid:-)
> I'll try to get the hostapd/wpa_supplicant patches finalized in the next weeks. Hopefully I have something to submit here once the Extended Key ID API is in mainline immediately.
have you tried to add Extended Key ID support into iwd?
Regards
Marcel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox