I'm also using ftgmac100 on my platform, and I don't have plan to change this property.After giving it more thought, I'm thinking about adding ncsi dt nodeThis property seems to be specific to Faraday FTGMAC100. Are you going
with following structure (mac/ncsi similar to mac/mdio/phy):
&mac0 {
/* MAC properties... */
use-ncsi;
to make it more generic?
Got it. Thank you for the sharing, and let me think it over :-)ncsi {You should get Rob Herring involved. This is not really describing
/* ncsi level properties if any */
package@0 {
hardware, so it might get rejected by the device tree maintainer.
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?1) mac driver doesn't need to parse "mac-offset" stuff: theseDoes that mean the NCSA code puts the interface into promiscuous mode?
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.
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.
I don't have the answer yet, but will talk to NCSI expert and figure it out.
Thanks,
Tao