Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3386054imm; Sun, 14 Oct 2018 19:09:37 -0700 (PDT) X-Google-Smtp-Source: ACcGV63nqW2CZtX6RvMyEAmDocGUIpPS3/xqIH/xLccxCjhQA7bbx4m2YMhTFmMb4vfwtvp3QCAu X-Received: by 2002:a63:d917:: with SMTP id r23-v6mr14528296pgg.0.1539569377904; Sun, 14 Oct 2018 19:09:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539569377; cv=none; d=google.com; s=arc-20160816; b=lD/FQeNTHgDRfp2ltuKaI1gT/320eUL+yzLiCdtwCR+2gRFSHpCJuUBTSYz3gvFLvJ eAlEgWGjDUwtYAA7aqL/c9AUtu7a/duNvGk9cBuGeNC65VIJo3NPFgKdunnH6vQEDc/1 gxJYDG7Bbf7nFptG3Bv7VgBBZ+Zxbg/DxR7TWHFggpWKUGHXn/ixXOqLBYHY15b4rE9G IpK1bIp6QHSfHXdMzHwf6iEnF0WRtne1pnU1XmdO6u6u66Fw4vPSea2QyW3tExEzY42v 4wCOu2UpW1RBQ656/Q0JlzJR0D7e5nMWI2rcVDROLy9OvnFHKZCgxDIPuLbqgjE9pmnx olUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature:dkim-signature; bh=sSLSi9K9Fj5PV5eH7SmuDNab5+W2ZA70HJWB8BjqOhc=; b=t5YjHTPJfec6oWYq35WQ51ramj+Ab/s0IR/1Ah322L3Nlt6HSkD5IX4WlXktbNegHd IO+rGo2ErYJ5sUspNEMHWEQn3Ax97S2NoMJe4AasnaKbGWgGbRKxOMRxqh9hNwPNbphW +5fvYt+U/sGMEs65gF8aGDoIAVSaGPat+Ep6cNBGVBWP+q+5rS1fVQU59Kbs0pX/f/lu XEumrkss2JoAKBE8tBt8uwKHes3TUwj8olacEPWbC06cK/70euba5/R7KtzUBmAk4PYQ /P6jwGJ4L0m0r1rG0ENotifn6/grPEhCB2kEK8fF9szqawb07+OnSUZdnbxrCLxVUV1E NHWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mendozajonas.com header.s=fm1 header.b=xaZgY2QD; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=unMpdg70; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t11-v6si8734118plq.280.2018.10.14.19.09.23; Sun, 14 Oct 2018 19:09:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@mendozajonas.com header.s=fm1 header.b=xaZgY2QD; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=unMpdg70; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726560AbeJOJv7 (ORCPT + 99 others); Mon, 15 Oct 2018 05:51:59 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:37999 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726098AbeJOJv7 (ORCPT ); Mon, 15 Oct 2018 05:51:59 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 37C7321F16; Sun, 14 Oct 2018 22:08:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 14 Oct 2018 22:08:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= mendozajonas.com; h=message-id:subject:from:to:cc:date :in-reply-to:references:content-type:mime-version :content-transfer-encoding; s=fm1; bh=sSLSi9K9Fj5PV5eH7SmuDNab5+ W2ZA70HJWB8BjqOhc=; b=xaZgY2QDF1rzuUogqFJgpMQoS8bCxqs31ytAb8dYgq Fr/I6fpLndOXlCVbRMi6HumiUAc/9aQDfbVphqYG8c60zH8fzU6RODujNfVt+Z1/ /7AmgUPAGcSbLy8g8QV1uuS2Rh4ST0OEEcrtJ8Zodjn8AOytjy2DQ9wj1Xnw5jPq 013rqbp311Rjzvng/prpzhZN9bCGQh2lYfj2rK9RUnLfGOGxAyVfD9dvaopdnaK3 gnHjZ1z3leoWn7IP79L++c90/dVfhZfQeJ2goycuqednBW/Su94mWW6uevDmvEaJ r9WVkmLa/q3U6lBmEpgMRqhMrSnJW6wwtJ/CywJXsnaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=sSLSi9K9Fj5PV5eH7SmuDNab5+W2ZA70HJWB8BjqO hc=; b=unMpdg70YeRQkFyrl2eUm78WXUyBtdK+2wc6SrFYEy7Kw2AvhpxrQNqcY DfH6fQ2alZ4TS7b4vGdqg69/SFoLzdN7WJOxRoPCTUljQV1lS3s+djjjhYpNVipG WV5nykx2Zmbee3ZLpMMa1F6jvmln2Gg++4DAcUPbk/u+kCOnHC6heuO5+Edb/L2D bna47vDNgX+6PQBdGiduzkBfnmJvKaKrqF/NS/cob5zt+OIPGux3oAdNwMJHR2Gn vLsHvypH6DtM5xpIzDtctOUDT8hmjWUzB3LpP3TpvQRI+BQEDTITVwCglxOZ7kfu man5w7WlJlX59S9HlcEzHXNwmngeQ== X-ME-Sender: X-ME-Proxy: Received: from v4 (unknown [122.99.82.10]) by mail.messagingengine.com (Postfix) with ESMTPA id 56DC4102DD; Sun, 14 Oct 2018 22:08:50 -0400 (EDT) Message-ID: <69cae9d44cbebb2cd4f468dc710d6a97210af835.camel@mendozajonas.com> Subject: Re: [PATCH net-next v4] net/ncsi: Add NCSI Broadcom OEM command From: Samuel Mendoza-Jonas To: Vijay Khemka , "David S. Miller" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: linux-aspeed@lists.ozlabs.org, openbmc@lists.ozlabs.org Date: Mon, 15 Oct 2018 13:08:46 +1100 In-Reply-To: <20181012182008.1665690-1-vijaykhemka@fb.com> References: <20181012182008.1665690-1-vijaykhemka@fb.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-10-12 at 11:20 -0700, Vijay Khemka wrote: > This patch adds OEM Broadcom commands and response handling. It also > defines OEM Get MAC Address handler to get and configure the device. > > ncsi_oem_gma_handler_bcm: This handler send NCSI broadcom command for > getting mac address. > ncsi_rsp_handler_oem_bcm: This handles response received for all > broadcom OEM commands. > ncsi_rsp_handler_oem_bcm_gma: This handles get mac address response and > set it to device. > > Signed-off-by: Vijay Khemka > --- > v4: updated as per comment from Sam, I was just wondering if I can remove > NCSI_OEM_CMD_GET_MAC config option and let this code be valid always and > it will configure mac address if there is get mac address handler for given > manufacture id. Hi Vijay, We can look at handling this a different way, but I don't think we want to unconditionally set the system's MAC address based on the OEM GMA command. If the user wants to set a custom MAC address, or in the case of OpenBMC for example who have their MAC address saved in flash, this will override that value with whatever the Network Controller has saved. In particular as it is set up it will override any MAC address every time a channel is configured, such as during a failover event. We *could* always send the GMA command if it is available and move the decision whether to use the resulting address or not into the response handler. That would simplify the ncsi_configure_channel() logic a bit. Another idea may be to have a Netlink command to tell NCSI to ignore the GMA result; then we could drop the config option and the system can safely change the address if desired. Any thoughts? I'll also ping some of the OpenBMC people and see what their expectations are. > +#if IS_ENABLED(CONFIG_NCSI_OEM_CMD_GET_MAC) > + > +/* NCSI OEM Command APIs */ > +static void ncsi_oem_gma_handler_bcm(struct ncsi_cmd_arg *nca) > +{ > + unsigned char data[NCSI_OEM_BCM_CMD_GMA_LEN]; > + int ret = 0; > + > + nca->payload = NCSI_OEM_BCM_CMD_GMA_LEN; > + > + memset(data, 0, NCSI_OEM_BCM_CMD_GMA_LEN); > + *(unsigned int *)data = ntohl(NCSI_OEM_MFR_BCM_ID); > + data[5] = NCSI_OEM_BCM_CMD_GMA; > + > + nca->data = data; > + > + ret = ncsi_xmit_cmd(nca); > + if (ret) > + netdev_err(nca->ndp->ndev.dev, > + "NCSI: Failed to transmit cmd 0x%x during configure\n", > + nca->type); > +} As a side note while unlikely we probably want to propagate the return value of ncsi_xmit_cmd() from here; otherwise we'll miss a failure and the configure process will stall. Regards, Sam