<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/phy/phy.c, branch linux-4.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-05-23T01:36:28Z</updated>
<entry>
<title>net: phy: avoid genphy_aneg_done() for PHYs without clause 22 support</title>
<updated>2018-05-23T01:36:28Z</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2017-06-05T11:22:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c04dda36ec57f95cac40444d3699d7eb2e6a4efd'/>
<id>urn:sha1:c04dda36ec57f95cac40444d3699d7eb2e6a4efd</id>
<content type='text'>
[ Upstream commit 41408ad519f7a2a1c5229e61f2a97f4df1b61adc ]

Avoid calling genphy_aneg_done() for PHYs that do not implement the
Clause 22 register set.

Clause 45 PHYs may implement the Clause 22 register set along with the
Clause 22 extension MMD.  Hence, we can't simply block access to the
Clause 22 functions based on the PHY being a Clause 45 PHY.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>net: phy: Correctly process PHY_HALTED in phy_stop_machine()</title>
<updated>2017-10-06T16:53:16Z</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2017-07-28T18:58:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ef0680a31df994e1d77b840f37772ff727cdc8ca'/>
<id>urn:sha1:ef0680a31df994e1d77b840f37772ff727cdc8ca</id>
<content type='text'>
[ Upstream commit 7ad813f208533cebfcc32d3d7474dc1677d1b09a ]

Marc reported that he was not getting the PHY library adjust_link()
callback function to run when calling phy_stop() + phy_disconnect()
which does not indeed happen because we set the state machine to
PHY_HALTED but we don't get to run it to process this state past that
point.

Fix this with a synchronous call to phy_state_machine() in order to have
the state machine actually act on PHY_HALTED, set the PHY device's link
down, turn the network device's carrier off and finally call the
adjust_link() function.

Reported-by: Marc Gonzalez &lt;marc_gonzalez@sigmadesigns.com&gt;
Fixes: a390d1f379cf ("phylib: convert state_queue work to delayed_work")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Marc Gonzalez &lt;marc_gonzalez@sigmadesigns.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"</title>
<updated>2017-10-04T01:36:49Z</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2017-08-31T00:49:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1204dc061e21ddfaabf08838b9dacd149daa98c2'/>
<id>urn:sha1:1204dc061e21ddfaabf08838b9dacd149daa98c2</id>
<content type='text'>
[ Upstream commit ebc8254aeae34226d0bc8fda309fd9790d4dccfe ]

This reverts commit 7ad813f208533cebfcc32d3d7474dc1677d1b09a ("net: phy:
Correctly process PHY_HALTED in phy_stop_machine()") because it is
creating the possibility for a NULL pointer dereference.

David Daney provide the following call trace and diagram of events:

When ndo_stop() is called we call:

 phy_disconnect()
    +---&gt; phy_stop_interrupts() implies: phydev-&gt;irq = PHY_POLL;
    +---&gt; phy_stop_machine()
    |      +---&gt; phy_state_machine()
    |              +----&gt; queue_delayed_work(): Work queued.
    +---&gt;phy_detach() implies: phydev-&gt;attached_dev = NULL;

Now at a later time the queued work does:

 phy_state_machine()
    +----&gt;netif_carrier_off(phydev-&gt;attached_dev): Oh no! It is NULL:

 CPU 12 Unable to handle kernel paging request at virtual address
0000000000000048, epc == ffffffff80de37ec, ra == ffffffff80c7c
Oops[#1]:
CPU: 12 PID: 1502 Comm: kworker/12:1 Not tainted 4.9.43-Cavium-Octeon+ #1
Workqueue: events_power_efficient phy_state_machine
task: 80000004021ed100 task.stack: 8000000409d70000
$ 0   : 0000000000000000 ffffffff84720060 0000000000000048 0000000000000004
$ 4   : 0000000000000000 0000000000000001 0000000000000004 0000000000000000
$ 8   : 0000000000000000 0000000000000000 00000000ffff98f3 0000000000000000
$12   : 8000000409d73fe0 0000000000009c00 ffffffff846547c8 000000000000af3b
$16   : 80000004096bab68 80000004096babd0 0000000000000000 80000004096ba800
$20   : 0000000000000000 0000000000000000 ffffffff81090000 0000000000000008
$24   : 0000000000000061 ffffffff808637b0
$28   : 8000000409d70000 8000000409d73cf0 80000000271bd300 ffffffff80c7804c
Hi    : 000000000000002a
Lo    : 000000000000003f
epc   : ffffffff80de37ec netif_carrier_off+0xc/0x58
ra    : ffffffff80c7804c phy_state_machine+0x48c/0x4f8
Status: 14009ce3        KX SX UX KERNEL EXL IE
Cause : 00800008 (ExcCode 02)
BadVA : 0000000000000048
PrId  : 000d9501 (Cavium Octeon III)
Modules linked in:
Process kworker/12:1 (pid: 1502, threadinfo=8000000409d70000,
task=80000004021ed100, tls=0000000000000000)
Stack : 8000000409a54000 80000004096bab68 80000000271bd300 80000000271c1e00
        0000000000000000 ffffffff808a1708 8000000409a54000 80000000271bd300
        80000000271bd320 8000000409a54030 ffffffff80ff0f00 0000000000000001
        ffffffff81090000 ffffffff808a1ac0 8000000402182080 ffffffff84650000
        8000000402182080 ffffffff84650000 ffffffff80ff0000 8000000409a54000
        ffffffff808a1970 0000000000000000 80000004099e8000 8000000402099240
        0000000000000000 ffffffff808a8598 0000000000000000 8000000408eeeb00
        8000000409a54000 00000000810a1d00 0000000000000000 8000000409d73de8
        8000000409d73de8 0000000000000088 000000000c009c00 8000000409d73e08
        8000000409d73e08 8000000402182080 ffffffff808a84d0 8000000402182080
        ...
Call Trace:
[&lt;ffffffff80de37ec&gt;] netif_carrier_off+0xc/0x58
[&lt;ffffffff80c7804c&gt;] phy_state_machine+0x48c/0x4f8
[&lt;ffffffff808a1708&gt;] process_one_work+0x158/0x368
[&lt;ffffffff808a1ac0&gt;] worker_thread+0x150/0x4c0
[&lt;ffffffff808a8598&gt;] kthread+0xc8/0xe0
[&lt;ffffffff808617f0&gt;] ret_from_kernel_thread+0x14/0x1c

The original motivation for this change originated from Marc Gonzales
indicating that his network driver did not have its adjust_link callback
executing with phydev-&gt;link = 0 while he was expecting it.

PHYLIB has never made any such guarantees ever because phy_stop() merely just
tells the workqueue to move into PHY_HALTED state which will happen
asynchronously.

Reported-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Reported-by: David Daney &lt;ddaney.cavm@gmail.com&gt;
Fixes: 7ad813f20853 ("net: phy: Correctly process PHY_HALTED in phy_stop_machine()")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>net: phy: Correctly process PHY_HALTED in phy_stop_machine()</title>
<updated>2017-09-10T20:36:04Z</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2017-07-28T18:58:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=128f29a4d83cab0ac3d1f5b47abafd32096d1b50'/>
<id>urn:sha1:128f29a4d83cab0ac3d1f5b47abafd32096d1b50</id>
<content type='text'>
[ Upstream commit 7ad813f208533cebfcc32d3d7474dc1677d1b09a ]

Marc reported that he was not getting the PHY library adjust_link()
callback function to run when calling phy_stop() + phy_disconnect()
which does not indeed happen because we set the state machine to
PHY_HALTED but we don't get to run it to process this state past that
point.

Fix this with a synchronous call to phy_state_machine() in order to have
the state machine actually act on PHY_HALTED, set the PHY device's link
down, turn the network device's carrier off and finally call the
adjust_link() function.

Reported-by: Marc Gonzalez &lt;marc_gonzalez@sigmadesigns.com&gt;
Fixes: a390d1f379cf ("phylib: convert state_queue work to delayed_work")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Marc Gonzalez &lt;marc_gonzalez@sigmadesigns.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>net: phy: handle state correctly in phy_stop_machine</title>
<updated>2017-06-13T13:29:18Z</updated>
<author>
<name>Nathan Sullivan</name>
<email>nathan.sullivan@ni.com</email>
</author>
<published>2017-03-22T20:27:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=28bad8a652e9ad3bd0b9a230ac43c7c2ff3648fd'/>
<id>urn:sha1:28bad8a652e9ad3bd0b9a230ac43c7c2ff3648fd</id>
<content type='text'>
[ Upstream commit 49d52e8108a21749dc2114b924c907db43358984 ]

If the PHY is halted on stop, then do not set the state to PHY_UP.  This
ensures the phy will be restarted later in phy_start when the machine is
started again.

Fixes: 00db8189d984 ("This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling ethernet drivers to remain as ignorant as is reasonable of the connected PHY's design and operation details.")
Signed-off-by: Nathan Sullivan &lt;nathan.sullivan@ni.com&gt;
Signed-off-by: Brad Mouring &lt;brad.mouring@ni.com&gt;
Acked-by: Xander Huff &lt;xander.huff@ni.com&gt;
Acked-by: Kyle Roeschley &lt;kyle.roeschley@ni.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>net: phy: Make sure phy_start() always re-enables the phy interrupts</title>
<updated>2015-05-20T16:22:08Z</updated>
<author>
<name>Tim Beale</name>
<email>tim.beale@alliedtelesis.co.nz</email>
</author>
<published>2015-05-18T03:38:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c15e10e71ce3b4ee78d85d80102a9621cde1edbd'/>
<id>urn:sha1:c15e10e71ce3b4ee78d85d80102a9621cde1edbd</id>
<content type='text'>
This is an alternative way of fixing:
 commit db9683fb412d ("net: phy: Make sure PHY_RESUMING state change
                      is always processed")

When the PHY state transitions from PHY_HALTED to PHY_RESUMING, there are
two things we need to do:
1). Re-enable interrupts (and power up the physical link, if powered down)
2). Update the PHY state and net-device based on the link status.

There's no strict reason why #1 has to be done from within the main
phy_state_machine() function. There is a risk that other changes to the
PHY (e.g. setting speed/duplex, which calls phy_start_aneg()) could cause
a subsequent state transition before phy_state_machine() has processed
the PHY_RESUMING state change. This would leave the PHY with interrupts
disabled and/or still in the BMCR_PDOWN/low-power mode.

Moving enabling the interrupts and phy_resume() into phy_start() will
guarantee this work always gets done. As the PHY is already in the HALTED
state and interrupts are disabled, it shouldn't conflict with any work
being done in phy_state_machine(). The downside of this change is that if
the PHY_RESUMING state is ever entered from anywhere else, it'll also have
to repeat this work.

Signed-off-by: Tim Beale &lt;tim.beale@alliedtelesis.co.nz&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: Make sure PHY_RESUMING state change is always processed</title>
<updated>2015-05-16T21:15:40Z</updated>
<author>
<name>Tim Beale</name>
<email>tim.beale@alliedtelesis.co.nz</email>
</author>
<published>2015-05-13T01:55:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=db9683fb412d4af33f66b9fe3d8dace1c6d113c9'/>
<id>urn:sha1:db9683fb412d4af33f66b9fe3d8dace1c6d113c9</id>
<content type='text'>
If phy_start_aneg() was called while the phydev is in the PHY_RESUMING
state, then its state would immediately transition to PHY_AN (or
PHY_FORCING). This meant the phy_state_machine() never processed the
PHY_RESUMING state change, which meant interrupts weren't enabled for the
PHY. If the PHY used low-power mode (i.e. using BMCR_PDOWN), then the
physical link wouldn't get powered up again.

There seems no point for phy_start_aneg() to make the PHY_RESUMING --&gt;
PHY_AN transition, as the state machine will do this anyway. I'm not sure
about the case where autoneg is disabled, as my patch will change
behaviour so that the PHY goes to PHY_NOLINK instead of PHY_FORCING. An
alternative solution would be to move the phy_config_interrupt() and
phy_resume() work out of the state machine and into phy_start().

The background behind this: we're running linux v3.16.7 and from user-space
we want to enable the eth port (i.e. do a SIOCSIFFLAGS ioctl with the
IFF_UP flag) and immediately afterward set the interface's speed/duplex.
Enabling the interface calls .ndo_open() then phy_start() and the PHY
transitions PHY_HALTED --&gt; PHY_RESUMING. Setting the speed/duplex ends up
calling phy_ethtool_sset(), which calls phy_start_aneg() (meanwhile the
phy_state_machine() hasn't processed the PHY_RESUMING state change yet).

Signed-off-by: Tim Beale &lt;tim.beale@alliedtelesis.co.nz&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: Allow EEE for all RGMII variants</title>
<updated>2015-05-16T01:20:47Z</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2015-05-15T23:30:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7e14069651591c81046ffaec13c3dac8cb70f5fb'/>
<id>urn:sha1:7e14069651591c81046ffaec13c3dac8cb70f5fb</id>
<content type='text'>
RGMII interfaces come in multiple flavors: RGMII with transmit or
receive internal delay, no delays at all, or delays in both direction.

This change extends the initial check for PHY_INTERFACE_MODE_RGMII to
cover all of these variants since EEE should be allowed for any of these
modes, since it is a property of the RGMII, hence Gigabit PHY capability
more than the RGMII electrical interface and its delays.

Fixes: a59a4d192166 ("phy: add the EEE support and the way to access to the MMD registers")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: Fix verification of EEE support in phy_init_eee</title>
<updated>2015-02-20T20:29:49Z</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2015-02-17T17:36:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=54da5a8be3c1e924c35480eb44c6e9b275f6444e'/>
<id>urn:sha1:54da5a8be3c1e924c35480eb44c6e9b275f6444e</id>
<content type='text'>
phy_init_eee uses phy_find_setting(phydev-&gt;speed, phydev-&gt;duplex)
to find a valid entry in the settings array for the given speed
and duplex value. For full duplex 1000baseT, this will return
the first matching entry, which is the entry for 1000baseKX_Full.

If the phy eee does not support 1000baseKX_Full, this entry will not
match, causing phy_init_eee to fail for no good reason.

Fixes: 9a9c56cb34e6 ("net: phy: fix a bug when verify the EEE support")
Fixes: 3e7077067e80c ("phy: Expand phy speed/duplex settings array")
Cc: Giuseppe Cavallaro &lt;peppe.cavallaro@st.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: Invalidate LP advertising flags when restarting or disabling AN</title>
<updated>2015-01-27T08:27:08Z</updated>
<author>
<name>Ben Hutchings</name>
<email>ben.hutchings@codethink.co.uk</email>
</author>
<published>2015-01-27T00:58:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9b3320ef702d1c7daf165d5c72c945f0be6b2bed'/>
<id>urn:sha1:9b3320ef702d1c7daf165d5c72c945f0be6b2bed</id>
<content type='text'>
It is possible to see the old value of the LP advertising flags
through ethtool after reconfiguring the PHY and before autonegotiation
completes.  If autonegotiation is turned off then the last value seen
will persist indefinitely.

Signed-off-by: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
