<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/phy, branch v4.14.263</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-01-27T08:00:57+00:00</updated>
<entry>
<title>net: phy: marvell: configure RGMII delays for 88E1118</title>
<updated>2022-01-27T08:00:57+00:00</updated>
<author>
<name>Russell King (Oracle)</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2022-01-04T16:38:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9a4300a91ef8fe126a28c42311a0716e6919253f'/>
<id>urn:sha1:9a4300a91ef8fe126a28c42311a0716e6919253f</id>
<content type='text'>
[ Upstream commit f22725c95ececb703c3f741e8f946d23705630b7 ]

Corentin Labbe reports that the SSI 1328 does not work when allowing
the PHY to operate at gigabit speeds, but does work with the generic
PHY driver.

This appears to be because m88e1118_config_init() writes a fixed value
to the MSCR register, claiming that this is to enable 1G speeds.
However, this always sets bits 4 and 5, enabling RGMII transmit and
receive delays. The suspicion is that the original board this was
added for required the delays to make 1G speeds work.

Add the necessary configuration for RGMII delays for the 88E1118 to
bring this into line with the requirements for RGMII support, and thus
make the SSI 1328 work.

Corentin Labbe has tested this on gemini-ssi1328 and gemini-ns2502.

Reported-by: Corentin Labbe &lt;clabbe.montjoie@gmail.com&gt;
Tested-by: Corentin Labbe &lt;clabbe.montjoie@gmail.com&gt;
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: mdio: Demote probed message to debug print</title>
<updated>2022-01-27T08:00:56+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2022-01-03T19:40:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c78017764c7d2c7b9ea42fd1aadd78f07b3ec403'/>
<id>urn:sha1:c78017764c7d2c7b9ea42fd1aadd78f07b3ec403</id>
<content type='text'>
[ Upstream commit 7590fc6f80ac2cbf23e6b42b668bbeded070850b ]

On systems with large numbers of MDIO bus/muxes the message indicating
that a given MDIO bus has been successfully probed is repeated for as
many buses we have, which can eat up substantial boot time for no
reason, demote to a debug print.

Reported-by: Maxime Bizon &lt;mbizon@freebox.fr&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20220103194024.2620-1-f.fainelli@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: avoid mvneta warning when setting pause parameters</title>
<updated>2021-11-26T10:40:32+00:00</updated>
<author>
<name>Russell King (Oracle)</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2021-10-28T14:55:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b5589f0e13d252b780b866e46ea9e14821ca88e3'/>
<id>urn:sha1:b5589f0e13d252b780b866e46ea9e14821ca88e3</id>
<content type='text'>
[ Upstream commit fd8d9731bcdfb22d28e45bce789bcb211c868c78 ]

mvneta does not support asymetric pause modes, and it flags this by the
lack of AsymPause in the supported field. When setting pause modes, we
check that pause-&gt;rx_pause == pause-&gt;tx_pause, but only when pause
autoneg is enabled. When pause autoneg is disabled, we still allow
pause-&gt;rx_pause != pause-&gt;tx_pause, which is incorrect when the MAC
does not support asymetric pause, and causes mvneta to issue a warning.

Fix this by removing the test for pause-&gt;autoneg, so we always check
that pause-&gt;rx_pause == pause-&gt;tx_pause for network devices that do not
support AsymPause.

Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Russell King (Oracle) &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>phy: micrel: ksz8041nl: do not use power down mode</title>
<updated>2021-11-26T10:40:31+00:00</updated>
<author>
<name>Stefan Agner</name>
<email>stefan@agner.ch</email>
</author>
<published>2021-10-19T19:16:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4d8e3a1fe785853420f4e83d9e23e442d67ebe45'/>
<id>urn:sha1:4d8e3a1fe785853420f4e83d9e23e442d67ebe45</id>
<content type='text'>
[ Upstream commit 2641b62d2fab52648e34cdc6994b2eacde2d27c1 ]

Some Micrel KSZ8041NL PHY chips exhibit continuous RX errors after using
the power down mode bit (0.11). If the PHY is taken out of power down
mode in a certain temperature range, the PHY enters a weird state which
leads to continuously reporting RX errors. In that state, the MAC is not
able to receive or send any Ethernet frames and the activity LED is
constantly blinking. Since Linux is using the suspend callback when the
interface is taken down, ending up in that state can easily happen
during a normal startup.

Micrel confirmed the issue in errata DS80000700A [*], caused by abnormal
clock recovery when using power down mode. Even the latest revision (A4,
Revision ID 0x1513) seems to suffer that problem, and according to the
errata is not going to be fixed.

Remove the suspend/resume callback to avoid using the power down mode
completely.

[*] https://ww1.microchip.com/downloads/en/DeviceDoc/80000700A.pdf

Fixes: 1a5465f5d6a2 ("phy/micrel: Add suspend/resume support to Micrel PHYs")
Signed-off-by: Stefan Agner &lt;stefan@agner.ch&gt;
Acked-by: Marcel Ziswiler &lt;marcel.ziswiler@toradex.com&gt;
Signed-off-by: Francesco Dolcini &lt;francesco.dolcini@toradex.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>Revert "net: mdiobus: Fix memory leak in __mdiobus_register"</title>
<updated>2021-11-02T17:25:11+00:00</updated>
<author>
<name>Pavel Skripkin</name>
<email>paskripkin@gmail.com</email>
</author>
<published>2021-09-30T17:49:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fdbffd95c4ce94d2197c504008eaac46b16bc5a4'/>
<id>urn:sha1:fdbffd95c4ce94d2197c504008eaac46b16bc5a4</id>
<content type='text'>
commit 10eff1f5788b6ffac212c254e2f3666219576889 upstream.

This reverts commit ab609f25d19858513919369ff3d9a63c02cd9e2e.

This patch is correct in the sense that we _should_ call device_put() in
case of device_register() failure, but the problem in this code is more
vast.

We need to set bus-&gt;state to UNMDIOBUS_REGISTERED before calling
device_register() to correctly release the device in mdiobus_free().
This patch prevents us from doing it, since in case of device_register()
failure put_device() will be called 2 times and it will cause UAF or
something else.

Also, Reported-by: tag in revered commit was wrong, since syzbot
reported different leak in same function.

Link: https://lore.kernel.org/netdev/20210928092657.GI2048@kadam/
Acked-by: Yanfei Xu &lt;yanfei.xu@windriver.com&gt;
Signed-off-by: Pavel Skripkin &lt;paskripkin@gmail.com&gt;
Link: https://lore.kernel.org/r/f12fb1faa4eccf0f355788225335eb4309ff2599.1633024062.git.paskripkin@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: mdiobus: Fix memory leak in __mdiobus_register</title>
<updated>2021-10-27T07:51:41+00:00</updated>
<author>
<name>Yanfei Xu</name>
<email>yanfei.xu@windriver.com</email>
</author>
<published>2021-09-26T04:53:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4ec0f9abc512cc02fb04daa89ccf6697e80ab417'/>
<id>urn:sha1:4ec0f9abc512cc02fb04daa89ccf6697e80ab417</id>
<content type='text'>
commit ab609f25d19858513919369ff3d9a63c02cd9e2e upstream.

Once device_register() failed, we should call put_device() to
decrement reference count for cleanup. Or it will cause memory
leak.

BUG: memory leak
unreferenced object 0xffff888114032e00 (size 256):
  comm "kworker/1:3", pid 2960, jiffies 4294943572 (age 15.920s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 08 2e 03 14 81 88 ff ff  ................
    08 2e 03 14 81 88 ff ff 90 76 65 82 ff ff ff ff  .........ve.....
  backtrace:
    [&lt;ffffffff8265cfab&gt;] kmalloc include/linux/slab.h:591 [inline]
    [&lt;ffffffff8265cfab&gt;] kzalloc include/linux/slab.h:721 [inline]
    [&lt;ffffffff8265cfab&gt;] device_private_init drivers/base/core.c:3203 [inline]
    [&lt;ffffffff8265cfab&gt;] device_add+0x89b/0xdf0 drivers/base/core.c:3253
    [&lt;ffffffff828dd643&gt;] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537
    [&lt;ffffffff828cb835&gt;] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
    [&lt;ffffffff82b92a00&gt;] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
    [&lt;ffffffff82b92a00&gt;] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
    [&lt;ffffffff82baa33f&gt;] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
    [&lt;ffffffff82c36e17&gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [&lt;ffffffff82661d17&gt;] call_driver_probe drivers/base/dd.c:517 [inline]
    [&lt;ffffffff82661d17&gt;] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
    [&lt;ffffffff826620bc&gt;] really_probe drivers/base/dd.c:558 [inline]
    [&lt;ffffffff826620bc&gt;] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
    [&lt;ffffffff826621ba&gt;] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
    [&lt;ffffffff82662a26&gt;] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
    [&lt;ffffffff8265eca7&gt;] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
    [&lt;ffffffff826625a2&gt;] __device_attach+0x122/0x260 drivers/base/dd.c:969
    [&lt;ffffffff82660916&gt;] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
    [&lt;ffffffff8265cd0b&gt;] device_add+0x5fb/0xdf0 drivers/base/core.c:3359
    [&lt;ffffffff82c343b9&gt;] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2170
    [&lt;ffffffff82c4473c&gt;] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238

BUG: memory leak
unreferenced object 0xffff888116f06900 (size 32):
  comm "kworker/0:2", pid 2670, jiffies 4294944448 (age 7.160s)
  hex dump (first 32 bytes):
    75 73 62 2d 30 30 31 3a 30 30 33 00 00 00 00 00  usb-001:003.....
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff81484516&gt;] kstrdup+0x36/0x70 mm/util.c:60
    [&lt;ffffffff814845a3&gt;] kstrdup_const+0x53/0x80 mm/util.c:83
    [&lt;ffffffff82296ba2&gt;] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48
    [&lt;ffffffff82358d4b&gt;] kobject_set_name_vargs+0x3b/0xe0 lib/kobject.c:289
    [&lt;ffffffff826575f3&gt;] dev_set_name+0x63/0x90 drivers/base/core.c:3147
    [&lt;ffffffff828dd63b&gt;] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535
    [&lt;ffffffff828cb835&gt;] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
    [&lt;ffffffff82b92a00&gt;] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
    [&lt;ffffffff82b92a00&gt;] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
    [&lt;ffffffff82baa33f&gt;] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
    [&lt;ffffffff82c36e17&gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [&lt;ffffffff82661d17&gt;] call_driver_probe drivers/base/dd.c:517 [inline]
    [&lt;ffffffff82661d17&gt;] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
    [&lt;ffffffff826620bc&gt;] really_probe drivers/base/dd.c:558 [inline]
    [&lt;ffffffff826620bc&gt;] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
    [&lt;ffffffff826621ba&gt;] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
    [&lt;ffffffff82662a26&gt;] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
    [&lt;ffffffff8265eca7&gt;] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
    [&lt;ffffffff826625a2&gt;] __device_attach+0x122/0x260 drivers/base/dd.c:969

Reported-by: syzbot+398e7dc692ddbbb4cfec@syzkaller.appspotmail.com
Signed-off-by: Yanfei Xu &lt;yanfei.xu@windriver.com&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>
<entry>
<title>net: phy: bcm7xxx: Fixed indirect MMD operations</title>
<updated>2021-10-17T08:08:33+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2021-09-28T20:32:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e0b6d06e9c902f57f3dd141177e79b487c44ea82'/>
<id>urn:sha1:e0b6d06e9c902f57f3dd141177e79b487c44ea82</id>
<content type='text'>
commit d88fd1b546ff19c8040cfaea76bf16aed1c5a0bb upstream.

When EEE support was added to the 28nm EPHY it was assumed that it would
be able to support the standard clause 45 over clause 22 register access
method. It turns out that the PHY does not support that, which is the
very reason for using the indirect shadow mode 2 bank 3 access method.

Implement {read,write}_mmd to allow the standard PHY library routines
pertaining to EEE querying and configuration to work correctly on these
PHYs. This forces us to implement a __phy_set_clr_bits() function that
does not grab the MDIO bus lock since the PHY driver's {read,write}_mmd
functions are always called with that lock held.

Fixes: 83ee102a6998 ("net: phy: bcm7xxx: add support for 28nm EPHY")
[florian: adjust locking since phy_{read,write}_mmd are called with no
PHYLIB locks held]
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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>phy: mdio: fix memory leak</title>
<updated>2021-10-17T08:08:32+00:00</updated>
<author>
<name>Pavel Skripkin</name>
<email>paskripkin@gmail.com</email>
</author>
<published>2021-09-30T17:50:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f4f502a04ee1e543825af78f47eb7785015cd9f6'/>
<id>urn:sha1:f4f502a04ee1e543825af78f47eb7785015cd9f6</id>
<content type='text'>
[ Upstream commit ca6e11c337daf7925ff8a2aac8e84490a8691905 ]

Syzbot reported memory leak in MDIO bus interface, the problem was in
wrong state logic.

MDIOBUS_ALLOCATED indicates 2 states:
	1. Bus is only allocated
	2. Bus allocated and __mdiobus_register() fails, but
	   device_register() was called

In case of device_register() has been called we should call put_device()
to correctly free the memory allocated for this device, but mdiobus_free()
calls just kfree(dev) in case of MDIOBUS_ALLOCATED state

To avoid this behaviour we need to set bus-&gt;state to MDIOBUS_UNREGISTERED
_before_ calling device_register(), because put_device() should be
called even in case of device_register() failure.

Link: https://lore.kernel.org/netdev/YVMRWNDZDUOvQjHL@shell.armlinux.org.uk/
Fixes: 46abc02175b3 ("phylib: give mdio buses a device tree presence")
Reported-and-tested-by: syzbot+398e7dc692ddbbb4cfec@syzkaller.appspotmail.com
Reviewed-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Pavel Skripkin &lt;paskripkin@gmail.com&gt;
Link: https://lore.kernel.org/r/eceae1429fbf8fa5c73dd2a0d39d525aa905074d.1633024062.git.paskripkin@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: mdio: introduce a shutdown method to mdio device drivers</title>
<updated>2021-10-09T12:09:45+00:00</updated>
<author>
<name>Vladimir Oltean</name>
<email>vladimir.oltean@nxp.com</email>
</author>
<published>2021-09-17T13:34:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e8c19822789f43f6e678b687172ff7361e141a34'/>
<id>urn:sha1:e8c19822789f43f6e678b687172ff7361e141a34</id>
<content type='text'>
[ Upstream commit cf9579976f724ad517cc15b7caadea728c7e245c ]

MDIO-attached devices might have interrupts and other things that might
need quiesced when we kexec into a new kernel. Things are even more
creepy when those interrupt lines are shared, and in that case it is
absolutely mandatory to disable all interrupt sources.

Moreover, MDIO devices might be DSA switches, and DSA needs its own
shutdown method to unlink from the DSA master, which is a new
requirement that appeared after commit 2f1e8ea726e9 ("net: dsa: link
interfaces with the DSA master to get rid of lockdep warnings").

So introduce a -&gt;shutdown method in the MDIO device driver structure.

Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&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>ptp: dp83640: don't define PAGE0</title>
<updated>2021-09-22T09:45:33+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2021-09-13T22:06:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3d3aed0cc0bec8cb6a775da0206aa4052c364ce0'/>
<id>urn:sha1:3d3aed0cc0bec8cb6a775da0206aa4052c364ce0</id>
<content type='text'>
commit 7366c23ff492ad260776a3ee1aaabba9fc773a8b upstream.

Building dp83640.c on arch/parisc/ produces a build warning for
PAGE0 being redefined. Since the macro is not used in the dp83640
driver, just make it a comment for documentation purposes.

In file included from ../drivers/net/phy/dp83640.c:23:
../drivers/net/phy/dp83640_reg.h:8: warning: "PAGE0" redefined
    8 | #define PAGE0                     0x0000
                 from ../drivers/net/phy/dp83640.c:11:
../arch/parisc/include/asm/page.h:187: note: this is the location of the previous definition
  187 | #define PAGE0   ((struct zeropage *)__PAGE_OFFSET)

Fixes: cb646e2b02b2 ("ptp: Added a clock driver for the National Semiconductor PHYTER.")
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Reported-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Cc: Richard Cochran &lt;richard.cochran@omicron.at&gt;
Cc: John Stultz &lt;john.stultz@linaro.org&gt;
Cc: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20210913220605.19682-1-rdunlap@infradead.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
