linux-kernel - RE: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC LAN8710/20

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] [day] [month] [year] [list]
Message-ID: <AM4PR0401MB226064E6CF5943716C8D8E05FF220@AM4PR0401MB2260.eurprd04.prod.outlook.com>
Date:   Mon, 20 Nov 2017 13:43:56 +0000
From:   Andy Duan <fugang.duan@....com>
To:     Richard Leitner <richard.leitner@...data.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "andrew@...n.ch" <andrew@...n.ch>
CC:     Richard Leitner <dev@...l1n.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Subject: RE: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC
 LAN8710/20

From: Richard Leitner <richard.leitner@...data.com> Sent: Monday, November 20, 2017 8:55 PM
>On 11/20/2017 11:35 AM, Andy Duan wrote:
>> From: Richard Leitner <richard.leitner@...data.com> Sent: Monday,
>> November 20, 2017 5:57 PM
>>> To: Andy Duan <fugang.duan@....com>; f.fainelli@...il.com;
>>> andrew@...n.ch
>>> Cc: Richard Leitner <dev@...l1n.net>; netdev@...r.kernel.org; linux-
>>> kernel@...r.kernel.org
>>> Subject: Re: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for
>>> SMSC
>>> LAN8710/20
>>>
>>>
>>> On 11/20/2017 10:47 AM, Andy Duan wrote:
>>>> From: Richard Leitner <dev@...l1n.net> Sent: Monday, November 20,
>>>> 2017
>>>> 4:34 PM
>>>>> To: f.fainelli@...il.com; Andy Duan <fugang.duan@....com>;
>>>>> andrew@...n.ch
>>>>> Cc: netdev@...r.kernel.org; linux-kernel@...r.kernel.org;
>>>>> richard.leitner@...data.com
>>>>> Subject: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for
>>>>> SMSC
>>>>> LAN8710/20
>>>>>
>>>>> From: Richard Leitner <richard.leitner@...data.com>
>>>>>
>>>>> Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow
>>>>> turning the refclk on and off again during operation (according to
>>>>> their
>>> datasheet).
>>>>> Nonetheless exactly this behaviour was introduced for power saving
>>>>> reasons by commit e8fcfcd5684a ("net: fec: optimize the clock
>>>>> management to save power").
>>>>> Therefore after enabling the refclk we detect if an affected PHY is
>>>>> attached. If so reset and initialize it again.
>>> ...
>>>
>>>>> +static int fec_enet_clk_ref_enable_reset_phy_quirk(struct
>>>>> +net_device
>>>>> +*ndev) {
>>>>> +	struct phy_device *phy_dev = ndev->phydev;
>>>>> +	u32 real_phy_id;
>>>>> +	int ret;
>>>>> +
>>>>> +	/* some PHYs need a reset after the refclk was enabled, so we
>>>>> +	 * reset them here
>>>>> +	 */
>>>>> +	if (!phy_dev)
>>>>> +		return 0;
>>>>> +	if (!phy_dev->drv)
>>>>> +		return 0;
>>>>> +	real_phy_id = phy_dev->drv->phy_id & phy_dev->drv->phy_id_mask;
>>>>> +	switch (real_phy_id) {
>>>>> +	case 0x0007c0f0: /* SMSC LAN8710/LAN8720 */
>>>> Don't hard code here...
>>>> I believe there have many other phys also do such operation,
>>>> hardcode is
>>> unacceptable...
>>>> And these code can be put into phy_device.c as common interface.
>>> Ok. Thank you for the feedback.
>>> So it would be fine to hardcode the affected phy_id's in a common
>>> function in phy_device.c?
>>>
>>>
>>> Another possible solution that came to my mind is to add a flag
>>> called something like "PHY_RST_AFTER_CLK_EN" to the flags variable in
>>> struct phy_driver. This flag could then be set in the smsc PHY driver
>>> for affected PHYs.
>>>
>>> Then instead of comparing the phy_id in the MAC driver this flag
>>> could be
>>> checked:
>>>
>>> if (phydev->drv->flags & PHY_RST_AFTER_CLK_EN) {
>>>    ret = fec_reset_phy(ndev);
>>>    ...
>>> }
>>>
>>> Would checking the flag be OK in fec_main.c?
>> Yes, it is better than previous solution.
>> But add new common API in phy_device.c is much better like:
>> 1. add a flag called "PHY_RST_AFTER_CLK_EN" to the flags variable in struct
>phy_driver,  all phy driver that need reset can set the flag.
>
>OK.
>
>> 2. add new common api interface phy_reset_after_clk_enable() in
>> phy_device.c driver
>
>OK. But see below...
>
>> 3. add reset gpio descriptor for common phy device driver.
>
>... if I understood it correctly the patch called "Teach phylib hard-resetting
>devices" by Geert and Sergei is exactly doing this:
>	https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F
>%2Fpatchwork.ozlabs.org%2Fcover%2F828503%2F&data=02%7C01%7Cfugang
>.duan%40nxp.com%7C087010d8b4784e3c88c608d53015f2ad%7C686ea1d3bc2
>b4c6fa92cd99c5c301635%7C0%7C0%7C636467793180108636&sdata=yY9thX8Q
>CCVteoF5vvUoAYYxGH0gg4wOUq7TQKtkiok%3D&reserved=0
>	https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F
>%2Flkml.org%2Flkml%2F2017%2F10%2F20%2F166&data=02%7C01%7Cfugang.
>duan%40nxp.com%7C087010d8b4784e3c88c608d53015f2ad%7C686ea1d3bc2b
>4c6fa92cd99c5c301635%7C0%7C0%7C636467793180108636&sdata=rxV12dum1
>VmbWLWvSACDuZevFSFbUoWr9AiUtVSsV6w%3D&reserved=0
>
>So I'll implement the phy_reset_after_clk_enable function atop of this patch-
>set and add a note that my patch-series depends on it. Would that be OK?
>
Yes, it is the best solution.

>> 4. then any mac driver can directly call the common
>interface .phy_reset_after_clk_enable().
>
>Sounds reasonable :-)
>
>>
>> That is only my suggestion, maybe there have better idea.
>> Thanks.
>>
>
>Thanks for your quick feedback.
>
>regards
>Richard.L