* [PATCH] ARM: dts: s5pv210: add interrupt-parent for ohci
From: Arnd Bergmann @ 2018-01-10 16:10 UTC (permalink / raw)
To: linux-arm-kernel
The ohci-hcd node has an interrupt number but no interrupt-parent,
leading to a warning with current dtc versions:
arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci at ec300000
As seen from the related exynos dts files, the ohci and ehci controllers
always share one interrupt number, and the number is the same here as
well, so setting the same interrupt-parent is the reasonable solution
here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/s5pv210.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
index 247c0029659c..67358562a6ea 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -460,6 +460,7 @@
compatible = "samsung,exynos4210-ohci";
reg = <0xec300000 0x100>;
interrupts = <23>;
+ interrupt-parent = <&vic1>;
clocks = <&clocks CLK_USB_HOST>;
clock-names = "usbhost";
#address-cells = <1>;
--
2.9.0
^ permalink raw reply related
* [PATCH net-next v4 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-10 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110155808.3484-1-antoine.tenart@free-electrons.com>
This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
nearly the same code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/ethernet/marvell/mvpp2.c | 49 ++++++++++++++++++++++++++++--------
1 file changed, 39 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 257a6b99b4ca..541b393a8583 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4502,6 +4502,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
break;
case PHY_INTERFACE_MODE_SGMII:
case PHY_INTERFACE_MODE_1000BASEX:
+ case PHY_INTERFACE_MODE_2500BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4540,7 +4541,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4571,7 +4573,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4584,7 +4587,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4599,6 +4603,16 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
mvpp22_gop_unmask_irq(port);
}
+/* Sets the PHY mode of the COMPHY (which configures the serdes lanes).
+ *
+ * The PHY mode used by the PPv2 driver comes from the network subsystem, while
+ * the one given to the COMPHY comes from the generic PHY subsystem. Hence they
+ * differ.
+ *
+ * The COMPHY configures the serdes lanes regardless of the actual use of the
+ * lanes by the physical layer. This is why configurations like
+ * "PPv2 (2500BaseX) - COMPHY (2500SGMII)" are valid.
+ */
static int mvpp22_comphy_init(struct mvpp2_port *port)
{
enum phy_mode mode;
@@ -4612,6 +4626,9 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
+ case PHY_INTERFACE_MODE_2500BASEX:
+ mode = PHY_MODE_2500SGMII;
+ break;
case PHY_INTERFACE_MODE_10GKR:
mode = PHY_MODE_10GKR;
break;
@@ -4631,7 +4648,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
u32 val;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4647,7 +4665,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
}
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PORT_TYPE_MASK;
else
val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
@@ -4660,7 +4679,13 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
- if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ /* Clear all fields we may want to explicitly set below */
+ val &= ~(MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_AN_SPEED_EN |
+ MVPP2_GMAC_AN_DUPLEX_EN);
+
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX |
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
/* 1000BaseX port cannot negotiate speed nor can it
* negotiate duplex: they are always operating with a
* fixed speed of 1000Mbps in full duplex, so force
@@ -4693,7 +4718,8 @@ static void mvpp2_port_mii_gmac_configure(struct mvpp2_port *port)
/* Configure the PCS and in-band AN */
val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
} else if (phy_interface_mode_is_rgmii(port->phy_interface)) {
val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
@@ -4756,7 +4782,8 @@ static void mvpp2_port_mii_set(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
mvpp2_port_mii_gmac_configure(port);
else if (port->phy_interface == PHY_INTERFACE_MODE_10GKR)
mvpp2_port_mii_xlg_configure(port);
@@ -4834,7 +4861,8 @@ static void mvpp2_port_loopback_set(struct mvpp2_port *port)
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -6048,7 +6076,8 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
}
} else if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
event = true;
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v4 3/4] net: mvpp2: 1000baseX support
From: Antoine Tenart @ 2018-01-10 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110155808.3484-1-antoine.tenart@free-electrons.com>
This patch adds the 1000Base-X PHY mode support in the Marvell PPv2
driver. 1000Base-X is quite close the SGMII and uses nearly the same
code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 45 ++++++++++++++++++++++++++++--------
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index a19760736b71..257a6b99b4ca 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4501,6 +4501,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
mvpp22_gop_init_rgmii(port);
break;
case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4538,7 +4539,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
u32 val;
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4568,7 +4570,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
}
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4580,7 +4583,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
u32 val;
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4605,6 +4609,7 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
switch (port->phy_interface) {
case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4625,7 +4630,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
{
u32 val;
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4640,9 +4646,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
}
- /* The port is connected to a copper PHY */
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ val |= MVPP2_GMAC_PORT_TYPE_MASK;
+ else
+ val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
writel(val, port->base + MVPP2_GMAC_CTRL_0_REG);
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
@@ -4651,6 +4659,19 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
MVPP2_GMAC_AN_DUPLEX_EN;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
+
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ /* 1000BaseX port cannot negotiate speed nor can it
+ * negotiate duplex: they are always operating with a
+ * fixed speed of 1000Mbps in full duplex, so force
+ * 1000 speed and full duplex here.
+ */
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ else
+ val |= MVPP2_GMAC_AN_SPEED_EN |
+ MVPP2_GMAC_AN_DUPLEX_EN;
+
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
}
@@ -4671,7 +4692,8 @@ static void mvpp2_port_mii_gmac_configure(struct mvpp2_port *port)
/* Configure the PCS and in-band AN */
val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
} else if (phy_interface_mode_is_rgmii(port->phy_interface)) {
val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
@@ -4733,7 +4755,8 @@ static void mvpp2_port_mii_set(struct mvpp2_port *port)
mvpp22_port_mii_set(port);
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
mvpp2_port_mii_gmac_configure(port);
else if (port->phy_interface == PHY_INTERFACE_MODE_10GKR)
mvpp2_port_mii_xlg_configure(port);
@@ -4810,7 +4833,8 @@ static void mvpp2_port_loopback_set(struct mvpp2_port *port)
else
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -6023,7 +6047,8 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
link = true;
}
} else if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
event = true;
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v4 2/4] phy: cp110-comphy: 2.5G SGMII mode
From: Antoine Tenart @ 2018-01-10 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110155808.3484-1-antoine.tenart@free-electrons.com>
This patch allow the CP100 comphy to configure some lanes in the
2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
same code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index a0d522154cdf..4ef429250d7b 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -135,19 +135,25 @@ struct mvebu_comhy_conf {
static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
/* lane 0 */
MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
/* lane 1 */
MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(1, 2, PHY_MODE_2500SGMII, 0x1),
/* lane 2 */
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(2, 0, PHY_MODE_2500SGMII, 0x1),
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
/* lane 3 */
MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(3, 1, PHY_MODE_2500SGMII, 0x2),
/* lane 4 */
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(4, 0, PHY_MODE_2500SGMII, 0x2),
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
/* lane 5 */
MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(5, 2, PHY_MODE_2500SGMII, 0x1),
};
struct mvebu_comphy_priv {
@@ -206,6 +212,10 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
if (mode == PHY_MODE_10GKR)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
+ else if (mode == PHY_MODE_2500SGMII)
+ val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x8) |
+ MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x8) |
+ MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
else if (mode == PHY_MODE_SGMII)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
@@ -296,13 +306,13 @@ static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane,
return 0;
}
-static int mvebu_comphy_set_mode_sgmii(struct phy *phy)
+static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
{
struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
struct mvebu_comphy_priv *priv = lane->priv;
u32 val;
- mvebu_comphy_ethernet_init_reset(lane, PHY_MODE_SGMII);
+ mvebu_comphy_ethernet_init_reset(lane, mode);
val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
@@ -487,7 +497,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
switch (lane->mode) {
case PHY_MODE_SGMII:
- ret = mvebu_comphy_set_mode_sgmii(phy);
+ case PHY_MODE_2500SGMII:
+ ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
break;
case PHY_MODE_10GKR:
ret = mvebu_comphy_set_mode_10gkr(phy);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v4 1/4] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2018-01-10 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110155808.3484-1-antoine.tenart@free-electrons.com>
This patch adds one more generic PHY mode to the phy_mode enum, to allow
configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
callback.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
include/linux/phy/phy.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 4f8423a948d5..5a80e9de3686 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ enum phy_mode {
PHY_MODE_USB_DEVICE,
PHY_MODE_USB_OTG,
PHY_MODE_SGMII,
+ PHY_MODE_2500SGMII,
PHY_MODE_10GKR,
PHY_MODE_UFS_HS_A,
PHY_MODE_UFS_HS_B,
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v4 0/4] net: mvpp2: 1000BaseX and 2500BaseX support
From: Antoine Tenart @ 2018-01-10 15:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
common PHY driver (cp110-comphy).
This was tested on a mcbin.
All patches should probably go through net-next as patch 4/4 depends on
patch 1/4 to build and work.
Please note the two mvpp2 patches do not conflict with the ACPI series
v2 Marcin sent a few days ago, and the two series can be processed in
parallel. (Marcin is aware of me sending this series).
Thanks!
Antoine
Since v3:
- Stopped setting the MII_SPEED bit in the GMAC AN register, as the
GMII_SPEED bit takes over anyway.
- Added Andrew's Reviewed-by on patch 4/4.
Since v2:
- Added a comment before mvpp22_comphy_init() about the different PHY modes
used and why they differ between the PPv2 driver and the COMPHY one.
Since v1:
- s/PHY_MODE_SGMII_2_5G/PHY_MODE_2500SGMII/
- Fixed a build error in 'net: mvpp2: 1000baseX support' (which was solved in
the 2500baseX support one, but the bisection was broken).
- Removed the dt patches, as the fourth network interface on the mcbin also
needs PHYLINK support in the PPv2 driver to be correctly supported.
Antoine Tenart (4):
phy: add 2.5G SGMII mode to the phy_mode enum
phy: cp110-comphy: 2.5G SGMII mode
net: mvpp2: 1000baseX support
net: mvpp2: 2500baseX support
drivers/net/ethernet/marvell/mvpp2.c | 74 ++++++++++++++++++++++++----
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 +++++--
include/linux/phy/phy.h | 1 +
3 files changed, 79 insertions(+), 13 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32
From: Christoph Hellwig @ 2018-01-10 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110155517.GA18774@lst.de>
On Wed, Jan 10, 2018 at 04:55:17PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 12:58:14PM +0000, Robin Murphy wrote:
> > On 10/01/18 08:09, Christoph Hellwig wrote:
> >> arm64 uses ZONE_DMA for allocations below 32-bits. These days we
> >> name the zone for that ZONE_DMA32, which will allow to use the
> >> dma-direct and generic swiotlb code as-is, so rename it.
> >
> > I do wonder if we could also "upgrade" GFP_DMA to GFP_DMA32 somehow when
> > !ZONE_DMA - there are almost certainly arm64 drivers out there using a
> > combination of GFP_DMA and streaming mappings which will no longer get the
> > guaranteed 32-bit addresses they expect after this. I'm not sure quite how
> > feasible that is, though :/
>
> I can't find anything obvious in the tree. The alternative would be
> to keep ZONE_DMA and set ARCH_ZONE_DMA_BITS.
>
> > That said, I do agree that this is an appropriate change (the legacy of
> > GFP_DMA is obviously horrible), so, provided we get plenty of time to find
> > and fix the fallout when it lands:
> >
> > Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>
> I was hoping to get this into 4.15. What would be proper time to
> fix the fallout?
Err, 4.16 of course.
^ permalink raw reply
* [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32
From: Christoph Hellwig @ 2018-01-10 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0371cef8-d980-96da-9cb5-3609c39be18a@arm.com>
On Wed, Jan 10, 2018 at 12:58:14PM +0000, Robin Murphy wrote:
> On 10/01/18 08:09, Christoph Hellwig wrote:
>> arm64 uses ZONE_DMA for allocations below 32-bits. These days we
>> name the zone for that ZONE_DMA32, which will allow to use the
>> dma-direct and generic swiotlb code as-is, so rename it.
>
> I do wonder if we could also "upgrade" GFP_DMA to GFP_DMA32 somehow when
> !ZONE_DMA - there are almost certainly arm64 drivers out there using a
> combination of GFP_DMA and streaming mappings which will no longer get the
> guaranteed 32-bit addresses they expect after this. I'm not sure quite how
> feasible that is, though :/
I can't find anything obvious in the tree. The alternative would be
to keep ZONE_DMA and set ARCH_ZONE_DMA_BITS.
> That said, I do agree that this is an appropriate change (the legacy of
> GFP_DMA is obviously horrible), so, provided we get plenty of time to find
> and fix the fallout when it lands:
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
I was hoping to get this into 4.15. What would be proper time to
fix the fallout?
^ permalink raw reply
* [PATCH 0/7] ARM: dts: STi: Fix DT dtc warnings
From: Arnd Bergmann @ 2018-01-10 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515572469-19276-1-git-send-email-patrice.chotard@st.com>
On Wed, Jan 10, 2018 at 9:21 AM, <patrice.chotard@st.com> wrote:
> From: Patrice Chotard <patrice.chotard@st.com>
>
> This series fixes all dtc warnings related to STi platforms dt files.
> It has been triggered by Rob Herring [1]
>
> [1] https://www.spinics.net/lists/devicetree/msg206209.html
>
> For most of implicated node, a simple move outside the soc node
> solves the warnings.
>
> Patrice Chotard (7):
> ARM: dts: STi: fix bindings notation
> ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property
> ARM: dts: STi: Move clocks without reg outside soc
> ARM: dts: STi: Move leds node outside soc node
> ARM: dts: STi: Move usb2_picophyX nodes without reg out of soc
> ARM: dts: STi: Move sound related nodes without reg out of soc
> ARM: dts: STi: Add fake reg property for sti-display-subsystem
Thanks a lot for addressing these!
As far as I can tell, there is one patch in particular that addresses a warning
we get at the default warning level: "ARM: dts: STi: Add gpio polarity for
"hdmi,hpd-gpio" property". Should we merge that one for 4.15 to get closer
to a clean build again? I'm not sure whether we can address the other
dtc warnings, but we're getting fairly close now.
Arnd
^ permalink raw reply
* [PATCH] crypto: marvell/cesa - Fix DMA API misuse
From: Christoph Hellwig @ 2018-01-10 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110162522.580089a5@bbrezillon>
On Wed, Jan 10, 2018 at 04:25:22PM +0100, Boris Brezillon wrote:
> On Wed, 10 Jan 2018 15:15:43 +0000
> Robin Murphy <robin.murphy@arm.com> wrote:
>
> > phys_to_dma() is an internal helper for certain DMA API implementations,
> > and is not appropriate for drivers to use. It appears that what the CESA
> > driver really wants to be using is dma_map_resource() - admittedly that
> > didn't exist when the offending code was first merged, but it does now.
> >
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Thanks. Robin, Boris: do you want me to pick this up in the
dma-mapping tree and move it before the dma-direct.h introduction?
^ permalink raw reply
* [PATCH v3 6/6] coresight: etm4x: Support panic kdump
From: Mathieu Poirier @ 2018-01-10 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110053319.GD16554@leoy-linaro>
On 9 January 2018 at 22:33, Leo Yan <leo.yan@linaro.org> wrote:
> On Tue, Jan 09, 2018 at 01:21:28PM -0700, Mathieu Poirier wrote:
>> On Thu, Dec 21, 2017 at 04:20:15PM +0800, Leo Yan wrote:
>> > ETMv4 hardware information and configuration needs to be saved as
>> > metadata; these metadata should be compatible with tool 'perf' and
>> > can be used for tracing data analysis. ETMv4 usually works as tracer
>> > per CPU, we cannot wait to gather ETM info after the CPU has been panic
>> > and cannot execute dump operations for itself; so should gather
>> > metadata when the corresponding CPU is alive.
>> >
>> > Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and
>> > won't change at the runtime. Those registers value are filled when
>> > tracers are instantiated.
>> >
>> > The configuration and control registers TRCCONFIGR and TRCTRACEIDR are
>> > dynamically configured, we record their value when enabling coresight
>> > path. When operating from sysFS tracer these two registers are recorded
>> > in etm4_enable_sysfs() and add kdump node into list, and remove the
>> > kdump node in etm4_disable_sysfs(). When operating from perf,
>> > etm_setup_aux() adds all tracers to the dump list and etm4_enable_perf()
>> > is used to record configuration registers and update dump buffer info,
>> > this can avoid unnecessary list addition and deletion operations.
>> > Removal of the tracers from the dump list is done in function
>> > free_event_data().
>> >
>> > Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
>> > ---
>> > drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +++++++++++-
>> > drivers/hwtracing/coresight/coresight-etm4x.c | 23 +++++++++++++++++++++++
>> > drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++++++++++++++
>> > 3 files changed, 49 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
>> > index 8a0ad77..fec779b 100644
>> > --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
>> > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
>> > @@ -137,6 +137,12 @@ static void free_event_data(struct work_struct *work)
>> > }
>> >
>> > for_each_cpu(cpu, mask) {
>> > + struct coresight_device *csdev;
>> > +
>> > + csdev = per_cpu(csdev_src, cpu);
>> > + if (csdev)
>> > + coresight_kdump_del(csdev);
>> > +
>> > if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
>> > coresight_release_path(event_data->path[cpu]);
>> > }
>> > @@ -195,7 +201,7 @@ static void etm_free_aux(void *data)
>> > static void *etm_setup_aux(int event_cpu, void **pages,
>> > int nr_pages, bool overwrite)
>> > {
>> > - int cpu;
>> > + int cpu, ret;
>> > cpumask_t *mask;
>> > struct coresight_device *sink;
>> > struct etm_event_data *event_data = NULL;
>> > @@ -238,6 +244,10 @@ static void *etm_setup_aux(int event_cpu, void **pages,
>> > event_data->path[cpu] = coresight_build_path(csdev, sink);
>> > if (IS_ERR(event_data->path[cpu]))
>> > goto err;
>> > +
>> > + ret = coresight_kdump_add(csdev, cpu);
>>
>> Aren't you missing the configuration for trcconfigr and trctraceidr?
>
> Ah, should update these two configurations in function
> etm4_enable_perf()?
Looking at what you've done for etm4_enable_sysfs() that is probably a
better choice.
>
>> > + if (ret)
>> > + goto err;
>> > }
>> >
>> > if (!sink_ops(sink)->alloc_buffer)
>> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
>> > index cf364a5..cbde398 100644
>> > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
>> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
>> > @@ -258,10 +258,19 @@ static int etm4_enable_perf(struct coresight_device *csdev,
>> > static int etm4_enable_sysfs(struct coresight_device *csdev)
>> > {
>> > struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> > + struct etmv4_config *config = &drvdata->config;
>> > + struct etmv4_metadata *metadata = &drvdata->metadata;
>> > int ret;
>> >
>> > spin_lock(&drvdata->spinlock);
>> >
>> > + /* Update meta data and add into kdump list */
>> > + metadata->trcconfigr = config->cfg;
>> > + metadata->trctraceidr = drvdata->trcid;
>> > +
>> > + coresight_kdump_add(csdev, drvdata->cpu);
>> > + coresight_kdump_update(csdev, (char *)metadata, sizeof(*metadata));
>> > +
>> > /*
>> > * Executing etm4_enable_hw on the cpu whose ETM is being enabled
>> > * ensures that register writes occur when cpu is powered.
>> > @@ -384,6 +393,9 @@ static void etm4_disable_sysfs(struct coresight_device *csdev)
>> > */
>> > smp_call_function_single(drvdata->cpu, etm4_disable_hw, drvdata, 1);
>> >
>> > + /* Delete from kdump list */
>> > + coresight_kdump_del(csdev);
>> > +
>> > spin_unlock(&drvdata->spinlock);
>> > cpus_read_unlock();
>> >
>> > @@ -438,6 +450,7 @@ static void etm4_init_arch_data(void *info)
>> > u32 etmidr4;
>> > u32 etmidr5;
>> > struct etmv4_drvdata *drvdata = info;
>> > + struct etmv4_metadata *metadata = &drvdata->metadata;
>> >
>> > /* Make sure all registers are accessible */
>> > etm4_os_unlock(drvdata);
>> > @@ -590,6 +603,16 @@ static void etm4_init_arch_data(void *info)
>> > drvdata->nrseqstate = BMVAL(etmidr5, 25, 27);
>> > /* NUMCNTR, bits[30:28] number of counters available for tracing */
>> > drvdata->nr_cntr = BMVAL(etmidr5, 28, 30);
>> > +
>> > + /* Update metadata */
>> > + metadata->magic = ETM4_METADATA_MAGIC;
>> > + metadata->cpu = drvdata->cpu;
>> > + metadata->trcidr0 = readl_relaxed(drvdata->base + TRCIDR0);
>> > + metadata->trcidr1 = readl_relaxed(drvdata->base + TRCIDR1);
>> > + metadata->trcidr2 = readl_relaxed(drvdata->base + TRCIDR2);
>> > + metadata->trcidr8 = readl_relaxed(drvdata->base + TRCIDR8);
>> > + metadata->trcauthstatus = readl_relaxed(drvdata->base + TRCAUTHSTATUS);
>> > +
>> > CS_LOCK(drvdata->base);
>> > }
>> >
>> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
>> > index b3b5ea7..08dc8b7 100644
>> > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
>> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
>> > @@ -198,6 +198,20 @@
>> > #define ETM_EXLEVEL_NS_HYP BIT(14)
>> > #define ETM_EXLEVEL_NS_NA BIT(15)
>> >
>> > +#define ETM4_METADATA_MAGIC 0x4040404040404040ULL
>>
>> This is a duplicate of the magic value found in cs-etm.h but I'm not sure of
>> what we'll do about that. It is probably time to come up
>> with a shared file between the kernel and the perf tools, just like
>> coresight-pmu.h. You can have a stab at it or concentrate on my previous
>> comments for now - it's entirely up to you.
>
> I will do some try for this for changing to use one shared single
> header, if I have no confidence for this I will go back to keep this
> code for new version patch.
Deal.
>
>> > +
>> > +struct etmv4_metadata {
>> > + u64 magic;
>> > + u64 cpu;
>> > + u64 trcconfigr;
>> > + u64 trctraceidr;
>> > + u64 trcidr0;
>> > + u64 trcidr1;
>> > + u64 trcidr2;
>> > + u64 trcidr8;
>> > + u64 trcauthstatus;
>> > +};
>>
>> Same here... This is a duplicate of struct etmv4_drvdata. Again not sure about
>> the best way to handle this. I'll think about it.
>
> Sure, I might check with you when I spin patches for this.
>
> Thanks,
> Leo Yan
>
>> > +
>> > /**
>> > * struct etmv4_config - configuration information related to an ETMv4
>> > * @mode: Controls various modes supported by this ETM.
>> > @@ -393,6 +407,7 @@ struct etmv4_drvdata {
>> > bool atbtrig;
>> > bool lpoverride;
>> > struct etmv4_config config;
>> > + struct etmv4_metadata metadata;
>> > };
>> >
>> > /* Address comparator access types */
>> > --
>> > 2.7.4
>> >
^ permalink raw reply
* [PATCH 10/22] swiotlb: refactor coherent buffer allocation
From: Christoph Hellwig @ 2018-01-10 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cecc98cf-2e6a-a7bc-7390-d6dcced038c4@arm.com>
On Wed, Jan 10, 2018 at 12:22:18PM +0000, Robin Murphy wrote:
>> + if (phys_addr == SWIOTLB_MAP_ERROR)
>> + goto out_warn;
>> - /* Confirm address can be DMA'd by device */
>> - if (dev_addr + size - 1 > dma_mask) {
>> - printk("hwdev DMA mask = 0x%016Lx, dev_addr = 0x%016Lx\n",
>> - (unsigned long long)dma_mask,
>> - (unsigned long long)dev_addr);
>> + *dma_handle = swiotlb_phys_to_dma(dev, phys_addr);
>
> nit: this should probably go after the dma_coherent_ok() check (as with the
> original logic).
But the originall logic also needs the dma_addr_t for the
dma_coherent_ok check:
dev_addr = swiotlb_phys_to_dma(hwdev, paddr);
/* Confirm address can be DMA'd by device */
if (dev_addr + size - 1 > dma_mask) {
...
goto err_warn;
}
or do you mean assining to *dma_handle? The dma_handle is not
valid for a failure return, so I don't think this should matter.
>> + if (ret) {
>> + *dma_handle = swiotlb_virt_to_bus(hwdev, ret);
>> + if (dma_coherent_ok(hwdev, *dma_handle, size)) {
>> + memset(ret, 0, size);
>> + return ret;
>> + }
>
> Aren't we leaking the pages here?
Yes, that free_pages got lost somewhere in the rebases, I've added
it back.
^ permalink raw reply
* [PATCH v3 3/6] coresight: Support panic kdump functionality
From: Mathieu Poirier @ 2018-01-10 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110051918.GC16554@leoy-linaro>
On 9 January 2018 at 22:19, Leo Yan <leo.yan@linaro.org> wrote:
> On Tue, Jan 09, 2018 at 11:41:26AM -0700, Mathieu Poirier wrote:
>> On Thu, Dec 21, 2017 at 04:20:12PM +0800, Leo Yan wrote:
>> > After kernel panic happens, coresight has many useful info can be used
>> > for analysis. For example, the trace info from ETB RAM can be used to
>> > check the CPU execution flows before crash. So we can save the tracing
>> > data from sink devices, and rely on kdump to save DDR content and uses
>> > "crash" tool to extract coresight dumping from vmcore file.
>> >
>> > This patch is to add a simple framework to support panic dump
>> > functionality; it registers panic notifier, and provide the general APIs
>> > {coresight_kdump_add|coresight_kdump_del} as helper functions so any
>> > coresight device can add itself into dump list or delete as needed.
>> >
>> > This driver provides helper function coresight_kdump_update() to update
>> > the dump buffer base address and buffer size. This function can be used
>> > by coresight driver, e.g. it can be used to save ETM meta data info at
>> > runtime and these info can be prepared pre panic happening.
>> >
>> > When kernel panic happens, the notifier iterates dump list and calls
>> > callback function to dump device specific info. The panic dump is
>> > mainly used to dump trace data so we can get to know the execution flow
>> > before the panic happens.
>> >
>> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
>> > ---
>> > drivers/hwtracing/coresight/Kconfig | 9 ++
>> > drivers/hwtracing/coresight/Makefile | 1 +
>> > .../hwtracing/coresight/coresight-panic-kdump.c | 154 +++++++++++++++++++++
>> > drivers/hwtracing/coresight/coresight-priv.h | 13 ++
>> > include/linux/coresight.h | 7 +
>> > 5 files changed, 184 insertions(+)
>> > create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
>> >
>> > diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
>> > index ef9cb3c..4812529 100644
>> > --- a/drivers/hwtracing/coresight/Kconfig
>> > +++ b/drivers/hwtracing/coresight/Kconfig
>> > @@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
>> > properly, please refer Documentation/trace/coresight-cpu-debug.txt
>> > for detailed description and the example for usage.
>> >
>> > +config CORESIGHT_PANIC_KDUMP
>> > + bool "CoreSight Panic Kdump driver"
>> > + depends on ARM || ARM64
>>
>> At this time only ETMv4 supports the feature, so it is only ARM64.
>
> Thanks for reviewing, Mathieu.
>
> Will change to only for ARM64.
>
>> > + help
>> > + This driver provides panic kdump functionality for CoreSight
>> > + devices. When a kernel panic happen a device supplied callback function
>> > + is used to save trace data to memory. From there we rely on kdump to extract
>> > + the trace data from kernel dump file.
>> > +
>> > endif
>> > diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
>> > index 61db9dd..946fe19 100644
>> > --- a/drivers/hwtracing/coresight/Makefile
>> > +++ b/drivers/hwtracing/coresight/Makefile
>> > @@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>> > obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
>> > obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>> > obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
>> > +obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
>> > diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c b/drivers/hwtracing/coresight/coresight-panic-kdump.c
>> > new file mode 100644
>> > index 0000000..c21d20b
>> > --- /dev/null
>> > +++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
>> > @@ -0,0 +1,154 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +// Copyright (c) 2017 Linaro Limited.
>> > +#include <linux/coresight.h>
>> > +#include <linux/coresight-pmu.h>
>> > +#include <linux/cpumask.h>
>> > +#include <linux/device.h>
>> > +#include <linux/init.h>
>> > +#include <linux/list.h>
>> > +#include <linux/mm.h>
>> > +#include <linux/perf_event.h>
>> > +#include <linux/slab.h>
>> > +#include <linux/types.h>
>> > +
>> > +#include "coresight-priv.h"
>> > +
>> > +typedef void (*coresight_cb_t)(void *data);
>> > +
>> > +/**
>> > + * struct coresight_kdump_node - Node information for dump
>> > + * @cpu: The cpu this node is affined to.
>> > + * @csdev: Handler for coresight device.
>> > + * @buf: Pointer for dump buffer.
>> > + * @buf_size: Length of dump buffer.
>> > + * @list: Hook to the list.
>> > + */
>> > +struct coresight_kdump_node {
>> > + int cpu;
>> > + struct coresight_device *csdev;
>> > + char *buf;
>> > + unsigned int buf_size;
>> > + struct list_head list;
>> > +};
>> > +
>> > +static DEFINE_SPINLOCK(coresight_kdump_lock);
>> > +static LIST_HEAD(coresight_kdump_list);
>> > +static struct notifier_block coresight_kdump_nb;
>> > +
>> > +int coresight_kdump_update(struct coresight_device *csdev, char *buf,
>> > + unsigned int buf_size)
>> > +{
>> > + struct coresight_kdump_node *node = csdev->dump_node;
>> > +
>> > + if (!node) {
>> > + dev_err(&csdev->dev, "Failed to update dump node.\n");
>> > + return -EINVAL;
>> > + }
>> > +
>> > + node->buf = buf;
>> > + node->buf_size = buf_size;
>> > + return 0;
>> > +}
>> > +
>> > +int coresight_kdump_add(struct coresight_device *csdev, int cpu)
>> > +{
>> > + struct coresight_kdump_node *node;
>> > + unsigned long flags;
>> > +
>> > + node = kzalloc(sizeof(*node), GFP_KERNEL);
>> > + if (!node)
>> > + return -ENOMEM;
>> > +
>> > + csdev->dump_node = (void *)node;
>> > + node->cpu = cpu;
>> > + node->csdev = csdev;
>> > +
>> > + spin_lock_irqsave(&coresight_kdump_lock, flags);
>> > + list_add_tail(&node->list, &coresight_kdump_list);
>> > + spin_unlock_irqrestore(&coresight_kdump_lock, flags);
>> > + return 0;
>> > +}
>> > +
>> > +void coresight_kdump_del(struct coresight_device *csdev)
>> > +{
>> > + struct coresight_kdump_node *node, *next;
>> > + unsigned long flags;
>> > +
>> > + spin_lock_irqsave(&coresight_kdump_lock, flags);
>> > + list_for_each_entry_safe(node, next, &coresight_kdump_list, list) {
>> > + if (node->csdev == csdev) {
>> > + list_del(&node->list);
>> > + kfree(node);
>> > + break;
>> > + }
>> > + }
>> > + spin_unlock_irqrestore(&coresight_kdump_lock, flags);
>> > +}
>> > +
>> > +static coresight_cb_t
>> > +coresight_kdump_get_cb(struct coresight_device *csdev)
>> > +{
>> > + coresight_cb_t cb = NULL;
>> > +
>> > + switch (csdev->type) {
>> > + case CORESIGHT_DEV_TYPE_SINK:
>> > + case CORESIGHT_DEV_TYPE_LINKSINK:
>> > + cb = sink_ops(csdev)->panic_cb;
>> > + break;
>> > + case CORESIGHT_DEV_TYPE_SOURCE:
>> > + cb = source_ops(csdev)->panic_cb;
>> > + break;
>> > + case CORESIGHT_DEV_TYPE_LINK:
>> > + cb = link_ops(csdev)->panic_cb;
>> > + break;
>>
>> I don't see why we need a callback for link devices - didn't I raised
>> that question before?
>
> Yes, sorry I have not deleted for link devices completely. Will remove
> it.
>
>> And I've been thinking further about this. The way we call the panic callbacks
>> won't work. When a panic is triggered there might be trace data in the CS network
>> that hasn't made it to the sink yet and calling the panic callbacks for sinks
>> will lead to a loss of data.
>>
>> That is why, when accessing from both sysFS and perf, the current implementation
>> takes great care to stop the tracers first and then deal with the sink. To fix
>> this I suggest to call the panic callbacks only for sources. What happens there
>> will depend on what interface is used (sysFS or perf) - look at what is
>> currently done to get a better understanding.
>
> Will look into this.
>
> If I understand correctly, we need firstly stop tracers and save trace
> data from sink, right? If so we need use single callback function to
> disable path and dump data for sink, will study current case and check
> what's the clean method for kdump.
You are correct - only the callback for sources should be used. In
that callback processing is different whether trace collection was
started from sysFS or perf. The code already exists, it's just a
matter of doing the right thing.
>
>> > + default:
>> > + dev_info(&csdev->dev, "Unsupport panic dump\n");
>>
>> I would not bother with the dev_info()...
>
> Will remove it.
>
>> > + break;
>> > + }
>> > +
>> > + return cb;
>> > +}
>> > +
>> > +/**
>> > + * coresight_kdump_notify - Invoke panic dump callbacks, this is
>> > + * the main function to fulfill the panic dump. It distinguishs
>> > + * to two types: one is pre panic dump which the callback function
>> > + * handler is NULL and coresight drivers can use function
>> > + * coresight_kdump_update() to directly update dump buffer base
>> > + * address and buffer size, for this case this function does nothing
>> > + * and directly bail out; another case is for post panic dump so
>> > + * invoke callback on alive CPU.
>>
>> Now that pre and post processing are gone the description above doesn't match
>> what the function is doing.
>
> Yeah, will remove 'pre' and 'post' to avoid confusion.
>
>> > + *
>> > + * Returns: 0 on success.
>> > + */
>> > +static int coresight_kdump_notify(struct notifier_block *nb,
>> > + unsigned long mode, void *_unused)
>> > +{
>> > + struct coresight_kdump_node *node;
>> > + struct coresight_device *csdev;
>> > + coresight_cb_t cb;
>> > + unsigned long flags;
>> > +
>> > + spin_lock_irqsave(&coresight_kdump_lock, flags);
>> > +
>> > + list_for_each_entry(node, &coresight_kdump_list, list) {
>> > + csdev = node->csdev;
>> > + cb = coresight_kdump_get_cb(csdev);
>> > + if (cb)
>> > + cb(csdev);
>> > + }
>> > +
>> > + spin_unlock_irqrestore(&coresight_kdump_lock, flags);
>> > + return 0;
>> > +}
>> > +
>> > +static int __init coresight_kdump_init(void)
>> > +{
>> > + int ret;
>> > +
>> > + coresight_kdump_nb.notifier_call = coresight_kdump_notify;
>> > + ret = atomic_notifier_chain_register(&panic_notifier_list,
>> > + &coresight_kdump_nb);
>> > + return ret;
>> > +}
>> > +late_initcall(coresight_kdump_init);
>> > diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
>> > index f1d0e21d..937750e 100644
>> > --- a/drivers/hwtracing/coresight/coresight-priv.h
>> > +++ b/drivers/hwtracing/coresight/coresight-priv.h
>> > @@ -151,4 +151,17 @@ static inline int etm_readl_cp14(u32 off, unsigned int *val) { return 0; }
>> > static inline int etm_writel_cp14(u32 off, u32 val) { return 0; }
>> > #endif
>> >
>> > +#ifdef CONFIG_CORESIGHT_PANIC_KDUMP
>> > +extern int coresight_kdump_add(struct coresight_device *csdev, int cpu);
>> > +extern void coresight_kdump_del(struct coresight_device *csdev);
>> > +extern int coresight_kdump_update(struct coresight_device *csdev,
>> > + char *buf, unsigned int buf_size);
>> > +#else
>> > +static inline int
>> > +coresight_kdump_add(struct coresight_device *csdev, int cpu) { return 0; }
>> > +static inline void coresight_kdump_del(struct coresight_device *csdev) {}
>> > +static inline int coresight_kdump_update(struct coresight_device *csdev,
>> > + char *buf, unsigned int buf_size) { return 0; }
>>
>> static inline int
>> coresight_kdump_update(struct coresight_device *csdev, char *buf,
>> unsigned int buf_size) { return 0; }
>
> Will fix.
>
>> > +#endif
>> > +
>> > #endif
>> > diff --git a/include/linux/coresight.h b/include/linux/coresight.h
>> > index d950dad..43e40fa 100644
>> > --- a/include/linux/coresight.h
>> > +++ b/include/linux/coresight.h
>> > @@ -171,6 +171,7 @@ struct coresight_device {
>> > bool orphan;
>> > bool enable; /* true only if configured as part of a path */
>> > bool activated; /* true only if a sink is part of a path */
>> > + void *dump_node;
>>
>> Please add a description for this entry.
>
> Will do.
>
> Thanks,
> Leo Yan
>
>> > };
>> >
>> > #define to_coresight_device(d) container_of(d, struct coresight_device, dev)
>> > @@ -189,6 +190,7 @@ struct coresight_device {
>> > * @set_buffer: initialises buffer mechanic before a trace session.
>> > * @reset_buffer: finalises buffer mechanic after a trace session.
>> > * @update_buffer: update buffer pointers after a trace session.
>> > + * @panic_cb: hook function for panic notifier.
>> > */
>> > struct coresight_ops_sink {
>> > int (*enable)(struct coresight_device *csdev, u32 mode);
>> > @@ -205,6 +207,7 @@ struct coresight_ops_sink {
>> > void (*update_buffer)(struct coresight_device *csdev,
>> > struct perf_output_handle *handle,
>> > void *sink_config);
>> > + void (*panic_cb)(void *data);
>> > };
>> >
>> > /**
>> > @@ -212,10 +215,12 @@ struct coresight_ops_sink {
>> > * Operations available for links.
>> > * @enable: enables flow between iport and oport.
>> > * @disable: disables flow between iport and oport.
>> > + * @panic_cb: hook function for panic notifier.
>> > */
>> > struct coresight_ops_link {
>> > int (*enable)(struct coresight_device *csdev, int iport, int oport);
>> > void (*disable)(struct coresight_device *csdev, int iport, int oport);
>> > + void (*panic_cb)(void *data);
>> > };
>> >
>> > /**
>> > @@ -227,6 +232,7 @@ struct coresight_ops_link {
>> > * to the HW.
>> > * @enable: enables tracing for a source.
>> > * @disable: disables tracing for a source.
>> > + * @panic_cb: hook function for panic notifier.
>> > */
>> > struct coresight_ops_source {
>> > int (*cpu_id)(struct coresight_device *csdev);
>> > @@ -235,6 +241,7 @@ struct coresight_ops_source {
>> > struct perf_event *event, u32 mode);
>> > void (*disable)(struct coresight_device *csdev,
>> > struct perf_event *event);
>> > + void (*panic_cb)(void *data);
>> > };
>> >
>> > struct coresight_ops {
>> > --
>> > 2.7.4
>> >
^ permalink raw reply
* [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header
From: Christoph Hellwig @ 2018-01-10 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0f90ed0-989f-4dc2-6f86-de8b4e486b55@arm.com>
On Wed, Jan 10, 2018 at 03:31:08PM +0000, Robin Murphy wrote:
> Yes indeed, modulo Vladimir's comments - it does seem prudent to fix the
> obvious off-by-ones as we touch them. I've wanted to do something like this
> for ages, but never got around to it myself.
I've fixed these now in a separate patch. I'm taking this as an
Acked-by.
^ permalink raw reply
* [PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops
From: Christoph Hellwig @ 2018-01-10 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a058876-08fc-7323-7cb3-fe85116e2ea8@arm.com>
On Wed, Jan 10, 2018 at 12:16:15PM +0000, Robin Murphy wrote:
> On 10/01/18 08:09, Christoph Hellwig wrote:
>> To properly reject too small DMA masks based on the addressability of the
>> bounce buffer.
>
> I reckon this is self-evident enough that it should simply be squashed into
> the previous patch.
x86 didn't wire it up before, so I want a clear blaimpoint for this
change instead of mixing it up.
^ permalink raw reply
* Applied "IIO: ADC: stm32_dfsdm_stop_filter() can be static" to the asoc tree
From: Mark Brown @ 2018-01-10 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110152305.GA83560@lkp-sb05>
The patch
IIO: ADC: stm32_dfsdm_stop_filter() can be static
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 1c4d0c5bc347328b257740d060ce9dbf48eebfe0 Mon Sep 17 00:00:00 2001
From: kbuild test robot <fengguang.wu@intel.com>
Date: Wed, 10 Jan 2018 23:23:05 +0800
Subject: [PATCH] IIO: ADC: stm32_dfsdm_stop_filter() can be static
Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/iio/adc/stm32-dfsdm-adc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
index b03ca3f94331..e628d04d5c77 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -254,7 +254,7 @@ static int stm32_dfsdm_start_filter(struct stm32_dfsdm *dfsdm,
DFSDM_CR1_RSWSTART(1));
}
-void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned int fl_id)
+static void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned int fl_id)
{
/* Disable conversion */
regmap_update_bits(dfsdm->regmap, DFSDM_CR1(fl_id),
@@ -296,9 +296,9 @@ static int stm32_dfsdm_filter_configure(struct stm32_dfsdm *dfsdm,
DFSDM_CR1_RSYNC(fl->sync_mode));
}
-int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
- struct iio_dev *indio_dev,
- struct iio_chan_spec *ch)
+static int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
+ struct iio_dev *indio_dev,
+ struct iio_chan_spec *ch)
{
struct stm32_dfsdm_channel *df_ch;
const char *of_str;
--
2.15.1
^ permalink raw reply related
* [PATCH 31/33] dma-direct: reject too small dma masks
From: Christoph Hellwig @ 2018-01-10 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0bcca030-a8da-c34a-a905-707986689f33@arm.com>
On Wed, Jan 10, 2018 at 11:49:34AM +0000, Robin Murphy wrote:
>> +#ifdef CONFIG_ZONE_DMA
>> + if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
>> + return 0;
>> +#else
>> + /*
>> + * Because 32-bit DMA masks are so common we expect every architecture
>> + * to be able to satisfy them - either by not supporting more physical
>> + * memory, or by providing a ZONE_DMA32. If neither is the case, the
>> + * architecture needs to use an IOMMU instead of the direct mapping.
>> + */
>> + if (mask < DMA_BIT_MASK(32))
>> + return 0;
>
> Do you think it's worth the effort to be a little more accommodating here?
> i.e.:
>
> return dma_max_pfn(dev) >= max_pfn;
>
> We seem to have a fair few 28-31 bit masks for older hardware which
> probably associates with host systems packing equivalently small amounts of
> RAM.
And those devices don't have a ZONE_DMA? I think we could do something
like that, but I'd rather have it as a separate commit with a good
explanation. Maybe you can just send on on top of the series?
^ permalink raw reply
* [RFC PATCH asoc] IIO: ADC: stm32_dfsdm_stop_filter() can be static
From: Arnaud Pouliquen @ 2018-01-10 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110152305.GA83560@lkp-sb05>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
On 01/10/2018 04:23 PM, kbuild test robot wrote:
>
> Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
> ?stm32-dfsdm-adc.c |??? 8 ++++----
> ?1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c
> b/drivers/iio/adc/stm32-dfsdm-adc.c
> index b03ca3f..e628d04 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -254,7 +254,7 @@ static int stm32_dfsdm_start_filter(struct
> stm32_dfsdm *dfsdm,
> ?????????????????????????????????? DFSDM_CR1_RSWSTART(1));
> ?}
> ?
> -void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned int fl_id)
> +static void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned
> int fl_id)
> ?{
> ???????? /* Disable conversion */
> ???????? regmap_update_bits(dfsdm->regmap, DFSDM_CR1(fl_id),
> @@ -296,9 +296,9 @@ static int stm32_dfsdm_filter_configure(struct
> stm32_dfsdm *dfsdm,
> ?????????????????????????????????? DFSDM_CR1_RSYNC(fl->sync_mode));
> ?}
> ?
> -int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
> -??????????????????????????????? struct iio_dev *indio_dev,
> -??????????????????????????????? struct iio_chan_spec *ch)
> +static int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
> +?????????????????????????????????????? struct iio_dev *indio_dev,
> +?????????????????????????????????????? struct iio_chan_spec *ch)
> ?{
> ???????? struct stm32_dfsdm_channel *df_ch;
> ???????? const char *of_str;
^ permalink raw reply
* [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header
From: Robin Murphy @ 2018-01-10 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110152617.GB17790@lst.de>
On 10/01/18 15:26, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 02:56:01PM +0000, Robin Murphy wrote:
>> I took a look at these, and it seems their phys_to_dma() usage is doing the
>> thing which we subsequently formalised as dma_map_resource(). I've had a
>> crack at a quick patch to update the CESA driver; qcom_nandc looks slightly
>> more complex in that the changes probably need to span the BAM dmaengine
>> driver as well.
>
> Sounds great, although probably something for the next merge window.
>
> In the meantime does this patch looks good to you?
Yes indeed, modulo Vladimir's comments - it does seem prudent to fix the
obvious off-by-ones as we touch them. I've wanted to do something like
this for ages, but never got around to it myself.
Thanks,
Robin.
^ permalink raw reply
* [PATCH 27/33] dma-direct: use node local allocations for coherent memory
From: Christoph Hellwig @ 2018-01-10 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3672aa56-b85c-5d2c-0c0e-709031b0c0a0@arm.com>
On Wed, Jan 10, 2018 at 12:06:22PM +0000, Robin Murphy wrote:
> On 10/01/18 08:00, Christoph Hellwig wrote:
>> To preserve the x86 behavior.
>
> And combined with patch 10/22 of the SWIOTLB refactoring, this means
> SWIOTLB allocations will also end up NUMA-aware, right? Great, that's what
> we want on arm64 too :)
Well, only for swiotlb allocations that can be satisfied by
dma_direct_alloc. If we actually have to fall back to the swiotlb
buffers there is not node affinity yet.
^ permalink raw reply
* [PATCH 20/33] dma-mapping: clear harmful GFP_* flags in common code
From: Christoph Hellwig @ 2018-01-10 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <27b90341-f9d0-356f-0194-1c7203a3f93e@arm.com>
On Wed, Jan 10, 2018 at 11:59:30AM +0000, Robin Murphy wrote:
> Just a note that if we're all happy to enshrine the "allocations are always
> zeroed" behaviour in the API (I am too, for the record), we should remember
> to follow up once the dust settles to update the docs and I guess just
> #define dma_zalloc_coherent dma_alloc_coherent.
And then just remove it. But yes, another item for the todo list..
^ permalink raw reply
* [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header
From: Christoph Hellwig @ 2018-01-10 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3721b4ba-0685-255e-06b9-6e60678a1a92@arm.com>
On Wed, Jan 10, 2018 at 02:56:01PM +0000, Robin Murphy wrote:
> I took a look at these, and it seems their phys_to_dma() usage is doing the
> thing which we subsequently formalised as dma_map_resource(). I've had a
> crack at a quick patch to update the CESA driver; qcom_nandc looks slightly
> more complex in that the changes probably need to span the BAM dmaengine
> driver as well.
Sounds great, although probably something for the next merge window.
In the meantime does this patch looks good to you?
^ permalink raw reply
* [PATCH] crypto: marvell/cesa - Fix DMA API misuse
From: Boris Brezillon @ 2018-01-10 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55d3177407b00dd4a9d51fe4f8e2bf2282fe8e3d.1515596541.git.robin.murphy@arm.com>
On Wed, 10 Jan 2018 15:15:43 +0000
Robin Murphy <robin.murphy@arm.com> wrote:
> phys_to_dma() is an internal helper for certain DMA API implementations,
> and is not appropriate for drivers to use. It appears that what the CESA
> driver really wants to be using is dma_map_resource() - admittedly that
> didn't exist when the offending code was first merged, but it does now.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
>
> Found by inspection and compile-tested only
>
> drivers/crypto/marvell/cesa.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
> index 293832488cc9..f81fa4a3e66b 100644
> --- a/drivers/crypto/marvell/cesa.c
> +++ b/drivers/crypto/marvell/cesa.c
> @@ -15,6 +15,7 @@
> */
>
> #include <linux/delay.h>
> +#include <linux/dma-mapping.h>
> #include <linux/genalloc.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> @@ -409,8 +410,11 @@ static int mv_cesa_get_sram(struct platform_device *pdev, int idx)
> if (IS_ERR(engine->sram))
> return PTR_ERR(engine->sram);
>
> - engine->sram_dma = phys_to_dma(cesa->dev,
> - (phys_addr_t)res->start);
> + engine->sram_dma = dma_map_resource(cesa->dev, res->start,
> + cesa->sram_size,
> + DMA_BIDIRECTIONAL, 0);
> + if (dma_mapping_error(cesa->dev, engine->sram_dma))
> + return -ENOMEM;
>
> return 0;
> }
> @@ -420,11 +424,12 @@ static void mv_cesa_put_sram(struct platform_device *pdev, int idx)
> struct mv_cesa_dev *cesa = platform_get_drvdata(pdev);
> struct mv_cesa_engine *engine = &cesa->engines[idx];
>
> - if (!engine->pool)
> - return;
> -
> - gen_pool_free(engine->pool, (unsigned long)engine->sram,
> - cesa->sram_size);
> + if (engine->pool)
> + gen_pool_free(engine->pool, (unsigned long)engine->sram,
> + cesa->sram_size);
> + else
> + dma_unmap_resource(cesa->dev, engine->sram_dma,
> + cesa->sram_size, DMA_BIDIRECTIONAL, 0);
> }
>
> static int mv_cesa_probe(struct platform_device *pdev)
^ permalink raw reply
* [RFC PATCH asoc] IIO: ADC: stm32_dfsdm_stop_filter() can be static
From: kbuild test robot @ 2018-01-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201801102320.fKoiIrHz%fengguang.wu@intel.com>
Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
stm32-dfsdm-adc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
index b03ca3f..e628d04 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -254,7 +254,7 @@ static int stm32_dfsdm_start_filter(struct stm32_dfsdm *dfsdm,
DFSDM_CR1_RSWSTART(1));
}
-void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned int fl_id)
+static void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned int fl_id)
{
/* Disable conversion */
regmap_update_bits(dfsdm->regmap, DFSDM_CR1(fl_id),
@@ -296,9 +296,9 @@ static int stm32_dfsdm_filter_configure(struct stm32_dfsdm *dfsdm,
DFSDM_CR1_RSYNC(fl->sync_mode));
}
-int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
- struct iio_dev *indio_dev,
- struct iio_chan_spec *ch)
+static int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
+ struct iio_dev *indio_dev,
+ struct iio_chan_spec *ch)
{
struct stm32_dfsdm_channel *df_ch;
const char *of_str;
^ permalink raw reply related
* [asoc:topic/iio 9/11] drivers/iio/adc/stm32-dfsdm-adc.c:241:6: sparse: symbol 'stm32_dfsdm_stop_filter' was not declared. Should it be static?
From: kbuild test robot @ 2018-01-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/iio
head: 16cbca06fa8288a4f58426fc898b141e12ee8008
commit: e2e6771c646251657fafb2a78db566d5c2c70635 [9/11] IIO: ADC: add STM32 DFSDM sigma delta ADC support
reproduce:
# apt-get install sparse
git checkout e2e6771c646251657fafb2a78db566d5c2c70635
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/iio/adc/stm32-dfsdm-adc.c:241:6: sparse: symbol 'stm32_dfsdm_stop_filter' was not declared. Should it be
>> drivers/iio/adc/stm32-dfsdm-adc.c:283:5: sparse: symbol 'stm32_dfsdm_channel_parse_of' was not declared. Should it be
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ 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