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

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

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 <redacted>
---
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

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[off-list ref]. 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 <redacted>
Reviewed-by: Yisen Zhuang <redacted>
---
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

On Wed, Aug 24, 2016 at 04:44:50AM +0800, Salil Mehta wrote:

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

-----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:

quoted

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 <redacted>
---
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

++++++++++++++++++++++-----

quoted

 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

quoted

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

quoted

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)

quoted

 	for (j = 0; j < eq_num; j++) {
 		ret = request_irq(eq_table->eq[j].irq,

hns_roce_msi_x_interrupt,

quoted

-				  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

quoted

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)

quoted

  * @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

quoted

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);

quoted

+int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool

dereset);

quoted

 #endif

diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c

b/drivers/infiniband/hw/hns/hns_roce_main.c

quoted

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,

},

quoted

+	{},
+};
+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

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

From: Salil Mehta <redacted>
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.

-----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 <redacted>
Date: Wed, 24 Aug 2016 04:44:48 +0800

quoted

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

driver.

quoted

Following changes have been made in the driver(s):

Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been

done in

quoted

   the RoCE reset function part of the HNS ethernet driver. Earlier

it only

quoted

   supported DT/syscon.

Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to

detect

quoted

   the type and then either use DT specific or ACPI spcific

functions. Where

quoted

   ever possible, this patch tries to make use of "Unified Device

Property

quoted

   Interface" APIs to support both DT and ACPI through single

interface.

quoted

NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI

Table

quoted

     (DSDT and IORT tables) changes part of UEFI/BIOS. These changes

are NOT

quoted

     part of this patch-set.
NOTE 2: Reset function in Patch 1/2 depends upon the reset function

added in

quoted

     ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,

this

quoted

     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

On 8/25/2016 12:53 AM, David Miller wrote:

From: Salil Mehta <redacted>
Date: Wed, 24 Aug 2016 04:44:48 +0800

quoted

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 [off-list ref]
    GPG Key ID: 0E572FDD

-----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:

quoted

From: Salil Mehta <redacted>
Date: Wed, 24 Aug 2016 04:44:48 +0800

quoted

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

driver.

quoted

quoted

Following changes have been made in the driver(s):

Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been

done in

quoted

quoted

   the RoCE reset function part of the HNS ethernet driver. Earlier

it only

quoted

quoted

   supported DT/syscon.

Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to

detect

quoted

quoted

   the type and then either use DT specific or ACPI spcific

functions. Where

quoted

quoted

   ever possible, this patch tries to make use of "Unified Device

Property

quoted

quoted

   Interface" APIs to support both DT and ACPI through single

interface.

quoted

quoted

NOTE 1: ACPI changes done in both of the drivers depend upon the

ACPI Table

quoted

quoted

     (DSDT and IORT tables) changes part of UEFI/BIOS. These changes

are NOT

quoted

quoted

     part of this patch-set.
NOTE 2: Reset function in Patch 1/2 depends upon the reset function

added in

quoted

quoted

     ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,

this

quoted

quoted

     change is NOT reflected in this patch-set.

I can't apply this series to my tree because the hns infiniband

driver

quoted

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 [off-list ref]
    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

On 8/25/2016 8:00 AM, Salil Mehta wrote:

quoted

-----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 <redacted>
Date: Wed, 24 Aug 2016 04:44:48 +0800

quoted

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

driver.

quoted

Following changes have been made in the driver(s):

Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been

done in

quoted

   the RoCE reset function part of the HNS ethernet driver. Earlier

it only

quoted

   supported DT/syscon.

Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to

detect

quoted

   the type and then either use DT specific or ACPI spcific

functions. Where

quoted

   ever possible, this patch tries to make use of "Unified Device

Property

quoted

   Interface" APIs to support both DT and ACPI through single

interface.

quoted

NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI

Table

quoted

     (DSDT and IORT tables) changes part of UEFI/BIOS. These changes

are NOT

quoted

     part of this patch-set.
NOTE 2: Reset function in Patch 1/2 depends upon the reset function

added in

quoted

     ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,

this

quoted

     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 [off-list ref]
    GPG Key ID: 0E572FDD

On 8/25/2016 8:08 AM, Salil Mehta wrote:

quoted

-----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:

quoted

From: Salil Mehta <redacted>
Date: Wed, 24 Aug 2016 04:44:48 +0800

quoted

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

driver.

quoted

quoted

Following changes have been made in the driver(s):

Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been

done in

quoted

quoted

   the RoCE reset function part of the HNS ethernet driver. Earlier

it only

quoted

quoted

   supported DT/syscon.

Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to

detect

quoted

quoted

   the type and then either use DT specific or ACPI spcific

functions. Where

quoted

quoted

   ever possible, this patch tries to make use of "Unified Device

Property

quoted

quoted

   Interface" APIs to support both DT and ACPI through single

interface.

quoted

quoted

NOTE 1: ACPI changes done in both of the drivers depend upon the

ACPI Table

quoted

quoted

     (DSDT and IORT tables) changes part of UEFI/BIOS. These changes

are NOT

quoted

quoted

     part of this patch-set.
NOTE 2: Reset function in Patch 1/2 depends upon the reset function

added in

quoted

quoted

     ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,

this

quoted

quoted

     change is NOT reflected in this patch-set.

I can't apply this series to my tree because the hns infiniband

driver

quoted

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 [off-list ref]
    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 [off-list ref]
    GPG Key ID: 0E572FDD

-----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:

quoted

quoted

-----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);

quoted

quoted

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

quoted

quoted

the Hisilicon RoCE Driver

From: Salil Mehta <redacted>
Date: Wed, 24 Aug 2016 04:44:48 +0800

quoted

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

driver.

quoted

Following changes have been made in the driver(s):

Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been

done in

quoted

   the RoCE reset function part of the HNS ethernet driver. Earlier

it only

quoted

   supported DT/syscon.

Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant

to

quoted

quoted

detect

quoted

   the type and then either use DT specific or ACPI spcific

functions. Where

quoted

   ever possible, this patch tries to make use of "Unified Device

Property

quoted

   Interface" APIs to support both DT and ACPI through single

interface.

quoted

NOTE 1: ACPI changes done in both of the drivers depend upon the

ACPI

quoted

quoted

Table

quoted

     (DSDT and IORT tables) changes part of UEFI/BIOS. These

changes

quoted

quoted

are NOT

quoted

     part of this patch-set.
NOTE 2: Reset function in Patch 1/2 depends upon the reset function

added in

quoted

     ACPI tables(basically DSDT table) part of the UEFI/BIOS.

Again,

quoted

quoted

this

quoted

     change is NOT reflected in this patch-set.

I can't apply this series to my tree because the hns infiniband

driver

quoted

quoted

doesn't exist in it.

Hi David,
I understand your point. This patch-set was primarily sent for Doug

Ledford

quoted

and is based on his internal repository (which has been rebased on

the

quoted

net-next).

Though we were hoping, if by any chance, we can expedite the

acceptance of the

quoted

below patch part of patch-set in the net-next. This might help Doug

Ledford as

quoted

well later on when he pushes the already accepted RoCE driver and

ACPI patches

quoted

to linux-next,

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

RoCE Reset

quoted

 function"

Below HNS RoCE reset function patch has already been accepted and is

part of your

quoted

net-next,
https://patchwork.kernel.org/patch/9287497/

Above ACPI support of RoCE Reset patch cleanly applies over the

already accepted

quoted

patch in the link. It is not dependent on other accompanying RoCE

driver ACPI

quoted

changes related patch or even the presence of the Infiniband/RoCE

Driver in the

quoted

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 [off-list ref]
    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

-----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:

quoted

quoted

-----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

quoted

quoted

the Hisilicon RoCE Driver

On 8/25/2016 12:53 AM, David Miller wrote:

quoted

From: Salil Mehta <redacted>
Date: Wed, 24 Aug 2016 04:44:48 +0800

quoted

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

driver.

quoted

quoted

Following changes have been made in the driver(s):

Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been

done in

quoted

quoted

   the RoCE reset function part of the HNS ethernet driver.

Earlier

quoted

quoted

it only

quoted

quoted

   supported DT/syscon.

Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant

to

quoted

quoted

detect

quoted

quoted

   the type and then either use DT specific or ACPI spcific

functions. Where

quoted

quoted

   ever possible, this patch tries to make use of "Unified Device

Property

quoted

quoted

   Interface" APIs to support both DT and ACPI through single

interface.

quoted

quoted

NOTE 1: ACPI changes done in both of the drivers depend upon the

ACPI Table

quoted

quoted

     (DSDT and IORT tables) changes part of UEFI/BIOS. These

changes

quoted

quoted

are NOT

quoted

quoted

     part of this patch-set.
NOTE 2: Reset function in Patch 1/2 depends upon the reset

function

quoted

quoted

added in

quoted

quoted

     ACPI tables(basically DSDT table) part of the UEFI/BIOS.

Again,

quoted

quoted

this

quoted

quoted

     change is NOT reflected in this patch-set.

I can't apply this series to my tree because the hns infiniband

driver

quoted

doesn't exist in it.

No.  This probably needs to go through my tree.  Although with all

of

quoted

quoted

the requirements, I'm a bit concerned about those being present
elsewhere.

--
Doug Ledford [off-list ref]
    GPG Key ID: 0E572FDD

Hello Doug,
Thanks for your reply. I have just replied to David email as well and

did

quoted

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

quoted

of the below patch (part of patch-set) in the net-next. This might

help you as

quoted

well in future when you will actually push the RoCE driver to the

linux-next.

quoted

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

RoCE Reset

quoted

 function"

Below HNS RoCE reset function patch has already been accepted by Dave

Miller and

quoted

is part of net-next,
https://patchwork.kernel.org/patch/9287497/

Also, above ACPI support of RoCE Reset patch cleanly applies over the

already

quoted

accepted patch in the link and is not dependent on other accompanying

RoCE

quoted

driver ACPI changes or even the presence of the Infiniband/RoCE

Driver in the

quoted

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 [off-list ref]
    GPG Key ID: 0E572FDD

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

quoted

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 [off-list ref]
    GPG Key ID: 0E572FDD

-----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:

quoted

quoted

I can take both.  I already pulled net-next to get the initial hns

roce

quoted

quoted

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

quoted

quoted

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

quoted

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

quoted

dependent upon HNS Ethernet driver.

Ok.

quoted

But kindly note, there could be some patches in development in HNS

Ethernet driver

quoted

which might sneak in through net-next. These might not be related to

RoCE Driver but

quoted

might have some common files which might lead to conflict again

further down

quoted

the line when you try to merge ACPI RoCE reset again. This HNS driver

change

quoted

is very difficult for us to control since amount of development going

on in HNS

quoted

is of much higher magnitude than the RoCE as of now. It will be

almost impossible

quoted

for us to convince internally and shift that entire development being

done right

quoted

now on net-next and rebase it to your internal hns-roce branch for a

month of time

quoted

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.

quoted

So, if I understood you correctly, this delta (which could be large),

when next merge

quoted

window open would be taken care by you. And we can expect below to be

part of 4.9

quoted

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 [off-list ref]
    GPG Key ID: 0E572FDD

-----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:

quoted

quoted

I can take both.  I already pulled net-next to get the initial hns

roce

quoted

quoted

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

quoted

quoted

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

quoted

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

quoted

dependent upon HNS Ethernet driver.

Ok.

quoted

But kindly note, there could be some patches in development in HNS

Ethernet driver

quoted

which might sneak in through net-next. These might not be related to

RoCE Driver but

quoted

might have some common files which might lead to conflict again

further down

quoted

the line when you try to merge ACPI RoCE reset again. This HNS driver

change

quoted

is very difficult for us to control since amount of development going

on in HNS

quoted

is of much higher magnitude than the RoCE as of now. It will be

almost impossible

quoted

for us to convince internally and shift that entire development being

done right

quoted

now on net-next and rebase it to your internal hns-roce branch for a

month of time

quoted

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

quoted

So, if I understood you correctly, this delta (which could be large),

when next merge

quoted

window open would be taken care by you. And we can expect below to be

part of 4.9

quoted

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 [off-list ref]
    GPG Key ID: 0E572FDD

-----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:

quoted

From: Salil Mehta <redacted>
Date: Wed, 24 Aug 2016 04:44:48 +0800

quoted

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

driver.

quoted

quoted

Following changes have been made in the driver(s):

Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been

done in

quoted

quoted

   the RoCE reset function part of the HNS ethernet driver. Earlier

it only

quoted

quoted

   supported DT/syscon.

Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to

detect

quoted

quoted

   the type and then either use DT specific or ACPI spcific

functions. Where

quoted

quoted

   ever possible, this patch tries to make use of "Unified Device

Property

quoted

quoted

   Interface" APIs to support both DT and ACPI through single

interface.

quoted

quoted

NOTE 1: ACPI changes done in both of the drivers depend upon the

ACPI Table

quoted

quoted

     (DSDT and IORT tables) changes part of UEFI/BIOS. These changes

are NOT

quoted

quoted

     part of this patch-set.
NOTE 2: Reset function in Patch 1/2 depends upon the reset function

added in

quoted

quoted

     ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,

this

quoted

quoted

     change is NOT reflected in this patch-set.

I can't apply this series to my tree because the hns infiniband

driver

quoted

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 [off-list ref]
    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

From: Salil Mehta <redacted>
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