* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Antoine Tenart @ 2017-12-27 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227222401.GT10595@n2100.armlinux.org.uk>
Hi Russell,
On Wed, Dec 27, 2017 at 10:24:01PM +0000, Russell King - ARM Linux wrote:
> On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> >
> > +&cps_eth2 {
> > + /* CPS Lane 5 */
> > + status = "okay";
> > + phy-mode = "2500base-x";
> > + /* Generic PHY, providing serdes lanes */
> > + phys = <&cps_comphy5 2>;
> > +};
> > +
>
> This is wrong. This lane is connected to a SFP cage which can support
> more than just 2500base-X. Tying it in this way to 2500base-X means
> that this port does not support conenctions at 1000base-X, despite
> that's one of the most popular and more standardised speeds.
What do you suggest to describe this in the dt, to enable a port using
the current PPv2 driver?
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Russell King - ARM Linux @ 2017-12-27 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227221446.18459-6-antoine.tenart@free-electrons.com>
On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> This patch enables the fourth network interface on the Marvell
> Macchiatobin. It is configured in the 2500Base-X PHY mode.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
> arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> index b3350827ee55..c51efd511324 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> @@ -279,6 +279,14 @@
> phys = <&cps_comphy0 1>;
> };
>
> +&cps_eth2 {
> + /* CPS Lane 5 */
> + status = "okay";
> + phy-mode = "2500base-x";
> + /* Generic PHY, providing serdes lanes */
> + phys = <&cps_comphy5 2>;
> +};
> +
This is wrong. This lane is connected to a SFP cage which can support
more than just 2500base-X. Tying it in this way to 2500base-X means
that this port does not support conenctions at 1000base-X, despite
that's one of the most popular and more standardised speeds.
So, I feel I have to NAK this patch in its current form.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH net-next 6/6] arm64: dts: marvell: add Ethernet aliases
From: Antoine Tenart @ 2017-12-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227221446.18459-1-antoine.tenart@free-electrons.com>
From: Yan Markman <ymarkman@marvell.com>
This patch adds Ethernet aliases in the Marvell Aramada 7040 DB, 8040 DB
and 8040 mcbin device trees so that the bootloader setup the MAC
addresses correctly.
Signed-off-by: Yan Markman <ymarkman@marvell.com>
[Antoine: commit message, small fixes]
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 6 ++++++
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 7 +++++++
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 7 +++++++
3 files changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index 52b5341cb270..62b83416b30c 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -61,6 +61,12 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cpm_eth1;
+ ethernet2 = &cpm_eth2;
+ };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "usb3h0-vbus";
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
index d97b72bed662..d9fffde64c44 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -61,6 +61,13 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cpm_eth2;
+ ethernet2 = &cps_eth0;
+ ethernet3 = &cps_eth1;
+ };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "cpm-usb3h0-vbus";
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index c51efd511324..7a23bb279e1c 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -62,6 +62,13 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cps_eth0;
+ ethernet2 = &cps_eth1;
+ ethernet3 = &cps_eth2;
+ };
+
/* Regulator labels correspond with schematics */
v_3_3: regulator-3-3v {
compatible = "regulator-fixed";
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Antoine Tenart @ 2017-12-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227221446.18459-1-antoine.tenart@free-electrons.com>
This patch enables the fourth network interface on the Marvell
Macchiatobin. It is configured in the 2500Base-X PHY mode.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index b3350827ee55..c51efd511324 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -279,6 +279,14 @@
phys = <&cps_comphy0 1>;
};
+&cps_eth2 {
+ /* CPS Lane 5 */
+ status = "okay";
+ phy-mode = "2500base-x";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cps_comphy5 2>;
+};
+
&cps_pinctrl {
cps_spi1_pins: spi1-pins {
marvell,pins = "mpp12", "mpp13", "mpp14", "mpp15", "mpp16";
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 4/6] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2017-12-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227221446.18459-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>
---
drivers/net/ethernet/marvell/mvpp2.c | 40 ++++++++++++++++++++++++++++--------
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 094db9dd633f..5d2a6f5a52b6 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);
@@ -4612,6 +4616,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_SGMII_2_5G;
+ break;
case PHY_INTERFACE_MODE_10GKR:
mode = PHY_MODE_10GKR;
break;
@@ -4631,7 +4638,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 +4655,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,6 +4669,11 @@ 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;
+ /* 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)
/* 1000BaseX port cannot negotiate speed nor can it
* negotiate duplex: they are always operating with a
@@ -4668,6 +4682,10 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
*/
val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ else if (port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX;
else
val |= MVPP2_GMAC_AN_SPEED_EN |
MVPP2_GMAC_AN_DUPLEX_EN;
@@ -4693,7 +4711,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 +4775,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 +4854,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 +6069,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 3/6] net: mvpp2: 1000baseX support
From: Antoine Tenart @ 2017-12-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227221446.18459-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..094db9dd633f 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 2/6] phy: cp110-comphy: 2.5G SGMII mode
From: Antoine Tenart @ 2017-12-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227221446.18459-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..946a6ed7b66f 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_SGMII_2_5G, 0x1),
/* lane 1 */
MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII_2_5G, 0x1),
/* lane 2 */
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII_2_5G, 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_SGMII_2_5G, 0x2),
/* lane 4 */
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII_2_5G, 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_SGMII_2_5G, 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_SGMII_2_5G)
+ 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_SGMII_2_5G:
+ 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 1/6] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2017-12-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227221446.18459-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..70459a28f3a1 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_SGMII_2_5G,
PHY_MODE_10GKR,
PHY_MODE_UFS_HS_A,
PHY_MODE_UFS_HS_B,
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 0/6] net: mvpp2: 1000BaseX and 2000BaseX support
From: Antoine Tenart @ 2017-12-27 22:14 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).
Thanks to theses patches the fourth network interface can be used on the
mcbin, and two patches are attached: one to describe the interface in
the mcbin device tree, and another one adding Ethernet aliases now that
the four interfaces are described.
This was tested on a mcbin.
Patches 1 and 2 should go through the PHY tree, patches 3 and 4 through
the net-next tree and patches 5 and 6 through the mvebu one.
Please note the two mvpp2 patches do not conflict with the ACPI series
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
Antoine Tenart (5):
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
arm64: dts: marvell: mcbin: enable the fourth network interface
Yan Markman (1):
arm64: dts: marvell: add Ethernet aliases
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 6 ++
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 7 +++
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 15 +++++
drivers/net/ethernet/marvell/mvpp2.c | 67 +++++++++++++++++++----
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 +++++-
include/linux/phy/phy.h | 1 +
6 files changed, 100 insertions(+), 13 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Rob Herring @ 2017-12-27 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fdb2ab5-1dca-c44c-b647-3388a8ecea81@codeaurora.org>
On Wed, Dec 27, 2017 at 4:20 AM, Sricharan R <sricharan@codeaurora.org> wrote:
> Hi Rob,
>
> On 12/26/2017 11:06 PM, Rob Herring wrote:
>> On Thu, Dec 21, 2017 at 5:53 AM, Sricharan R <sricharan@codeaurora.org> wrote:
>>> Hi Rob,
>>>
>>> On 12/21/2017 2:48 AM, Rob Herring wrote:
>>>> On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
>>>>> Hi Viresh,
>>>>>
>>>>> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
>>>>>> On 19-12-17, 21:25, Sricharan R wrote:
>>>>>>> + cpu at 0 {
>>>>>>> + compatible = "qcom,krait";
>>>>>>> + enable-method = "qcom,kpss-acc-v1";
>>>>>>> + device_type = "cpu";
>>>>>>> + reg = <0>;
>>>>>>> + qcom,acc = <&acc0>;
>>>>>>> + qcom,saw = <&saw0>;
>>>>>>> + clocks = <&kraitcc 0>;
>>>>>>> + clock-names = "cpu";
>>>>>>> + cpu-supply = <&smb208_s2a>;
>>>>>>> + operating-points-v2 = <&cpu_opp_table>;
>>>>>>> + };
>>>>>>> +
>>>>>>> + qcom,pvs {
>>>>>>> + qcom,pvs-format-a;
>>>>>>> + };
>>>>>>
>>>>>> Not sure what Rob is going to say on that :)
>>>>>>
>>>>>
>>>>> Yes. Would be good to know the best way.
>>>>
>>>> Seems like this should be a property of an efuse node either implied by
>>>> the compatible or a separate property. What determines format A vs. B?
>>>>
>>>
>>> Yes, this efuse registers are part of the eeprom (qfprom) tied to the soc.
>>> So this property (details like bitfields and register offsets that it represents)
>>> can be put soc specific and nvmem apis can be used to read
>>> the registers. Does something like below look ok ?
>>>
>>> qcom,pvs {
>>> compatible = "qcom,pvs-ipq8064";
>>> nvmem-cells = <&pvs_efuse>;
>>> }
>>
>> Why do you need this node? It doesn't look like it corresponds to a
>> h/w block. It looks like you are just creating it to instantiate a
>> driver.
>>
>>> qfprom: qfprom at 700000 {
>>> compatible = "qcom,qfprom";
>>
>> Either this or...
>>
>>> reg = <0x00700000 0x1000>;
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> ranges;
>>> pvs_efuse: pvs {
>>
>> a compatible here should be specific enough so the OS can know what
>> the bits are.
>
> Infact the above "qcom,pvs" node is required mainly to act as a consumer
> for the nvmem data provider ("qcom,qfprom") (using nvmem-cells = <&pvs_efuse>)
> Then "qfprom" can be made to contain a "format_a" or "format_b" specific cell.
>
> So all that is needed is, nvmem-cells = <&pvs_efuse_phandle> needs to be available
> somewhere. The requirement is similar what is now done by "operating-points-v2-ti-cpu"
> and the ti-cpufreq.c. There "operating-points-v2-ti-cpu" node, contains the syscon
> register to read the efuse values. Similarly does defining a new
> "operating-points-v2-krait-cpu" which would contain the nvmem-cells property look ok ?
> This would avoid defining a new qcom,pvs node.
Yes, this seems reasonable.
>
> cpu at 0 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> reg = <0>;
> qcom,acc = <&acc0>;
> qcom,saw = <&saw0>;
> clocks = <&kraitcc 0>;
> clock-names = "cpu";
> cpu-supply = <&smb208_s2a>;
> operating-points-v2 = <&cpu_opp_table>;
> };
>
> cpu_opp_table: opp_table {
> compatible = "operating-points-v2-krait-cpu";
>
> nvmem-cells = <&pvs_efuse_format_a>;
> /*
> * Missing opp-shared property means CPUs switch DVFS states
> * independently.
> */
>
> opp-1400000000 {
> opp-hz = /bits/ 64 <1400000000>;
> opp-microvolt-speed0-pvs0-v0 = <1250000>;
> opp-microvolt-speed0-pvs1-v0 = <1175000>;
> opp-microvolt-speed0-pvs2-v0 = <1125000>;
> opp-microvolt-speed0-pvs3-v0 = <1050000>;
>
> };
> ...
> }
>
> qfprom: qfprom at 700000 {
> compatible = "qcom,qfprom";
> reg = <0x00700000 0x1000>;
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
> pvs_efuse_format_a: pvs {
> reg = <0xc0 0x8>;
> };
> }
>
> Regards,
> Sricharan
>
> --
> "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] pinctrl: spear: Delete an error message for a failed memory allocation in spear_pinctrl_probe()
From: SF Markus Elfring @ 2017-12-27 21:48 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 27 Dec 2017 22:44:04 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/pinctrl/spear/pinctrl-spear.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pinctrl/spear/pinctrl-spear.c b/drivers/pinctrl/spear/pinctrl-spear.c
index 4db52ba38d8d..efe79d3f7659 100644
--- a/drivers/pinctrl/spear/pinctrl-spear.c
+++ b/drivers/pinctrl/spear/pinctrl-spear.c
@@ -361,10 +361,8 @@ int spear_pinctrl_probe(struct platform_device *pdev,
return -ENODEV;
pmx = devm_kzalloc(&pdev->dev, sizeof(*pmx), GFP_KERNEL);
- if (!pmx) {
- dev_err(&pdev->dev, "Can't alloc spear_pmx\n");
+ if (!pmx)
return -ENOMEM;
- }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pmx->vbase = devm_ioremap_resource(&pdev->dev, res);
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Sakari Ailus @ 2017-12-27 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221104935.663812085b616935ca3046de@magewell.com>
Hi Yong,
On Thu, Dec 21, 2017 at 10:49:35AM +0800, Yong wrote:
> Hi,
>
> On Tue, 19 Dec 2017 13:53:28 +0200
> Sakari Ailus <sakari.ailus@iki.fi> wrote:
>
> > Hi Yong,
> >
> > On Thu, Jul 27, 2017 at 01:01:36PM +0800, Yong Deng wrote:
> > > Add binding documentation for Allwinner V3s CSI.
> > >
> > > Signed-off-by: Yong Deng <yong.deng@magewell.com>
> >
> > DT bindings should precede the driver.
>
> OK.
>
> >
> > > ---
> > > .../devicetree/bindings/media/sun6i-csi.txt | 49 ++++++++++++++++++++++
> > > 1 file changed, 49 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > new file mode 100644
> > > index 0000000..f8d83f6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > @@ -0,0 +1,49 @@
> > > +Allwinner V3s Camera Sensor Interface
> > > +------------------------------
> > > +
> > > +Required properties:
> > > + - compatible: value must be "allwinner,sun8i-v3s-csi"
> >
> > What are sun6i and sun8i? Is this device first present in sun6i SoCs,
> > whereas you have only defined bindings for sun8i?
>
> Yes, some sun6i SoCs has the almost same CSI module.
> There is only V3s on my hand. So, I only tested it on V3s. But
> some people work on the others.
Ack.
>
> >
> > > + - reg: base address and size of the memory-mapped region.
> > > + - interrupts: interrupt associated to this IP
> > > + - clocks: phandles to the clocks feeding the CSI
> > > + * ahb: the CSI interface clock
> > > + * mod: the CSI module clock
> > > + * ram: the CSI DRAM clock
> > > + - clock-names: the clock names mentioned above
> > > + - resets: phandles to the reset line driving the CSI
> > > +
> > > +- ports: A ports node with endpoint definitions as defined in
> > > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> >
> > Please document mandatory and optional endpoint properties relevant for the
> > hardware.
>
> I have added below commit in my v3:
> Currently, the driver only support the parallel interface. So, a single port
> node with one endpoint and parallel bus is supported.
Please specify the exact properties that are relevant for the hardware. No
references should be made to the driver, the bindings are entirely
separate.
Are the non-parallel (CSI-2?) and parallel bus on the same interface? If
yes, they should probably use different endpoints, if not, then different
ports.
You could document the other bus or omit it now altogether, in which case
you'd only detail the parallel bus properties here.
>
> >
> > > +
> > > +Example:
> > > +
> > > + csi1: csi at 01cb4000 {
> > > + compatible = "allwinner,sun8i-v3s-csi";
> > > + reg = <0x01cb4000 0x1000>;
> > > + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_CSI>,
> > > + <&ccu CLK_CSI1_SCLK>,
> > > + <&ccu CLK_DRAM_CSI>;
> > > + clock-names = "ahb", "mod", "ram";
> > > + resets = <&ccu RST_BUS_CSI>;
> > > +
> > > + port {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + /* Parallel bus endpoint */
> > > + csi1_ep: endpoint {
> > > + remote-endpoint = <&adv7611_ep>;
> > > + bus-width = <16>;
> > > + data-shift = <0>;
> > > +
> > > + /* If hsync-active/vsync-active are missing,
> > > + embedded BT.656 sync is used */
> > > + hsync-active = <0>; /* Active low */
> > > + vsync-active = <0>; /* Active low */
> > > + data-active = <1>; /* Active high */
> > > + pclk-sample = <1>; /* Rising */
> > > + };
> > > + };
> > > + };
> > > +
> >
> > --
> > Kind regards,
> >
> > Sakari Ailus
> > e-mail: sakari.ailus at iki.fi
>
>
> Thanks,
> Yong
--
Regards,
Sakari Ailus
e-mail: sakari.ailus at iki.fi
^ permalink raw reply
* v4.15: camera problems on n900
From: Pavel Machek @ 2017-12-27 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227211718.favif66afztygfje@kekkonen.localdomain>
1;2802;0cOn Wed 2017-12-27 23:17:19, Sakari Ailus wrote:
> On Wed, Dec 27, 2017 at 10:05:43PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > In v4.14, back camera on N900 works. On v4.15-rc1.. it works for few
> > seconds, but then I get repeated oopses.
> >
> > On v4.15-rc0.5 (commit ed30b147e1f6e396e70a52dbb6c7d66befedd786),
> > camera does not start.
> >
> > Any ideas what might be wrong there?
>
> What kind of oopses do you get?
They seemed to be in unrelated processes -> not useful for
debugging. I tried again, but this time it hangs, similar way to
-rc0.5. (That might be good news).
Does it work for you on N9?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171227/e7892f96/attachment.sig>
^ permalink raw reply
* [PATCH] pinctrl/spear/plgpio: Delete two error messages for a failed memory allocation in plgpio_probe()
From: SF Markus Elfring @ 2017-12-27 21:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 27 Dec 2017 22:34:28 +0100
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/pinctrl/spear/pinctrl-plgpio.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/spear/pinctrl-plgpio.c b/drivers/pinctrl/spear/pinctrl-plgpio.c
index 6a0ed8ab33b9..d2123e396b29 100644
--- a/drivers/pinctrl/spear/pinctrl-plgpio.c
+++ b/drivers/pinctrl/spear/pinctrl-plgpio.c
@@ -519,10 +519,8 @@ static int plgpio_probe(struct platform_device *pdev)
int ret, irq;
plgpio = devm_kzalloc(&pdev->dev, sizeof(*plgpio), GFP_KERNEL);
- if (!plgpio) {
- dev_err(&pdev->dev, "memory allocation fail\n");
+ if (!plgpio)
return -ENOMEM;
- }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
plgpio->base = devm_ioremap_resource(&pdev->dev, res);
@@ -544,10 +542,8 @@ static int plgpio_probe(struct platform_device *pdev)
sizeof(*plgpio->csave_regs) *
DIV_ROUND_UP(plgpio->chip.ngpio, MAX_GPIO_PER_REG),
GFP_KERNEL);
- if (!plgpio->csave_regs) {
- dev_err(&pdev->dev, "csave registers memory allocation fail\n");
+ if (!plgpio->csave_regs)
return -ENOMEM;
- }
#endif
platform_set_drvdata(pdev, plgpio);
--
2.15.1
^ permalink raw reply related
* v4.15: camera problems on n900
From: Sakari Ailus @ 2017-12-27 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227210543.GA19719@amd>
On Wed, Dec 27, 2017 at 10:05:43PM +0100, Pavel Machek wrote:
> Hi!
>
> In v4.14, back camera on N900 works. On v4.15-rc1.. it works for few
> seconds, but then I get repeated oopses.
>
> On v4.15-rc0.5 (commit ed30b147e1f6e396e70a52dbb6c7d66befedd786),
> camera does not start.
>
> Any ideas what might be wrong there?
What kind of oopses do you get?
--
Sakari Ailus
sakari.ailus at linux.intel.com
^ permalink raw reply
* [PATCH] Device tree binding for Avago APDS990X light sensor
From: Sakari Ailus @ 2017-12-27 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227200147.GB16799@amd>
On Wed, Dec 27, 2017 at 09:01:47PM +0100, Pavel Machek wrote:
> Hi!
>
> > > +Required properties:
> > > +- compatible: "avago,apds990x"
> > > +- reg: address on the I2C bus
> > > +- interrupts: external interrupt line number
> > > +- Vdd-supply: power supply for VDD
> > > +- Vled-supply: power supply for LEDA
> >
> > AFAIK the custom is to use lower case letters for regulator supplies.
> >
> > > +- ga: Glass attenuation
> > > +- cf1: Clear channel factor 1
> > > +- irf1: IR channel factor 1
> > > +- cf2: Clear channel factor 2
> > > +- irf2: IR channel factor 2
> > > +- df: Device factor
> > > +- pdrive: IR current, one of APDS_IRLED_CURR_XXXmA values
> > > +- ppcount: Proximity pulse count
> >
> > Are these device specific? If so, please add the vendor prefix to them.
>
> Well, whole binding is "vendor specific". Does it make sense to add
> prefix in such case?
Yes, it does. If you later find one or more of these are generic, you could
remove the vendor prefix. I doubt that'll happen though, these seem very
device specific parameters.
--
Sakari Ailus
sakari.ailus at linux.intel.com
^ permalink raw reply
* [PATCH] Device tree binding for Avago APDS990X light sensor
From: Sakari Ailus @ 2017-12-27 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a5d43a9-27f5-bdbd-780f-6c6bc47fb987@gmail.com>
On Wed, Dec 27, 2017 at 07:50:42PM +0100, Filip Matijevi? wrote:
> Hi Sakari,
>
> and thank you for your input - I've added a few comments below.
>
> On 12/27/2017 07:00 PM, Sakari Ailus wrote:
> > Hi Pavel,
> >
> > Thanks for the patch. Please see my comments below.
> >
> > On Wed, Dec 27, 2017 at 10:18:28AM +0100, Pavel Machek wrote:
> >> From: Filip Matijevi? <filip.matijevic.pz@gmail.com>
> >>
> >> This prepares binding for light sensor used in Nokia N9.
> >>
> >> Signed-off-by: Filip Matijevi? <filip.matijevic.pz@gmail.com>
> >> Signed-off-by: Pavel machek <pavel@ucw.cz>
> >>
> >> ---
> >>
> >> Patches to convert APDS990X driver to device tree and to switch to iio
> >> are available.
> >>
> >> diff --git a/Documentation/devicetree/bindings/misc/avago-apds990x.txt b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
> >> new file mode 100644
> >> index 0000000..e038146
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
> >> @@ -0,0 +1,39 @@
> >> +Avago APDS990X driver
> >> +
> >> +Required properties:
> >> +- compatible: "avago,apds990x"
> >> +- reg: address on the I2C bus
> >> +- interrupts: external interrupt line number
> >> +- Vdd-supply: power supply for VDD
> >> +- Vled-supply: power supply for LEDA
> >
> > AFAIK the custom is to use lower case letters for regulator supplies.
>
> I've just used the same notation as in current driver. Datasheet calls
> those VDD (with DD being in subscript) and LEDA. I see no problem in
> changing those to vdd-supply and vled-supply if no one else objects.
>
> >
> >> +- ga: Glass attenuation
> >> +- cf1: Clear channel factor 1
> >> +- irf1: IR channel factor 1
> >> +- cf2: Clear channel factor 2
> >> +- irf2: IR channel factor 2
> >> +- df: Device factor
> >> +- pdrive: IR current, one of APDS_IRLED_CURR_XXXmA values
> >> +- ppcount: Proximity pulse count
> >
> > Are these device specific? If so, please add the vendor prefix to them.
>
> AFAIK yes - same as before if no one else objects, these will be changed.
>
> >
> > I might not use short abbreviations such as "df" either. I wonder what
> > others think.
>
> These are also come from current driver - some of these comes from the
> datasheet itself, but not all. For example "ga" and "df" are in there
> (so I I would leave those alone), but "irf1" is called "B", "cf2" is
> called "C" and "irf2" is called "D" (I guess the missing "cf1" should be
> "A", but there is no such thing in the datasheet).
> IMHO using some other names might just add to the confusion.
Ack, datasheet names are fine.
You could also use a single property with all device specific coefficients
in a pre-defined order.
I don't have a strong opinion either way.
--
Regards,
Sakari Ailus
sakari.ailus at linux.intel.com
^ permalink raw reply
* v4.15: camera problems on n900
From: Pavel Machek @ 2017-12-27 21:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
In v4.14, back camera on N900 works. On v4.15-rc1.. it works for few
seconds, but then I get repeated oopses.
On v4.15-rc0.5 (commit ed30b147e1f6e396e70a52dbb6c7d66befedd786),
camera does not start.
Any ideas what might be wrong there?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171227/4a951706/attachment.sig>
^ permalink raw reply
* [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Ard Biesheuvel @ 2017-12-27 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFzygF6P3v5VxyBucZfn-tg58jeV6qwt0y7QGmmNiKYghQ@mail.gmail.com>
On 27 December 2017 at 20:13, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Dec 27, 2017 at 12:11 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>>
>> I tried to keep the generic patches generic, so perhaps I should just
>> put the arm64 vmlinux.lds.S change in a patch on its own?
>
> I guess it doesn't matter, but regardless of where it gets introduced
> I would like to see the explanation for where the heck that magical
> ".init.discard.text" comes from. It's definitely not obvious from the
> patches, and is presumably some odd arm64 special case.
>
This has to do with the EFI stub. x86 and ARM link it into the
decompressor, and so the code and data are not annotated as __init
(and doing so would involve modifying a lot of code). arm64 does not
have a decompressor, and so the EFI stub is linked into the kernel
proper. To make sure the code ends up in the .init segment, all
sections are prepended with .init at the object level, using objcopy.
Annoyingly, we need this because there is a single instance of a
special section that ends up in the EFI stub code: we build lib/sort.c
again as a EFI libstub object, and given that sort() is exported, we
end up with a ksymtab section in the EFI stub. The sort() thing has
caused issues before [0], so perhaps I should just clone sort.c into
drivers/firmware/efi/libstub and get rid of that hack.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29f9007b3182ab3f328a31da13e6b1c9072f7a95
^ permalink raw reply
* [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Linus Torvalds @ 2017-12-27 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-2NUzsakN2rcM_5fqD0ubr+6ZXSc+5sjZZPbU3wj_Xsg@mail.gmail.com>
On Wed, Dec 27, 2017 at 12:11 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> I tried to keep the generic patches generic, so perhaps I should just
> put the arm64 vmlinux.lds.S change in a patch on its own?
I guess it doesn't matter, but regardless of where it gets introduced
I would like to see the explanation for where the heck that magical
".init.discard.text" comes from. It's definitely not obvious from the
patches, and is presumably some odd arm64 special case.
Linus
^ permalink raw reply
* [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Ard Biesheuvel @ 2017-12-27 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFxqJqJq_7VUzBVTppgXFPc-8Ou55iLsZjp3fr6B2gRyTQ@mail.gmail.com>
On 27 December 2017 at 20:07, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Dec 27, 2017 at 12:50 AM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
>> index 52e611ab9a6c..fe752d365334 100644
>> --- a/include/linux/compiler.h
>> +++ b/include/linux/compiler.h
>> @@ -327,4 +327,15 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
>> compiletime_assert(__native_word(t), \
>> "Need native word sized stores/loads for atomicity.")
>>
>> +/*
>> + * Force the compiler to emit 'sym' as a symbol, so that we can reference
>> + * it from inline assembler. Necessary in case 'sym' could be inlined
>> + * otherwise, or eliminated entirely due to lack of references that are
>> + * visibile to the compiler.
>> + */
>> +#define __ADDRESSABLE(sym) \
>> + static void *__attribute__((section(".discard.text"), used)) \
>> + __PASTE(__discard_##sym, __LINE__)(void) \
>> + { return (void *)&sym; } \
>> +
>> #endif /* __LINUX_COMPILER_H */
>
> Isn't this logically the point where you should add the arm64
> vmlinux.lds.S change, and explain how ".discard.text" turns into
> ".init.discard.text" for some odd arm64 reason?
>
I tried to keep the generic patches generic, so perhaps I should just
put the arm64 vmlinux.lds.S change in a patch on its own?
^ permalink raw reply
* [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Linus Torvalds @ 2017-12-27 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227085033.22389-3-ard.biesheuvel@linaro.org>
On Wed, Dec 27, 2017 at 12:50 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 52e611ab9a6c..fe752d365334 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -327,4 +327,15 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
> compiletime_assert(__native_word(t), \
> "Need native word sized stores/loads for atomicity.")
>
> +/*
> + * Force the compiler to emit 'sym' as a symbol, so that we can reference
> + * it from inline assembler. Necessary in case 'sym' could be inlined
> + * otherwise, or eliminated entirely due to lack of references that are
> + * visibile to the compiler.
> + */
> +#define __ADDRESSABLE(sym) \
> + static void *__attribute__((section(".discard.text"), used)) \
> + __PASTE(__discard_##sym, __LINE__)(void) \
> + { return (void *)&sym; } \
> +
> #endif /* __LINUX_COMPILER_H */
Isn't this logically the point where you should add the arm64
vmlinux.lds.S change, and explain how ".discard.text" turns into
".init.discard.text" for some odd arm64 reason?
Linus
^ permalink raw reply
* [PATCH] Device tree binding for Avago APDS990X light sensor
From: Pavel Machek @ 2017-12-27 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227180000.6ejpbqmr736nqx5i@kekkonen.localdomain>
Hi!
> > +Required properties:
> > +- compatible: "avago,apds990x"
> > +- reg: address on the I2C bus
> > +- interrupts: external interrupt line number
> > +- Vdd-supply: power supply for VDD
> > +- Vled-supply: power supply for LEDA
>
> AFAIK the custom is to use lower case letters for regulator supplies.
>
> > +- ga: Glass attenuation
> > +- cf1: Clear channel factor 1
> > +- irf1: IR channel factor 1
> > +- cf2: Clear channel factor 2
> > +- irf2: IR channel factor 2
> > +- df: Device factor
> > +- pdrive: IR current, one of APDS_IRLED_CURR_XXXmA values
> > +- ppcount: Proximity pulse count
>
> Are these device specific? If so, please add the vendor prefix to them.
Well, whole binding is "vendor specific". Does it make sense to add
prefix in such case?
> I might not use short abbreviations such as "df" either. I wonder what
> others think.
I see.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171227/ff1c47f7/attachment.sig>
^ permalink raw reply
* [PATCH v6 1/8] arch: enable relative relocations for arm64, power, x86, s390 and x86
From: Ard Biesheuvel @ 2017-12-27 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFyJg=-PfrVV1kw_bqKKd9Uk+q2FS4pqPp-og_DDbhhaFw@mail.gmail.com>
On 27 December 2017 at 19:54, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Dec 27, 2017 at 12:50 AM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
>> index 7da3e5c366a0..49ae5b43fe2b 100644
>> --- a/arch/arm64/kernel/vmlinux.lds.S
>> +++ b/arch/arm64/kernel/vmlinux.lds.S
>> @@ -156,7 +156,7 @@ SECTIONS
>> CON_INITCALL
>> SECURITY_INITCALL
>> INIT_RAM_FS
>> - *(.init.rodata.* .init.bss) /* from the EFI stub */
>> + *(.init.rodata.* .init.bss .init.discard.*) /* EFI stub */
>> }
>> .exit.data : {
>> ARM_EXIT_KEEP(EXIT_DATA)
>
> Weren't you supposed to explain this part in the commit message?
>
Oops. Apologies, I indeed forgot to update the commit log.
> It isn't obvious why this is mixed up with the Kconfig changes, and
> somebody already asked about it. The commit message only talks about
> the Kconfig changes, and then suddenly there's that odd vmlinux.lds.S
> change in there...
>
Yeah. It doesn't make sense to respin right away for just that, so I
will give people some time to respond, and respin in a week or so.
^ permalink raw reply
* [PATCH v6 1/8] arch: enable relative relocations for arm64, power, x86, s390 and x86
From: Linus Torvalds @ 2017-12-27 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227085033.22389-2-ard.biesheuvel@linaro.org>
On Wed, Dec 27, 2017 at 12:50 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 7da3e5c366a0..49ae5b43fe2b 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -156,7 +156,7 @@ SECTIONS
> CON_INITCALL
> SECURITY_INITCALL
> INIT_RAM_FS
> - *(.init.rodata.* .init.bss) /* from the EFI stub */
> + *(.init.rodata.* .init.bss .init.discard.*) /* EFI stub */
> }
> .exit.data : {
> ARM_EXIT_KEEP(EXIT_DATA)
Weren't you supposed to explain this part in the commit message?
It isn't obvious why this is mixed up with the Kconfig changes, and
somebody already asked about it. The commit message only talks about
the Kconfig changes, and then suddenly there's that odd vmlinux.lds.S
change in there...
Linus
^ 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