Message-ID: <OF8E108F72.39D22E89-ON00258765.001E46EB-00258765.00251157@ibm.com>
Date:   Tue, 5 Oct 2021 06:44:52 +0000
From:   "Milton Miller II" <miltonm@...ibm.com>
To:     "Ivan Mikhaylov" <i.mikhaylov@...ro.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        "Jakub Kicinski" <kuba@...nel.org>,
        "Samuel Mendoza-Jonas" <sam@...dozajonas.com>,
        "Brad Ho" <Brad_Ho@...enix.com>,
        "Paul Fertser" <fercerpav@...il.com>, <openbmc@...ts.ozlabs.org>,
        <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
        <devicetree@...r.kernel.org>,
        "Ricardo Del Pozo Gonzalez" <ricardopozo@...ibm.com>
Subject: 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:
>> On August 30, 2021, Ivan Mikhaylov" <i.mikhaylov@...ro.com> wrote:
>> > This patch adds OEM Intel GMA command and response handler for
>it.
>> > 
>> > /* Get Link Status */
>> > struct ncsi_rsp_gls_pkt {
>> >         struct ncsi_rsp_pkt_hdr rsp;        /* Response header
>*/
>> > 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)
>> > +{
>> > +       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);
>> > +
>> > +       saddr.sa_family = ndev->type;
>> > +       ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
>> > +       memcpy(saddr.sa_data, &rsp->data[INTEL_MAC_ADDR_OFFSET],
>ETH_ALEN);
>> > +       /* 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
>> anticipates the BMC will "share" the MAC by stealing specific TCP
>and 
>> UDP port traffic destined to the host.
>> 
>> This "add one" allocation of the MAC is therefore a policy, and one
>that 
>> is beyond the data sheet.
>> 
>> While this +1 policy may work for some OEM boards, there are other
>boards 
>> where the MAC address assigned to the BMC does not follow this
>pattern, 
>> but instead the MAC is stored in some platform dependent location
>obtained 
>> in a platform specific manner.
>> 
>> I suggest this BMC = ether_addr_inc(GMA) be opt in via a device
>tree
>> property.  
>> 
>> as it appears it would be generic to more than one vendor.
>> 
>> Unfortunately, we missed this when we added the broadcom and
>mellanox
>> 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

Powered by blists - more mailing lists