linux-kernel - Re: [PATCH 4.9 181/310] net: phy: micrel: Restore led_mode and clk

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: <1524154267.17017.15.camel@nxp.com>
Date:   Thu, 19 Apr 2018 19:11:07 +0300
From:   Leonard Crestez <leonard.crestez@....com>
To:     Naresh Kamboju <naresh.kamboju@...aro.org>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     open list <linux-kernel@...r.kernel.org>,
        linux- stable <stable@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Sasha Levin <alexander.levin@...rosoft.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 4.9 181/310] net: phy: micrel: Restore led_mode and
 clk_sel on resume

On Thu, 2018-04-19 at 17:02 +0530, Naresh Kamboju wrote:
> On 12 April 2018 at 00:05, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > 
> > 4.9-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Leonard Crestez <leonard.crestez@....com>
> > 
> > [ Upstream commit 79e498a9c7da0737829ff864aae44df434105676 ]
> > 
> > These bits seem to be lost after a suspend/resume cycle so just set them
> > again. Do this by splitting the handling of these bits into a function
> > that is also called on resume.
> > 
> > This patch fixes ethernet suspend/resume on imx6ul-14x14-evk boards.
> > 
> > Signed-off-by: Leonard Crestez <leonard.crestez@....com>
> > Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
> > Signed-off-by: David S. Miller <davem@...emloft.net>
> > Signed-off-by: Sasha Levin <alexander.levin@...rosoft.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > ---
> >  drivers/net/phy/micrel.c |   42 ++++++++++++++++++++++++++++--------------
> >  1 file changed, 28 insertions(+), 14 deletions(-)

> arm32 x15 device booting 4.9 kernel shows kernel warning and
> the network is not working on the device.
> 
> Linux version 4.9.95-rc1 (buildslave@...t-01) (gcc version 6.2.1 20161016
>  (Linaro GCC 6.2-2016.11) ) #1 SMP Tue Apr 17 19:12:22 UTC 2018
> 
> Boot log kernel crash log:
> --------------------------
> [   13.766589] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   13.805441] net eth0: initializing cpsw version 1.15 (0)
> [   13.930334] Unable to handle kernel NULL pointer dereference at
> virtual address 00000008
> [   13.982009] PC is at kszphy_config_reset+0x1c/0x150
> [   13.986909] LR is at kszphy_resume+0x24/0x64
> LAVA job id: https://lkft.validation.linaro.org/scheduler/job/187429#L3341

Looking at this dump I'm guessing that phydev->priv is NULL at the
start of kszphy_config_reset and this really shouldn't be happening.

The phydev->priv field is initialized by kszphy_probe but your
particular phy (KSZ9031) in linux-4.9.y does not seem to have .probe =
kszphy_probe assigned in the struct phy_driver ksphy_driver array.

In upstream this was added by commit bfe72442578b ("net: phy: micrel:
fix crash when statistic requested for KSZ9031 phy"). The message for
that patch claims to fix a kernel crash on this command:

    ethtool --phy-statistics eth0

Looking at the code this issue should affect linux-4.9.y on your board.
Naresh: can you please check?

Commit bfe72442578b was not tagged or selected for stable but it seems
to be a more serious issue.

BTW, the original patch was 2nd of a series, actually making imx6ul-
4x14-evk correctly suspend/resume ethernet in linux-4.9.y also requires
1st commit e6f4292ae0a1 ("ARM: dts: imx6ul-14x14-evk: Add ksz8081 phy
properties"). But this is not a terribly important fix.

--
Regards,
Leonard