* Re: [PATCHv1 1/6] net: dsa: Support internal phy on 'cpu' port
From: Sebastian Reichel @ 2018-01-03 15:07 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, Shawn Guo, Sascha Hauer,
Fabio Estevam, Ian Ray, Nandor Han, Rob Herring, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180103132128.GI15036-g2DYL2Zd6BY@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3868 bytes --]
Hi Andrew,
On Wed, Jan 03, 2018 at 02:21:28PM +0100, Andrew Lunn wrote:
> On Wed, Jan 03, 2018 at 01:26:04PM +0100, Sebastian Reichel wrote:
> > This adds support for enabling the internal phy for a 'cpu' port.
> > It has been tested on GE B850v3 and B650v3, which have a built-in
> > MV88E6240 switch connected to a PCIe based network card. Without
> > this patch the link does not come up and no traffic can be routed
> > through the switch.
> >
> > Signed-off-by: Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> > ---
> > net/dsa/port.c | 26 ++++++++++++++++++++++----
> > 1 file changed, 22 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/dsa/port.c b/net/dsa/port.c
> > index bb4be2679904..f99c1d34416c 100644
> > --- a/net/dsa/port.c
> > +++ b/net/dsa/port.c
> > @@ -282,6 +282,10 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
> > int mode;
> > int err;
> >
> > + mode = of_get_phy_mode(dn);
> > + if (mode < 0)
> > + mode = PHY_INTERFACE_MODE_NA;
> > +
> > if (of_phy_is_fixed_link(dn)) {
> > err = of_phy_register_fixed_link(dn);
> > if (err) {
> > @@ -292,10 +296,6 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
> > }
> >
> > phydev = of_phy_find_device(dn);
> > -
> > - mode = of_get_phy_mode(dn);
> > - if (mode < 0)
> > - mode = PHY_INTERFACE_MODE_NA;
> > phydev->interface = mode;
> >
> > genphy_config_init(phydev);
> > @@ -305,6 +305,24 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
> > ds->ops->adjust_link(ds, port, phydev);
> >
> > put_device(&phydev->mdio.dev);
> > + } else if (mode == PHY_INTERFACE_MODE_INTERNAL ||
> > + mode == PHY_INTERFACE_MODE_NA) {
>
> Hi Sebastian
>
> I understand what you are trying to do, i've got boards which also
> have back-to-back PHYs for the CPU port. These boards however have the
> strapping correct, so nothing needs doing in software.
What I have is a PCIe intel network card with phy, that is wired to a
mv88e6240 switch. The network card is exposed as normal network device,
so phy is enabled when the interface is brought up. The 'cpu' port
for mv88e6240 has an integrated phy, that needs to be enabled.
Your boards must be different, since mv88e6xxx is being reset during
probe(). So even if the 'cpu' phy was enabled before driver probe(),
it would be disabled afterwards.
> But the way you are doing it is wrong. PHY_INTERFACE_MODE_NA means
> something else has already setup the interface mode, leave it alone.
Ok, I assumed, that PHY_INTERFACE_MODE_NA means "no explicit
configuration found, use implicit configuration". E.g. for
mv88e6xxx the downstream ports are not configured in DT, but
their PHY is enabled.
> PHY_INTERFACE_MODE_INTERNAL means there is some other sort of bus
> between the MAC and the PHY than the normal MII.
>
> What you want to say is that there is a PHY on this port, and that you
> want to configure it to a given fixed configuration, probably 1000
> Full, with auto-neg turned off. This is something completely different
> to a fixed phy, which is used when there is no PHY at all.
That's why I put the new code into
if (of_phy_is_fixed_link(...)) {
<<< old code >>>
} else {
<<< new code >>>
}
I agree, that the function name dsa_port_fixed_link_register_of() is
a bit confusing with the added code. I actually added this to
dsa_cpu_dsa_setup() and with the rebase to current master it ended
up there.
> What state is the PHY in, if you don't have this patch? Is it powered
> down?
The phy is part of mv88e6240, which is being reset during probe.
So the phy is powered down and DSA is not functional except for
phy information of downstream ports. The PCIe network interface
does not detect a carrier.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net-next v2 0/4] net: mvpp2: 1000BaseX and 2000BaseX support
From: Antoine Tenart @ 2018-01-03 15:07 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-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 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 | 67 +++++++++++++++++++++++-----
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 +++++--
include/linux/phy/phy.h | 1 +
3 files changed, 72 insertions(+), 13 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH net-next v2 1/4] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2018-01-03 15:07 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-kernel
In-Reply-To: <20180103150750.12974-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 v2 2/4] phy: cp110-comphy: 2.5G SGMII mode
From: Antoine Tenart @ 2018-01-03 15:07 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-kernel
In-Reply-To: <20180103150750.12974-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 v2 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-03 15:07 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-kernel
In-Reply-To: <20180103150750.12974-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 257a6b99b4ca..d5e4bec98b2b 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_2500SGMII;
+ 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
* Re: [PATCH net-next 1/6] phy: add 2.5G SGMII mode to the phy_mode enum
From: Andrew Lunn @ 2018-01-03 15:08 UTC (permalink / raw)
To: Antoine Tenart
Cc: Florian Fainelli, thomas.petazzoni, ymarkman, jason, netdev,
linux-kernel, linux, kishon, nadavh, miquel.raynal,
gregory.clement, stefanc, mw, davem, linux-arm-kernel,
sebastian.hesselbarth
In-Reply-To: <20180103143541.GE21727@kwain>
> > >>> 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,
> > >>
> > >> There was a discussion maybe last month about adding 2.5G SGMII. I
> > >> would prefer 2500SGMII. Putting the number first makes it uniform with
> > >> the other defines, 1000BASEX, 25000BASEX, 10GKR.
> > >
> > > Good to know. I wasn't completely sure how to name this mode properly,
> > > but I'm fine with PHY_MODE_2500SGMII. I'll update the patches and send a
> > > v2 (without the dt part).
> >
> > And since you are respinning, please make sure you update phy_modes() in
> > the same header file as well as
> > Documentation/devicetree/bindings/net/ethernet.txt with the newly added
> > PHY interface mode.
>
> Actually it's a generic PHY mode I'm adding, not a network PHY mode.
> There's no phy_modes() function for generic PHYs (and this 2500BaseX
> mode already is supported in the network PHY modes).
Hi Antoine
Don't you need it in both include/linux/phy/phy.h and
include/linux/phy.h?
Andrew
^ permalink raw reply
* [PATCH] net: plip: Delete an error message for a failed memory allocation in plip_receive_packet()
From: SF Markus Elfring @ 2018-01-03 15:08 UTC (permalink / raw)
To: netdev, David S. Miller, Gustavo A. R. Silva; +Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 3 Jan 2018 16:00:23 +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/net/plip/plip.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
index feb92ecd1880..22f10d395d9c 100644
--- a/drivers/net/plip/plip.c
+++ b/drivers/net/plip/plip.c
@@ -632,10 +632,9 @@ plip_receive_packet(struct net_device *dev, struct net_local *nl,
}
/* Malloc up new buffer. */
rcv->skb = dev_alloc_skb(rcv->length.h + 2);
- if (rcv->skb == NULL) {
- printk(KERN_ERR "%s: Memory squeeze.\n", dev->name);
+ if (!rcv->skb)
return ERROR;
- }
+
skb_reserve(rcv->skb, 2); /* Align IP on 16 byte boundaries */
skb_put(rcv->skb,rcv->length.h);
rcv->skb->dev = dev;
--
2.15.1
^ permalink raw reply related
* [PATCH net-next v2 3/4] net: mvpp2: 1000baseX support
From: Antoine Tenart @ 2018-01-03 15:07 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-kernel
In-Reply-To: <20180103150750.12974-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
* Re: [PATCHv2] 3c59x: fix missing dma_mapping_error check and bad ring refill logic
From: Neil Horman @ 2018-01-03 15:13 UTC (permalink / raw)
To: David Miller; +Cc: nhorman, netdev, tedheadster, klassert
In-Reply-To: <20180103.095849.985156664792555290.davem@davemloft.net>
On Wed, Jan 03, 2018 at 09:58:49AM -0500, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Wed, 3 Jan 2018 09:44:15 -0500
>
> > A few spots in 3c59x missed calls to dma_mapping_error checks, casuing
> > WARN_ONS to trigger. Clean those up. While we're at it, refactor the
> > refill code a bit so that if skb allocation or dma mapping fails, we
> > recycle the existing buffer. This prevents holes in the rx ring, and
> > makes for much simpler logic
> >
> > Note: This is compile only tested. Ted, if you could run this and
> > confirm that it continues to work properly, I would appreciate it, as I
> > currently don't have access to this hardware
> >
> > Signed-off-by: Neil Horman <nhorman@redhat.com>
> > CC: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
> > CC: "David S. Miller" <davem@davemloft.net>
> > Reported-by: tedheadster@gmail.com
>
> See my other reply.
>
> Your RX handling must become more sophisticated.
>
Yes, I understood your previous reply.
> This is exactly what we tell driver authors to do. If you cannot allocate
> or DMA map a replacement RX buffer, you _MUST_ recycle the existing buffer
> back to the chip rather than pass it up to the stack.
>
Thats exactly what this patch does, instead of creating a second loop to
traverse all the emptied ring buffers, now I:
1) Pre-allocate a new skb when I know I'm going to receive the in-place skb
2) Map the skb into the appropriate dma device domain
3) If (1) and (2) succede, then I swap the newly allocate skb and dma address
with the old one and recieve the old into the network stack
4) If (1) or (2) fail, then I goto clear_complete, which leaves the old skb and
dma address in place, sets the buffer status back to 0 (indicating completion),
and write the new ring status back to the hardware
This is what you wanted, a pre-allocate and swap-if-successful, recycle-if-not
approach, rather than the leave-a-hole-in-the-ring approach that is there
currently, no? Or did I miss something else?
Neil
^ permalink raw reply
* Re: [PATCH v6 3/6] can: m_can: Add PM Runtime
From: Marc Kleine-Budde @ 2018-01-03 15:17 UTC (permalink / raw)
To: Faiz Abbas, wg, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, nsekhar, fcooper,
robh, Wenyou.Yang, sergei.shtylyov
In-Reply-To: <a45431f2-d262-39a1-9152-a2ff75560d21@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 2157 bytes --]
On 01/03/2018 04:06 PM, Faiz Abbas wrote:
> Hi,
>
> On Wednesday 03 January 2018 07:55 PM, Marc Kleine-Budde wrote:
>> On 01/03/2018 01:39 PM, Faiz Abbas wrote:
>>> On Tuesday 02 January 2018 09:37 PM, Marc Kleine-Budde wrote:
>>>> On 12/22/2017 02:31 PM, Faiz Abbas wrote:
>>>>> From: Franklin S Cooper Jr <fcooper@ti.com>
>>>>>
>>>>> Add support for PM Runtime which is the new way to handle managing clocks.
>>>>> However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk
>>>>> management approach in place.
>>>>
>>>> There is no PM_RUNTIME anymore since 464ed18ebdb6 ("PM: Eliminate
>>>> CONFIG_PM_RUNTIME")
>>>
>>> Ok. Will change the commit message.
>>>
>>>>
>>>> Have a look at the discussion: https://patchwork.kernel.org/patch/9436507/ :
>>>>
>>>>>> Well, I admit it would be nicer if drivers didn't have to worry about
>>>>>> whether or not CONFIG_PM was enabled. A slightly cleaner approach
>>>>>> from the one outlined above would have the probe routine do this:
>>>>>>
>>>>>> my_power_up(dev);
>>>>>> pm_runtime_set_active(dev);
>>>>>> pm_runtime_get_noresume(dev);
>>>>>> pm_runtime_enable(dev);
>>>
>>> This discussion seems to be about cases in which CONFIG_PM is not
>>> enabled. CONFIG_PM is always selected in the case of omap devices.
>>
>> Yes, but in the commit message you state that you need to support
>> systems that don't have PM_RUNTIME enabled. The only mainline SoCs I see
>> is "arch/arm/boot/dts/sama5d2.dtsi" so far. Please check if they select
>> CONFIG_PM, then we can make the driver much simpler.
>
> Actually the old clock management (for hclk which is the interface
> clock) is still required as mentioned in the cover letter. Will change
> the rather misleading description.
Ok. So you can use the code as discussed on
https://patchwork.kernel.org/patch/9436507/ ?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net] ethtool: do not print warning for applications using legacy API
From: Stephen Hemminger @ 2018-01-03 15:19 UTC (permalink / raw)
To: David Miller; +Cc: decot, netdev, linux-kernel
In-Reply-To: <20180102.215002.671661044941618104.davem@davemloft.net>
On Tue, 02 Jan 2018 21:50:02 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Fri, 29 Dec 2017 10:02:52 -0800
>
> > From: Stephen Hemminger <stephen@networkplumber.org>
> >
> > In kernel log ths message appears on every boot:
> > "warning: `NetworkChangeNo' uses legacy ethtool link settings API,
> > link modes are only partially reported"
> >
> > When ethtool link settings API changed, it started complaining about
> > usages of old API. Ironically, the original patch was from google but
> > the application using the legacy API is chrome.
>
> Chrome on my machine doesn't do this, FWIW...
I did report a bug to chrome team as well.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update my email address.
From: Joe Perches @ 2018-01-03 15:20 UTC (permalink / raw)
To: Pravin B Shelar, davem; +Cc: netdev
In-Reply-To: <1514952882-7040-1-git-send-email-pshelar@ovn.org>
On Tue, 2018-01-02 at 20:14 -0800, Pravin B Shelar wrote:
> Signed-off-by: Pravin Shelar <pshelar@ovn.org>
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 753799d..1704ed4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10152,7 +10152,7 @@ F: drivers/irqchip/irq-ompic.c
> F: drivers/irqchip/irq-or1k-*
>
> OPENVSWITCH
> -M: Pravin Shelar <pshelar@nicira.com>
> +M: Pravin B Shelar <pshelar@ovn.org>
If you are going to change the format of your name
by adding a middle initial, you should probably
also add a .mailmap entry.
> L: netdev@vger.kernel.org
> L: dev@openvswitch.org
> W: http://openvswitch.org
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: mvpp2: 2500baseX support
From: Andrew Lunn @ 2018-01-03 15:20 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, linux, mw, stefanc, ymarkman,
thomas.petazzoni, miquel.raynal, nadavh, netdev, linux-kernel
In-Reply-To: <20180103150750.12974-5-antoine.tenart@free-electrons.com>
> @@ -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_2500SGMII;
> + break;
I think this is the source of confusion with linux/phy.h and
linux/phy/phy.h.
What would PHY_INTERFACE_MODE_2500SGMII use?
Where is this all getting confused? Should the caller to
mvpp22_comphy_init() actually be passing PHY_INTERFACE_MODE_2500SGMII?
What is the MAC actually doing at this point? 2500BASEX or 2500SGMII?
At minimum there needs to be a comment that this is not a typ0,
otherwise you are going to get patches submitted to 'fix' this.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH 0/2] Kill redundant checks in the Renesas Ethernet drivers
From: David Miller @ 2018-01-03 15:21 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <20171231184134.684953583@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 31 Dec 2017 21:41:34 +0300
> Here's a set of 2 patches against DaveM's 'net-next.git' repo removing
> redundant checks in the driver probe() methods.
Series applied with the "disassembly" typo fixed.
^ permalink raw reply
* Re: [PATCH v5 02/39] openrisc: add ioremap_nocache declaration before include asm-generic/io.h and sync ioremap prototype with it.
From: Greentime Hu @ 2018-01-03 15:23 UTC (permalink / raw)
To: Stafford Horne
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial, Geert Uytterhoeven, Linus Walleij,
Mark Rutland, Greg KH
In-Reply-To: <20180103143803.GI32243@lianli.shorne-pla.net>
Hi, Stafford:
2018-01-03 22:38 GMT+08:00 Stafford Horne <shorne@gmail.com>:
> Hello,
>
> On Tue, Jan 02, 2018 at 04:24:34PM +0800, Greentime Hu wrote:
>> From: Greentime Hu <greentime@andestech.com>
>>
>> It will be built failed if commit id: d25ea659 is selected. This patch can fix this
>> build error.
>
> Ideally you would mention the commit description since the id is not yet
> usptream. I found it here (its 1 in this series):
>
> https://github.com/andestech/linux/commit/d25ea659
> asm-generic/io.h: move ioremap_nocache/ioremap_uc/ioremap_wc/ioremap_...
>
>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>> ---
>> arch/openrisc/include/asm/io.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h
>> index 7c69139..6709b28 100644
>> --- a/arch/openrisc/include/asm/io.h
>> +++ b/arch/openrisc/include/asm/io.h
>> @@ -29,13 +29,14 @@
>> #define PIO_OFFSET 0
>> #define PIO_MASK 0
>>
>> +#define ioremap_nocache ioremap_nocache
>> #include <asm-generic/io.h>
>
> Ideally we could move <asm-generic/io.h> include down to the bottom of the file
> and not have to do the defines like like this, it seems clumsy to me. In
> 'cris', 'nios2' and other architectures I can see they have the generic include
> at the bottom of the file and not need for #define's.
>
> I tried that but I get a lot of errors. Does your patch to asm-generic/io.h
> cause build issues for those architectures as well?
>
I got this email from kbuild test robot. I personally tried arm64/x86
before I sent the generic asm io.h patch.
I tried openrisc/sparc before I sent these v5 patches.
BUILD REGRESSION
tree/branch: https://github.com/0day-ci/linux
Greentime-Hu/Andes-nds32-Linux-Kernel/20171220-155937
branch HEAD: 9353e22157b9b69be3a3beea3553b5a105a45516 dt-bindings:
timer: Add andestech atcpit100 timer binding doc
Regressions in current branch:
arch/cris/mm/ioremap.c:79:15: note: in expansion of macro 'ioremap_nocache'
arch/openrisc/include/asm/io.h:38:29: error: conflicting types for 'ioremap'
arch/openrisc/include/asm/io.h:44:29: note: in expansion of macro
'ioremap_nocache'
arch/sparc/include/asm/io_32.h:129:15: error: conflicting types for 'ioremap'
arch/sparc/include/asm/io_32.h:130:0: warning: "ioremap_nocache" redefined
arch/sparc/include/asm/io_32.h:131:0: warning: "ioremap_wc" redefined
arch/sparc/include/asm/io_32.h:132:0: warning: "ioremap_wt" redefined
arch/sparc/kernel/ioport.c:124:15: error: conflicting types for 'ioremap'
arch/sparc/kernel/ioport.c:131:1: note: in expansion of macro 'EXPORT_SYMBOL'
drivers/net/ethernet/faraday/ftmac100.c:205:32: sparse: restricted
__le32 degrades to integer
drivers/net/ethernet/faraday/ftmac100.c:221:23: sparse: incorrect type
in assignment (different base types)
drivers/net/ethernet/faraday/ftmac100.c:251:16: sparse: cast to
restricted __le32
drivers/net/ethernet/faraday/ftmac100.c:262:23: sparse: invalid assignment: &=
drivers/net/ethernet/faraday/ftmac100.c:274:23: sparse: incorrect type
in assignment (different base types)
drivers/net/ethernet/faraday/ftmac100.c:288:18: warning: cast from
pointer to integer of different size [-Wpointer-to-int-cast]
drivers/net/ethernet/faraday/ftmac100.c:293:9: warning: cast to
pointer from integer of different size [-Wint-to-pointer-cast]
drivers/net/ethernet/faraday/ftmac100.c:534:23: sparse: incorrect type
in assignment (different base types)
include/asm-generic/io.h:864:15: error: conflicting types for 'ioremap'
include/asm-generic/io.h:865:25: error: conflicting types for 'ioremap_nocache'
include/asm-generic/io.h:866:29: note: in expansion of macro 'ioremap_nocache'
Error ids grouped by kconfigs:
recent_errors
├── cris-etrax-100lx_v2_defconfig
│ └── arch-cris-mm-ioremap.c:note:in-expansion-of-macro-ioremap_nocache
├── openrisc-or1ksim_defconfig
│ ├── arch-openrisc-include-asm-io.h:error:conflicting-types-for-ioremap
│ └── arch-openrisc-include-asm-io.h:note:in-expansion-of-macro-ioremap_nocache
├── sparc64-allyesconfig
│ ├── drivers-net-ethernet-faraday-ftmac100.c:warning:cast-from-pointer-to-integer-of-different-size
│ └── drivers-net-ethernet-faraday-ftmac100.c:warning:cast-to-pointer-from-integer-of-different-size
├── sparc-defconfig
│ ├── arch-sparc-include-asm-io_32.h:error:conflicting-types-for-ioremap
│ ├── arch-sparc-include-asm-io_32.h:warning:ioremap_nocache-redefined
│ ├── arch-sparc-include-asm-io_32.h:warning:ioremap_wc-redefined
│ ├── arch-sparc-include-asm-io_32.h:warning:ioremap_wt-redefined
│ ├── arch-sparc-kernel-ioport.c:error:conflicting-types-for-ioremap
│ └── arch-sparc-kernel-ioport.c:note:in-expansion-of-macro-EXPORT_SYMBOL
├── x86_64-allmodconfig
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:cast-to-restricted-__le32
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:incorrect-type-in-assignment-(different-base-types)-expected-unsigned-int-unsigned-rxdes0-got-restrunsigned-int-unsigned-rxdes0
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:incorrect-type-in-assignment-(different-base-types)-expected-unsigned-int-unsigned-rxdes2-got-restrunsigned-int-unsigned-rxdes2
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:incorrect-type-in-assignment-(different-base-types)-expected-unsigned-int-unsigned-txdes2-got-restrunsigned-int-unsigned-txdes2
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:invalid-assignment:
│ ├── drivers-net-ethernet-faraday-ftmac100.c:sparse:restricted-__le32-degrades-to-integer
│ ├── drivers-net-ethernet-faraday-ftmac100.c:warning:cast-from-pointer-to-integer-of-different-size
│ └── drivers-net-ethernet-faraday-ftmac100.c:warning:cast-to-pointer-from-integer-of-different-size
└── xtensa-allmodconfig
├── include-asm-generic-io.h:error:conflicting-types-for-ioremap
├── include-asm-generic-io.h:error:conflicting-types-for-ioremap_nocache
└── include-asm-generic-io.h:note:in-expansion-of-macro-ioremap_nocache
elapsed time: 359m
configs tested: 128
i386 tinyconfig
i386 randconfig-x016-201751
i386 randconfig-x011-201751
i386 randconfig-x014-201751
i386 randconfig-x017-201751
i386 randconfig-x019-201751
i386 randconfig-x018-201751
i386 randconfig-x010-201751
i386 randconfig-x013-201751
i386 randconfig-x015-201751
i386 randconfig-x012-201751
i386 randconfig-n0-201751
x86_64 randconfig-x003-201751
x86_64 randconfig-x002-201751
x86_64 randconfig-x006-201751
x86_64 randconfig-x007-201751
x86_64 randconfig-x000-201751
x86_64 randconfig-x005-201751
x86_64 randconfig-x004-201751
x86_64 randconfig-x009-201751
x86_64 randconfig-x008-201751
x86_64 randconfig-x001-201751
ia64 allnoconfig
ia64 defconfig
ia64 alldefconfig
i386 randconfig-i0-12180843
i386 randconfig-i1-12180843
x86_64 randconfig-x012-201751
x86_64 randconfig-x010-201751
x86_64 randconfig-x011-201751
x86_64 randconfig-x015-201751
x86_64 randconfig-x019-201751
x86_64 randconfig-x014-201751
x86_64 randconfig-x013-201751
x86_64 randconfig-x016-201751
x86_64 randconfig-x017-201751
x86_64 randconfig-x018-201751
i386 randconfig-a0-201751
i386 randconfig-a1-201751
c6x evmc6678_defconfig
xtensa common_defconfig
m32r m32104ut_defconfig
score spct6600_defconfig
xtensa iss_defconfig
m32r opsput_defconfig
m32r usrv_defconfig
m32r mappi3.smp_defconfig
nios2 10m50_defconfig
h8300 h8300h-sim_defconfig
cris etrax-100lx_v2_defconfig
blackfin TCM-BF537_defconfig
blackfin BF561-EZKIT-SMP_defconfig
blackfin BF533-EZKIT_defconfig
blackfin BF526-EZBRD_defconfig
i386 allnoconfig
i386 defconfig
i386 alldefconfig
i386 randconfig-s1-201751
i386 randconfig-s0-201751
mn10300 asb2364_defconfig
openrisc or1ksim_defconfig
um x86_64_defconfig
um i386_defconfig
frv defconfig
tile tilegx_defconfig
i386 allmodconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
sh titan_defconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh allnoconfig
i386 randconfig-x007-201751
i386 randconfig-x008-201751
i386 randconfig-x009-201751
i386 randconfig-x004-201751
i386 randconfig-x002-201751
i386 randconfig-x005-201751
i386 randconfig-x001-201751
i386 randconfig-x006-201751
i386 randconfig-x003-201751
i386 randconfig-x000-201751
m68k sun3_defconfig
m68k multi_defconfig
m68k m5475evb_defconfig
mips jz4740
mips malta_kvm_defconfig
mips 64r6el_defconfig
mips 32r2_defconfig
mips allnoconfig
mips fuloong2e_defconfig
mips txx9
sparc defconfig
sparc64 allnoconfig
sparc64 defconfig
x86_64 allmodconfig
parisc c3000_defconfig
parisc b180_defconfig
parisc defconfig
alpha defconfig
parisc allnoconfig
s390 default_defconfig
arm at91_dt_defconfig
arm allnoconfig
arm efm32_defconfig
arm64 defconfig
arm multi_v5_defconfig
arm sunxi_defconfig
arm64 allnoconfig
arm exynos_defconfig
arm shmobile_defconfig
arm multi_v7_defconfig
i386 randconfig-x072-201751
i386 randconfig-x078-201751
i386 randconfig-x071-201751
i386 randconfig-x077-201751
i386 randconfig-x070-201751
i386 randconfig-x074-201751
i386 randconfig-x073-201751
i386 randconfig-x079-201751
i386 randconfig-x076-201751
i386 randconfig-x075-201751
x86_64 acpi-redef
x86_64 allyesdebian
x86_64 nfsroot
x86_64 kexec
x86_64 rhel
x86_64 rhel-7.2
^ permalink raw reply
* Re: [PATCHv1 3/6] ARM: dts: imx6q-bx50v3: Add internal switch
From: Sebastian Reichel @ 2018-01-03 15:24 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Shawn Guo,
Sascha Hauer, Fabio Estevam, Ian Ray, Nandor Han, Rob Herring,
David S. Miller, netdev, devicetree, linux-kernel
In-Reply-To: <5c87f610-4927-faca-40a7-3f83e7f00ff7@cogentembedded.com>
[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]
Hi,
On Wed, Jan 03, 2018 at 05:48:42PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 01/03/2018 03:26 PM, Sebastian Reichel wrote:
>
> > B850v3, B650v3 and B450v3 all have a GPIO bit banged MDIO bus to
> > communicate with a Marvell switch. On all devices the switch is
> > connected to a PCI based network card, which needs to be referenced
> > by DT, so this also adds the common PCI root node.
> >
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> > ---
> > arch/arm/boot/dts/imx6q-bx50v3.dtsi | 37 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > index b915837bbb5f..689981e90e68 100644
> > --- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > +++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > @@ -92,6 +92,31 @@
> > mux-int-port = <1>;
> > mux-ext-port = <4>;
> > };
> > +
> > + aliases {
> > + mdio-gpio0 = &mdio0;
> > + };
> > +
> > + mdio0: mdio-gpio {
> > + compatible = "virtual,mdio-gpio";
> > + gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>, /* mdc */
> > + <&gpio2 7 GPIO_ACTIVE_HIGH>; /* mdio */
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + switch@0 {
> > + compatible = "marvell,mv88e6240";
>
> Why suddenly 2 extra tabs instead of 1?
will be fixed in PATCHv2.
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + switch_ports: ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > + };
> > };
> > &ecspi5 {
> [...]
>
> MBR, Sergei
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCHv2] 3c59x: fix missing dma_mapping_error check and bad ring refill logic
From: David Miller @ 2018-01-03 15:26 UTC (permalink / raw)
To: nhorman; +Cc: nhorman, netdev, tedheadster, klassert
In-Reply-To: <20180103151333.GB22129@hmswarspite.think-freely.org>
From: Neil Horman <nhorman@redhat.com>
Date: Wed, 3 Jan 2018 10:13:33 -0500
> Thats exactly what this patch does, instead of creating a second loop to
> traverse all the emptied ring buffers, now I:
>
> 1) Pre-allocate a new skb when I know I'm going to receive the in-place skb
> 2) Map the skb into the appropriate dma device domain
> 3) If (1) and (2) succede, then I swap the newly allocate skb and dma address
> with the old one and recieve the old into the network stack
> 4) If (1) or (2) fail, then I goto clear_complete, which leaves the old skb and
> dma address in place, sets the buffer status back to 0 (indicating completion),
> and write the new ring status back to the hardware
>
> This is what you wanted, a pre-allocate and swap-if-successful, recycle-if-not
> approach, rather than the leave-a-hole-in-the-ring approach that is there
> currently, no? Or did I miss something else?
I misread the code sorry, you're absolutely right.
I'll apply this patch, thanks Neil. :)
^ permalink raw reply
* Re: [PATCHv2] 3c59x: fix missing dma_mapping_error check and bad ring refill logic
From: David Miller @ 2018-01-03 15:28 UTC (permalink / raw)
To: nhorman; +Cc: nhorman, netdev, tedheadster, klassert
In-Reply-To: <20180103.102606.1453240990448791901.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 03 Jan 2018 10:26:06 -0500 (EST)
> From: Neil Horman <nhorman@redhat.com>
> Date: Wed, 3 Jan 2018 10:13:33 -0500
>
>> Thats exactly what this patch does, instead of creating a second loop to
>> traverse all the emptied ring buffers, now I:
>>
>> 1) Pre-allocate a new skb when I know I'm going to receive the in-place skb
>> 2) Map the skb into the appropriate dma device domain
>> 3) If (1) and (2) succede, then I swap the newly allocate skb and dma address
>> with the old one and recieve the old into the network stack
>> 4) If (1) or (2) fail, then I goto clear_complete, which leaves the old skb and
>> dma address in place, sets the buffer status back to 0 (indicating completion),
>> and write the new ring status back to the hardware
>>
>> This is what you wanted, a pre-allocate and swap-if-successful, recycle-if-not
>> approach, rather than the leave-a-hole-in-the-ring approach that is there
>> currently, no? Or did I miss something else?
>
> I misread the code sorry, you're absolutely right.
>
> I'll apply this patch, thanks Neil. :)
Hmmm, maybe we need a V3 after all :)
CC [M] drivers/net/ethernet/3com/3c59x.o
drivers/net/ethernet/3com/3c59x.c: In function ‘boomerang_rx’:
drivers/net/ethernet/3com/3c59x.c:2605:13: warning: unused variable ‘dma’ [-Wunused-variable]
dma_addr_t dma;
^~~
^ permalink raw reply
* [PATCH iproute2] devlink, rdma, tipc: properly define TARGETS without HAVE_MNL
From: Matthias Schiffer @ 2018-01-03 15:28 UTC (permalink / raw)
To: stephen; +Cc: netdev
Leaving a variable with a generic name such as TARGETS undefined would lead
to Make picking up its value from the environment. Avoid this by always
defining TARGETS in the Makefiles.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
---
I also noticed that many Makefiles refer to a variable LIBS, which is
neither defined nor documented to be passed from the outside. Is this
intentional?
devlink/Makefile | 4 +++-
rdma/Makefile | 4 +++-
tipc/Makefile | 4 +++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/devlink/Makefile b/devlink/Makefile
index 3afda65e..ace34c7b 100644
--- a/devlink/Makefile
+++ b/devlink/Makefile
@@ -1,10 +1,12 @@
# SPDX-License-Identifier: GPL-2.0
include ../config.mk
+TARGETS :=
+
ifeq ($(HAVE_MNL),y)
DEVLINKOBJ = devlink.o mnlg.o
-TARGETS=devlink
+TARGETS += devlink
CFLAGS += $(shell $(PKG_CONFIG) libmnl --cflags)
LDLIBS += $(shell $(PKG_CONFIG) libmnl --libs)
diff --git a/rdma/Makefile b/rdma/Makefile
index c8966bfd..454f25f8 100644
--- a/rdma/Makefile
+++ b/rdma/Makefile
@@ -1,11 +1,13 @@
# SPDX-License-Identifier: GPL-2.0
include ../config.mk
+TARGETS :=
+
ifeq ($(HAVE_MNL),y)
RDMA_OBJ = rdma.o utils.o dev.o link.o
-TARGETS=rdma
+TARGETS += rdma
endif
all: $(TARGETS) $(LIBS)
diff --git a/tipc/Makefile b/tipc/Makefile
index abd33ab0..fdb18d39 100644
--- a/tipc/Makefile
+++ b/tipc/Makefile
@@ -1,6 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
include ../config.mk
+TARGETS :=
+
ifeq ($(HAVE_MNL),y)
TIPCOBJ=bearer.o \
@@ -10,7 +12,7 @@ TIPCOBJ=bearer.o \
node.o socket.o \
peer.o tipc.o
-TARGETS=tipc
+TARGETS += tipc
endif
--
2.15.1
^ permalink raw reply related
* Re: [PATCH net-next 5/5] net: dsa: mv88e6xxx: Get mv88e6352 SERDES statistics
From: Vivien Didelot @ 2018-01-03 15:31 UTC (permalink / raw)
To: Andrew Lunn, David Miller
Cc: Florian Fainelli, netdev, Russell King, Andrew Lunn
In-Reply-To: <1514988562-20079-6-git-send-email-andrew@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> +struct mv88e6xxx_port {
> + u64 serdes_stats[2];
> +};
> +
> struct mv88e6xxx_chip {
> const struct mv88e6xxx_info *info;
>
> @@ -207,6 +211,9 @@ struct mv88e6xxx_chip {
> int irq;
> int device_irq;
> int watchdog_irq;
> +
> + /* Array of port structures. */
> + struct mv88e6xxx_port ports[DSA_MAX_PORTS];
> };
We are trying to get rid of these global DSA limitations for ports and
switches and support dynamic values. It wasn't mentioned but I assume
you couldn't use a zero length array here because we allocate before
detecting the switch model. Please define MV88E6XXX_MAX_PORTS to 16
instead, which is indeed a Marvell limitation for SOHO devices.
>
> struct mv88e6xxx_bus_ops {
> diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
> index d32522276fea..3b911b80da33 100644
> --- a/drivers/net/dsa/mv88e6xxx/serdes.c
> +++ b/drivers/net/dsa/mv88e6xxx/serdes.c
> @@ -87,6 +87,90 @@ int mv88e6352_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
> return 0;
> }
>
> +struct mv88e6352_serdes_hw_stat {
> + char string[ETH_GSTRING_LEN];
> + int sizeof_stat;
You can simply define size_t size.
> + int reg;
> +};
> +
> +static struct mv88e6352_serdes_hw_stat mv88e6352_serdes_hw_stats[] = {
> + { "serdes_fibre_rx_error", 16, 21 },
> + { "serdes_PRBS_error", 32, 24 },
> +};
<...>
> + BUILD_BUG_ON(ARRAY_SIZE(mv88e6352_serdes_hw_stats) >
> + ARRAY_SIZE(mv88e6xxx_port->serdes_stats));
> +
> + for (i = 0; i < ARRAY_SIZE(mv88e6352_serdes_hw_stats); i++) {
> + stat = &mv88e6352_serdes_hw_stats[i];
> + value = mv88e6352_serdes_get_stat(chip, stat);
extra space
> + mv88e6xxx_port->serdes_stats[i] += value;
> + data[i] = mv88e6xxx_port->serdes_stats[i];
> + }
> +}
^ permalink raw reply
* Re: [PATCH net] sctp: fix handling of ICMP Frag Needed for too small MTUs
From: Xin Long @ 2018-01-03 15:31 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: network dev, linux-sctp, Vlad Yasevich, Neil Horman
In-Reply-To: <20180103133513.GA727@localhost.localdomain>
On Wed, Jan 3, 2018 at 9:35 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Jan 03, 2018 at 03:31:00PM +0800, Xin Long wrote:
>> On Wed, Jan 3, 2018 at 5:44 AM, Marcelo Ricardo Leitner
>> <marcelo.leitner@gmail.com> wrote:
>> > syzbot reported a hang involving SCTP, on which it kept flooding dmesg
>> > with the message:
>> > [ 246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
>> > low, using default minimum of 512
>> >
>> > That happened because whenever SCTP hits an ICMP Frag Needed, it tries
>> > to adjust to the new MTU and triggers an immediate retransmission. But
>> > it didn't consider the fact that MTUs smaller than the SCTP minimum MTU
>> > allowed (512) would not cause the PMTU to change, and issued the
>> > retransmission anyway (thus leading to another ICMP Frag Needed, and so
>> > on).
>> >
>> > The fix is to disable Path MTU discovery for such transport and to skip
>> > the retransmission in such cases. By doing this, SCTP will do the
>> > backoff retransmissions as needed and will likely switch to another
>> > transport if available.
>> >
>> > See-also: https://lkml.org/lkml/2017/12/22/811
>> > Reported-by: syzbot <syzkaller@googlegroups.com>
>> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
>> > ---
>> > net/sctp/input.c | 5 ++++-
>> > net/sctp/transport.c | 2 ++
>> > 2 files changed, 6 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/net/sctp/input.c b/net/sctp/input.c
>> > index 621b5ca3fd1c17c3d7ef7bb1c7677ab98cebbe77..a24658c6f181e03d85f12dbe929c8bb4abaefcbd 100644
>> > --- a/net/sctp/input.c
>> > +++ b/net/sctp/input.c
>> > @@ -412,8 +412,11 @@ void sctp_icmp_frag_needed(struct sock *sk, struct sctp_association *asoc,
>> > * Needed will never be sent, but if a message was sent before
>> > * PMTU discovery was disabled that was larger than the PMTU, it
>> > * would not be fragmented, so it must be re-transmitted fragmented.
>> > + * If the new PMTU is invalid, we will keep getting ICMP Frag
>> > + * Needed. In this case, simply avoid the retransmit.
>> > */
>> > - sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD);
>> > + if (pmtu >= SCTP_DEFAULT_MINSEGMENT)
>> > + sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD);
>> > }
>> >
>> > void sctp_icmp_redirect(struct sock *sk, struct sctp_transport *t,
>> > diff --git a/net/sctp/transport.c b/net/sctp/transport.c
>> > index 1e5a22430cf56e40a6f323081beb97836b506384..fbd9fe25764d4d98f93c60a48eccefd9cc6b4165 100644
>> > --- a/net/sctp/transport.c
>> > +++ b/net/sctp/transport.c
>> > @@ -259,6 +259,8 @@ void sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu)
>> > * pmtu discovery on this transport.
>> > */
>> > t->pathmtu = SCTP_DEFAULT_MINSEGMENT;
>> > + t->param_flags = (t->param_flags & ~SPP_PMTUD) |
>> > + SPP_PMTUD_DISABLE;
>> It seems that once it hits here, this transport will have the minimum pmtu
>> forever, even after t->dst has expired. It means this tx path will not come
>> back to normal any more even when it gets a needfrag with reasonable
>> pmtu. is it too harsh to this transport ?
>
> That was the idea. That is what the comment above these lines is
> describing already. Though I missed 06ad391919b2 ("[SCTP] Don't
> disable PMTU discovery when mtu is small") and yes, too harsh.
>
>>
>> Another thing is on sctp_sendmsg, it also checks pmtu_pending that may
>> be set by needfrag, and goes to sctp_assoc_sync_pmtu to trigger this
>> warning again.
>
> That is true but that's not an issue, is it? We are not trying to get
> ride of the warning, instead we want to not cause a flood of
> bogus retransmissions (which led to the flood of warnings).
Right, I guess that the flood of warnings mostly came from that
sctp_retransmit() in sctp_icmp_frag_needed().
Otherwise, that transport should be marked as 'unreachable'
or the asoc should abort after so many times rtx.
>
> By not disabling PMTU discovery (as above) we will have such warning
> every now and then again for the same transport. We may add
> _ratelimited to it, that would help in the case of we have like a
> thousand transports suddenly being affected by such small MTU, but
> won't omit it completely.
If it can't be avoided only with the check 'pmtu >= SCTP_DEFAULT_MINSEGMENT',
yeah, _ratelimited looks good. :-)
>
> I'll spin a v2, thanks.
>
>>
>> > } else {
>> > t->pathmtu = pmtu;
>> > }
>> > --
>> > 2.14.3
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-03 15:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem, kishon, gregory.clement, linux, mw,
stefanc, ymarkman, thomas.petazzoni, miquel.raynal, nadavh,
netdev, linux-kernel
In-Reply-To: <20180103152036.GC3401@lunn.ch>
Hi Andrew,
On Wed, Jan 03, 2018 at 04:20:36PM +0100, Andrew Lunn wrote:
> > @@ -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_2500SGMII;
> > + break;
>
> I think this is the source of confusion with linux/phy.h and
> linux/phy/phy.h.
>
> What would PHY_INTERFACE_MODE_2500SGMII use?
>
> Where is this all getting confused? Should the caller to
> mvpp22_comphy_init() actually be passing PHY_INTERFACE_MODE_2500SGMII?
> What is the MAC actually doing at this point? 2500BASEX or 2500SGMII?
PHY_INTERFACE_MODE_2500BASEX is the PHY mode whereas PHY_MODE_2500SGMII
is the mode used by the common PHY driver (i.e. the one configuring the
serdes lanes).
There's no PHY_INTERFACE_MODE_2500SGMII mode.
> At minimum there needs to be a comment that this is not a typ0,
> otherwise you are going to get patches submitted to 'fix' this.
Sure, I can add a comment to state this function is a translation
between the net PHY mode and the generic PHY mode (it's a n-to-1
translation).
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [RFC PATCH net-next 03/19] ipv6: Clear nexthop flags upon netdev up
From: David Ahern @ 2018-01-03 15:32 UTC (permalink / raw)
To: Ido Schimmel; +Cc: Ido Schimmel, netdev, davem, roopa, nicolas.dichtel, mlxsw
In-Reply-To: <20180103074418.GA761@splinter>
On 1/3/18 12:44 AM, Ido Schimmel wrote:
>>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>>> index ed06b1190f05..b6405568ed7b 100644
>>> --- a/net/ipv6/addrconf.c
>>> +++ b/net/ipv6/addrconf.c
>>> @@ -3484,6 +3484,9 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
>>> if (run_pending)
>>> addrconf_dad_run(idev);
>>>
>>> + /* Device has an address by now */
>>> + rt6_sync_up(dev, RTNH_F_DEAD);
>>> +
>>
>> Seems like this should be in the NETDEV_UP section, say after
>> addrconf_permanent_addr.
>
> Unless the `keep_addr_on_down` sysctl is set, then at this stage the
> netdev doesn't have an IP address and we shouldn't clear the dead flag
> just yet.
>
> This is consistent with IPv4 that clears the dead flag from nexthops in
> a multipath route only if the nexthop device has an IP address. When the
> last IPv4 address is removed from a netdev all the routes using it are
> flushed and there's nothing to clear upon NETDEV_UP.
I have a bug about that IPv4 handling from the FRR team:
$ ip link add dummy1 type dummy
$ ip li set dummy1 up
$ ip route add 1.1.1.0/24 dev dummy1
$ ip addr add dev dummy1 2.2.2.1/24
$ ip ro ls | grep dummy1
1.1.1.0/24 dev dummy1 scope link
2.2.2.0/24 dev dummy1 proto kernel scope link src 2.2.2.1
$ ip addr del dev dummy1 2.2.2.1/24
$ ip ro ls | grep dummy1
<no outpu>
The 1.1.1.0/24 route was removed as well the 2.2.2.0 connected route.
^ permalink raw reply
* Re: [PATCH 0/2] Kill redundant checks in the Renesas Ethernet drivers
From: Sergei Shtylyov @ 2018-01-03 15:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-renesas-soc
In-Reply-To: <20180103.102155.745876383952341968.davem@davemloft.net>
Hello!
On 01/03/2018 06:21 PM, David Miller wrote:
> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Date: Sun, 31 Dec 2017 21:41:34 +0300
>
>> Here's a set of 2 patches against DaveM's 'net-next.git' repo removing
>> redundant checks in the driver probe() methods.
>
> Series applied with the "disassembly" typo fixed.
Thank you. Expect a fix for a 'sh_eth' bug added in 2013 soonish. :-)
MBR, Sergei
^ permalink raw reply
* Re: [PATCHv5 2/3] net: socionext: Add Synquacer NetSec driver
From: David Miller @ 2018-01-03 15:35 UTC (permalink / raw)
To: jassisinghbrar
Cc: netdev, devicetree, arnd.bergmann, andrew, ard.biesheuvel,
robh+dt, mark.rutland, masami.hiramatsu, jaswinder.singh
In-Reply-To: <1514783689-4352-1-git-send-email-jassisinghbrar@gmail.com>
From: jassisinghbrar@gmail.com
Date: Mon, 1 Jan 2018 10:44:49 +0530
> +#define DRING_TAIL(r) ((r)->tail)
> +
> +#define DRING_HEAD(r) ((r)->head)
These macros do not help readability at all.
> +#define MOVE_TAIL(r) do { \
> + if (++(r)->tail == DESC_NUM) \
> + (r)->tail = 0; \
> + } while (0)
> +
> +#define MOVE_HEAD(r) do { \
> + if (++(r)->head == DESC_NUM) \
> + (r)->head = 0; \
> + } while (0)
> +
> +#define JUMP_HEAD(r, n) do { \
> + int i; \
> + for (i = 0; i < (n); i++) \
> + MOVE_HEAD(r); \
> + } while (0)
Neither do these.
And JUMP_HEAD is so inefficient, it's a constant time calculation:
r->head += n;
if (r->head >= DESC_NUM)
r->head -= DESC_NUM;
All of this stuff can be done inline without all of these CPP macros
which are discouraged, have multiple evaluation issues, and decrease
the amount of type checking going on.
If you absolutely must have helpers, use static functions (without
the inline keyword, let the compiler device).
> +static inline int available_descs(struct netsec_desc_ring *r)
No inline functions in foo.c files, let the compiler device.
> +/*************************************************************/
> +/*********************** NETDEV_OPS **************************/
> +/*************************************************************/
Please, comments are not billboards or Star Wars openning sequences.
Simplify this, thank you.
> +
> +static void netsec_set_tx_de(struct netsec_priv *priv,
> + struct netsec_desc_ring *dring,
> + const struct netsec_tx_pkt_ctrl *tx_ctrl,
> + const struct netsec_desc *desc,
> + struct sk_buff *skb)
> +{
> + struct netsec_de *de;
> + int idx = DRING_HEAD(dring);
> + u32 attr;
Please order local variables from longest to shortest line.
Please audit your entire submission for this issue.
Thank you.
^ 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