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.
On Mon, Dec 11, 2023 at 12:53:56AM +0300, Ivan Mikhaylov wrote:
>
> 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?
I agree that both of your recommendations might make the code better,
but I don't see why we would need to revert it. The code does the
intended function for many use cases, even if you've identified a few
where calling `dev_set_mac_address` would be better.
Either you or I can send a "Fixes: " on this commit to improve the
handling as you're proposing. While the change is likely trivial, I
have not had any chance to test it yet, so I've not sent it up myself.
If you want to refactor the code to reduce duplication, I think that should
be an entirely separate proposal.
--
Patrick Williams
On Sun, 10 Dec 2023 20:50:56 -0600 Patrick Williams wrote:
> Either you or I can send a "Fixes: " on this commit to improve the
> handling as you're proposing. While the change is likely trivial, I
> have not had any chance to test it yet, so I've not sent it up myself.
> If you want to refactor the code to reduce duplication, I think that should
> be an entirely separate proposal.
Yes, incremental change is better.