* RE: [PATCH 3/3] fec: move to new ethtool api {get|set}_link_ksettings
From: Fugang Duan @ 2016-04-15 2:38 UTC (permalink / raw)
To: Philippe Reynes, davem@davemloft.net, decot@googlers.com,
f.fainelli@gmail.com
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <1460673301-10599-4-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com> Sent: Friday, April 15, 2016 6:35 AM
> To: davem@davemloft.net; decot@googlers.com; f.fainelli@gmail.com; Fugang
> Duan <fugang.duan@nxp.com>
> Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org; Philippe Reynes
> <tremyfr@gmail.com>
> Subject: [PATCH 3/3] fec: move to new ethtool api {get|set}_link_ksettings
>
> The ethtool api {get|set}_settings is deprecated.
> We move the fec driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 08243c2..bfa10c3 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2058,8 +2058,8 @@ static void fec_enet_mii_remove(struct
> fec_enet_private *fep)
> }
> }
>
> -static int fec_enet_get_settings(struct net_device *ndev,
> - struct ethtool_cmd *cmd)
> +static int fec_enet_get_link_ksettings(struct net_device *ndev,
> + struct ethtool_link_ksettings *cmd)
> {
> struct fec_enet_private *fep = netdev_priv(ndev);
> struct phy_device *phydev = fep->phy_dev; @@ -2067,11 +2067,11
> @@ static int fec_enet_get_settings(struct net_device *ndev,
> if (!phydev)
> return -ENODEV;
>
> - return phy_ethtool_gset(phydev, cmd);
> + return phy_ethtool_ksettings_get(phydev, cmd);
> }
>
> -static int fec_enet_set_settings(struct net_device *ndev,
> - struct ethtool_cmd *cmd)
> +static int fec_enet_set_link_ksettings(struct net_device *ndev,
> + const struct ethtool_link_ksettings *cmd)
> {
> struct fec_enet_private *fep = netdev_priv(ndev);
> struct phy_device *phydev = fep->phy_dev; @@ -2079,7 +2079,7 @@
> static int fec_enet_set_settings(struct net_device *ndev,
> if (!phydev)
> return -ENODEV;
>
> - return phy_ethtool_sset(phydev, cmd);
> + return phy_ethtool_ksettings_set(phydev, cmd);
> }
>
> static void fec_enet_get_drvinfo(struct net_device *ndev, @@ -2562,8
> +2562,6 @@ fec_enet_set_wol(struct net_device *ndev, struct
> ethtool_wolinfo *wol) }
>
> static const struct ethtool_ops fec_enet_ethtool_ops = {
> - .get_settings = fec_enet_get_settings,
> - .set_settings = fec_enet_set_settings,
> .get_drvinfo = fec_enet_get_drvinfo,
> .get_regs_len = fec_enet_get_regs_len,
> .get_regs = fec_enet_get_regs,
> @@ -2583,6 +2581,8 @@ static const struct ethtool_ops fec_enet_ethtool_ops
> = {
> .set_tunable = fec_enet_set_tunable,
> .get_wol = fec_enet_get_wol,
> .set_wol = fec_enet_set_wol,
> + .get_link_ksettings = fec_enet_get_link_ksettings,
> + .set_link_ksettings = fec_enet_set_link_ksettings,
> };
>
> static int fec_enet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
> --
> 1.7.4.4
Acked-by: Fugang Duan <fugang.duan@nxp.com>
^ permalink raw reply
* [PATCH net-next v2 6/6] fjes: Update fjes driver version : 1.1
From: Taku Izumi @ 2016-04-15 2:25 UTC (permalink / raw)
To: davem, netdev; +Cc: jiri, isimatu.yasuaki, Taku Izumi
In-Reply-To: <1460686800-26427-1-git-send-email-izumi.taku@jp.fujitsu.com>
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 87b2474..bb7e903 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -29,7 +29,7 @@
#include "fjes.h"
#define MAJ 1
-#define MIN 0
+#define MIN 1
#define DRV_VERSION __stringify(MAJ) "." __stringify(MIN)
#define DRV_NAME "fjes"
char fjes_driver_name[] = DRV_NAME;
--
2.4.3
^ permalink raw reply related
* [PATCH net-next v2 5/6] fjes: Introduce spinlock for rx_status
From: Taku Izumi @ 2016-04-15 2:25 UTC (permalink / raw)
To: davem, netdev; +Cc: jiri, isimatu.yasuaki, Taku Izumi
In-Reply-To: <1460686800-26427-1-git-send-email-izumi.taku@jp.fujitsu.com>
This patch introduces spinlock of rx_status for
proper excusive control.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_hw.c | 22 ++++++++++++++++-
drivers/net/fjes/fjes_hw.h | 2 ++
drivers/net/fjes/fjes_main.c | 57 +++++++++++++++++++++++++++++++++++++-------
3 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/net/fjes/fjes_hw.c b/drivers/net/fjes/fjes_hw.c
index e9f494b..0dbafed 100644
--- a/drivers/net/fjes/fjes_hw.c
+++ b/drivers/net/fjes/fjes_hw.c
@@ -216,6 +216,7 @@ static int fjes_hw_setup(struct fjes_hw *hw)
u8 mac[ETH_ALEN] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
struct fjes_device_command_param param;
struct ep_share_mem_info *buf_pair;
+ unsigned long flags;
size_t mem_size;
int result;
int epidx;
@@ -264,10 +265,12 @@ static int fjes_hw_setup(struct fjes_hw *hw)
if (result)
return result;
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&buf_pair->tx, mac,
fjes_support_mtu[0]);
fjes_hw_setup_epbuf(&buf_pair->rx, mac,
fjes_support_mtu[0]);
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
}
}
@@ -329,6 +332,7 @@ int fjes_hw_init(struct fjes_hw *hw)
INIT_WORK(&hw->epstop_task, fjes_hw_epstop_task);
mutex_init(&hw->hw_info.lock);
+ spin_lock_init(&hw->rx_status_lock);
hw->max_epid = fjes_hw_get_max_epid(hw);
hw->my_epid = fjes_hw_get_my_epid(hw);
@@ -736,6 +740,7 @@ fjes_hw_get_partner_ep_status(struct fjes_hw *hw, int epid)
void fjes_hw_raise_epstop(struct fjes_hw *hw)
{
enum ep_partner_status status;
+ unsigned long flags;
int epidx;
for (epidx = 0; epidx < hw->max_epid; epidx++) {
@@ -755,8 +760,10 @@ void fjes_hw_raise_epstop(struct fjes_hw *hw)
set_bit(epidx, &hw->hw_info.buffer_unshare_reserve_bit);
set_bit(epidx, &hw->txrx_stop_req_bit);
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[epidx].tx.info->v1i.rx_status |=
FJES_RX_STOP_REQ_REQUEST;
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
}
}
@@ -938,6 +945,7 @@ static void fjes_hw_update_zone_task(struct work_struct *work)
struct fjes_adapter *adapter;
struct net_device *netdev;
+ unsigned long flags;
ulong unshare_bit = 0;
ulong share_bit = 0;
@@ -1030,8 +1038,10 @@ static void fjes_hw_update_zone_task(struct work_struct *work)
continue;
if (test_bit(epidx, &share_bit)) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&hw->ep_shm_info[epidx].tx,
netdev->dev_addr, netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
mutex_lock(&hw->hw_info.lock);
@@ -1075,10 +1085,14 @@ static void fjes_hw_update_zone_task(struct work_struct *work)
mutex_unlock(&hw->hw_info.lock);
- if (ret == 0)
+ if (ret == 0) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(
&hw->ep_shm_info[epidx].tx,
netdev->dev_addr, netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock,
+ flags);
+ }
}
if (test_bit(epidx, &irq_bit)) {
@@ -1086,9 +1100,11 @@ static void fjes_hw_update_zone_task(struct work_struct *work)
REG_ICTL_MASK_TXRX_STOP_REQ);
set_bit(epidx, &hw->txrx_stop_req_bit);
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[epidx].tx.
info->v1i.rx_status |=
FJES_RX_STOP_REQ_REQUEST;
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
set_bit(epidx, &hw->hw_info.buffer_unshare_reserve_bit);
}
}
@@ -1104,6 +1120,7 @@ static void fjes_hw_epstop_task(struct work_struct *work)
{
struct fjes_hw *hw = container_of(work, struct fjes_hw, epstop_task);
struct fjes_adapter *adapter = (struct fjes_adapter *)hw->back;
+ unsigned long flags;
ulong remain_bit;
int epid_bit;
@@ -1111,9 +1128,12 @@ static void fjes_hw_epstop_task(struct work_struct *work)
while ((remain_bit = hw->epstop_req_bit)) {
for (epid_bit = 0; remain_bit; remain_bit >>= 1, epid_bit++) {
if (remain_bit & 1) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[epid_bit].
tx.info->v1i.rx_status |=
FJES_RX_STOP_REQ_DONE;
+ spin_unlock_irqrestore(&hw->rx_status_lock,
+ flags);
clear_bit(epid_bit, &hw->epstop_req_bit);
set_bit(epid_bit,
diff --git a/drivers/net/fjes/fjes_hw.h b/drivers/net/fjes/fjes_hw.h
index f40cf07..1445ac9 100644
--- a/drivers/net/fjes/fjes_hw.h
+++ b/drivers/net/fjes/fjes_hw.h
@@ -300,6 +300,8 @@ struct fjes_hw {
u8 *base;
struct fjes_hw_info hw_info;
+
+ spinlock_t rx_status_lock; /* spinlock for rx_status */
};
int fjes_hw_init(struct fjes_hw *);
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 3c0c120..87b2474 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -290,6 +290,7 @@ static int fjes_close(struct net_device *netdev)
{
struct fjes_adapter *adapter = netdev_priv(netdev);
struct fjes_hw *hw = &adapter->hw;
+ unsigned long flags;
int epidx;
netif_tx_stop_all_queues(netdev);
@@ -299,13 +300,18 @@ static int fjes_close(struct net_device *netdev)
napi_disable(&adapter->napi);
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
for (epidx = 0; epidx < hw->max_epid; epidx++) {
if (epidx == hw->my_epid)
continue;
- adapter->hw.ep_shm_info[epidx].tx.info->v1i.rx_status &=
- ~FJES_RX_POLL_WORK;
+ if (fjes_hw_get_partner_ep_status(hw, epidx) ==
+ EP_PARTNER_SHARED)
+ adapter->hw.ep_shm_info[epidx]
+ .tx.info->v1i.rx_status &=
+ ~FJES_RX_POLL_WORK;
}
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
fjes_free_irq(adapter);
@@ -330,6 +336,7 @@ static int fjes_setup_resources(struct fjes_adapter *adapter)
struct net_device *netdev = adapter->netdev;
struct ep_share_mem_info *buf_pair;
struct fjes_hw *hw = &adapter->hw;
+ unsigned long flags;
int result;
int epidx;
@@ -371,8 +378,10 @@ static int fjes_setup_resources(struct fjes_adapter *adapter)
buf_pair = &hw->ep_shm_info[epidx];
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&buf_pair->tx, netdev->dev_addr,
netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
if (fjes_hw_epid_is_same_zone(hw, epidx)) {
mutex_lock(&hw->hw_info.lock);
@@ -402,6 +411,7 @@ static void fjes_free_resources(struct fjes_adapter *adapter)
struct ep_share_mem_info *buf_pair;
struct fjes_hw *hw = &adapter->hw;
bool reset_flag = false;
+ unsigned long flags;
int result;
int epidx;
@@ -418,8 +428,10 @@ static void fjes_free_resources(struct fjes_adapter *adapter)
buf_pair = &hw->ep_shm_info[epidx];
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&buf_pair->tx,
netdev->dev_addr, netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
clear_bit(epidx, &hw->txrx_stop_req_bit);
}
@@ -766,6 +778,7 @@ static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
struct fjes_adapter *adapter = netdev_priv(netdev);
bool running = netif_running(netdev);
struct fjes_hw *hw = &adapter->hw;
+ unsigned long flags;
int ret = -EINVAL;
int idx, epidx;
@@ -784,12 +797,15 @@ static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
return ret;
if (running) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
for (epidx = 0; epidx < hw->max_epid; epidx++) {
if (epidx == hw->my_epid)
continue;
hw->ep_shm_info[epidx].tx.info->v1i.rx_status &=
~FJES_RX_MTU_CHANGING_DONE;
}
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
+
netif_tx_stop_all_queues(netdev);
netif_carrier_off(netdev);
cancel_work_sync(&adapter->tx_stall_task);
@@ -803,23 +819,25 @@ static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
netdev->mtu = new_mtu;
if (running) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
for (epidx = 0; epidx < hw->max_epid; epidx++) {
if (epidx == hw->my_epid)
continue;
- local_irq_disable();
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&hw->ep_shm_info[epidx].tx,
netdev->dev_addr,
netdev->mtu);
- local_irq_enable();
hw->ep_shm_info[epidx].tx.info->v1i.rx_status |=
FJES_RX_MTU_CHANGING_DONE;
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
}
netif_tx_wake_all_queues(netdev);
netif_carrier_on(netdev);
napi_enable(&adapter->napi);
+ napi_schedule(&adapter->napi);
}
return ret;
@@ -866,6 +884,7 @@ static void fjes_txrx_stop_req_irq(struct fjes_adapter *adapter,
{
struct fjes_hw *hw = &adapter->hw;
enum ep_partner_status status;
+ unsigned long flags;
status = fjes_hw_get_partner_ep_status(hw, src_epid);
switch (status) {
@@ -875,8 +894,10 @@ static void fjes_txrx_stop_req_irq(struct fjes_adapter *adapter,
break;
case EP_PARTNER_WAITING:
if (src_epid < hw->my_epid) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[src_epid].tx.info->v1i.rx_status |=
FJES_RX_STOP_REQ_DONE;
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
clear_bit(src_epid, &hw->txrx_stop_req_bit);
set_bit(src_epid, &adapter->unshare_watch_bitmask);
@@ -902,14 +923,17 @@ static void fjes_stop_req_irq(struct fjes_adapter *adapter, int src_epid)
{
struct fjes_hw *hw = &adapter->hw;
enum ep_partner_status status;
+ unsigned long flags;
set_bit(src_epid, &hw->hw_info.buffer_unshare_reserve_bit);
status = fjes_hw_get_partner_ep_status(hw, src_epid);
switch (status) {
case EP_PARTNER_WAITING:
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[src_epid].tx.info->v1i.rx_status |=
FJES_RX_STOP_REQ_DONE;
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
clear_bit(src_epid, &hw->txrx_stop_req_bit);
/* fall through */
case EP_PARTNER_UNSHARE:
@@ -1042,13 +1066,17 @@ static int fjes_poll(struct napi_struct *napi, int budget)
size_t frame_len;
void *frame;
+ spin_lock(&hw->rx_status_lock);
for (epidx = 0; epidx < hw->max_epid; epidx++) {
if (epidx == hw->my_epid)
continue;
- adapter->hw.ep_shm_info[epidx].tx.info->v1i.rx_status |=
- FJES_RX_POLL_WORK;
+ if (fjes_hw_get_partner_ep_status(hw, epidx) ==
+ EP_PARTNER_SHARED)
+ adapter->hw.ep_shm_info[epidx]
+ .tx.info->v1i.rx_status |= FJES_RX_POLL_WORK;
}
+ spin_unlock(&hw->rx_status_lock);
while (work_done < budget) {
prefetch(&adapter->hw);
@@ -1106,13 +1134,17 @@ static int fjes_poll(struct napi_struct *napi, int budget)
if (((long)jiffies - (long)adapter->rx_last_jiffies) < 3) {
napi_reschedule(napi);
} else {
+ spin_lock(&hw->rx_status_lock);
for (epidx = 0; epidx < hw->max_epid; epidx++) {
if (epidx == hw->my_epid)
continue;
- adapter->hw.ep_shm_info[epidx]
- .tx.info->v1i.rx_status &=
+ if (fjes_hw_get_partner_ep_status(hw, epidx) ==
+ EP_PARTNER_SHARED)
+ adapter->hw.ep_shm_info[epidx].tx
+ .info->v1i.rx_status &=
~FJES_RX_POLL_WORK;
}
+ spin_unlock(&hw->rx_status_lock);
fjes_hw_set_irqmask(hw, REG_ICTL_MASK_RX_DATA, false);
}
@@ -1281,6 +1313,7 @@ static void fjes_watch_unshare_task(struct work_struct *work)
int max_epid, my_epid, epidx;
int stop_req, stop_req_done;
ulong unshare_watch_bitmask;
+ unsigned long flags;
int wait_time = 0;
int is_shared;
int ret;
@@ -1333,8 +1366,10 @@ static void fjes_watch_unshare_task(struct work_struct *work)
}
mutex_unlock(&hw->hw_info.lock);
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&hw->ep_shm_info[epidx].tx,
netdev->dev_addr, netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
clear_bit(epidx, &hw->txrx_stop_req_bit);
clear_bit(epidx, &unshare_watch_bitmask);
@@ -1372,9 +1407,12 @@ static void fjes_watch_unshare_task(struct work_struct *work)
}
mutex_unlock(&hw->hw_info.lock);
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(
&hw->ep_shm_info[epidx].tx,
netdev->dev_addr, netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock,
+ flags);
clear_bit(epidx, &hw->txrx_stop_req_bit);
clear_bit(epidx, &unshare_watch_bitmask);
@@ -1382,8 +1420,11 @@ static void fjes_watch_unshare_task(struct work_struct *work)
}
if (test_bit(epidx, &unshare_watch_bitmask)) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[epidx].tx.info->v1i.rx_status &=
~FJES_RX_STOP_REQ_DONE;
+ spin_unlock_irqrestore(&hw->rx_status_lock,
+ flags);
}
}
}
--
2.4.3
^ permalink raw reply related
* [PATCH net-next v2 4/6] fjes: Enhance changing MTU related work
From: Taku Izumi @ 2016-04-15 2:25 UTC (permalink / raw)
To: davem, netdev; +Cc: jiri, isimatu.yasuaki, Taku Izumi
In-Reply-To: <1460686800-26427-1-git-send-email-izumi.taku@jp.fujitsu.com>
This patch enhances the fjes_change_mtu() method
by introducing new flag named FJES_RX_MTU_CHANGING_DONE
in rx_status. At the same time, default MTU value is
changed into 65510 bytes.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_hw.c | 8 +++++-
drivers/net/fjes/fjes_hw.h | 1 +
drivers/net/fjes/fjes_main.c | 60 ++++++++++++++++++++++++++++++++++++--------
3 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/drivers/net/fjes/fjes_hw.c b/drivers/net/fjes/fjes_hw.c
index b103adb..e9f494b 100644
--- a/drivers/net/fjes/fjes_hw.c
+++ b/drivers/net/fjes/fjes_hw.c
@@ -179,6 +179,8 @@ void fjes_hw_setup_epbuf(struct epbuf_handler *epbh, u8 *mac_addr, u32 mtu)
for (i = 0; i < EP_BUFFER_SUPPORT_VLAN_MAX; i++)
info->v1i.vlan_id[i] = vlan_id[i];
+
+ info->v1i.rx_status |= FJES_RX_MTU_CHANGING_DONE;
}
void
@@ -810,7 +812,8 @@ bool fjes_hw_check_mtu(struct epbuf_handler *epbh, u32 mtu)
{
union ep_buffer_info *info = epbh->info;
- return (info->v1i.frame_max == FJES_MTU_TO_FRAME_SIZE(mtu));
+ return ((info->v1i.frame_max == FJES_MTU_TO_FRAME_SIZE(mtu)) &&
+ info->v1i.rx_status & FJES_RX_MTU_CHANGING_DONE);
}
bool fjes_hw_check_vlan_id(struct epbuf_handler *epbh, u16 vlan_id)
@@ -863,6 +866,9 @@ bool fjes_hw_epbuf_rx_is_empty(struct epbuf_handler *epbh)
{
union ep_buffer_info *info = epbh->info;
+ if (!(info->v1i.rx_status & FJES_RX_MTU_CHANGING_DONE))
+ return true;
+
if (info->v1i.count_max == 0)
return true;
diff --git a/drivers/net/fjes/fjes_hw.h b/drivers/net/fjes/fjes_hw.h
index baee7f5..f40cf07 100644
--- a/drivers/net/fjes/fjes_hw.h
+++ b/drivers/net/fjes/fjes_hw.h
@@ -57,6 +57,7 @@ struct fjes_hw;
#define FJES_RX_STOP_REQ_DONE (0x1)
#define FJES_RX_STOP_REQ_REQUEST (0x2)
#define FJES_RX_POLL_WORK (0x4)
+#define FJES_RX_MTU_CHANGING_DONE (0x8)
#define EP_BUFFER_SIZE \
(((sizeof(union ep_buffer_info) + (128 * (64 * 1024))) \
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index e22a869..3c0c120 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -481,6 +481,9 @@ static void fjes_tx_stall_task(struct work_struct *work)
info = adapter->hw.ep_shm_info[epid].tx.info;
+ if (!(info->v1i.rx_status & FJES_RX_MTU_CHANGING_DONE))
+ return;
+
if (EP_RING_FULL(info->v1i.head, info->v1i.tail,
info->v1i.count_max)) {
all_queue_available = 0;
@@ -760,9 +763,11 @@ fjes_get_stats64(struct net_device *netdev, struct rtnl_link_stats64 *stats)
static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
{
+ struct fjes_adapter *adapter = netdev_priv(netdev);
bool running = netif_running(netdev);
- int ret = 0;
- int idx;
+ struct fjes_hw *hw = &adapter->hw;
+ int ret = -EINVAL;
+ int idx, epidx;
for (idx = 0; fjes_support_mtu[idx] != 0; idx++) {
if (new_mtu <= fjes_support_mtu[idx]) {
@@ -770,19 +775,54 @@ static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
if (new_mtu == netdev->mtu)
return 0;
- if (running)
- fjes_close(netdev);
+ ret = 0;
+ break;
+ }
+ }
+
+ if (ret)
+ return ret;
+
+ if (running) {
+ for (epidx = 0; epidx < hw->max_epid; epidx++) {
+ if (epidx == hw->my_epid)
+ continue;
+ hw->ep_shm_info[epidx].tx.info->v1i.rx_status &=
+ ~FJES_RX_MTU_CHANGING_DONE;
+ }
+ netif_tx_stop_all_queues(netdev);
+ netif_carrier_off(netdev);
+ cancel_work_sync(&adapter->tx_stall_task);
+ napi_disable(&adapter->napi);
+
+ msleep(1000);
- netdev->mtu = new_mtu;
+ netif_tx_stop_all_queues(netdev);
+ }
- if (running)
- ret = fjes_open(netdev);
+ netdev->mtu = new_mtu;
- return ret;
+ if (running) {
+ for (epidx = 0; epidx < hw->max_epid; epidx++) {
+ if (epidx == hw->my_epid)
+ continue;
+
+ local_irq_disable();
+ fjes_hw_setup_epbuf(&hw->ep_shm_info[epidx].tx,
+ netdev->dev_addr,
+ netdev->mtu);
+ local_irq_enable();
+
+ hw->ep_shm_info[epidx].tx.info->v1i.rx_status |=
+ FJES_RX_MTU_CHANGING_DONE;
}
+
+ netif_tx_wake_all_queues(netdev);
+ netif_carrier_on(netdev);
+ napi_enable(&adapter->napi);
}
- return -EINVAL;
+ return ret;
}
static int fjes_vlan_rx_add_vid(struct net_device *netdev,
@@ -1204,7 +1244,7 @@ static void fjes_netdev_setup(struct net_device *netdev)
netdev->watchdog_timeo = FJES_TX_RETRY_INTERVAL;
netdev->netdev_ops = &fjes_netdev_ops;
fjes_set_ethtool_ops(netdev);
- netdev->mtu = fjes_support_mtu[0];
+ netdev->mtu = fjes_support_mtu[3];
netdev->flags |= IFF_BROADCAST;
netdev->features |= NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_CTAG_FILTER;
}
--
2.4.3
^ permalink raw reply related
* [PATCH net-next v2 3/6] fjes: fix bitwise check bug in fjes_raise_intr_rxdata_task
From: Taku Izumi @ 2016-04-15 2:25 UTC (permalink / raw)
To: davem, netdev; +Cc: jiri, isimatu.yasuaki, Taku Izumi
In-Reply-To: <1460686800-26427-1-git-send-email-izumi.taku@jp.fujitsu.com>
In fjes_raise_intr_rxdata_task(), there's a bug of bitwise
check because of missing "& FJES_RX_POLL_WORK".
This patch fixes this bug.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 05bdd8b..e22a869 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -549,7 +549,8 @@ static void fjes_raise_intr_rxdata_task(struct work_struct *work)
if ((hw->ep_shm_info[epid].tx_status_work ==
FJES_TX_DELAY_SEND_PENDING) &&
(pstatus == EP_PARTNER_SHARED) &&
- !(hw->ep_shm_info[epid].rx.info->v1i.rx_status)) {
+ !(hw->ep_shm_info[epid].rx.info->v1i.rx_status &
+ FJES_RX_POLL_WORK)) {
fjes_hw_raise_interrupt(hw, epid,
REG_ICTL_MASK_RX_DATA);
}
--
2.4.3
^ permalink raw reply related
* [PATCH net-next v2 2/6] fjes: fix incorrect statistics information in fjes_xmit_frame()
From: Taku Izumi @ 2016-04-15 2:25 UTC (permalink / raw)
To: davem, netdev; +Cc: jiri, isimatu.yasuaki, Taku Izumi
In-Reply-To: <1460686800-26427-1-git-send-email-izumi.taku@jp.fujitsu.com>
There are bugs of acounting statistics in fjes_xmit_frame().
Accounting self stats is wrong. accounting stats of other
EPs to be transmitted is right.
This patch fixes this bug.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_main.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 061b4af..05bdd8b 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -653,7 +653,7 @@ fjes_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
&adapter->hw.ep_shm_info[dest_epid].rx, 0)) {
/* version is NOT 0 */
adapter->stats64.tx_carrier_errors += 1;
- hw->ep_shm_info[my_epid].net_stats
+ hw->ep_shm_info[dest_epid].net_stats
.tx_carrier_errors += 1;
ret = NETDEV_TX_OK;
@@ -661,9 +661,9 @@ fjes_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
&adapter->hw.ep_shm_info[dest_epid].rx,
netdev->mtu)) {
adapter->stats64.tx_dropped += 1;
- hw->ep_shm_info[my_epid].net_stats.tx_dropped += 1;
+ hw->ep_shm_info[dest_epid].net_stats.tx_dropped += 1;
adapter->stats64.tx_errors += 1;
- hw->ep_shm_info[my_epid].net_stats.tx_errors += 1;
+ hw->ep_shm_info[dest_epid].net_stats.tx_errors += 1;
ret = NETDEV_TX_OK;
} else if (vlan &&
@@ -694,10 +694,10 @@ fjes_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
(long)adapter->tx_start_jiffies) >=
FJES_TX_RETRY_TIMEOUT) {
adapter->stats64.tx_fifo_errors += 1;
- hw->ep_shm_info[my_epid].net_stats
+ hw->ep_shm_info[dest_epid].net_stats
.tx_fifo_errors += 1;
adapter->stats64.tx_errors += 1;
- hw->ep_shm_info[my_epid].net_stats
+ hw->ep_shm_info[dest_epid].net_stats
.tx_errors += 1;
ret = NETDEV_TX_OK;
@@ -714,10 +714,10 @@ fjes_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
} else {
if (!is_multi) {
adapter->stats64.tx_packets += 1;
- hw->ep_shm_info[my_epid].net_stats
+ hw->ep_shm_info[dest_epid].net_stats
.tx_packets += 1;
adapter->stats64.tx_bytes += len;
- hw->ep_shm_info[my_epid].net_stats
+ hw->ep_shm_info[dest_epid].net_stats
.tx_bytes += len;
}
--
2.4.3
^ permalink raw reply related
* [PATCH net-next v2 1/6] fjes: optimize timeout value
From: Taku Izumi @ 2016-04-15 2:25 UTC (permalink / raw)
To: davem, netdev; +Cc: jiri, isimatu.yasuaki, Taku Izumi
In-Reply-To: <1460686800-26427-1-git-send-email-izumi.taku@jp.fujitsu.com>
This patch optimizes the following timeout value.
- FJES_DEVICE_RESET_TIMEOUT
- FJES_COMMAND_REQ_TIMEOUT
- FJES_COMMAND_REQ_BUFF_TIMEOUT
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_hw.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/fjes/fjes_hw.h b/drivers/net/fjes/fjes_hw.h
index 6d57b89..baee7f5 100644
--- a/drivers/net/fjes/fjes_hw.h
+++ b/drivers/net/fjes/fjes_hw.h
@@ -33,9 +33,9 @@ struct fjes_hw;
#define EP_BUFFER_SUPPORT_VLAN_MAX 4
#define EP_BUFFER_INFO_SIZE 4096
-#define FJES_DEVICE_RESET_TIMEOUT ((17 + 1) * 3) /* sec */
-#define FJES_COMMAND_REQ_TIMEOUT (5 + 1) /* sec */
-#define FJES_COMMAND_REQ_BUFF_TIMEOUT (8 * 3) /* sec */
+#define FJES_DEVICE_RESET_TIMEOUT ((17 + 1) * 3 * 8) /* sec */
+#define FJES_COMMAND_REQ_TIMEOUT ((5 + 1) * 3 * 8) /* sec */
+#define FJES_COMMAND_REQ_BUFF_TIMEOUT (60 * 3) /* sec */
#define FJES_COMMAND_EPSTOP_WAIT_TIMEOUT (1) /* sec */
#define FJES_CMD_REQ_ERR_INFO_PARAM (0x0001)
--
2.4.3
^ permalink raw reply related
* [PATCH net-next v2 0/6] FUJITSU Extended Socket driver version 1.1
From: Taku Izumi @ 2016-04-15 2:20 UTC (permalink / raw)
To: davem, netdev; +Cc: jiri, isimatu.yasuaki, Taku Izumi
This patchsets update FUJITSU Extended Socket network driver into version 1.1.
This mainly includes some improvements and minor bugfix.
v1->v2:
- Remove ioctl and debugfs facility according to David comment
Taku Izumi (6):
fjes: optimize timeout value
fjes: fix incorrect statistics information in fjes_xmit_frame()
fjes: fix bitwise check bug in fjes_raise_intr_rxdata_task
fjes: Enhance changing MTU related work
fjes: Introduce spinlock for rx_status
fjes: Update fjes driver version : 1.1
drivers/net/fjes/fjes_hw.c | 30 +++++++++-
drivers/net/fjes/fjes_hw.h | 9 ++-
drivers/net/fjes/fjes_main.c | 132 +++++++++++++++++++++++++++++++++++--------
3 files changed, 141 insertions(+), 30 deletions(-)
--
2.4.3
^ permalink raw reply
* Re: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts
From: Jeff Kirsher @ 2016-04-15 2:21 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: olaf, intel-wired-lan, netdev, jasowang, LKML, jackm, yevgenyp,
Ronciak, John, eli, apw, devel, David Miller
In-Reply-To: <1460678121-30308-1-git-send-email-kys@microsoft.com>
On Thu, Apr 14, 2016 at 4:55 PM, K. Y. Srinivasan <kys@microsoft.com> wrote:
> Make adjustments to the Intel 10G VF driver to support
> running on Hyper-V hosts.
>
> K. Y. Srinivasan (2):
> ethernet: intel: Add the device ID's presented while running on
> Hyper-V
> intel: ixgbevf: Support Windows hosts (Hyper-V)
>
> drivers/net/ethernet/intel/ixgbevf/defines.h | 5 +
> drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 11 ++
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 56 ++++++---
> drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
> drivers/net/ethernet/intel/ixgbevf/vf.c | 138 +++++++++++++++++++++
> drivers/net/ethernet/intel/ixgbevf/vf.h | 2 +
> 6 files changed, 206 insertions(+), 18 deletions(-)
Don't know how you butchered the mailing list address, but you did not
send this series to intel-wired-lan@lists.osuosl.org mailing list.
Please address the requested changes that Mark suggested and resubmit
to the correct mailing list please.
^ permalink raw reply
* WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]
From: Borislav Petkov @ 2016-04-15 2:07 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, Luca Coelho, Sara Sharon, Haim Dreyfuss,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hi,
so I'm seeing this when wlan0 tries to associate. On 4.6-rc2 + tip.
After that, wifi is dead in the water. Anyone have a clue?
And 4.5 seems fine, I'm typing from it as we speak.
...
[ 2.111418] iwlwifi 0000:02:00.0: loaded firmware version 21.302800.0 op_mode iwlmvm
...
[ 2.220954] iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 7265, REV=0x210
[ 2.221460] iwlwifi 0000:02:00.0: L1 Enabled - LTR Disabled
[ 2.221988] iwlwifi 0000:02:00.0: L1 Enabled - LTR Disabled
...
[ 311.776764] iwlwifi 0000:02:00.0: L1 Enabled - LTR Disabled
[ 311.777226] iwlwifi 0000:02:00.0: L1 Enabled - LTR Disabled
[ 311.837783] iwlwifi 0000:02:00.0: L1 Enabled - LTR Disabled
[ 311.838262] iwlwifi 0000:02:00.0: L1 Enabled - LTR Disabled
[ 311.853871] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 315.606321] wlan0: authenticate with 00:c0:23:b9:ff:10
[ 315.609802] wlan0: send auth to 00:c0:23:b9:ff:10 (try 1/3)
[ 315.612246] wlan0: authenticated
[ 315.612656] iwlwifi 0000:02:00.0 wlan0: disabling HT as WMM/QoS is not supported by the AP
[ 315.612946] iwlwifi 0000:02:00.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP
[ 315.614655] wlan0: associate with 00:c0:23:b9:ff:10 (try 1/3)
[ 315.718696] wlan0: associate with 00:c0:23:b9:ff:10 (try 2/3)
[ 315.722311] wlan0: deauthenticated from 00:c0:23:b9:ff:10 while associating (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA)
[ 316.159994] wlan0: authenticate with 00:c0:23:ba:5a:70
[ 316.162826] wlan0: send auth to 00:c0:23:ba:5a:70 (try 1/3)
[ 316.166422] wlan0: authenticated
[ 316.166864] iwlwifi 0000:02:00.0 wlan0: disabling HT as WMM/QoS is not supported by the AP
[ 316.167164] iwlwifi 0000:02:00.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP
[ 316.170689] wlan0: associate with 00:c0:23:ba:5a:70 (try 1/3)
[ 316.173951] wlan0: RX AssocResp from 00:c0:23:ba:5a:70 (capab=0x121 status=0 aid=4)
[ 316.175966] wlan0: associated
[ 316.176160] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 653.272205] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 653.272497] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 653.290868] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 653.291211] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 661.124556] iwlwifi 0000:02:00.0: Queue 2 stuck for 10000 ms.
[ 661.124748] iwlwifi 0000:02:00.0: Current SW read_ptr 59 write_ptr 63
[ 661.142657] ------------[ cut here ]------------
[ 661.142816] WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]
[ 661.143231] Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)
[ 661.143449] Modules linked in: msr hid_generic arc4 kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul iwlmvm crc32c_intel mac80211 jitterentropy_rng sha256_generic hmac acpi_cpufreq tpm_infineon drbg amdgpu iwlwifi aesni_intel snd_hda_codec_conexant aes_x86_64 glue_helper lrw snd_hda_codec_generic gf128mul snd_hda_codec_hdmi ablk_helper cryptd psmouse snd_hda_intel evdev joydev input_leds cfg80211 snd_hda_codec serio_raw pcspkr snd_hwdep snd_hda_core tg3 snd_pcm fam15h_power ptp edac_core pps_core xhci_pci k10temp snd_timer ttm xhci_hcd libphy ehci_pci snd ehci_hcd i2c_piix4 sg soundcore battery tpm_tis tpm video processor ac button sd_mod thermal
[ 661.145657] CPU: 1 PID: 2485 Comm: iceweasel Tainted: G W 4.6.0-rc2+ #1
[ 661.145905] Hardware name: HP HP EliteBook 745 G3/807E, BIOS N73 Ver. 01.08 01/28/2016
[ 661.146159] 0000000000000000 ffffffff812d9e79 ffff88043dc83d78 0000000000000000
[ 661.146418] ffffffff810588ac ffff880424740000 ffff88043dc83dc8 ffff880424747adc
[ 661.146677] ffff88043dc83e00 ffff88009b2301e0 ffff88009b2301f0 ffffffff8105891f
[ 661.146937] Call Trace:
[ 661.147020] <IRQ> [<ffffffff812d9e79>] ? dump_stack+0x5c/0x83
[ 661.147223] [<ffffffff810588ac>] ? __warn+0xec/0x110
[ 661.147387] [<ffffffff8105891f>] ? warn_slowpath_fmt+0x4f/0x60
[ 661.147580] [<ffffffffc03650af>] ? iwl_poll_bit+0x2f/0x70 [iwlwifi]
[ 661.147785] [<ffffffffc0373770>] ? iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]
[ 661.148045] [<ffffffffc0371cf7>] ? iwl_trans_pcie_read_mem+0x27/0x90 [iwlwifi]
[ 661.148280] [<ffffffffc036d7d0>] ? iwl_pcie_txq_stuck_timer+0xd0/0x380 [iwlwifi]
[ 661.148521] [<ffffffff8108a438>] ? task_tick_fair+0x4b8/0x920
[ 661.148712] [<ffffffff811311df>] ? perf_event_task_tick+0x6f/0x230
[ 661.148915] [<ffffffffc036d700>] ? iwl_pcie_txq_unmap+0x160/0x160 [iwlwifi]
[ 661.149142] [<ffffffff810b93d0>] ? call_timer_fn+0x30/0x150
[ 661.149325] [<ffffffffc036d700>] ? iwl_pcie_txq_unmap+0x160/0x160 [iwlwifi]
[ 661.149552] [<ffffffff810b99d3>] ? run_timer_softirq+0x223/0x2d0
[ 661.149750] [<ffffffff815ebd9d>] ? __do_softirq+0xdd/0x2c4
[ 661.149931] [<ffffffff8105e195>] ? irq_exit+0x85/0x90
[ 661.150098] [<ffffffff815ebb9e>] ? smp_apic_timer_interrupt+0x3e/0x50
[ 661.150308] [<ffffffff815ea132>] ? apic_timer_interrupt+0x82/0x90
[ 661.150507] <EOI>
[ 661.150573] ---[ end trace 9159ae5cde33d1c4 ]---
[ 661.150786] iwl data: 00000000: df 11 13 81 ff ff ff ff ae 0f 0c 81 00 00 00 00 ................
[ 661.168775] iwlwifi 0000:02:00.0: FH TRBs(0) = 0x5a5a5a5a
[ 661.186643] iwlwifi 0000:02:00.0: FH TRBs(1) = 0x5a5a5a5a
[ 661.204498] iwlwifi 0000:02:00.0: FH TRBs(2) = 0x5a5a5a5a
[ 661.222649] iwlwifi 0000:02:00.0: FH TRBs(3) = 0x5a5a5a5a
[ 661.240715] iwlwifi 0000:02:00.0: FH TRBs(4) = 0x5a5a5a5a
[ 661.258767] iwlwifi 0000:02:00.0: FH TRBs(5) = 0x5a5a5a5a
[ 661.276772] iwlwifi 0000:02:00.0: FH TRBs(6) = 0x5a5a5a5a
[ 661.294687] iwlwifi 0000:02:00.0: FH TRBs(7) = 0x5a5a5a5a
[ 661.330307] ------------[ cut here ]------------
[ 661.330461] WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/iwl-trans.h:1161 iwl_pcie_txq_stuck_timer+0x2b2/0x380 [iwlwifi]
[ 661.330861] Modules linked in: msr hid_generic arc4 kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul iwlmvm crc32c_intel mac80211 jitterentropy_rng sha256_generic hmac acpi_cpufreq tpm_infineon drbg amdgpu iwlwifi aesni_intel snd_hda_codec_conexant aes_x86_64 glue_helper lrw snd_hda_codec_generic gf128mul snd_hda_codec_hdmi ablk_helper cryptd psmouse snd_hda_intel evdev joydev input_leds cfg80211 snd_hda_codec serio_raw pcspkr snd_hwdep snd_hda_core tg3 snd_pcm fam15h_power ptp edac_core pps_core xhci_pci k10temp snd_timer ttm xhci_hcd libphy ehci_pci snd ehci_hcd i2c_piix4 sg soundcore battery tpm_tis tpm video processor ac button sd_mod thermal
[ 661.333137] CPU: 1 PID: 2485 Comm: iceweasel Tainted: G W 4.6.0-rc2+ #1
[ 661.333425] Hardware name: HP HP EliteBook 745 G3/807E, BIOS N73 Ver. 01.08 01/28/2016
[ 661.333681] 0000000000000000 ffffffff812d9e79 0000000000000000 0000000000000000
[ 661.333943] ffffffff810588ac 0000000000000000 000000000080f0c0 ffff880424740218
[ 661.334206] ffff880424740000 0000000000a02e34 00000000000007e0 ffffffffc036d9b2
[ 661.334468] Call Trace:
[ 661.334551] <IRQ> [<ffffffff812d9e79>] ? dump_stack+0x5c/0x83
[ 661.334751] [<ffffffff810588ac>] ? __warn+0xec/0x110
[ 661.334918] [<ffffffffc036d9b2>] ? iwl_pcie_txq_stuck_timer+0x2b2/0x380 [iwlwifi]
[ 661.335164] [<ffffffff811311df>] ? perf_event_task_tick+0x6f/0x230
[ 661.335368] [<ffffffffc036d700>] ? iwl_pcie_txq_unmap+0x160/0x160 [iwlwifi]
[ 661.335597] [<ffffffff810b93d0>] ? call_timer_fn+0x30/0x150
[ 661.335782] [<ffffffffc036d700>] ? iwl_pcie_txq_unmap+0x160/0x160 [iwlwifi]
[ 661.336011] [<ffffffff810b99d3>] ? run_timer_softirq+0x223/0x2d0
[ 661.336210] [<ffffffff815ebd9d>] ? __do_softirq+0xdd/0x2c4
[ 661.336392] [<ffffffff8105e195>] ? irq_exit+0x85/0x90
[ 661.336562] [<ffffffff815ebb9e>] ? smp_apic_timer_interrupt+0x3e/0x50
[ 661.336775] [<ffffffff815ea132>] ? apic_timer_interrupt+0x82/0x90
[ 661.336976] <EOI>
[ 661.337086] ---[ end trace 9159ae5cde33d1c5 ]---
[ 661.372860] iwlwifi 0000:02:00.0: Q 0 is active and mapped to fifo 2 ra_tid 0xa5a5 [90,1515870810]
[ 661.408857] ------------[ cut here ]------------
[ 661.409014] WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/iwl-trans.h:1161 iwl_pcie_txq_stuck_timer+0x2b2/0x380 [iwlwifi]
[ 661.409420] Modules linked in: msr hid_generic arc4 kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul iwlmvm crc32c_intel mac80211 jitterentropy_rng sha256_generic hmac acpi_cpufreq tpm_infineon drbg amdgpu iwlwifi aesni_intel snd_hda_codec_conexant aes_x86_64 glue_helper lrw snd_hda_codec_generic gf128mul snd_hda_codec_hdmi ablk_helper cryptd psmouse snd_hda_intel evdev joydev input_leds cfg80211 snd_hda_codec serio_raw pcspkr snd_hwdep snd_hda_core tg3 snd_pcm fam15h_power ptp edac_core pps_core xhci_pci k10temp snd_timer ttm xhci_hcd libphy ehci_pci snd ehci_hcd i2c_piix4 sg soundcore battery tpm_tis tpm video processor ac button sd_mod thermal
[ 661.411677] CPU: 1 PID: 2485 Comm: iceweasel Tainted: G W 4.6.0-rc2+ #1
[ 661.411930] Hardware name: HP HP EliteBook 745 G3/807E, BIOS N73 Ver. 01.08 01/28/2016
[ 661.412189] 0000000000000000 ffffffff812d9e79 0000000000000000 0000000000000000
[ 661.412455] ffffffff810588ac 0000000000000001 000000005a5a5a5a ffff880424740218
[ 661.412722] ffff880424740000 0000000000a02e38 00000000000007e2 ffffffffc036d9b2
[ 661.412988] Call Trace:
[ 661.413075] <IRQ> [<ffffffff812d9e79>] ? dump_stack+0x5c/0x83
[ 661.413279] [<ffffffff810588ac>] ? __warn+0xec/0x110
[ 661.413448] [<ffffffffc036d9b2>] ? iwl_pcie_txq_stuck_timer+0x2b2/0x380 [iwlwifi]
[ 661.413697] [<ffffffff811311df>] ? perf_event_task_tick+0x6f/0x230
[ 661.413905] [<ffffffffc036d700>] ? iwl_pcie_txq_unmap+0x160/0x160 [iwlwifi]
[ 661.414137] [<ffffffff810b93d0>] ? call_timer_fn+0x30/0x150
[ 661.414325] [<ffffffffc036d700>] ? iwl_pcie_txq_unmap+0x160/0x160 [iwlwifi]
[ 661.414557] [<ffffffff810b99d3>] ? run_timer_softirq+0x223/0x2d0
[ 661.414759] [<ffffffff815ebd9d>] ? __do_softirq+0xdd/0x2c4
[ 661.414944] [<ffffffff8105e195>] ? irq_exit+0x85/0x90
[ 661.415115] [<ffffffff815ebb9e>] ? smp_apic_timer_interrupt+0x3e/0x50
[ 661.415330] [<ffffffff815ea132>] ? apic_timer_interrupt+0x82/0x90
[ 661.415534] <EOI>
[ 661.415621] ---[ end trace 9159ae5cde33d1c6 ]---
[ 661.451288] iwlwifi 0000:02:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0xa5a5 [90,1515870810]
[ 661.487025] ------------[ cut here ]------------
[ 661.487186] WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/iwl-trans.h:1161 iwl_pcie_txq_stuck_timer+0x2b2/0x380 [iwlwifi]
[ 661.487591] Modules linked in: msr hid_generic arc4 kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul iwlmvm crc32c_intel mac80211 jitterentropy_rng sha256_generic hmac acpi_cpufreq tpm_infineon drbg amdgpu iwlwifi aesni_intel snd_hda_codec_conexant aes_x86_64 glue_helper lrw snd_hda_codec_generic gf128mul snd_hda_codec_hdmi ablk_helper cryptd psmouse snd_hda_intel evdev joydev input_leds cfg80211 snd_hda_codec serio_raw pcspkr snd_hwdep snd_hda_core tg3 snd_pcm fam15h_power ptp edac_core pps_core xhci_pci k10temp snd_timer ttm xhci_hcd libphy ehci_pci snd ehci_hcd i2c_piix4 sg soundcore battery tpm_tis tpm video processor ac button sd_mod thermal
[ 661.489848] CPU: 1 PID: 2485 Comm: iceweasel Tainted: G W 4.6.0-rc2+ #1
[ 661.490102] Hardware name: HP HP EliteBook 745 G3/807E, BIOS N73 Ver. 01.08 01/28/2016
[ 661.490360] 0000000000000000 ffffffff812d9e79 0000000000000000 0000000000000000
[ 661.490626] ffffffff810588ac 0000000000000002 000000005a5a5a5a ffff880424740218
[ 661.490892] ffff880424740000 0000000000a02e3c 00000000000007e4 ffffffffc036d9b2
[ 661.491157] Call Trace:
[ 661.491241] <IRQ> [<ffffffff812d9e79>] ? dump_stack+0x5c/0x83
[ 661.491444] [<ffffffff810588ac>] ? __warn+0xec/0x110
[ 661.491614] [<ffffffffc036d9b2>] ? iwl_pcie_txq_stuck_timer+0x2b2/0x380 [iwlwifi]
[ 661.491863] [<ffffffff811311df>] ? perf_event_task_tick+0x6f/0x230
[ 661.492071] [<ffffffffc036d700>] ? iwl_pcie_txq_unmap+0x160/0x160 [iwlwifi]
[ 661.492303] [<ffffffff810b93d0>] ? call_timer_fn+0x30/0x150
[ 661.492491] [<ffffffffc036d700>] ? iwl_pcie_txq_unmap+0x160/0x160 [iwlwifi]
[ 661.492724] [<ffffffff810b99d3>] ? run_timer_softirq+0x223/0x2d0
[ 661.492927] [<ffffffff815ebd9d>] ? __do_softirq+0xdd/0x2c4
[ 661.493111] [<ffffffff8105e195>] ? irq_exit+0x85/0x90
[ 661.493286] [<ffffffff815ebb9e>] ? smp_apic_timer_interrupt+0x3e/0x50
[ 661.493501] [<ffffffff815ea132>] ? apic_timer_interrupt+0x82/0x90
[ 661.493704] <EOI>
[ 661.493791] ---[ end trace 9159ae5cde33d1c7 ]---
[ 661.529378] iwlwifi 0000:02:00.0: Q 2 is active and mapped to fifo 2 ra_tid 0xa5a5 [90,1515870810]
[ 661.565101] ------------[ cut here ]------------
[ 661.565257] WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/iwl-trans.h:1161 iwl_pcie_txq_stuck_timer+0x2b2/0x380 [iwlwifi]
[ 661.565662] Modules linked in: msr hid_generic arc4 kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul iwlmvm crc32c_intel mac80211 jitterentropy_rng sha256_generic hmac acpi_cpufreq tpm_infineon drbg amdgpu iwlwifi aesni_intel snd_hda_codec_conexant aes_x86_64 glue_helper lrw snd_hda_codec_generic gf128mul snd_hda_codec_hdmi ablk_helper cryptd psmouse snd_hda_intel evdev joydev input_leds cfg80211 snd_hda_codec serio_raw pcspkr snd_hwdep snd_hda_core tg3 snd_pcm fam15h_power ptp edac_core pps_core xhci_pci k10temp snd_timer ttm xhci_hcd libphy ehci_pci snd ehci_hcd i2c_piix4 sg soundcore battery tpm_tis tpm video processor ac button sd_mod thermal
[ 661.567910] CPU: 1 PID: 2485 Comm: iceweasel Tainted: G W 4.6.0-rc2+ #1
[ 661.568163] Hardware name: HP HP EliteBook 745 G3/807E, BIOS N73 Ver. 01.08 01/28/2016
[ 661.568422] 0000000000000000 ffffffff812d9e79 0000000000000000 0000000000000000
[ 661.568690] ffffffff810588ac 0000000000000003 000000005a5a5a5a ffff880424740218
[ 661.568956] ffff880424740000 0000000000a02e40 00000000000007e6 ffffffffc036d9b2
[ 661.569221] Call Trace:
[ 661.569306] <IRQ> [<ffffffff812d9e79>] ? dump_stack+0x5c/0x83
[ 661.569508] [<ffffffff810588ac>] ? __warn+0xec/0x110
[ 661.569678] [<ffffffffc036d9b2>] ? iwl_pcie_txq_stuck_timer+0x2b2/0x380 [iwlwifi]
[ 661.569927] [<ffffffff811311df>] ? perf_event_task_tick+0x6f/0x230
[ 661.570136] [<ffffffffc036d700>] ? iwl_pcie_txq_unmap+0x160/0x160 [iwlwifi]
[ 661.570370] [<ffffffff810b93d0>] ? call_timer_fn+0x30/0x150
[ 661.570562] [<ffffffffc036d700>] ? iwl_pcie_txq_unmap+0x160/0x160 [iwlwifi]
[ 661.570793] [<ffffffff810b99d3>] ? run_timer_softirq+0x223/0x2d0
[ 661.570996] [<ffffffff815ebd9d>] ? __do_softirq+0xdd/0x2c4
[ 661.571180] [<ffffffff8105e195>] ? irq_exit+0x85/0x90
[ 661.571352] [<ffffffff815ebb9e>] ? smp_apic_timer_interrupt+0x3e/0x50
[ 661.571567] [<ffffffff815ea132>] ? apic_timer_interrupt+0x82/0x90
[ 661.571770] <EOI>
[ 661.571855] ---[ end trace 9159ae5cde33d1c8 ]---
...
[ 663.717404] iwlwifi 0000:02:00.0: Q 30 is active and mapped to fifo 2 ra_tid 0xa5a5 [90,1515870810]
[ 696.349979] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 696.350314] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 696.368395] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 696.368655] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 719.417826] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 719.418110] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 719.436495] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 719.436765] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 732.474561] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 732.474892] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 732.492952] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 732.493163] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 745.528645] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 745.528908] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 745.547015] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 745.547259] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 758.581935] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 758.582190] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 758.600251] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 758.600480] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 771.635874] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 771.636135] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 771.654359] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 771.654617] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 784.689656] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 784.689950] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 784.707989] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 784.708199] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 797.748413] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 797.748739] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 797.766851] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 797.767089] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 810.806073] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 810.806395] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
[ 810.824452] iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
[ 810.824677] iwlwifi 0000:02:00.0: Error sending STATISTICS_CMD: enqueue_hcmd failed: -5
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply. Srsly.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [net-next PATCH] stmmac: socfpga: remove extra call to socfpga_dwmac_setup
From: dinguyen @ 2016-04-15 1:42 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: dinh.linux, mgerlach, davem, netdev, Dinh Nguyen
From: Dinh Nguyen <dinguyen@opensource.altera.com>
In the socfpga_dwmac_probe function, we have a call to socfpga_dwmac_setup,
which is already called from socfpga_dwmac_init later in the probe function.
Remove this extra call to socfpga_dwmac_setup.
Also we should not be calling socfpga_dwmac_setup() directly without wrapping
it around the proper reset assert/deasserts. That is because the
socfpga_dwmac_setup() is setting up PHY modes in the system manager, and it
is requires the EMAC's to be in reset during the PHY setup.
Reported-by: Matthew Gerlach <mgerlach@opensource.altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index f0d797a..41f4c58 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -267,12 +267,6 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
return ret;
}
- ret = socfpga_dwmac_setup(dwmac);
- if (ret) {
- dev_err(dev, "couldn't setup SoC glue (%d)\n", ret);
- return ret;
- }
-
plat_dat->bsp_priv = dwmac;
plat_dat->init = socfpga_dwmac_init;
plat_dat->exit = socfpga_dwmac_exit;
--
2.6.2
^ permalink raw reply related
* Re: [PATCH net-next] net: validate_xmit_skb() changes
From: David Miller @ 2016-04-15 1:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1460523007.32504.13.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 12 Apr 2016 21:50:07 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> skbs given to validate_xmit_skb() should not have a next
> pointer anymore.
>
> Also if a packet is dropped, increment dev->tx_dropped
> __dev_queue_xmit() no longer has to change tx_dropped in this case.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 0/5] BPF updates
From: David Miller @ 2016-04-15 1:37 UTC (permalink / raw)
To: daniel; +Cc: alexei.starovoitov, tgraf, bblanco, brendan.d.gregg, netdev
In-Reply-To: <cover.1460497071.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 13 Apr 2016 00:10:49 +0200
> This series adds a new verifier argument type called
> ARG_PTR_TO_RAW_STACK and converts related helpers to make
> use of it. Basic idea is that we can save init of stack
> memory when the helper function is guaranteed to fully
> fill out the passed buffer in every path. Series also adds
> test cases and converts samples. For more details, please
> see individual patches.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/2] Fixes for SO_REUSEPORT and mixed v4/v6 sockets
From: David Miller @ 2016-04-15 1:18 UTC (permalink / raw)
To: kraigatgoog; +Cc: netdev
In-Reply-To: <1460481086-12982-1-git-send-email-kraigatgoog@gmail.com>
From: Craig Gallek <kraigatgoog@gmail.com>
Date: Tue, 12 Apr 2016 13:11:24 -0400
> From: Craig Gallek <kraig@google.com>
>
> Recent changes to the datastructures associated with SO_REUSEPORT broke
> an existing behavior when equivalent SO_REUSEPORT sockets are created
> using both AF_INET and AF_INET6. This patch series restores the previous
> behavior and includes a test to validate it.
>
> This series should be a trivial merge to stable kernels (if deemed
> necessary), but will have conflicts in net-next. The following patches
> recently replaced the use of hlist_nulls with hlists for UDP and TCP
> socket lists:
> ca065d0cf80f ("udp: no longer use SLAB_DESTROY_BY_RCU")
> 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood")
>
> If this series is accepted, I will send an RFC for the net-next change
> to assist with the merge.
Applied and patch #1 queued up for -stable.
^ permalink raw reply
* Re: [PATCH 4.6 fix] bgmac: fix MAC soft-reset bit for corerev > 4
From: David Miller @ 2016-04-15 1:17 UTC (permalink / raw)
To: zajec5; +Cc: netdev, hauke, nbd
In-Reply-To: <1460478449-22561-1-git-send-email-zajec5@gmail.com>
From: Rafał Miłecki <zajec5@gmail.com>
Date: Tue, 12 Apr 2016 18:27:29 +0200
> From: Felix Fietkau <nbd@openwrt.org>
>
> Only core revisions older than 4 use BGMAC_CMDCFG_SR_REV0. This mainly
> fixes support for BCM4708A0KF SoCs with Ethernet core rev 5 (it means
> only some devices as most of BCM4708A0KF-s got core rev 4).
> This was tested for regressions on BCM47094 which doesn't seem to care
> which bit gets used.
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Applied.
^ permalink raw reply
* Re: [RFC PATCH net-next] sunvnet: Add ethtool support for netdev stastics
From: David Miller @ 2016-04-15 1:09 UTC (permalink / raw)
To: atish.patra; +Cc: netdev, aaron.young, sowmini.varadhan
In-Reply-To: <1460477959-185461-1-git-send-email-atish.patra@oracle.com>
From: Atish Patra <atish.patra@oracle.com>
Date: Tue, 12 Apr 2016 09:19:19 -0700
> Currently, sunvnet does not support statstics display
> via sysfs entry using ethtool.
ethtool is not for the already provided network device statistics.
It is for device specific statistic extensions, and acts as an
addition to the existing generic networking device stats, rather
than duplicating what already exists.
^ permalink raw reply
* Re: [PATCH 1/3] rxrpc: Don't permit use of connect() op and simplify sendmsg() op
From: David Miller @ 2016-04-15 1:07 UTC (permalink / raw)
To: dhowells; +Cc: linux-afs, netdev, linux-kernel
In-Reply-To: <20160412150540.20637.31886.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Tue, 12 Apr 2016 16:05:41 +0100
> Simplify the RxRPC user interface and remove the use of connect() to direct
> client calls. It is redundant given that sendmsg() can be given the target
> address and calls to multiple targets are permitted from a client socket
> and also from a service socket.
You can't just change completely the socket semantics for your
protocol like this, every single userland application is going to
break.
Sorry, there is no way I am applying changes like this.
^ permalink raw reply
* Re: [PATCH net,stable] cdc_mbim: apply "NDP to end" quirk to all Huawei devices
From: David Miller @ 2016-04-15 1:04 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
andreas.fett-opNxpl+3fjRBDgjK7y7TUQ,
burdandrei-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1460470272-9289-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Tue, 12 Apr 2016 16:11:12 +0200
> We now have a positive report of another Huawei device needing
> this quirk: The ME906s-158 (12d1:15c1). This is an m.2 form
> factor modem with no obvious relationship to the E3372 (12d1:157d)
> we already have a quirk entry for. This is reason enough to
> believe the quirk might be necessary for any number of current
> and future Huawei devices.
>
> Applying the quirk to all Huawei devices, since it is crucial
> to any device affected by the firmware bug, while the impact
> on non-affected devices is negligible.
>
> The quirk can if necessary be disabled per-device by writing
> N to /sys/class/net/<iface>/cdc_ncm/ndp_to_end
>
> Reported-by: Andreas Fett <andreas.fett-opNxpl+3fjRBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH nf] netfilter: ipv6: Orphan skbs in nf_ct_frag6_gather()
From: Joe Stringer @ 2016-04-15 0:35 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Florian Westphal, David Laight, netfilter-devel@vger.kernel.org,
diproiettod@vmware.com, netdev@vger.kernel.org
In-Reply-To: <20160414103533.GA3211@salvia>
On 14 April 2016 at 03:35, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Thu, Apr 14, 2016 at 10:40:15AM +0200, Florian Westphal wrote:
>> David Laight <David.Laight@ACULAB.COM> wrote:
>> > From: Joe Stringer
>> > > Sent: 13 April 2016 19:10
>> > > This is the IPv6 equivalent of commit 8282f27449bf ("inet: frag: Always
>> > > orphan skbs inside ip_defrag()").
>> > >
>> > > Prior to commit 029f7f3b8701 ("netfilter: ipv6: nf_defrag: avoid/free
>> > > clone operations"), ipv6 fragments sent to nf_ct_frag6_gather() would be
>> > > cloned (implicitly orphaning) prior to queueing for reassembly. As such,
>> > > when the IPv6 message is eventually reassembled, the skb->sk for all
>> > > fragments would be NULL. After that commit was introduced, rather than
>> > > cloning, the original skbs were queued directly without orphaning. The
>> > > end result is that all frags except for the first and last may have a
>> > > socket attached.
>> >
>> > I'd have thought that the queued fragments would still want to be
>> > resource-counted against the socket (I think that is what skb->sk is for).
>>
>> No, ipv4/ipv6 reasm has its own accouting.
>>
>> > Although I can't imagine why IPv6 reassembly is happening on skb
>> > associated with a socket.
>>
>> Right, thats a much more interesting question -- both ipv4 and
>> ipv6 orphan skbs before NF_HOOK prerouting trip.
>>
>> (That being said, I don't mind the patch, I'm just be curious how this
>> can happen).
>
> If this change is specific to get this working in ovs and its
> conntrack support, then I don't think this belong to core
> infrastructure. This should be fixed in ovs instead.
I admit I've only been able to reproduce it with OVS. My main reason
for proposing the fix this way was just because this is what the IPv4
code does, so I figured IPv6 should be consistent with that.
^ permalink raw reply
* RE: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: KY Srinivasan @ 2016-04-15 0:26 UTC (permalink / raw)
To: Alexander Duyck
Cc: olaf@aepfle.de, netdev, jasowang@redhat.com,
linux-kernel@vger.kernel.org, jackm@mellanox.com,
yevgenyp@mellanox.com, Ronciak, John,
intel-wired-lan@lists.osuosl.org, eli@mellanox.com,
apw@canonical.com, devel@linuxdriverproject.org, Rustad, Mark D,
David Miller
In-Reply-To: <CAKgT0UckBes1tNXrNjA0R4uCdXouG9qQrf+VaLJMd8AhgYQieQ@mail.gmail.com>
> -----Original Message-----
> From: Alexander Duyck [mailto:alexander.duyck@gmail.com]
> Sent: Thursday, April 14, 2016 5:19 PM
> To: KY Srinivasan <kys@microsoft.com>
> Cc: Rustad, Mark D <mark.d.rustad@intel.com>; David Miller
> <davem@davemloft.net>; netdev <netdev@vger.kernel.org>; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org; olaf@aepfle.de;
> apw@canonical.com; jasowang@redhat.com; eli@mellanox.com;
> jackm@mellanox.com; yevgenyp@mellanox.com; Ronciak, John
> <john.ronciak@intel.com>; intel-wired-lan@linuxonhyperv.com
> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
> (Hyper-V)
>
> On Thu, Apr 14, 2016 at 5:11 PM, KY Srinivasan <kys@microsoft.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Rustad, Mark D [mailto:mark.d.rustad@intel.com]
> >> Sent: Thursday, April 14, 2016 5:07 PM
> >> To: KY Srinivasan <kys@microsoft.com>
> >> Cc: David Miller <davem@davemloft.net>; netdev
> >> <netdev@vger.kernel.org>; linux-kernel@vger.kernel.org;
> >> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> >> jasowang@redhat.com; eli@mellanox.com; jackm@mellanox.com;
> >> yevgenyp@mellanox.com; Ronciak, John <john.ronciak@intel.com>;
> intel-
> >> wired-lan@linuxonhyperv.com
> >> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
> >> (Hyper-V)
> >>
> >> KY Srinivasan <kys@microsoft.com> wrote:
> >>
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: Rustad, Mark D [mailto:mark.d.rustad@intel.com]
> >> >> Sent: Thursday, April 14, 2016 4:01 PM
> >> >> To: KY Srinivasan <kys@microsoft.com>
> >> >> Cc: David Miller <davem@davemloft.net>; netdev
> >> >> <netdev@vger.kernel.org>; linux-kernel@vger.kernel.org;
> >> >> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> >> >> jasowang@redhat.com; eli@mellanox.com; jackm@mellanox.com;
> >> >> yevgenyp@mellanox.com; Ronciak, John <john.ronciak@intel.com>;
> >> intel-
> >> >> wired-lan@linuxonhyperv.com
> >> >> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows
> hosts
> >> >> (Hyper-V)
> >> >>
> >> >> Some comments below:
> >> >
> >> > Mark,
> >> >
> >> > Thank you for the comments. I will address them and repost the
> patches.
> >> >
> >> > Regards,
> >> >
> >> > K. Y
> >>
> >> Please look closely at Alex's comments. I think they are much more
> >> important.
> >
> > I am looking at Alex's comments as I am writing this.
> >
>
> On additional thought that just occurred to me after looking over the
> other patches you submitted for the hv_netvsc is that you might just
> stub out the multicast, unicast, and vfta configuration calls for the
> hyperV interface since all that stuff should be handled by the other
> link in the bond anyway. Then you should be able to mostly contain
> all the changes other than the device IDs to the vf.c file which is
> really how this kind of change should work anyway.
I will do that.
>
> Also I was wondering. Since HyperV is using a proprietary device ID
> anyway do you really need the calls like the one below?:
> + if (x86_hyper == &x86_hyper_ms_hyperv) {
>
> If we can just identify HyperV via the device Id then we could drop
> the x86 arch specific bits and instead just build for all cases.
Yes; I was planning to get rid of the x86 dependency. I will fix this.
K. Y
>
> - Alex
^ permalink raw reply
* Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: Alexander Duyck @ 2016-04-15 0:19 UTC (permalink / raw)
To: KY Srinivasan
Cc: olaf@aepfle.de, intel-wired-lan@linuxonhyperv.com, netdev,
jasowang@redhat.com, linux-kernel@vger.kernel.org,
jackm@mellanox.com, yevgenyp@mellanox.com, Ronciak, John,
eli@mellanox.com, apw@canonical.com, devel@linuxdriverproject.org,
Rustad, Mark D, David Miller
In-Reply-To: <SN2PR03MB19196E84DF934294DE7BB739A0680@SN2PR03MB1919.namprd03.prod.outlook.com>
On Thu, Apr 14, 2016 at 5:11 PM, KY Srinivasan <kys@microsoft.com> wrote:
>
>
>> -----Original Message-----
>> From: Rustad, Mark D [mailto:mark.d.rustad@intel.com]
>> Sent: Thursday, April 14, 2016 5:07 PM
>> To: KY Srinivasan <kys@microsoft.com>
>> Cc: David Miller <davem@davemloft.net>; netdev
>> <netdev@vger.kernel.org>; linux-kernel@vger.kernel.org;
>> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
>> jasowang@redhat.com; eli@mellanox.com; jackm@mellanox.com;
>> yevgenyp@mellanox.com; Ronciak, John <john.ronciak@intel.com>; intel-
>> wired-lan@linuxonhyperv.com
>> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
>> (Hyper-V)
>>
>> KY Srinivasan <kys@microsoft.com> wrote:
>>
>> >
>> >
>> >> -----Original Message-----
>> >> From: Rustad, Mark D [mailto:mark.d.rustad@intel.com]
>> >> Sent: Thursday, April 14, 2016 4:01 PM
>> >> To: KY Srinivasan <kys@microsoft.com>
>> >> Cc: David Miller <davem@davemloft.net>; netdev
>> >> <netdev@vger.kernel.org>; linux-kernel@vger.kernel.org;
>> >> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
>> >> jasowang@redhat.com; eli@mellanox.com; jackm@mellanox.com;
>> >> yevgenyp@mellanox.com; Ronciak, John <john.ronciak@intel.com>;
>> intel-
>> >> wired-lan@linuxonhyperv.com
>> >> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
>> >> (Hyper-V)
>> >>
>> >> Some comments below:
>> >
>> > Mark,
>> >
>> > Thank you for the comments. I will address them and repost the patches.
>> >
>> > Regards,
>> >
>> > K. Y
>>
>> Please look closely at Alex's comments. I think they are much more
>> important.
>
> I am looking at Alex's comments as I am writing this.
>
On additional thought that just occurred to me after looking over the
other patches you submitted for the hv_netvsc is that you might just
stub out the multicast, unicast, and vfta configuration calls for the
hyperV interface since all that stuff should be handled by the other
link in the bond anyway. Then you should be able to mostly contain
all the changes other than the device IDs to the vf.c file which is
really how this kind of change should work anyway.
Also I was wondering. Since HyperV is using a proprietary device ID
anyway do you really need the calls like the one below?:
+ if (x86_hyper == &x86_hyper_ms_hyperv) {
If we can just identify HyperV via the device Id then we could drop
the x86 arch specific bits and instead just build for all cases.
- Alex
^ permalink raw reply
* Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: Rustad, Mark D @ 2016-04-15 0:19 UTC (permalink / raw)
To: KY Srinivasan
Cc: olaf@aepfle.de, netdev, jasowang@redhat.com,
linux-kernel@vger.kernel.org, jackm@mellanox.com,
yevgenyp@mellanox.com, Ronciak, John, intel-wired-lan,
eli@mellanox.com, apw@canonical.com, devel@linuxdriverproject.org,
David Miller
In-Reply-To: <SN2PR03MB19196E84DF934294DE7BB739A0680@SN2PR03MB1919.namprd03.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 1863 bytes --]
KY Srinivasan <kys@microsoft.com> wrote:
>
>
>> -----Original Message-----
>> From: Rustad, Mark D [mailto:mark.d.rustad@intel.com]
>> Sent: Thursday, April 14, 2016 5:07 PM
>> To: KY Srinivasan <kys@microsoft.com>
>> Cc: David Miller <davem@davemloft.net>; netdev
>> <netdev@vger.kernel.org>; linux-kernel@vger.kernel.org;
>> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
>> jasowang@redhat.com; eli@mellanox.com; jackm@mellanox.com;
>> yevgenyp@mellanox.com; Ronciak, John <john.ronciak@intel.com>; intel-
>> wired-lan@linuxonhyperv.com
>> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
>> (Hyper-V)
>>
>> KY Srinivasan <kys@microsoft.com> wrote:
>>
>>>> -----Original Message-----
>>>> From: Rustad, Mark D [mailto:mark.d.rustad@intel.com]
>>>> Sent: Thursday, April 14, 2016 4:01 PM
>>>> To: KY Srinivasan <kys@microsoft.com>
>>>> Cc: David Miller <davem@davemloft.net>; netdev
>>>> <netdev@vger.kernel.org>; linux-kernel@vger.kernel.org;
>>>> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
>>>> jasowang@redhat.com; eli@mellanox.com; jackm@mellanox.com;
>>>> yevgenyp@mellanox.com; Ronciak, John <john.ronciak@intel.com>;
>> intel-
>>>> wired-lan@linuxonhyperv.com
>>>> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
>>>> (Hyper-V)
>>>>
>>>> Some comments below:
>>>
>>> Mark,
>>>
>>> Thank you for the comments. I will address them and repost the patches.
>>>
>>> Regards,
>>>
>>> K. Y
>>
>> Please look closely at Alex's comments. I think they are much more
>> important.
>
> I am looking at Alex's comments as I am writing this.
>
> K. Y
>> --
>> Mark Rustad, Networking Division, Intel Corporation
Can you please stop putting that crazy intel-wired-lan@linuxonhyperv.com in
your messages? It doesn't exist.
--
Mark Rustad, Networking Division, Intel Corporation
[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [PATCH nf] netfilter: ipv6: Orphan skbs in nf_ct_frag6_gather()
From: Joe Stringer @ 2016-04-15 0:14 UTC (permalink / raw)
To: Florian Westphal
Cc: David Laight, netfilter-devel@vger.kernel.org,
diproiettod@vmware.com, netdev@vger.kernel.org
In-Reply-To: <20160414084015.GA3192@breakpoint.cc>
On 14 April 2016 at 01:40, Florian Westphal <fw@strlen.de> wrote:
> David Laight <David.Laight@ACULAB.COM> wrote:
>> From: Joe Stringer
>> > Sent: 13 April 2016 19:10
>> > This is the IPv6 equivalent of commit 8282f27449bf ("inet: frag: Always
>> > orphan skbs inside ip_defrag()").
>> >
>> > Prior to commit 029f7f3b8701 ("netfilter: ipv6: nf_defrag: avoid/free
>> > clone operations"), ipv6 fragments sent to nf_ct_frag6_gather() would be
>> > cloned (implicitly orphaning) prior to queueing for reassembly. As such,
>> > when the IPv6 message is eventually reassembled, the skb->sk for all
>> > fragments would be NULL. After that commit was introduced, rather than
>> > cloning, the original skbs were queued directly without orphaning. The
>> > end result is that all frags except for the first and last may have a
>> > socket attached.
>>
>> I'd have thought that the queued fragments would still want to be
>> resource-counted against the socket (I think that is what skb->sk is for).
>
> No, ipv4/ipv6 reasm has its own accouting.
>
>> Although I can't imagine why IPv6 reassembly is happening on skb
>> associated with a socket.
>
> Right, thats a much more interesting question -- both ipv4 and
> ipv6 orphan skbs before NF_HOOK prerouting trip.
>
> (That being said, I don't mind the patch, I'm just be curious how this
> can happen).
The topology is quite simple, there is a veth pair connected between a
namespace and OVS. The OVS bridge has an internal port. The
bridge is configured with flows to send packets through conntrack
(causing packet reassembly + refragmentation on output), and then
forward packets between the host and the veth. The internal port and
the veth inside the netns have IP addresses configured in the same
subnet.
In the test case, we send a large ICMPv6 ping request from the
namespace to the internal port. The namespace will fragment the IP
message into fragments and send through the veth. OVS processes these,
sends to conntrack (reassembly), then decides to output to the
internal port (refragmenting). The host stack finally receives the
fragments and processes the ICMP request. On response, the host sends
several fragments to OVS. OVS reassembles these and sends them to
conntrack, then decides to forward to the veth. When forwarding to the
veth, the skb frag queue is in this state with many skbs (all except
first and last) having skb->sk populated, and we hit the
BUG_ON(skb->sk) in ip6_fragment() just prior to transmitting to the veth.
In regards to your question about prerouting, does the response even
hit the input path on the host? An ICMP response is generated, and it
needs to be directed out to the device (output path), then when the
internal device receives it, it starts OVS processing.
^ permalink raw reply
* RE: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: KY Srinivasan @ 2016-04-15 0:11 UTC (permalink / raw)
To: Rustad, Mark D
Cc: olaf@aepfle.de, intel-wired-lan@linuxonhyperv.com, netdev,
jasowang@redhat.com, linux-kernel@vger.kernel.org,
jackm@mellanox.com, yevgenyp@mellanox.com, Ronciak, John,
eli@mellanox.com, apw@canonical.com, devel@linuxdriverproject.org,
David Miller
In-Reply-To: <DA0F5562-FC38-4037-B018-42116DD142E8@intel.com>
> -----Original Message-----
> From: Rustad, Mark D [mailto:mark.d.rustad@intel.com]
> Sent: Thursday, April 14, 2016 5:07 PM
> To: KY Srinivasan <kys@microsoft.com>
> Cc: David Miller <davem@davemloft.net>; netdev
> <netdev@vger.kernel.org>; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> jasowang@redhat.com; eli@mellanox.com; jackm@mellanox.com;
> yevgenyp@mellanox.com; Ronciak, John <john.ronciak@intel.com>; intel-
> wired-lan@linuxonhyperv.com
> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
> (Hyper-V)
>
> KY Srinivasan <kys@microsoft.com> wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: Rustad, Mark D [mailto:mark.d.rustad@intel.com]
> >> Sent: Thursday, April 14, 2016 4:01 PM
> >> To: KY Srinivasan <kys@microsoft.com>
> >> Cc: David Miller <davem@davemloft.net>; netdev
> >> <netdev@vger.kernel.org>; linux-kernel@vger.kernel.org;
> >> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> >> jasowang@redhat.com; eli@mellanox.com; jackm@mellanox.com;
> >> yevgenyp@mellanox.com; Ronciak, John <john.ronciak@intel.com>;
> intel-
> >> wired-lan@linuxonhyperv.com
> >> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
> >> (Hyper-V)
> >>
> >> Some comments below:
> >
> > Mark,
> >
> > Thank you for the comments. I will address them and repost the patches.
> >
> > Regards,
> >
> > K. Y
>
> Please look closely at Alex's comments. I think they are much more
> important.
I am looking at Alex's comments as I am writing this.
K. Y
>
> --
> Mark Rustad, Networking Division, Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: Rustad, Mark D @ 2016-04-15 0:06 UTC (permalink / raw)
To: KY Srinivasan
Cc: olaf@aepfle.de, intel-wired-lan@linuxonhyperv.com, netdev,
jasowang@redhat.com, linux-kernel@vger.kernel.org,
jackm@mellanox.com, yevgenyp@mellanox.com, Ronciak, John,
eli@mellanox.com, apw@canonical.com, devel@linuxdriverproject.org,
David Miller
In-Reply-To: <SN2PR03MB1919133D2E9B5DDBC2AED643A0680@SN2PR03MB1919.namprd03.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 917 bytes --]
KY Srinivasan <kys@microsoft.com> wrote:
>
>
>> -----Original Message-----
>> From: Rustad, Mark D [mailto:mark.d.rustad@intel.com]
>> Sent: Thursday, April 14, 2016 4:01 PM
>> To: KY Srinivasan <kys@microsoft.com>
>> Cc: David Miller <davem@davemloft.net>; netdev
>> <netdev@vger.kernel.org>; linux-kernel@vger.kernel.org;
>> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
>> jasowang@redhat.com; eli@mellanox.com; jackm@mellanox.com;
>> yevgenyp@mellanox.com; Ronciak, John <john.ronciak@intel.com>; intel-
>> wired-lan@linuxonhyperv.com
>> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
>> (Hyper-V)
>>
>> Some comments below:
>
> Mark,
>
> Thank you for the comments. I will address them and repost the patches.
>
> Regards,
>
> K. Y
Please look closely at Alex's comments. I think they are much more important.
--
Mark Rustad, Networking Division, Intel Corporation
[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ 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