> > CM3 won't use this interface till ethtool priv flag was set, it can be done > > by > communication over CM3 SRAM memory. > > > > > How does CM3 know the status of the link? > > > > CM3 has access to MAC registers and can read port status bit. > > > > > How does CM3 set its > > > flow control depending on what auto-neg determines, etc? > > > > Same as PPv2 Packet Processor RX and TX flow don't really care about auto- > neg, flow control, etc. > > CM3 can ignore it, all this stuff handled in MAC layer. CM3 just polling RX > descriptor ring and using TX ring for transmit. > > > > > > > > > 3. In some cases we need to dynamically switch the port "user" > > > > between CM3 and kernel. So I would like to preserve this > > > > functionality. > > > > > > And how do you synchronize between Linux and CM3 so you know how > is > > > using it and who cannot use it? > > > > > > Andrew > > > > I can add CM3 SRAM update into ethtool priv flag callback, so CM3 won't > use port till it was reserved to CM3. > > I really think you need to step back here and look at the bigger picture. If > linux should not use the interface, it should not exist. If it does not > exist, you > cannot use ethtool on it. > > What you might want to consider is adding remoteproc support between > Linux on the main processor and whatever you have on the CM3. You can > use RPMsg to send requests back and forth between Linux and the CM3. It > can request that the shared parts of the packet processor are set up for it. > Linux can tell it when the link comes up? It can request how the PHY auto- > neg should be configured. > > Andrew
I would check this option. Thanks, Stefan.
