[PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

This patch is meant to add support of ACPI to the Hisilicon RoCE driver.
Following changes have been made in the driver(s):

Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been done in
   the RoCE reset function part of the HNS ethernet driver. Earlier it only
   supported DT/syscon.

Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to detect
   the type and then either use DT specific or ACPI spcific functions. Where
   ever possible, this patch tries to make use of "Unified Device Property
   Interface" APIs to support both DT and ACPI through single interface.

NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI Table
     (DSDT and IORT tables) changes part of UEFI/BIOS. These changes are NOT
     part of this patch-set.
NOTE 2: Reset function in Patch 1/2 depends upon the reset function added in
     ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again, this
     change is NOT reflected in this patch-set.

Salil Mehta (2):
  net: hns: Add support of ACPI to HNS driver RoCE Reset function
  IB/hns: Add support of ACPI to the Hisilicon RoCE driver

 drivers/infiniband/hw/hns/hns_roce_device.h        |    2 +-
 drivers/infiniband/hw/hns/hns_roce_eq.c            |    2 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c         |   37 ++++--
 drivers/infiniband/hw/hns/hns_roce_hw_v1.h         |    2 +-
 drivers/infiniband/hw/hns/hns_roce_main.c          |  127 ++++++++++++++++----
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c  |   17 +--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c |   47 ++++++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |    9 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c |   53 +++++++-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h |    3 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  |    4 +-
 11 files changed, 228 insertions(+), 75 deletions(-)

-- 
1.7.9.5

[PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

This patch is meant to add support of ACPI to the Hisilicon RoCE driver.
Following changes have been made in the driver(s):

Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been done in
   the RoCE reset function part of the HNS ethernet driver. Earlier it only
   supported DT/syscon.

Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to detect
   the type and then either use DT specific or ACPI spcific functions. Where
   ever possible, this patch tries to make use of "Unified Device Property
   Interface" APIs to support both DT and ACPI through single interface.

NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI Table
     (DSDT and IORT tables) changes part of UEFI/BIOS. These changes are NOT
     part of this patch-set.
NOTE 2: Reset function in Patch 1/2 depends upon the reset function added in
     ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again, this
     change is NOT reflected in this patch-set.

Salil Mehta (2):
  net: hns: Add support of ACPI to HNS driver RoCE Reset function
  IB/hns: Add support of ACPI to the Hisilicon RoCE driver

 drivers/infiniband/hw/hns/hns_roce_device.h        |    2 +-
 drivers/infiniband/hw/hns/hns_roce_eq.c            |    2 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c         |   37 ++++--
 drivers/infiniband/hw/hns/hns_roce_hw_v1.h         |    2 +-
 drivers/infiniband/hw/hns/hns_roce_main.c          |  127 ++++++++++++++++----
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c  |   17 +--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c |   47 ++++++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |    9 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c |   53 +++++++-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h |    3 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  |    4 +-
 11 files changed, 228 insertions(+), 75 deletions(-)

-- 
1.7.9.5

[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver RoCE Reset function

[Salil Mehta]

In the Hip06 SoC, the RoCE Engine is part of the Hisilicon Network
Subsystem and is dependent upon DSAF module. Therefore, certain
functions like RESET are exposed through the common registers of
HNS DSAF module which are memory-mapped by the HNS driver and
currently can only be accessed through DT/syscon interface.

This patch adds the support of ACPI to the existing RoCE reset
function in the HNS driver(please refer NOTE 2). Hisilicon RoCE
driver (please refer NOTE 1) shall call this reset function during
probe time to reset the RoCE Engine.

The HNS Reset function indirectly ends up in calling the _DSM()
function part of the DSDT ACPI Table. Actual reset functionality
for ACPI is implemented within the ACPI DSDT Table which also has
been enhanced to support this change.

Support of ACPI in the HNS RoCE driver shall be pushed through a
different accompanying below patch:
"IB/hns: Add support of ACPI to the Hisilicon RoCE Driver"

NOTE 1: HNS RoCE driver has already been accepted by its maintainer
Doug Ledford<dledford@redhat.com>. Please refer below link:
https://www.spinics.net/lists/linux-rdma/msg38850.html

NOTE 2: RoCE reset function patch has been accepted and now is
part of the net-next:
https://www.mail-archive.com/netdev@vger.kernel.org/msg123867.html

Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Reviewed-by: Yisen Zhuang <yisen.zhuang@huawei.com>
---
Change Log

PATCH V1: Initial version to support ACPI in RoCE Reset
          functionality of the HNS driver.
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c  |   17 +------
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c |   47 ++++++++++++-----
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |    9 ++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c |   53 ++++++++++++++++++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h |    3 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  |    4 +-
 6 files changed, 92 insertions(+), 41 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index a834774..a68eef0 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -644,21 +644,6 @@ hns_mac_phy_parse_addr(struct device *dev, struct fwnode_handle *fwnode)
 	return addr;
 }
 
-static int hns_mac_phydev_match(struct device *dev, void *fwnode)
-{
-	return dev->fwnode == fwnode;
-}
-
-static struct
-platform_device *hns_mac_find_platform_device(struct fwnode_handle *fwnode)
-{
-	struct device *dev;
-
-	dev = bus_find_device(&platform_bus_type, NULL,
-			      fwnode, hns_mac_phydev_match);
-	return dev ? to_platform_device(dev) : NULL;
-}
-
 static int
 hns_mac_register_phydev(struct mii_bus *mdio, struct hns_mac_cb *mac_cb,
 			u32 addr)
@@ -724,7 +709,7 @@ static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
 		return;
 
 	/* dev address in adev */
-	pdev = hns_mac_find_platform_device(acpi_fwnode_handle(args.adev));
+	pdev = hns_dsaf_find_platform_device(acpi_fwnode_handle(args.adev));
 	mii_bus = platform_get_drvdata(pdev);
 	rc = hns_mac_register_phydev(mii_bus, mac_cb, addr);
 	if (!rc)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 05bd19f..9283bc6 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -2788,7 +2788,7 @@ module_platform_driver(g_dsaf_driver);
  * @enable: false - request reset , true - drop reset
  * retuen 0 - success , negative -fail
  */
-int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool enable)
+int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset)
 {
 	struct dsaf_device *dsaf_dev;
 	struct platform_device *pdev;
@@ -2817,24 +2817,44 @@ int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool enable)
 		{DSAF_ROCE_SL_1, DSAF_ROCE_SL_1, DSAF_ROCE_SL_3},
 	};
 
-	if (!is_of_node(dsaf_fwnode)) {
-		pr_err("hisi_dsaf: Only support DT node!\n");
+	/* find the platform device corresponding to fwnode */
+	if (is_of_node(dsaf_fwnode)) {
+		pdev = of_find_device_by_node(to_of_node(dsaf_fwnode));
+	} else if (is_acpi_device_node(dsaf_fwnode)) {
+		pdev = hns_dsaf_find_platform_device(dsaf_fwnode);
+	} else {
+		pr_err("fwnode is neither OF or ACPI type\n");
 		return -EINVAL;
 	}
-	pdev = of_find_device_by_node(to_of_node(dsaf_fwnode));
+
+	/* check if we were a success in fetching pdev */
+	if (!pdev) {
+		pr_err("couldn't find platform device for node\n");
+		return -ENODEV;
+	}
+
+	/* retrieve the dsaf_device from the driver data */
 	dsaf_dev = dev_get_drvdata(&pdev->dev);
+	if (!dsaf_dev) {
+		dev_err(&pdev->dev, "dsaf_dev is NULL\n");
+		return -ENODEV;
+	}
+
+	/* now, make sure we are running on compatible SoC */
 	if (AE_IS_VER1(dsaf_dev->dsaf_ver)) {
 		dev_err(dsaf_dev->dev, "%s v1 chip doesn't support RoCE!\n",
 			dsaf_dev->ae_dev.name);
 		return -ENODEV;
 	}
 
-	if (!enable) {
-		/* Reset rocee-channels in dsaf and rocee */
-		hns_dsaf_srst_chns(dsaf_dev, DSAF_CHNS_MASK, false);
-		hns_dsaf_roce_srst(dsaf_dev, false);
+	/* do reset or de-reset according to the flag */
+	if (!dereset) {
+		/* reset rocee-channels in dsaf and rocee */
+		dsaf_dev->misc_op->hns_dsaf_srst_chns(dsaf_dev, DSAF_CHNS_MASK,
+						      false);
+		dsaf_dev->misc_op->hns_dsaf_roce_srst(dsaf_dev, false);
 	} else {
-		/* Configure dsaf tx roce correspond to port map and sl map */
+		/* configure dsaf tx roce correspond to port map and sl map */
 		mp = dsaf_read_dev(dsaf_dev, DSAF_ROCE_PORT_MAP_REG);
 		for (i = 0; i < DSAF_ROCE_CREDIT_CHN; i++)
 			dsaf_set_field(mp, 7 << i * 3, i * 3,
@@ -2848,12 +2868,13 @@ int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool enable)
 				       sl_map[i][DSAF_ROCE_6PORT_MODE]);
 		dsaf_write_dev(dsaf_dev, DSAF_ROCE_SL_MAP_REG, sl);
 
-		/* De-reset rocee-channels in dsaf and rocee */
-		hns_dsaf_srst_chns(dsaf_dev, DSAF_CHNS_MASK, true);
+		/* de-reset rocee-channels in dsaf and rocee */
+		dsaf_dev->misc_op->hns_dsaf_srst_chns(dsaf_dev, DSAF_CHNS_MASK,
+						      true);
 		msleep(SRST_TIME_INTERVAL);
-		hns_dsaf_roce_srst(dsaf_dev, true);
+		dsaf_dev->misc_op->hns_dsaf_roce_srst(dsaf_dev, true);
 
-		/* Eanble dsaf channel rocee credit */
+		/* enable dsaf channel rocee credit */
 		credit = dsaf_read_dev(dsaf_dev, DSAF_SBM_ROCEE_CFG_REG_REG);
 		dsaf_set_bit(credit, DSAF_SBM_ROCEE_CFG_CRD_EN_B, 0);
 		dsaf_write_dev(dsaf_dev, DSAF_SBM_ROCEE_CFG_REG_REG, credit);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
index f3681d5..35df187 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
@@ -305,7 +305,7 @@ struct dsaf_misc_op {
 	void (*cpld_reset_led)(struct hns_mac_cb *mac_cb);
 	int (*cpld_set_led_id)(struct hns_mac_cb *mac_cb,
 			       enum hnae_led_state status);
-	/* reset seris function, it will be reset if the dereseet is 0 */
+	/* reset series function, it will be reset if the dereset is 0 */
 	void (*dsaf_reset)(struct dsaf_device *dsaf_dev, bool dereset);
 	void (*xge_srst)(struct dsaf_device *dsaf_dev, u32 port, bool dereset);
 	void (*xge_core_srst)(struct dsaf_device *dsaf_dev, u32 port,
@@ -313,6 +313,9 @@ struct dsaf_misc_op {
 	void (*ge_srst)(struct dsaf_device *dsaf_dev, u32 port, bool dereset);
 	void (*ppe_srst)(struct dsaf_device *dsaf_dev, u32 port, bool dereset);
 	void (*ppe_comm_srst)(struct dsaf_device *dsaf_dev, bool dereset);
+	void (*hns_dsaf_srst_chns)(struct dsaf_device *dsaf_dev, u32 msk,
+				   bool dereset);
+	void (*hns_dsaf_roce_srst)(struct dsaf_device *dsaf_dev, bool dereset);
 
 	phy_interface_t (*get_phy_if)(struct hns_mac_cb *mac_cb);
 	int (*get_sfp_prsnt)(struct hns_mac_cb *mac_cb, int *sfp_prsnt);
@@ -445,10 +448,6 @@ int hns_dsaf_get_mac_entry_by_index(
 
 void hns_dsaf_fix_mac_mode(struct hns_mac_cb *mac_cb);
 
-void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool enable);
-
-void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool enable);
-
 int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev);
 void hns_dsaf_ae_uninit(struct dsaf_device *dsaf_dev);
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index 36b9f79..67accce 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@ -26,6 +26,8 @@ enum _dsm_rst_type {
 	HNS_XGE_CORE_RESET_FUNC = 0x3,
 	HNS_XGE_RESET_FUNC      = 0x4,
 	HNS_GE_RESET_FUNC       = 0x5,
+	HNS_DSAF_CHN_RESET_FUNC = 0x6,
+	HNS_ROCE_RESET_FUNC     = 0x7,
 };
 
 const u8 hns_dsaf_acpi_dsm_uuid[] = {
@@ -241,11 +243,11 @@ static void hns_dsaf_xge_core_srst_by_port(struct dsaf_device *dsaf_dev,
  * bit18-19 for com/dfx
  * @enable: false - request reset , true - drop reset
  */
-void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool enable)
+void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool dereset)
 {
 	u32 reg_addr;
 
-	if (!enable)
+	if (!dereset)
 		reg_addr = DSAF_SUB_SC_DSAF_RESET_REQ_REG;
 	else
 		reg_addr = DSAF_SUB_SC_DSAF_RESET_DREQ_REG;
@@ -253,9 +255,27 @@ void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool enable)
 	dsaf_write_sub(dsaf_dev, reg_addr, msk);
 }
 
-void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool enable)
+/**
+ * hns_dsaf_srst_chns - reset dsaf channels
+ * @dsaf_dev: dsaf device struct pointer
+ * @msk: xbar channels mask value:
+ * bit0-5 for xge0-5
+ * bit6-11 for ppe0-5
+ * bit12-17 for roce0-5
+ * bit18-19 for com/dfx
+ * @enable: false - request reset , true - drop reset
+ */
+void
+hns_dsaf_srst_chns_acpi(struct dsaf_device *dsaf_dev, u32 msk, bool dereset)
 {
-	if (!enable) {
+	hns_dsaf_acpi_srst_by_port(dsaf_dev, HNS_OP_RESET_FUNC,
+				   HNS_DSAF_CHN_RESET_FUNC,
+				   msk, dereset);
+}
+
+void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool dereset)
+{
+	if (!dereset) {
 		dsaf_write_sub(dsaf_dev, DSAF_SUB_SC_ROCEE_RESET_REQ_REG, 1);
 	} else {
 		dsaf_write_sub(dsaf_dev,
@@ -267,6 +287,12 @@ void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool enable)
 	}
 }
 
+void hns_dsaf_roce_srst_acpi(struct dsaf_device *dsaf_dev, bool dereset)
+{
+	hns_dsaf_acpi_srst_by_port(dsaf_dev, HNS_OP_RESET_FUNC,
+				   HNS_ROCE_RESET_FUNC, 0, dereset);
+}
+
 static void
 hns_dsaf_xge_core_srst_by_port_acpi(struct dsaf_device *dsaf_dev,
 				    u32 port, bool dereset)
@@ -575,6 +601,8 @@ struct dsaf_misc_op *hns_misc_op_get(struct dsaf_device *dsaf_dev)
 		misc_op->ge_srst = hns_dsaf_ge_srst_by_port;
 		misc_op->ppe_srst = hns_ppe_srst_by_port;
 		misc_op->ppe_comm_srst = hns_ppe_com_srst;
+		misc_op->hns_dsaf_srst_chns = hns_dsaf_srst_chns;
+		misc_op->hns_dsaf_roce_srst = hns_dsaf_roce_srst;
 
 		misc_op->get_phy_if = hns_mac_get_phy_if;
 		misc_op->get_sfp_prsnt = hns_mac_get_sfp_prsnt;
@@ -591,6 +619,8 @@ struct dsaf_misc_op *hns_misc_op_get(struct dsaf_device *dsaf_dev)
 		misc_op->ge_srst = hns_dsaf_ge_srst_by_port_acpi;
 		misc_op->ppe_srst = hns_ppe_srst_by_port_acpi;
 		misc_op->ppe_comm_srst = hns_ppe_com_srst;
+		misc_op->hns_dsaf_srst_chns = hns_dsaf_srst_chns_acpi;
+		misc_op->hns_dsaf_roce_srst = hns_dsaf_roce_srst_acpi;
 
 		misc_op->get_phy_if = hns_mac_get_phy_if_acpi;
 		misc_op->get_sfp_prsnt = hns_mac_get_sfp_prsnt;
@@ -603,3 +633,18 @@ struct dsaf_misc_op *hns_misc_op_get(struct dsaf_device *dsaf_dev)
 
 	return (void *)misc_op;
 }
+
+static int hns_dsaf_dev_match(struct device *dev, void *fwnode)
+{
+	return dev->fwnode == fwnode;
+}
+
+struct
+platform_device *hns_dsaf_find_platform_device(struct fwnode_handle *fwnode)
+{
+	struct device *dev;
+
+	dev = bus_find_device(&platform_bus_type, NULL,
+			      fwnode, hns_dsaf_dev_match);
+	return dev ? to_platform_device(dev) : NULL;
+}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h
index f06bb03..310e802 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h
@@ -34,5 +34,6 @@
 #define DSAF_LED_ANCHOR_B 5
 
 struct dsaf_misc_op *hns_misc_op_get(struct dsaf_device *dsaf_dev);
-
+struct
+platform_device *hns_dsaf_find_platform_device(struct fwnode_handle *fwnode);
 #endif
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 13c16ab..4b8b803 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -78,10 +78,10 @@
 #define DSAF_SUB_SC_RCB_PPE_COM_RESET_REQ_REG		0xA88
 #define DSAF_SUB_SC_RCB_PPE_COM_RESET_DREQ_REG		0xA8C
 #define DSAF_SUB_SC_DSAF_RESET_REQ_REG			0xAA8
-#define DSAF_SUB_SC_ROCEE_RESET_REQ_REG			0xA50
 #define DSAF_SUB_SC_DSAF_RESET_DREQ_REG			0xAAC
-#define DSAF_SUB_SC_ROCEE_CLK_DIS_REG			0x32C
+#define DSAF_SUB_SC_ROCEE_RESET_REQ_REG			0xA50
 #define DSAF_SUB_SC_ROCEE_RESET_DREQ_REG		0xA54
+#define DSAF_SUB_SC_ROCEE_CLK_DIS_REG			0x32C
 #define DSAF_SUB_SC_ROCEE_CLK_EN_REG			0x328
 #define DSAF_SUB_SC_LIGHT_MODULE_DETECT_EN_REG		0x2060
 #define DSAF_SUB_SC_TCAM_MBIST_EN_REG			0x2300
-- 
1.7.9.5

[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver RoCE Reset function

[Salil Mehta]

In the Hip06 SoC, the RoCE Engine is part of the Hisilicon Network
Subsystem and is dependent upon DSAF module. Therefore, certain
functions like RESET are exposed through the common registers of
HNS DSAF module which are memory-mapped by the HNS driver and
currently can only be accessed through DT/syscon interface.

This patch adds the support of ACPI to the existing RoCE reset
function in the HNS driver(please refer NOTE 2). Hisilicon RoCE
driver (please refer NOTE 1) shall call this reset function during
probe time to reset the RoCE Engine.

The HNS Reset function indirectly ends up in calling the _DSM()
function part of the DSDT ACPI Table. Actual reset functionality
for ACPI is implemented within the ACPI DSDT Table which also has
been enhanced to support this change.

Support of ACPI in the HNS RoCE driver shall be pushed through a
different accompanying below patch:
"IB/hns: Add support of ACPI to the Hisilicon RoCE Driver"

NOTE 1: HNS RoCE driver has already been accepted by its maintainer
Doug Ledford<dledford@redhat.com>. Please refer below link:
https://www.spinics.net/lists/linux-rdma/msg38850.html

NOTE 2: RoCE reset function patch has been accepted and now is
part of the net-next:
https://www.mail-archive.com/netdev@vger.kernel.org/msg123867.html

Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Reviewed-by: Yisen Zhuang <yisen.zhuang@huawei.com>
---
Change Log

PATCH V1: Initial version to support ACPI in RoCE Reset
          functionality of the HNS driver.
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c  |   17 +------
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c |   47 ++++++++++++-----
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |    9 ++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c |   53 ++++++++++++++++++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h |    3 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  |    4 +-
 6 files changed, 92 insertions(+), 41 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index a834774..a68eef0 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -644,21 +644,6 @@ hns_mac_phy_parse_addr(struct device *dev, struct fwnode_handle *fwnode)
 	return addr;
 }
 
-static int hns_mac_phydev_match(struct device *dev, void *fwnode)
-{
-	return dev->fwnode == fwnode;
-}
-
-static struct
-platform_device *hns_mac_find_platform_device(struct fwnode_handle *fwnode)
-{
-	struct device *dev;
-
-	dev = bus_find_device(&platform_bus_type, NULL,
-			      fwnode, hns_mac_phydev_match);
-	return dev ? to_platform_device(dev) : NULL;
-}
-
 static int
 hns_mac_register_phydev(struct mii_bus *mdio, struct hns_mac_cb *mac_cb,
 			u32 addr)
@@ -724,7 +709,7 @@ static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
 		return;
 
 	/* dev address in adev */
-	pdev = hns_mac_find_platform_device(acpi_fwnode_handle(args.adev));
+	pdev = hns_dsaf_find_platform_device(acpi_fwnode_handle(args.adev));
 	mii_bus = platform_get_drvdata(pdev);
 	rc = hns_mac_register_phydev(mii_bus, mac_cb, addr);
 	if (!rc)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 05bd19f..9283bc6 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -2788,7 +2788,7 @@ module_platform_driver(g_dsaf_driver);
  * @enable: false - request reset , true - drop reset
  * retuen 0 - success , negative -fail
  */
-int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool enable)
+int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset)
 {
 	struct dsaf_device *dsaf_dev;
 	struct platform_device *pdev;
@@ -2817,24 +2817,44 @@ int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool enable)
 		{DSAF_ROCE_SL_1, DSAF_ROCE_SL_1, DSAF_ROCE_SL_3},
 	};
 
-	if (!is_of_node(dsaf_fwnode)) {
-		pr_err("hisi_dsaf: Only support DT node!\n");
+	/* find the platform device corresponding to fwnode */
+	if (is_of_node(dsaf_fwnode)) {
+		pdev = of_find_device_by_node(to_of_node(dsaf_fwnode));
+	} else if (is_acpi_device_node(dsaf_fwnode)) {
+		pdev = hns_dsaf_find_platform_device(dsaf_fwnode);
+	} else {
+		pr_err("fwnode is neither OF or ACPI type\n");
 		return -EINVAL;
 	}
-	pdev = of_find_device_by_node(to_of_node(dsaf_fwnode));
+
+	/* check if we were a success in fetching pdev */
+	if (!pdev) {
+		pr_err("couldn't find platform device for node\n");
+		return -ENODEV;
+	}
+
+	/* retrieve the dsaf_device from the driver data */
 	dsaf_dev = dev_get_drvdata(&pdev->dev);
+	if (!dsaf_dev) {
+		dev_err(&pdev->dev, "dsaf_dev is NULL\n");
+		return -ENODEV;
+	}
+
+	/* now, make sure we are running on compatible SoC */
 	if (AE_IS_VER1(dsaf_dev->dsaf_ver)) {
 		dev_err(dsaf_dev->dev, "%s v1 chip doesn't support RoCE!\n",
 			dsaf_dev->ae_dev.name);
 		return -ENODEV;
 	}
 
-	if (!enable) {
-		/* Reset rocee-channels in dsaf and rocee */
-		hns_dsaf_srst_chns(dsaf_dev, DSAF_CHNS_MASK, false);
-		hns_dsaf_roce_srst(dsaf_dev, false);
+	/* do reset or de-reset according to the flag */
+	if (!dereset) {
+		/* reset rocee-channels in dsaf and rocee */
+		dsaf_dev->misc_op->hns_dsaf_srst_chns(dsaf_dev, DSAF_CHNS_MASK,
+						      false);
+		dsaf_dev->misc_op->hns_dsaf_roce_srst(dsaf_dev, false);
 	} else {
-		/* Configure dsaf tx roce correspond to port map and sl map */
+		/* configure dsaf tx roce correspond to port map and sl map */
 		mp = dsaf_read_dev(dsaf_dev, DSAF_ROCE_PORT_MAP_REG);
 		for (i = 0; i < DSAF_ROCE_CREDIT_CHN; i++)
 			dsaf_set_field(mp, 7 << i * 3, i * 3,
@@ -2848,12 +2868,13 @@ int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool enable)
 				       sl_map[i][DSAF_ROCE_6PORT_MODE]);
 		dsaf_write_dev(dsaf_dev, DSAF_ROCE_SL_MAP_REG, sl);
 
-		/* De-reset rocee-channels in dsaf and rocee */
-		hns_dsaf_srst_chns(dsaf_dev, DSAF_CHNS_MASK, true);
+		/* de-reset rocee-channels in dsaf and rocee */
+		dsaf_dev->misc_op->hns_dsaf_srst_chns(dsaf_dev, DSAF_CHNS_MASK,
+						      true);
 		msleep(SRST_TIME_INTERVAL);
-		hns_dsaf_roce_srst(dsaf_dev, true);
+		dsaf_dev->misc_op->hns_dsaf_roce_srst(dsaf_dev, true);
 
-		/* Eanble dsaf channel rocee credit */
+		/* enable dsaf channel rocee credit */
 		credit = dsaf_read_dev(dsaf_dev, DSAF_SBM_ROCEE_CFG_REG_REG);
 		dsaf_set_bit(credit, DSAF_SBM_ROCEE_CFG_CRD_EN_B, 0);
 		dsaf_write_dev(dsaf_dev, DSAF_SBM_ROCEE_CFG_REG_REG, credit);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
index f3681d5..35df187 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
@@ -305,7 +305,7 @@ struct dsaf_misc_op {
 	void (*cpld_reset_led)(struct hns_mac_cb *mac_cb);
 	int (*cpld_set_led_id)(struct hns_mac_cb *mac_cb,
 			       enum hnae_led_state status);
-	/* reset seris function, it will be reset if the dereseet is 0 */
+	/* reset series function, it will be reset if the dereset is 0 */
 	void (*dsaf_reset)(struct dsaf_device *dsaf_dev, bool dereset);
 	void (*xge_srst)(struct dsaf_device *dsaf_dev, u32 port, bool dereset);
 	void (*xge_core_srst)(struct dsaf_device *dsaf_dev, u32 port,
@@ -313,6 +313,9 @@ struct dsaf_misc_op {
 	void (*ge_srst)(struct dsaf_device *dsaf_dev, u32 port, bool dereset);
 	void (*ppe_srst)(struct dsaf_device *dsaf_dev, u32 port, bool dereset);
 	void (*ppe_comm_srst)(struct dsaf_device *dsaf_dev, bool dereset);
+	void (*hns_dsaf_srst_chns)(struct dsaf_device *dsaf_dev, u32 msk,
+				   bool dereset);
+	void (*hns_dsaf_roce_srst)(struct dsaf_device *dsaf_dev, bool dereset);
 
 	phy_interface_t (*get_phy_if)(struct hns_mac_cb *mac_cb);
 	int (*get_sfp_prsnt)(struct hns_mac_cb *mac_cb, int *sfp_prsnt);
@@ -445,10 +448,6 @@ int hns_dsaf_get_mac_entry_by_index(
 
 void hns_dsaf_fix_mac_mode(struct hns_mac_cb *mac_cb);
 
-void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool enable);
-
-void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool enable);
-
 int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev);
 void hns_dsaf_ae_uninit(struct dsaf_device *dsaf_dev);
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index 36b9f79..67accce 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@ -26,6 +26,8 @@ enum _dsm_rst_type {
 	HNS_XGE_CORE_RESET_FUNC = 0x3,
 	HNS_XGE_RESET_FUNC      = 0x4,
 	HNS_GE_RESET_FUNC       = 0x5,
+	HNS_DSAF_CHN_RESET_FUNC = 0x6,
+	HNS_ROCE_RESET_FUNC     = 0x7,
 };
 
 const u8 hns_dsaf_acpi_dsm_uuid[] = {
@@ -241,11 +243,11 @@ static void hns_dsaf_xge_core_srst_by_port(struct dsaf_device *dsaf_dev,
  * bit18-19 for com/dfx
  * @enable: false - request reset , true - drop reset
  */
-void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool enable)
+void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool dereset)
 {
 	u32 reg_addr;
 
-	if (!enable)
+	if (!dereset)
 		reg_addr = DSAF_SUB_SC_DSAF_RESET_REQ_REG;
 	else
 		reg_addr = DSAF_SUB_SC_DSAF_RESET_DREQ_REG;
@@ -253,9 +255,27 @@ void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool enable)
 	dsaf_write_sub(dsaf_dev, reg_addr, msk);
 }
 
-void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool enable)
+/**
+ * hns_dsaf_srst_chns - reset dsaf channels
+ * @dsaf_dev: dsaf device struct pointer
+ * @msk: xbar channels mask value:
+ * bit0-5 for xge0-5
+ * bit6-11 for ppe0-5
+ * bit12-17 for roce0-5
+ * bit18-19 for com/dfx
+ * @enable: false - request reset , true - drop reset
+ */
+void
+hns_dsaf_srst_chns_acpi(struct dsaf_device *dsaf_dev, u32 msk, bool dereset)
 {
-	if (!enable) {
+	hns_dsaf_acpi_srst_by_port(dsaf_dev, HNS_OP_RESET_FUNC,
+				   HNS_DSAF_CHN_RESET_FUNC,
+				   msk, dereset);
+}
+
+void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool dereset)
+{
+	if (!dereset) {
 		dsaf_write_sub(dsaf_dev, DSAF_SUB_SC_ROCEE_RESET_REQ_REG, 1);
 	} else {
 		dsaf_write_sub(dsaf_dev,
@@ -267,6 +287,12 @@ void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool enable)
 	}
 }
 
+void hns_dsaf_roce_srst_acpi(struct dsaf_device *dsaf_dev, bool dereset)
+{
+	hns_dsaf_acpi_srst_by_port(dsaf_dev, HNS_OP_RESET_FUNC,
+				   HNS_ROCE_RESET_FUNC, 0, dereset);
+}
+
 static void
 hns_dsaf_xge_core_srst_by_port_acpi(struct dsaf_device *dsaf_dev,
 				    u32 port, bool dereset)
@@ -575,6 +601,8 @@ struct dsaf_misc_op *hns_misc_op_get(struct dsaf_device *dsaf_dev)
 		misc_op->ge_srst = hns_dsaf_ge_srst_by_port;
 		misc_op->ppe_srst = hns_ppe_srst_by_port;
 		misc_op->ppe_comm_srst = hns_ppe_com_srst;
+		misc_op->hns_dsaf_srst_chns = hns_dsaf_srst_chns;
+		misc_op->hns_dsaf_roce_srst = hns_dsaf_roce_srst;
 
 		misc_op->get_phy_if = hns_mac_get_phy_if;
 		misc_op->get_sfp_prsnt = hns_mac_get_sfp_prsnt;
@@ -591,6 +619,8 @@ struct dsaf_misc_op *hns_misc_op_get(struct dsaf_device *dsaf_dev)
 		misc_op->ge_srst = hns_dsaf_ge_srst_by_port_acpi;
 		misc_op->ppe_srst = hns_ppe_srst_by_port_acpi;
 		misc_op->ppe_comm_srst = hns_ppe_com_srst;
+		misc_op->hns_dsaf_srst_chns = hns_dsaf_srst_chns_acpi;
+		misc_op->hns_dsaf_roce_srst = hns_dsaf_roce_srst_acpi;
 
 		misc_op->get_phy_if = hns_mac_get_phy_if_acpi;
 		misc_op->get_sfp_prsnt = hns_mac_get_sfp_prsnt;
@@ -603,3 +633,18 @@ struct dsaf_misc_op *hns_misc_op_get(struct dsaf_device *dsaf_dev)
 
 	return (void *)misc_op;
 }
+
+static int hns_dsaf_dev_match(struct device *dev, void *fwnode)
+{
+	return dev->fwnode == fwnode;
+}
+
+struct
+platform_device *hns_dsaf_find_platform_device(struct fwnode_handle *fwnode)
+{
+	struct device *dev;
+
+	dev = bus_find_device(&platform_bus_type, NULL,
+			      fwnode, hns_dsaf_dev_match);
+	return dev ? to_platform_device(dev) : NULL;
+}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h
index f06bb03..310e802 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h
@@ -34,5 +34,6 @@
 #define DSAF_LED_ANCHOR_B 5
 
 struct dsaf_misc_op *hns_misc_op_get(struct dsaf_device *dsaf_dev);
-
+struct
+platform_device *hns_dsaf_find_platform_device(struct fwnode_handle *fwnode);
 #endif
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 13c16ab..4b8b803 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -78,10 +78,10 @@
 #define DSAF_SUB_SC_RCB_PPE_COM_RESET_REQ_REG		0xA88
 #define DSAF_SUB_SC_RCB_PPE_COM_RESET_DREQ_REG		0xA8C
 #define DSAF_SUB_SC_DSAF_RESET_REQ_REG			0xAA8
-#define DSAF_SUB_SC_ROCEE_RESET_REQ_REG			0xA50
 #define DSAF_SUB_SC_DSAF_RESET_DREQ_REG			0xAAC
-#define DSAF_SUB_SC_ROCEE_CLK_DIS_REG			0x32C
+#define DSAF_SUB_SC_ROCEE_RESET_REQ_REG			0xA50
 #define DSAF_SUB_SC_ROCEE_RESET_DREQ_REG		0xA54
+#define DSAF_SUB_SC_ROCEE_CLK_DIS_REG			0x32C
 #define DSAF_SUB_SC_ROCEE_CLK_EN_REG			0x328
 #define DSAF_SUB_SC_LIGHT_MODULE_DETECT_EN_REG		0x2060
 #define DSAF_SUB_SC_TCAM_MBIST_EN_REG			0x2300
-- 
1.7.9.5

[PATCH for-next 2/2] IB/hns: Add support of ACPI to the Hisilicon RoCE driver

[Salil Mehta]

This patch is meant to add support of ACPI to the Hisilicon RoCE
driver.

Changes done are primarily meant to detect the type and then either
use DT specific or ACPI spcific functions. Where ever possible,
this patch tries to make use of Unified Device Property Interface
APIs to support both DT and ACPI through single interface.

This patch depends upon HNS ethernet driver to Reset RoCE. This
function within HNS ethernet driver has also been enhanced to
support ACPI and is part of other accompanying patch with this
patch-set.

NOTE: The changes in this patch are done over below branch,
https://github.com/dledford/linux/tree/hns-roce

Signed-off-by: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
Change Log

PATCH V1: Initial version to support ACPI in HNS RoCE driver.
---
 drivers/infiniband/hw/hns/hns_roce_device.h |    2 +-
 drivers/infiniband/hw/hns/hns_roce_eq.c     |    2 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c  |   37 ++++++--
 drivers/infiniband/hw/hns/hns_roce_hw_v1.h  |    2 +-
 drivers/infiniband/hw/hns/hns_roce_main.c   |  127 ++++++++++++++++++++++-----
 5 files changed, 136 insertions(+), 34 deletions(-)

diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h b/drivers/infiniband/hw/hns/hns_roce_device.h
index 00f01be..ea73580 100644
--- a/drivers/infiniband/hw/hns/hns_roce_device.h
+++ b/drivers/infiniband/hw/hns/hns_roce_device.h
@@ -531,7 +531,7 @@ struct hns_roce_dev {
 	struct ib_device	ib_dev;
 	struct platform_device  *pdev;
 	struct hns_roce_uar     priv_uar;
-	const char		*irq_names;
+	const char		*irq_names[HNS_ROCE_MAX_IRQ_NUM];
 	spinlock_t		sm_lock;
 	spinlock_t		cq_db_lock;
 	spinlock_t		bt_cmd_lock;
diff --git a/drivers/infiniband/hw/hns/hns_roce_eq.c b/drivers/infiniband/hw/hns/hns_roce_eq.c
index 5febbb4..98af7fe 100644
--- a/drivers/infiniband/hw/hns/hns_roce_eq.c
+++ b/drivers/infiniband/hw/hns/hns_roce_eq.c
@@ -713,7 +713,7 @@ int hns_roce_init_eq_table(struct hns_roce_dev *hr_dev)
 
 	for (j = 0; j < eq_num; j++) {
 		ret = request_irq(eq_table->eq[j].irq, hns_roce_msi_x_interrupt,
-				  0, hr_dev->irq_names, eq_table->eq + j);
+				  0, hr_dev->irq_names[j], eq_table->eq + j);
 		if (ret) {
 			dev_err(dev, "request irq error!\n");
 			goto err_request_irq_fail;
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
index b52f3ba..399f5de 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -31,6 +31,7 @@
  */
 
 #include <linux/platform_device.h>
+#include <linux/acpi.h>
 #include <rdma/ib_umem.h>
 #include "hns_roce_common.h"
 #include "hns_roce_device.h"
@@ -794,29 +795,47 @@ static void hns_roce_port_enable(struct hns_roce_dev *hr_dev, int enable_flag)
  * @enable: true -- drop reset, false -- reset
  * return 0 - success , negative --fail
  */
-int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool enable)
+int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool dereset)
 {
 	struct device_node *dsaf_node;
 	struct device *dev = &hr_dev->pdev->dev;
 	struct device_node *np = dev->of_node;
+	struct fwnode_handle *fwnode;
 	int ret;
 
-	dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
-	if (!dsaf_node) {
-		dev_err(dev, "Unable to get dsaf node by dsaf-handle!\n");
-		return -EINVAL;
+	/* check if this is DT/ACPI case */
+	if (dev_of_node(dev)) {
+		dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
+		if (!dsaf_node) {
+			dev_err(dev, "could not find dsaf-handle\n");
+			return -EINVAL;
+		}
+		fwnode = &dsaf_node->fwnode;
+	} else if (is_acpi_device_node(dev->fwnode)) {
+		struct acpi_reference_args args;
+
+		ret = acpi_node_get_property_reference(dev->fwnode,
+						       "dsaf-handle", 0, &args);
+		if (ret) {
+			dev_err(dev, "could not find dsaf-handle\n");
+			return ret;
+		}
+		fwnode = acpi_fwnode_handle(args.adev);
+	} else {
+		dev_err(dev, "cannot read data from DT or ACPI\n");
+		return -ENXIO;
 	}
 
-	ret = hns_dsaf_roce_reset(&dsaf_node->fwnode, false);
+	ret = hns_dsaf_roce_reset(fwnode, false);
 	if (ret)
 		return ret;
 
-	if (enable) {
+	if (dereset) {
 		msleep(SLEEP_TIME_INTERVAL);
-		return hns_dsaf_roce_reset(&dsaf_node->fwnode, true);
+		ret = hns_dsaf_roce_reset(fwnode, true);
 	}
 
-	return 0;
+	return ret;
 }
 
 void hns_roce_v1_profile(struct hns_roce_dev *hr_dev)
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.h b/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
index 2b3bf21..316b592 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
@@ -976,6 +976,6 @@ struct hns_roce_v1_priv {
 	struct hns_roce_raq_table raq_table;
 };
 
-int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool enable);
+int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset);
 
 #endif
diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c
index 6ead671..f64f0dd 100644
--- a/drivers/infiniband/hw/hns/hns_roce_main.c
+++ b/drivers/infiniband/hw/hns/hns_roce_main.c
@@ -30,7 +30,7 @@
  * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  * SOFTWARE.
  */
-
+#include <linux/acpi.h>
 #include <linux/of_platform.h>
 #include <rdma/ib_addr.h>
 #include <rdma/ib_smi.h>
@@ -694,40 +694,122 @@ error_failed_setup_mtu_gids:
 	return ret;
 }
 
+static const struct of_device_id hns_roce_of_match[] = {
+	{ .compatible = "hisilicon,hns-roce-v1", .data = &hns_roce_hw_v1, },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hns_roce_of_match);
+
+static const struct acpi_device_id hns_roce_acpi_match[] = {
+	{ "HISI00D1", (kernel_ulong_t)&hns_roce_hw_v1 },
+	{},
+};
+MODULE_DEVICE_TABLE(acpi, hns_roce_acpi_match);
+
+static int hns_roce_node_match(struct device *dev, void *fwnode)
+{
+	return dev->fwnode == fwnode;
+}
+
+static struct
+platform_device *hns_roce_find_pdev(struct fwnode_handle *fwnode)
+{
+	struct device *dev;
+
+	/* get the 'device'corresponding to matching 'fwnode' */
+	dev = bus_find_device(&platform_bus_type, NULL,
+			      fwnode, hns_roce_node_match);
+	/* get the platform device */
+	return dev ? to_platform_device(dev) : NULL;
+}
+
 static int hns_roce_get_cfg(struct hns_roce_dev *hr_dev)
 {
 	int i;
+	int ret;
 	u8 phy_port;
 	int port_cnt = 0;
 	struct device *dev = &hr_dev->pdev->dev;
-	struct device_node *np = dev->of_node;
 	struct device_node *net_node;
 	struct net_device *netdev = NULL;
 	struct platform_device *pdev = NULL;
 	struct resource *res;
 
-	if (of_device_is_compatible(np, "hisilicon,hns-roce-v1")) {
-		hr_dev->hw = &hns_roce_hw_v1;
+	/* check if we are compatible with the underlying SoC */
+	if (dev_of_node(dev)) {
+		const struct of_device_id *of_id;
+
+		of_id = of_match_node(hns_roce_of_match, dev->of_node);
+		if (!of_id) {
+			dev_err(dev, "device is not compatible!\n");
+			return -ENXIO;
+		}
+		hr_dev->hw = (struct hns_roce_hw *)of_id->data;
+		if (!hr_dev->hw) {
+			dev_err(dev, "couldn't get H/W specific DT data!\n");
+			return -ENXIO;
+		}
+	} else if (is_acpi_device_node(dev->fwnode)) {
+		const struct acpi_device_id *acpi_id;
+
+		acpi_id = acpi_match_device(hns_roce_acpi_match, dev);
+		if (!acpi_id) {
+			dev_err(dev, "device is not compatible!\n");
+			return -ENXIO;
+		}
+		hr_dev->hw = (struct hns_roce_hw *) acpi_id->driver_data;
+		if (!hr_dev->hw) {
+			dev_err(dev, "couldn't get H/W specific ACPI data!\n");
+			return -ENXIO;
+		}
 	} else {
-		dev_err(dev, "device no compatible!\n");
-		return -EINVAL;
+		dev_err(dev, "can't read compatibility data from DT or ACPI\n");
+		return -ENXIO;
 	}
 
+	/* get the mapped register base address */
 	res = platform_get_resource(hr_dev->pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "memory resource not found!\n");
+		return -EINVAL;
+	}
 	hr_dev->reg_base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(hr_dev->reg_base))
 		return PTR_ERR(hr_dev->reg_base);
 
+	/* get the RoCE associated ethernet ports or netdevices */
 	for (i = 0; i < HNS_ROCE_MAX_PORTS; i++) {
-		net_node = of_parse_phandle(np, "eth-handle", i);
-		if (net_node) {
+		if (dev_of_node(dev)) {
+			net_node = of_parse_phandle(dev->of_node, "eth-handle",
+						    i);
+			if (!net_node)
+				continue;
 			pdev = of_find_device_by_node(net_node);
+		} else if (is_acpi_device_node(dev->fwnode)) {
+			struct acpi_reference_args args;
+			struct fwnode_handle *fwnode;
+
+			ret = acpi_node_get_property_reference(dev->fwnode,
+							       "eth-handle",
+							       i, &args);
+			if (ret)
+				continue;
+			fwnode = acpi_fwnode_handle(args.adev);
+			pdev = hns_roce_find_pdev(fwnode);
+		} else {
+			dev_err(dev, "cannot read data from DT or ACPI\n");
+			return -ENXIO;
+		}
+
+		if (pdev) {
 			netdev = platform_get_drvdata(pdev);
 			phy_port = (u8)i;
 			if (netdev) {
 				hr_dev->iboe.netdevs[port_cnt] = netdev;
 				hr_dev->iboe.phy_port[port_cnt] = phy_port;
 			} else {
+				dev_err(dev, "no netdev found with pdev %s\n",
+					pdev->name);
 				return -ENODEV;
 			}
 			port_cnt++;
@@ -735,26 +817,32 @@ static int hns_roce_get_cfg(struct hns_roce_dev *hr_dev)
 	}
 
 	if (port_cnt == 0) {
-		dev_err(dev, "Unable to get available port by eth-handle!\n");
+		dev_err(dev, "unable to get eth-handle for available ports!\n");
 		return -EINVAL;
 	}
 
 	hr_dev->caps.num_ports = port_cnt;
 
-	/* Cmd issue mode: 0 is poll, 1 is event */
+	/* cmd issue mode: 0 is poll, 1 is event */
 	hr_dev->cmd_mod = 1;
 	hr_dev->loop_idc = 0;
 
+	/* read the interrupt names from the DT or ACPI */
+	ret = device_property_read_string_array(dev, "interrupt-names",
+						hr_dev->irq_names,
+						HNS_ROCE_MAX_IRQ_NUM);
+	if (ret < 0) {
+		dev_err(dev, "couldn't get interrupt names from DT or ACPI!\n");
+		return ret;
+	}
+
+	/* fetch the interrupt numbers */
 	for (i = 0; i < HNS_ROCE_MAX_IRQ_NUM; i++) {
 		hr_dev->irq[i] = platform_get_irq(hr_dev->pdev, i);
 		if (hr_dev->irq[i] <= 0) {
-			dev_err(dev, "Get No.%d irq resource failed!\n", i);
+			dev_err(dev, "platform get of irq[=%d] failed!\n", i);
 			return -EINVAL;
 		}
-
-		if (of_property_read_string_index(np, "interrupt-names", i,
-						  &hr_dev->irq_names))
-			return -EINVAL;
 	}
 
 	return 0;
@@ -917,7 +1005,7 @@ static int hns_roce_probe(struct platform_device *pdev)
 
 	if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64ULL)) &&
 	    dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32ULL))) {
-		dev_err(dev, "No usable DMA addressing mode\n");
+		dev_err(dev, "Not usable DMA addressing mode\n");
 		ret = -EIO;
 		goto error_failed_get_cfg;
 	}
@@ -1035,18 +1123,13 @@ static int hns_roce_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct of_device_id hns_roce_of_match[] = {
-	{ .compatible = "hisilicon,hns-roce-v1",},
-	{},
-};
-MODULE_DEVICE_TABLE(of, hns_roce_of_match);
-
 static struct platform_driver hns_roce_driver = {
 	.probe = hns_roce_probe,
 	.remove = hns_roce_remove,
 	.driver = {
 		.name = DRV_NAME,
 		.of_match_table = hns_roce_of_match,
+		.acpi_match_table = ACPI_PTR(hns_roce_acpi_match),
 	},
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 2/2] IB/hns: Add support of ACPI to the Hisilicon RoCE driver

[Salil Mehta]

This patch is meant to add support of ACPI to the Hisilicon RoCE
driver.

Changes done are primarily meant to detect the type and then either
use DT specific or ACPI spcific functions. Where ever possible,
this patch tries to make use of Unified Device Property Interface
APIs to support both DT and ACPI through single interface.

This patch depends upon HNS ethernet driver to Reset RoCE. This
function within HNS ethernet driver has also been enhanced to
support ACPI and is part of other accompanying patch with this
patch-set.

NOTE: The changes in this patch are done over below branch,
https://github.com/dledford/linux/tree/hns-roce

Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
Change Log

PATCH V1: Initial version to support ACPI in HNS RoCE driver.
---
 drivers/infiniband/hw/hns/hns_roce_device.h |    2 +-
 drivers/infiniband/hw/hns/hns_roce_eq.c     |    2 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c  |   37 ++++++--
 drivers/infiniband/hw/hns/hns_roce_hw_v1.h  |    2 +-
 drivers/infiniband/hw/hns/hns_roce_main.c   |  127 ++++++++++++++++++++++-----
 5 files changed, 136 insertions(+), 34 deletions(-)

diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h b/drivers/infiniband/hw/hns/hns_roce_device.h
index 00f01be..ea73580 100644
--- a/drivers/infiniband/hw/hns/hns_roce_device.h
+++ b/drivers/infiniband/hw/hns/hns_roce_device.h
@@ -531,7 +531,7 @@ struct hns_roce_dev {
 	struct ib_device	ib_dev;
 	struct platform_device  *pdev;
 	struct hns_roce_uar     priv_uar;
-	const char		*irq_names;
+	const char		*irq_names[HNS_ROCE_MAX_IRQ_NUM];
 	spinlock_t		sm_lock;
 	spinlock_t		cq_db_lock;
 	spinlock_t		bt_cmd_lock;
diff --git a/drivers/infiniband/hw/hns/hns_roce_eq.c b/drivers/infiniband/hw/hns/hns_roce_eq.c
index 5febbb4..98af7fe 100644
--- a/drivers/infiniband/hw/hns/hns_roce_eq.c
+++ b/drivers/infiniband/hw/hns/hns_roce_eq.c
@@ -713,7 +713,7 @@ int hns_roce_init_eq_table(struct hns_roce_dev *hr_dev)
 
 	for (j = 0; j < eq_num; j++) {
 		ret = request_irq(eq_table->eq[j].irq, hns_roce_msi_x_interrupt,
-				  0, hr_dev->irq_names, eq_table->eq + j);
+				  0, hr_dev->irq_names[j], eq_table->eq + j);
 		if (ret) {
 			dev_err(dev, "request irq error!\n");
 			goto err_request_irq_fail;
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
index b52f3ba..399f5de 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -31,6 +31,7 @@
  */
 
 #include <linux/platform_device.h>
+#include <linux/acpi.h>
 #include <rdma/ib_umem.h>
 #include "hns_roce_common.h"
 #include "hns_roce_device.h"
@@ -794,29 +795,47 @@ static void hns_roce_port_enable(struct hns_roce_dev *hr_dev, int enable_flag)
  * @enable: true -- drop reset, false -- reset
  * return 0 - success , negative --fail
  */
-int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool enable)
+int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool dereset)
 {
 	struct device_node *dsaf_node;
 	struct device *dev = &hr_dev->pdev->dev;
 	struct device_node *np = dev->of_node;
+	struct fwnode_handle *fwnode;
 	int ret;
 
-	dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
-	if (!dsaf_node) {
-		dev_err(dev, "Unable to get dsaf node by dsaf-handle!\n");
-		return -EINVAL;
+	/* check if this is DT/ACPI case */
+	if (dev_of_node(dev)) {
+		dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
+		if (!dsaf_node) {
+			dev_err(dev, "could not find dsaf-handle\n");
+			return -EINVAL;
+		}
+		fwnode = &dsaf_node->fwnode;
+	} else if (is_acpi_device_node(dev->fwnode)) {
+		struct acpi_reference_args args;
+
+		ret = acpi_node_get_property_reference(dev->fwnode,
+						       "dsaf-handle", 0, &args);
+		if (ret) {
+			dev_err(dev, "could not find dsaf-handle\n");
+			return ret;
+		}
+		fwnode = acpi_fwnode_handle(args.adev);
+	} else {
+		dev_err(dev, "cannot read data from DT or ACPI\n");
+		return -ENXIO;
 	}
 
-	ret = hns_dsaf_roce_reset(&dsaf_node->fwnode, false);
+	ret = hns_dsaf_roce_reset(fwnode, false);
 	if (ret)
 		return ret;
 
-	if (enable) {
+	if (dereset) {
 		msleep(SLEEP_TIME_INTERVAL);
-		return hns_dsaf_roce_reset(&dsaf_node->fwnode, true);
+		ret = hns_dsaf_roce_reset(fwnode, true);
 	}
 
-	return 0;
+	return ret;
 }
 
 void hns_roce_v1_profile(struct hns_roce_dev *hr_dev)
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.h b/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
index 2b3bf21..316b592 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
@@ -976,6 +976,6 @@ struct hns_roce_v1_priv {
 	struct hns_roce_raq_table raq_table;
 };
 
-int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool enable);
+int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset);
 
 #endif
diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c
index 6ead671..f64f0dd 100644
--- a/drivers/infiniband/hw/hns/hns_roce_main.c
+++ b/drivers/infiniband/hw/hns/hns_roce_main.c
@@ -30,7 +30,7 @@
  * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  * SOFTWARE.
  */
-
+#include <linux/acpi.h>
 #include <linux/of_platform.h>
 #include <rdma/ib_addr.h>
 #include <rdma/ib_smi.h>
@@ -694,40 +694,122 @@ error_failed_setup_mtu_gids:
 	return ret;
 }
 
+static const struct of_device_id hns_roce_of_match[] = {
+	{ .compatible = "hisilicon,hns-roce-v1", .data = &hns_roce_hw_v1, },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hns_roce_of_match);
+
+static const struct acpi_device_id hns_roce_acpi_match[] = {
+	{ "HISI00D1", (kernel_ulong_t)&hns_roce_hw_v1 },
+	{},
+};
+MODULE_DEVICE_TABLE(acpi, hns_roce_acpi_match);
+
+static int hns_roce_node_match(struct device *dev, void *fwnode)
+{
+	return dev->fwnode == fwnode;
+}
+
+static struct
+platform_device *hns_roce_find_pdev(struct fwnode_handle *fwnode)
+{
+	struct device *dev;
+
+	/* get the 'device'corresponding to matching 'fwnode' */
+	dev = bus_find_device(&platform_bus_type, NULL,
+			      fwnode, hns_roce_node_match);
+	/* get the platform device */
+	return dev ? to_platform_device(dev) : NULL;
+}
+
 static int hns_roce_get_cfg(struct hns_roce_dev *hr_dev)
 {
 	int i;
+	int ret;
 	u8 phy_port;
 	int port_cnt = 0;
 	struct device *dev = &hr_dev->pdev->dev;
-	struct device_node *np = dev->of_node;
 	struct device_node *net_node;
 	struct net_device *netdev = NULL;
 	struct platform_device *pdev = NULL;
 	struct resource *res;
 
-	if (of_device_is_compatible(np, "hisilicon,hns-roce-v1")) {
-		hr_dev->hw = &hns_roce_hw_v1;
+	/* check if we are compatible with the underlying SoC */
+	if (dev_of_node(dev)) {
+		const struct of_device_id *of_id;
+
+		of_id = of_match_node(hns_roce_of_match, dev->of_node);
+		if (!of_id) {
+			dev_err(dev, "device is not compatible!\n");
+			return -ENXIO;
+		}
+		hr_dev->hw = (struct hns_roce_hw *)of_id->data;
+		if (!hr_dev->hw) {
+			dev_err(dev, "couldn't get H/W specific DT data!\n");
+			return -ENXIO;
+		}
+	} else if (is_acpi_device_node(dev->fwnode)) {
+		const struct acpi_device_id *acpi_id;
+
+		acpi_id = acpi_match_device(hns_roce_acpi_match, dev);
+		if (!acpi_id) {
+			dev_err(dev, "device is not compatible!\n");
+			return -ENXIO;
+		}
+		hr_dev->hw = (struct hns_roce_hw *) acpi_id->driver_data;
+		if (!hr_dev->hw) {
+			dev_err(dev, "couldn't get H/W specific ACPI data!\n");
+			return -ENXIO;
+		}
 	} else {
-		dev_err(dev, "device no compatible!\n");
-		return -EINVAL;
+		dev_err(dev, "can't read compatibility data from DT or ACPI\n");
+		return -ENXIO;
 	}
 
+	/* get the mapped register base address */
 	res = platform_get_resource(hr_dev->pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "memory resource not found!\n");
+		return -EINVAL;
+	}
 	hr_dev->reg_base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(hr_dev->reg_base))
 		return PTR_ERR(hr_dev->reg_base);
 
+	/* get the RoCE associated ethernet ports or netdevices */
 	for (i = 0; i < HNS_ROCE_MAX_PORTS; i++) {
-		net_node = of_parse_phandle(np, "eth-handle", i);
-		if (net_node) {
+		if (dev_of_node(dev)) {
+			net_node = of_parse_phandle(dev->of_node, "eth-handle",
+						    i);
+			if (!net_node)
+				continue;
 			pdev = of_find_device_by_node(net_node);
+		} else if (is_acpi_device_node(dev->fwnode)) {
+			struct acpi_reference_args args;
+			struct fwnode_handle *fwnode;
+
+			ret = acpi_node_get_property_reference(dev->fwnode,
+							       "eth-handle",
+							       i, &args);
+			if (ret)
+				continue;
+			fwnode = acpi_fwnode_handle(args.adev);
+			pdev = hns_roce_find_pdev(fwnode);
+		} else {
+			dev_err(dev, "cannot read data from DT or ACPI\n");
+			return -ENXIO;
+		}
+
+		if (pdev) {
 			netdev = platform_get_drvdata(pdev);
 			phy_port = (u8)i;
 			if (netdev) {
 				hr_dev->iboe.netdevs[port_cnt] = netdev;
 				hr_dev->iboe.phy_port[port_cnt] = phy_port;
 			} else {
+				dev_err(dev, "no netdev found with pdev %s\n",
+					pdev->name);
 				return -ENODEV;
 			}
 			port_cnt++;
@@ -735,26 +817,32 @@ static int hns_roce_get_cfg(struct hns_roce_dev *hr_dev)
 	}
 
 	if (port_cnt == 0) {
-		dev_err(dev, "Unable to get available port by eth-handle!\n");
+		dev_err(dev, "unable to get eth-handle for available ports!\n");
 		return -EINVAL;
 	}
 
 	hr_dev->caps.num_ports = port_cnt;
 
-	/* Cmd issue mode: 0 is poll, 1 is event */
+	/* cmd issue mode: 0 is poll, 1 is event */
 	hr_dev->cmd_mod = 1;
 	hr_dev->loop_idc = 0;
 
+	/* read the interrupt names from the DT or ACPI */
+	ret = device_property_read_string_array(dev, "interrupt-names",
+						hr_dev->irq_names,
+						HNS_ROCE_MAX_IRQ_NUM);
+	if (ret < 0) {
+		dev_err(dev, "couldn't get interrupt names from DT or ACPI!\n");
+		return ret;
+	}
+
+	/* fetch the interrupt numbers */
 	for (i = 0; i < HNS_ROCE_MAX_IRQ_NUM; i++) {
 		hr_dev->irq[i] = platform_get_irq(hr_dev->pdev, i);
 		if (hr_dev->irq[i] <= 0) {
-			dev_err(dev, "Get No.%d irq resource failed!\n", i);
+			dev_err(dev, "platform get of irq[=%d] failed!\n", i);
 			return -EINVAL;
 		}
-
-		if (of_property_read_string_index(np, "interrupt-names", i,
-						  &hr_dev->irq_names))
-			return -EINVAL;
 	}
 
 	return 0;
@@ -917,7 +1005,7 @@ static int hns_roce_probe(struct platform_device *pdev)
 
 	if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64ULL)) &&
 	    dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32ULL))) {
-		dev_err(dev, "No usable DMA addressing mode\n");
+		dev_err(dev, "Not usable DMA addressing mode\n");
 		ret = -EIO;
 		goto error_failed_get_cfg;
 	}
@@ -1035,18 +1123,13 @@ static int hns_roce_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct of_device_id hns_roce_of_match[] = {
-	{ .compatible = "hisilicon,hns-roce-v1",},
-	{},
-};
-MODULE_DEVICE_TABLE(of, hns_roce_of_match);
-
 static struct platform_driver hns_roce_driver = {
 	.probe = hns_roce_probe,
 	.remove = hns_roce_remove,
 	.driver = {
 		.name = DRV_NAME,
 		.of_match_table = hns_roce_of_match,
+		.acpi_match_table = ACPI_PTR(hns_roce_acpi_match),
 	},
 };
 
-- 
1.7.9.5

[PATCH for-next 2/2] IB/hns: Add support of ACPI to the Hisilicon RoCE driver

[Salil Mehta]

This patch is meant to add support of ACPI to the Hisilicon RoCE
driver.

Changes done are primarily meant to detect the type and then either
use DT specific or ACPI spcific functions. Where ever possible,
this patch tries to make use of Unified Device Property Interface
APIs to support both DT and ACPI through single interface.

This patch depends upon HNS ethernet driver to Reset RoCE. This
function within HNS ethernet driver has also been enhanced to
support ACPI and is part of other accompanying patch with this
patch-set.

NOTE: The changes in this patch are done over below branch,
https://github.com/dledford/linux/tree/hns-roce

Signed-off-by: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
Change Log

PATCH V1: Initial version to support ACPI in HNS RoCE driver.
---
 drivers/infiniband/hw/hns/hns_roce_device.h |    2 +-
 drivers/infiniband/hw/hns/hns_roce_eq.c     |    2 +-
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c  |   37 ++++++--
 drivers/infiniband/hw/hns/hns_roce_hw_v1.h  |    2 +-
 drivers/infiniband/hw/hns/hns_roce_main.c   |  127 ++++++++++++++++++++++-----
 5 files changed, 136 insertions(+), 34 deletions(-)

diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h b/drivers/infiniband/hw/hns/hns_roce_device.h
index 00f01be..ea73580 100644
--- a/drivers/infiniband/hw/hns/hns_roce_device.h
+++ b/drivers/infiniband/hw/hns/hns_roce_device.h
@@ -531,7 +531,7 @@ struct hns_roce_dev {
 	struct ib_device	ib_dev;
 	struct platform_device  *pdev;
 	struct hns_roce_uar     priv_uar;
-	const char		*irq_names;
+	const char		*irq_names[HNS_ROCE_MAX_IRQ_NUM];
 	spinlock_t		sm_lock;
 	spinlock_t		cq_db_lock;
 	spinlock_t		bt_cmd_lock;
diff --git a/drivers/infiniband/hw/hns/hns_roce_eq.c b/drivers/infiniband/hw/hns/hns_roce_eq.c
index 5febbb4..98af7fe 100644
--- a/drivers/infiniband/hw/hns/hns_roce_eq.c
+++ b/drivers/infiniband/hw/hns/hns_roce_eq.c
@@ -713,7 +713,7 @@ int hns_roce_init_eq_table(struct hns_roce_dev *hr_dev)
 
 	for (j = 0; j < eq_num; j++) {
 		ret = request_irq(eq_table->eq[j].irq, hns_roce_msi_x_interrupt,
-				  0, hr_dev->irq_names, eq_table->eq + j);
+				  0, hr_dev->irq_names[j], eq_table->eq + j);
 		if (ret) {
 			dev_err(dev, "request irq error!\n");
 			goto err_request_irq_fail;
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
index b52f3ba..399f5de 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -31,6 +31,7 @@
  */
 
 #include <linux/platform_device.h>
+#include <linux/acpi.h>
 #include <rdma/ib_umem.h>
 #include "hns_roce_common.h"
 #include "hns_roce_device.h"
@@ -794,29 +795,47 @@ static void hns_roce_port_enable(struct hns_roce_dev *hr_dev, int enable_flag)
  * @enable: true -- drop reset, false -- reset
  * return 0 - success , negative --fail
  */
-int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool enable)
+int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool dereset)
 {
 	struct device_node *dsaf_node;
 	struct device *dev = &hr_dev->pdev->dev;
 	struct device_node *np = dev->of_node;
+	struct fwnode_handle *fwnode;
 	int ret;
 
-	dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
-	if (!dsaf_node) {
-		dev_err(dev, "Unable to get dsaf node by dsaf-handle!\n");
-		return -EINVAL;
+	/* check if this is DT/ACPI case */
+	if (dev_of_node(dev)) {
+		dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
+		if (!dsaf_node) {
+			dev_err(dev, "could not find dsaf-handle\n");
+			return -EINVAL;
+		}
+		fwnode = &dsaf_node->fwnode;
+	} else if (is_acpi_device_node(dev->fwnode)) {
+		struct acpi_reference_args args;
+
+		ret = acpi_node_get_property_reference(dev->fwnode,
+						       "dsaf-handle", 0, &args);
+		if (ret) {
+			dev_err(dev, "could not find dsaf-handle\n");
+			return ret;
+		}
+		fwnode = acpi_fwnode_handle(args.adev);
+	} else {
+		dev_err(dev, "cannot read data from DT or ACPI\n");
+		return -ENXIO;
 	}
 
-	ret = hns_dsaf_roce_reset(&dsaf_node->fwnode, false);
+	ret = hns_dsaf_roce_reset(fwnode, false);
 	if (ret)
 		return ret;
 
-	if (enable) {
+	if (dereset) {
 		msleep(SLEEP_TIME_INTERVAL);
-		return hns_dsaf_roce_reset(&dsaf_node->fwnode, true);
+		ret = hns_dsaf_roce_reset(fwnode, true);
 	}
 
-	return 0;
+	return ret;
 }
 
 void hns_roce_v1_profile(struct hns_roce_dev *hr_dev)
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.h b/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
index 2b3bf21..316b592 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
@@ -976,6 +976,6 @@ struct hns_roce_v1_priv {
 	struct hns_roce_raq_table raq_table;
 };
 
-int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool enable);
+int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset);
 
 #endif
diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c
index 6ead671..f64f0dd 100644
--- a/drivers/infiniband/hw/hns/hns_roce_main.c
+++ b/drivers/infiniband/hw/hns/hns_roce_main.c
@@ -30,7 +30,7 @@
  * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  * SOFTWARE.
  */
-
+#include <linux/acpi.h>
 #include <linux/of_platform.h>
 #include <rdma/ib_addr.h>
 #include <rdma/ib_smi.h>
@@ -694,40 +694,122 @@ error_failed_setup_mtu_gids:
 	return ret;
 }
 
+static const struct of_device_id hns_roce_of_match[] = {
+	{ .compatible = "hisilicon,hns-roce-v1", .data = &hns_roce_hw_v1, },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hns_roce_of_match);
+
+static const struct acpi_device_id hns_roce_acpi_match[] = {
+	{ "HISI00D1", (kernel_ulong_t)&hns_roce_hw_v1 },
+	{},
+};
+MODULE_DEVICE_TABLE(acpi, hns_roce_acpi_match);
+
+static int hns_roce_node_match(struct device *dev, void *fwnode)
+{
+	return dev->fwnode == fwnode;
+}
+
+static struct
+platform_device *hns_roce_find_pdev(struct fwnode_handle *fwnode)
+{
+	struct device *dev;
+
+	/* get the 'device'corresponding to matching 'fwnode' */
+	dev = bus_find_device(&platform_bus_type, NULL,
+			      fwnode, hns_roce_node_match);
+	/* get the platform device */
+	return dev ? to_platform_device(dev) : NULL;
+}
+
 static int hns_roce_get_cfg(struct hns_roce_dev *hr_dev)
 {
 	int i;
+	int ret;
 	u8 phy_port;
 	int port_cnt = 0;
 	struct device *dev = &hr_dev->pdev->dev;
-	struct device_node *np = dev->of_node;
 	struct device_node *net_node;
 	struct net_device *netdev = NULL;
 	struct platform_device *pdev = NULL;
 	struct resource *res;
 
-	if (of_device_is_compatible(np, "hisilicon,hns-roce-v1")) {
-		hr_dev->hw = &hns_roce_hw_v1;
+	/* check if we are compatible with the underlying SoC */
+	if (dev_of_node(dev)) {
+		const struct of_device_id *of_id;
+
+		of_id = of_match_node(hns_roce_of_match, dev->of_node);
+		if (!of_id) {
+			dev_err(dev, "device is not compatible!\n");
+			return -ENXIO;
+		}
+		hr_dev->hw = (struct hns_roce_hw *)of_id->data;
+		if (!hr_dev->hw) {
+			dev_err(dev, "couldn't get H/W specific DT data!\n");
+			return -ENXIO;
+		}
+	} else if (is_acpi_device_node(dev->fwnode)) {
+		const struct acpi_device_id *acpi_id;
+
+		acpi_id = acpi_match_device(hns_roce_acpi_match, dev);
+		if (!acpi_id) {
+			dev_err(dev, "device is not compatible!\n");
+			return -ENXIO;
+		}
+		hr_dev->hw = (struct hns_roce_hw *) acpi_id->driver_data;
+		if (!hr_dev->hw) {
+			dev_err(dev, "couldn't get H/W specific ACPI data!\n");
+			return -ENXIO;
+		}
 	} else {
-		dev_err(dev, "device no compatible!\n");
-		return -EINVAL;
+		dev_err(dev, "can't read compatibility data from DT or ACPI\n");
+		return -ENXIO;
 	}
 
+	/* get the mapped register base address */
 	res = platform_get_resource(hr_dev->pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "memory resource not found!\n");
+		return -EINVAL;
+	}
 	hr_dev->reg_base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(hr_dev->reg_base))
 		return PTR_ERR(hr_dev->reg_base);
 
+	/* get the RoCE associated ethernet ports or netdevices */
 	for (i = 0; i < HNS_ROCE_MAX_PORTS; i++) {
-		net_node = of_parse_phandle(np, "eth-handle", i);
-		if (net_node) {
+		if (dev_of_node(dev)) {
+			net_node = of_parse_phandle(dev->of_node, "eth-handle",
+						    i);
+			if (!net_node)
+				continue;
 			pdev = of_find_device_by_node(net_node);
+		} else if (is_acpi_device_node(dev->fwnode)) {
+			struct acpi_reference_args args;
+			struct fwnode_handle *fwnode;
+
+			ret = acpi_node_get_property_reference(dev->fwnode,
+							       "eth-handle",
+							       i, &args);
+			if (ret)
+				continue;
+			fwnode = acpi_fwnode_handle(args.adev);
+			pdev = hns_roce_find_pdev(fwnode);
+		} else {
+			dev_err(dev, "cannot read data from DT or ACPI\n");
+			return -ENXIO;
+		}
+
+		if (pdev) {
 			netdev = platform_get_drvdata(pdev);
 			phy_port = (u8)i;
 			if (netdev) {
 				hr_dev->iboe.netdevs[port_cnt] = netdev;
 				hr_dev->iboe.phy_port[port_cnt] = phy_port;
 			} else {
+				dev_err(dev, "no netdev found with pdev %s\n",
+					pdev->name);
 				return -ENODEV;
 			}
 			port_cnt++;
@@ -735,26 +817,32 @@ static int hns_roce_get_cfg(struct hns_roce_dev *hr_dev)
 	}
 
 	if (port_cnt == 0) {
-		dev_err(dev, "Unable to get available port by eth-handle!\n");
+		dev_err(dev, "unable to get eth-handle for available ports!\n");
 		return -EINVAL;
 	}
 
 	hr_dev->caps.num_ports = port_cnt;
 
-	/* Cmd issue mode: 0 is poll, 1 is event */
+	/* cmd issue mode: 0 is poll, 1 is event */
 	hr_dev->cmd_mod = 1;
 	hr_dev->loop_idc = 0;
 
+	/* read the interrupt names from the DT or ACPI */
+	ret = device_property_read_string_array(dev, "interrupt-names",
+						hr_dev->irq_names,
+						HNS_ROCE_MAX_IRQ_NUM);
+	if (ret < 0) {
+		dev_err(dev, "couldn't get interrupt names from DT or ACPI!\n");
+		return ret;
+	}
+
+	/* fetch the interrupt numbers */
 	for (i = 0; i < HNS_ROCE_MAX_IRQ_NUM; i++) {
 		hr_dev->irq[i] = platform_get_irq(hr_dev->pdev, i);
 		if (hr_dev->irq[i] <= 0) {
-			dev_err(dev, "Get No.%d irq resource failed!\n", i);
+			dev_err(dev, "platform get of irq[=%d] failed!\n", i);
 			return -EINVAL;
 		}
-
-		if (of_property_read_string_index(np, "interrupt-names", i,
-						  &hr_dev->irq_names))
-			return -EINVAL;
 	}
 
 	return 0;
@@ -917,7 +1005,7 @@ static int hns_roce_probe(struct platform_device *pdev)
 
 	if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64ULL)) &&
 	    dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32ULL))) {
-		dev_err(dev, "No usable DMA addressing mode\n");
+		dev_err(dev, "Not usable DMA addressing mode\n");
 		ret = -EIO;
 		goto error_failed_get_cfg;
 	}
@@ -1035,18 +1123,13 @@ static int hns_roce_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct of_device_id hns_roce_of_match[] = {
-	{ .compatible = "hisilicon,hns-roce-v1",},
-	{},
-};
-MODULE_DEVICE_TABLE(of, hns_roce_of_match);
-
 static struct platform_driver hns_roce_driver = {
 	.probe = hns_roce_probe,
 	.remove = hns_roce_remove,
 	.driver = {
 		.name = DRV_NAME,
 		.of_match_table = hns_roce_of_match,
+		.acpi_match_table = ACPI_PTR(hns_roce_acpi_match),
 	},
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 2/2] IB/hns: Add support of ACPI to the Hisilicon RoCE driver

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 6211 bytes --]

On Wed, Aug 24, 2016 at 04:44:50AM +0800, Salil Mehta wrote:
> This patch is meant to add support of ACPI to the Hisilicon RoCE
> driver.
>
> Changes done are primarily meant to detect the type and then either
> use DT specific or ACPI spcific functions. Where ever possible,
> this patch tries to make use of Unified Device Property Interface
> APIs to support both DT and ACPI through single interface.
>
> This patch depends upon HNS ethernet driver to Reset RoCE. This
> function within HNS ethernet driver has also been enhanced to
> support ACPI and is part of other accompanying patch with this
> patch-set.
>
> NOTE: The changes in this patch are done over below branch,
> https://github.com/dledford/linux/tree/hns-roce
>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> ---
> Change Log
>
> PATCH V1: Initial version to support ACPI in HNS RoCE driver.
> ---
>  drivers/infiniband/hw/hns/hns_roce_device.h |    2 +-
>  drivers/infiniband/hw/hns/hns_roce_eq.c     |    2 +-
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.c  |   37 ++++++--
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.h  |    2 +-
>  drivers/infiniband/hw/hns/hns_roce_main.c   |  127 ++++++++++++++++++++++-----
>  5 files changed, 136 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h b/drivers/infiniband/hw/hns/hns_roce_device.h
> index 00f01be..ea73580 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_device.h
> +++ b/drivers/infiniband/hw/hns/hns_roce_device.h
> @@ -531,7 +531,7 @@ struct hns_roce_dev {
>  	struct ib_device	ib_dev;
>  	struct platform_device  *pdev;
>  	struct hns_roce_uar     priv_uar;
> -	const char		*irq_names;
> +	const char		*irq_names[HNS_ROCE_MAX_IRQ_NUM];
>  	spinlock_t		sm_lock;
>  	spinlock_t		cq_db_lock;
>  	spinlock_t		bt_cmd_lock;
> diff --git a/drivers/infiniband/hw/hns/hns_roce_eq.c b/drivers/infiniband/hw/hns/hns_roce_eq.c
> index 5febbb4..98af7fe 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_eq.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_eq.c
> @@ -713,7 +713,7 @@ int hns_roce_init_eq_table(struct hns_roce_dev *hr_dev)
>
>  	for (j = 0; j < eq_num; j++) {
>  		ret = request_irq(eq_table->eq[j].irq, hns_roce_msi_x_interrupt,
> -				  0, hr_dev->irq_names, eq_table->eq + j);
> +				  0, hr_dev->irq_names[j], eq_table->eq + j);
>  		if (ret) {
>  			dev_err(dev, "request irq error!\n");
>  			goto err_request_irq_fail;
> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> index b52f3ba..399f5de 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> @@ -31,6 +31,7 @@
>   */
>
>  #include <linux/platform_device.h>
> +#include <linux/acpi.h>
>  #include <rdma/ib_umem.h>
>  #include "hns_roce_common.h"
>  #include "hns_roce_device.h"
> @@ -794,29 +795,47 @@ static void hns_roce_port_enable(struct hns_roce_dev *hr_dev, int enable_flag)
>   * @enable: true -- drop reset, false -- reset
>   * return 0 - success , negative --fail
>   */
> -int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool enable)
> +int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool dereset)
>  {
>  	struct device_node *dsaf_node;
>  	struct device *dev = &hr_dev->pdev->dev;
>  	struct device_node *np = dev->of_node;
> +	struct fwnode_handle *fwnode;
>  	int ret;
>
> -	dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
> -	if (!dsaf_node) {
> -		dev_err(dev, "Unable to get dsaf node by dsaf-handle!\n");
> -		return -EINVAL;
> +	/* check if this is DT/ACPI case */
> +	if (dev_of_node(dev)) {
> +		dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
> +		if (!dsaf_node) {
> +			dev_err(dev, "could not find dsaf-handle\n");
> +			return -EINVAL;
> +		}
> +		fwnode = &dsaf_node->fwnode;
> +	} else if (is_acpi_device_node(dev->fwnode)) {
> +		struct acpi_reference_args args;
> +
> +		ret = acpi_node_get_property_reference(dev->fwnode,
> +						       "dsaf-handle", 0, &args);
> +		if (ret) {
> +			dev_err(dev, "could not find dsaf-handle\n");
> +			return ret;
> +		}
> +		fwnode = acpi_fwnode_handle(args.adev);
> +	} else {
> +		dev_err(dev, "cannot read data from DT or ACPI\n");
> +		return -ENXIO;
>  	}
>
> -	ret = hns_dsaf_roce_reset(&dsaf_node->fwnode, false);
> +	ret = hns_dsaf_roce_reset(fwnode, false);
>  	if (ret)
>  		return ret;
>
> -	if (enable) {
> +	if (dereset) {
>  		msleep(SLEEP_TIME_INTERVAL);
> -		return hns_dsaf_roce_reset(&dsaf_node->fwnode, true);
> +		ret = hns_dsaf_roce_reset(fwnode, true);
>  	}
>
> -	return 0;
> +	return ret;
>  }
>
>  void hns_roce_v1_profile(struct hns_roce_dev *hr_dev)
> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.h b/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
> index 2b3bf21..316b592 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
> @@ -976,6 +976,6 @@ struct hns_roce_v1_priv {
>  	struct hns_roce_raq_table raq_table;
>  };
>
> -int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool enable);
> +int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset);
>
>  #endif
> diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c
> index 6ead671..f64f0dd 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_main.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_main.c
> @@ -30,7 +30,7 @@
>   * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
>   * SOFTWARE.
>   */
> -
> +#include <linux/acpi.h>
>  #include <linux/of_platform.h>
>  #include <rdma/ib_addr.h>
>  #include <rdma/ib_smi.h>
> @@ -694,40 +694,122 @@ error_failed_setup_mtu_gids:
>  	return ret;
>  }
>
> +static const struct of_device_id hns_roce_of_match[] = {
> +	{ .compatible = "hisilicon,hns-roce-v1", .data = &hns_roce_hw_v1, },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, hns_roce_of_match);
> +
> +static const struct acpi_device_id hns_roce_acpi_match[] = {
> +	{ "HISI00D1", (kernel_ulong_t)&hns_roce_hw_v1 },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(acpi, hns_roce_acpi_match);
> +
> +static int hns_roce_node_match(struct device *dev, void *fwnode)
> +{
> +	return dev->fwnode == fwnode;
> +}

It looks like this function should return bool and not int.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: [PATCH for-next 2/2] IB/hns: Add support of ACPI to the Hisilicon RoCE driver

[Salil Mehta]

> -----Original Message-----
> From: Leon Romanovsky [mailto:leon@kernel.org]
> Sent: Wednesday, August 24, 2016 2:59 PM
> To: Salil Mehta
> Cc: dledford@redhat.com; davem@davemloft.net; Huwei (Xavier); oulijun;
> Zhuangyuzeng (Yisen); mehta.salil.lnk@gmail.com; linux-
> rdma@vger.kernel.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 2/2] IB/hns: Add support of ACPI to the
> Hisilicon RoCE driver
> 
> On Wed, Aug 24, 2016 at 04:44:50AM +0800, Salil Mehta wrote:
> > This patch is meant to add support of ACPI to the Hisilicon RoCE
> > driver.
> >
> > Changes done are primarily meant to detect the type and then either
> > use DT specific or ACPI spcific functions. Where ever possible,
> > this patch tries to make use of Unified Device Property Interface
> > APIs to support both DT and ACPI through single interface.
> >
> > This patch depends upon HNS ethernet driver to Reset RoCE. This
> > function within HNS ethernet driver has also been enhanced to
> > support ACPI and is part of other accompanying patch with this
> > patch-set.
> >
> > NOTE: The changes in this patch are done over below branch,
> > https://github.com/dledford/linux/tree/hns-roce
> >
> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> > ---
> > Change Log
> >
> > PATCH V1: Initial version to support ACPI in HNS RoCE driver.
> > ---
> >  drivers/infiniband/hw/hns/hns_roce_device.h |    2 +-
> >  drivers/infiniband/hw/hns/hns_roce_eq.c     |    2 +-
> >  drivers/infiniband/hw/hns/hns_roce_hw_v1.c  |   37 ++++++--
> >  drivers/infiniband/hw/hns/hns_roce_hw_v1.h  |    2 +-
> >  drivers/infiniband/hw/hns/hns_roce_main.c   |  127
> ++++++++++++++++++++++-----
> >  5 files changed, 136 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h
> b/drivers/infiniband/hw/hns/hns_roce_device.h
> > index 00f01be..ea73580 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_device.h
> > +++ b/drivers/infiniband/hw/hns/hns_roce_device.h
> > @@ -531,7 +531,7 @@ struct hns_roce_dev {
> >  	struct ib_device	ib_dev;
> >  	struct platform_device  *pdev;
> >  	struct hns_roce_uar     priv_uar;
> > -	const char		*irq_names;
> > +	const char		*irq_names[HNS_ROCE_MAX_IRQ_NUM];
> >  	spinlock_t		sm_lock;
> >  	spinlock_t		cq_db_lock;
> >  	spinlock_t		bt_cmd_lock;
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_eq.c
> b/drivers/infiniband/hw/hns/hns_roce_eq.c
> > index 5febbb4..98af7fe 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_eq.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_eq.c
> > @@ -713,7 +713,7 @@ int hns_roce_init_eq_table(struct hns_roce_dev
> *hr_dev)
> >
> >  	for (j = 0; j < eq_num; j++) {
> >  		ret = request_irq(eq_table->eq[j].irq,
> hns_roce_msi_x_interrupt,
> > -				  0, hr_dev->irq_names, eq_table->eq + j);
> > +				  0, hr_dev->irq_names[j], eq_table->eq + j);
> >  		if (ret) {
> >  			dev_err(dev, "request irq error!\n");
> >  			goto err_request_irq_fail;
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> > index b52f3ba..399f5de 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> > @@ -31,6 +31,7 @@
> >   */
> >
> >  #include <linux/platform_device.h>
> > +#include <linux/acpi.h>
> >  #include <rdma/ib_umem.h>
> >  #include "hns_roce_common.h"
> >  #include "hns_roce_device.h"
> > @@ -794,29 +795,47 @@ static void hns_roce_port_enable(struct
> hns_roce_dev *hr_dev, int enable_flag)
> >   * @enable: true -- drop reset, false -- reset
> >   * return 0 - success , negative --fail
> >   */
> > -int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool enable)
> > +int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool dereset)
> >  {
> >  	struct device_node *dsaf_node;
> >  	struct device *dev = &hr_dev->pdev->dev;
> >  	struct device_node *np = dev->of_node;
> > +	struct fwnode_handle *fwnode;
> >  	int ret;
> >
> > -	dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
> > -	if (!dsaf_node) {
> > -		dev_err(dev, "Unable to get dsaf node by dsaf-handle!\n");
> > -		return -EINVAL;
> > +	/* check if this is DT/ACPI case */
> > +	if (dev_of_node(dev)) {
> > +		dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
> > +		if (!dsaf_node) {
> > +			dev_err(dev, "could not find dsaf-handle\n");
> > +			return -EINVAL;
> > +		}
> > +		fwnode = &dsaf_node->fwnode;
> > +	} else if (is_acpi_device_node(dev->fwnode)) {
> > +		struct acpi_reference_args args;
> > +
> > +		ret = acpi_node_get_property_reference(dev->fwnode,
> > +						       "dsaf-handle", 0, &args);
> > +		if (ret) {
> > +			dev_err(dev, "could not find dsaf-handle\n");
> > +			return ret;
> > +		}
> > +		fwnode = acpi_fwnode_handle(args.adev);
> > +	} else {
> > +		dev_err(dev, "cannot read data from DT or ACPI\n");
> > +		return -ENXIO;
> >  	}
> >
> > -	ret = hns_dsaf_roce_reset(&dsaf_node->fwnode, false);
> > +	ret = hns_dsaf_roce_reset(fwnode, false);
> >  	if (ret)
> >  		return ret;
> >
> > -	if (enable) {
> > +	if (dereset) {
> >  		msleep(SLEEP_TIME_INTERVAL);
> > -		return hns_dsaf_roce_reset(&dsaf_node->fwnode, true);
> > +		ret = hns_dsaf_roce_reset(fwnode, true);
> >  	}
> >
> > -	return 0;
> > +	return ret;
> >  }
> >
> >  void hns_roce_v1_profile(struct hns_roce_dev *hr_dev)
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
> b/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
> > index 2b3bf21..316b592 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
> > +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.h
> > @@ -976,6 +976,6 @@ struct hns_roce_v1_priv {
> >  	struct hns_roce_raq_table raq_table;
> >  };
> >
> > -int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool
> enable);
> > +int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool
> dereset);
> >
> >  #endif
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c
> b/drivers/infiniband/hw/hns/hns_roce_main.c
> > index 6ead671..f64f0dd 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_main.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_main.c
> > @@ -30,7 +30,7 @@
> >   * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> >   * SOFTWARE.
> >   */
> > -
> > +#include <linux/acpi.h>
> >  #include <linux/of_platform.h>
> >  #include <rdma/ib_addr.h>
> >  #include <rdma/ib_smi.h>
> > @@ -694,40 +694,122 @@ error_failed_setup_mtu_gids:
> >  	return ret;
> >  }
> >
> > +static const struct of_device_id hns_roce_of_match[] = {
> > +	{ .compatible = "hisilicon,hns-roce-v1", .data = &hns_roce_hw_v1,
> },
> > +	{},
> > +};
> > +MODULE_DEVICE_TABLE(of, hns_roce_of_match);
> > +
> > +static const struct acpi_device_id hns_roce_acpi_match[] = {
> > +	{ "HISI00D1", (kernel_ulong_t)&hns_roce_hw_v1 },
> > +	{},
> > +};
> > +MODULE_DEVICE_TABLE(acpi, hns_roce_acpi_match);
> > +
> > +static int hns_roce_node_match(struct device *dev, void *fwnode)
> > +{
> > +	return dev->fwnode == fwnode;
> > +}
> 
> It looks like this function should return bool and not int.

Hi Leon,
Thanks for reviewing. Yes, I think bool would have been much
better as a return value but if you see the prototype of the
"match" function in bus_find_device(), it returns int:

struct device *bus_find_device(struct bus_type *bus,
			       struct device *start, void *data,
			       int (*match)(struct device *dev, void *data))
{
	struct klist_iter i;
      ..........................
      ..........................
}

I also verified this in few other example code legs where it is being
used, like:

File: platform.c
static int of_dev_node_match(struct device *dev, void *data)
{
	return dev->of_node == data;
}

being used in below function 

struct platform_device *of_find_device_by_node(struct device_node *np)
{
	struct device *dev;

	dev = bus_find_device(&platform_bus_type, NULL, np, of_dev_node_match);
	return dev ? to_platform_device(dev) : NULL;
}


It looks like we should retain the int as a return type or if you have
some other opinion or if I have missed something here please share :)

Best regards
Salil

Re: [PATCH for-next 2/2] IB/hns: Add support of ACPI to the Hisilicon RoCE driver

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

On Wed, Aug 24, 2016 at 02:25:12PM +0000, Salil Mehta wrote:
>
> It looks like we should retain the int as a return type or if you have
> some other opinion or if I have missed something here please share :)

Thanks for the explanation.

>
> Best regards
> Salil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH for-next 2/2] IB/hns: Add support of ACPI to the Hisilicon RoCE driver

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

On Wed, Aug 24, 2016 at 02:25:12PM +0000, Salil Mehta wrote:
>
> It looks like we should retain the int as a return type or if you have
> some other opinion or if I have missed something here please share :)

Thanks for the explanation.

>
> Best regards
> Salil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[David Miller]

From: Salil Mehta <salil.mehta@huawei.com>
Date: Wed, 24 Aug 2016 04:44:48 +0800

> This patch is meant to add support of ACPI to the Hisilicon RoCE driver.
> Following changes have been made in the driver(s):
> 
> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been done in
>    the RoCE reset function part of the HNS ethernet driver. Earlier it only
>    supported DT/syscon.
> 
> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to detect
>    the type and then either use DT specific or ACPI spcific functions. Where
>    ever possible, this patch tries to make use of "Unified Device Property
>    Interface" APIs to support both DT and ACPI through single interface.
> 
> NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI Table
>      (DSDT and IORT tables) changes part of UEFI/BIOS. These changes are NOT
>      part of this patch-set.
> NOTE 2: Reset function in Patch 1/2 depends upon the reset function added in
>      ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again, this
>      change is NOT reflected in this patch-set.

I can't apply this series to my tree because the hns infiniband driver
doesn't exist in it.

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 1513 bytes --]

On 8/25/2016 12:53 AM, David Miller wrote:
> From: Salil Mehta <salil.mehta@huawei.com>
> Date: Wed, 24 Aug 2016 04:44:48 +0800
> 
>> This patch is meant to add support of ACPI to the Hisilicon RoCE driver.
>> Following changes have been made in the driver(s):
>>
>> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been done in
>>    the RoCE reset function part of the HNS ethernet driver. Earlier it only
>>    supported DT/syscon.
>>
>> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to detect
>>    the type and then either use DT specific or ACPI spcific functions. Where
>>    ever possible, this patch tries to make use of "Unified Device Property
>>    Interface" APIs to support both DT and ACPI through single interface.
>>
>> NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI Table
>>      (DSDT and IORT tables) changes part of UEFI/BIOS. These changes are NOT
>>      part of this patch-set.
>> NOTE 2: Reset function in Patch 1/2 depends upon the reset function added in
>>      ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again, this
>>      change is NOT reflected in this patch-set.
> 
> I can't apply this series to my tree because the hns infiniband driver
> doesn't exist in it.
> 

No.  This probably needs to go through my tree.  Although with all of
the requirements, I'm a bit concerned about those being present elsewhere.

-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

RE: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

> -----Original Message-----
> From: David Miller [mailto:davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org]
> Sent: Thursday, August 25, 2016 5:54 AM
> To: Salil Mehta
> Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm
> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
> the Hisilicon RoCE Driver
> 
> From: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Date: Wed, 24 Aug 2016 04:44:48 +0800
> 
> > This patch is meant to add support of ACPI to the Hisilicon RoCE
> driver.
> > Following changes have been made in the driver(s):
> >
> > Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
> done in
> >    the RoCE reset function part of the HNS ethernet driver. Earlier
> it only
> >    supported DT/syscon.
> >
> > Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to
> detect
> >    the type and then either use DT specific or ACPI spcific
> functions. Where
> >    ever possible, this patch tries to make use of "Unified Device
> Property
> >    Interface" APIs to support both DT and ACPI through single
> interface.
> >
> > NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI
> Table
> >      (DSDT and IORT tables) changes part of UEFI/BIOS. These changes
> are NOT
> >      part of this patch-set.
> > NOTE 2: Reset function in Patch 1/2 depends upon the reset function
> added in
> >      ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,
> this
> >      change is NOT reflected in this patch-set.
> 
> I can't apply this series to my tree because the hns infiniband driver
> doesn't exist in it.
Hi David,
I understand your point. This patch-set was primarily sent for Doug Ledford
and is based on his internal repository (which has been rebased on the
net-next). 

Though we were hoping, if by any chance, we can expedite the acceptance of the
below patch part of patch-set in the net-next. This might help Doug Ledford as
well later on when he pushes the already accepted RoCE driver and ACPI patches
to linux-next,

"[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver RoCE Reset
 function"

Below HNS RoCE reset function patch has already been accepted and is part of your
net-next,
https://patchwork.kernel.org/patch/9287497/

Above ACPI support of RoCE Reset patch cleanly applies over the already accepted
patch in the link. It is not dependent on other accompanying RoCE driver ACPI
changes related patch or even the presence of the Infiniband/RoCE Driver in the
net-next repository.

Could you please suggest anything here?  

Thanks 
Salil

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, August 25, 2016 5:54 AM
> To: Salil Mehta
> Cc: dledford@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
> the Hisilicon RoCE Driver
> 
> From: Salil Mehta <salil.mehta@huawei.com>
> Date: Wed, 24 Aug 2016 04:44:48 +0800
> 
> > This patch is meant to add support of ACPI to the Hisilicon RoCE
> driver.
> > Following changes have been made in the driver(s):
> >
> > Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
> done in
> >    the RoCE reset function part of the HNS ethernet driver. Earlier
> it only
> >    supported DT/syscon.
> >
> > Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to
> detect
> >    the type and then either use DT specific or ACPI spcific
> functions. Where
> >    ever possible, this patch tries to make use of "Unified Device
> Property
> >    Interface" APIs to support both DT and ACPI through single
> interface.
> >
> > NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI
> Table
> >      (DSDT and IORT tables) changes part of UEFI/BIOS. These changes
> are NOT
> >      part of this patch-set.
> > NOTE 2: Reset function in Patch 1/2 depends upon the reset function
> added in
> >      ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,
> this
> >      change is NOT reflected in this patch-set.
> 
> I can't apply this series to my tree because the hns infiniband driver
> doesn't exist in it.
Hi David,
I understand your point. This patch-set was primarily sent for Doug Ledford
and is based on his internal repository (which has been rebased on the
net-next). 

Though we were hoping, if by any chance, we can expedite the acceptance of the
below patch part of patch-set in the net-next. This might help Doug Ledford as
well later on when he pushes the already accepted RoCE driver and ACPI patches
to linux-next,

"[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver RoCE Reset
 function"

Below HNS RoCE reset function patch has already been accepted and is part of your
net-next,
https://patchwork.kernel.org/patch/9287497/

Above ACPI support of RoCE Reset patch cleanly applies over the already accepted
patch in the link. It is not dependent on other accompanying RoCE driver ACPI
changes related patch or even the presence of the Infiniband/RoCE Driver in the
net-next repository.

Could you please suggest anything here?  

Thanks 
Salil

RE: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

> -----Original Message-----
> From: Doug Ledford [mailto:dledford@redhat.com]
> Sent: Thursday, August 25, 2016 12:57 PM
> To: David Miller; Salil Mehta
> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
> the Hisilicon RoCE Driver
> 
> On 8/25/2016 12:53 AM, David Miller wrote:
> > From: Salil Mehta <salil.mehta@huawei.com>
> > Date: Wed, 24 Aug 2016 04:44:48 +0800
> >
> >> This patch is meant to add support of ACPI to the Hisilicon RoCE
> driver.
> >> Following changes have been made in the driver(s):
> >>
> >> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
> done in
> >>    the RoCE reset function part of the HNS ethernet driver. Earlier
> it only
> >>    supported DT/syscon.
> >>
> >> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to
> detect
> >>    the type and then either use DT specific or ACPI spcific
> functions. Where
> >>    ever possible, this patch tries to make use of "Unified Device
> Property
> >>    Interface" APIs to support both DT and ACPI through single
> interface.
> >>
> >> NOTE 1: ACPI changes done in both of the drivers depend upon the
> ACPI Table
> >>      (DSDT and IORT tables) changes part of UEFI/BIOS. These changes
> are NOT
> >>      part of this patch-set.
> >> NOTE 2: Reset function in Patch 1/2 depends upon the reset function
> added in
> >>      ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,
> this
> >>      change is NOT reflected in this patch-set.
> >
> > I can't apply this series to my tree because the hns infiniband
> driver
> > doesn't exist in it.
> >
> 
> No.  This probably needs to go through my tree.  Although with all of
> the requirements, I'm a bit concerned about those being present
> elsewhere.
> 
> --
> Doug Ledford <dledford@redhat.com>
>     GPG Key ID: 0E572FDD
Hello Doug,
Thanks for your reply. I have just replied to David email as well and did
not realize your response was already on the way. Sorry for this!

I would just like to request, if by any chance, we can expedite the acceptance
of the below patch (part of patch-set) in the net-next. This might help you as
well in future when you will actually push the RoCE driver to the linux-next.

"[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver RoCE Reset
 function"

Below HNS RoCE reset function patch has already been accepted by Dave Miller and
is part of net-next,
https://patchwork.kernel.org/patch/9287497/

Also, above ACPI support of RoCE Reset patch cleanly applies over the already
accepted patch in the link and is not dependent on other accompanying RoCE
driver ACPI changes or even the presence of the Infiniband/RoCE Driver in the
net-next repository.

Could you please suggest if this the something which can be considered?   

Thanks in anticipation
Salil Mehta

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 3575 bytes --]

On 8/25/2016 8:00 AM, Salil Mehta wrote:
> 
> 
>> -----Original Message-----
>> From: David Miller [mailto:davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org]
>> Sent: Thursday, August 25, 2016 5:54 AM
>> To: Salil Mehta
>> Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
>> mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
>> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm
>> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
>> the Hisilicon RoCE Driver
>>
>> From: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> Date: Wed, 24 Aug 2016 04:44:48 +0800
>>
>>> This patch is meant to add support of ACPI to the Hisilicon RoCE
>> driver.
>>> Following changes have been made in the driver(s):
>>>
>>> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
>> done in
>>>    the RoCE reset function part of the HNS ethernet driver. Earlier
>> it only
>>>    supported DT/syscon.
>>>
>>> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to
>> detect
>>>    the type and then either use DT specific or ACPI spcific
>> functions. Where
>>>    ever possible, this patch tries to make use of "Unified Device
>> Property
>>>    Interface" APIs to support both DT and ACPI through single
>> interface.
>>>
>>> NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI
>> Table
>>>      (DSDT and IORT tables) changes part of UEFI/BIOS. These changes
>> are NOT
>>>      part of this patch-set.
>>> NOTE 2: Reset function in Patch 1/2 depends upon the reset function
>> added in
>>>      ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,
>> this
>>>      change is NOT reflected in this patch-set.
>>
>> I can't apply this series to my tree because the hns infiniband driver
>> doesn't exist in it.
> Hi David,
> I understand your point. This patch-set was primarily sent for Doug Ledford
> and is based on his internal repository (which has been rebased on the
> net-next). 
> 
> Though we were hoping, if by any chance, we can expedite the acceptance of the
> below patch part of patch-set in the net-next. This might help Doug Ledford as
> well later on when he pushes the already accepted RoCE driver and ACPI patches
> to linux-next,
> 
> "[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver RoCE Reset
>  function"
> 
> Below HNS RoCE reset function patch has already been accepted and is part of your
> net-next,
> https://patchwork.kernel.org/patch/9287497/
> 
> Above ACPI support of RoCE Reset patch cleanly applies over the already accepted
> patch in the link. It is not dependent on other accompanying RoCE driver ACPI
> changes related patch or even the presence of the Infiniband/RoCE Driver in the
> net-next repository.
> 
> Could you please suggest anything here?  
> 
> Thanks 
> Salil
> 

I can take both.  I already pulled net-next to get the initial hns roce
reset patch from Dave, so these will apply cleanly with my tree and
merge cleanly with Dave's due to the common ancestral base.  The only
problem is that if you intend to send any other patches that effect this
code, then they would need to come through me until the 4.9 merge window
is complete so that we don't have later merge conflicts.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 3360 bytes --]

On 8/25/2016 8:00 AM, Salil Mehta wrote:
> 
> 
>> -----Original Message-----
>> From: David Miller [mailto:davem@davemloft.net]
>> Sent: Thursday, August 25, 2016 5:54 AM
>> To: Salil Mehta
>> Cc: dledford@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
>> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
>> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
>> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
>> the Hisilicon RoCE Driver
>>
>> From: Salil Mehta <salil.mehta@huawei.com>
>> Date: Wed, 24 Aug 2016 04:44:48 +0800
>>
>>> This patch is meant to add support of ACPI to the Hisilicon RoCE
>> driver.
>>> Following changes have been made in the driver(s):
>>>
>>> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
>> done in
>>>    the RoCE reset function part of the HNS ethernet driver. Earlier
>> it only
>>>    supported DT/syscon.
>>>
>>> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to
>> detect
>>>    the type and then either use DT specific or ACPI spcific
>> functions. Where
>>>    ever possible, this patch tries to make use of "Unified Device
>> Property
>>>    Interface" APIs to support both DT and ACPI through single
>> interface.
>>>
>>> NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI
>> Table
>>>      (DSDT and IORT tables) changes part of UEFI/BIOS. These changes
>> are NOT
>>>      part of this patch-set.
>>> NOTE 2: Reset function in Patch 1/2 depends upon the reset function
>> added in
>>>      ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,
>> this
>>>      change is NOT reflected in this patch-set.
>>
>> I can't apply this series to my tree because the hns infiniband driver
>> doesn't exist in it.
> Hi David,
> I understand your point. This patch-set was primarily sent for Doug Ledford
> and is based on his internal repository (which has been rebased on the
> net-next). 
> 
> Though we were hoping, if by any chance, we can expedite the acceptance of the
> below patch part of patch-set in the net-next. This might help Doug Ledford as
> well later on when he pushes the already accepted RoCE driver and ACPI patches
> to linux-next,
> 
> "[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver RoCE Reset
>  function"
> 
> Below HNS RoCE reset function patch has already been accepted and is part of your
> net-next,
> https://patchwork.kernel.org/patch/9287497/
> 
> Above ACPI support of RoCE Reset patch cleanly applies over the already accepted
> patch in the link. It is not dependent on other accompanying RoCE driver ACPI
> changes related patch or even the presence of the Infiniband/RoCE Driver in the
> net-next repository.
> 
> Could you please suggest anything here?  
> 
> Thanks 
> Salil
> 

I can take both.  I already pulled net-next to get the initial hns roce
reset patch from Dave, so these will apply cleanly with my tree and
merge cleanly with Dave's due to the common ancestral base.  The only
problem is that if you intend to send any other patches that effect this
code, then they would need to come through me until the 4.9 merge window
is complete so that we don't have later merge conflicts.

-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 3417 bytes --]

On 8/25/2016 8:08 AM, Salil Mehta wrote:
> 
> 
>> -----Original Message-----
>> From: Doug Ledford [mailto:dledford@redhat.com]
>> Sent: Thursday, August 25, 2016 12:57 PM
>> To: David Miller; Salil Mehta
>> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
>> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
>> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
>> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
>> the Hisilicon RoCE Driver
>>
>> On 8/25/2016 12:53 AM, David Miller wrote:
>>> From: Salil Mehta <salil.mehta@huawei.com>
>>> Date: Wed, 24 Aug 2016 04:44:48 +0800
>>>
>>>> This patch is meant to add support of ACPI to the Hisilicon RoCE
>> driver.
>>>> Following changes have been made in the driver(s):
>>>>
>>>> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
>> done in
>>>>    the RoCE reset function part of the HNS ethernet driver. Earlier
>> it only
>>>>    supported DT/syscon.
>>>>
>>>> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to
>> detect
>>>>    the type and then either use DT specific or ACPI spcific
>> functions. Where
>>>>    ever possible, this patch tries to make use of "Unified Device
>> Property
>>>>    Interface" APIs to support both DT and ACPI through single
>> interface.
>>>>
>>>> NOTE 1: ACPI changes done in both of the drivers depend upon the
>> ACPI Table
>>>>      (DSDT and IORT tables) changes part of UEFI/BIOS. These changes
>> are NOT
>>>>      part of this patch-set.
>>>> NOTE 2: Reset function in Patch 1/2 depends upon the reset function
>> added in
>>>>      ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,
>> this
>>>>      change is NOT reflected in this patch-set.
>>>
>>> I can't apply this series to my tree because the hns infiniband
>> driver
>>> doesn't exist in it.
>>>
>>
>> No.  This probably needs to go through my tree.  Although with all of
>> the requirements, I'm a bit concerned about those being present
>> elsewhere.
>>
>> --
>> Doug Ledford <dledford@redhat.com>
>>     GPG Key ID: 0E572FDD
> Hello Doug,
> Thanks for your reply. I have just replied to David email as well and did
> not realize your response was already on the way. Sorry for this!
> 
> I would just like to request, if by any chance, we can expedite the acceptance
> of the below patch (part of patch-set) in the net-next. This might help you as
> well in future when you will actually push the RoCE driver to the linux-next.
> 
> "[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver RoCE Reset
>  function"
> 
> Below HNS RoCE reset function patch has already been accepted by Dave Miller and
> is part of net-next,
> https://patchwork.kernel.org/patch/9287497/
> 
> Also, above ACPI support of RoCE Reset patch cleanly applies over the already
> accepted patch in the link and is not dependent on other accompanying RoCE
> driver ACPI changes or even the presence of the Infiniband/RoCE Driver in the
> net-next repository.
> 
> Could you please suggest if this the something which can be considered?   

I've pulled both of these patches in.  I usually merge late in the merge
window, so it won't be any stretch to wait until the ACPI tree has been
merged before I send Linus my pull request.


-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

RE: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

> -----Original Message-----
> From: Doug Ledford [mailto:dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org]
> Sent: Thursday, August 25, 2016 2:53 PM
> To: Salil Mehta; David Miller
> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm
> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
> the Hisilicon RoCE Driver
> 
> On 8/25/2016 8:00 AM, Salil Mehta wrote:
> >
> >
> >> -----Original Message-----
> >> From: David Miller [mailto:davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org]
> >> Sent: Thursday, August 25, 2016 5:54 AM
> >> To: Salil Mehta
> >> Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; Huwei (Xavier); oulijun; Zhuangyuzeng
> (Yisen);
> >> mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> >> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm
> >> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI
> to
> >> the Hisilicon RoCE Driver
> >>
> >> From: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >> Date: Wed, 24 Aug 2016 04:44:48 +0800
> >>
> >>> This patch is meant to add support of ACPI to the Hisilicon RoCE
> >> driver.
> >>> Following changes have been made in the driver(s):
> >>>
> >>> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
> >> done in
> >>>    the RoCE reset function part of the HNS ethernet driver. Earlier
> >> it only
> >>>    supported DT/syscon.
> >>>
> >>> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant
> to
> >> detect
> >>>    the type and then either use DT specific or ACPI spcific
> >> functions. Where
> >>>    ever possible, this patch tries to make use of "Unified Device
> >> Property
> >>>    Interface" APIs to support both DT and ACPI through single
> >> interface.
> >>>
> >>> NOTE 1: ACPI changes done in both of the drivers depend upon the
> ACPI
> >> Table
> >>>      (DSDT and IORT tables) changes part of UEFI/BIOS. These
> changes
> >> are NOT
> >>>      part of this patch-set.
> >>> NOTE 2: Reset function in Patch 1/2 depends upon the reset function
> >> added in
> >>>      ACPI tables(basically DSDT table) part of the UEFI/BIOS.
> Again,
> >> this
> >>>      change is NOT reflected in this patch-set.
> >>
> >> I can't apply this series to my tree because the hns infiniband
> driver
> >> doesn't exist in it.
> > Hi David,
> > I understand your point. This patch-set was primarily sent for Doug
> Ledford
> > and is based on his internal repository (which has been rebased on
> the
> > net-next).
> >
> > Though we were hoping, if by any chance, we can expedite the
> acceptance of the
> > below patch part of patch-set in the net-next. This might help Doug
> Ledford as
> > well later on when he pushes the already accepted RoCE driver and
> ACPI patches
> > to linux-next,
> >
> > "[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver
> RoCE Reset
> >  function"
> >
> > Below HNS RoCE reset function patch has already been accepted and is
> part of your
> > net-next,
> > https://patchwork.kernel.org/patch/9287497/
> >
> > Above ACPI support of RoCE Reset patch cleanly applies over the
> already accepted
> > patch in the link. It is not dependent on other accompanying RoCE
> driver ACPI
> > changes related patch or even the presence of the Infiniband/RoCE
> Driver in the
> > net-next repository.
> >
> > Could you please suggest anything here?
> >
> > Thanks
> > Salil
> >
> 
> I can take both.  I already pulled net-next to get the initial hns roce
> reset patch from Dave, so these will apply cleanly with my tree and
> merge cleanly with Dave's due to the common ancestral base.  The only
> problem is that if you intend to send any other patches that effect
> this
> code, then they would need to come through me until the 4.9 merge
> window
> is complete so that we don't have later merge conflicts.
Ok sure, I got your point. Yes, there are few patches we need to push in
but are related to RoCE CM(Connection Manager) mode and would follow
soon. There are no further patches we foresee which are for RoCE Driver but are
dependent upon HNS Ethernet driver. 

But kindly note, there could be some patches in development in HNS Ethernet driver
which might sneak in through net-next. These might not be related to RoCE Driver but
might have some common files which might lead to conflict again further down
the line when you try to merge ACPI RoCE reset again. This HNS driver change
is very difficult for us to control since amount of development going on in HNS
is of much higher magnitude than the RoCE as of now. It will be almost impossible
for us to convince internally and shift that entire development being done right
now on net-next and rebase it to your internal hns-roce branch for a month of time
till 4.9. This will affect many features deadlines internally. 

So, if I understood you correctly, this delta (which could be large), when next merge
window open would be taken care by you. And we can expect below to be part of 4.9
1) RoCE Base driver (*Already Accepted*)
2) ACPI changes for RoCE Driver (*if accepted*)
   * ACPI changes for the RoCE Driver
   * ACPI changes for RoCE reset function part of the HNS driver

Please correct my understanding if I am wrong here.

Thanks, again!
Salil Mehta
> 
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG Key ID: 0E572FDD

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

> -----Original Message-----
> From: Doug Ledford [mailto:dledford@redhat.com]
> Sent: Thursday, August 25, 2016 2:53 PM
> To: Salil Mehta; David Miller
> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
> the Hisilicon RoCE Driver
> 
> On 8/25/2016 8:00 AM, Salil Mehta wrote:
> >
> >
> >> -----Original Message-----
> >> From: David Miller [mailto:davem@davemloft.net]
> >> Sent: Thursday, August 25, 2016 5:54 AM
> >> To: Salil Mehta
> >> Cc: dledford@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng
> (Yisen);
> >> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
> >> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> >> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI
> to
> >> the Hisilicon RoCE Driver
> >>
> >> From: Salil Mehta <salil.mehta@huawei.com>
> >> Date: Wed, 24 Aug 2016 04:44:48 +0800
> >>
> >>> This patch is meant to add support of ACPI to the Hisilicon RoCE
> >> driver.
> >>> Following changes have been made in the driver(s):
> >>>
> >>> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
> >> done in
> >>>    the RoCE reset function part of the HNS ethernet driver. Earlier
> >> it only
> >>>    supported DT/syscon.
> >>>
> >>> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant
> to
> >> detect
> >>>    the type and then either use DT specific or ACPI spcific
> >> functions. Where
> >>>    ever possible, this patch tries to make use of "Unified Device
> >> Property
> >>>    Interface" APIs to support both DT and ACPI through single
> >> interface.
> >>>
> >>> NOTE 1: ACPI changes done in both of the drivers depend upon the
> ACPI
> >> Table
> >>>      (DSDT and IORT tables) changes part of UEFI/BIOS. These
> changes
> >> are NOT
> >>>      part of this patch-set.
> >>> NOTE 2: Reset function in Patch 1/2 depends upon the reset function
> >> added in
> >>>      ACPI tables(basically DSDT table) part of the UEFI/BIOS.
> Again,
> >> this
> >>>      change is NOT reflected in this patch-set.
> >>
> >> I can't apply this series to my tree because the hns infiniband
> driver
> >> doesn't exist in it.
> > Hi David,
> > I understand your point. This patch-set was primarily sent for Doug
> Ledford
> > and is based on his internal repository (which has been rebased on
> the
> > net-next).
> >
> > Though we were hoping, if by any chance, we can expedite the
> acceptance of the
> > below patch part of patch-set in the net-next. This might help Doug
> Ledford as
> > well later on when he pushes the already accepted RoCE driver and
> ACPI patches
> > to linux-next,
> >
> > "[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver
> RoCE Reset
> >  function"
> >
> > Below HNS RoCE reset function patch has already been accepted and is
> part of your
> > net-next,
> > https://patchwork.kernel.org/patch/9287497/
> >
> > Above ACPI support of RoCE Reset patch cleanly applies over the
> already accepted
> > patch in the link. It is not dependent on other accompanying RoCE
> driver ACPI
> > changes related patch or even the presence of the Infiniband/RoCE
> Driver in the
> > net-next repository.
> >
> > Could you please suggest anything here?
> >
> > Thanks
> > Salil
> >
> 
> I can take both.  I already pulled net-next to get the initial hns roce
> reset patch from Dave, so these will apply cleanly with my tree and
> merge cleanly with Dave's due to the common ancestral base.  The only
> problem is that if you intend to send any other patches that effect
> this
> code, then they would need to come through me until the 4.9 merge
> window
> is complete so that we don't have later merge conflicts.
Ok sure, I got your point. Yes, there are few patches we need to push in
but are related to RoCE CM(Connection Manager) mode and would follow
soon. There are no further patches we foresee which are for RoCE Driver but are
dependent upon HNS Ethernet driver. 

But kindly note, there could be some patches in development in HNS Ethernet driver
which might sneak in through net-next. These might not be related to RoCE Driver but
might have some common files which might lead to conflict again further down
the line when you try to merge ACPI RoCE reset again. This HNS driver change
is very difficult for us to control since amount of development going on in HNS
is of much higher magnitude than the RoCE as of now. It will be almost impossible
for us to convince internally and shift that entire development being done right
now on net-next and rebase it to your internal hns-roce branch for a month of time
till 4.9. This will affect many features deadlines internally. 

So, if I understood you correctly, this delta (which could be large), when next merge
window open would be taken care by you. And we can expect below to be part of 4.9
1) RoCE Base driver (*Already Accepted*)
2) ACPI changes for RoCE Driver (*if accepted*)
   * ACPI changes for the RoCE Driver
   * ACPI changes for RoCE reset function part of the HNS driver

Please correct my understanding if I am wrong here.

Thanks, again!
Salil Mehta
> 
> --
> Doug Ledford <dledford@redhat.com>
>     GPG Key ID: 0E572FDD

RE: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org [mailto:linux-rdma-
> owner@vger.kernel.org] On Behalf Of Doug Ledford
> Sent: Thursday, August 25, 2016 3:09 PM
> To: Salil Mehta; David Miller
> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
> the Hisilicon RoCE Driver
> 
> On 8/25/2016 8:08 AM, Salil Mehta wrote:
> >
> >
> >> -----Original Message-----
> >> From: Doug Ledford [mailto:dledford@redhat.com]
> >> Sent: Thursday, August 25, 2016 12:57 PM
> >> To: David Miller; Salil Mehta
> >> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> >> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
> >> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> >> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI
> to
> >> the Hisilicon RoCE Driver
> >>
> >> On 8/25/2016 12:53 AM, David Miller wrote:
> >>> From: Salil Mehta <salil.mehta@huawei.com>
> >>> Date: Wed, 24 Aug 2016 04:44:48 +0800
> >>>
> >>>> This patch is meant to add support of ACPI to the Hisilicon RoCE
> >> driver.
> >>>> Following changes have been made in the driver(s):
> >>>>
> >>>> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
> >> done in
> >>>>    the RoCE reset function part of the HNS ethernet driver.
> Earlier
> >> it only
> >>>>    supported DT/syscon.
> >>>>
> >>>> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant
> to
> >> detect
> >>>>    the type and then either use DT specific or ACPI spcific
> >> functions. Where
> >>>>    ever possible, this patch tries to make use of "Unified Device
> >> Property
> >>>>    Interface" APIs to support both DT and ACPI through single
> >> interface.
> >>>>
> >>>> NOTE 1: ACPI changes done in both of the drivers depend upon the
> >> ACPI Table
> >>>>      (DSDT and IORT tables) changes part of UEFI/BIOS. These
> changes
> >> are NOT
> >>>>      part of this patch-set.
> >>>> NOTE 2: Reset function in Patch 1/2 depends upon the reset
> function
> >> added in
> >>>>      ACPI tables(basically DSDT table) part of the UEFI/BIOS.
> Again,
> >> this
> >>>>      change is NOT reflected in this patch-set.
> >>>
> >>> I can't apply this series to my tree because the hns infiniband
> >> driver
> >>> doesn't exist in it.
> >>>
> >>
> >> No.  This probably needs to go through my tree.  Although with all
> of
> >> the requirements, I'm a bit concerned about those being present
> >> elsewhere.
> >>
> >> --
> >> Doug Ledford <dledford@redhat.com>
> >>     GPG Key ID: 0E572FDD
> > Hello Doug,
> > Thanks for your reply. I have just replied to David email as well and
> did
> > not realize your response was already on the way. Sorry for this!
> >
> > I would just like to request, if by any chance, we can expedite the
> acceptance
> > of the below patch (part of patch-set) in the net-next. This might
> help you as
> > well in future when you will actually push the RoCE driver to the
> linux-next.
> >
> > "[PATCH for-next 1/2] net: hns: Add support of ACPI to HNS driver
> RoCE Reset
> >  function"
> >
> > Below HNS RoCE reset function patch has already been accepted by Dave
> Miller and
> > is part of net-next,
> > https://patchwork.kernel.org/patch/9287497/
> >
> > Also, above ACPI support of RoCE Reset patch cleanly applies over the
> already
> > accepted patch in the link and is not dependent on other accompanying
> RoCE
> > driver ACPI changes or even the presence of the Infiniband/RoCE
> Driver in the
> > net-next repository.
> >
> > Could you please suggest if this the something which can be
> considered?
> 
> I've pulled both of these patches in.  I usually merge late in the
> merge
> window, so it won't be any stretch to wait until the ACPI tree has been
> merged before I send Linus my pull request.
Thanks David! Hope we can take care of the delta which might get created
because of unrelated (not related to RoCE driver from other people) HNS
Ethernet changes?

The pace & magnitude at which HNS development is going on and at which RoCE
Development is going on is different.

Best regards
Salil
> 
> 
> --
> Doug Ledford <dledford@redhat.com>
>     GPG Key ID: 0E572FDD

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 2977 bytes --]

On 8/25/2016 10:50 AM, Salil Mehta wrote:

>> I can take both.  I already pulled net-next to get the initial hns roce
>> reset patch from Dave, so these will apply cleanly with my tree and
>> merge cleanly with Dave's due to the common ancestral base.  The only
>> problem is that if you intend to send any other patches that effect
>> this
>> code, then they would need to come through me until the 4.9 merge
>> window
>> is complete so that we don't have later merge conflicts.
> Ok sure, I got your point. Yes, there are few patches we need to push in
> but are related to RoCE CM(Connection Manager) mode and would follow
> soon. There are no further patches we foresee which are for RoCE Driver but are
> dependent upon HNS Ethernet driver. 

Ok.

> But kindly note, there could be some patches in development in HNS Ethernet driver
> which might sneak in through net-next. These might not be related to RoCE Driver but
> might have some common files which might lead to conflict again further down
> the line when you try to merge ACPI RoCE reset again. This HNS driver change
> is very difficult for us to control since amount of development going on in HNS
> is of much higher magnitude than the RoCE as of now. It will be almost impossible
> for us to convince internally and shift that entire development being done right
> now on net-next and rebase it to your internal hns-roce branch for a month of time
> till 4.9. This will affect many features deadlines internally. 

This is what Linus wants to avoid.  It's not necessary to shift your
work from one tree to another, what is needed if for your RoCE team and
your net team to plan out what you are going to submit for the next
kernel and provide a complete list of conflicting code patches to both
Dave and myself and allow us to pull those patches into both our trees
so there are no conflicts.  See the recent threads on linux-rdma about
the pull requests from Mellanox.  This is how it needs to be done.
Neither team needs to slow down, or not do your work, you simply need to
plan that work out and provide a common base for Dave and I to apply the
separate patches on top of.

> So, if I understood you correctly, this delta (which could be large), when next merge
> window open would be taken care by you. And we can expect below to be part of 4.9
> 1) RoCE Base driver (*Already Accepted*)
> 2) ACPI changes for RoCE Driver (*if accepted*)
>    * ACPI changes for the RoCE Driver
>    * ACPI changes for RoCE reset function part of the HNS driver

Both of these changes are already applied to my tree.  However, if you
submit other changes to net-next and it starts generating merge
conflicts, you and the net team are going to get yelled at.  If you are
going to have a shared driver, then you *HAVE* to work as a larger team
and plan your changes you submit to the linux kernel.


-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

RE: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

> -----Original Message-----
> From: Doug Ledford [mailto:dledford@redhat.com]
> Sent: Thursday, August 25, 2016 4:00 PM
> To: Salil Mehta; David Miller
> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
> the Hisilicon RoCE Driver
> 
> On 8/25/2016 10:50 AM, Salil Mehta wrote:
> 
> >> I can take both.  I already pulled net-next to get the initial hns
> roce
> >> reset patch from Dave, so these will apply cleanly with my tree and
> >> merge cleanly with Dave's due to the common ancestral base.  The
> only
> >> problem is that if you intend to send any other patches that effect
> >> this
> >> code, then they would need to come through me until the 4.9 merge
> >> window
> >> is complete so that we don't have later merge conflicts.
> > Ok sure, I got your point. Yes, there are few patches we need to push
> in
> > but are related to RoCE CM(Connection Manager) mode and would follow
> > soon. There are no further patches we foresee which are for RoCE
> Driver but are
> > dependent upon HNS Ethernet driver.
> 
> Ok.
> 
> > But kindly note, there could be some patches in development in HNS
> Ethernet driver
> > which might sneak in through net-next. These might not be related to
> RoCE Driver but
> > might have some common files which might lead to conflict again
> further down
> > the line when you try to merge ACPI RoCE reset again. This HNS driver
> change
> > is very difficult for us to control since amount of development going
> on in HNS
> > is of much higher magnitude than the RoCE as of now. It will be
> almost impossible
> > for us to convince internally and shift that entire development being
> done right
> > now on net-next and rebase it to your internal hns-roce branch for a
> month of time
> > till 4.9. This will affect many features deadlines internally.
> 
> This is what Linus wants to avoid.  It's not necessary to shift your
> work from one tree to another, what is needed if for your RoCE team and
> your net team to plan out what you are going to submit for the next
> kernel and provide a complete list of conflicting code patches to both
> Dave and myself and allow us to pull those patches into both our trees
> so there are no conflicts.  See the recent threads on linux-rdma about
> the pull requests from Mellanox.  This is how it needs to be done.
> Neither team needs to slow down, or not do your work, you simply need
> to
> plan that work out and provide a common base for Dave and I to apply
> the
> separate patches on top of.
I got your point now. Thanks for this clear explanation, Doug. I would
discuss this internally and plan the other non-related HNS conflicting
patches according to the example procedure you indicated in linux-rdma
mail-chain.

> 
> > So, if I understood you correctly, this delta (which could be large),
> when next merge
> > window open would be taken care by you. And we can expect below to be
> part of 4.9
> > 1) RoCE Base driver (*Already Accepted*)
> > 2) ACPI changes for RoCE Driver (*if accepted*)
> >    * ACPI changes for the RoCE Driver
> >    * ACPI changes for RoCE reset function part of the HNS driver
> 
> Both of these changes are already applied to my tree.  However, if you
> submit other changes to net-next and it starts generating merge
> conflicts, you and the net team are going to get yelled at.

Ok thanks. I totally understand that, my current efforts of the discussion
are to understand the process correctly and to ensure that conflict do not
happen.

>  If you are
> going to have a shared driver, then you *HAVE* to work as a larger team
> and plan your changes you submit to the linux kernel.
Sure, agreed
 
> 
> --
> Doug Ledford <dledford@redhat.com>
>     GPG Key ID: 0E572FDD

RE: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

> -----Original Message-----
> From: Doug Ledford [mailto:dledford@redhat.com]
> Sent: Thursday, August 25, 2016 4:00 PM
> To: Salil Mehta; David Miller
> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
> the Hisilicon RoCE Driver
> 
> On 8/25/2016 10:50 AM, Salil Mehta wrote:
> 
> >> I can take both.  I already pulled net-next to get the initial hns
> roce
> >> reset patch from Dave, so these will apply cleanly with my tree and
> >> merge cleanly with Dave's due to the common ancestral base.  The
> only
> >> problem is that if you intend to send any other patches that effect
> >> this
> >> code, then they would need to come through me until the 4.9 merge
> >> window
> >> is complete so that we don't have later merge conflicts.
> > Ok sure, I got your point. Yes, there are few patches we need to push
> in
> > but are related to RoCE CM(Connection Manager) mode and would follow
> > soon. There are no further patches we foresee which are for RoCE
> Driver but are
> > dependent upon HNS Ethernet driver.
> 
> Ok.
> 
> > But kindly note, there could be some patches in development in HNS
> Ethernet driver
> > which might sneak in through net-next. These might not be related to
> RoCE Driver but
> > might have some common files which might lead to conflict again
> further down
> > the line when you try to merge ACPI RoCE reset again. This HNS driver
> change
> > is very difficult for us to control since amount of development going
> on in HNS
> > is of much higher magnitude than the RoCE as of now. It will be
> almost impossible
> > for us to convince internally and shift that entire development being
> done right
> > now on net-next and rebase it to your internal hns-roce branch for a
> month of time
> > till 4.9. This will affect many features deadlines internally.
> 
> This is what Linus wants to avoid.  It's not necessary to shift your
> work from one tree to another, what is needed if for your RoCE team and
> your net team to plan out what you are going to submit for the next
> kernel and provide a complete list of conflicting code patches to both
> Dave and myself and allow us to pull those patches into both our trees
> so there are no conflicts.  See the recent threads on linux-rdma about
> the pull requests from Mellanox.  This is how it needs to be done.
> Neither team needs to slow down, or not do your work, you simply need
> to
> plan that work out and provide a common base for Dave and I to apply
> the
> separate patches on top of.
Hello Doug/David,
As per above discussion, we have identified certain conflicting patches
in HNS driver pipeline which are in conflict With already accepted HNS ACPI
Reset patch in your internal hns-roce repo. We would like to float them on
the lines of Mellanox git-pull request example you mentioned earlier.

HNS driver Patches *in-pipeline* are(formally, later-on, I shall provide
start and end commit IDs within our internal repo):
End-commit-ID
net: hns: fix the bug of forwarding table 
net: hns: fix port not available after testing loopback
net: hns: add promisc mode for hns
net: hns: add fuzzy match of tcam table for hns
net: hns: delete repeat read fbd num after while
net: hns: add fini_process for v2 napi process
net: hns: bug fix about setting coalsecs-usecs to 0
net:hns:fix port unavailable after hnae_reserve_buffer_map fail
start-commit-ID

All of above patches are dependent on the presence of below patch:
"IB/hns: Add support of ACPI to HNS RoCE Reset function"

This patch is already accepted and is part of your k.o/for-4.9-topics/hns-roce.
But this is not part of David Miller's "net-next" yet, so I was wondering
How should I raise the pull request of above set of patches. If I include
the already accepted patch then it will lead conflict in your repo (as it
is already part of it) else it will lead conflict in David's net-next when
he pulls above patches.

Hope the answer is not trivial and I am not missing anything here. 
Please guide. Thanks!

Best regards
Salil
> > So, if I understood you correctly, this delta (which could be large),
> when next merge
> > window open would be taken care by you. And we can expect below to be
> part of 4.9
> > 1) RoCE Base driver (*Already Accepted*)
> > 2) ACPI changes for RoCE Driver (*if accepted*)
> >    * ACPI changes for the RoCE Driver
> >    * ACPI changes for RoCE reset function part of the HNS driver
> 
> Both of these changes are already applied to my tree.  However, if you
> submit other changes to net-next and it starts generating merge
> conflicts, you and the net team are going to get yelled at.  If you are
> going to have a shared driver, then you *HAVE* to work as a larger team
> and plan your changes you submit to the linux kernel.
> 
> 
> --
> Doug Ledford <dledford@redhat.com>
>     GPG Key ID: 0E572FDD

RE: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

> -----Original Message-----
> From: Doug Ledford [mailto:dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org]
> Sent: Thursday, August 25, 2016 12:57 PM
> To: David Miller; Salil Mehta
> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm
> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
> the Hisilicon RoCE Driver
> 
> On 8/25/2016 12:53 AM, David Miller wrote:
> > From: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > Date: Wed, 24 Aug 2016 04:44:48 +0800
> >
> >> This patch is meant to add support of ACPI to the Hisilicon RoCE
> driver.
> >> Following changes have been made in the driver(s):
> >>
> >> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
> done in
> >>    the RoCE reset function part of the HNS ethernet driver. Earlier
> it only
> >>    supported DT/syscon.
> >>
> >> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to
> detect
> >>    the type and then either use DT specific or ACPI spcific
> functions. Where
> >>    ever possible, this patch tries to make use of "Unified Device
> Property
> >>    Interface" APIs to support both DT and ACPI through single
> interface.
> >>
> >> NOTE 1: ACPI changes done in both of the drivers depend upon the
> ACPI Table
> >>      (DSDT and IORT tables) changes part of UEFI/BIOS. These changes
> are NOT
> >>      part of this patch-set.
> >> NOTE 2: Reset function in Patch 1/2 depends upon the reset function
> added in
> >>      ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,
> this
> >>      change is NOT reflected in this patch-set.
> >
> > I can't apply this series to my tree because the hns infiniband
> driver
> > doesn't exist in it.
> >
> 
> No.  This probably needs to go through my tree.  Although with all of
> the requirements, I'm a bit concerned about those being present
> elsewhere.
> 
Hi David,
There is a patch in net-next for HNS Ethernet driver which has been accepted.
"b3dc935 net: hns: remove redundant dev_err call in hns_dsaf_get_cfg()"

This patch is creating conflict with Doug Ledford's hns-roce branch. Internally,
We have decided to let all the HNS patches pass through the hns-roce for 4.9
Merge window to facilitate non-conflict merge of pending RoCE driver by Doug Ledford.

Though, we are trying to take a grip of the process for this merge window but
Somehow this one bypassed the internal process. This will create problems for
Hns-roce during merge later this window. Can I request you to drop this patch
For now. We shall re-submit this patch later when things have been settled at
the RoCE/RDMA end or would come again to you through hns-roce branch.

Please let me know if this is possible this time. Thanks in anticipation!

Best regards
Salil

> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG Key ID: 0E572FDD

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[Salil Mehta]

> -----Original Message-----
> From: Doug Ledford [mailto:dledford@redhat.com]
> Sent: Thursday, August 25, 2016 12:57 PM
> To: David Miller; Salil Mehta
> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to
> the Hisilicon RoCE Driver
> 
> On 8/25/2016 12:53 AM, David Miller wrote:
> > From: Salil Mehta <salil.mehta@huawei.com>
> > Date: Wed, 24 Aug 2016 04:44:48 +0800
> >
> >> This patch is meant to add support of ACPI to the Hisilicon RoCE
> driver.
> >> Following changes have been made in the driver(s):
> >>
> >> Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been
> done in
> >>    the RoCE reset function part of the HNS ethernet driver. Earlier
> it only
> >>    supported DT/syscon.
> >>
> >> Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to
> detect
> >>    the type and then either use DT specific or ACPI spcific
> functions. Where
> >>    ever possible, this patch tries to make use of "Unified Device
> Property
> >>    Interface" APIs to support both DT and ACPI through single
> interface.
> >>
> >> NOTE 1: ACPI changes done in both of the drivers depend upon the
> ACPI Table
> >>      (DSDT and IORT tables) changes part of UEFI/BIOS. These changes
> are NOT
> >>      part of this patch-set.
> >> NOTE 2: Reset function in Patch 1/2 depends upon the reset function
> added in
> >>      ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,
> this
> >>      change is NOT reflected in this patch-set.
> >
> > I can't apply this series to my tree because the hns infiniband
> driver
> > doesn't exist in it.
> >
> 
> No.  This probably needs to go through my tree.  Although with all of
> the requirements, I'm a bit concerned about those being present
> elsewhere.
> 
Hi David,
There is a patch in net-next for HNS Ethernet driver which has been accepted.
"b3dc935 net: hns: remove redundant dev_err call in hns_dsaf_get_cfg()"

This patch is creating conflict with Doug Ledford's hns-roce branch. Internally,
We have decided to let all the HNS patches pass through the hns-roce for 4.9
Merge window to facilitate non-conflict merge of pending RoCE driver by Doug Ledford.

Though, we are trying to take a grip of the process for this merge window but
Somehow this one bypassed the internal process. This will create problems for
Hns-roce during merge later this window. Can I request you to drop this patch
For now. We shall re-submit this patch later when things have been settled at
the RoCE/RDMA end or would come again to you through hns-roce branch.

Please let me know if this is possible this time. Thanks in anticipation!

Best regards
Salil

> --
> Doug Ledford <dledford@redhat.com>
>     GPG Key ID: 0E572FDD

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[David Miller]

From: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Date: Mon, 5 Sep 2016 12:53:07 +0000

> There is a patch in net-next for HNS Ethernet driver which has been accepted.
> "b3dc935 net: hns: remove redundant dev_err call in hns_dsaf_get_cfg()"
> 
> This patch is creating conflict with Doug Ledford's hns-roce branch. Internally,
> We have decided to let all the HNS patches pass through the hns-roce for 4.9
> Merge window to facilitate non-conflict merge of pending RoCE driver by Doug Ledford.
> 
> Though, we are trying to take a grip of the process for this merge window but
> Somehow this one bypassed the internal process. This will create problems for
> Hns-roce during merge later this window. Can I request you to drop this patch
> For now. We shall re-submit this patch later when things have been settled at
> the RoCE/RDMA end or would come again to you through hns-roce branch.
> 
> Please let me know if this is possible this time. Thanks in anticipation!

This cannot work like this.

If I see an obvious fix to something in networking, I will apply the
patch.

Merge conflicts happen and they have to be resolved.

We don't just revert legitimate changes to eliminate the conflict.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

[David Miller]

From: Salil Mehta <salil.mehta@huawei.com>
Date: Mon, 5 Sep 2016 12:53:07 +0000

> There is a patch in net-next for HNS Ethernet driver which has been accepted.
> "b3dc935 net: hns: remove redundant dev_err call in hns_dsaf_get_cfg()"
> 
> This patch is creating conflict with Doug Ledford's hns-roce branch. Internally,
> We have decided to let all the HNS patches pass through the hns-roce for 4.9
> Merge window to facilitate non-conflict merge of pending RoCE driver by Doug Ledford.
> 
> Though, we are trying to take a grip of the process for this merge window but
> Somehow this one bypassed the internal process. This will create problems for
> Hns-roce during merge later this window. Can I request you to drop this patch
> For now. We shall re-submit this patch later when things have been settled at
> the RoCE/RDMA end or would come again to you through hns-roce branch.
> 
> Please let me know if this is possible this time. Thanks in anticipation!

This cannot work like this.

If I see an obvious fix to something in networking, I will apply the
patch.

Merge conflicts happen and they have to be resolved.

We don't just revert legitimate changes to eliminate the conflict.