linux-stable.git/drivers/net/phy, branch v4.9.331

net: phy: broadcom: Fix brcm_fet_config_init()

2022-04-20T07:06:37+00:00

[ Upstream commit bf8bfc4336f7a34e48b3bbd19b1542bf085bdc3d ]

A Broadcom AC201 PHY (same entry as 5241) would be flagged by the
Broadcom UniMAC MDIO controller as not completing the turn around
properly since the PHY expects 65 MDC clock cycles to complete a write
cycle, and the MDIO controller was only sending 64 MDC clock cycles as
determined by looking at a scope shot.

This would make the subsequent read fail with the UniMAC MDIO controller
command field having MDIO_READ_FAIL set and we would abort the
brcm_fet_config_init() function and thus not probe the PHY at all.

After issuing a software reset, wait for at least 1ms which is well
above the 1us reset delay advertised by the datasheet and issue a dummy
read to let the PHY turn around the line properly. This read
specifically ignores -EIO which would be returned by MDIO controllers
checking for the line being turned around.

If we have a genuine reaad failure, the next read of the interrupt
status register would pick it up anyway.

Fixes: d7a2ed9248a3 ("broadcom: Add AC131 phy support")
Signed-off-by: Florian Fainelli 
Link: https://lore.kernel.org/r/20220324232438.1156812-1-f.fainelli@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: mdio: Demote probed message to debug print

2022-01-27T07:47:38+00:00

[ 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 
Signed-off-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20220103194024.2620-1-f.fainelli@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: mdio-mux: fix unbalanced put_device

2021-11-26T10:48:40+00:00

commit 60f786525032432af1b7d9b8935cb12936244ccd upstream.

mdio_mux_uninit() call put_device (unconditionally) because of
of_mdio_find_bus() in mdio_mux_init.
But of_mdio_find_bus is only called if mux_bus is empty.
If mux_bus is set, mdio_mux_uninit will print a "refcount_t: underflow"
trace.

This patch add a get_device in the other branch of "if (mux_bus)".

Signed-off-by: Corentin Labbe 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Florian Fainelli 
Signed-off-by: Greg Kroah-Hartman

phy: micrel: ksz8041nl: do not use power down mode

2021-11-26T10:48:35+00:00

[ 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 
Acked-by: Marcel Ziswiler 
Signed-off-by: Francesco Dolcini 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

Revert "net: mdiobus: Fix memory leak in __mdiobus_register"

2021-11-02T16:39:23+00:00

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->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 
Signed-off-by: Pavel Skripkin 
Link: https://lore.kernel.org/r/f12fb1faa4eccf0f355788225335eb4309ff2599.1633024062.git.paskripkin@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

net: mdiobus: Fix memory leak in __mdiobus_register

2021-10-27T07:34:01+00:00

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:
    [] kmalloc include/linux/slab.h:591 [inline]
    [] kzalloc include/linux/slab.h:721 [inline]
    [] device_private_init drivers/base/core.c:3203 [inline]
    [] device_add+0x89b/0xdf0 drivers/base/core.c:3253
    [] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537
    [] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
    [] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
    [] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
    [] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
    [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [] call_driver_probe drivers/base/dd.c:517 [inline]
    [] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
    [] really_probe drivers/base/dd.c:558 [inline]
    [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
    [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
    [] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
    [] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
    [] __device_attach+0x122/0x260 drivers/base/dd.c:969
    [] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
    [] device_add+0x5fb/0xdf0 drivers/base/core.c:3359
    [] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2170
    [] 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:
    [] kstrdup+0x36/0x70 mm/util.c:60
    [] kstrdup_const+0x53/0x80 mm/util.c:83
    [] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48
    [] kobject_set_name_vargs+0x3b/0xe0 lib/kobject.c:289
    [] dev_set_name+0x63/0x90 drivers/base/core.c:3147
    [] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535
    [] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
    [] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
    [] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
    [] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
    [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [] call_driver_probe drivers/base/dd.c:517 [inline]
    [] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
    [] really_probe drivers/base/dd.c:558 [inline]
    [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
    [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
    [] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
    [] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
    [] __device_attach+0x122/0x260 drivers/base/dd.c:969

Reported-by: syzbot+398e7dc692ddbbb4cfec@syzkaller.appspotmail.com
Signed-off-by: Yanfei Xu 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

phy: mdio: fix memory leak

2021-10-17T08:05:39+00:00

[ 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->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 
Signed-off-by: Pavel Skripkin 
Link: https://lore.kernel.org/r/eceae1429fbf8fa5c73dd2a0d39d525aa905074d.1633024062.git.paskripkin@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: mdio: introduce a shutdown method to mdio device drivers

2021-10-09T11:25:58+00:00

[ 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 ->shutdown method in the MDIO device driver structure.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Andrew Lunn 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ptp: dp83640: don't define PAGE0

2021-09-22T09:43:09+00:00

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 
Reported-by: Geert Uytterhoeven 
Cc: Richard Cochran 
Cc: John Stultz 
Cc: Heiner Kallweit 
Cc: Russell King 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20210913220605.19682-1-rdunlap@infradead.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

net: mdiobus: get rid of a BUG_ON()

2021-06-16T09:36:33+00:00

[ Upstream commit 1dde47a66d4fb181830d6fa000e5ea86907b639e ]

We spotted a bug recently during a review where a driver was
unregistering a bus that wasn't registered, which would trigger this
BUG_ON().  Let's handle that situation more gracefully, and just print
a warning and return.

Reported-by: Russell King (Oracle) 
Signed-off-by: Dan Carpenter 
Reviewed-by: Russell King (Oracle) 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin