* [PATCH net-next v1 01/18] net: ethtool: propagate get_settings error
From: David Decotigny @ 2015-01-27 1:35 UTC (permalink / raw)
To: David S. Miller, Ben Hutchings, Amir Vadai, linux-kernel, netdev,
linux-api
Cc: Eric Dumazet, Eugenia Emantayev, Or Gerlitz, Ido Shamay,
Joe Perches, Saeed Mahameed, Govindarajulu Varadarajan,
Venkata Duvvuru, Jeff Kirsher, Eyal Perry, Pravin B Shelar,
Ed Swierk, David Decotigny
In-Reply-To: <1422322574-6188-1-git-send-email-ddecotig@gmail.com>
From: David Decotigny <decot@googlers.com>
Signed-off-by: David Decotigny <decot@googlers.com>
---
net/core/ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 91f74f3..52efb7e 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -364,7 +364,7 @@ static int ethtool_get_settings(struct net_device *dev, void __user *useraddr)
if (copy_to_user(useraddr, &cmd, sizeof(cmd)))
return -EFAULT;
- return 0;
+ return err;
}
static int ethtool_set_settings(struct net_device *dev, void __user *useraddr)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next v1 02/18] net: usnic: remove unused call to ethtool_ops::get_settings
From: David Decotigny @ 2015-01-27 1:35 UTC (permalink / raw)
To: David S. Miller, Ben Hutchings, Amir Vadai, linux-kernel, netdev,
linux-api
Cc: Eric Dumazet, Eugenia Emantayev, Or Gerlitz, Ido Shamay,
Joe Perches, Saeed Mahameed, Govindarajulu Varadarajan,
Venkata Duvvuru, Jeff Kirsher, Eyal Perry, Pravin B Shelar,
Ed Swierk, David Decotigny
In-Reply-To: <1422322574-6188-1-git-send-email-ddecotig@gmail.com>
From: David Decotigny <decot@googlers.com>
Signed-off-by: David Decotigny <decot@googlers.com>
---
drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
index 53bd6a2..61337c7c 100644
--- a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
+++ b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
@@ -253,13 +253,11 @@ int usnic_ib_query_device(struct ib_device *ibdev,
struct usnic_ib_dev *us_ibdev = to_usdev(ibdev);
union ib_gid gid;
struct ethtool_drvinfo info;
- struct ethtool_cmd cmd;
int qp_per_vf;
usnic_dbg("\n");
mutex_lock(&us_ibdev->usdev_lock);
us_ibdev->netdev->ethtool_ops->get_drvinfo(us_ibdev->netdev, &info);
- us_ibdev->netdev->ethtool_ops->get_settings(us_ibdev->netdev, &cmd);
memset(props, 0, sizeof(*props));
usnic_mac_ip_to_gid(us_ibdev->ufdev->mac, us_ibdev->ufdev->inaddr,
&gid.raw[0]);
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next v1 09/18] net: macvlan: use __ethtool_get_ksettings
From: David Decotigny @ 2015-01-27 1:36 UTC (permalink / raw)
To: David S. Miller, Ben Hutchings, Amir Vadai, linux-kernel, netdev,
linux-api
Cc: Eric Dumazet, Eugenia Emantayev, Or Gerlitz, Ido Shamay,
Joe Perches, Saeed Mahameed, Govindarajulu Varadarajan,
Venkata Duvvuru, Jeff Kirsher, Eyal Perry, Pravin B Shelar,
Ed Swierk, David Decotigny
In-Reply-To: <1422322574-6188-1-git-send-email-ddecotig@gmail.com>
From: David Decotigny <decot@googlers.com>
Signed-off-by: David Decotigny <decot@googlers.com>
---
drivers/net/macvlan.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 1df38bd..ce934c3 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -925,12 +925,12 @@ static void macvlan_ethtool_get_drvinfo(struct net_device *dev,
strlcpy(drvinfo->version, "0.1", sizeof(drvinfo->version));
}
-static int macvlan_ethtool_get_settings(struct net_device *dev,
- struct ethtool_cmd *cmd)
+static int macvlan_ethtool_get_ksettings(struct net_device *dev,
+ struct ethtool_ksettings *cmd)
{
const struct macvlan_dev *vlan = netdev_priv(dev);
- return __ethtool_get_settings(vlan->lowerdev, cmd);
+ return __ethtool_get_ksettings(vlan->lowerdev, cmd);
}
static netdev_features_t macvlan_fix_features(struct net_device *dev,
@@ -998,7 +998,7 @@ static void macvlan_dev_netpoll_cleanup(struct net_device *dev)
static const struct ethtool_ops macvlan_ethtool_ops = {
.get_link = ethtool_op_get_link,
- .get_settings = macvlan_ethtool_get_settings,
+ .get_ksettings = macvlan_ethtool_get_ksettings,
.get_drvinfo = macvlan_ethtool_get_drvinfo,
};
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next v1 12/18] net: rdma: use __ethtool_get_ksettings
From: David Decotigny @ 2015-01-27 1:36 UTC (permalink / raw)
To: David S. Miller, Ben Hutchings, Amir Vadai, linux-kernel, netdev,
linux-api
Cc: Eric Dumazet, Eugenia Emantayev, Or Gerlitz, Ido Shamay,
Joe Perches, Saeed Mahameed, Govindarajulu Varadarajan,
Venkata Duvvuru, Jeff Kirsher, Eyal Perry, Pravin B Shelar,
Ed Swierk, David Decotigny
In-Reply-To: <1422322574-6188-1-git-send-email-ddecotig@gmail.com>
From: David Decotigny <decot@googlers.com>
Signed-off-by: David Decotigny <decot@googlers.com>
---
include/rdma/ib_addr.h | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/include/rdma/ib_addr.h b/include/rdma/ib_addr.h
index ce55906..782bb8c 100644
--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -241,24 +241,22 @@ static inline enum ib_mtu iboe_get_mtu(int mtu)
static inline int iboe_get_rate(struct net_device *dev)
{
- struct ethtool_cmd cmd;
- u32 speed;
+ struct ethtool_ksettings cmd;
int err;
rtnl_lock();
- err = __ethtool_get_settings(dev, &cmd);
+ err = __ethtool_get_ksettings(dev, &cmd);
rtnl_unlock();
if (err)
return IB_RATE_PORT_CURRENT;
- speed = ethtool_cmd_speed(&cmd);
- if (speed >= 40000)
+ if (cmd.parent.speed >= 40000)
return IB_RATE_40_GBPS;
- else if (speed >= 30000)
+ else if (cmd.parent.speed >= 30000)
return IB_RATE_30_GBPS;
- else if (speed >= 20000)
+ else if (cmd.parent.speed >= 20000)
return IB_RATE_20_GBPS;
- else if (speed >= 10000)
+ else if (cmd.parent.speed >= 10000)
return IB_RATE_10_GBPS;
else
return IB_RATE_PORT_CURRENT;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2015-01-27 2:00 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Nimrod Andy
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
arch/arm/boot/dts/imx6sx-sdb.dts between commit 9143e398a443 ("ARM:
dts: imx6sx: correct i.MX6sx sdb board enet phy address") from the net
tree and commit fc8347778017 ("ARM: dts: imx6sx: correct i.MX6sx sdb
board enet phy address") from the net-next tree.
I fixed it up (according to the commit comments, the version from the
net tree is newer, so I used that) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the arm-soc tree
From: Stephen Rothwell @ 2015-01-27 2:04 UTC (permalink / raw)
To: David Miller, netdev, Olof Johansson, Arnd Bergmann,
linux-arm-kernel
Cc: linux-next, linux-kernel, Roger Chen, Chris Zhong, Heiko Stuebner
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
arch/arm/boot/dts/rk3288.dtsi between commit eecfe981cecd ("ARM: dts:
rockchip: add RK3288 suspend support") from the arm-soc tree and commit
3d3fb74afc9b ("ARM: dts: rockchip: add gmac info for rk3288") from the
net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/boot/dts/rk3288.dtsi
index 2a878a35facc,910dcad2088a..000000000000
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@@ -734,24 -741,11 +750,29 @@@
bias-disable;
};
+ pcfg_pull_none_12ma: pcfg-pull-none-12ma {
+ bias-disable;
+ drive-strength = <12>;
+ };
+
+ sleep {
+ global_pwroff: global-pwroff {
+ rockchip,pins = <0 0 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ ddrio_pwroff: ddrio-pwroff {
+ rockchip,pins = <0 1 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ ddr0_retention: ddr0-retention {
+ rockchip,pins = <0 2 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ ddr1_retention: ddr1-retention {
+ rockchip,pins = <0 3 RK_FUNC_1 &pcfg_pull_up>;
+ };
+ };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins = <0 15 RK_FUNC_1 &pcfg_pull_none>,
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: [PATCH net-next 1/1] net: phy: unbind phy device from generic and specifical driver
From: fugang.duan @ 2015-01-27 2:27 UTC (permalink / raw)
To: Florian Fainelli, davem@davemloft.net
Cc: netdev@vger.kernel.org, s.hauer@pengutronix.de,
bhutchings@solarflare.com, stephen@networkplumber.org
In-Reply-To: <54C67D97.7080203@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com> Sent: Tuesday, January 27, 2015 1:47 AM
> To: Duan Fugang-B38611; davem@davemloft.net
> Cc: netdev@vger.kernel.org; s.hauer@pengutronix.de;
> bhutchings@solarflare.com; stephen@networkplumber.org
> Subject: Re: [PATCH net-next 1/1] net: phy: unbind phy device from
> generic and specifical driver
>
> On 26/01/15 09:14, Florian Fainelli wrote:
> > On 26/01/15 00:14, Fugang Duan wrote:
> >> The current .phy_detach() function only unbind generic phy driver,
> >> which causes specifical driver suspend/resume function still work like
> Atheros AT803X PHYs.
> >>
> >> For example:
> >> ifconfig eth0 down
> >> echo mem > /sys/power/status
> >>
> >> After eth0 interface down, driver call phy_detach to unbind phy
> >> driver, and then do suspend/resume operation,
> >> at803x_suspend()/at803x_resume() functions still get called that call
> >> mdio bus read/write function. When eth0 interface down, MAC driver may
> close all clocks and mdio bus cannot work. So the issue happens.
> >
> > I was just hitting this problem on Friday evening and was about to
> > submit a similar change. Thanks!
> >
> >>
> >> The patch can unbind generic and specifical driver.
> >>
> >> Signed-off-by: Fugang Duan <B38611@freescale.com>
> >
> > Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> > Tested-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Humm, this breaks a sequence of ifconfig down then up, the driver is
> removed, and we never get to probe it again, does this work for you using
> the FEC driver?
>
It works fine for FEC driver with below flow case.
echo enabled > /sys/class/tty/ttymxc0/power/wakeup
echo mem > /sys/power/state
ifconfig eth0 down
echo mem > /sys/power/state
ifconfig eth0 up
ping 10.192.242.204 //ping work fine
echo mem > /sys/power/state
...
I know the reason, the first fec driver use Atheros 8031 ethernet special phy driver, like:
fec 2188000.ethernet eth0: Freescale FEC PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=2188000.ethernet:01, irq=-1)
After down and up, fec use generic phy driver, but it still can work fine:
fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet:01, irq=-1)
After down and up, in here, phy driver only is initialized as generic phy driver.
int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
u32 flags, phy_interface_t interface)
{
...
/* Assume that if there is no driver, that it doesn't
* exist, and we should use the genphy driver.
*/
if (NULL == d->driver) {
if (phydev->is_c45)
d->driver = &genphy_driver[GENPHY_DRV_10G].driver;
else
d->driver = &genphy_driver[GENPHY_DRV_1G].driver;
err = d->driver->probe(d);
if (err >= 0)
err = device_bind_driver(d);
if (err)
return err;
}
...
}
So, I suggest to use your patches set.
Regards,
Andy
^ permalink raw reply
* RE: [PATCH net-next 1/4] net: phy: utilize phy_suspend and phy_resume
From: fugang.duan @ 2015-01-27 2:42 UTC (permalink / raw)
To: Florian Fainelli, netdev@vger.kernel.org
Cc: davem@davemloft.net, s.hauer@pengutronix.de
In-Reply-To: <1422318673-9418-2-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com> Sent: Tuesday, January 27, 2015 8:31 AM
> To: netdev@vger.kernel.org
> Cc: davem@davemloft.net; s.hauer@pengutronix.de; Duan Fugang-B38611;
> Florian Fainelli
> Subject: [PATCH net-next 1/4] net: phy: utilize phy_suspend and
> phy_resume
>
> phy_suspend and phy_resume are an abstraction on top of the PHY device
> driver suspend and resume callbacks, utilize those since they are the
> proper interface to suspending and resuming a PHY device.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/phy/mdio_bus.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 50051f271b10..20447741893a 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -465,7 +465,6 @@ static bool mdio_bus_phy_may_suspend(struct
> phy_device *phydev)
>
> static int mdio_bus_suspend(struct device *dev) {
> - struct phy_driver *phydrv = to_phy_driver(dev->driver);
> struct phy_device *phydev = to_phy_device(dev);
>
> /* We must stop the state machine manually, otherwise it stops out
> of @@ -479,19 +478,18 @@ static int mdio_bus_suspend(struct device *dev)
> if (!mdio_bus_phy_may_suspend(phydev))
> return 0;
>
> - return phydrv->suspend(phydev);
> + return phy_suspend(phydev);
> }
>
> static int mdio_bus_resume(struct device *dev) {
> - struct phy_driver *phydrv = to_phy_driver(dev->driver);
> struct phy_device *phydev = to_phy_device(dev);
> int ret;
>
> if (!mdio_bus_phy_may_suspend(phydev))
> goto no_resume;
>
> - ret = phydrv->resume(phydev);
> + ret = phy_resume(phydev);
> if (ret < 0)
> return ret;
>
> --
> 2.1.0
Test on i.MX6q sabresd board, works fine.
Acked-by: Fugang Duan <B38611@freescale.com>
Tested-by: Fugang Duan <B38611@freescale.com>
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] bonding: fix incorrect lacp mux state when agg not active
From: Jay Vosburgh @ 2015-01-27 2:42 UTC (permalink / raw)
To: Jonathan Toppins
Cc: Veaceslav Falico, Andy Gospodarek, netdev, Wilson Kok,
Andy Gospodarek
In-Reply-To: <1422253021-3798-4-git-send-email-jtoppins@cumulusnetworks.com>
Jonathan Toppins <jtoppins@cumulusnetworks.com> wrote:
>From: Wilson Kok <wkok@cumulusnetworks.com>
>
>This patch attempts to fix the following problems when an actor or
>partner's aggregator is not active:
> 1. a slave's lacp port state is marked as AD_STATE_SYNCHRONIZATION
> even if it is attached to an inactive aggregator. LACP advertises
> this state to the partner, making the partner think he can move
> into COLLECTING_DISTRIBUTING state even though this link will not
> pass traffic on the local side
>
> 2. a slave goes into COLLECTING_DISTRIBUTING state without checking
> if the aggregator is actually active
>
> 3. when in COLLECTING_DISTRIBUTING state, the partner parameters may
> change, e.g. the partner_oper_port_state.SYNCHRONIZATION. The
> local mux machine is not reacting to the change and continue to
> keep the slave and bond up
>
> 4. When bond slave leaves an inactive aggregator and joins an active
> aggregator, the actor oper port state need to update to SYNC state.
This is a lot of subtle changes for one patch, and it's
difficult to read the patch and figure out which of the above points
corresponds to which code change(s). I think this would have been
better as 2 or 3 patches, perhaps without the first blocks that merely
add debug statements.
In general, though, I believe I understand the problems and the
solutions, and the solutions appear sound.
For point 1, what it's doing is introducing an "ATTACHED-ish"
state, ultimately because the standard lacks the concept of "active" or
"inactive" aggregator. From my reading, when the port transitions to
ATTACHED state, 5.4.15 "Mux machine" requires that it set SYNC at that
time.
I understand why we would want to not enable SYNC for a port
that's a member of an aggregator that will not currently send or receive
traffic (is inactive in bonding-speak), but in my opinion we are
violating the standard and really should note that fact, and why we're
doing so, in the code.
Point 2 is similar to point 1 (although here we're not
transitioning from ATTACHED to COLLECTING / COLLECTING_DISTRIBUTING
when the partner's SYNC is true); same comment applies.
Points 3 and 4 look to be independent issues from points 1 and
2, and could be simple independent patches.
-J
>v2:
> * fix style issues in bond_3ad.c
>
>Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
>Reviewed-by: Nikolay Aleksandrov <nikolay@redhat.com>
>Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
>Signed-off-by: Jonathan Toppins <jtoppins@cumulusnetworks.com>
>---
> drivers/net/bonding/bond_3ad.c | 44 +++++++++++++++++++++++++++++++---------
> 1 file changed, 34 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>index 8baa87d..e3c96b2 100644
>--- a/drivers/net/bonding/bond_3ad.c
>+++ b/drivers/net/bonding/bond_3ad.c
>@@ -467,11 +467,14 @@ static void __record_pdu(struct lacpdu *lacpdu, struct port *port)
> /* set the partner sync. to on if the partner is sync,
> * and the port is matched
> */
>- if ((port->sm_vars & AD_PORT_MATCHED)
>- && (lacpdu->actor_state & AD_STATE_SYNCHRONIZATION))
>+ if ((port->sm_vars & AD_PORT_MATCHED) &&
>+ (lacpdu->actor_state & AD_STATE_SYNCHRONIZATION)) {
> partner->port_state |= AD_STATE_SYNCHRONIZATION;
>- else
>+ pr_debug("%s partner sync=1\n", port->slave->dev->name);
>+ } else {
> partner->port_state &= ~AD_STATE_SYNCHRONIZATION;
>+ pr_debug("%s partner sync=0\n", port->slave->dev->name);
>+ }
> }
> }
>
>@@ -726,6 +729,8 @@ static inline void __update_lacpdu_from_port(struct port *port)
> lacpdu->actor_port_priority = htons(port->actor_port_priority);
> lacpdu->actor_port = htons(port->actor_port_number);
> lacpdu->actor_state = port->actor_oper_port_state;
>+ pr_debug("update lacpdu: %s, actor port state %x\n",
>+ port->slave->dev->name, port->actor_oper_port_state);
>
> /* lacpdu->reserved_3_1 initialized
> * lacpdu->tlv_type_partner_info initialized
>@@ -898,7 +903,9 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> if ((port->sm_vars & AD_PORT_SELECTED) &&
> (port->partner_oper.port_state & AD_STATE_SYNCHRONIZATION) &&
> !__check_agg_selection_timer(port)) {
>- port->sm_mux_state = AD_MUX_COLLECTING_DISTRIBUTING;
>+ if (port->aggregator->is_active)
>+ port->sm_mux_state =
>+ AD_MUX_COLLECTING_DISTRIBUTING;
> } else if (!(port->sm_vars & AD_PORT_SELECTED) ||
> (port->sm_vars & AD_PORT_STANDBY)) {
> /* if UNSELECTED or STANDBY */
>@@ -910,12 +917,16 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> */
> __set_agg_ports_ready(port->aggregator, __agg_ports_are_ready(port->aggregator));
> port->sm_mux_state = AD_MUX_DETACHED;
>+ } else if (port->aggregator->is_active) {
>+ port->actor_oper_port_state |=
>+ AD_STATE_SYNCHRONIZATION;
> }
> break;
> case AD_MUX_COLLECTING_DISTRIBUTING:
> if (!(port->sm_vars & AD_PORT_SELECTED) ||
> (port->sm_vars & AD_PORT_STANDBY) ||
>- !(port->partner_oper.port_state & AD_STATE_SYNCHRONIZATION)) {
>+ !(port->partner_oper.port_state & AD_STATE_SYNCHRONIZATION) ||
>+ !(port->actor_oper_port_state & AD_STATE_SYNCHRONIZATION)) {
> port->sm_mux_state = AD_MUX_ATTACHED;
> } else {
> /* if port state hasn't changed make
>@@ -937,8 +948,10 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
>
> /* check if the state machine was changed */
> if (port->sm_mux_state != last_state) {
>- pr_debug("Mux Machine: Port=%d, Last State=%d, Curr State=%d\n",
>- port->actor_port_number, last_state,
>+ pr_debug("Mux Machine: Port=%d (%s), Last State=%d, Curr State=%d\n",
>+ port->actor_port_number,
>+ port->slave->dev->name,
>+ last_state,
> port->sm_mux_state);
> switch (port->sm_mux_state) {
> case AD_MUX_DETACHED:
>@@ -953,7 +966,12 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> port->sm_mux_timer_counter = __ad_timer_to_ticks(AD_WAIT_WHILE_TIMER, 0);
> break;
> case AD_MUX_ATTACHED:
>- port->actor_oper_port_state |= AD_STATE_SYNCHRONIZATION;
>+ if (port->aggregator->is_active)
>+ port->actor_oper_port_state |=
>+ AD_STATE_SYNCHRONIZATION;
>+ else
>+ port->actor_oper_port_state &=
>+ ~AD_STATE_SYNCHRONIZATION;
> port->actor_oper_port_state &= ~AD_STATE_COLLECTING;
> port->actor_oper_port_state &= ~AD_STATE_DISTRIBUTING;
> ad_disable_collecting_distributing(port,
>@@ -963,6 +981,7 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> case AD_MUX_COLLECTING_DISTRIBUTING:
> port->actor_oper_port_state |= AD_STATE_COLLECTING;
> port->actor_oper_port_state |= AD_STATE_DISTRIBUTING;
>+ port->actor_oper_port_state |= AD_STATE_SYNCHRONIZATION;
> ad_enable_collecting_distributing(port,
> update_slave_arr);
> port->ntt = true;
>@@ -1044,8 +1063,10 @@ static void ad_rx_machine(struct lacpdu *lacpdu, struct port *port)
>
> /* check if the State machine was changed or new lacpdu arrived */
> if ((port->sm_rx_state != last_state) || (lacpdu)) {
>- pr_debug("Rx Machine: Port=%d, Last State=%d, Curr State=%d\n",
>- port->actor_port_number, last_state,
>+ pr_debug("Rx Machine: Port=%d (%s), Last State=%d, Curr State=%d\n",
>+ port->actor_port_number,
>+ port->slave->dev->name,
>+ last_state,
> port->sm_rx_state);
> switch (port->sm_rx_state) {
> case AD_RX_INITIALIZE:
>@@ -1394,6 +1415,9 @@ static void ad_port_selection_logic(struct port *port, bool *update_slave_arr)
>
> aggregator = __get_first_agg(port);
> ad_agg_selection_logic(aggregator, update_slave_arr);
>+
>+ if (!port->aggregator->is_active)
>+ port->actor_oper_port_state &= ~AD_STATE_SYNCHRONIZATION;
> }
>
> /* Decide if "agg" is a better choice for the new active aggregator that
>--
>1.7.10.4
>
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: make allyesconfig i386 build failure with next-20150122 (caused by fb_agm1264k-fl driver)
From: Guenter Roeck @ 2015-01-27 2:42 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jim Davis, Stephen Rothwell, linux-next, linux-kernel, devel,
isdn, netdev, Thomas Petazzoni
In-Reply-To: <20150126224654.GA17166@kroah.com>
On 01/26/2015 02:46 PM, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2015 at 01:59:59PM -0800, Guenter Roeck wrote:
>> On Thu, Jan 22, 2015 at 12:10:33PM -0700, Jim Davis wrote:
>>> make ARCH=i386 allyesconfig fails with
>>>
>>> drivers/staging/built-in.o: In function `reset':
>>> (.text+0x2ae89d): multiple definition of `reset'
>>> drivers/isdn/built-in.o:(.text+0x185dc2): first defined here
>>> make[1]: *** [drivers/built-in.o] Error 1
>>
>> Culprit:
>>
>> commit b2ebd4be6fa1d2329b63531b044f9e25474981cb
>> Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Date: Wed Dec 31 10:11:10 2014 +0100
>>
>> staging: fbtft: add fb_agm1264k-fl driver
>>
>> A global function named 'reset' isn't really a good idea.
>>
>> Not that the global function with the same name in the isdn code
>> is better ;-).
>
> Agreed, the fbtft code is now fixed. Patches to fix the isdn code would
> be gladly accepted as well :)
>
Did you have a look into the isdn code ? It will need someone
with a lot of spare time to clean this code up.
Guenter
^ permalink raw reply
* RE: [PATCH net-next 3/4] net: phy: keep track of the PHY suspend state
From: fugang.duan @ 2015-01-27 2:43 UTC (permalink / raw)
To: Florian Fainelli, netdev@vger.kernel.org
Cc: davem@davemloft.net, s.hauer@pengutronix.de
In-Reply-To: <1422318673-9418-4-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com> Sent: Tuesday, January 27, 2015 8:31 AM
> To: netdev@vger.kernel.org
> Cc: davem@davemloft.net; s.hauer@pengutronix.de; Duan Fugang-B38611;
> Florian Fainelli
> Subject: [PATCH net-next 3/4] net: phy: keep track of the PHY suspend
> state
>
> In order to avoid double calls to phydev->drv->suspend and resume, keep
> track of whether the PHY has already been suspended as a consequence of a
> successful call to phy_suspend(). We will use this in our MDIO bus
> suspend/resume hooks to avoid a double suspend call.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/phy/phy_device.c | 22 ++++++++++++++++++----
> include/linux/phy.h | 2 ++
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 3fc91e89f5a5..c90cecc0fe15 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -699,6 +699,7 @@ int phy_suspend(struct phy_device *phydev) {
> struct phy_driver *phydrv = to_phy_driver(phydev->dev.driver);
> struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
> + int ret = 0;
>
> /* If the device has WOL enabled, we cannot suspend the PHY */
> phy_ethtool_get_wol(phydev, &wol);
> @@ -706,18 +707,31 @@ int phy_suspend(struct phy_device *phydev)
> return -EBUSY;
>
> if (phydrv->suspend)
> - return phydrv->suspend(phydev);
> - return 0;
> + ret = phydrv->suspend(phydev);
> +
> + if (ret)
> + return ret;
> +
> + phydev->suspended = true;
> +
> + return ret;
> }
> EXPORT_SYMBOL(phy_suspend);
>
> int phy_resume(struct phy_device *phydev) {
> struct phy_driver *phydrv = to_phy_driver(phydev->dev.driver);
> + int ret;
=> int ret = 0;
[...]
Regards,
Andy
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Ben Hutchings @ 2015-01-27 2:47 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: netdev, edumazet, mst, virtualization
In-Reply-To: <1422283026-27832-2-git-send-email-vyasevic@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1772 bytes --]
On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> If the IPv6 fragment id has not been set and we perform
> fragmentation due to UFO, select a new fragment id.
> When we store the fragment id into skb_shinfo, set the bit
> in the skb so we can re-use the selected id.
> This preserves the behavior of UFO packets generated on the
> host and solves the issue of id generation for packet sockets
> and tap/macvtap devices.
>
> This patch moves ipv6_select_ident() back in to the header file.
> It also provides the helper function that sets skb_shinfo() frag
> id and sets the bit.
>
> It also makes sure that we select the fragment id when doing
> just gso validation, since it's possible for the packet to
> come from an untrusted source (VM) and be forwarded through
> a UFO enabled device which will expect the fragment id.
>
> CC: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> ---
> include/linux/skbuff.h | 3 ++-
> include/net/ipv6.h | 2 ++
> net/ipv6/ip6_output.c | 4 ++--
> net/ipv6/output_core.c | 9 ++++++++-
> net/ipv6/udp_offload.c | 10 +++++++++-
> 5 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 85ab7d7..3ad5203 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -605,7 +605,8 @@ struct sk_buff {
> __u8 ipvs_property:1;
> __u8 inner_protocol_type:1;
> __u8 remcsum_offload:1;
> - /* 3 or 5 bit hole */
> + __u8 ufo_fragid_set:1;
[...]
Doesn't the flag belong in struct skb_shared_info, rather than struct
sk_buff? Otherwise this looks fine.
Ben.
--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 3/3] Revert "drivers/net: Disable UFO through virtio"
From: Ben Hutchings @ 2015-01-27 2:51 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: netdev, edumazet, mst, virtualization
In-Reply-To: <1422283026-27832-4-git-send-email-vyasevic@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 572 bytes --]
On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4.
>
> Now that UFO functionality can correctly track the fragment
> id has been selected and select a fragment id if necessary,
> we can re-enable UFO on tap/macvap and virtio devices.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
[...]
Acked-by: Ben Hutchings <ben@decadent.org.uk>
I think this is sensible even before your other patches.
Ben.
--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Please let me know if you need to print color box, display box and labels
From: Jinghao Printing - CHINA @ 2015-01-27 2:58 UTC (permalink / raw)
Hi, this is David Wu from Shanghai, China.
Please let me know if you need color box, display box, corrugated box,
label, hang tag etc.
I will send you the website.
Best regards,
David Wu
^ permalink raw reply
* [PATCH ipsec-next] xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host
From: Fan Du @ 2015-01-27 2:54 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, davem, netdev, fengyuleidian0615
structure like xfrm_usersa_info or xfrm_userpolicy_info
has different sizeof when compiled as 32bits and 64bits
due to not appending pack attribute in their definition.
This will result in broken SA and SP information when user
trying to configure them through netlink interface.
Inform user land about this situation instead of keeping
silent, the upper test scripts would behave accordingly.
Quotes from: http://marc.info/?l=linux-netdev&m=142226348715503&w=2
>
> Before a clean solution show up, I think it's better to warn user in some way
> like http://patchwork.ozlabs.org/patch/323842/ did. Otherwise, many people
> who stuck there will always spend time and try to fix this issue in whatever way.
Yes, this is the first thing we should do. I'm willing to accept a patch
Signed-off-by: Fan Du <fan.du@intel.com>
---
ChangeLog:
v2:
- Rebase with latest tree
---
net/xfrm/xfrm_user.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 8128594..f960bd9 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2419,6 +2419,11 @@ static int xfrm_user_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
const struct xfrm_link *link;
int type, err;
+#ifdef CONFIG_COMPAT
+ if (is_compat_task())
+ return -EPERM;
+#endif
+
type = nlh->nlmsg_type;
if (type > XFRM_MSG_MAX)
return -EINVAL;
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH net-next 4/4] net: phy: avoid suspending twice a PHY
From: fugang.duan @ 2015-01-27 2:44 UTC (permalink / raw)
To: Florian Fainelli, netdev@vger.kernel.org
Cc: davem@davemloft.net, s.hauer@pengutronix.de
In-Reply-To: <1422318673-9418-5-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com> Sent: Tuesday, January 27, 2015 8:31 AM
> To: netdev@vger.kernel.org
> Cc: davem@davemloft.net; s.hauer@pengutronix.de; Duan Fugang-B38611;
> Florian Fainelli
> Subject: [PATCH net-next 4/4] net: phy: avoid suspending twice a PHY
>
> As part of a call to ndo_close() a netdevice driver may call
> phy_disconnect() -> phy_detach() -> phy_suspend(), such that the PHY is
> suspsended at this point and a netdevice driver may clock gate the
> backing peripheral providing MDIO bus accessses as well.
>
> Update mdio_bus_phy_may_suspend() to return whether a PHY is allowed to
> be suspended and conversely resumed if and only if it was not previously
> suspended before while it is currently in detached (netdev pointer is
> NULL) state.
>
> This fixes bus errors seen during S2/S3 suspend/resume cycles for
> netdevice drivers such as GENET which clock gates the entire Ethernet MAC,
> including the MDIO bus block.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/phy/mdio_bus.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 20447741893a..095ef3fe369a 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -443,9 +443,13 @@ static bool mdio_bus_phy_may_suspend(struct
> phy_device *phydev)
> if (!drv || !phydrv->suspend)
> return false;
>
> - /* PHY not attached? May suspend. */
> + /* PHY not attached? May suspend if the PHY has not already been
> + * suspended as part of a prior call to phy_disconnect() ->
> + * phy_detach() -> phy_suspend() because the parent netdev might be
> the
> + * MDIO bus driver and clock gated at this point.
> + */
> if (!netdev)
> - return true;
> + return !phydev->suspended;
>
> /* Don't suspend PHY if the attched netdev parent may wakeup.
> * The parent may point to a PCI device, as in tg3 driver.
> --
> 2.1.0
Acked-by: Fugang Duan <B38611@freescale.com>
Tested-by: Fugang Duan <B38611@freescale.com>
^ permalink raw reply
* Re: ipv6: oops in datagram.c line 260
From: Chris Ruehl @ 2015-01-27 4:20 UTC (permalink / raw)
To: Steffen Klassert, Hannes Frederic Sowa; +Cc: netdev, davem
In-Reply-To: <20150126083512.GI13046@secunet.com>
On Monday, January 26, 2015 04:35 PM, Steffen Klassert wrote:
> On Tue, Jan 06, 2015 at 05:01:13PM +0100, Hannes Frederic Sowa wrote:
>> On Mi, 2014-12-24 at 21:42 +0800, Chris Ruehl wrote:
>>> [447604.244357] ipv6_pinfo is NULL
>>> [447604.273733] ------------[ cut here ]------------
>>> [447604.303628] WARNING: CPU: 7 PID: 0 at net/ipv6/datagram.c:262
>>> ipv6_local_error+0x16b/0x1a0()
>>> [[...]]
>>> [last unloaded: ipmi_si]
>>> [447605.087999] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.14.27 #11
>>> [447605.139687] Hardware name: Dell Inc. PowerEdge R420/0CN7CM, BIOS 2.3.3
>>> 07/10/2014
>>> [447605.242931] 0000000000000009 ffff8806172e3b48 ffffffff815ffd58 0000000000000000
>>> [447605.349130] ffff8806172e3b80 ffffffff81043c23 ffff8800a16322e8 ffff880037daa1c0
>>> [447605.459659] ffff88000b026800 0000000000000000 ffff880037daa4b8 ffff8806172e3b90
>>> [447605.576385] Call Trace:
>>> [447605.634243] <IRQ> [<ffffffff815ffd58>] dump_stack+0x45/0x56
>>> [447605.692870] [<ffffffff81043c23>] warn_slowpath_common+0x73/0x90
>>> [447605.751097] [<ffffffff81043cf5>] warn_slowpath_null+0x15/0x20
>>> [447605.808000] [<ffffffff815da6db>] ipv6_local_error+0x16b/0x1a0
>>> [447605.863821] [<ffffffff815e29d0>] xfrm6_local_error+0x60/0x90
>>> [447605.918493] [<ffffffff8150b485>] ? skb_dequeue+0x15/0x70
>>> [447605.971871] [<ffffffff815a6cc1>] xfrm_local_error+0x51/0x70
>>> [447606.024218] [<ffffffff8159ca15>] xfrm4_extract_output+0x75/0xb0
>>> [447606.075630] [<ffffffff815a6c5a>] xfrm_inner_extract_output+0x6a/0x80
>>> [447606.126055] [<ffffffff815e27a2>] xfrm6_prepare_output+0x12/0x60
>>> [447606.175310] [<ffffffff815a6ed0>] xfrm_output_resume+0x1f0/0x370
>>> [447606.223406] [<ffffffff8151a486>] ? skb_checksum_help+0x76/0x190
>>> [447606.270572] [<ffffffff815a709b>] xfrm_output+0x3b/0xf0
>>> [447606.316454] [<ffffffff815e2ae0>] ? xfrm6_extract_output+0xe0/0xe0
>>> [447606.361803] [<ffffffff815e2af7>] xfrm6_output_finish+0x17/0x20
>>> [447606.406053] [<ffffffff8159cad6>] xfrm4_output+0x46/0x80
>>> [447606.448694] [<ffffffff81550a80>] ip_local_out+0x20/0x30
>>> [447606.489952] [<ffffffff81550dd5>] ip_queue_xmit+0x135/0x3c0
>>> [447606.530017] [<ffffffff815672e1>] tcp_transmit_skb+0x461/0x8c0
>>> [447606.569362] [<ffffffff8156786e>] tcp_write_xmit+0x12e/0xb20
>>> [447606.607876] [<ffffffff815669ff>] ? tcp_current_mss+0x4f/0x70
>>> [447606.645723] [<ffffffff8156b320>] ? tcp_write_timer_handler+0x1b0/0x1b0
>>> [447606.682837] [<ffffffff81569487>] tcp_send_loss_probe+0x37/0x1f0
>>> [447606.719000] [<ffffffff8156b320>] ? tcp_write_timer_handler+0x1b0/0x1b0
>>> [447606.754537] [<ffffffff8156b1bb>] tcp_write_timer_handler+0x4b/0x1b0
>>> [447606.789266] [<ffffffff8156b320>] ? tcp_write_timer_handler+0x1b0/0x1b0
>>> [447606.823242] [<ffffffff8156b378>] tcp_write_timer+0x58/0x60
>>> [447606.856047] [<ffffffff8104e848>] call_timer_fn.isra.32+0x18/0x80
>>> [447606.888029] [<ffffffff8104ea1a>] run_timer_softirq+0x16a/0x200
>>> [447606.920224] [<ffffffff81047efc>] __do_softirq+0xec/0x250
>>> [447606.951850] [<ffffffff810482f5>] irq_exit+0xf5/0x100
>>> [447606.982665] [<ffffffff8102bc6f>] smp_apic_timer_interrupt+0x3f/0x50
>>> [447607.014382] [<ffffffff8160d98a>] apic_timer_interrupt+0x6a/0x70
>>> [447607.046175] <EOI> [<ffffffff8104f336>] ? get_next_timer_interrupt+0x1d6/0x250
>>> [447607.111311] [<ffffffff814d45a7>] ? cpuidle_enter_state+0x47/0xc0
>>> [447607.145850] [<ffffffff814d45a3>] ? cpuidle_enter_state+0x43/0xc0
>>> [447607.179625] [<ffffffff814d46b6>] cpuidle_idle_call+0x96/0x130
>>> [447607.213531] [<ffffffff8100b909>] arch_cpu_idle+0x9/0x20
>>> [447607.247052] [<ffffffff810925ba>] cpu_startup_entry+0xda/0x1d0
>>> [447607.280775] [<ffffffff81029d22>] start_secondary+0x212/0x2c0
>>> [447607.314555] ---[ end trace 6ff3826b6e4fdf67 ]---
>>>
>> Thanks for the report!
>>
>> xfrm6_output_finish unconditionally resets skb->protocol so we try to
>> dispatch to the IPv6 handler, even though tcp just sends an IPv4 packet.
>>
> Looks like we can postpone the setting of skb->protocol to the
> xfrm{4,6}_prepare_output() functions where we finally switch to
> outer mode.
>
> This has two implications:
>
> - We reset skb->protocol only for tunnel modes, should be ok.
>
> - This affects the xfrm_output_gso() codepath on interfamily
> tunnels. skb_mac_gso_segment() dispatches to the gso_segment()
> callback functions via skb->protocol. So we dispatch to
> the gso_segment() function of the outer mode what looks
> wrong to me. If we postpone the setting of skb->protocol
> to the xfrm{4,6}_prepare_output() we dispatch to inner mode
> here.
>
> Unfortunately I was not able to reproduce the problem on our test
> setup. Chris could you try if the the patch below fixes your
> problem?
>
> Subject: [PATCH RFC] xfrm: Fix local error reporting crash with interfamily
> tunnels
>
> We set the outer mode protocol too early. As a result, the
> local error handler might dispatch to the wrong address family
> and report the error to a wrong socket type. We fix this by
> seting the outer protocol to the skb after we accessed the
> inner mode for the last time, right before we do the atcual
> encapsulation where we switch finally to the outer mode.
>
> Reported-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
> net/ipv4/xfrm4_output.c | 2 +-
> net/ipv6/xfrm6_output.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
> index d5f6bd9..dab7381 100644
> --- a/net/ipv4/xfrm4_output.c
> +++ b/net/ipv4/xfrm4_output.c
> @@ -63,6 +63,7 @@ int xfrm4_prepare_output(struct xfrm_state *x, struct sk_buff *skb)
> return err;
>
> IPCB(skb)->flags |= IPSKB_XFRM_TUNNEL_SIZE;
> + skb->protocol = htons(ETH_P_IP);
>
> return x->outer_mode->output2(x, skb);
> }
> @@ -71,7 +72,6 @@ EXPORT_SYMBOL(xfrm4_prepare_output);
> int xfrm4_output_finish(struct sk_buff *skb)
> {
> memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
> - skb->protocol = htons(ETH_P_IP);
>
> #ifdef CONFIG_NETFILTER
> IPCB(skb)->flags |= IPSKB_XFRM_TRANSFORMED;
> diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
> index ca3f29b..010f8bd 100644
> --- a/net/ipv6/xfrm6_output.c
> +++ b/net/ipv6/xfrm6_output.c
> @@ -114,6 +114,7 @@ int xfrm6_prepare_output(struct xfrm_state *x, struct sk_buff *skb)
> return err;
>
> skb->ignore_df = 1;
> + skb->protocol = htons(ETH_P_IPV6);
>
> return x->outer_mode->output2(x, skb);
> }
> @@ -122,7 +123,6 @@ EXPORT_SYMBOL(xfrm6_prepare_output);
> int xfrm6_output_finish(struct sk_buff *skb)
> {
> memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
> - skb->protocol = htons(ETH_P_IPV6);
>
> #ifdef CONFIG_NETFILTER
> IP6CB(skb)->flags |= IP6SKB_XFRM_TRANSFORMED;
Steffen,
I will apply the patch and let you know. I keep my warning so we will
see if its hits it (hopefully not)
After apply the patch it can take a couple of day until we know it - see
below
root@sh1:/home/chris/kernel.d/linux-3.14.x# dmesg | grep WARNING
[447604.303628] WARNING: CPU: 7 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[1738973.489326] WARNING: CPU: 7 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[1738973.678786] WARNING: CPU: 6 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[2795700.233928] WARNING: CPU: 7 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[2805335.085370] WARNING: CPU: 0 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[2881267.252047] WARNING: CPU: 6 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[3042311.131764] WARNING: CPU: 7 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[3061315.974711] WARNING: CPU: 6 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[3070653.051669] WARNING: CPU: 6 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[3089456.783231] WARNING: CPU: 6 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[3098986.926483] WARNING: CPU: 6 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
[3118180.833934] WARNING: CPU: 6 PID: 0 at net/ipv6/datagram.c:262
ipv6_local_error+0x16b/0x1a0()
Thanks
Chris
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: David Ahern @ 2015-01-27 4:28 UTC (permalink / raw)
To: Jamal Hadi Salim, Simon Horman
Cc: John Fastabend, Thomas Graf, Jiri Pirko, Pablo Neira Ayuso,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <54C6326D.4090608@mojatatu.com>
On 1/26/15 5:26 AM, Jamal Hadi Salim wrote:
> On 01/26/15 03:26, Simon Horman wrote:
>> On Sat, Jan 24, 2015 at 08:01:52AM -0500, Jamal Hadi Salim wrote:
>>> Lets discuss at the meeting. I am just skimming these emails (the
>>> conference is chewing a lot of my time so i will mostly be absent).
>>> Sorry if i am not responding to some things.
>>
>> Is "the meeting" the Hardware Offloading BoF at Netdev 1.0?
>> For the benefit of others: https://www.netdev01.org/sessions/10
>>
>
> Yes, that is the plan. Sorry - the statement was addressed at the usual
> suspects who probably understood the context.
Will someone be taking copious notes or recording the sessions and then
making those available for those not in attendance?
David
^ permalink raw reply
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Andy Gospodarek @ 2015-01-27 4:56 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Stephen Hemminger, David Ahern, netdev
In-Reply-To: <1422015737.2824.8.camel@stressinduktion.org>
On Fri, Jan 23, 2015 at 01:22:17PM +0100, Hannes Frederic Sowa wrote:
> On Do, 2015-01-22 at 22:40 -0800, Stephen Hemminger wrote:
> > On Wed, 14 Jan 2015 12:17:19 -0700
> > David Ahern <dsahern@gmail.com> wrote:
> >
> > > Currently, ipv6 addresses are flushed when the interface is configured down:
> > >
> > > [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> > > [root@f20 ~]# ip addr show dev eth1
> > > 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
> > > link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> > > inet6 2000:11:1:1::1/64 scope global tentative
> > > valid_lft forever preferred_lft forever
> > > [root@f20 ~]# ip link set dev eth1 up
> > > [root@f20 ~]# ip link set dev eth1 down
> > > [root@f20 ~]# ip addr show dev eth1
> > > 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> > > link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> > >
> > > Add a new sysctl to make this behavior optional. Setting defaults to flush
> > > addresses to maintain backwards compatibility. When reset flushing is bypassed:
> > >
> > > [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
> > > [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> > > [root@f20 ~]# ip addr show dev eth1
> > > 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> > > link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> > > inet6 2000:11:1:1::1/64 scope global tentative
> > > valid_lft forever preferred_lft forever
> > > [root@f20 ~]# ip link set dev eth1 up
> > > [root@f20 ~]# ip link set dev eth1 down
> > > [root@f20 ~]# ip addr show dev eth1
> > > 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> > > link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> > > inet6 2000:11:1:1::1/64 scope global
> > > valid_lft forever preferred_lft forever
> > > inet6 fe80::4:11ff:fe22:3301/64 scope link
> > > valid_lft forever preferred_lft forever
> > >
> > > Suggested-by: Hannes Frederic Sowa <hannes@redhat.com>
> > > Signed-off-by: David Ahern <dsahern@gmail.com>
> > > Cc: Hannes Frederic Sowa <hannes@redhat.com>
> >
> > Would this break existing application expecting a particular semantic
> > by listening to netlink? What happens to packets received with the static
> > address when interface is down? With IPv4 Linux is mostly a weak host
> > model, and IPv6 somewhere in between.
>
> IPv6 is mostly a weak end model, too, but IFA_LINK addresses are used
> much more. So yes, it is somewhere in between.
>
> Addresses bound to interfaces which are currently down will work with
> IPv6 (in contrast to IPv4).
>
> > For vendors that control the application stack or have limited number
> > of services this would work fine, but what about RHEL?
>
> The new model is only enabled if the sysctl is set. I don't expect a lot
> of vendors or distributions switching anytime soon.
You are probably correct that many will not switch, but this sysctl
gives those who want to switch a nice option without having to carry
extra kernel patches. I like it.
I have been pondering a few different changes to interface address and
route behavior on both interface and link (gasp!) down and would like to
use sysctls to make those options available to those who are interested
without changing the current model.
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Andy Gospodarek @ 2015-01-27 4:58 UTC (permalink / raw)
To: David Ahern
Cc: Jamal Hadi Salim, Simon Horman, John Fastabend, Thomas Graf,
Jiri Pirko, Pablo Neira Ayuso, sfeldma, netdev, davem, gerlitz.or,
andy, ast
In-Reply-To: <54C71409.8060007@gmail.com>
On Mon, Jan 26, 2015 at 09:28:57PM -0700, David Ahern wrote:
> On 1/26/15 5:26 AM, Jamal Hadi Salim wrote:
> >On 01/26/15 03:26, Simon Horman wrote:
> >>On Sat, Jan 24, 2015 at 08:01:52AM -0500, Jamal Hadi Salim wrote:
> >>>Lets discuss at the meeting. I am just skimming these emails (the
> >>>conference is chewing a lot of my time so i will mostly be absent).
> >>>Sorry if i am not responding to some things.
> >>
> >>Is "the meeting" the Hardware Offloading BoF at Netdev 1.0?
> >>For the benefit of others: https://www.netdev01.org/sessions/10
> >>
> >
> >Yes, that is the plan. Sorry - the statement was addressed at the usual
> >suspects who probably understood the context.
>
> Will someone be taking copious notes or recording the sessions and then
> making those available for those not in attendance?
>
I'm not sure if the sessions will be recorded, but notes will be taken
for those wise enough not to come to Ottawa this time of year. :)
^ permalink raw reply
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Fu, Zhonghui @ 2015-01-27 5:35 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo
Cc: Sergei Shtylyov, brudley, Franky Lin, meuleman, linville,
pieterpg, hdegoede, wens, linux-wireless, brcm80211-dev-list,
netdev, linux-kernel@vger.kernel.org
In-Reply-To: <54C28E6B.8090408@broadcom.com>
On 2015/1/24 2:09, Arend van Spriel wrote:
> On 01/23/15 16:29, Kalle Valo wrote:
>> Arend van Spriel<arend@broadcom.com> writes:
>>
>>> On 01/22/15 14:54, Sergei Shtylyov wrote:
>>>> Hello.
>>>>
>>>> On 1/22/2015 4:49 PM, Kalle Valo wrote:
>>>>
>>>>>> > From 04d3fa673897ca4ccbea6c76836d0092dba2484a Mon Sep 17 00:00:00 2001
>>>>>> From: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>>>>>> Date: Tue, 20 Jan 2015 11:14:13 +0800
>>>>>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>>>>
>>>>>> WiFi chip has 2 SDIO functions, and PM core will trigger
>>>>>> twice suspend/resume operations for one WiFi chip to do
>>>>>> the same things. This patch avoid this case.
>>>>
>>>>>> Acked-by: Arend van Spriel<arend@broadcom.com>
>>>>>> Acked-by: Sergei Shtylyov<sergei.shtylyov@cogentembedded.com>
>>>>>> Acked-by: Kalle Valo<kvalo@codeaurora.org>
>>>>>> Signed-off-by: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>>>>
>>>>> I don't remember giving Acked-by to this (or for matter to anything for
>>>>> a long time). What about Sergei or Arend?
>>>>
>>>> I haven't ACK'ed this patch either.
>>>
>>> I did ACK the initial patch and felt it still valid for this 'V2' patch.
>>
>> Ok, thanks. So the patch is good, Zhonghui just needs to remove the two
>> acked-by lines.
>
> Indeed.
I have removed the two acked-by lines and sent the new patch in another mail.
Thanks,
Zhonghui
>
> Regards,
> Arend
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 3/4] net: phy: keep track of the PHY suspend state
From: Florian Fainelli @ 2015-01-27 5:55 UTC (permalink / raw)
To: fugang.duan@freescale.com
Cc: netdev@vger.kernel.org, davem@davemloft.net,
s.hauer@pengutronix.de
In-Reply-To: <BLUPR03MB3730BDE319193713AC9EA27F5320@BLUPR03MB373.namprd03.prod.outlook.com>
2015-01-26 18:43 GMT-08:00 fugang.duan@freescale.com
<fugang.duan@freescale.com>:
> From: Florian Fainelli <f.fainelli@gmail.com> Sent: Tuesday, January 27, 2015 8:31 AM
>> To: netdev@vger.kernel.org
>> Cc: davem@davemloft.net; s.hauer@pengutronix.de; Duan Fugang-B38611;
>> Florian Fainelli
>> Subject: [PATCH net-next 3/4] net: phy: keep track of the PHY suspend
>> state
>>
>> In order to avoid double calls to phydev->drv->suspend and resume, keep
>> track of whether the PHY has already been suspended as a consequence of a
>> successful call to phy_suspend(). We will use this in our MDIO bus
>> suspend/resume hooks to avoid a double suspend call.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/net/phy/phy_device.c | 22 ++++++++++++++++++----
>> include/linux/phy.h | 2 ++
>> 2 files changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index 3fc91e89f5a5..c90cecc0fe15 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -699,6 +699,7 @@ int phy_suspend(struct phy_device *phydev) {
>> struct phy_driver *phydrv = to_phy_driver(phydev->dev.driver);
>> struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
>> + int ret = 0;
>>
>> /* If the device has WOL enabled, we cannot suspend the PHY */
>> phy_ethtool_get_wol(phydev, &wol);
>> @@ -706,18 +707,31 @@ int phy_suspend(struct phy_device *phydev)
>> return -EBUSY;
>>
>> if (phydrv->suspend)
>> - return phydrv->suspend(phydev);
>> - return 0;
>> + ret = phydrv->suspend(phydev);
>> +
>> + if (ret)
>> + return ret;
>> +
>> + phydev->suspended = true;
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(phy_suspend);
>>
>> int phy_resume(struct phy_device *phydev) {
>> struct phy_driver *phydrv = to_phy_driver(phydev->dev.driver);
>> + int ret;
>
> => int ret = 0;
Good catch, let me re-submit with your tags, thanks for testing!
--
Florian
^ permalink raw reply
* BPF backend has landed in LLVM
From: Alexei Starovoitov @ 2015-01-27 5:56 UTC (permalink / raw)
To: Network Development, LKML
Cc: Brendan Gregg, Daniel Borkmann, Hannes Frederic Sowa,
Steven Rostedt, Ingo Molnar, David S. Miller, Jovi Zhangwei,
Jesse Gross, Thomas Graf
llvm trunk now has BPF backend:
https://twitter.com/llvmweekly/status/559076464973594625
It's the one used to build samples/bpf/*_kern.c examples.
Compiler just emits extended BPF instructions. It's not
aware whether they are used for tracing or networking,
or how they're loaded into the kernel.
the backend has 'experimental' status,
meaning that it doesn't get configured by default and
one needs to use --enable-experimental-targets=bpf
to build it.
todo list:
- promote it from 'experimental' status by
the time llvm 3.7 is released :)
- write front-end for tracing via mcjit api
llvm will be used as a library: parsing of some
tracing language, codegen, loading of bpf via
syscall will be done from one process
- tighten accepted IR and improve error reporting
(currently it can compile too much of C that
kernel will later reject, so need to make strict)
- test/fix what it emits on arm and other archs
(all little endian should work as-is, big-endian
might need some fixes)
- support 32-bit subregisters
If anyone has spare cycles to help out, it
would be great.
Thanks
^ permalink raw reply
* [PATCH net-next v2 0/4] net: phy: prevent double suspend
From: Florian Fainelli @ 2015-01-27 6:05 UTC (permalink / raw)
To: netdev; +Cc: davem, s.hauer, b38611, Florian Fainelli
Hi David, Fugang,
This patch series addresses a problem that Fugang and I observed on different
platforms where a given PHY device might end-up being suspended twice.
Once as part of the call from ndo_open() all the way down to phy_detach() and
phy_suspend() and a second time when the generic platform device/driver
suspend/resume callbacks are called in drivers/net/phy/mdio_bus.c.
Thanks to Fugang for giving this a quick try on i.MX6/FEC and reporting
positive test results!
Florian Fainelli (4):
net: phy: utilize phy_suspend and phy_resume
net: phy: document has_fixups field
net: phy: keep track of the PHY suspend state
net: phy: avoid suspending twice a PHY
drivers/net/phy/mdio_bus.c | 14 ++++++++------
drivers/net/phy/phy_device.c | 22 ++++++++++++++++++----
include/linux/phy.h | 3 +++
3 files changed, 29 insertions(+), 10 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net-next v2 1/4] net: phy: utilize phy_suspend and phy_resume
From: Florian Fainelli @ 2015-01-27 6:05 UTC (permalink / raw)
To: netdev; +Cc: davem, s.hauer, b38611, Florian Fainelli
In-Reply-To: <1422338740-18418-1-git-send-email-f.fainelli@gmail.com>
phy_suspend and phy_resume are an abstraction on top of the PHY device
driver suspend and resume callbacks, utilize those since they are the
proper interface to suspending and resuming a PHY device.
Acked-by: Fugang Duan <B38611@freescale.com>
Tested-by: Fugang Duan <B38611@freescale.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- added Fugang's tags
drivers/net/phy/mdio_bus.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 50051f271b10..20447741893a 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -465,7 +465,6 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
static int mdio_bus_suspend(struct device *dev)
{
- struct phy_driver *phydrv = to_phy_driver(dev->driver);
struct phy_device *phydev = to_phy_device(dev);
/* We must stop the state machine manually, otherwise it stops out of
@@ -479,19 +478,18 @@ static int mdio_bus_suspend(struct device *dev)
if (!mdio_bus_phy_may_suspend(phydev))
return 0;
- return phydrv->suspend(phydev);
+ return phy_suspend(phydev);
}
static int mdio_bus_resume(struct device *dev)
{
- struct phy_driver *phydrv = to_phy_driver(dev->driver);
struct phy_device *phydev = to_phy_device(dev);
int ret;
if (!mdio_bus_phy_may_suspend(phydev))
goto no_resume;
- ret = phydrv->resume(phydev);
+ ret = phy_resume(phydev);
if (ret < 0)
return ret;
--
2.1.0
^ permalink raw reply related
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