RE: [PATCH 1/1] net/ncsi: add get MAC address command to get Intel i210 MAC address

On September 2, 2021, Ivan Mikhaylov wrote:

On Thu, 2021-09-02 at 05:48 +0000, Milton Miller II wrote:

quoted

On August 30, 2021, Ivan Mikhaylov" [off-list ref] wrote:

quoted

This patch adds OEM Intel GMA command and response handler for

it.

quoted

quoted

/* Get Link Status */
struct ncsi_rsp_gls_pkt {
        struct ncsi_rsp_pkt_hdr rsp;        /* Response header

*/

quoted

quoted

diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index d48374894817..6447a09932f5 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c

@@ -699,9 +699,51 @@ static int ncsi_rsp_handler_oem_bcm(struct

ncsi_request *nr)
        return 0;
}

+/* Response handler for Intel command Get Mac Address */
+static int ncsi_rsp_handler_oem_intel_gma(struct ncsi_request

*nr)

quoted

quoted

+{
+       struct ncsi_dev_priv *ndp = nr->ndp;
+       struct net_device *ndev = ndp->ndev.dev;
+       const struct net_device_ops *ops = ndev->netdev_ops;
+       struct ncsi_rsp_oem_pkt *rsp;
+       struct sockaddr saddr;
+       int ret = 0;
+
+       /* Get the response header */
+       rsp = (struct ncsi_rsp_oem_pkt

*)skb_network_header(nr->rsp);

quoted

quoted

+
+       saddr.sa_family = ndev->type;
+       ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+       memcpy(saddr.sa_data, &rsp->data[INTEL_MAC_ADDR_OFFSET],

ETH_ALEN);

quoted

quoted

+       /* Increase mac address by 1 for BMC's address */
+       eth_addr_inc((u8 *)saddr.sa_data);
+       if (!is_valid_ether_addr((const u8 *)saddr.sa_data))
+               return -ENXIO;

The Intel GMA retireves the MAC address of the host, and the

datasheet

quoted

anticipates the BMC will "share" the MAC by stealing specific TCP

and 

quoted

UDP port traffic destined to the host.

This "add one" allocation of the MAC is therefore a policy, and one

that 

quoted

is beyond the data sheet.

While this +1 policy may work for some OEM boards, there are other

boards 

quoted

where the MAC address assigned to the BMC does not follow this

pattern, 

quoted

but instead the MAC is stored in some platform dependent location

obtained 

quoted

in a platform specific manner.

I suggest this BMC = ether_addr_inc(GMA) be opt in via a device

tree

quoted

property.  

as it appears it would be generic to more than one vendor.

Unfortunately, we missed this when we added the broadcom and

mellanox

quoted

handlers.

Milton,

maybe something like "mac_addr_inc" or "ncsi,mac_addr_inc"? Also
those 3(intel,
mellanox, broadcom) functions even with handlers similar to each
other, they
could be unified on idea, difference in addresses, payload lengths,
ids only as
I see. Joel proposed in the past about dts option for Intel OEM
keep_phy option,
maybe that's the right time to reorganize all OEM related parts to
fit in one
direction with dts options for ethernet interface without Kconfig
options?

I was hopping to get some feed back from device tree maintainers. 
I hope we can get something decided before we have to ask for a 
revert.  

Since the existing properties are mac-address and local-mac-address, 
I feel the new property should build upon the former like the later.  
I think the most general would be to have an offset that could be 
positive or negative.  I don't think we necessarily need the full 
range of address offset as I expect the upper bytes would be remain 
the assigned block but maybe some would want a large offset in the 
administrativly set address space?  or buy 2 ranges and assign one 
from each?

Anyways, I propose one of

mac-address-host-offset
host-mac-address-offset

how do we make it clear its the offset from the host to the BMC not 
from the BMC to the host?   Is the description in the binding enough?

Do we need more than 3 bytes offset?  How should we represent a 
decrement vs an increment?  sign extend a u32?  two cells for u64?
treat the first byte as add or subtract and the rest the offset?  Do 
we need a separate property name to subtract?

My system stores the MAC for the BMC elsewhere but we need a 
way to opt out of using an offset from the host, hence the need of
at least some property to opt in.





Some background for Rob (and others):

DTMF spec DSP0222 NC-SI (network controller sideband interface)
is a method to provide a BMC (Baseboard management controller) shared
access to an external ethernet port for comunication to the management
network in the outside world.  The protocol describes ethernet packets 
that control selective bridging implemented in a host network controller
to share its phy.  Various NIC OEMs have added a query to find out the 
address the host is using, and some vendors have added code to query host
nic and set the BMC mac to a fixed offset (current hard coded +1 from
the host value).  If this is compiled in the kernel, the NIC OEM is 
recognised and the BMC doesn't miss the NIC response the address is set
once each time the NCSI stack reinitializes.  This mechanism overrides
any mac-address or local-mac-address or other assignment.

DSP0222 https://www.dmtf.org/documents/pmci/network-controller-sideband-interface-nc-si-specification-110

milton