netdev - Re: [PATCH v2 00/13] ftgmac100: Rework batch 1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 Apr 2017 12:46:30 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        netdev@...r.kernel.org
Subject: Re: [PATCH v2 00/13] ftgmac100: Rework batch 1 - Link & Interrupts



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