* [PATCH net-next 10/10] net: hns3: Fixes the missing PCI iounmap for various legs
From: Salil Mehta @ 2018-05-15 18:20 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180515182014.42196-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
We call pcim_iomap in hclge_pci_init, pcim_iounmap should be called
in error handle of hclge_init_ae_dev.
We call pcim_iomap in hclge_pci_init, but do not call pcim_iounmap in
hclge_pci_uninit. When we remove the hclge.ko and insert it again, a
problem that pci can not map will happen. pcim_iounmap need to be called
in hclge_pci_uninit.
Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@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 75d9b8c..46435c8 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5425,6 +5425,7 @@ static void hclge_pci_uninit(struct hclge_dev *hdev)
{
struct pci_dev *pdev = hdev->pdev;
+ pcim_iounmap(pdev, hdev->hw.io_base);
pci_free_irq_vectors(pdev);
pci_clear_master(pdev);
pci_release_mem_regions(pdev);
@@ -5589,6 +5590,7 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
err_cmd_uninit:
hclge_destroy_cmd_queue(&hdev->hw);
err_pci_uninit:
+ pcim_iounmap(pdev, hdev->hw.io_base);
pci_clear_master(pdev);
pci_release_regions(pdev);
pci_disable_device(pdev);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 09/10] net: hns3: Add support of .sriov_configure in HNS3 driver
From: Salil Mehta @ 2018-05-15 18:20 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm
In-Reply-To: <20180515182014.42196-1-salil.mehta@huawei.com>
From: Peng Li <lipeng321@huawei.com>
As HNS3 driver will enable SRIOV default and enable all VFs the
HW support, if PF and VF driver compiled to kernel, VF driver
will work on host default, it is not right.
This patch adds support for hns3_driver.sriov_configure to support
user configs the VF_num, and do not enable sriov default.
Signed-off-by: Peng Li <lipeng321@huawei.com>
Suggested-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 58 ++++++++++++++-----------
1 file changed, 32 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index ac75b5d..e85ff38 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1511,29 +1511,6 @@ static bool hns3_is_phys_func(struct pci_dev *pdev)
return false;
}
-static int get_num_req_vfs(struct pci_dev *pdev)
-{
- /* a variable vf num will be supported later */
- return pci_sriov_get_totalvfs(pdev);
-}
-
-static void hns3_enable_sriov(struct pci_dev *pdev)
-{
- int num_req_vfs = get_num_req_vfs(pdev);
- int ret;
-
- /* Enable SRIOV */
- if (!num_req_vfs)
- return;
-
- dev_info(&pdev->dev, "active VFs(%d) found, enabling SRIOV\n",
- num_req_vfs);
-
- ret = pci_enable_sriov(pdev, num_req_vfs);
- if (ret)
- dev_err(&pdev->dev, "SRIOV enable failed %d\n", ret);
-}
-
static void hns3_disable_sriov(struct pci_dev *pdev)
{
/* If our VFs are assigned we cannot shut down SR-IOV
@@ -1578,9 +1555,6 @@ static int hns3_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
hnae3_register_ae_dev(ae_dev);
- if (hns3_is_phys_func(pdev) && IS_ENABLED(CONFIG_PCI_IOV))
- hns3_enable_sriov(pdev);
-
return 0;
}
@@ -1597,11 +1571,43 @@ static void hns3_remove(struct pci_dev *pdev)
hnae3_unregister_ae_dev(ae_dev);
}
+/**
+ * hns3_pci_sriov_configure
+ * @pdev: pointer to a pci_dev structure
+ * @num_vfs: number of VFs to allocate
+ *
+ * Enable or change the number of VFs. Called when the user updates the number
+ * of VFs in sysfs.
+ **/
+int hns3_pci_sriov_configure(struct pci_dev *pdev, int num_vfs)
+{
+ int ret;
+
+ if (!(hns3_is_phys_func(pdev) && IS_ENABLED(CONFIG_PCI_IOV))) {
+ dev_warn(&pdev->dev, "Can not config SRIOV\n");
+ return -EINVAL;
+ }
+
+ if (num_vfs) {
+ ret = pci_enable_sriov(pdev, num_vfs);
+ if (ret)
+ dev_err(&pdev->dev, "SRIOV enable failed %d\n", ret);
+ } else if (!pci_vfs_assigned(pdev)) {
+ pci_disable_sriov(pdev);
+ } else {
+ dev_warn(&pdev->dev,
+ "Unable to free VFs because some are assigned to VMs.\n");
+ }
+
+ return 0;
+}
+
static struct pci_driver hns3_driver = {
.name = hns3_driver_name,
.id_table = hns3_pci_tbl,
.probe = hns3_probe,
.remove = hns3_remove,
+ .sriov_configure = hns3_pci_sriov_configure,
};
/* set default feature to hns3 */
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 08/10] net: hns3: Fix for fiber link up problem
From: Salil Mehta @ 2018-05-15 18:20 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180515182014.42196-1-salil.mehta@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
When hclge_ae_start is called, hdev->hw.mac.link may be set
to one after up/down multi-times, which does not correspond to
the link state of netdev when the netdev is up.
This fixes it by setting hdev->hw.mac.link to zero when
hclge_ae_start is called.
Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index d060903..75d9b8c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3756,6 +3756,7 @@ static int hclge_ae_start(struct hnae3_handle *handle)
hclge_cfg_mac_mode(hdev, true);
clear_bit(HCLGE_STATE_DOWN, &hdev->state);
mod_timer(&hdev->service_timer, jiffies + HZ);
+ hdev->hw.mac.link = 0;
/* reset tqp stats */
hclge_reset_tqp_stats(handle);
@@ -3792,7 +3793,6 @@ static void hclge_ae_stop(struct hnae3_handle *handle)
/* reset tqp stats */
hclge_reset_tqp_stats(handle);
- hclge_update_link_status(hdev);
}
static int hclge_get_mac_vlan_cmd_status(struct hclge_vport *vport,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 07/10] net: hns3: Fixes the back pressure setting When sriov is enabled
From: Salil Mehta @ 2018-05-15 18:20 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180515182014.42196-1-salil.mehta@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
When sriov is enabled, the Qset and tc mapping is not longer one
to one relation.
This patch fixes it by mapping all pf and vf's Qset to tc.
Fixes: 848440544b41 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 45 +++++++++++++++++++---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h | 5 +++
2 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
index c69ecab..262c125 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
@@ -500,7 +500,8 @@ static int hclge_tm_qs_schd_mode_cfg(struct hclge_dev *hdev, u16 qs_id, u8 mode)
return hclge_cmd_send(&hdev->hw, &desc, 1);
}
-static int hclge_tm_qs_bp_cfg(struct hclge_dev *hdev, u8 tc)
+static int hclge_tm_qs_bp_cfg(struct hclge_dev *hdev, u8 tc, u8 grp_id,
+ u32 bit_map)
{
struct hclge_bp_to_qs_map_cmd *bp_to_qs_map_cmd;
struct hclge_desc desc;
@@ -511,9 +512,8 @@ static int hclge_tm_qs_bp_cfg(struct hclge_dev *hdev, u8 tc)
bp_to_qs_map_cmd = (struct hclge_bp_to_qs_map_cmd *)desc.data;
bp_to_qs_map_cmd->tc_id = tc;
-
- /* Qset and tc is one by one mapping */
- bp_to_qs_map_cmd->qs_bit_map = cpu_to_le32(1 << tc);
+ bp_to_qs_map_cmd->qs_group_id = grp_id;
+ bp_to_qs_map_cmd->qs_bit_map = cpu_to_le32(bit_map);
return hclge_cmd_send(&hdev->hw, &desc, 1);
}
@@ -1167,6 +1167,41 @@ static int hclge_pfc_setup_hw(struct hclge_dev *hdev)
hdev->tm_info.hw_pfc_map);
}
+/* Each Tc has a 1024 queue sets to backpress, it divides to
+ * 32 group, each group contains 32 queue sets, which can be
+ * represented by u32 bitmap.
+ */
+static int hclge_bp_setup_hw(struct hclge_dev *hdev, u8 tc)
+{
+ struct hclge_vport *vport = hdev->vport;
+ u32 i, k, qs_bitmap;
+ int ret;
+
+ for (i = 0; i < HCLGE_BP_GRP_NUM; i++) {
+ qs_bitmap = 0;
+
+ for (k = 0; k < hdev->num_alloc_vport; k++) {
+ u16 qs_id = vport->qs_offset + tc;
+ u8 grp, sub_grp;
+
+ grp = hnae_get_field(qs_id, HCLGE_BP_GRP_ID_M,
+ HCLGE_BP_GRP_ID_S);
+ sub_grp = hnae_get_field(qs_id, HCLGE_BP_SUB_GRP_ID_M,
+ HCLGE_BP_SUB_GRP_ID_S);
+ if (i == grp)
+ qs_bitmap |= (1 << sub_grp);
+
+ vport++;
+ }
+
+ ret = hclge_tm_qs_bp_cfg(hdev, tc, i, qs_bitmap);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int hclge_mac_pause_setup_hw(struct hclge_dev *hdev)
{
bool tx_en, rx_en;
@@ -1218,7 +1253,7 @@ int hclge_pause_setup_hw(struct hclge_dev *hdev)
dev_warn(&hdev->pdev->dev, "set pfc pause failed:%d\n", ret);
for (i = 0; i < hdev->tm_info.num_tc; i++) {
- ret = hclge_tm_qs_bp_cfg(hdev, i);
+ ret = hclge_bp_setup_hw(hdev, i);
if (ret)
return ret;
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h
index 2dbe177..c2b6e8a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h
@@ -89,6 +89,11 @@ struct hclge_pg_shapping_cmd {
__le32 pg_shapping_para;
};
+#define HCLGE_BP_GRP_NUM 32
+#define HCLGE_BP_SUB_GRP_ID_S 0
+#define HCLGE_BP_SUB_GRP_ID_M GENMASK(4, 0)
+#define HCLGE_BP_GRP_ID_S 5
+#define HCLGE_BP_GRP_ID_M GENMASK(9, 5)
struct hclge_bp_to_qs_map_cmd {
u8 tc_id;
u8 rsvd[2];
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 06/10] net: hns3: Change return value in hnae3_register_client
From: Salil Mehta @ 2018-05-15 18:20 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180515182014.42196-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
A client includes many client instance. Just like ae_algo, Initializing
client instance failed does not represent registering client failed.
The action of registering client just is adding client to the client
list and the result always is true. This patch changes the return
value of hnae3_register_client form a variable value to a fixed value,
makes the function always return ok.
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 3b1c396..bd3c232 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -98,7 +98,7 @@ int hnae3_register_client(struct hnae3_client *client)
exit:
mutex_unlock(&hnae3_common_lock);
- return ret;
+ return 0;
}
EXPORT_SYMBOL(hnae3_register_client);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 05/10] net: hns3: Change return type of hnae3_register_ae_algo
From: Salil Mehta @ 2018-05-15 18:20 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180515182014.42196-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
The ae_algo is used by many ae_devs. It is not only belong to just a
ae_dev. Initializing ae_dev failed does not represent registering ae_algo
failed. Because the action of registering ae_algo just is adding ae_algo
to the ae_algo list and it is always is true, it make no sense to define
return type as int.
This patch changes the return type of hnae3_register_ae_algo from int to
void.
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 4 +---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4 +++-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 4 +++-
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index cb93295..3b1c396 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -121,7 +121,7 @@ EXPORT_SYMBOL(hnae3_unregister_client);
* @ae_algo: AE algorithm
* NOTE: the duplicated name will not be checked
*/
-int hnae3_register_ae_algo(struct hnae3_ae_algo *ae_algo)
+void hnae3_register_ae_algo(struct hnae3_ae_algo *ae_algo)
{
const struct pci_device_id *id;
struct hnae3_ae_dev *ae_dev;
@@ -160,8 +160,6 @@ int hnae3_register_ae_algo(struct hnae3_ae_algo *ae_algo)
}
mutex_unlock(&hnae3_common_lock);
-
- return ret;
}
EXPORT_SYMBOL(hnae3_register_ae_algo);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index ea6e6ea..2f266ef 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -519,7 +519,7 @@ void hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev);
void hnae3_unregister_ae_dev(struct hnae3_ae_dev *ae_dev);
void hnae3_unregister_ae_algo(struct hnae3_ae_algo *ae_algo);
-int hnae3_register_ae_algo(struct hnae3_ae_algo *ae_algo);
+void hnae3_register_ae_algo(struct hnae3_ae_algo *ae_algo);
void hnae3_unregister_client(struct hnae3_client *client);
int hnae3_register_client(struct hnae3_client *client);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index c2501b1..d060903 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -6250,7 +6250,9 @@ static int hclge_init(void)
{
pr_info("%s is initializing\n", HCLGE_NAME);
- return hnae3_register_ae_algo(&ae_algo);
+ hnae3_register_ae_algo(&ae_algo);
+
+ return 0;
}
static void hclge_exit(void)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index b7578c6..f1f4a17 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -1852,7 +1852,9 @@ static int hclgevf_init(void)
{
pr_info("%s is initializing\n", HCLGEVF_NAME);
- return hnae3_register_ae_algo(&ae_algovf);
+ hnae3_register_ae_algo(&ae_algovf);
+
+ return 0;
}
static void hclgevf_exit(void)
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 04/10] net: hns3: Change return type of hnae3_register_ae_dev
From: Salil Mehta @ 2018-05-15 18:20 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180515182014.42196-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
If hclge.ko has not been inserted, the value of ret always is zero
in hnae3_register_ae_dev. If hclge.ko has been inserted, the value
of ret is zero or non zero. Different execution ways have different
results. It is confusing.
The ae_dev which is initialized failed can be reinitialized when we
remove hclge.ko and insert it again. For the case initializing client
instance, it is just like the case initializing ae_dev. The main function
of hnae3_register_ae_dev is adding the ae_dev to ad_dev list. Because
adding ae_dev is always ok, we does not need to return any in this
function.
This patch changes the return type of hnae3_register_ae_dev from int
to void.
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 5 +----
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 +---
3 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 21cb0c5..cb93295 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -203,7 +203,7 @@ EXPORT_SYMBOL(hnae3_unregister_ae_algo);
* @ae_dev: the AE device
* NOTE: the duplicated name will not be checked
*/
-int hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
+void hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
{
const struct pci_device_id *id;
struct hnae3_ae_algo *ae_algo;
@@ -224,7 +224,6 @@ int hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
if (!ae_dev->ops) {
dev_err(&ae_dev->pdev->dev, "ae_dev ops are null\n");
- ret = -EOPNOTSUPP;
goto out_err;
}
@@ -251,8 +250,6 @@ int hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
out_err:
mutex_unlock(&hnae3_common_lock);
-
- return ret;
}
EXPORT_SYMBOL(hnae3_register_ae_dev);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index ffec231..ea6e6ea 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -515,7 +515,7 @@ struct hnae3_handle {
#define hnae_get_bit(origin, shift) \
hnae_get_field((origin), (0x1 << (shift)), (shift))
-int hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev);
+void hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev);
void hnae3_unregister_ae_dev(struct hnae3_ae_dev *ae_dev);
void hnae3_unregister_ae_algo(struct hnae3_ae_algo *ae_algo);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index af9e90f..ac75b5d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1576,9 +1576,7 @@ static int hns3_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
ae_dev->dev_type = HNAE3_DEV_KNIC;
pci_set_drvdata(pdev, ae_dev);
- ret = hnae3_register_ae_dev(ae_dev);
- if (ret)
- return ret;
+ hnae3_register_ae_dev(ae_dev);
if (hns3_is_phys_func(pdev) && IS_ENABLED(CONFIG_PCI_IOV))
hns3_enable_sriov(pdev);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 03/10] net: hns3: Add a check for client instance init state
From: Salil Mehta @ 2018-05-15 18:20 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180515182014.42196-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
If the client instance is initializd failed, we do not need to uninit it.
This patch adds a state check to check init state of client instance.
Fixes: 38caee9d3ee8 ("net: hns3: Add support of the HNAE3 framework")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 15 ++++++++++++---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index ab2e72c..21cb0c5 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -50,13 +50,22 @@ static int hnae3_match_n_instantiate(struct hnae3_client *client,
/* now, (un-)instantiate client by calling lower layer */
if (is_reg) {
ret = ae_dev->ops->init_client_instance(client, ae_dev);
- if (ret)
+ if (ret) {
dev_err(&ae_dev->pdev->dev,
"fail to instantiate client\n");
- return ret;
+ return ret;
+ }
+
+ hnae_set_bit(ae_dev->flag, HNAE3_CLIENT_INITED_B, 1);
+ return 0;
+ }
+
+ if (hnae_get_bit(ae_dev->flag, HNAE3_CLIENT_INITED_B)) {
+ ae_dev->ops->uninit_client_instance(client, ae_dev);
+
+ hnae_set_bit(ae_dev->flag, HNAE3_CLIENT_INITED_B, 0);
}
- ae_dev->ops->uninit_client_instance(client, ae_dev);
return 0;
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 804ea83..ffec231 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -52,6 +52,7 @@
#define HNAE3_DEV_INITED_B 0x0
#define HNAE3_DEV_SUPPORT_ROCE_B 0x1
#define HNAE3_DEV_SUPPORT_DCB_B 0x2
+#define HNAE3_CLIENT_INITED_B 0x3
#define HNAE3_DEV_SUPPORT_ROCE_DCB_BITS (BIT(HNAE3_DEV_SUPPORT_DCB_B) |\
BIT(HNAE3_DEV_SUPPORT_ROCE_B))
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 01/10] net: hns3: Fix for deadlock problem occurring when unregistering ae_algo
From: Salil Mehta @ 2018-05-15 18:20 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180515182014.42196-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
When hnae3_unregister_ae_algo is called by PF, pci_disable_sriov is
called. And then, hns3_remove is called by VF. We get deadlocked in
this case.
Since VF pci device is dependent on PF pci device, When PF pci device
is removed, VF pci device must be removed. Also, To solve the deadlock
problem, VF pci device should be removed before PF pci device is removed.
This patch moves pci_enable/disable_sriov from hclge to hns3 to solve
the deadlock problem.
Also, we do not need to return EPROBE_DEFER in hnae3_register_ae_dev,
because SRIOV is no longer enabled in the context calling
hnae3_register_ae_dev. Mutex_trylock can be replaced with mutex_lock.
Fixes: 424eb834a9be ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 12 +---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 74 +++++++++++++++++++++-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 42 ++----------
3 files changed, 79 insertions(+), 49 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 02145f2..1686ceb 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -196,17 +196,9 @@ 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, lock_acquired;
+ int ret = 0;
- /* we can get deadlocked if SRIOV is being enabled in context to probe
- * and probe gets called again in same context. This can happen when
- * pci_enable_sriov() is called to create VFs from PF probes context.
- * Therefore, for simplicity uniformly defering further probing in all
- * cases where we detect contention.
- */
- lock_acquired = mutex_trylock(&hnae3_common_lock);
- if (!lock_acquired)
- return -EPROBE_DEFER;
+ mutex_lock(&hnae3_common_lock);
list_add_tail(&ae_dev->node, &hnae3_ae_dev_list);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4031174..af9e90f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1487,6 +1487,68 @@ static const struct net_device_ops hns3_nic_netdev_ops = {
.ndo_set_vf_vlan = hns3_ndo_set_vf_vlan,
};
+static bool hns3_is_phys_func(struct pci_dev *pdev)
+{
+ u32 dev_id = pdev->device;
+
+ switch (dev_id) {
+ case HNAE3_DEV_ID_GE:
+ case HNAE3_DEV_ID_25GE:
+ case HNAE3_DEV_ID_25GE_RDMA:
+ case HNAE3_DEV_ID_25GE_RDMA_MACSEC:
+ case HNAE3_DEV_ID_50GE_RDMA:
+ case HNAE3_DEV_ID_50GE_RDMA_MACSEC:
+ case HNAE3_DEV_ID_100G_RDMA_MACSEC:
+ return true;
+ case HNAE3_DEV_ID_100G_VF:
+ case HNAE3_DEV_ID_100G_RDMA_DCB_PFC_VF:
+ return false;
+ default:
+ dev_warn(&pdev->dev, "un-recognized pci device-id %d",
+ dev_id);
+ }
+
+ return false;
+}
+
+static int get_num_req_vfs(struct pci_dev *pdev)
+{
+ /* a variable vf num will be supported later */
+ return pci_sriov_get_totalvfs(pdev);
+}
+
+static void hns3_enable_sriov(struct pci_dev *pdev)
+{
+ int num_req_vfs = get_num_req_vfs(pdev);
+ int ret;
+
+ /* Enable SRIOV */
+ if (!num_req_vfs)
+ return;
+
+ dev_info(&pdev->dev, "active VFs(%d) found, enabling SRIOV\n",
+ num_req_vfs);
+
+ ret = pci_enable_sriov(pdev, num_req_vfs);
+ if (ret)
+ dev_err(&pdev->dev, "SRIOV enable failed %d\n", ret);
+}
+
+static void hns3_disable_sriov(struct pci_dev *pdev)
+{
+ /* If our VFs are assigned we cannot shut down SR-IOV
+ * without causing issues, so just leave the hardware
+ * available but disabled
+ */
+ if (pci_vfs_assigned(pdev)) {
+ dev_warn(&pdev->dev,
+ "disabling driver while VFs are assigned\n");
+ return;
+ }
+
+ pci_disable_sriov(pdev);
+}
+
/* hns3_probe - Device initialization routine
* @pdev: PCI device information struct
* @ent: entry in hns3_pci_tbl
@@ -1514,7 +1576,14 @@ static int hns3_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
ae_dev->dev_type = HNAE3_DEV_KNIC;
pci_set_drvdata(pdev, ae_dev);
- return hnae3_register_ae_dev(ae_dev);
+ ret = hnae3_register_ae_dev(ae_dev);
+ if (ret)
+ return ret;
+
+ if (hns3_is_phys_func(pdev) && IS_ENABLED(CONFIG_PCI_IOV))
+ hns3_enable_sriov(pdev);
+
+ return 0;
}
/* hns3_remove - Device removal routine
@@ -1524,6 +1593,9 @@ static void hns3_remove(struct pci_dev *pdev)
{
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(pdev);
+ if (hns3_is_phys_func(pdev) && IS_ENABLED(CONFIG_PCI_IOV))
+ hns3_disable_sriov(pdev);
+
hnae3_unregister_ae_dev(ae_dev);
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 316ec842..343197a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -1473,21 +1473,8 @@ static int hclge_alloc_vport(struct hclge_dev *hdev)
hdev->vport = vport;
hdev->num_alloc_vport = num_vport;
-#ifdef CONFIG_PCI_IOV
- /* Enable SRIOV */
- if (hdev->num_req_vfs) {
- dev_info(&pdev->dev, "active VFs(%d) found, enabling SRIOV\n",
- hdev->num_req_vfs);
- ret = pci_enable_sriov(hdev->pdev, hdev->num_req_vfs);
- if (ret) {
- hdev->num_alloc_vfs = 0;
- dev_err(&pdev->dev, "SRIOV enable failed %d\n",
- ret);
- return ret;
- }
- }
- hdev->num_alloc_vfs = hdev->num_req_vfs;
-#endif
+ if (IS_ENABLED(CONFIG_PCI_IOV))
+ hdev->num_alloc_vfs = hdev->num_req_vfs;
for (i = 0; i < num_vport; i++) {
vport->back = hdev;
@@ -2946,21 +2933,6 @@ static void hclge_service_task(struct work_struct *work)
hclge_service_complete(hdev);
}
-static void hclge_disable_sriov(struct hclge_dev *hdev)
-{
- /* If our VFs are assigned we cannot shut down SR-IOV
- * without causing issues, so just leave the hardware
- * available but disabled
- */
- if (pci_vfs_assigned(hdev->pdev)) {
- dev_warn(&hdev->pdev->dev,
- "disabling driver while VFs are assigned\n");
- return;
- }
-
- pci_disable_sriov(hdev->pdev);
-}
-
struct hclge_vport *hclge_get_vport(struct hnae3_handle *handle)
{
/* VF handle has no client */
@@ -5540,7 +5512,7 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
ret = hclge_map_tqp(hdev);
if (ret) {
dev_err(&pdev->dev, "Map tqp error, ret = %d.\n", ret);
- goto err_sriov_disable;
+ goto err_msi_irq_uninit;
}
if (hdev->hw.mac.media_type == HNAE3_MEDIA_TYPE_COPPER) {
@@ -5548,7 +5520,7 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
if (ret) {
dev_err(&hdev->pdev->dev,
"mdio config fail ret=%d\n", ret);
- goto err_sriov_disable;
+ goto err_msi_irq_uninit;
}
}
@@ -5612,9 +5584,6 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
err_mdiobus_unreg:
if (hdev->hw.mac.phydev)
mdiobus_unregister(hdev->hw.mac.mdio_bus);
-err_sriov_disable:
- if (IS_ENABLED(CONFIG_PCI_IOV))
- hclge_disable_sriov(hdev);
err_msi_irq_uninit:
hclge_misc_irq_uninit(hdev);
err_msi_uninit:
@@ -5717,9 +5686,6 @@ static void hclge_uninit_ae_dev(struct hnae3_ae_dev *ae_dev)
set_bit(HCLGE_STATE_DOWN, &hdev->state);
- if (IS_ENABLED(CONFIG_PCI_IOV))
- hclge_disable_sriov(hdev);
-
if (hdev->service_timer.function)
del_timer_sync(&hdev->service_timer);
if (hdev->service_task.func)
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 00/10] Misc. Bug Fixes and clean-ups for HNS3 Driver
From: Salil Mehta @ 2018-05-15 18:20 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm
This patch-set mainly introduces various bug fixes, cleanups and one
very small enhancement to existing HN3 driver code.
Fuyun Liang (7):
net: hns3: Fix for deadlock problem occurring when unregistering
ae_algo
net: hns3: Fix for the null pointer problem occurring when
initializing ae_dev failed
net: hns3: Add a check for client instance init state
net: hns3: Change return type of hnae3_register_ae_dev
net: hns3: Change return type of hnae3_register_ae_algo
net: hns3: Change return value in hnae3_register_client
net: hns3: Fixes the missing PCI iounmap for various legs
Peng Li (1):
net: hns3: Add support of .sriov_configure in HNS3 driver
Yunsheng Lin (2):
net: hns3: Fixes the back pressure setting When sriov is enabled
net: hns3: Fix for fiber link up problem
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 44 ++++++------
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 5 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 78 +++++++++++++++++++++-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 55 +++------------
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 45 +++++++++++--
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h | 5 ++
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 10 +--
7 files changed, 164 insertions(+), 78 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: qualcomm: rmnet: Add support for ethtool private stats
From: Subash Abhinov Kasiviswanathan @ 2018-05-15 18:09 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, davem, netdev
In-Reply-To: <201805151651.Vgq47bPJ%fengguang.wu@intel.com>
On 2018-05-15 02:41, kbuild test robot wrote:
> Hi Subash,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on net-next/master]
>
> url:
> https://github.com/0day-ci/linux/commits/Subash-Abhinov-Kasiviswanathan/net-qualcomm-rmnet-Updates-2018-05-14/20180515-115355
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones prefixed by >>)
>
>>> drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c:199:26: sparse:
>>> symbol 'rmnet_ethtool_ops' was not declared. Should it be static?
>
> Please review and possibly fold the followup patch.
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology
> Center
> https://lists.01.org/pipermail/kbuild-all Intel
> Corporation
Thanks Fengguang. I will fix both issues in v2
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v1 iproute2-next 2/3] rdma: print driver resource attributes
From: Doug Ledford @ 2018-05-15 18:00 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: Steve Wise, dsahern, stephen, netdev, linux-rdma
In-Reply-To: <20180515165955.GD10381@mtr-leonro.mtl.com>
[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]
On Tue, 2018-05-15 at 19:59 +0300, Leon Romanovsky wrote:
> On Tue, May 15, 2018 at 12:35:34PM -0400, Doug Ledford wrote:
> > On Mon, 2018-05-14 at 09:51 -0500, Steve Wise wrote:
> > >
> > > On 5/13/2018 8:24 AM, Leon Romanovsky wrote:
> > > > On Mon, May 07, 2018 at 08:53:16AM -0700, Steve Wise wrote:
> > > > > This enhancement allows printing rdma device-specific state, if provided
> > > > > by the kernel. This is done in a generic manner, so rdma tool doesn't
> > > >
> > > > Double space between "." and "This".
> > > >
> > > > > need to know about the details of every type of rdma device.
> > > > >
> > > > > Driver attributes for a rdma resource are in the form of <key,
> > > > > [print_type], value> tuples, where the key is a string and the value can
> > > > > be any supported driver attribute. The print_type attribute, if present,
> > > >
> > > > ditto
> > >
> > > I'll fix these.
> >
> > Fix it if you want, but don't do it because Leon told you to. A double
> > space after period is perfectly acceptable.
>
> It is very controversial thing [1],
>
> "Most style guides indicate that single sentence spacing is proper for
> final or published work today, and most publishers require manuscripts
> to be submitted as they will appear in publication—single
> sentence spaced."
>
> [1] https://en.wikipedia.org/wiki/Sentence_spacing
Yes...and the justification is that proportional font systems resolve
the issue of delineating sentences without the need for a second space
(they actually don't because they are improperly implemented, but that's
another issue). But we don't work on proportional font systems, we work
with git, on command lines, with fixed spacing fonts, all the things
that indicate double spaces are actually preferred even by those people
that are proponents of single spacing. And on top of that, current
research suggests maybe the single spacers are wrong after all :-o
https://www.theatlantic.com/science/archive/2018/05/two-spaces-after-a-p
eriod/559304/
Anyway, my original point stands. It's controversial, as you said, so
Steve should do what Steve feels is best and not worry about anyone
else' opinion on the matter.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* SCM_RIGHTS and file descriptor limits
From: Andres Freund @ 2018-05-15 17:52 UTC (permalink / raw)
To: David S. Miller, mtk.manpages, Kees Cook, David Windsor,
Hans Liljestrand, Reshetova, Elena, Al Viro
Cc: linux-man, netdev, linux-kernel
Hi,
I'm not sure if this is a documentation omission, kernel code bug,
missing understanding on my part, or all of the above.
I'm looking at recvmsg()'s behaviour for AF_UNIX, where the sender has
sent an fd using SCM_RIGHTS, and the receiving process has already
exceeded RLIMIT_NOFILE.
By my reading of scm_detach_fds() (called from
unix_stream_read_generic() / unix_dgram_recvmsg(), via scm_recv()), the
error appears to just be thrown away, with no notification given to
userland at all:
void scm_detach_fds(struct msghdr *msg, struct scm_cookie *scm)
{
...
for (i=0, cmfptr=(__force int __user *)CMSG_DATA(cm); i<fdmax;
i++, cmfptr++)
{
struct socket *sock;
int new_fd;
err = security_file_receive(fp[i]);
if (err)
break;
err = get_unused_fd_flags(MSG_CMSG_CLOEXEC & msg->msg_flags
? O_CLOEXEC : 0);
if (err < 0)
break;
If I understand correctly no error is reported to the user (function
returns void, no put_user() calls for the unsuccessful fds/i), but all
the scm data is "consumed" via scm_destroy().
Silently consuming data without reporting an error doesn't strike me as
nice. Now admittedly scm is one of the more kludgey interfaces, and it's
not entirely obvious how one would do much better without significant
added complication - the correct behaviour seems to be to return EMFILE,
but that'd need to somehow rewind the received data, which seems
complicated... On the other hand it's not generally knowable how many
file descriptors the other side sent, so one really needs to duplicate
all scm information on the data level to make sure nothing gets lost.
In case this is something that won't be fixed, it seems appropriate to
add a section to the man pages (hence CCing linux man-pages list)
Greetings,
Andres Freund
^ permalink raw reply
* RE: [PATCH v1 iproute2-next 2/3] rdma: print driver resource attributes
From: Steve Wise @ 2018-05-15 17:51 UTC (permalink / raw)
To: 'Leon Romanovsky', 'Doug Ledford'
Cc: dsahern, stephen, netdev, linux-rdma
In-Reply-To: <20180515165955.GD10381@mtr-leonro.mtl.com>
>
> On Tue, May 15, 2018 at 12:35:34PM -0400, Doug Ledford wrote:
> > On Mon, 2018-05-14 at 09:51 -0500, Steve Wise wrote:
> > >
> > > On 5/13/2018 8:24 AM, Leon Romanovsky wrote:
> > > > On Mon, May 07, 2018 at 08:53:16AM -0700, Steve Wise wrote:
> > > > > This enhancement allows printing rdma device-specific state, if
> provided
> > > > > by the kernel. This is done in a generic manner, so rdma tool doesn't
> > > >
> > > > Double space between "." and "This".
> > > >
> > > > > need to know about the details of every type of rdma device.
> > > > >
> > > > > Driver attributes for a rdma resource are in the form of <key,
> > > > > [print_type], value> tuples, where the key is a string and the value can
> > > > > be any supported driver attribute. The print_type attribute, if
> present,
> > > >
> > > > ditto
> > >
> > > I'll fix these.
> >
> > Fix it if you want, but don't do it because Leon told you to. A double
> > space after period is perfectly acceptable.
>
> It is very controversial thing [1],
>
> "Most style guides indicate that single sentence spacing is proper for
> final or published work today, and most publishers require manuscripts
> to be submitted as they will appear in publication—single
> sentence spaced."
>
> [1] https://en.wikipedia.org/wiki/Sentence_spacing
We're not writing a manuscript. 😉 Regardless, I made the changes and they are in v2 of the patch series, which I think is probably ready to merge.
Steve.
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/5] samples: bpf: fix build after move to full libbpf
From: Jakub Kicinski @ 2018-05-15 17:46 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexei Starovoitov, daniel, oss-drivers, netdev,
Björn Töpel, Y Song
In-Reply-To: <20180515111643.1507fead@redhat.com>
On Tue, 15 May 2018 11:16:43 +0200, Jesper Dangaard Brouer wrote:
> > $ cd tools/lib/bpf/
> > $ make
> >
> > Auto-detecting system features:
> > ... libelf: [ on ]
> > ... bpf: [ on ]
> >
> > Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from latest version at 'include/uapi/linux/bpf.h'
> > Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h' differs from latest version at 'include/uapi/linux/if_link.h'
> > CC libbpf.o
> > CC bpf.o
> > CC nlattr.o
> > CC btf.o
> > LD libbpf-in.o
> > LINK libbpf.a
> > LINK libbpf.so
>
> SOLVED
>
> It seems that the "Auto-detecting system" needed a 'make clean'.
> My problem goes away when I did the following:
>
> $ cd tools/
> $ make clean
>
> $ cd lib/bpf/
> $ make
>
> Auto-detecting system features:
> ... libelf: [ on ]
> ... bpf: [ on ]
Interesting! I've seen the same thing (on Fedora, not sure distro is
relevant). I tracked it down to dependency files (*.d) in
tools/build/features/ containing a reference to a sigset.h header which
didn't exist :S I did git clean -xdf to fix my tree.
Thanks for testing and sorry about the breakage!
^ permalink raw reply
* Re: [PATCH v1 iproute2-next 2/3] rdma: print driver resource attributes
From: Leon Romanovsky @ 2018-05-15 16:59 UTC (permalink / raw)
To: Doug Ledford; +Cc: Steve Wise, dsahern, stephen, netdev, linux-rdma
In-Reply-To: <13da78012c55e8f224c2226f3c0cfc53bd0522be.camel@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
On Tue, May 15, 2018 at 12:35:34PM -0400, Doug Ledford wrote:
> On Mon, 2018-05-14 at 09:51 -0500, Steve Wise wrote:
> >
> > On 5/13/2018 8:24 AM, Leon Romanovsky wrote:
> > > On Mon, May 07, 2018 at 08:53:16AM -0700, Steve Wise wrote:
> > > > This enhancement allows printing rdma device-specific state, if provided
> > > > by the kernel. This is done in a generic manner, so rdma tool doesn't
> > >
> > > Double space between "." and "This".
> > >
> > > > need to know about the details of every type of rdma device.
> > > >
> > > > Driver attributes for a rdma resource are in the form of <key,
> > > > [print_type], value> tuples, where the key is a string and the value can
> > > > be any supported driver attribute. The print_type attribute, if present,
> > >
> > > ditto
> >
> > I'll fix these.
>
> Fix it if you want, but don't do it because Leon told you to. A double
> space after period is perfectly acceptable.
It is very controversial thing [1],
"Most style guides indicate that single sentence spacing is proper for
final or published work today, and most publishers require manuscripts
to be submitted as they will appear in publication—single
sentence spaced."
[1] https://en.wikipedia.org/wiki/Sentence_spacing
>
> --
> Doug Ledford <dledford@redhat.com>
> GPG KeyID: B826A3330E572FDD
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC bpf-next 07/11] bpf: Add helper to retrieve socket in BPF
From: Martin KaFai Lau @ 2018-05-15 16:48 UTC (permalink / raw)
To: Alexei Starovoitov, Joe Stringer; +Cc: daniel, netdev, ast, john fastabend
In-Reply-To: <20180515031657.4wza3jsatn2ggsj5@ast-mbp>
On Mon, May 14, 2018 at 08:16:59PM -0700, Alexei Starovoitov wrote:
> On Fri, May 11, 2018 at 05:54:33PM -0700, Joe Stringer wrote:
> > On 11 May 2018 at 14:41, Martin KaFai Lau <kafai@fb.com> wrote:
> > > On Fri, May 11, 2018 at 02:08:01PM -0700, Joe Stringer wrote:
> > >> On 10 May 2018 at 22:00, Martin KaFai Lau <kafai@fb.com> wrote:
> > >> > On Wed, May 09, 2018 at 02:07:05PM -0700, Joe Stringer wrote:
> > >> >> This patch adds a new BPF helper function, sk_lookup() which allows BPF
> > >> >> programs to find out if there is a socket listening on this host, and
> > >> >> returns a socket pointer which the BPF program can then access to
> > >> >> determine, for instance, whether to forward or drop traffic. sk_lookup()
> > >> >> takes a reference on the socket, so when a BPF program makes use of this
> > >> >> function, it must subsequently pass the returned pointer into the newly
> > >> >> added sk_release() to return the reference.
> > >> >>
> > >> >> By way of example, the following pseudocode would filter inbound
> > >> >> connections at XDP if there is no corresponding service listening for
> > >> >> the traffic:
> > >> >>
> > >> >> struct bpf_sock_tuple tuple;
> > >> >> struct bpf_sock_ops *sk;
> > >> >>
> > >> >> populate_tuple(ctx, &tuple); // Extract the 5tuple from the packet
> > >> >> sk = bpf_sk_lookup(ctx, &tuple, sizeof tuple, netns, 0);
> > >> >> if (!sk) {
> > >> >> // Couldn't find a socket listening for this traffic. Drop.
> > >> >> return TC_ACT_SHOT;
> > >> >> }
> > >> >> bpf_sk_release(sk, 0);
> > >> >> return TC_ACT_OK;
> > >> >>
> > >> >> Signed-off-by: Joe Stringer <joe@wand.net.nz>
> > >> >> ---
> > >>
> > >> ...
> > >>
> > >> >> @@ -4032,6 +4036,96 @@ static const struct bpf_func_proto bpf_skb_get_xfrm_state_proto = {
> > >> >> };
> > >> >> #endif
> > >> >>
> > >> >> +struct sock *
> > >> >> +sk_lookup(struct net *net, struct bpf_sock_tuple *tuple) {
> > >> > Would it be possible to have another version that
> > >> > returns a sk without taking its refcnt?
> > >> > It may have performance benefit.
> > >>
> > >> Not really. The sockets are not RCU-protected, and established sockets
> > >> may be torn down without notice. If we don't take a reference, there's
> > >> no guarantee that the socket will continue to exist for the duration
> > >> of running the BPF program.
> > >>
> > >> From what I follow, the comment below has a hidden implication which
> > >> is that sockets without SOCK_RCU_FREE, eg established sockets, may be
> > >> directly freed regardless of RCU.
> > > Right, SOCK_RCU_FREE sk is the one I am concern about.
> > > For example, TCP_LISTEN socket does not require taking a refcnt
> > > now. Doing a bpf_sk_lookup() may have a rather big
> > > impact on handling TCP syn flood. or the usual intention
> > > is to redirect instead of passing it up to the stack?
> >
> > I see, if you're only interested in listen sockets then probably this
> > series could be extended with a new flag, eg something like
> > BPF_F_SK_FIND_LISTENERS which restricts the set of possible sockets
> > found to only listen sockets, then the implementation would call into
> > __inet_lookup_listener() instead of inet_lookup(). The presence of
> > that flag in the relevant register during CALL instruction would show
> > that the verifier should not reference-track the result, then there'd
> > need to be a check on the release to ensure that this unreferenced
> > socket is never released. Just a thought, completely untested and I
> > could still be missing some detail..
> >
> > That said, I don't completely follow how you would expect to handle
> > the traffic for sockets that are already established - the helper
> > would no longer find those sockets, so you wouldn't know whether to
> > pass the traffic up the stack for established traffic or not.
>
> I think Martin has a valid concern here that if somebody starts using
> this helper on the rx traffic the bpf program (via these two new
> helpers) will be doing refcnt++ and refcnt-- even for listener
> sockets which will cause synflood to suffer.
> One can argue that this is bpf author mistake, but without fixes
> (and api changes) to the helper the programmer doesn't really have a way
> of avoiding this situation.
> Also udp sockets don't need refcnt at all.
> How about we split this single helper into three:
> - bpf_sk_lookup_tcp_established() that will return refcnt-ed socket
> and has to be bpf_sk_release()d by the program.
> - bpf_sk_lookup_tcp_listener() that doesn't refcnt, since progs
> run in rcu.
> - bpf_sk_lookup_udp() that also doesn't refcnt.
> The logic you want to put into this helper can be easily
> replicated with these three helpers and the whole thing will
> be much faster.
> Thoughts?
Just came to my mind.
or can we explore something like:
On the bpf_sk_lookup() side, use __inet[6]_lookup()
and __udp[46]_lib_lookup() instead. That should
only take refcnt if it has to.
On the bpf_sk_release() side, it skips refcnt--
if sk is SOCK_RCU_FREE.
^ permalink raw reply
* Re: [PATCH net] tcp: purge write queue in tcp_connect_init()
From: Neal Cardwell @ 2018-05-15 16:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Netdev, Eric Dumazet, Yuchung Cheng
In-Reply-To: <20180515041426.94062-1-edumazet@google.com>
On Tue, May 15, 2018 at 12:14 AM Eric Dumazet <edumazet@google.com> wrote:
> syzkaller found a reliable way to crash the host, hitting a BUG()
> in __tcp_retransmit_skb()
> Malicous MSG_FASTOPEN is the root cause. We need to purge write queue
> in tcp_connect_init() at the point we init snd_una/write_seq.
> This patch also replaces the BUG() by a less intrusive WARN_ON_ONCE()
> kernel BUG at net/ipv4/tcp_output.c:2837!
...
> Fixes: cf60af03ca4e ("net-tcp: Fast Open client - sendmsg(MSG_FASTOPEN)")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> ---
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks, Eric!
neal
^ permalink raw reply
* Re: [PATCH v1 iproute2-next 2/3] rdma: print driver resource attributes
From: Doug Ledford @ 2018-05-15 16:35 UTC (permalink / raw)
To: Steve Wise, Leon Romanovsky; +Cc: dsahern, stephen, netdev, linux-rdma
In-Reply-To: <c57b8f18-858c-62df-50c6-453933a67913@opengridcomputing.com>
[-- Attachment #1: Type: text/plain, Size: 998 bytes --]
On Mon, 2018-05-14 at 09:51 -0500, Steve Wise wrote:
>
> On 5/13/2018 8:24 AM, Leon Romanovsky wrote:
> > On Mon, May 07, 2018 at 08:53:16AM -0700, Steve Wise wrote:
> > > This enhancement allows printing rdma device-specific state, if provided
> > > by the kernel. This is done in a generic manner, so rdma tool doesn't
> >
> > Double space between "." and "This".
> >
> > > need to know about the details of every type of rdma device.
> > >
> > > Driver attributes for a rdma resource are in the form of <key,
> > > [print_type], value> tuples, where the key is a string and the value can
> > > be any supported driver attribute. The print_type attribute, if present,
> >
> > ditto
>
> I'll fix these.
Fix it if you want, but don't do it because Leon told you to. A double
space after period is perfectly acceptable.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RESEND PATCH v2 1/1] net: phy: micrel: add 125MHz reference clock workaround
From: Andrew Lunn @ 2018-05-15 16:33 UTC (permalink / raw)
To: Marco Felsch
Cc: robh+dt, mark.rutland, f.fainelli, netdev, devicetree, kernel,
niebelm
In-Reply-To: <20180515081856.23322-2-m.felsch@pengutronix.de>
On Tue, May 15, 2018 at 10:18:56AM +0200, Marco Felsch wrote:
> From: Markus Niebel <Markus.Niebel@tqs.de>
>
> The micrel KSZ9031 phy has a optional clock pin (CLK125_NDO) which can be
> used as reference clock for the MAC unit. The clock signal must meet the
> RGMII requirements to ensure the correct data transmission between the
> MAC and the PHY. The KSZ9031 phy does not fulfill the duty cycle
> requirement if the phy is configured as slave. For a complete
> describtion look at the errata sheets: DS80000691D or DS80000692D.
>
> The errata sheet recommends to force the phy into master mode whenever
> there is a 1000Base-T link-up as work around. Only set the
> "micrel,force-master" property if you use the phy reference clock provided
> by CLK125_NDO pin as MAC reference clock in your application.
>
> Attenation, this workaround is only usable if the link partner can
> be configured to slave mode for 1000Base-T.
Thanks for adding all the documentation.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* KMSAN: uninit-value in __sctp_v6_cmp_addr
From: syzbot @ 2018-05-15 16:25 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, netdev, nhorman, syzkaller-bugs,
vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: 74ee2200b89f kmsan: bump .config.example to v4.17-rc3
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=169efb5b800000
kernel config: https://syzkaller.appspot.com/x/.config?x=4ca1e57bafa8ab1f
dashboard link: https://syzkaller.appspot.com/bug?extid=85490c30c260afff22f2
compiler: clang version 7.0.0 (trunk 329391)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=157e9237800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10fe5de7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+85490c30c260afff22f2@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x49a/0x850
net/sctp/ipv6.c:580
CPU: 0 PID: 4453 Comm: syz-executor325 Not tainted 4.17.0-rc3+ #88
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
__sctp_v6_cmp_addr+0x49a/0x850 net/sctp/ipv6.c:580
sctp_inet6_cmp_addr+0x3dc/0x400 net/sctp/ipv6.c:898
sctp_bind_addr_match+0x18b/0x2f0 net/sctp/bind_addr.c:330
sctp_addrs_lookup_transport+0x904/0xa20 net/sctp/input.c:942
__sctp_lookup_association net/sctp/input.c:985 [inline]
__sctp_rcv_lookup net/sctp/input.c:1249 [inline]
sctp_rcv+0x15e6/0x4d30 net/sctp/input.c:170
ip_local_deliver_finish+0x874/0xec0 net/ipv4/ip_input.c:215
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:256
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0xa36/0x1d00 net/ipv4/ip_input.c:396
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_rcv+0x118f/0x16d0 net/ipv4/ip_input.c:492
__netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4592
__netif_receive_skb net/core/dev.c:4657 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5337
napi_poll net/core/dev.c:5735 [inline]
net_rx_action+0x7c1/0x1a70 net/core/dev.c:5801
__do_softirq+0x56d/0x93d kernel/softirq.c:285
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
</IRQ>
do_softirq kernel/softirq.c:329 [inline]
__local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
ip_finish_output2+0x135a/0x1470 net/ipv4/ip_output.c:231
ip_finish_output+0xcb2/0xff0 net/ipv4/ip_output.c:317
NF_HOOK_COND include/linux/netfilter.h:277 [inline]
ip_output+0x505/0x5d0 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:444 [inline]
ip_local_out net/ipv4/ip_output.c:124 [inline]
ip_queue_xmit+0x1a1e/0x1d10 net/ipv4/ip_output.c:504
sctp_v4_xmit+0x188/0x210 net/sctp/protocol.c:983
sctp_packet_transmit+0x3eaa/0x4350 net/sctp/output.c:650
sctp_outq_flush+0x1a7a/0x6320 net/sctp/outqueue.c:1197
sctp_outq_uncork+0xd2/0xf0 net/sctp/outqueue.c:776
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x8707/0x8d20 net/sctp/sm_sideeffect.c:1191
sctp_primitive_REQUESTHEARTBEAT+0x175/0x1a0 net/sctp/primitive.c:200
sctp_apply_peer_addr_params+0x207/0x1670 net/sctp/socket.c:2487
sctp_setsockopt_peer_addr_params net/sctp/socket.c:2683 [inline]
sctp_setsockopt+0x10e5f/0x11600 net/sctp/socket.c:4258
sock_common_setsockopt+0x136/0x170 net/core/sock.c:3039
__sys_setsockopt+0x4af/0x560 net/socket.c:1903
__do_sys_setsockopt net/socket.c:1914 [inline]
__se_sys_setsockopt net/socket.c:1911 [inline]
__x64_sys_setsockopt+0x15c/0x1c0 net/socket.c:1911
do_syscall_64+0x154/0x220 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x43fef9
RSP: 002b:00007ffc00d9bfd8 EFLAGS: 00000207 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fef9
RDX: 0000000000000009 RSI: 0000000000000084 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 0000000000000098 R09: 000000000000001c
R10: 0000000020000180 R11: 0000000000000207 R12: 0000000000401820
R13: 00000000004018b0 R14: 0000000000000000 R15: 0000000000000000
Local variable description: ----dest@sctp_rcv
Variable was created at:
sctp_rcv+0x13d/0x4d30 net/sctp/input.c:97
ip_local_deliver_finish+0x874/0xec0 net/ipv4/ip_input.c:215
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH 1/2] Convert target drivers to use sbitmap
From: Jens Axboe @ 2018-05-15 16:20 UTC (permalink / raw)
To: Matthew Wilcox, linux-kernel, linux-scsi, target-devel,
linux1394-devel, linux-usb, kvm, virtualization, netdev,
Juergen Gross, qla2xxx-upstream, Kent Overstreet
Cc: Matthew Wilcox
In-Reply-To: <3a56027b-47bc-dcb8-a465-3670031572f1@kernel.dk>
On 5/15/18 10:11 AM, Jens Axboe wrote:
> On 5/15/18 10:00 AM, Matthew Wilcox wrote:
>> From: Matthew Wilcox <mawilcox@microsoft.com>
>>
>> The sbitmap and the percpu_ida perform essentially the same task,
>> allocating tags for commands. Since the sbitmap is more used than
>> the percpu_ida, convert the percpu_ida users to the sbitmap API.
>
> It should also be the same performance as percpu_ida in light use, and
> performs much better at > 50% utilization of the tag space. I think
> that's better justification than "more used than".
Had to search long and hard for the perf numbers I did for percpu_ida
on higher utilization, but here it is:
https://lkml.org/lkml/2014/4/22/553
--
Jens Axboe
^ permalink raw reply
* RE: [PATCH V2 8/8] dt-bindings: stm32: add compatible for syscon
From: Christophe ROULLIER @ 2018-05-15 16:19 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, andrew@lunn.ch, Alexandre TORGUE,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
mcoquelin.stm32@gmail.com, Peppe CAVALLARO,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20180507163537.GA15212@rob-hp-laptop>
Hi Rob,
I do not understand, so let me explain our status:
We have syscfg IP Harware in our SOC.
But we do not have SoC specific driver to manage syscfg, we are using a generic driver "syscon".
So can you tell me what you wish to describe this part in our SOC bindings ?
Thanks for your help.
Christophe.
-----Original Message-----
From: Rob Herring [mailto:robh@kernel.org]
Sent: lundi 7 mai 2018 18:36
To: Christophe ROULLIER <christophe.roullier@st.com>
Cc: mark.rutland@arm.com; mcoquelin.stm32@gmail.com; Alexandre TORGUE <alexandre.torgue@st.com>; Peppe CAVALLARO <peppe.cavallaro@st.com>; devicetree@vger.kernel.org; andrew@lunn.ch; linux-arm-kernel@lists.infradead.org; netdev@vger.kernel.org
Subject: Re: [PATCH V2 8/8] dt-bindings: stm32: add compatible for syscon
On Wed, May 02, 2018 at 04:18:43PM +0200, Christophe Roullier wrote:
> This patch describes syscon DT bindings.
>
> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
> ---
> Documentation/devicetree/bindings/arm/stm32.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/stm32.txt
> b/Documentation/devicetree/bindings/arm/stm32.txt
> index 6808ed9..06e3834 100644
> --- a/Documentation/devicetree/bindings/arm/stm32.txt
> +++ b/Documentation/devicetree/bindings/arm/stm32.txt
> @@ -8,3 +8,7 @@ using one of the following compatible strings:
> st,stm32f746
> st,stm32h743
> st,stm32mp157
> +
> +Required nodes:
> +- syscon: the soc bus node must have a system controller node
> +pointing to the
> + global control registers, with the compatible string "syscon";
You misunderstood my prior comment. 'syscon' alone is not valid. You need SoC specific compatible string for it and 'stm32' is not SoC specific. IOW, the compatible property for a syscon should imply every single register field in the block.
Rob
^ permalink raw reply
* Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not working
From: Florian Fainelli @ 2018-05-15 16:17 UTC (permalink / raw)
To: Andrew Lunn, Michal Vokáč; +Cc: netdev, Vivien Didelot
In-Reply-To: <20180515160824.GJ27867@lunn.ch>
On 05/15/2018 09:08 AM, Andrew Lunn wrote:
> On Tue, May 15, 2018 at 04:25:49PM +0200, Michal Vokáč wrote:
>> On 10.5.2018 16:29, Andrew Lunn wrote:
>>> I would probably add code to dump all the qca8k registers. Compare the
>>> values for your working setup and your non-working setup. Hopefully
>>> they are not too different, and you can quickly get to the bits which
>>> matter.
>>
>> Perfect! Thanks to your suggestion I did that again and much more carefully.
>> After some tedious comparison I think I finally found the problem.
>>
>> The RGMII works only if I write 0x7e to the PORT0_STATUS (0x7c) register
>> from setup. Then I found out that this setup is also described in
>> Qualcomm QCA8334 Q&A document. When I do that, everything work as expected.
>
> Great.
>
>>
>> Both PORT0 and PORT6 may be configured as xGMII, xMII and SerDes and their
>> functions may be exchanged. In all cases the port status register should be
>> set to 0x7X where X depends on the link speed setup.
>>
>> Translated into register bits this means:
>> - clear BIT(12) - disable MAC flow control auto-negotiation (set by default)
>> - clear BIT(7) - disable MAC Tx flow control in half-duplex (set by default)
>> - set BIT(6) - use full-duplex
>> - set BIT(5,4) - enable Rx/Tx flow control
>> - set BIT(3) - enable Rx MAC - this one is tricky, the bit is described as
>> R/O in datasheet but it does not work when not set.
>> - set BIT(2) - enable Tx MAC
>> - set BIT(1,0) - set speed to 1000Mb
>
> The Marvell devices have something similar. What we do there is for
> the cpu port is to always set the port up, full duplex, and the
> fastest speed it supports. This covers 95% of boards. We have a few
> boards where the SoC on the other end can only do 100Mbps, not
> 1G. Then we use a fixed-phy.
>
>> I wonder whether there are some users of this driver and what may be their
>> setup that they are not affected by that?
>
> It could be the bootloader is setting up the CPU port? I don't really
> like that.
This is unfortunately not uncommon...
>
>> I would like to have confirmed that I understand it correctly and that
>> the problem is really in the driver not handling fixed-link.
>
> I would actually skip fixed-link, if you don't need it. Just hardwire
> the CPU port, like the Marvell driver does:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/net/dsa/mv88e6xxx/chip.c#L1780
>
> I would do it here:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/net/dsa/qca8k.c#L518
Agreed with Andrew here, though if you can implement fixed-link, this
should be more future proof.
As far as people using this driver, John submitted it, but we have not
see many fixes/enhancements, so I am not clear who is actually using it
these days... glad you are though!
--
Florian
^ permalink raw reply
* Re: [PATCH 1/2] Convert target drivers to use sbitmap
From: Jens Axboe @ 2018-05-15 16:11 UTC (permalink / raw)
To: Matthew Wilcox, linux-kernel, linux-scsi, target-devel,
linux1394-devel, linux-usb, kvm, virtualization, netdev,
Juergen Gross, qla2xxx-upstream, Kent Overstreet
Cc: Matthew Wilcox
In-Reply-To: <20180515160043.27044-2-willy@infradead.org>
On 5/15/18 10:00 AM, Matthew Wilcox wrote:
> From: Matthew Wilcox <mawilcox@microsoft.com>
>
> The sbitmap and the percpu_ida perform essentially the same task,
> allocating tags for commands. Since the sbitmap is more used than
> the percpu_ida, convert the percpu_ida users to the sbitmap API.
It should also be the same performance as percpu_ida in light use, and
performs much better at > 50% utilization of the tag space. I think
that's better justification than "more used than".
> diff --git a/drivers/target/iscsi/iscsi_target_util.c b/drivers/target/iscsi/iscsi_target_util.c
> index 4435bf374d2d..28bcffae609f 100644
> --- a/drivers/target/iscsi/iscsi_target_util.c
> +++ b/drivers/target/iscsi/iscsi_target_util.c
> @@ -17,7 +17,7 @@
> ******************************************************************************/
>
> #include <linux/list.h>
> -#include <linux/percpu_ida.h>
> +#include <linux/sched/signal.h>
> #include <net/ipv6.h> /* ipv6_addr_equal() */
> #include <scsi/scsi_tcq.h>
> #include <scsi/iscsi_proto.h>
> @@ -147,6 +147,28 @@ void iscsit_free_r2ts_from_list(struct iscsi_cmd *cmd)
> spin_unlock_bh(&cmd->r2t_lock);
> }
>
> +int iscsit_wait_for_tag(struct se_session *se_sess, int state, int *cpup)
> +{
> + int tag = -1;
> + DEFINE_WAIT(wait);
> + struct sbq_wait_state *ws;
> +
> + if (state == TASK_RUNNING)
> + return tag;
> +
> + ws = &se_sess->sess_tag_pool.ws[0];
> + for (;;) {
> + prepare_to_wait_exclusive(&ws->wait, &wait, state);
> + if (signal_pending_state(state, current))
> + break;
> + schedule();
> + tag = sbitmap_queue_get(&se_sess->sess_tag_pool, cpup);
> + }
> +
> + finish_wait(&ws->wait, &wait);
> + return tag;
> +}
Seems like that should be:
ws = &se_sess->sess_tag_pool.ws[0];
for (;;) {
prepare_to_wait_exclusive(&ws->wait, &wait, state);
if (signal_pending_state(state, current))
break;
tag = sbitmap_queue_get(&se_sess->sess_tag_pool, cpup);
if (tag != -1)
break;
schedule();
}
finish_wait(&ws->wait, &wait);
return tag;
> /*
> * May be called from software interrupt (timer) context for allocating
> * iSCSI NopINs.
> @@ -155,9 +177,11 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn *conn, int state)
> {
> struct iscsi_cmd *cmd;
> struct se_session *se_sess = conn->sess->se_sess;
> - int size, tag;
> + int size, tag, cpu;
>
> - tag = percpu_ida_alloc(&se_sess->sess_tag_pool, state);
> + tag = sbitmap_queue_get(&se_sess->sess_tag_pool, &cpu);
> + if (tag < 0)
> + tag = iscsit_wait_for_tag(se_sess, state, &cpu);
> if (tag < 0)
> return NULL;
Might make sense to just roll the whole thing into iscsi_get_tag(), that
would be cleaner.
sbitmap should provide a helper for that, but we can do that cleanup
later. That would encapsulate things like the per-cpu caching hint too,
for instance.
Rest looks fine to me.
--
Jens Axboe
^ 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