[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231210215356.4154-1-fr0st61te@gmail.com>
Date: Mon, 11 Dec 2023 00:53:56 +0300
From: Ivan Mikhaylov <fr0st61te@...il.com>
To: patrick@...cx.xyz
Cc: davem@...emloft.net,
edumazet@...gle.com,
kuba@...nel.org,
linux-kernel@...r.kernel.org,
netdev@...r.kernel.org,
pabeni@...hat.com,
peter@....dev,
sam@...dozajonas.com
Subject: Re: [PATCH net-next v2 3/3] net/ncsi: Add NC-SI 1.2 Get MC MAC Address command
Patrick, Peter,
> +static int ncsi_rsp_handler_gmcma(struct ncsi_request *nr)
> +{
> + struct ncsi_dev_priv *ndp = nr->ndp;
> + struct net_device *ndev = ndp->ndev.dev;
> + struct ncsi_rsp_gmcma_pkt *rsp;
> + struct sockaddr saddr;
> + int ret = -1;
> + int i;
> +
> + rsp = (struct ncsi_rsp_gmcma_pkt *)skb_network_header(nr->rsp);
> + saddr.sa_family = ndev->type;
> + ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
> +
> + netdev_info(ndev, "NCSI: Received %d provisioned MAC addresses\n",
> + rsp->address_count);
> + for (i = 0; i < rsp->address_count; i++) {
> + netdev_info(ndev, "NCSI: MAC address %d: %02x:%02x:%02x:%02x:%02x:%02x\n",
> + i, rsp->addresses[i][0], rsp->addresses[i][1],
> + rsp->addresses[i][2], rsp->addresses[i][3],
> + rsp->addresses[i][4], rsp->addresses[i][5]);
> + }
> +
> + for (i = 0; i < rsp->address_count; i++) {
> + memcpy(saddr.sa_data, &rsp->addresses[i], ETH_ALEN);
> + ret = ndev->netdev_ops->ndo_set_mac_address(ndev, &saddr);
> + if (ret < 0) {
> + netdev_warn(ndev, "NCSI: Unable to assign %pM to device\n",
> + saddr.sa_data);
> + continue;
> + }
> + netdev_warn(ndev, "NCSI: Set MAC address to %pM\n", saddr.sa_data);
> + break;
> + }
> +
> + ndp->gma_flag = ret == 0;
> + return ret;
> +}
seems very similar to ncsi_rsp_handler_oem_gma except address_count, why it
shouldn't be part of this call with additional param? What's inside it just
code duplicity of ncsi_rsp_handler_oem_gma.
And as we talked in openbmc mailing list, ndo_set_mac_address do not notify
network layer about mac change and this fixed part already in
ncsi_rsp_handler_oem_gma with 790071347a0a1a89e618eedcd51c687ea783aeb3 .
David, any actions should be needed about fixing it in net-next? Need it to
put patch above with fix or do the revert from net-next and make it right?
Thanks.
Powered by blists - more mailing lists