<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/phy, branch v6.1.2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-12-08T04:04:11+00:00</updated>
<entry>
<title>net: phy: mxl-gpy: add MDINT workaround</title>
<updated>2022-12-08T04:04:11+00:00</updated>
<author>
<name>Michael Walle</name>
<email>michael@walle.cc</email>
</author>
<published>2022-12-05T20:04:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5f4d487d01ff5349da38f7a09ca36bf6aa2e29fb'/>
<id>urn:sha1:5f4d487d01ff5349da38f7a09ca36bf6aa2e29fb</id>
<content type='text'>
At least the GPY215B and GPY215C has a bug where it is still driving the
interrupt line (MDINT) even after the interrupt status register is read
and its bits are cleared. This will cause an interrupt storm.

Although the MDINT is multiplexed with a GPIO pin and theoretically we
could switch the pinmux to GPIO input mode, this isn't possible because
the access to this register will stall exactly as long as the interrupt
line is asserted. We exploit this very fact and just read a random
internal register in our interrupt handler. This way, it will be delayed
until the external interrupt line is released and an interrupt storm is
avoided.

The internal register access via the mailbox was deduced by looking at
the downstream PHY API because the datasheet doesn't mention any of
this.

Fixes: 7d901a1e878a ("net: phy: add Maxlinear GPY115/21x/24x driver")
Signed-off-by: Michael Walle &lt;michael@walle.cc&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20221205200453.3447866-1-michael@walle.cc
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: mdio: fix unbalanced fwnode reference count in mdio_device_release()</title>
<updated>2022-12-06T11:50:00+00:00</updated>
<author>
<name>Zeng Heng</name>
<email>zengheng4@huawei.com</email>
</author>
<published>2022-12-03T07:34:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cb37617687f2bfa5b675df7779f869147c9002bd'/>
<id>urn:sha1:cb37617687f2bfa5b675df7779f869147c9002bd</id>
<content type='text'>
There is warning report about of_node refcount leak
while probing mdio device:

OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry:
attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4

In of_mdiobus_register_device(), we increase fwnode refcount
by fwnode_handle_get() before associating the of_node with
mdio device, but it has never been decreased in normal path.
Since that, in mdio_device_release(), it needs to call
fwnode_handle_put() in addition instead of calling kfree()
directly.

After above, just calling mdio_device_free() in the error handle
path of of_mdiobus_register_device() is enough to keep the
refcount balanced.

Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.")
Signed-off-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Reviewed-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Link: https://lore.kernel.org/r/20221203073441.3885317-1-zengheng4@huawei.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>net: mdiobus: fix unbalanced node reference count</title>
<updated>2022-11-29T02:10:25+00:00</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2022-11-24T15:01:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cdde1560118f82498fc9e9a7c1ef7f0ef7755891'/>
<id>urn:sha1:cdde1560118f82498fc9e9a7c1ef7f0ef7755891</id>
<content type='text'>
I got the following report while doing device(mscc-miim) load test
with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:

  OF: ERROR: memory leak, expected refcount 1 instead of 2,
  of_node_get()/of_node_put() unbalanced - destroy cset entry:
  attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0

If the 'fwnode' is not an acpi node, the refcount is get in
fwnode_mdiobus_phy_device_register(), but it has never been
put when the device is freed in the normal path. So call
fwnode_handle_put() in phy_device_release() to avoid leak.

If it's an acpi node, it has never been get, but it's put
in the error path, so call fwnode_handle_get() before
phy_device_register() to keep get/put operation balanced.

Fixes: bc1bee3b87ee ("net: mdiobus: Introduce fwnode_mdiobus_register_phy()")
Signed-off-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20221124150130.609420-1-yangyingliang@huawei.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: fix PHY validation with rate adaption</title>
<updated>2022-11-28T11:12:39+00:00</updated>
<author>
<name>Russell King (Oracle)</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2022-11-24T09:06:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7642cc28fd37a15feacff0ccf0e5a8466630df5d'/>
<id>urn:sha1:7642cc28fd37a15feacff0ccf0e5a8466630df5d</id>
<content type='text'>
Tim Harvey reports that link modes which he does not expect to be
supported are being advertised, and this is because of the workaround
we have for PHYs that switch interface modes.

Fix this up by checking whether rate matching will be used for the
requested interface mode, and if rate matching will be used, perform
validation only with the requested interface mode, rather than invoking
this workaround.

Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: fix null-ptr-deref while probe() failed</title>
<updated>2022-11-27T19:09:59+00:00</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2022-11-23T13:28:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=369eb2c9f1f72adbe91e0ea8efb130f0a2ba11a6'/>
<id>urn:sha1:369eb2c9f1f72adbe91e0ea8efb130f0a2ba11a6</id>
<content type='text'>
I got a null-ptr-deref report as following when doing fault injection test:

BUG: kernel NULL pointer dereference, address: 0000000000000058
Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G    B            N 6.1.0-rc3+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:klist_put+0x2d/0xd0
Call Trace:
 &lt;TASK&gt;
 klist_remove+0xf1/0x1c0
 device_release_driver_internal+0x23e/0x2d0
 bus_remove_device+0x1bd/0x240
 device_del+0x357/0x770
 phy_device_remove+0x11/0x30
 mdiobus_unregister+0xa5/0x140
 release_nodes+0x6a/0xa0
 devres_release_all+0xf8/0x150
 device_unbind_cleanup+0x19/0xd0

//probe path:
phy_device_register()
  device_add()

phy_connect
  phy_attach_direct() //set device driver
    probe() //it's failed, driver is not bound
    device_bind_driver() // probe failed, it's not called

//remove path:
phy_device_remove()
  device_del()
    device_release_driver_internal()
      __device_release_driver() //dev-&gt;drv is not NULL
        klist_remove() &lt;- knode_driver is not added yet, cause null-ptr-deref

In phy_attach_direct(), after setting the 'dev-&gt;driver', probe() fails,
device_bind_driver() is not called, so the knode_driver-&gt;n_klist is not
set, then it causes null-ptr-deref in __device_release_driver() while
deleting device. Fix this by setting dev-&gt;driver to NULL in the error
path in phy_attach_direct().

Fixes: e13934563db0 ("[PATCH] PHY Layer fixup")
Signed-off-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: at803x: fix error return code in at803x_probe()</title>
<updated>2022-11-22T04:43:01+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>weiyongjun1@huawei.com</email>
</author>
<published>2022-11-18T10:36:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1f0dd412e34e177621769866bef347f0b22364df'/>
<id>urn:sha1:1f0dd412e34e177621769866bef347f0b22364df</id>
<content type='text'>
Fix to return a negative error code from the ccr read error handling
case instead of 0, as done elsewhere in this function.

Fixes: 3265f4218878 ("net: phy: at803x: add fiber support")
Signed-off-by: Wei Yongjun &lt;weiyongjun1@huawei.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20221118103635.254256-1-weiyongjun@huaweicloud.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: marvell: add sleep time after enabling the loopback bit</title>
<updated>2022-11-15T12:14:46+00:00</updated>
<author>
<name>Aminuddin Jamaluddin</name>
<email>aminuddin.jamaluddin@intel.com</email>
</author>
<published>2022-11-14T06:53:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=18c532e44939caa17f1fa380f7ac50dbc0718dbb'/>
<id>urn:sha1:18c532e44939caa17f1fa380f7ac50dbc0718dbb</id>
<content type='text'>
Sleep time is added to ensure the phy to be ready after loopback
bit was set. This to prevent the phy loopback test from failing.

Fixes: 020a45aff119 ("net: phy: marvell: add Marvell specific PHY loopback")
Cc: &lt;stable@vger.kernel.org&gt; # 5.15.x
Signed-off-by: Muhammad Husaini Zulkifli &lt;muhammad.husaini.zulkifli@intel.com&gt;
Signed-off-by: Aminuddin Jamaluddin &lt;aminuddin.jamaluddin@intel.com&gt;
Link: https://lore.kernel.org/r/20221114065302.10625-1-aminuddin.jamaluddin@intel.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>net: phy: dp83867: Fix SGMII FIFO depth for non OF devices</title>
<updated>2022-11-12T03:58:44+00:00</updated>
<author>
<name>Michael Sit Wei Hong</name>
<email>michael.wei.hong.sit@intel.com</email>
</author>
<published>2022-11-10T05:49:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e2a54350dc9642e7dfc07335ca355581caa9dbfe'/>
<id>urn:sha1:e2a54350dc9642e7dfc07335ca355581caa9dbfe</id>
<content type='text'>
Current driver code will read device tree node information,
and set default values if there is no info provided.

This is not done in non-OF devices leading to SGMII fifo depths being
set to the smallest size.

This patch sets the value to the default value of the PHY as stated in the
PHY datasheet.

Fixes: 4dc08dcc9f6f ("net: phy: dp83867: introduce critical chip default init for non-of platform")
Signed-off-by: Michael Sit Wei Hong &lt;michael.wei.hong.sit@intel.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20221110054938.925347-1-michael.wei.hong.sit@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: mscc: macsec: clear encryption keys when freeing a flow</title>
<updated>2022-11-10T10:58:52+00:00</updated>
<author>
<name>Antoine Tenart</name>
<email>atenart@kernel.org</email>
</author>
<published>2022-11-08T15:34:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1b16b3fdf675cca15a537572bac50cc5354368fc'/>
<id>urn:sha1:1b16b3fdf675cca15a537572bac50cc5354368fc</id>
<content type='text'>
Commit aaab73f8fba4 ("macsec: clear encryption keys from the stack after
setting up offload") made sure to clean encryption keys from the stack
after setting up offloading, but the MSCC PHY driver made a copy, kept
it in the flow data and did not clear it when freeing a flow. Fix this.

Fixes: 28c5107aa904 ("net: phy: mscc: macsec support")
Signed-off-by: Antoine Tenart &lt;atenart@kernel.org&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>net: mdio: fix undefined behavior in bit shift for __mdiobus_register</title>
<updated>2022-11-03T03:30:51+00:00</updated>
<author>
<name>Gaosheng Cui</name>
<email>cuigaosheng1@huawei.com</email>
</author>
<published>2022-10-31T13:26:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=40e4eb324c59e11fcb927aa46742d28aba6ecb8a'/>
<id>urn:sha1:40e4eb324c59e11fcb927aa46742d28aba6ecb8a</id>
<content type='text'>
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:

UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x7d/0xa5
 dump_stack+0x15/0x1b
 ubsan_epilogue+0xe/0x4e
 __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
 __mdiobus_register+0x49d/0x4e0
 fixed_mdio_bus_init+0xd8/0x12d
 do_one_initcall+0x76/0x430
 kernel_init_freeable+0x3b3/0x422
 kernel_init+0x24/0x1e0
 ret_from_fork+0x1f/0x30
 &lt;/TASK&gt;

Fixes: 4fd5f812c23c ("phylib: allow incremental scanning of an mii bus")
Signed-off-by: Gaosheng Cui &lt;cuigaosheng1@huawei.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20221031132645.168421-1-cuigaosheng1@huawei.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
</feed>
