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
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 <[email protected]>
---
.../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
Device unload control net function should inform firmware
of driver unload to let it take necessary actions to cleanup.
Signed-off-by: Shinas Rasheed <[email protected]>
---
.../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
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?
> -----Original Message-----
> From: Jakub Kicinski <[email protected]>
> Sent: Tuesday, November 28, 2023 8:13 AM
> To: Shinas Rasheed <[email protected]>
>
> 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?
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.
On Tue, 28 Nov 2023 04:22:11 +0000 Shinas Rasheed wrote:
> > 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?
>
> 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.
> -----Original Message-----
> From: Jakub Kicinski <[email protected]>
> Sent: Tuesday, November 28, 2023 9:57 PM
> To: Shinas Rasheed <[email protected]>
> Cc: [email protected]; [email protected]; Haseeb Gani
> On Tue, 28 Nov 2023 04:22:11 +0000 Shinas Rasheed wrote:
> > > 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?
> >
> > 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.
On Tue, 28 Nov 2023 19:08:26 +0000 Shinas Rasheed wrote:
> > 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..
> -----Original Message-----
> From: Jakub Kicinski <[email protected]>
> Sent: Wednesday, November 29, 2023 3:25 AM
> To: Shinas Rasheed <[email protected]>
> >+ 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