From: Leon Romanovsky <leon@kernel.org>
To: sunil.kovvuri@gmail.com
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
Geetha sowjanya <gakula@marvell.com>,
Sunil Goutham <sgoutham@marvell.com>
Subject: Re: [PATCH v2 net-next 2/7] octeontx2-pf: Handle VF function level reset
Date: Fri, 13 Mar 2020 20:16:48 +0200 [thread overview]
Message-ID: <20200313181648.GD67638@unreal> (raw)
In-Reply-To: <1584092566-4793-3-git-send-email-sunil.kovvuri@gmail.com>
On Fri, Mar 13, 2020 at 03:12:41PM +0530, sunil.kovvuri@gmail.com wrote:
> From: Geetha sowjanya <gakula@marvell.com>
>
> When FLR is initiated for a VF (PCI function level reset),
> the parent PF gets a interrupt. PF then sends a message to
> admin function (AF), which then cleanups all resources attached
> to that VF.
>
> Also handled IRQs triggered when master enable bit is cleared
> or set for VFs. This handler just clears the transaction pending
> ie TRPEND bit.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
> ---
> .../ethernet/marvell/octeontx2/nic/otx2_common.h | 7 +
> .../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 234 ++++++++++++++++++++-
> 2 files changed, 240 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
> index 74439e1..c0a9693 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
> @@ -191,6 +191,11 @@ struct otx2_hw {
> u64 cgx_tx_stats[CGX_TX_STATS_COUNT];
> };
>
> +struct flr_work {
> + struct work_struct work;
> + struct otx2_nic *pf;
> +};
> +
> struct refill_work {
> struct delayed_work pool_refill_work;
> struct otx2_nic *pf;
> @@ -226,6 +231,8 @@ struct otx2_nic {
>
> u64 reset_count;
> struct work_struct reset_task;
> + struct workqueue_struct *flr_wq;
> + struct flr_work *flr_wrk;
> struct refill_work *refill_wrk;
>
> /* Ethtool stuff */
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> index 967ef7b..bf6e2529 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> @@ -61,6 +61,224 @@ static int otx2_change_mtu(struct net_device *netdev, int new_mtu)
> return err;
> }
>
> +static void otx2_disable_flr_me_intr(struct otx2_nic *pf)
> +{
> + int irq, vfs = pf->total_vfs;
> +
> + /* Disable VFs ME interrupts */
> + otx2_write64(pf, RVU_PF_VFME_INT_ENA_W1CX(0), INTR_MASK(vfs));
> + irq = pci_irq_vector(pf->pdev, RVU_PF_INT_VEC_VFME0);
> + free_irq(irq, pf);
> +
> + /* Disable VFs FLR interrupts */
> + otx2_write64(pf, RVU_PF_VFFLR_INT_ENA_W1CX(0), INTR_MASK(vfs));
> + irq = pci_irq_vector(pf->pdev, RVU_PF_INT_VEC_VFFLR0);
> + free_irq(irq, pf);
> +
> + if (vfs <= 64)
> + return;
> +
> + otx2_write64(pf, RVU_PF_VFME_INT_ENA_W1CX(1), INTR_MASK(vfs - 64));
> + irq = pci_irq_vector(pf->pdev, RVU_PF_INT_VEC_VFME1);
> + free_irq(irq, pf);
> +
> + otx2_write64(pf, RVU_PF_VFFLR_INT_ENA_W1CX(1), INTR_MASK(vfs - 64));
> + irq = pci_irq_vector(pf->pdev, RVU_PF_INT_VEC_VFFLR1);
> + free_irq(irq, pf);
> +}
> +
> +static void otx2_flr_wq_destroy(struct otx2_nic *pf)
> +{
> + if (!pf->flr_wq)
> + return;
> + flush_workqueue(pf->flr_wq);
> + destroy_workqueue(pf->flr_wq);
destroy_workqueue() calls to drain_workqueue() which calls to
flush_workqueue() in proper order and not like it is written here.
> + pf->flr_wq = NULL;
> + devm_kfree(pf->dev, pf->flr_wrk);
> +}
> +
> +static void otx2_flr_handler(struct work_struct *work)
> +{
> + struct flr_work *flrwork = container_of(work, struct flr_work, work);
> + struct otx2_nic *pf = flrwork->pf;
> + struct msg_req *req;
> + int vf, reg = 0;
> +
> + vf = flrwork - pf->flr_wrk;
> +
> + otx2_mbox_lock(&pf->mbox);
It is so bad that such function exists, it hides simple mutex_lock()
which is standard primitive.
Thanks
next prev parent reply other threads:[~2020-03-13 18:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-13 9:42 [PATCH v2 net-next 0/7] octeontx2-vf: Add network driver for virtual function sunil.kovvuri
2020-03-13 9:42 ` [PATCH v2 net-next 1/7] octeontx2-pf: Enable SRIOV and added VF mbox handling sunil.kovvuri
2020-03-13 9:42 ` [PATCH v2 net-next 2/7] octeontx2-pf: Handle VF function level reset sunil.kovvuri
2020-03-13 18:16 ` Leon Romanovsky [this message]
2020-03-14 15:42 ` Sunil Kovvuri
2020-03-13 9:42 ` [PATCH v2 net-next 3/7] octeontx2-vf: Virtual function driver support sunil.kovvuri
2020-03-13 18:11 ` Leon Romanovsky
2020-03-14 15:40 ` Sunil Kovvuri
2020-03-14 17:59 ` Leon Romanovsky
2020-03-14 19:12 ` Leon Romanovsky
2020-03-15 8:42 ` Andrew Lunn
2020-03-13 9:42 ` [PATCH v2 net-next 4/7] octeontx2-vf: Ethtool support sunil.kovvuri
2020-03-13 17:56 ` Leon Romanovsky
2020-03-14 15:42 ` Sunil Kovvuri
2020-03-13 9:42 ` [PATCH v2 net-next 5/7] octeontx2-vf: Link event notification support sunil.kovvuri
2020-03-13 9:42 ` [PATCH v2 net-next 6/7] octeontx2-pf: Cleanup all receive buffers in SG descriptor sunil.kovvuri
2020-03-13 9:42 ` [PATCH v2 net-next 7/7] octeontx2-af: Remove driver version and fix authorship sunil.kovvuri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200313181648.GD67638@unreal \
--to=leon@kernel.org \
--cc=davem@davemloft.net \
--cc=gakula@marvell.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sgoutham@marvell.com \
--cc=sunil.kovvuri@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.