From: Jakub Kicinski <kuba@kernel.org>
To: Shinas Rasheed <srasheed@marvell.com>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<hgani@marvell.com>, <sedara@marvell.com>, <vimleshk@marvell.com>,
<thaller@redhat.com>, <wizhao@redhat.com>, <kheib@redhat.com>,
<egallen@redhat.com>, <konguyen@redhat.com>, <horms@kernel.org>,
<einstein.xue@synaxg.com>,
Veerasenareddy Burru <vburru@marvell.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH net-next v2] octeon_ep: add ndo ops for VFs in PF driver
Date: Thu, 14 Nov 2024 19:16:48 -0800 [thread overview]
Message-ID: <20241114191648.34410e79@kernel.org> (raw)
In-Reply-To: <20241112185432.1152541-1-srasheed@marvell.com>
On Tue, 12 Nov 2024 10:54:31 -0800 Shinas Rasheed wrote:
> These APIs are needed to support applications that use netlink to get VF
> information from a PF driver.
>
> Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
> +static int octep_get_vf_config(struct net_device *dev, int vf, struct ifla_vf_info *ivi)
Please don't go over 80 chars for no good reason.
use checkpatch with --strict --max-line-length=80
> +{
> + struct octep_device *oct = netdev_priv(dev);
> +
> + ivi->vf = vf;
> + ether_addr_copy(ivi->mac, oct->vf_info[vf].mac_addr);
> + ivi->vlan = 0;
> + ivi->qos = 0;
no need to clear these fields
> + ivi->spoofchk = 0;
> + ivi->linkstate = IFLA_VF_LINK_STATE_ENABLE;
> + ivi->trusted = true;
so you set spoofchk to 0 and trusted to true, indicating no
enforcement [1]
> + ivi->max_tx_rate = 10000;
> + ivi->min_tx_rate = 0;
Why are you setting max rate to a fixed value?
> +
> + return 0;
> +}
> +
> +static int octep_set_vf_mac(struct net_device *dev, int vf, u8 *mac)
> +{
> + struct octep_device *oct = netdev_priv(dev);
> + int err;
> +
> + if (!is_valid_ether_addr(mac)) {
> + dev_err(&oct->pdev->dev, "Invalid MAC Address %pM\n", mac);
> + return -EADDRNOTAVAIL;
> + }
> +
> + dev_dbg(&oct->pdev->dev, "set vf-%d mac to %pM\n", vf, mac);
> + ether_addr_copy(oct->vf_info[vf].mac_addr, mac);
> + oct->vf_info[vf].flags |= OCTEON_PFVF_FLAG_MAC_SET_BY_PF;
double space
> +
> + err = octep_ctrl_net_set_mac_addr(oct, vf, mac, true);
> + if (err)
> + dev_err(&oct->pdev->dev, "Set VF%d MAC address failed via host control Mbox\n", vf);
> +
> + return err;
> +}
> +
> static const struct net_device_ops octep_netdev_ops = {
> .ndo_open = octep_open,
> .ndo_stop = octep_stop,
> @@ -1146,6 +1184,9 @@ static const struct net_device_ops octep_netdev_ops = {
> .ndo_set_mac_address = octep_set_mac,
> .ndo_change_mtu = octep_change_mtu,
> .ndo_set_features = octep_set_features,
> + /* for VFs */
what does this comment achieve?
> + .ndo_get_vf_config = octep_get_vf_config,
> + .ndo_set_vf_mac = octep_set_vf_mac
> };
>
> /**
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_main.h b/drivers/net/ethernet/marvell/octeon_ep/octep_main.h
> index fee59e0e0138..3b56916af468 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 flags;
the flags are u32 [2]
> u32 mbox_version;
> };
>
> 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 e6eb98d70f3c..26db2d34d1c0 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> @@ -156,12 +156,23 @@ static void octep_pfvf_set_mac_addr(struct octep_device *oct, u32 vf_id,
> {
> int err;
>
> + if (oct->vf_info[vf_id].flags & OCTEON_PFVF_FLAG_MAC_SET_BY_PF) {
> + dev_err(&oct->pdev->dev,
> + "VF%d attempted to override administrative set MAC address\n",
> + vf_id);
> + rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_NACK;
> + return;
> + }
[1] and yet you reject VF side changes. So is there enforcement or not?
:S
> err = octep_ctrl_net_set_mac_addr(oct, vf_id, cmd.s_set_mac.mac_addr, true);
> if (err) {
> rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_NACK;
> - dev_err(&oct->pdev->dev, "Set VF MAC address failed via host control Mbox\n");
> + dev_err(&oct->pdev->dev, "Set VF%d MAC address failed via host control Mbox\n",
> + vf_id);
> return;
> }
> +
> + ether_addr_copy(oct->vf_info[vf_id].mac_addr, cmd.s_set_mac.mac_addr);
> rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> }
>
> @@ -171,10 +182,17 @@ static void octep_pfvf_get_mac_addr(struct octep_device *oct, u32 vf_id,
> {
> int err;
>
> + if (oct->vf_info[vf_id].flags & OCTEON_PFVF_FLAG_MAC_SET_BY_PF) {
> + dev_dbg(&oct->pdev->dev, "VF%d MAC address set by PF\n", vf_id);
> + ether_addr_copy(rsp->s_set_mac.mac_addr, oct->vf_info[vf_id].mac_addr);
> + rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> + return;
> + }
> err = octep_ctrl_net_get_mac_addr(oct, vf_id, rsp->s_set_mac.mac_addr);
> if (err) {
> rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_NACK;
> - dev_err(&oct->pdev->dev, "Get VF MAC address failed via host control Mbox\n");
> + dev_err(&oct->pdev->dev, "Get VF%d MAC address failed via host control Mbox\n",
> + vf_id);
> return;
> }
> rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> 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 0dc6eead292a..339977c7131a 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.h
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.h
> @@ -23,6 +23,9 @@ enum octep_pfvf_mbox_version {
>
> #define OCTEP_PFVF_MBOX_VERSION_CURRENT OCTEP_PFVF_MBOX_VERSION_V2
>
> +/* VF flags */
> +#define OCTEON_PFVF_FLAG_MAC_SET_BY_PF BIT_ULL(0) /* PF has set VF MAC address */
[2] but the bit definition uses ULL ?
> enum octep_pfvf_mbox_opcode {
> OCTEP_PFVF_MBOX_CMD_VERSION,
> OCTEP_PFVF_MBOX_CMD_SET_MTU,
--
pw-bot: cr
next prev parent reply other threads:[~2024-11-15 3:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 18:54 [PATCH net-next v2] octeon_ep: add ndo ops for VFs in PF driver Shinas Rasheed
2024-11-13 3:50 ` Kalesh Anakkur Purayil
2024-11-13 13:46 ` Simon Horman
2024-11-15 3:16 ` Jakub Kicinski [this message]
2024-11-16 17:21 ` [EXTERNAL] " 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=20241114191648.34410e79@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=egallen@redhat.com \
--cc=einstein.xue@synaxg.com \
--cc=hgani@marvell.com \
--cc=horms@kernel.org \
--cc=kheib@redhat.com \
--cc=konguyen@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sedara@marvell.com \
--cc=srasheed@marvell.com \
--cc=thaller@redhat.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 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.