netdev - Re: [PATCH net-next 3/4] net: dsa: Plug in PHYLINK support

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:   Mon, 19 Mar 2018 11:11:27 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        privat@...l-hjelmeland.no, vivien.didelot@...oirfairelinux.com,
        davem@...emloft.net, sean.wang@...iatek.com,
        Woojung.Huh@...rochip.com, john@...ozen.org, cphealy@...il.com
Subject: Re: [PATCH net-next 3/4] net: dsa: Plug in PHYLINK support

On 03/19/2018 11:09 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 19, 2018 at 10:59:55AM -0700, Florian Fainelli wrote:
>> Hi Andrew,
>>
>> On 03/18/2018 12:19 PM, Andrew Lunn wrote:
>>>> +static int dsa_slave_nway_reset(struct net_device *dev)
>>>> +{
>>>> +	struct dsa_port *dp = dsa_slave_to_port(dev);
>>>> +
>>>> +	return phylink_ethtool_nway_reset(dp->pl);
>>>> +}
>>>
>>> Hi Florian
>>>
>>> I've seen in one of Russells trees a patch to put a phylink into
>>> net_device. That would make a generic slave_nway_reset() possible, and
>>> a few others as well. Maybe it makes sense to pull in that patch?
>>
>> To make this generic, we would have to have net_device carry a reference
>> to a phylink instance, which I would rather not do. Were you possibly
>> referring to this patch set:
>>
>> http://git.armlinux.org.uk/cgit/linux-arm.git/commit/?h=phy&id=4eda3b76573473d811bc80a6f0e5a2e06dd76bf6
>>
>> in which case I think it was discussed and rejected (that was my
>> recollection).
> 
> Unfortunately, that rejection kind'a prevents SFP support on a PHY,
> which is why I'm not pushing the 3310 patches (I don't have any other
> solution to this problem at the moment as PHYLIB gets in the way of
> knowing what state the network interface is in.)

I don't remember the basis on which this was rejected, and since then, I
had many sleepless nights which don't help with long term memory :) Can
you refresh the context?
-- 
Florian