On 04/04/2017 11:31 PM, Benjamin Herrenschmidt wrote: > On Tue, 2017-04-04 at 23:02 -0700, Florian Fainelli wrote: > >> We don't necessarily have a phydev attached when using NC-SI, so it was >>> easier to have the core code path not have to go fishing for those >>> settings in different places based on whether we're using NC-SI or not. >> >> Oh right, I missed that part. Is there a reason why NC-SI does not have >> a PHY device attached? If not, could you somehow model the link using a >> fixed PHY (which appears to Linux as a normal phy_device) just to keep >> things simple. > > Hrm ... maybe another day if you don't mind ;-) > > First NC-SI isn't really a PHY .... it's a cross-over RMII connection > to another NIC. > > Now we could make it a phydev using a "fixed" PHY I suppose, that just > "represents" the other end. That would be a way to do it. It would need > to have the link permanently up however (see below). > > That said I do want to tackle making it some kind of pseudo-PHY that > actually reflects the state of the remote end (especially the link > state, ie. up/down). > > However there are a couple of issues to tackle if we do that. Well > mostly one annoying one: > > NC-SI needs to talk to the remote NIC via specific ethernet frames. > > With the current link watch code however, if we reflect the remote link > to the local NIC link via netif_carrier_on/off, we end up deactivating > the device on link off and thus preventing the NC-SI stack from talking > to the peer NIC at all. > > I thought a while ago we could add some dev flag to prevent the link > watch from doing that, but never got to look into it myself and > apparently neither did Gavin.
It sounds like a similar situation to e.g: 802.1x, you want to let some frames make it through and you need a working link for that, but you can't quite flag the device as UP entirely. Maybe you can find a way to re-use IFF_LOWER_UP to that purpose and only set that flag based on the NC-SI frames indicating link state? -- Florian
