| Message ID | 1536078525-31534-1-git-send-email-sunil.kovvuri@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | soc: octeontx2: Add RVU admin function driver | expand |
On Tue, Sep 4, 2018 at 9:58 PM <sunil.kovvuri@gmail.com> wrote: > > From: Sunil Goutham <sgoutham@marvell.com> > > Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC supports > multiple PCIe SRIOV physical functions (PFs) and virtual functions (VFs). > PF0 is called administrative / admin function (AF) and has privilege access > to registers to provision different RVU functional blocks to each of > PF/VF. > > This admin function (AF) driver acts as a configuration / administrative > software which provisions functional blocks to a PF/VF on demand for them > to work as one of the following > - A basic network controller (i.e NIC). > - NIC with packet filtering, shaping and scheduling capabilities. > - A crypto device. > - A combination of above etc. > > PF/VFs communicate with admin function via a shared memory region. > This patch series adds logic for the following > - RVU AF driver with functional blocks provisioning support > - Mailbox infrastructure for communication between AF and PFs. > - CGX driver which provides information about physcial network > interfaces which AF processes and forwards required info to > PF/VF drivers. > > This is the first set of patches out of 70 odd patches. > > Note: This driver neither receives any data nor processes it i.e no I/O, > just does the hardware configuration. > > Changes from v2: > No changes, submitted again with netdev mailing list in loop. > - Suggested by Arnd Bergmann and Andrew Lunn > > Changes from v1: > 1 Merged RVU admin function and CGX drivers into a single module > - Suggested by Arnd Bergmann > 2 Pulled mbox communication APIs into a separate module to remove > admin function driver dependency in a VM where AF is not attached. > - Suggested by Arnd Bergmann > Hi Arnd, Didn't receive any feedback for the v3 patch series over a week's time. Can you please pick up these patches to merge into arm-soc ? Thanks, Sunil.
On Tue, Sep 11, 2018 at 2:37 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote: > > Didn't receive any feedback for the v3 patch series over a week's time. > Can you please pick up these patches to merge into arm-soc ? I would still prefer to see the whole thing as part of drivers/net/ instead of drivers/soc, and reviewed in full on the netdev side, including the parts that are not ethernet specific. Arnd
On Tue, Sep 11, 2018 at 7:07 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Tue, Sep 11, 2018 at 2:37 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote: > > > > Didn't receive any feedback for the v3 patch series over a week's time. > > Can you please pick up these patches to merge into arm-soc ? > > I would still prefer to see the whole thing as part of drivers/net/ > instead of drivers/soc, > and reviewed in full on the netdev side, including the parts that are > not ethernet specific. > > Arnd Hmm.. I agree that there are many networking terms used in the driver but it's not a networking driver, it's just a HW configuration driver which includes how HW should parse the packet. This driver doesn't fit into drivers/net. Let's say if netdev driver in drivers/net/ethernet doesn't make use of crypto feature then i guess netdev maintainers would reject any patches which configure crypto block. Also as i have been saying there are other scenarios as well. Future silicons may add support for other features into this resource virtualization unit's domain. An example would be compression. Any patches which do compression related HW configuration might be rejected by netdev maintainers, cause they are no way related to networking. I will keep netdev mailing list in all the patch submissions but moving this driver into drivers/net doesn't sound right, from it's functionality perspective. Thanks, Sunil.
On Tue, Sep 11, 2018 at 6:28 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote: > > On Tue, Sep 11, 2018 at 7:07 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > > On Tue, Sep 11, 2018 at 2:37 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote: > > > > > > Didn't receive any feedback for the v3 patch series over a week's time. > > > Can you please pick up these patches to merge into arm-soc ? > > > > I would still prefer to see the whole thing as part of drivers/net/ > > instead of drivers/soc, > > and reviewed in full on the netdev side, including the parts that are > > not ethernet specific. > > > > Arnd > > Hmm.. I agree that there are many networking terms used in the driver > but it's not a > networking driver, it's just a HW configuration driver which includes > how HW should > parse the packet. This driver doesn't fit into drivers/net. Who says it doesn't fit? > Let's say if netdev driver in drivers/net/ethernet doesn't make use of > crypto feature > then i guess netdev maintainers would reject any patches which configure crypto > block. Also as i have been saying there are other scenarios as well. > Future silicons may add support for other features into this resource > virtualization unit's domain. > An example would be compression. Any patches which do compression > related HW configuration > might be rejected by netdev maintainers, cause they are no way related > to networking. > > I will keep netdev mailing list in all the patch submissions but > moving this driver into drivers/net > doesn't sound right, from it's functionality perspective. Have you discussed this with the network maintainers? I agree that it's not a perfect fit, but IMHO it would be better to keep everything in one place than to split the code location into separate ddirectories for management, networking and crypto. If we find one place for it, then I think drivers/net/ethernet is the best since the purpose of that (combined) hardware is ultimately to interface with ethernet. If the network folks say they don't want it there, we can take the management bits into drivers/soc as you suggest. Arnd
From: Sunil Goutham <sgoutham@marvell.com> Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC supports multiple PCIe SRIOV physical functions (PFs) and virtual functions (VFs). PF0 is called administrative / admin function (AF) and has privilege access to registers to provision different RVU functional blocks to each of PF/VF. This admin function (AF) driver acts as a configuration / administrative software which provisions functional blocks to a PF/VF on demand for them to work as one of the following - A basic network controller (i.e NIC). - NIC with packet filtering, shaping and scheduling capabilities. - A crypto device. - A combination of above etc. PF/VFs communicate with admin function via a shared memory region. This patch series adds logic for the following - RVU AF driver with functional blocks provisioning support - Mailbox infrastructure for communication between AF and PFs. - CGX driver which provides information about physcial network interfaces which AF processes and forwards required info to PF/VF drivers. This is the first set of patches out of 70 odd patches. Note: This driver neither receives any data nor processes it i.e no I/O, just does the hardware configuration. Changes from v2: No changes, submitted again with netdev mailing list in loop. - Suggested by Arnd Bergmann and Andrew Lunn Changes from v1: 1 Merged RVU admin function and CGX drivers into a single module - Suggested by Arnd Bergmann 2 Pulled mbox communication APIs into a separate module to remove admin function driver dependency in a VM where AF is not attached. - Suggested by Arnd Bergmann Aleksey Makarov (2): soc: octeontx2: Add mailbox support infra soc: octeontx2: Convert mbox msg id check to a macro Geetha sowjanya (1): soc: octeontx2: Reconfig MSIX base with IOVA Linu Cherian (3): soc: octeontx2: Set RVU PFs to CGX LMACs mapping soc: octeontx2: Add support for CGX link management soc: octeontx2: Register for CGX lmac events Sunil Goutham (9): soc: octeontx2: Add Marvell OcteonTX2 RVU AF driver soc: octeontx2: Reset all RVU blocks soc: octeontx2: Gather RVU blocks HW info soc: octeontx2: Add mailbox IRQ and msg handlers soc: octeontx2: Scan blocks for LFs provisioned to PF/VF soc: octeontx2: Add RVU block LF provisioning support soc: octeontx2: Configure block LF's MSIX vector offset soc: octeontx2: Add Marvell OcteonTX2 CGX driver MAINTAINERS: Add entry for Marvell OcteonTX2 Admin Function driver MAINTAINERS | 10 + drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/marvell/Kconfig | 18 + drivers/soc/marvell/Makefile | 2 + drivers/soc/marvell/octeontx2/Makefile | 10 + drivers/soc/marvell/octeontx2/cgx.c | 517 +++++++++ drivers/soc/marvell/octeontx2/cgx.h | 65 ++ drivers/soc/marvell/octeontx2/cgx_fw_if.h | 225 ++++ drivers/soc/marvell/octeontx2/mbox.c | 303 +++++ drivers/soc/marvell/octeontx2/mbox.h | 211 ++++ drivers/soc/marvell/octeontx2/rvu.c | 1637 ++++++++++++++++++++++++++++ drivers/soc/marvell/octeontx2/rvu.h | 158 +++ drivers/soc/marvell/octeontx2/rvu_cgx.c | 194 ++++ drivers/soc/marvell/octeontx2/rvu_reg.h | 442 ++++++++ drivers/soc/marvell/octeontx2/rvu_struct.h | 78 ++ 16 files changed, 3872 insertions(+) create mode 100644 drivers/soc/marvell/Kconfig create mode 100644 drivers/soc/marvell/Makefile create mode 100644 drivers/soc/marvell/octeontx2/Makefile create mode 100644 drivers/soc/marvell/octeontx2/cgx.c create mode 100644 drivers/soc/marvell/octeontx2/cgx.h create mode 100644 drivers/soc/marvell/octeontx2/cgx_fw_if.h create mode 100644 drivers/soc/marvell/octeontx2/mbox.c create mode 100644 drivers/soc/marvell/octeontx2/mbox.h create mode 100644 drivers/soc/marvell/octeontx2/rvu.c create mode 100644 drivers/soc/marvell/octeontx2/rvu.h create mode 100644 drivers/soc/marvell/octeontx2/rvu_cgx.c create mode 100644 drivers/soc/marvell/octeontx2/rvu_reg.h create mode 100644 drivers/soc/marvell/octeontx2/rvu_struct.h