[PATCH net-next v1 0/2] support OCTEON CN98 devices

STALE1030d

Revision v1 of 2 in this series.

9 messages, 2 authors, 2023-11-29 · open the first message on its own page

[PATCH net-next v1 0/2] support OCTEON CN98 devices

From: Shinas Rasheed <srasheed@marvell.com>
Date: 2023-11-27 16:22:21

Implement device unload control net API required for CN98
devices and add support in driver for the same.

Shinas Rasheed (2):
  octeon_ep: implement device unload control net API
  octeon_ep: support OCTEON CN98 devices

 .../ethernet/marvell/octeon_ep.rst            |  1 +
 .../marvell/octeon_ep/octep_cn9k_pf.c         | 24 +++++++++++++++----
 .../marvell/octeon_ep/octep_ctrl_net.c        | 16 ++++++++++++-
 .../marvell/octeon_ep/octep_ctrl_net.h        | 11 +++++++++
 .../ethernet/marvell/octeon_ep/octep_main.c   |  4 ++++
 .../ethernet/marvell/octeon_ep/octep_main.h   |  1 +
 .../marvell/octeon_ep/octep_regs_cn9k_pf.h    |  4 ++++
 7 files changed, 56 insertions(+), 5 deletions(-)

-- 
2.25.1

[PATCH net-next v1 1/2] octeon_ep: implement device unload control net API

From: Shinas Rasheed <srasheed@marvell.com>
Date: 2023-11-27 16:22:18

Device unload control net function should inform firmware
of driver unload to let it take necessary actions to cleanup.

Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
---
 .../ethernet/marvell/octeon_ep/octep_ctrl_net.c  | 16 +++++++++++++++-
 .../ethernet/marvell/octeon_ep/octep_ctrl_net.h  | 11 +++++++++++
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.c b/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.c
index 5fa596c674da..f0fdfda8894a 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.c
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.c

@@ -26,7 +26,7 @@ static atomic_t ctrl_net_msg_id;
 
 /* Control plane version in which OCTEP_CTRL_NET_H2F_CMD was added */
 static const u32 octep_ctrl_net_h2f_cmd_versions[OCTEP_CTRL_NET_H2F_CMD_MAX] = {
-	[OCTEP_CTRL_NET_H2F_CMD_INVALID ... OCTEP_CTRL_NET_H2F_CMD_GET_INFO] =
+	[OCTEP_CTRL_NET_H2F_CMD_INVALID ... OCTEP_CTRL_NET_H2F_CMD_DEV_REMOVE] =
 	 OCTEP_CP_VERSION(1, 0, 0)
 };

@@ -393,10 +393,24 @@ int octep_ctrl_net_get_info(struct octep_device *oct, int vfid,
 	return 0;
 }
 
+int octep_ctrl_net_dev_remove(struct octep_device *oct, int vfid)
+{
+	struct octep_ctrl_net_wait_data d = {};
+	struct octep_ctrl_net_h2f_req *req;
+
+	req = &d.data.req;
+	dev_info(&oct->pdev->dev, "Sending dev_unload msg to fw\n");
+	init_send_req(&d.msg, req, sizeof(int), vfid);
+	req->hdr.s.cmd = OCTEP_CTRL_NET_H2F_CMD_DEV_REMOVE;
+
+	return octep_send_mbox_req(oct, &d, false);
+}
 int octep_ctrl_net_uninit(struct octep_device *oct)
 {
 	struct octep_ctrl_net_wait_data *pos, *n;
 
+	octep_ctrl_net_dev_remove(oct, OCTEP_CTRL_NET_INVALID_VFID);
+
 	list_for_each_entry_safe(pos, n, &oct->ctrl_req_wait_list, list)
 		pos->done = 1;

diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.h b/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.h
index a2463b460ad9..0de4de2ceb8f 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.h
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.h

@@ -42,6 +42,7 @@ enum octep_ctrl_net_h2f_cmd {
 	OCTEP_CTRL_NET_H2F_CMD_RX_STATE,
 	OCTEP_CTRL_NET_H2F_CMD_LINK_INFO,
 	OCTEP_CTRL_NET_H2F_CMD_GET_INFO,
+	OCTEP_CTRL_NET_H2F_CMD_DEV_REMOVE,
 	OCTEP_CTRL_NET_H2F_CMD_MAX
 };

@@ -370,6 +371,16 @@ void octep_ctrl_net_recv_fw_messages(struct octep_device *oct);
 int octep_ctrl_net_get_info(struct octep_device *oct, int vfid,
 			    struct octep_fw_info *info);
 
+/**
+ * octep_ctrl_net_dev_remove() - Indicate to firmware that a device unload has happened.
+ *
+ * @oct: non-null pointer to struct octep_device.
+ * @vfid: Index of virtual function.
+ *
+ * return value: 0 on success, -errno on failure.
+ */
+int octep_ctrl_net_dev_remove(struct octep_device *oct, int vfid);
+
 /**
  * octep_ctrl_net_uninit() - Uninitialize data for ctrl net.
  *

-- 
2.25.1

[PATCH net-next v1 2/2] octeon_ep: support OCTEON CN98 devices

From: Shinas Rasheed <srasheed@marvell.com>
Date: 2023-11-27 16:22:24

Add PCI Endpoint NIC support for Octeon CN98 devices.
CN98 devices are part of Octeon 9 family products with
similar PCI NIC characteristics to CN93, already supported
driver.

Add CN98 card to the device id table, as well
as support differences in the register fields and
certain usage scenarios such as unload.

Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
---
 .../ethernet/marvell/octeon_ep.rst            |  1 +
 .../marvell/octeon_ep/octep_cn9k_pf.c         | 24 +++++++++++++++----
 .../ethernet/marvell/octeon_ep/octep_main.c   |  4 ++++
 .../ethernet/marvell/octeon_ep/octep_main.h   |  1 +
 .../marvell/octeon_ep/octep_regs_cn9k_pf.h    |  4 ++++
 5 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst
index 613a818d5db6..c96d262b30be 100644
--- a/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst
+++ b/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst

@@ -22,6 +22,7 @@ EndPoint NIC.
 Supported Devices
 =================
 Currently, this driver support following devices:
+ * Network controller: Cavium, Inc. Device b100
  * Network controller: Cavium, Inc. Device b200
  * Network controller: Cavium, Inc. Device b400
  * Network controller: Cavium, Inc. Device b900

diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_cn9k_pf.c b/drivers/net/ethernet/marvell/octeon_ep/octep_cn9k_pf.c
index d4ee2454675b..8baabd07e91f 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_cn9k_pf.c
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_cn9k_pf.c

@@ -216,9 +216,15 @@ static void octep_init_config_cn93_pf(struct octep_device *oct)
 	conf->sriov_cfg.vf_srn = CN93_SDP_EPF_RINFO_SRN(val);
 
 	val = octep_read_csr64(oct, CN93_SDP_MAC_PF_RING_CTL(oct->pcie_port));
-	conf->pf_ring_cfg.srn =  CN93_SDP_MAC_PF_RING_CTL_SRN(val);
-	conf->pf_ring_cfg.max_io_rings = CN93_SDP_MAC_PF_RING_CTL_RPPF(val);
-	conf->pf_ring_cfg.active_io_rings = conf->pf_ring_cfg.max_io_rings;
+	if (oct->chip_id == OCTEP_PCI_DEVICE_ID_CN98_PF) {
+		conf->pf_ring_cfg.srn =  CN98_SDP_MAC_PF_RING_CTL_SRN(val);
+		conf->pf_ring_cfg.max_io_rings = CN98_SDP_MAC_PF_RING_CTL_RPPF(val);
+		conf->pf_ring_cfg.active_io_rings = conf->pf_ring_cfg.max_io_rings;
+	} else {
+		conf->pf_ring_cfg.srn =  CN93_SDP_MAC_PF_RING_CTL_SRN(val);
+		conf->pf_ring_cfg.max_io_rings = CN93_SDP_MAC_PF_RING_CTL_RPPF(val);
+		conf->pf_ring_cfg.active_io_rings = conf->pf_ring_cfg.max_io_rings;
+	}
 	dev_info(&pdev->dev, "pf_srn=%u rpvf=%u nvfs=%u rppf=%u\n",
 		 conf->pf_ring_cfg.srn, conf->sriov_cfg.active_rings_per_vf,
 		 conf->sriov_cfg.active_vfs, conf->pf_ring_cfg.active_io_rings);

@@ -578,6 +584,13 @@ static irqreturn_t octep_ioq_intr_handler_cn93_pf(void *data)
 	return IRQ_HANDLED;
 }
 
+/* soft reset of 98xx */
+static int octep_soft_reset_cn98_pf(struct octep_device *oct)
+{
+	dev_info(&oct->pdev->dev, "CN98XX: skip soft reset\n");
+	return 0;
+}
+
 /* soft reset of 93xx */
 static int octep_soft_reset_cn93_pf(struct octep_device *oct)
 {

@@ -806,7 +819,10 @@ void octep_device_setup_cn93_pf(struct octep_device *oct)
 	oct->hw_ops.misc_intr_handler = octep_misc_intr_handler_cn93_pf;
 	oct->hw_ops.rsvd_intr_handler = octep_rsvd_intr_handler_cn93_pf;
 	oct->hw_ops.ioq_intr_handler = octep_ioq_intr_handler_cn93_pf;
-	oct->hw_ops.soft_reset = octep_soft_reset_cn93_pf;
+	if (oct->chip_id == OCTEP_PCI_DEVICE_ID_CN98_PF)
+		oct->hw_ops.soft_reset = octep_soft_reset_cn98_pf;
+	else
+		oct->hw_ops.soft_reset = octep_soft_reset_cn93_pf;
 	oct->hw_ops.reinit_regs = octep_reinit_regs_cn93_pf;
 
 	oct->hw_ops.enable_interrupts = octep_enable_interrupts_cn93_pf;

diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_main.c b/drivers/net/ethernet/marvell/octeon_ep/octep_main.c
index 423eec5ff3ad..1a24b3d3cce6 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_main.c
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_main.c

@@ -22,6 +22,7 @@ struct workqueue_struct *octep_wq;
 
 /* Supported Devices */
 static const struct pci_device_id octep_pci_id_tbl[] = {
+	{PCI_DEVICE(PCI_VENDOR_ID_CAVIUM, OCTEP_PCI_DEVICE_ID_CN98_PF)},
 	{PCI_DEVICE(PCI_VENDOR_ID_CAVIUM, OCTEP_PCI_DEVICE_ID_CN93_PF)},
 	{PCI_DEVICE(PCI_VENDOR_ID_CAVIUM, OCTEP_PCI_DEVICE_ID_CNF95N_PF)},
 	{PCI_DEVICE(PCI_VENDOR_ID_CAVIUM, OCTEP_PCI_DEVICE_ID_CN10KA_PF)},

@@ -1147,6 +1148,8 @@ static void octep_ctrl_mbox_task(struct work_struct *work)
 static const char *octep_devid_to_str(struct octep_device *oct)
 {
 	switch (oct->chip_id) {
+	case OCTEP_PCI_DEVICE_ID_CN98_PF:
+		return "CN98XX";
 	case OCTEP_PCI_DEVICE_ID_CN93_PF:
 		return "CN93XX";
 	case OCTEP_PCI_DEVICE_ID_CNF95N_PF:

@@ -1197,6 +1200,7 @@ int octep_device_setup(struct octep_device *oct)
 	dev_info(&pdev->dev, "chip_id = 0x%x\n", pdev->device);
 
 	switch (oct->chip_id) {
+	case OCTEP_PCI_DEVICE_ID_CN98_PF:
 	case OCTEP_PCI_DEVICE_ID_CN93_PF:
 	case OCTEP_PCI_DEVICE_ID_CNF95N_PF:
 		dev_info(&pdev->dev, "Setting up OCTEON %s PF PASS%d.%d\n",

diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_main.h b/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
index e2fe8b28eb0e..e1b4b2af618e 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_main.h

@@ -18,6 +18,7 @@
 #define  OCTEP_PCIID_CN93_PF  0xB200177d
 #define  OCTEP_PCIID_CN93_VF  0xB203177d
 
+#define  OCTEP_PCI_DEVICE_ID_CN98_PF 0xB100
 #define  OCTEP_PCI_DEVICE_ID_CN93_PF 0xB200
 #define  OCTEP_PCI_DEVICE_ID_CN93_VF 0xB203

diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_regs_cn9k_pf.h b/drivers/net/ethernet/marvell/octeon_ep/octep_regs_cn9k_pf.h
index 0a43983e9101..2e20a39d89af 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_regs_cn9k_pf.h
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_regs_cn9k_pf.h

@@ -362,6 +362,10 @@
 #define    CN93_SDP_MAC_PF_RING_CTL_SRN(val)   (((val) >> 8) & 0xFF)
 #define    CN93_SDP_MAC_PF_RING_CTL_RPPF(val)  (((val) >> 16) & 0x3F)
 
+#define    CN98_SDP_MAC_PF_RING_CTL_NPFS(val)  (((val) >> 48) & 0xF)
+#define    CN98_SDP_MAC_PF_RING_CTL_SRN(val)   ((val) & 0xFF)
+#define    CN98_SDP_MAC_PF_RING_CTL_RPPF(val)  (((val) >> 32) & 0x3F)
+
 /* Number of non-queue interrupts in CN93xx */
 #define    CN93_NUM_NON_IOQ_INTR    16

-- 
2.25.1

Re: [PATCH net-next v1 1/2] octeon_ep: implement device unload control net API

From: Jakub Kicinski <kuba@kernel.org>
Date: 2023-11-28 02:43:11

On Mon, 27 Nov 2023 08:21:34 -0800 Shinas Rasheed wrote:

Device unload control net function should inform firmware

What is "control net" again?

RE: [EXT] Re: [PATCH net-next v1 1/2] octeon_ep: implement device unload control net API

From: Shinas Rasheed <srasheed@marvell.com>
Date: 2023-11-28 04:22:30

-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: Tuesday, November 28, 2023 8:13 AM
To: Shinas Rasheed <srasheed@marvell.com>

On Mon, 27 Nov 2023 08:21:34 -0800 Shinas Rasheed wrote:

quoted

Device unload control net function should inform firmware

What is "control net" again?

Control net is just a software layer which is used by the host driver as well as the firmware to communicate with each other, given in the source file octep_ctrl_net.c and the corresponding octep_ctrl_net.h interface, which is already part of upstreamed driver.

Re: [EXT] Re: [PATCH net-next v1 1/2] octeon_ep: implement device unload control net API

From: Jakub Kicinski <kuba@kernel.org>
Date: 2023-11-28 16:27:17

On Tue, 28 Nov 2023 04:22:11 +0000 Shinas Rasheed wrote:

quoted

On Mon, 27 Nov 2023 08:21:34 -0800 Shinas Rasheed wrote:

quoted

Device unload control net function should inform firmware

What is "control net" again?

Control net is just a software layer which is used by the host driver
as well as the firmware to communicate with each other, given in the
source file octep_ctrl_net.c and the corresponding octep_ctrl_net.h
interface, which is already part of upstreamed driver.

Yes, I think it went in before I had time to nack it.
I'm strongly against using the IP stack to talk to FW,
if you read the ML you would know it.

No new patches to octep_ctrl_net will be accepted.

RE: [EXT] Re: [PATCH net-next v1 1/2] octeon_ep: implement device unload control net API

From: Shinas Rasheed <srasheed@marvell.com>
Date: 2023-11-28 19:08:42

-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: Tuesday, November 28, 2023 9:57 PM
To: Shinas Rasheed <srasheed@marvell.com>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Haseeb Gani
On Tue, 28 Nov 2023 04:22:11 +0000 Shinas Rasheed wrote:

quoted

On Mon, 27 Nov 2023 08:21:34 -0800 Shinas Rasheed wrote:

quoted

Device unload control net function should inform firmware

What is "control net" again?

Control net is just a software layer which is used by the host driver
as well as the firmware to communicate with each other, given in the
source file octep_ctrl_net.c and the corresponding octep_ctrl_net.h
interface, which is already part of upstreamed driver.

Yes, I think it went in before I had time to nack it.
I'm strongly against using the IP stack to talk to FW,
if you read the ML you would know it.

No new patches to octep_ctrl_net will be accepted.

Control net doesn't use the IP stack at all. It's a simple producer-consumer based ring mechanism using PCIe BAR4 memory. Sorry maybe the nomenclature suggests something of that nature.

Re: [EXT] Re: [PATCH net-next v1 1/2] octeon_ep: implement device unload control net API

From: Jakub Kicinski <kuba@kernel.org>
Date: 2023-11-28 21:54:55

On Tue, 28 Nov 2023 19:08:26 +0000 Shinas Rasheed wrote:

quoted

Yes, I think it went in before I had time to nack it.
I'm strongly against using the IP stack to talk to FW,
if you read the ML you would know it.

No new patches to octep_ctrl_net will be accepted.

Control net doesn't use the IP stack at all. It's a simple
producer-consumer based ring mechanism using PCIe BAR4 memory.
Sorry maybe the nomenclature suggests something of that nature.

Ah, got it. I read that as "separate netdev for control", my bad.
Just one nit then:

+	dev_info(&oct->pdev->dev, "Sending dev_unload msg to fw\n");

Is it really necessary to print this at info level for each remove?
Remove is a normal part of operation and we shouldn't spam logs
unless we have a good reason..

RE: [EXT] Re: [PATCH net-next v1 1/2] octeon_ep: implement device unload control net API

From: Shinas Rasheed <srasheed@marvell.com>
Date: 2023-11-29 04:42:42

-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: Wednesday, November 29, 2023 3:25 AM
To: Shinas Rasheed <srasheed@marvell.com>

quoted

+	dev_info(&oct->pdev->dev, "Sending dev_unload msg to fw\n");

Is it really necessary to print this at info level for each remove?
Remove is a normal part of operation and we shouldn't spam logs
unless we have a good reason..

I suppose it's not a need other than maybe for debug purposes. I'll use dev_dbg and submit a second version

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help