> Problem here is that from Documentation falling edge can be set only on > PAD0. PAD5 and PAD6 have the related bit reserved. Meaning in future, they could be used for this, if those ports get support for SGMII. > But anyway qca8k support only single sgmii and it's not supported a > config with multiple sgmii. Yet, until such hardware appears. We do see more support for SFPs. And more support for multi-gigi ports. Both of which use a SERDES interface which can support SGMII. So i would not be too surprised if future versions of the switch have more ports like this. > Do we have standard binding for this? No, there is no standard binding for this. This seems specific to these devices, maybe a proprietary extension to SGMII? > About the mac swap. Do we really need to implement a complex thing for > something that is really implemented internally to the switch? If it was truly internal to the switch, no. But i don't think it is. The DSA core has no idea the ports are swapped, and so i think will put the names on the wrong ports. Does devlink understand the ports are swapped? How about .ndo_get_phys_port_name? Will udev mix up the ports? The way you wanted to look in the other ports DT properties suggests it is not internal to the switch. I think to help my understanding, we need some examples of DTS files with and without the swap, where the properties are read from, what the interface names are, etc. > I will move the falling binding to the port DT node and move the > configuration to mac_config. Should I keep the > dedicated function to setup PAD0 swap or I can directly add the check in > the qca8k_setup for only the bit related to enable the swap? That does not matter too much. DT is an ABI, we should not change it later, so we need to look forward. C code is not ABI, it can be changed if/when more SGMII ports actually arrive. Andrew
