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]
Message-ID: <4f331a7a-49bd-3f84-1437-ac42141abf18@gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ