* RE: [PATCH net-next] r8152: divide the tx and rx bottom functions
From: Hayes Wang @ 2019-08-16 8:10 UTC (permalink / raw)
To: Eric Dumazet, netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org
In-Reply-To: <9749764d-7815-b673-0fc4-22475601efec@gmail.com>
Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Friday, August 16, 2019 2:40 PM
[...]
> tasklet and NAPI are scheduled on the same core (the current
> cpu calling napi_schedule() or tasklet_schedule())
>
> I would rather not add this dubious tasklet, and instead try to understand
> what is wrong in this driver ;)
>
> The various napi_schedule() calls are suspect IMO.
The original method as following.
static int r8152_poll(struct napi_struct *napi, int budget)
{
struct r8152 *tp = container_of(napi, struct r8152, napi);
int work_done;
work_done = rx_bottom(tp, budget); <-- RX
bottom_half(tp); <-- Tx (tx_bottom)
[...]
The rx_bottom and tx_bottom would only be called in r8152_poll.
That is, tx_bottom wouldn't be run unless rx_bottom is finished.
And, rx_bottom would be called if tx_bottom is running.
If the traffic is busy. rx_bottom or tx_bottom may take a lot
of time to deal with the packets. And the one would increase
the latency time for the other one.
Therefore, when I separate the tx_bottom and rx_bottom to
different tasklet and napi, the callback functions of tx and
rx may schedule the tasklet and napi to different cpu. Then,
the rx_bottom and tx_bottom may be run at the same time.
Take our arm platform for example. There are five cpus to
handle the interrupt of USB host controller. When the rx is
completed, cpu #1 may handle the interrupt and napi would
be scheduled. When the tx is finished, cpu #2 may handle
the interrupt and the tasklet is scheduled. Then, napi is
run on cpu #1, and tasklet is run on cpu #2.
> Also rtl8152_start_xmit() uses skb_queue_tail(&tp->tx_queue, skb);
>
> But I see nothing really kicking the transmit if tx_free is empty ?
Tx callback function "write_bulk_callback" would deal with it.
The callback function would check if there are packets waiting
to be sent.
Best Regards,
Hayes
^ permalink raw reply
* [PATCH net-next 2/6] net: hns3: modify redundant initialization of variable
From: Huazhong Tan @ 2019-08-16 8:09 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Guojia Liao, Guangbin Huang, Huzhong Tan
In-Reply-To: <1565942982-12105-1-git-send-email-tanhuazhong@huawei.com>
From: Guojia Liao <liaoguojia@huawei.com>
Some temporary variables do not need to be initialized that
they will be set before used, so this patch deletes the
initialization value of these temporary variables.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: Huzhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 7 +++----
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 2 +-
6 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 908d4f4..6bbba15 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -104,7 +104,6 @@ int hnae3_register_client(struct hnae3_client *client)
{
struct hnae3_client *client_tmp;
struct hnae3_ae_dev *ae_dev;
- int ret = 0;
if (!client)
return -ENODEV;
@@ -123,7 +122,7 @@ int hnae3_register_client(struct hnae3_client *client)
/* if the client could not be initialized on current port, for
* any error reasons, move on to next available port
*/
- ret = hnae3_init_client_instance(client, ae_dev);
+ int ret = hnae3_init_client_instance(client, ae_dev);
if (ret)
dev_err(&ae_dev->pdev->dev,
"match and instantiation failed for port, ret = %d\n",
@@ -164,7 +163,7 @@ void hnae3_register_ae_algo(struct hnae3_ae_algo *ae_algo)
const struct pci_device_id *id;
struct hnae3_ae_dev *ae_dev;
struct hnae3_client *client;
- int ret = 0;
+ int ret;
if (!ae_algo)
return;
@@ -258,7 +257,7 @@ int hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
const struct pci_device_id *id;
struct hnae3_ae_algo *ae_algo;
struct hnae3_client *client;
- int ret = 0;
+ int ret;
if (!ae_dev)
return -ENODEV;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 677bfe06..4260653 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -749,7 +749,7 @@ static int hns3_set_link_ksettings(struct net_device *netdev,
{
struct hnae3_handle *handle = hns3_get_handle(netdev);
const struct hnae3_ae_ops *ops = handle->ae_algo->ops;
- int ret = 0;
+ int ret;
/* Chip don't support this mode. */
if (cmd->base.speed == SPEED_1000 && cmd->base.duplex == DUPLEX_HALF)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index 05a4cdb..5ce9a8a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -1557,8 +1557,8 @@ int hclge_config_rocee_ras_interrupt(struct hclge_dev *hdev, bool en)
static void hclge_handle_rocee_ras_error(struct hnae3_ae_dev *ae_dev)
{
- enum hnae3_reset_type reset_type = HNAE3_NONE_RESET;
struct hclge_dev *hdev = ae_dev->priv;
+ enum hnae3_reset_type reset_type;
if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state) ||
hdev->pdev->revision < 0x21)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
index f30d112..e829101 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
@@ -404,8 +404,8 @@ static int hclge_tm_port_shaper_cfg(struct hclge_dev *hdev)
{
struct hclge_port_shapping_cmd *shap_cfg_cmd;
struct hclge_desc desc;
- u32 shapping_para = 0;
u8 ir_u, ir_b, ir_s;
+ u32 shapping_para;
int ret;
ret = hclge_shaper_para_calc(hdev->hw.mac.speed,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
index 55d3c78..4c2c945 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
@@ -43,7 +43,7 @@ static int hclgevf_cmd_csq_clean(struct hclgevf_hw *hw)
{
struct hclgevf_dev *hdev = container_of(hw, struct hclgevf_dev, hw);
struct hclgevf_cmq_ring *csq = &hw->cmq.csq;
- int clean = 0;
+ int clean;
u32 head;
head = hclgevf_read_dev(hw, HCLGEVF_NIC_CSQ_HEAD_REG);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index defc905..594cae8 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -2302,7 +2302,7 @@ static void hclgevf_uninit_msi(struct hclgevf_dev *hdev)
static int hclgevf_misc_irq_init(struct hclgevf_dev *hdev)
{
- int ret = 0;
+ int ret;
hclgevf_get_misc_vector(hdev);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/6] net: hns3: add or modify comments
From: Huazhong Tan @ 2019-08-16 8:09 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Guojia Liao, Zhongzhu Liu, Weihang Li,
Guangbin Huang, Huazhong Tan
In-Reply-To: <1565942982-12105-1-git-send-email-tanhuazhong@huawei.com>
From: Guojia Liao <liaoguojia@huawei.com>
To explain some code, this patch adds some comments, and modifies or
merges some comments to make them more neat.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Zhongzhu Liu <liuzhongzhu@huawei.com>
Signed-off-by: Weihang Li <liweihang@hisilicon.com>
Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 12 ++++++------
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 8 ++++----
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 8 ++++----
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 3 +++
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 8 ++++----
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 9 ++++-----
8 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 6c9fd58..3e21533 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -85,10 +85,10 @@ struct hnae3_queue {
void __iomem *io_base;
struct hnae3_ae_algo *ae_algo;
struct hnae3_handle *handle;
- int tqp_index; /* index in a handle */
- u32 buf_size; /* size for hnae_desc->addr, preset by AE */
- u16 tx_desc_num;/* total number of tx desc */
- u16 rx_desc_num;/* total number of rx desc */
+ int tqp_index; /* index in a handle */
+ u32 buf_size; /* size for hnae_desc->addr, preset by AE */
+ u16 tx_desc_num; /* total number of tx desc */
+ u16 rx_desc_num; /* total number of rx desc */
};
struct hns3_mac_stats {
@@ -96,7 +96,7 @@ struct hns3_mac_stats {
u64 rx_pause_cnt;
};
-/*hnae3 loop mode*/
+/* hnae3 loop mode */
enum hnae3_loop {
HNAE3_LOOP_APP,
HNAE3_LOOP_SERIAL_SERDES,
@@ -621,7 +621,7 @@ struct hnae3_handle {
struct pci_dev *pdev;
void *priv;
struct hnae3_ae_algo *ae_algo; /* the class who provides this handle */
- u64 flags; /* Indicate the capabilities for this handle*/
+ u64 flags; /* Indicate the capabilities for this handle */
union {
struct net_device *netdev; /* first member */
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 1750f80..a11d514 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -229,9 +229,9 @@ static void hns3_vector_gl_rl_init(struct hns3_enet_tqp_vector *tqp_vector,
/* initialize the configuration for interrupt coalescing.
* 1. GL (Interrupt Gap Limiter)
* 2. RL (Interrupt Rate Limiter)
+ *
+ * Default: enable interrupt coalescing self-adaptive and GL
*/
-
- /* Default: enable interrupt coalescing self-adaptive and GL */
tqp_vector->tx_group.coal.gl_adapt_enable = 1;
tqp_vector->rx_group.coal.gl_adapt_enable = 1;
@@ -4207,8 +4207,8 @@ int hns3_nic_reset_all_ring(struct hnae3_handle *h)
static void hns3_store_coal(struct hns3_nic_priv *priv)
{
/* ethtool only support setting and querying one coal
- * configuation for now, so save the vector 0' coal
- * configuation here in order to restore it.
+ * configuration for now, so save the vector 0' coal
+ * configuration here in order to restore it.
*/
memcpy(&priv->tx_coal, &priv->tqp_vector[0].tx_group.coal,
sizeof(struct hns3_enet_coalesce));
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 5b0ee1f..e37e64e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -302,7 +302,7 @@ struct hns3_desc_cb {
dma_addr_t dma; /* dma address of this desc */
void *buf; /* cpu addr for a desc */
- /* priv data for the desc, e.g. skb when use with ip stack*/
+ /* priv data for the desc, e.g. skb when use with ip stack */
void *priv;
u32 page_offset;
u32 length; /* length of the buffer */
@@ -325,11 +325,11 @@ enum hns3_pkt_l3type {
HNS3_L3_TYPE_MAC_PAUSE,
HNS3_L3_TYPE_PFC_PAUSE,/* 0x9*/
- /* reserved for 0xA~0xB*/
+ /* reserved for 0xA~0xB */
HNS3_L3_TYPE_CNM = 0xc,
- /* reserved for 0xD~0xE*/
+ /* reserved for 0xD~0xE */
HNS3_L3_TYPE_PARSE_FAIL = 0xf /* must be last */
};
@@ -354,7 +354,7 @@ enum hns3_pkt_ol3type {
HNS3_OL3_TYPE_IPV4_OPT = 4,
HNS3_OL3_TYPE_IPV6_EXT,
- /* reserved for 0x6~0xE*/
+ /* reserved for 0x6~0xE */
HNS3_OL3_TYPE_PARSE_FAIL = 0xf /* must be last */
};
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 185ff32..677bfe06 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -635,7 +635,7 @@ static void hns3_get_ksettings(struct hnae3_handle *h,
&cmd->base.speed,
&cmd->base.duplex);
- /* 2.get link mode*/
+ /* 2.get link mode */
if (ops->get_link_mode)
ops->get_link_mode(h,
cmd->link_modes.supported,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
index f0295d1..025184a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
@@ -897,14 +897,17 @@ static void hclge_dbg_fd_tcam_read(struct hclge_dev *hdev, u8 stage,
dev_info(&hdev->pdev->dev, " read result tcam key %s(%u):\n",
sel_x ? "x" : "y", loc);
+ /* tcam_data0 ~ tcam_data1 */
req = (u32 *)req1->tcam_data;
for (i = 0; i < 2; i++)
dev_info(&hdev->pdev->dev, "%08x\n", *req++);
+ /* tcam_data2 ~ tcam_data7 */
req = (u32 *)req2->tcam_data;
for (i = 0; i < 6; i++)
dev_info(&hdev->pdev->dev, "%08x\n", *req++);
+ /* tcam_data8 ~ tcam_data12 */
req = (u32 *)req3->tcam_data;
for (i = 0; i < 5; i++)
dev_info(&hdev->pdev->dev, "%08x\n", *req++);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index a3ca0e6..1d8dee1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2810,9 +2810,9 @@ static u32 hclge_check_event_cause(struct hclge_dev *hdev, u32 *clearval)
* defer the processing of the mailbox events. Since, we would have not
* cleared RX CMDQ event this time we would receive again another
* interrupt from H/W just for the mailbox.
+ *
+ * check for vector0 reset event sources
*/
-
- /* check for vector0 reset event sources */
if (BIT(HCLGE_VECTOR0_IMPRESET_INT_B) & rst_src_reg) {
dev_info(&hdev->pdev->dev, "IMP reset interrupt\n");
set_bit(HNAE3_IMP_RESET, &hdev->reset_pending);
@@ -8000,7 +8000,7 @@ int hclge_set_vlan_filter(struct hnae3_handle *handle, __be16 proto,
return -EBUSY;
}
- /* When port base vlan enabled, we use port base vlan as the vlan
+ /* when port base vlan enabled, we use port base vlan as the vlan
* filter entry. In this case, we don't update vlan filter table
* when user add new vlan or remove exist vlan, just update the vport
* vlan list. The vlan id in vlan list will be writen in vlan filter
@@ -8019,7 +8019,7 @@ int hclge_set_vlan_filter(struct hnae3_handle *handle, __be16 proto,
hclge_add_vport_vlan_table(vport, vlan_id,
writen_to_tbl);
} else if (is_kill) {
- /* When remove hw vlan filter failed, record the vlan id,
+ /* when remove hw vlan filter failed, record the vlan id,
* and try to remove it from hw later, to be consistence
* with stack
*/
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
index 5a7221e..f5da28a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -479,7 +479,7 @@ static void hclge_mbx_reset_vf_queue(struct hclge_vport *vport,
hclge_reset_vf_queue(vport, queue_id);
- /* send response msg to VF after queue reset complete*/
+ /* send response msg to VF after queue reset complete */
hclge_gen_resp_to_vf(vport, mbx_req, 0, NULL, 0);
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index d8b8281..defc905 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -1269,7 +1269,7 @@ static int hclgevf_set_vlan_filter(struct hnae3_handle *handle,
HCLGE_MBX_VLAN_FILTER, msg_data,
HCLGEVF_VLAN_MBX_MSG_LEN, false, NULL, 0);
- /* When remove hw vlan filter failed, record the vlan id,
+ /* when remove hw vlan filter failed, record the vlan id,
* and try to remove it from hw later, to be consistence
* with stack.
*/
@@ -1561,7 +1561,7 @@ static int hclgevf_reset(struct hclgevf_dev *hdev)
rtnl_lock();
- /* now, re-initialize the nic client and ae device*/
+ /* now, re-initialize the nic client and ae device */
ret = hclgevf_reset_stack(hdev);
if (ret) {
dev_err(&hdev->pdev->dev, "failed to reset VF stack\n");
@@ -1784,9 +1784,8 @@ static void hclgevf_reset_service_task(struct work_struct *work)
* 1b and 2. cases but we will not get any intimation about 1a
* from PF as cmdq would be in unreliable state i.e. mailbox
* communication between PF and VF would be broken.
- */
-
- /* if we are never geting into pending state it means either:
+ *
+ * if we are never geting into pending state it means either:
* 1. PF is not receiving our request which could be due to IMP
* reset
* 2. PF is screwed
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 5/6] net: hns3: prevent unnecessary MAC TNL interrupt
From: Huazhong Tan @ 2019-08-16 8:09 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
In-Reply-To: <1565942982-12105-1-git-send-email-tanhuazhong@huawei.com>
MAC TNL interrupt is used to collect statistic info about
link status changing suddenly when netdev is running.
But when stopping netdev, the enabled MAC TNL interrupt is
unnecessary, and may add some noises to the statistic info.
So this patch disables it before stopping MAC.
Fixes: a63457878b12 ("net: hns3: Add handling of MAC tunnel interruption")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 24b59f0..9d64c43 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -6380,6 +6380,8 @@ static void hclge_ae_stop(struct hnae3_handle *handle)
for (i = 0; i < handle->kinfo.num_tqps; i++)
hclge_reset_tqp(handle, i);
+ hclge_config_mac_tnl_int(hdev, false);
+
/* Mac disable */
hclge_cfg_mac_mode(hdev, false);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 3/6] net: hns3: fix error and incorrect format
From: Huazhong Tan @ 2019-08-16 8:09 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Guojia Liao, Weihang Li, Jian Shen,
Guangbin Huang, Huazhong Tan
In-Reply-To: <1565942982-12105-1-git-send-email-tanhuazhong@huawei.com>
From: Guojia Liao <liaoguojia@huawei.com>
The pointer type parameter should be declare as const for preventing
from its pointed value being unexpected modified.
The uninitialized variable can not be return directly. The default
return value is 0 if no abnormal result.
This patch fixes the preceding two errors, deletes redundant
declaration of a function and align one parameter.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Weihang Li <liweihang@hisilicon.com>
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 7 ++++---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 1 -
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 6bbba15..528f624 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -46,7 +46,7 @@ void hnae3_set_client_init_flag(struct hnae3_client *client,
EXPORT_SYMBOL(hnae3_set_client_init_flag);
static int hnae3_get_client_init_flag(struct hnae3_client *client,
- struct hnae3_ae_dev *ae_dev)
+ struct hnae3_ae_dev *ae_dev)
{
int inited = 0;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 4260653..0332d6f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -704,7 +704,7 @@ static int hns3_get_link_ksettings(struct net_device *netdev,
return 0;
}
-static int hns3_check_ksettings_param(struct net_device *netdev,
+static int hns3_check_ksettings_param(const struct net_device *netdev,
const struct ethtool_link_ksettings *cmd)
{
struct hnae3_handle *handle = hns3_get_handle(netdev);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 1d8dee1..24b59f0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -1128,6 +1128,7 @@ static void hclge_parse_link_mode(struct hclge_dev *hdev, u8 speed_ability)
else if (media_type == HNAE3_MEDIA_TYPE_BACKPLANE)
hclge_parse_backplane_link_mode(hdev, speed_ability);
}
+
static void hclge_parse_cfg(struct hclge_cfg *cfg, struct hclge_desc *desc)
{
struct hclge_cfg_param_cmd *req;
@@ -4364,8 +4365,8 @@ int hclge_bind_ring_with_vector(struct hclge_vport *vport,
struct hclge_dev *hdev = vport->back;
struct hnae3_ring_chain_node *node;
struct hclge_desc desc;
- struct hclge_ctrl_vector_chain_cmd *req
- = (struct hclge_ctrl_vector_chain_cmd *)desc.data;
+ struct hclge_ctrl_vector_chain_cmd *req =
+ (struct hclge_ctrl_vector_chain_cmd *)desc.data;
enum hclge_cmd_status status;
enum hclge_opcode_type op;
u16 tqp_type_and_id;
@@ -8656,7 +8657,7 @@ static int hclge_init_client_instance(struct hnae3_client *client,
}
}
- return ret;
+ return 0;
clear_nic:
hdev->nic_client = NULL;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index f6d9b57..7c28933 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -1000,7 +1000,6 @@ int hclge_buffer_alloc(struct hclge_dev *hdev);
int hclge_rss_init_hw(struct hclge_dev *hdev);
void hclge_rss_indir_init_cfg(struct hclge_dev *hdev);
-int hclge_inform_reset_assert_to_vf(struct hclge_vport *vport);
void hclge_mbx_handler(struct hclge_dev *hdev);
int hclge_reset_tqp(struct hnae3_handle *handle, u16 queue_id);
void hclge_reset_vf_queue(struct hclge_vport *vport, u16 queue_id);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 6/6] net: hns3: add phy_attached_info() to the hns3 driver
From: Huazhong Tan @ 2019-08-16 8:09 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Yonglong Liu, Huazhong Tan
In-Reply-To: <1565942982-12105-1-git-send-email-tanhuazhong@huawei.com>
From: Yonglong Liu <liuyonglong@huawei.com>
This patch adds the call to phy_attached_info() to the hns3 driver
to identify which exact PHY drivers and models is in use.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
index abb1b43..dc4dfd4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
@@ -231,6 +231,8 @@ int hclge_mac_connect_phy(struct hnae3_handle *handle)
linkmode_clear_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
phydev->advertising);
+ phy_attached_info(phydev);
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 4/6] net: hns3: change print level of RAS error log from warning to error
From: Huazhong Tan @ 2019-08-16 8:09 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Xiaofei Tan, Weihang Li, Huazhong Tan
In-Reply-To: <1565942982-12105-1-git-send-email-tanhuazhong@huawei.com>
From: Xiaofei Tan <tanxiaofei@huawei.com>
This patch changes print level of RAS error log from warning to error.
Because RAS error and its recovery process could cause application
failure. Also uses %u instead of %d when the parameter is unsigned.
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: Weihang Li <liweihang@hisilicon.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 88 +++++++++++-----------
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index 5ce9a8a..2425b3f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -637,8 +637,8 @@ static void hclge_log_error(struct device *dev, char *reg,
{
while (err->msg) {
if (err->int_msk & err_sts) {
- dev_warn(dev, "%s %s found [error status=0x%x]\n",
- reg, err->msg, err_sts);
+ dev_err(dev, "%s %s found [error status=0x%x]\n",
+ reg, err->msg, err_sts);
if (err->reset_level &&
err->reset_level != HNAE3_NONE_RESET)
set_bit(err->reset_level, reset_requests);
@@ -1163,8 +1163,8 @@ static int hclge_handle_mpf_ras_error(struct hclge_dev *hdev,
status = le32_to_cpu(*(desc_data + 3)) & BIT(0);
if (status) {
- dev_warn(dev, "SSU_ECC_MULTI_BIT_INT_1 ssu_mem32_ecc_mbit_err found [error status=0x%x]\n",
- status);
+ dev_err(dev, "SSU_ECC_MULTI_BIT_INT_1 ssu_mem32_ecc_mbit_err found [error status=0x%x]\n",
+ status);
set_bit(HNAE3_GLOBAL_RESET, &ae_dev->hw_err_reset_req);
}
@@ -1200,8 +1200,8 @@ static int hclge_handle_mpf_ras_error(struct hclge_dev *hdev,
desc_data = (__le32 *)&desc[5];
status = le32_to_cpu(*(desc_data + 1));
if (status) {
- dev_warn(dev, "PPU_MPF_ABNORMAL_INT_ST1 %s found\n",
- "rpu_rx_pkt_ecc_mbit_err");
+ dev_err(dev,
+ "PPU_MPF_ABNORMAL_INT_ST1 rpu_rx_pkt_ecc_mbit_err found\n");
set_bit(HNAE3_GLOBAL_RESET, &ae_dev->hw_err_reset_req);
}
@@ -1379,17 +1379,17 @@ static int hclge_log_rocee_axi_error(struct hclge_dev *hdev)
return ret;
}
- dev_info(dev, "AXI1: %08X %08X %08X %08X %08X %08X\n",
- le32_to_cpu(desc[0].data[0]), le32_to_cpu(desc[0].data[1]),
- le32_to_cpu(desc[0].data[2]), le32_to_cpu(desc[0].data[3]),
- le32_to_cpu(desc[0].data[4]), le32_to_cpu(desc[0].data[5]));
- dev_info(dev, "AXI2: %08X %08X %08X %08X %08X %08X\n",
- le32_to_cpu(desc[1].data[0]), le32_to_cpu(desc[1].data[1]),
- le32_to_cpu(desc[1].data[2]), le32_to_cpu(desc[1].data[3]),
- le32_to_cpu(desc[1].data[4]), le32_to_cpu(desc[1].data[5]));
- dev_info(dev, "AXI3: %08X %08X %08X %08X\n",
- le32_to_cpu(desc[2].data[0]), le32_to_cpu(desc[2].data[1]),
- le32_to_cpu(desc[2].data[2]), le32_to_cpu(desc[2].data[3]));
+ dev_err(dev, "AXI1: %08X %08X %08X %08X %08X %08X\n",
+ le32_to_cpu(desc[0].data[0]), le32_to_cpu(desc[0].data[1]),
+ le32_to_cpu(desc[0].data[2]), le32_to_cpu(desc[0].data[3]),
+ le32_to_cpu(desc[0].data[4]), le32_to_cpu(desc[0].data[5]));
+ dev_err(dev, "AXI2: %08X %08X %08X %08X %08X %08X\n",
+ le32_to_cpu(desc[1].data[0]), le32_to_cpu(desc[1].data[1]),
+ le32_to_cpu(desc[1].data[2]), le32_to_cpu(desc[1].data[3]),
+ le32_to_cpu(desc[1].data[4]), le32_to_cpu(desc[1].data[5]));
+ dev_err(dev, "AXI3: %08X %08X %08X %08X\n",
+ le32_to_cpu(desc[2].data[0]), le32_to_cpu(desc[2].data[1]),
+ le32_to_cpu(desc[2].data[2]), le32_to_cpu(desc[2].data[3]));
return 0;
}
@@ -1408,12 +1408,12 @@ static int hclge_log_rocee_ecc_error(struct hclge_dev *hdev)
return ret;
}
- dev_info(dev, "ECC1: %08X %08X %08X %08X %08X %08X\n",
- le32_to_cpu(desc[0].data[0]), le32_to_cpu(desc[0].data[1]),
- le32_to_cpu(desc[0].data[2]), le32_to_cpu(desc[0].data[3]),
- le32_to_cpu(desc[0].data[4]), le32_to_cpu(desc[0].data[5]));
- dev_info(dev, "ECC2: %08X %08X %08X\n", le32_to_cpu(desc[1].data[0]),
- le32_to_cpu(desc[1].data[1]), le32_to_cpu(desc[1].data[2]));
+ dev_err(dev, "ECC1: %08X %08X %08X %08X %08X %08X\n",
+ le32_to_cpu(desc[0].data[0]), le32_to_cpu(desc[0].data[1]),
+ le32_to_cpu(desc[0].data[2]), le32_to_cpu(desc[0].data[3]),
+ le32_to_cpu(desc[0].data[4]), le32_to_cpu(desc[0].data[5]));
+ dev_err(dev, "ECC2: %08X %08X %08X\n", le32_to_cpu(desc[1].data[0]),
+ le32_to_cpu(desc[1].data[1]), le32_to_cpu(desc[1].data[2]));
return 0;
}
@@ -1442,9 +1442,9 @@ static int hclge_log_rocee_ovf_error(struct hclge_dev *hdev)
le32_to_cpu(desc[0].data[0]);
while (err->msg) {
if (err->int_msk == err_sts) {
- dev_warn(dev, "%s [error status=0x%x] found\n",
- err->msg,
- le32_to_cpu(desc[0].data[0]));
+ dev_err(dev, "%s [error status=0x%x] found\n",
+ err->msg,
+ le32_to_cpu(desc[0].data[0]));
break;
}
err++;
@@ -1452,13 +1452,13 @@ static int hclge_log_rocee_ovf_error(struct hclge_dev *hdev)
}
if (le32_to_cpu(desc[0].data[1]) & HCLGE_ROCEE_OVF_ERR_INT_MASK) {
- dev_warn(dev, "ROCEE TSP OVF [error status=0x%x] found\n",
- le32_to_cpu(desc[0].data[1]));
+ dev_err(dev, "ROCEE TSP OVF [error status=0x%x] found\n",
+ le32_to_cpu(desc[0].data[1]));
}
if (le32_to_cpu(desc[0].data[2]) & HCLGE_ROCEE_OVF_ERR_INT_MASK) {
- dev_warn(dev, "ROCEE SCC OVF [error status=0x%x] found\n",
- le32_to_cpu(desc[0].data[2]));
+ dev_err(dev, "ROCEE SCC OVF [error status=0x%x] found\n",
+ le32_to_cpu(desc[0].data[2]));
}
return 0;
@@ -1486,10 +1486,10 @@ hclge_log_and_clear_rocee_ras_error(struct hclge_dev *hdev)
if (status & HCLGE_ROCEE_AXI_ERR_INT_MASK) {
if (status & HCLGE_ROCEE_RERR_INT_MASK)
- dev_warn(dev, "ROCEE RAS AXI rresp error\n");
+ dev_err(dev, "ROCEE RAS AXI rresp error\n");
if (status & HCLGE_ROCEE_BERR_INT_MASK)
- dev_warn(dev, "ROCEE RAS AXI bresp error\n");
+ dev_err(dev, "ROCEE RAS AXI bresp error\n");
reset_type = HNAE3_FUNC_RESET;
@@ -1499,7 +1499,7 @@ hclge_log_and_clear_rocee_ras_error(struct hclge_dev *hdev)
}
if (status & HCLGE_ROCEE_ECC_INT_MASK) {
- dev_warn(dev, "ROCEE RAS 2bit ECC error\n");
+ dev_err(dev, "ROCEE RAS 2bit ECC error\n");
reset_type = HNAE3_GLOBAL_RESET;
ret = hclge_log_rocee_ecc_error(hdev);
@@ -1640,16 +1640,16 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct hnae3_ae_dev *ae_dev)
/* Handling Non-fatal HNS RAS errors */
if (status & HCLGE_RAS_REG_NFE_MASK) {
- dev_warn(dev,
- "HNS Non-Fatal RAS error(status=0x%x) identified\n",
- status);
+ dev_err(dev,
+ "HNS Non-Fatal RAS error(status=0x%x) identified\n",
+ status);
hclge_handle_all_ras_errors(hdev);
}
/* Handling Non-fatal Rocee RAS errors */
if (hdev->pdev->revision >= 0x21 &&
status & HCLGE_RAS_REG_ROCEE_ERR_MASK) {
- dev_warn(dev, "ROCEE Non-Fatal RAS error identified\n");
+ dev_err(dev, "ROCEE Non-Fatal RAS error identified\n");
hclge_handle_rocee_ras_error(ae_dev);
}
@@ -1728,8 +1728,8 @@ static void hclge_handle_over_8bd_err(struct hclge_dev *hdev,
return;
}
- dev_warn(dev, "PPU_PF_ABNORMAL_INT_ST over_8bd_no_fe found, vf_id(%d), queue_id(%d)\n",
- vf_id, q_id);
+ dev_err(dev, "PPU_PF_ABNORMAL_INT_ST over_8bd_no_fe found, vf_id(%u), queue_id(%u)\n",
+ vf_id, q_id);
if (vf_id) {
if (vf_id >= hdev->num_alloc_vport) {
@@ -1746,8 +1746,8 @@ static void hclge_handle_over_8bd_err(struct hclge_dev *hdev,
ret = hclge_inform_reset_assert_to_vf(&hdev->vport[vf_id]);
if (ret)
- dev_warn(dev, "inform reset to vf(%d) failed %d!\n",
- hdev->vport->vport_id, ret);
+ dev_err(dev, "inform reset to vf(%u) failed %d!\n",
+ hdev->vport->vport_id, ret);
} else {
set_bit(HNAE3_FUNC_RESET, reset_requests);
}
@@ -1793,8 +1793,8 @@ static int hclge_handle_mpf_msix_error(struct hclge_dev *hdev,
status = le32_to_cpu(*(desc_data + 2)) &
HCLGE_PPU_MPF_INT_ST2_MSIX_MASK;
if (status)
- dev_warn(dev, "PPU_MPF_ABNORMAL_INT_ST2 rx_q_search_miss found [dfx status=0x%x\n]",
- status);
+ dev_err(dev, "PPU_MPF_ABNORMAL_INT_ST2 rx_q_search_miss found [dfx status=0x%x\n]",
+ status);
/* clear all main PF MSIx errors */
ret = hclge_clear_hw_msix_error(hdev, desc, true, mpf_bd_num);
@@ -1988,7 +1988,7 @@ void hclge_handle_all_hns_hw_errors(struct hnae3_ae_dev *ae_dev)
/* Handle Non-fatal HNS RAS errors */
if (status & HCLGE_RAS_REG_NFE_MASK) {
- dev_warn(dev, "HNS hw error(RAS) identified during init\n");
+ dev_err(dev, "HNS hw error(RAS) identified during init\n");
hclge_handle_all_ras_errors(hdev);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/6] net: hns3: add some cleanups & bugfix
From: Huazhong Tan @ 2019-08-16 8:09 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
This patch-set includes cleanups and bugfix for the HNS3 ethernet
controller driver.
[patch 01/06 - 03/06] adds some cleanups.
[patch 04/06] changes the print level of RAS.
[patch 05/06] fixes a bug related to MAC TNL.
[patch 06/06] adds phy_attached_info().
Guojia Liao (3):
net: hns3: add or modify comments
net: hns3: modify redundant initialization of variable
net: hns3: fix error and incorrect format
Huazhong Tan (1):
net: hns3: prevent unnecessary MAC TNL interrupt
Xiaofei Tan (1):
net: hns3: change print level of RAS error log from warning to error
Yonglong Liu (1):
net: hns3: add phy_attached_info() to the hns3 driver
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 9 +--
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 12 +--
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 8 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 8 +-
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 6 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 3 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 90 +++++++++++-----------
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 17 ++--
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 1 -
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 2 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 2 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 2 +-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 2 +-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 11 ++-
14 files changed, 89 insertions(+), 84 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH] arm64: do_csum: implement accelerated scalar version
From: Shaokun Zhang @ 2019-08-16 8:15 UTC (permalink / raw)
To: Will Deacon
Cc: Robin Murphy, Ard Biesheuvel, linux-arm-kernel, netdev,
ilias.apalodimas, huanglingyan (A), steve.capper
In-Reply-To: <20190815164609.GI2015@fuggles.cambridge.arm.com>
Hi Will,
On 2019/8/16 0:46, Will Deacon wrote:
> On Thu, May 16, 2019 at 11:14:35AM +0800, Zhangshaokun wrote:
>> On 2019/5/15 17:47, Will Deacon wrote:
>>> On Mon, Apr 15, 2019 at 07:18:22PM +0100, Robin Murphy wrote:
>>>> On 12/04/2019 10:52, Will Deacon wrote:
>>>>> I'm waiting for Robin to come back with numbers for a C implementation.
>>>>>
>>>>> Robin -- did you get anywhere with that?
>>>>
>>>> Still not what I would call finished, but where I've got so far (besides an
>>>> increasingly elaborate test rig) is as below - it still wants some unrolling
>>>> in the middle to really fly (and actual testing on BE), but the worst-case
>>>> performance already equals or just beats this asm version on Cortex-A53 with
>>>> GCC 7 (by virtue of being alignment-insensitive and branchless except for
>>>> the loop). Unfortunately, the advantage of C code being instrumentable does
>>>> also come around to bite me...
>>>
>>> Is there any interest from anybody in spinning a proper patch out of this?
>>> Shaokun?
>>
>> HiSilicon's Kunpeng920(Hi1620) benefits from do_csum optimization, if Ard and
>> Robin are ok, Lingyan or I can try to do it.
>> Of course, if any guy posts the patch, we are happy to test it.
>> Any will be ok.
>
> I don't mind who posts it, but Robin is super busy with SMMU stuff at the
> moment so it probably makes more sense for you or Lingyan to do it.
Thanks for restarting this topic, I or Lingyan will do it soon.
Thanks,
Shaokun
>
> Will
>
> .
>
^ permalink raw reply
* Re: [PATCH net-next] r8152: divide the tx and rx bottom functions
From: Eric Dumazet @ 2019-08-16 8:19 UTC (permalink / raw)
To: Hayes Wang, netdev@vger.kernel.org; +Cc: nic_swsd, linux-kernel@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2F18D470D@RTITMBSVM03.realtek.com.tw>
On 8/16/19 10:10 AM, Hayes Wang wrote:
> Eric Dumazet [mailto:eric.dumazet@gmail.com]
>> Sent: Friday, August 16, 2019 2:40 PM
> [...]
>> tasklet and NAPI are scheduled on the same core (the current
>> cpu calling napi_schedule() or tasklet_schedule())
>>
>> I would rather not add this dubious tasklet, and instead try to understand
>> what is wrong in this driver ;)
>>
>> The various napi_schedule() calls are suspect IMO.
>
> The original method as following.
>
> static int r8152_poll(struct napi_struct *napi, int budget)
> {
> struct r8152 *tp = container_of(napi, struct r8152, napi);
> int work_done;
>
> work_done = rx_bottom(tp, budget); <-- RX
> bottom_half(tp); <-- Tx (tx_bottom)
> [...]
>
> The rx_bottom and tx_bottom would only be called in r8152_poll.
> That is, tx_bottom wouldn't be run unless rx_bottom is finished.
> And, rx_bottom would be called if tx_bottom is running.
>
> If the traffic is busy. rx_bottom or tx_bottom may take a lot
> of time to deal with the packets. And the one would increase
> the latency time for the other one.
>
> Therefore, when I separate the tx_bottom and rx_bottom to
> different tasklet and napi, the callback functions of tx and
> rx may schedule the tasklet and napi to different cpu. Then,
> the rx_bottom and tx_bottom may be run at the same time.
Your patch makes absolutely no guarantee of doing what you
want, I am afraid.
>
> Take our arm platform for example. There are five cpus to
> handle the interrupt of USB host controller. When the rx is
> completed, cpu #1 may handle the interrupt and napi would
> be scheduled. When the tx is finished, cpu #2 may handle
> the interrupt and the tasklet is scheduled. Then, napi is
> run on cpu #1, and tasklet is run on cpu #2.
>
>> Also rtl8152_start_xmit() uses skb_queue_tail(&tp->tx_queue, skb);
>>
>> But I see nothing really kicking the transmit if tx_free is empty ?
>
> Tx callback function "write_bulk_callback" would deal with it.
> The callback function would check if there are packets waiting
> to be sent.
Which callback ?
After an idle period (no activity, no prior packets being tx-completed ...),
a packet is sent by the upper stack, enters the ndo_start_xmit() of a network driver.
This driver ndo_start_xmit() simply adds an skb to a local list, and returns.
Where/how is scheduled this callback ?
Some kind of timer ?
An (unrelated) incoming packet ?
>
>
> Best Regards,
> Hayes
>
>
^ permalink raw reply
* [PATCH REPOST 0/2] can: flexcan: fix PM and wakeup issue
From: Joakim Zhang @ 2019-08-16 8:20 UTC (permalink / raw)
To: mkl@pengutronix.de, linux-can@vger.kernel.org, sean@geanix.com
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Joakim Zhang
This patch set intends to fix Flecan PM and wakeup issue.
Joakim Zhang (2):
can: flexcan: fix deadlock when using self wakeup
can: flexcan: add LPSR mode support for i.MX7D
drivers/net/can/flexcan.c | 34 ++++++++++++++++++++++++++++++----
1 file changed, 30 insertions(+), 4 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH REPOST 1/2] can: flexcan: fix deadlock when using self wakeup
From: Joakim Zhang @ 2019-08-16 8:20 UTC (permalink / raw)
To: mkl@pengutronix.de, linux-can@vger.kernel.org, sean@geanix.com
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Joakim Zhang
In-Reply-To: <20190816081749.19300-1-qiangqing.zhang@nxp.com>
As reproted by Sean Nyekjaer below:
When suspending, when there is still can traffic on the interfaces the
flexcan immediately wakes the platform again. As it should :-). But it
throws this error msg:
[ 3169.378661] PM: noirq suspend of devices failed
On the way down to suspend the interface that throws the error message does
call flexcan_suspend but fails to call flexcan_noirq_suspend. That means the
flexcan_enter_stop_mode is called, but on the way out of suspend the driver
only calls flexcan_resume and skips flexcan_noirq_resume, thus it doesn't call
flexcan_exit_stop_mode. This leaves the flexcan in stop mode, and with the
current driver it can't recover from this even with a soft reboot, it requires
a hard reboot.
The best way to exit stop mode is in Wake Up interrupt context, and then
suspend() and resume() functions can be symmetric. However, stop mode
request and ack will be controlled by SCU(System Control Unit) firmware(manage
clock,power,stop mode, etc. by Cortex-M4 core) in coming i.MX8(QM/QXP). And SCU
firmware interface can't be available in interrupt context.
For compatibillity, the wake up mechanism can't be symmetric, so we need
in_stop_mode hack.
Fixes: de3578c198c6 ("can: flexcan: add self wakeup support")
Reported-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Changelog:
V1->V2:
* add Reported-by tag.
* rebase on patch: can:flexcan:fix stop mode acknowledgment.
V2->V3:
* move into a patch set.
---
drivers/net/can/flexcan.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 56fa98d7aa90..de2bf71b335b 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -282,6 +282,7 @@ struct flexcan_priv {
const struct flexcan_devtype_data *devtype_data;
struct regulator *reg_xceiver;
struct flexcan_stop_mode stm;
+ bool in_stop_mode;
/* Read and Write APIs */
u32 (*read)(void __iomem *addr);
@@ -1636,6 +1637,8 @@ static int __maybe_unused flexcan_suspend(struct device *device)
err = flexcan_enter_stop_mode(priv);
if (err)
return err;
+
+ priv->in_stop_mode = true;
} else {
err = flexcan_chip_disable(priv);
if (err)
@@ -1660,6 +1663,15 @@ static int __maybe_unused flexcan_resume(struct device *device)
netif_device_attach(dev);
netif_start_queue(dev);
if (device_may_wakeup(device)) {
+ if (priv->in_stop_mode) {
+ flexcan_enable_wakeup_irq(priv, false);
+ err = flexcan_exit_stop_mode(priv);
+ if (err)
+ return err;
+
+ priv->in_stop_mode = false;
+ }
+
disable_irq_wake(dev->irq);
} else {
err = flexcan_chip_enable(priv);
@@ -1675,6 +1687,11 @@ static int __maybe_unused flexcan_noirq_suspend(struct device *device)
struct net_device *dev = dev_get_drvdata(device);
struct flexcan_priv *priv = netdev_priv(dev);
+ /* Need to enable wakeup interrupt in noirq suspend stage. Otherwise,
+ * it will trigger continuously wakeup interrupt if the wakeup event
+ * comes before noirq suspend stage, and simultaneously it has enter
+ * the stop mode.
+ */
if (netif_running(dev) && device_may_wakeup(device))
flexcan_enable_wakeup_irq(priv, true);
@@ -1687,11 +1704,17 @@ static int __maybe_unused flexcan_noirq_resume(struct device *device)
struct flexcan_priv *priv = netdev_priv(dev);
int err;
+ /* Need to exit stop mode in noirq resume stage. Otherwise, it will
+ * trigger continuously wakeup interrupt if the wakeup event comes,
+ * and simultaneously it has still in stop mode.
+ */
if (netif_running(dev) && device_may_wakeup(device)) {
flexcan_enable_wakeup_irq(priv, false);
err = flexcan_exit_stop_mode(priv);
if (err)
return err;
+
+ priv->in_stop_mode = false;
}
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH REPOST 2/2] can: flexcan: add LPSR mode support for i.MX7D
From: Joakim Zhang @ 2019-08-16 8:20 UTC (permalink / raw)
To: mkl@pengutronix.de, linux-can@vger.kernel.org, sean@geanix.com
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Joakim Zhang
In-Reply-To: <20190816081749.19300-1-qiangqing.zhang@nxp.com>
For i.MX7D LPSR mode, the controller will lost power and got the
configuration state lost after system resume back. (coming i.MX8QM/QXP
will also completely power off the domain, the controller state will be
lost and needs restore).
So we need to set pinctrl state again and re-start chip to do
re-configuration after resume.
For wakeup case, it should not set pinctrl to sleep state by
pinctrl_pm_select_sleep_state.
For interface is not up before suspend case, we don't need
re-configure as it will be configured by user later by interface up.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
ChangeLog:
V1->V2:
* rebase on linux-can/testing.
* move into a patch set.
---
drivers/net/can/flexcan.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index de2bf71b335b..b3edaf6a5a61 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -25,6 +25,7 @@
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/regmap.h>
#define DRV_NAME "flexcan"
@@ -1640,9 +1641,9 @@ static int __maybe_unused flexcan_suspend(struct device *device)
priv->in_stop_mode = true;
} else {
- err = flexcan_chip_disable(priv);
- if (err)
- return err;
+ flexcan_chip_stop(dev);
+
+ pinctrl_pm_select_sleep_state(device);
}
netif_stop_queue(dev);
netif_device_detach(dev);
@@ -1674,7 +1675,9 @@ static int __maybe_unused flexcan_resume(struct device *device)
disable_irq_wake(dev->irq);
} else {
- err = flexcan_chip_enable(priv);
+ pinctrl_pm_select_default_state(device);
+
+ err = flexcan_chip_start(dev);
if (err)
return err;
}
--
2.17.1
^ permalink raw reply related
* Re: WARNING in is_bpf_text_address
From: Will Deacon @ 2019-08-16 8:21 UTC (permalink / raw)
To: Bart Van Assche
Cc: syzbot, akpm, ast, bpf, daniel, davem, dvyukov, hawk, hdanton,
jakub.kicinski, johannes.berg, johannes, john.fastabend, kafai,
linux-kernel, longman, mingo, netdev, paulmck, peterz,
songliubraving, syzkaller-bugs, tglx, tj, torvalds, will.deacon,
xdp-newbies, yhs
In-Reply-To: <456d0da6-3e16-d3fc-ecf6-7abb410bf689@acm.org>
On Thu, Aug 15, 2019 at 06:39:56PM -0700, Bart Van Assche wrote:
> On 8/15/19 12:51 AM, Will Deacon wrote:
> > On Sat, Aug 10, 2019 at 05:24:06PM -0700, syzbot wrote:
> > > The bug was bisected to:
> > >
> > > commit a0b0fd53e1e67639b303b15939b9c653dbe7a8c4
> > > Author: Bart Van Assche <bvanassche@acm.org>
> > > Date: Thu Feb 14 23:00:46 2019 +0000
> > >
> > > locking/lockdep: Free lock classes that are no longer in use
> > >
> > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=152f6a9da00000
> > > final crash: https://syzkaller.appspot.com/x/report.txt?x=172f6a9da00000
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=132f6a9da00000
> >
> > I know you don't think much to these reports, but please could you have a
> > look (even if it's just to declare it a false positive)?
>
> Had you already noticed the following message?
>
> https://lore.kernel.org/bpf/d76d7a63-7854-e92d-30cb-52546d333ffe@iogearbox.net/
>
> From that message: "Hey Bart, don't think it's related in any way to your
> commit. I'll allocate some time on working on this issue today, thanks!"
Apologies, but I hadn't received that when I sent my initial email. Anyway,
just wanted to make sure somebody was looking into it!
Will
^ permalink raw reply
* Re: [PATCH net] tunnel: fix dev null pointer dereference when send pkg larger than mtu in collect_md mode
From: Eric Dumazet @ 2019-08-16 8:23 UTC (permalink / raw)
To: Hangbin Liu
Cc: netdev, Stefano Brivio, wenxu, Alexei Starovoitov,
David S . Miller
In-Reply-To: <20190816032418.GX18865@dhcp-12-139.nay.redhat.com>
On 8/16/19 5:24 AM, Hangbin Liu wrote:
> Hi Eric,
>
> Thanks for the review.
> On Thu, Aug 15, 2019 at 11:16:58AM +0200, Eric Dumazet wrote:
>>> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
>>> index 38c02bb62e2c..c6713c7287df 100644
>>> --- a/net/ipv4/ip_tunnel.c
>>> +++ b/net/ipv4/ip_tunnel.c
>>> @@ -597,6 +597,9 @@ void ip_md_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
>>> goto tx_error;
>>> }
>>>
>>> + if (skb_dst(skb) && !skb_dst(skb)->dev)
>>> + skb_dst(skb)->dev = rt->dst.dev;
>>> +
>>
>>
>> IMO this looks wrong.
>> This dst seems shared.
>
> If the dst is shared, it may cause some problem. Could you point me where the
> dst may be shared possibly?
>
dst are inherently shared.
This is why we have a refcount on them.
Only when the dst has been allocated by the current thread we can make changes on them.
^ permalink raw reply
* AW: can: tcan4x5x: spi bits_per_word issue on Raspberry PI
From: FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu) @ 2019-08-16 8:26 UTC (permalink / raw)
To: Patrick Menschel, Marc Kleine-Budde, linux-can@vger.kernel.org,
netdev@vger.kernel.org
Cc: Dan Murphy
In-Reply-To: <e6577cc2-89fc-9428-b73e-47f41eff2949@posteo.de>
> >> Now I have another really confusing problem. Anything I write to SPI is written little endian. The tcan chip expects big endian.
> >> Anything I read from SPI is treated as little endian but is big endian. Does anyone know why this happens?
> >> Is there a flag or something I can set for the SPI device/wire to fix this?
> >
> > Have you changed the bits_per_word to 8? Then you read just a stream
> > of bytes. If you tread them as an u32 they are in host order.
> >
@Marc
Yes, I changed bits_per_word to 8. Since the PI does not support any values apart from
8 and 9 this seems to be the only way.
> > Marc
> >
>
>
> Hi,
>
> from my experience with SPIDEV on RPI, the driver uses a char array for I/O.
> As the RPI code is build little endian, logically little endian comes out of SPI. You
> basically have to invert the bit and byte order by hand for a big endian slave.
>
@Patrick, Marc
You both are right. This seems to be the problem. The SPI driver uses char arrays
and the tcan driver treats them as u32.
I will try to change the byte order by hand to get it running for my project. But in the long
run, this does not seem to be a proper solution...
Regards,
Konstantin
> Clock Phase and Clock Polarity are also an issue on the RPI as at least SPIDEV
> kindly overlooks any options set previously.
> I had my share of this while writing a test app for a MAX31855 IC and ended up
> casting a little endian array to a big endian structure.
>
> Regards,
> Patrick
^ permalink raw reply
* Re: AW: can: tcan4x5x: spi bits_per_word issue on Raspberry PI
From: Marc Kleine-Budde @ 2019-08-16 8:37 UTC (permalink / raw)
To: FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu),
Patrick Menschel, linux-can@vger.kernel.org,
netdev@vger.kernel.org
Cc: Dan Murphy
In-Reply-To: <47108d803086402c83d1073f3e3a62bb@escrypt.com>
[-- Attachment #1.1: Type: text/plain, Size: 1583 bytes --]
On 8/16/19 10:26 AM, FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu)
wrote:
>>> Have you changed the bits_per_word to 8? Then you read just a stream
>>> of bytes. If you tread them as an u32 they are in host order.
>
> @Marc
> Yes, I changed bits_per_word to 8. Since the PI does not support any values apart from
> 8 and 9 this seems to be the only way.
ok
>> from my experience with SPIDEV on RPI, the driver uses a char array for I/O.
>> As the RPI code is build little endian, logically little endian comes out of SPI. You
>> basically have to invert the bit and byte order by hand for a big endian slave.
>
> @Patrick, Marc
> You both are right. This seems to be the problem. The SPI driver uses char arrays
> and the tcan driver treats them as u32.
No, the tcan configures the spi device or rather the host driver that
the word len should be 32 bit. If you change the value to 8 you break
the assumptions in the driver.
> I will try to change the byte order by hand to get it running for my project. But in the long
> run, this does not seem to be a proper solution...
Indeed, that's the wrong approach. I don't have any HW here to test, but
I'll prepare a patch. BTW: the driver is broken in several ways, when it
comes to the regmap configuration.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH net-next] r8152: divide the tx and rx bottom functions
From: Hayes Wang @ 2019-08-16 9:08 UTC (permalink / raw)
To: Eric Dumazet, netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org
In-Reply-To: <68015004-fb60-f6c6-05b0-610466223cf5@gmail.com>
Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Friday, August 16, 2019 4:20 PM
[...]
> Which callback ?
The USB device has two endpoints for Tx and Rx.
If I submit tx or rx URB to the USB host controller,
the relative callback functions would be called, when
they are finished. For rx, it is read_bulk_callback.
For tx, it is write_bulk_callback.
> After an idle period (no activity, no prior packets being tx-completed ...),
> a packet is sent by the upper stack, enters the ndo_start_xmit() of a network
> driver.
>
> This driver ndo_start_xmit() simply adds an skb to a local list, and returns.
Base on the current method (without tasklet), when
ndo_start_xmit() is called, napi_schedule is called only
if there is at least one free buffer (!list_empty(&tp->tx_free))
to transmit the packet. Then, the flow would be as following.
- Call r8152_poll
-- Call bottom_half
--- Call tx_bottom
---- Call r8152_tx_agg_fill
----- submit tx urb
- Call write_bulk_callback if tx is completed
When the tx transfer is completed, write_bulk_callback would
be called. And it would check if there is any tx packet
in &tp->tx_queue and determine whether it is necessary to
schedule the napi again or not.
> Where/how is scheduled this callback ?
For tx, you could find the following code in r8152_tx_agg_fill().
usb_fill_bulk_urb(agg->urb, tp->udev, usb_sndbulkpipe(tp->udev, 2),
agg->head, (int)(tx_data - (u8 *)agg->head),
(usb_complete_t)write_bulk_callback, agg);
ret = usb_submit_urb(agg->urb, GFP_ATOMIC);
For rx you could find the following code in r8152_submit_rx().
usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
agg->buffer, tp->rx_buf_sz,
(usb_complete_t)read_bulk_callback, agg);
ret = usb_submit_urb(agg->urb, mem_flags);
> Some kind of timer ?
> An (unrelated) incoming packet ?
When the rx or tx is completed, a interrupt of USB
host controller would be triggered. Then, the callback
functions would be called.
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH bpf-next 3/5] i40e: Enable XDP_SKIP_BPF option for AF_XDP sockets
From: kbuild test robot @ 2019-08-16 9:21 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: kbuild-all, magnus.karlsson, bjorn.topel, netdev, bpf,
sridhar.samudrala, intel-wired-lan, maciej.fijalkowski,
tom.herbert
In-Reply-To: <1565840783-8269-4-git-send-email-sridhar.samudrala@intel.com>
[-- Attachment #1: Type: text/plain, Size: 6746 bytes --]
Hi Sridhar,
I love your patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/xsk-Convert-bool-zc-field-in-struct-xdp_umem-to-a-u32-bitmap/20190816-144642
base: https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: x86_64-lkp (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/net/ethernet/intel/i40e/i40e_txrx.c: In function 'i40e_run_xdp':
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2215:9: error: implicit declaration of function 'xsk_umem_rcv'; did you mean 'xsk_rcv'? [-Werror=implicit-function-declaration]
err = xsk_umem_rcv(umem, xdp);
^~~~~~~~~~~~
xsk_rcv
drivers/net/ethernet/intel/i40e/i40e_txrx.c: In function 'i40e_finalize_xdp_rx':
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2322:4: error: implicit declaration of function 'xsk_umem_flush'; did you mean 'xsk_umem_fq_reuse'? [-Werror=implicit-function-declaration]
xsk_umem_flush(umem);
^~~~~~~~~~~~~~
xsk_umem_fq_reuse
cc1: some warnings being treated as errors
--
drivers/net/ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_run_xdp_zc':
>> drivers/net/ethernet/intel/i40e/i40e_xsk.c:199:9: error: implicit declaration of function 'xsk_umem_rcv'; did you mean 'xsk_rcv'? [-Werror=implicit-function-declaration]
err = xsk_umem_rcv(rx_ring->xsk_umem, xdp);
^~~~~~~~~~~~
xsk_rcv
cc1: some warnings being treated as errors
vim +2215 drivers/net/ethernet/intel/i40e/i40e_txrx.c
2190
2191 /**
2192 * i40e_run_xdp - run an XDP program
2193 * @rx_ring: Rx ring being processed
2194 * @xdp: XDP buffer containing the frame
2195 **/
2196 static struct sk_buff *i40e_run_xdp(struct i40e_ring *rx_ring,
2197 struct xdp_buff *xdp)
2198 {
2199 int err, result = I40E_XDP_PASS;
2200 struct i40e_ring *xdp_ring;
2201 struct bpf_prog *xdp_prog;
2202 struct xdp_umem *umem;
2203 u32 act;
2204
2205 rcu_read_lock();
2206 xdp_prog = READ_ONCE(rx_ring->xdp_prog);
2207
2208 if (!xdp_prog)
2209 goto xdp_out;
2210
2211 prefetchw(xdp->data_hard_start); /* xdp_frame write */
2212
2213 umem = xdp_get_umem_from_qid(rx_ring->netdev, rx_ring->queue_index);
2214 if (xsk_umem_skip_bpf(umem)) {
> 2215 err = xsk_umem_rcv(umem, xdp);
2216 result = !err ? I40E_XDP_REDIR : I40E_XDP_CONSUMED;
2217 goto xdp_out;
2218 }
2219
2220 act = bpf_prog_run_xdp(xdp_prog, xdp);
2221 switch (act) {
2222 case XDP_PASS:
2223 break;
2224 case XDP_TX:
2225 xdp_ring = rx_ring->vsi->xdp_rings[rx_ring->queue_index];
2226 result = i40e_xmit_xdp_tx_ring(xdp, xdp_ring);
2227 break;
2228 case XDP_REDIRECT:
2229 err = xdp_do_redirect(rx_ring->netdev, xdp, xdp_prog);
2230 result = !err ? I40E_XDP_REDIR : I40E_XDP_CONSUMED;
2231 break;
2232 default:
2233 bpf_warn_invalid_xdp_action(act);
2234 /* fall through */
2235 case XDP_ABORTED:
2236 trace_xdp_exception(rx_ring->netdev, xdp_prog, act);
2237 /* fall through -- handle aborts by dropping packet */
2238 case XDP_DROP:
2239 result = I40E_XDP_CONSUMED;
2240 break;
2241 }
2242 xdp_out:
2243 rcu_read_unlock();
2244 return ERR_PTR(-result);
2245 }
2246
2247 /**
2248 * i40e_rx_buffer_flip - adjusted rx_buffer to point to an unused region
2249 * @rx_ring: Rx ring
2250 * @rx_buffer: Rx buffer to adjust
2251 * @size: Size of adjustment
2252 **/
2253 static void i40e_rx_buffer_flip(struct i40e_ring *rx_ring,
2254 struct i40e_rx_buffer *rx_buffer,
2255 unsigned int size)
2256 {
2257 #if (PAGE_SIZE < 8192)
2258 unsigned int truesize = i40e_rx_pg_size(rx_ring) / 2;
2259
2260 rx_buffer->page_offset ^= truesize;
2261 #else
2262 unsigned int truesize = SKB_DATA_ALIGN(i40e_rx_offset(rx_ring) + size);
2263
2264 rx_buffer->page_offset += truesize;
2265 #endif
2266 }
2267
2268 /**
2269 * i40e_xdp_ring_update_tail - Updates the XDP Tx ring tail register
2270 * @xdp_ring: XDP Tx ring
2271 *
2272 * This function updates the XDP Tx ring tail register.
2273 **/
2274 void i40e_xdp_ring_update_tail(struct i40e_ring *xdp_ring)
2275 {
2276 /* Force memory writes to complete before letting h/w
2277 * know there are new descriptors to fetch.
2278 */
2279 wmb();
2280 writel_relaxed(xdp_ring->next_to_use, xdp_ring->tail);
2281 }
2282
2283 /**
2284 * i40e_update_rx_stats - Update Rx ring statistics
2285 * @rx_ring: rx descriptor ring
2286 * @total_rx_bytes: number of bytes received
2287 * @total_rx_packets: number of packets received
2288 *
2289 * This function updates the Rx ring statistics.
2290 **/
2291 void i40e_update_rx_stats(struct i40e_ring *rx_ring,
2292 unsigned int total_rx_bytes,
2293 unsigned int total_rx_packets)
2294 {
2295 u64_stats_update_begin(&rx_ring->syncp);
2296 rx_ring->stats.packets += total_rx_packets;
2297 rx_ring->stats.bytes += total_rx_bytes;
2298 u64_stats_update_end(&rx_ring->syncp);
2299 rx_ring->q_vector->rx.total_packets += total_rx_packets;
2300 rx_ring->q_vector->rx.total_bytes += total_rx_bytes;
2301 }
2302
2303 /**
2304 * i40e_finalize_xdp_rx - Bump XDP Tx tail and/or flush redirect map
2305 * @rx_ring: Rx ring
2306 * @xdp_res: Result of the receive batch
2307 *
2308 * This function bumps XDP Tx tail and/or flush redirect map, and
2309 * should be called when a batch of packets has been processed in the
2310 * napi loop.
2311 **/
2312 void i40e_finalize_xdp_rx(struct i40e_ring *rx_ring, unsigned int xdp_res)
2313 {
2314 if (xdp_res & I40E_XDP_REDIR) {
2315 struct xdp_umem *umem;
2316
2317 umem = rx_ring->xsk_umem;
2318 if (!umem)
2319 umem = xdp_get_umem_from_qid(rx_ring->netdev,
2320 rx_ring->queue_index);
2321 if (xsk_umem_skip_bpf(umem))
> 2322 xsk_umem_flush(umem);
2323 else
2324 xdp_do_flush_map();
2325 }
2326
2327 if (xdp_res & I40E_XDP_TX) {
2328 struct i40e_ring *xdp_ring =
2329 rx_ring->vsi->xdp_rings[rx_ring->queue_index];
2330
2331 i40e_xdp_ring_update_tail(xdp_ring);
2332 }
2333 }
2334
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27706 bytes --]
^ permalink raw reply
* Re: linux-next: Signed-off-by missing for commits in the net-next tree
From: Andy Grover @ 2019-08-16 9:15 UTC (permalink / raw)
To: Gerd Rausch, Stephen Rothwell, David Miller, Networking,
Chris Mason
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Andy Grover,
Chris Mason
In-Reply-To: <8fd20efa-8e3d-eca2-8adf-897428a2f9ad@oracle.com>
On 8/16/19 3:06 PM, Gerd Rausch wrote:
> Hi,
>
> Just added the e-mail addresses I found using a simple "google search",
> in order to reach out to the original authors of these commits:
> Chris Mason and Andy Grover.
>
> I'm hoping they still remember their work from 7-8 years ago.
Yes looks like what I was working on. What did you need from me? It's
too late to amend the commitlogs...
-- Andy
>
> Thanks,
>
> Gerd
>
> On 15/08/2019 14.53, Stephen Rothwell wrote:
>> Hi all,
>>
>> Commits
>>
>> 11740ef44829 ("rds: check for excessive looping in rds_send_xmit")
>> 65dedd7fe1f2 ("RDS: limit the number of times we loop in rds_send_xmit")
>>
>> are missing a Signed-off-by from their authors.
>>
^ permalink raw reply
* [PATCH v2 00/10] Add definition for the number of standard PCI BARs
From: Denis Efremov @ 2019-08-16 9:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, linux-kernel, linux-pci, Sebastian Ott,
Gerald Schaefer, H. Peter Anvin, Giuseppe Cavallaro,
Alexandre Torgue, Matt Porter, Alexandre Bounine, Peter Jones,
Bartlomiej Zolnierkiewicz, Cornelia Huck, Alex Williamson,
Andrew Murray, Jose Abreu, kvm, linux-fbdev, netdev, x86,
linux-s390
Code that iterates over all standard PCI BARs typically uses
PCI_STD_RESOURCE_END, but this is error-prone because it requires
"i <= PCI_STD_RESOURCE_END" rather than something like
"i < PCI_STD_NUM_BARS". We could add such a definition and use it the same
way PCI_SRIOV_NUM_BARS is used. There is already the definition
PCI_BAR_COUNT for s390 only. Thus, this patchset introduces it globally.
Changes in v2:
- Reverse checks in pci_iomap_range,pci_iomap_wc_range.
- Refactor loops in vfio_pci to keep PCI_STD_RESOURCES.
- Add 2 new patches to replace the magic constant with new define.
- Split net patch in v1 to separate stmmac and dwc-xlgmac patches.
Denis Efremov (10):
PCI: Add define for the number of standard PCI BARs
s390/pci: Loop using PCI_STD_NUM_BARS
x86/PCI: Loop using PCI_STD_NUM_BARS
stmmac: pci: Loop using PCI_STD_NUM_BARS
net: dwc-xlgmac: Loop using PCI_STD_NUM_BARS
rapidio/tsi721: Loop using PCI_STD_NUM_BARS
efifb: Loop using PCI_STD_NUM_BARS
vfio_pci: Loop using PCI_STD_NUM_BARS
PCI: hv: Use PCI_STD_NUM_BARS
PCI: Use PCI_STD_NUM_BARS
arch/s390/include/asm/pci.h | 5 +----
arch/s390/include/asm/pci_clp.h | 6 +++---
arch/s390/pci/pci.c | 16 ++++++++--------
arch/s390/pci/pci_clp.c | 6 +++---
arch/x86/pci/common.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 ++--
drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c | 2 +-
drivers/pci/controller/pci-hyperv.c | 10 +++++-----
drivers/pci/pci.c | 11 ++++++-----
drivers/pci/quirks.c | 4 ++--
drivers/rapidio/devices/tsi721.c | 2 +-
drivers/vfio/pci/vfio_pci.c | 11 +++++++----
drivers/vfio/pci/vfio_pci_config.c | 10 ++++++----
drivers/vfio/pci/vfio_pci_private.h | 4 ++--
drivers/video/fbdev/efifb.c | 2 +-
include/linux/pci.h | 2 +-
include/uapi/linux/pci_regs.h | 1 +
17 files changed, 51 insertions(+), 47 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH v2 01/10] PCI: Add define for the number of standard PCI BARs
From: Denis Efremov @ 2019-08-16 9:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, linux-kernel, linux-pci, Sebastian Ott,
Gerald Schaefer, H. Peter Anvin, Giuseppe Cavallaro,
Alexandre Torgue, Matt Porter, Alexandre Bounine, Peter Jones,
Bartlomiej Zolnierkiewicz, Cornelia Huck, Alex Williamson,
Andrew Murray, Jose Abreu, kvm, linux-fbdev, netdev, x86,
linux-s390
In-Reply-To: <20190816092437.31846-1-efremov@linux.com>
Code that iterates over all standard PCI BARs typically uses
PCI_STD_RESOURCE_END. However, it requires the "unusual" loop condition
"i <= PCI_STD_RESOURCE_END" rather than something more standard like
"i < PCI_STD_NUM_BARS".
This patch adds the definition PCI_STD_NUM_BARS which is equivalent to
"PCI_STD_RESOURCE_END + 1" and updates loop conditions to use it.
Signed-off-by: Denis Efremov <efremov@linux.com>
---
drivers/pci/quirks.c | 2 +-
include/linux/pci.h | 2 +-
include/uapi/linux/pci_regs.h | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 208aacf39329..02bdf3a0231e 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -475,7 +475,7 @@ static void quirk_extend_bar_to_page(struct pci_dev *dev)
{
int i;
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
struct resource *r = &dev->resource[i];
if (r->flags & IORESOURCE_MEM && resource_size(r) < PAGE_SIZE) {
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 9e700d9f9f28..7b9590d5dc2d 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -76,7 +76,7 @@ enum pci_mmap_state {
enum {
/* #0-5: standard PCI resources */
PCI_STD_RESOURCES,
- PCI_STD_RESOURCE_END = 5,
+ PCI_STD_RESOURCE_END = PCI_STD_RESOURCES + PCI_STD_NUM_BARS - 1,
/* #6: expansion ROM resource */
PCI_ROM_RESOURCE,
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index f28e562d7ca8..68b571d491eb 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -34,6 +34,7 @@
* of which the first 64 bytes are standardized as follows:
*/
#define PCI_STD_HEADER_SIZEOF 64
+#define PCI_STD_NUM_BARS 6 /* Number of standard BARs */
#define PCI_VENDOR_ID 0x00 /* 16 bits */
#define PCI_DEVICE_ID 0x02 /* 16 bits */
#define PCI_COMMAND 0x04 /* 16 bits */
--
2.21.0
^ permalink raw reply related
* [PATCH v2 04/10] stmmac: pci: Loop using PCI_STD_NUM_BARS
From: Denis Efremov @ 2019-08-16 9:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, Giuseppe Cavallaro, Alexandre Torgue, netdev,
linux-pci, linux-kernel
In-Reply-To: <20190816092437.31846-1-efremov@linux.com>
Refactor loops to use 'i < PCI_STD_NUM_BARS' instead of
'i <= PCI_STD_RESOURCE_END'.
Signed-off-by: Denis Efremov <efremov@linux.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 86f9c07a38cf..cfe496cdd78b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -258,7 +258,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
}
/* Get the base address of device */
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pdev, i) == 0)
continue;
ret = pcim_iomap_regions(pdev, BIT(i), pci_name(pdev));
@@ -296,7 +296,7 @@ static void stmmac_pci_remove(struct pci_dev *pdev)
stmmac_dvr_remove(&pdev->dev);
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pdev, i) == 0)
continue;
pcim_iounmap_regions(pdev, BIT(i));
--
2.21.0
^ permalink raw reply related
* [PATCH v2 05/10] net: dwc-xlgmac: Loop using PCI_STD_NUM_BARS
From: Denis Efremov @ 2019-08-16 9:24 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Denis Efremov, Jose Abreu, netdev, linux-pci, linux-kernel
In-Reply-To: <20190816092437.31846-1-efremov@linux.com>
Refactor loops to use 'i < PCI_STD_NUM_BARS' instead of
'i <= PCI_STD_RESOURCE_END'.
Signed-off-by: Denis Efremov <efremov@linux.com>
---
drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
index 386bafe74c3f..fa8604d7b797 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
@@ -34,7 +34,7 @@ static int xlgmac_probe(struct pci_dev *pcidev, const struct pci_device_id *id)
return ret;
}
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pcidev, i) == 0)
continue;
ret = pcim_iomap_regions(pcidev, BIT(i), XLGMAC_DRV_NAME);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH net-next] r8152: divide the tx and rx bottom functions
From: Eric Dumazet @ 2019-08-16 9:27 UTC (permalink / raw)
To: Hayes Wang, Eric Dumazet, netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2F18D47C8@RTITMBSVM03.realtek.com.tw>
On 8/16/19 11:08 AM, Hayes Wang wrote:
> Eric Dumazet [mailto:eric.dumazet@gmail.com]
>> Sent: Friday, August 16, 2019 4:20 PM
> [...]
>> Which callback ?
>
> The USB device has two endpoints for Tx and Rx.
> If I submit tx or rx URB to the USB host controller,
> the relative callback functions would be called, when
> they are finished. For rx, it is read_bulk_callback.
> For tx, it is write_bulk_callback.
>
>> After an idle period (no activity, no prior packets being tx-completed ...),
>> a packet is sent by the upper stack, enters the ndo_start_xmit() of a network
>> driver.
>>
>> This driver ndo_start_xmit() simply adds an skb to a local list, and returns.
>
> Base on the current method (without tasklet), when
> ndo_start_xmit() is called, napi_schedule is called only
> if there is at least one free buffer (!list_empty(&tp->tx_free))
> to transmit the packet. Then, the flow would be as following.
Very uncommon naming conventions really :/
Maybe you would avoid messing with a tasklet (we really try to get rid
of tasklets in general) using two NAPI, one for TX, one for RX.
Some drivers already use two NAPI, it is fine.
This might avoid the ugly dance in r8152_poll(),
calling napi_schedule(napi) after napi_complete_done() !
^ 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