<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/phy, branch linux-5.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-07-28T06:28:29Z</updated>
<entry>
<title>net: phy: sfp: hwmon: Fix scaling of RX power</title>
<updated>2019-07-28T06:28:29Z</updated>
<author>
<name>Andrew Lunn</name>
<email>andrew@lunn.ch</email>
</author>
<published>2019-07-21T16:50:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ba5f4cb33e9bdcbc895902dc78fd990a526de005'/>
<id>urn:sha1:ba5f4cb33e9bdcbc895902dc78fd990a526de005</id>
<content type='text'>
[ Upstream commit 0cea0e1148fe134a4a3aaf0b1496f09241fb943a ]

The RX power read from the SFP uses units of 0.1uW. This must be
scaled to units of uW for HWMON. This requires a divide by 10, not the
current 100.

With this change in place, sensors(1) and ethtool -m agree:

sff2-isa-0000
Adapter: ISA adapter
in0:          +3.23 V
temp1:        +33.1 C
power1:      270.00 uW
power2:      200.00 uW
curr1:        +0.01 A

        Laser output power                        : 0.2743 mW / -5.62 dBm
        Receiver signal average optical power     : 0.2014 mW / -6.96 dBm

Reported-by: chris.healy@zii.aero
Signed-off-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: sfp: add mutex to prevent concurrent state checks</title>
<updated>2019-07-26T07:12:32Z</updated>
<author>
<name>Robert Hancock</name>
<email>hancock@sedsystems.ca</email>
</author>
<published>2019-06-07T16:42:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b892e3cf62cc35109a618ba15d005858679979b1'/>
<id>urn:sha1:b892e3cf62cc35109a618ba15d005858679979b1</id>
<content type='text'>
[ Upstream commit 2158e856f56bb762ef90f3ec244d41a519826f75 ]

sfp_check_state can potentially be called by both a threaded IRQ handler
and delayed work. If it is concurrently called, it could result in
incorrect state management. Add a st_mutex to protect the state - this
lock gets taken outside of code that checks and handle state changes, and
the existing sm_mutex nests inside of it.

Suggested-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Robert Hancock &lt;hancock@sedsystems.ca&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: Check against net_device being NULL</title>
<updated>2019-07-26T07:12:28Z</updated>
<author>
<name>Ioana Ciornei</name>
<email>ioana.ciornei@nxp.com</email>
</author>
<published>2019-05-28T17:38:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8db10b192f96deb625f202013b0b0c6051f19031'/>
<id>urn:sha1:8db10b192f96deb625f202013b0b0c6051f19031</id>
<content type='text'>
[ Upstream commit 82c76aca81187b3d28a6fb3062f6916450ce955e ]

In general, we don't want MAC drivers calling phy_attach_direct with the
net_device being NULL. Add checks against this in all the functions
calling it: phy_attach() and phy_connect_direct().

Signed-off-by: Ioana Ciornei &lt;ioana.ciornei@nxp.com&gt;
Suggested-by: Andrew Lunn &lt;andrew@lunn.ch&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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: rename Asix Electronics PHY driver</title>
<updated>2019-07-14T06:09:39Z</updated>
<author>
<name>Michael Schmitz</name>
<email>schmitzmic@gmail.com</email>
</author>
<published>2019-06-07T05:37:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fe218cfad2fb8677a1becc90ecc98c9376dffa65'/>
<id>urn:sha1:fe218cfad2fb8677a1becc90ecc98c9376dffa65</id>
<content type='text'>
[ Upstream commit a9520543b123bbd7275a0ab8d0375a5412683b41 ]

[Resent to net instead of net-next - may clash with Anders Roxell's patch
series addressing duplicate module names]

Commit 31dd83b96641 ("net-next: phy: new Asix Electronics PHY driver")
introduced a new PHY driver drivers/net/phy/asix.c that causes a module
name conflict with a pre-existiting driver (drivers/net/usb/asix.c).

The PHY driver is used by the X-Surf 100 ethernet card driver, and loaded
by that driver via its PHY ID. A rename of the driver looks unproblematic.

Rename PHY driver to ax88796b.c in order to resolve name conflict.

Signed-off-by: Michael Schmitz &lt;schmitzmic@gmail.com&gt;
Tested-by: Michael Schmitz &lt;schmitzmic@gmail.com&gt;
Fixes: 31dd83b96641 ("net-next: phy: new Asix Electronics PHY driver")
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: avoid reducing support mask</title>
<updated>2019-06-25T03:34:51Z</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2019-06-02T14:12:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f193786d78af356cfff0a5dd478c2a0e81ca3a1c'/>
<id>urn:sha1:f193786d78af356cfff0a5dd478c2a0e81ca3a1c</id>
<content type='text'>
[ Upstream commit 77316763321ee4050f0576ffd472183aa90dcb30 ]

Avoid reducing the support mask as a result of the interface type
selected for SFP modules, or when setting the link settings through
ethtool - this should only change when the supported link modes of
the hardware combination change.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: dp83867: Set up RGMII TX delay</title>
<updated>2019-06-22T06:09:14Z</updated>
<author>
<name>Max Uvarov</name>
<email>muvarov@gmail.com</email>
</author>
<published>2019-05-28T10:00:52Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b68f9cbff4448ee9bcddc91af7edbbfbaa2622ce'/>
<id>urn:sha1:b68f9cbff4448ee9bcddc91af7edbbfbaa2622ce</id>
<content type='text'>
[ Upstream commit 2b892649254fec01678c64f16427622b41fa27f4 ]

PHY_INTERFACE_MODE_RGMII_RXID is less then TXID
so code to set tx delay is never called.

Fixes: 2a10154abcb75 ("net: phy: dp83867: Add TI dp83867 phy")
Signed-off-by: Max Uvarov &lt;muvarov@gmail.com&gt;
Cc: Florian Fainelli &lt;f.fainelli@gmail.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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: dp83867: increase SGMII autoneg timer duration</title>
<updated>2019-06-22T06:09:14Z</updated>
<author>
<name>Max Uvarov</name>
<email>muvarov@gmail.com</email>
</author>
<published>2019-05-28T10:00:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8ee9f9c48f2d3944de54c2f0094157347230519b'/>
<id>urn:sha1:8ee9f9c48f2d3944de54c2f0094157347230519b</id>
<content type='text'>
[ Upstream commit 1a97a477e666cbdededab93bd3754e508f0c09d7 ]

After reset SGMII Autoneg timer is set to 2us (bits 6 and 5 are 01).
That is not enough to finalize autonegatiation on some devices.
Increase this timer duration to maximum supported 16ms.

Signed-off-by: Max Uvarov &lt;muvarov@gmail.com&gt;
Cc: Heiner Kallweit &lt;hkallweit1@gmail.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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: dp83867: fix speed 10 in sgmii mode</title>
<updated>2019-06-22T06:09:14Z</updated>
<author>
<name>Max Uvarov</name>
<email>muvarov@gmail.com</email>
</author>
<published>2019-05-28T10:00:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=315cb046c6d37ce32d1f06c1a9af1004c5e38221'/>
<id>urn:sha1:315cb046c6d37ce32d1f06c1a9af1004c5e38221</id>
<content type='text'>
[ Upstream commit 333061b924539c0de081339643f45514f5f1c1e6 ]

For supporting 10Mps speed in SGMII mode DP83867_10M_SGMII_RATE_ADAPT bit
of DP83867_10M_SGMII_CFG register has to be cleared by software.
That does not affect speeds 100 and 1000 so can be done on init.

Signed-off-by: Max Uvarov &lt;muvarov@gmail.com&gt;
Cc: Heiner Kallweit &lt;hkallweit1@gmail.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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: ensure consistent phy interface mode</title>
<updated>2019-06-22T06:09:14Z</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2019-05-28T09:27:21Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=132a01b4dc554231c4143bc78ae5058b3ef7502c'/>
<id>urn:sha1:132a01b4dc554231c4143bc78ae5058b3ef7502c</id>
<content type='text'>
[ Upstream commit c678726305b9425454be7c8a7624290b602602fc ]

Ensure that we supply the same phy interface mode to mac_link_down() as
we did for the corresponding mac_link_up() call.  This ensures that MAC
drivers that use the phy interface mode in these methods can depend on
mac_link_down() always corresponding to a mac_link_up() call for the
same interface mode.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: sfp: read eeprom in maximum 16 byte increments</title>
<updated>2019-06-11T10:19:11Z</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2019-06-02T14:13:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bab4057c77a4195f11af2c59f4f68d426fe31722'/>
<id>urn:sha1:bab4057c77a4195f11af2c59f4f68d426fe31722</id>
<content type='text'>
[ Upstream commit 28e74a7cfd6403f0d1c0f8b10b45d6fae37b227e ]

Some SFP modules do not like reads longer than 16 bytes, so read the
EEPROM in chunks of 16 bytes at a time.  This behaviour is not specified
in the SFP MSAs, which specifies:

 "The serial interface uses the 2-wire serial CMOS E2PROM protocol
  defined for the ATMEL AT24C01A/02/04 family of components."

and

 "As long as the SFP+ receives an acknowledge, it shall serially clock
  out sequential data words. The sequence is terminated when the host
  responds with a NACK and a STOP instead of an acknowledge."

We must avoid breaking a read across a 16-bit quantity in the diagnostic
page, thankfully all 16-bit quantities in that page are naturally
aligned.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
