mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "shenjian (K)" <shenjian15@huawei.com>
To: Shinas Rasheed <srasheed@marvell.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Cc: <hgani@marvell.com>, <vimleshk@marvell.com>, <egallen@redhat.com>,
	<mschmidt@redhat.com>, <pabeni@redhat.com>, <horms@kernel.org>,
	<kuba@kernel.org>, <davem@davemloft.net>, <wizhao@redhat.com>,
	<kheib@redhat.com>, <konguyen@redhat.com>,
	Veerasenareddy Burru <vburru@marvell.com>,
	Sathesh Edara <sedara@marvell.com>,
	Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH net-next v4 2/4] octeon_ep: PF-VF mailbox version support
Date: Thu, 14 Dec 2023 21:16:44 +0800	[thread overview]
Message-ID: <59426716-2f97-2f08-1d9f-84ce6483cfa9@huawei.com> (raw)
In-Reply-To: <20231213035816.2656851-3-srasheed@marvell.com>



在 2023/12/13 11:58, Shinas Rasheed 写道:
> Add PF-VF mailbox initial version support
>
> Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
> ---
> V4:
>    - No changes
>
> V3: https://lore.kernel.org/all/20231211063355.2630028-3-srasheed@marvell.com/
>    - No changes
>
> V2: https://lore.kernel.org/all/20231209081450.2613561-3-srasheed@marvell.com/
>    - No changes
>
> V1: https://lore.kernel.org/all/20231208070352.2606192-3-srasheed@marvell.com/
>
>   .../net/ethernet/marvell/octeon_ep/octep_main.h   |  1 +
>   .../ethernet/marvell/octeon_ep/octep_pfvf_mbox.c  | 15 ++++++++++++---
>   .../ethernet/marvell/octeon_ep/octep_pfvf_mbox.h  |  7 +++++--
>   3 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_main.h b/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
> index 3223bb6f95ea..fee59e0e0138 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
> @@ -220,6 +220,7 @@ struct octep_iface_link_info {
>   /* The Octeon VF device specific info data structure.*/
>   struct octep_pfvf_info {
>   	u8 mac_addr[ETH_ALEN];
> +	u32 mbox_version;
>   };
>   
>   /* The Octeon device specific private data structure.
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> index 43b40e91f7bf..baffe298a2a0 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> @@ -28,10 +28,18 @@ static void octep_pfvf_validate_version(struct octep_device *oct,  u32 vf_id,
>   {
>   	u32 vf_version = (u32)cmd.s_version.version;
>   
> -	if (vf_version <= OCTEP_PFVF_MBOX_VERSION_V1)
> -		rsp->s_version.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> +	dev_dbg(&oct->pdev->dev, "VF id:%d VF version:%d PF version:%d\n",
> +		vf_id, vf_version, OCTEP_PFVF_MBOX_VERSION_CURRENT);
> +	if (vf_version < OCTEP_PFVF_MBOX_VERSION_CURRENT)
> +		rsp->s_version.version = vf_version;
>   	else
> -		rsp->s_version.type = OCTEP_PFVF_MBOX_TYPE_RSP_NACK;
> +		rsp->s_version.version = OCTEP_PFVF_MBOX_VERSION_CURRENT;
> +
> +	oct->vf_info[vf_id].mbox_version = rsp->s_version.version;
> +	dev_dbg(&oct->pdev->dev, "VF id:%d negotiated VF version:%d\n",
> +		vf_id, oct->vf_info[vf_id].mbox_version);
> +
> +	rsp->s_version.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
>   }
>   
>   static void octep_pfvf_get_link_status(struct octep_device *oct, u32 vf_id,
> @@ -167,6 +175,7 @@ int octep_setup_pfvf_mbox(struct octep_device *oct)
>   			goto free_mbox;
>   
>   		memset(oct->mbox[ring], 0, sizeof(struct octep_mbox));
> +		memset(&oct->vf_info[i], 0, sizeof(struct octep_pfvf_info));
>   		mutex_init(&oct->mbox[ring]->lock);
>   		INIT_WORK(&oct->mbox[ring]->wk.work, octep_pfvf_mbox_work);
>   		oct->mbox[ring]->wk.ctxptr = oct->mbox[ring];
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.h b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.h
> index 34feeb559b0d..af4dcf5ef7f1 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.h
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.h
> @@ -13,11 +13,15 @@
>   #define OCTEON_SDP_16K_HW_FRS  16380UL
>   #define OCTEON_SDP_64K_HW_FRS  65531UL
>   
> +/* When a new command is implemented,PF Mbox version should be bumped.
> + */
>   enum octep_pfvf_mbox_version {
>   	OCTEP_PFVF_MBOX_VERSION_V0,
>   	OCTEP_PFVF_MBOX_VERSION_V1,
>   };
>   
> +#define OCTEP_PFVF_MBOX_VERSION_CURRENT	OCTEP_PFVF_MBOX_VERSION_V1
> +
>   enum octep_pfvf_mbox_opcode {
>   	OCTEP_PFVF_MBOX_CMD_VERSION,
>   	OCTEP_PFVF_MBOX_CMD_SET_MTU,
> @@ -30,7 +34,7 @@ enum octep_pfvf_mbox_opcode {
>   	OCTEP_PFVF_MBOX_CMD_GET_LINK_STATUS,
>   	OCTEP_PFVF_MBOX_CMD_GET_MTU,
>   	OCTEP_PFVF_MBOX_CMD_DEV_REMOVE,
> -	OCTEP_PFVF_MBOX_CMD_LAST,
> +	OCTEP_PFVF_MBOX_CMD_MAX,
>   };
This change is unrelative with
this enum is introduced in the first patch, why not directly rename it 
in the first one?

>   
>   enum octep_pfvf_mbox_word_type {
> @@ -79,7 +83,6 @@ enum octep_pfvf_link_autoneg {
>   
>   #define OCTEP_PFVF_MBOX_TIMEOUT_MS     500
>   #define OCTEP_PFVF_MBOX_MAX_RETRIES    2
> -#define OCTEP_PFVF_MBOX_VERSION        0
Similar here,  you introduce it in first patch, and no place used, then 
remove it int the second one.
Maybe you can reorganize this patchset ?

>   #define OCTEP_PFVF_MBOX_MAX_DATA_SIZE  6
>   #define OCTEP_PFVF_MBOX_MORE_FRAG_FLAG 1
>   #define OCTEP_PFVF_MBOX_WRITE_WAIT_TIME msecs_to_jiffies(1)


  reply	other threads:[~2023-12-14 13:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13  3:58 [PATCH net-next v4 0/4] add PF-VF mailbox support Shinas Rasheed
2023-12-13  3:58 ` [PATCH net-next v4 1/4] octeon_ep: add PF-VF mailbox communication Shinas Rasheed
2023-12-14 13:18   ` shenjian (K)
2023-12-13  3:58 ` [PATCH net-next v4 2/4] octeon_ep: PF-VF mailbox version support Shinas Rasheed
2023-12-14 13:16   ` shenjian (K) [this message]
2023-12-14 16:16     ` [EXT] " Shinas Rasheed
2023-12-13  3:58 ` [PATCH net-next v4 3/4] octeon_ep: control net framework to support VF offloads Shinas Rasheed
2023-12-13  3:58 ` [PATCH net-next v4 4/4] octeon_ep: support firmware notifications for VFs Shinas Rasheed

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=59426716-2f97-2f08-1d9f-84ce6483cfa9@huawei.com \
    --to=shenjian15@huawei.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=egallen@redhat.com \
    --cc=hgani@marvell.com \
    --cc=horms@kernel.org \
    --cc=kheib@redhat.com \
    --cc=konguyen@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mschmidt@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sedara@marvell.com \
    --cc=srasheed@marvell.com \
    --cc=vburru@marvell.com \
    --cc=vimleshk@marvell.com \
    --cc=wizhao@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®