On 8/8/19 4:03 PM, Andrew Lunn wrote: >> After giving it more thought, I'm thinking about adding ncsi dt node >> with following structure (mac/ncsi similar to mac/mdio/phy): >> >> &mac0 { >> /* MAC properties... */ >> >> use-ncsi; > > This property seems to be specific to Faraday FTGMAC100. Are you going > to make it more generic?
I'm also using ftgmac100 on my platform, and I don't have plan to change this property. >> ncsi { >> /* ncsi level properties if any */ >> >> package@0 { > > You should get Rob Herring involved. This is not really describing > hardware, so it might get rejected by the device tree maintainer. Got it. Thank you for the sharing, and let me think it over :-) >> 1) mac driver doesn't need to parse "mac-offset" stuff: these >> ncsi-network-controller specific settings should be parsed in ncsi >> stack. > >> 2) get_bmc_mac_address command is a channel specific command, and >> technically people can configure different offset/formula for >> different channels. > > Does that mean the NCSA code puts the interface into promiscuous mode? > Or at least adds these unicast MAC addresses to the MAC receive > filter? Humm, ftgmac100 only seems to support multicast address > filtering, not unicast filters, so it must be using promisc mode, if > you expect to receive frames using this MAC address. Uhh, I actually didn't think too much about this: basically it's how to configure frame filtering when there are multiple packages/channels active: single BMC MAC or multiple BMC MAC is also allowed? I don't have the answer yet, but will talk to NCSI expert and figure it out. Thanks, Tao