kernel/linux.git/drivers/net/ethernet/dlink, branch v6.12.81

net: dlink: handle dma_map_single() failure properly

2025-10-23T14:20:28+00:00

[ Upstream commit 65946eac6d888d50ae527c4e5c237dbe5cc3a2f2 ] There is no error handling for `dma_map_single()` failures. Add error handling by checking `dma_mapping_error()` and freeing the `skb` using `dev_kfree_skb()` (process context) when it fails. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yeounsu Moon Tested-on: D-Link DGE-550T Rev-A3 Suggested-by: Simon Horman Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: dlink: handle copy_thresh allocation failure

2025-10-15T10:00:19+00:00

[ Upstream commit 8169a6011c5fecc6cb1c3654c541c567d3318de8 ] The driver did not handle failure of `netdev_alloc_skb_ip_align()`. If the allocation failed, dereferencing `skb->protocol` could lead to a NULL pointer dereference. This patch tries to allocate `skb`. If the allocation fails, it falls back to the normal path. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Jakub Kicinski Tested-on: D-Link DGE-550T Rev-A3 Signed-off-by: Yeounsu Moon Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250928190124.1156-1-yyyynoom@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: dlink: fix multicast stats being counted incorrectly

2025-09-04T13:31:48+00:00

[ Upstream commit 007a5ffadc4fd51739527f1503b7cf048f31c413 ] `McstFramesRcvdOk` counts the number of received multicast packets, and it reports the value correctly. However, reading `McstFramesRcvdOk` clears the register to zero. As a result, the driver was reporting only the packets since the last read, instead of the accumulated total. Fix this by updating the multicast statistics accumulatively instaed of instantaneously. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-on: D-Link DGE-550T Rev-A3 Signed-off-by: Yeounsu Moon Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250823182927.6063-3-yyyynoom@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: dlink: add synchronization for stats update

2025-06-27T10:11:29+00:00

[ Upstream commit 12889ce926e9a9baf6b83d809ba316af539b89e2 ] This patch synchronizes code that accesses from both user-space and IRQ contexts. The `get_stats()` function can be called from both context. `dev->stats.tx_errors` and `dev->stats.collisions` are also updated in the `tx_errors()` function. Therefore, these fields must also be protected by synchronized. There is no code that accessses `dev->stats.tx_errors` between the previous and updated lines, so the updating point can be moved. Signed-off-by: Moon Yeounsu Link: https://patch.msgid.link/20250515075333.48290-1-yyyynoom@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: dlink: Correct endianness handling of led_mode

2025-05-09T07:50:43+00:00

[ Upstream commit e7e5ae71831c44d58627a991e603845a2fed2cab ] As it's name suggests, parse_eeprom() parses EEPROM data. This is done by reading data, 16 bits at a time as follows: for (i = 0; i < 128; i++) ((__le16 *) sromdata)[i] = cpu_to_le16(read_eeprom(np, i)); sromdata is at the same memory location as psrom. And the type of psrom is a pointer to struct t_SROM. As can be seen in the loop above, data is stored in sromdata, and thus psrom, as 16-bit little-endian values. However, the integer fields of t_SROM are host byte order integers. And in the case of led_mode this leads to a little endian value being incorrectly treated as host byte order. Looking at rio_set_led_mode, this does appear to be a bug as that code masks led_mode with 0x1, 0x2 and 0x8. Logic that would be effected by a reversed byte order. This problem would only manifest on big endian hosts. Found by inspection while investigating a sparse warning regarding the crc field of t_SROM. I believe that warning is a false positive. And although I plan to send a follow-up to use little-endian types for other the integer fields of PSROM_t I do not believe that will involve any bug fixes. Compile tested only. Fixes: c3f45d322cbd ("dl2k: Add support for IP1000A-based cards") Signed-off-by: Simon Horman Link: https://patch.msgid.link/20250425-dlink-led-mode-v1-1-6bae3c36e736@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: ethernet: dlink: replace deprecated macro

2024-08-14T11:20:55+00:00

Macro `SIMPLE_DEV_PM_OPS()` is deprecated. This patch replaces `SIMPLE_DEV_PM_OPS()` with `DEFINE_SIMPLE_DEV_PM_OPS()` currently used. Expanded results are the same since remaining member is initialized as zero (NULL): static SIMPLE_DEV_PM_OPS(rio_pm_ops, rio_suspend, rio_resume); Expanded to: static const struct dev_pm_ops __attribute__((__unused__)) rio_pm_ops = { .suspend = ((1) ? ((rio_suspend)) : ((void *)0)), .resume = ((1) ? ((rio_resume)) : ((void *)0)), .freeze = ((1) ? ((rio_suspend)) : ((void *)0)), .thaw = ((1) ? ((rio_resume)) : ((void *)0)), .poweroff = ((1) ? ((rio_suspend)) : ((void *)0)), .restore = ((1) ? ((rio_resume)) : ((void *)0)), }; static DEFINE_SIMPLE_DEV_PM_OPS(rio_pm_ops, rio_suspend, rio_resume); Expanded to: static const struct dev_pm_ops rio_pm_ops = { .suspend = ((1) ? ((rio_suspend)) : ((void *)0)), .resume = ((1) ? ((rio_resume)) : ((void *)0)), .freeze = ((1) ? ((rio_suspend)) : ((void *)0)), .thaw = ((1) ? ((rio_resume)) : ((void *)0)), .poweroff = ((1) ? ((rio_suspend)) : ((void *)0)), .restore = ((1) ? ((rio_resume)) : ((void *)0)), .runtime_suspend = ((void *)0), .runtime_resume = ((void *)0), .runtime_idle = ((void *)0), }; Signed-off-by: Moon Yeounsu Reviewed-by: Simon Horman Signed-off-by: David S. Miller

net: annotate writes on dev->mtu from ndo_change_mtu()

2024-05-07T23:19:14+00:00

Simon reported that ndo_change_mtu() methods were never updated to use WRITE_ONCE(dev->mtu, new_mtu) as hinted in commit 501a90c94510 ("inet: protect against too small mtu values.") We read dev->mtu without holding RTNL in many places, with READ_ONCE() annotations. It is time to take care of ndo_change_mtu() methods to use corresponding WRITE_ONCE() Signed-off-by: Eric Dumazet Reported-by: Simon Horman Closes: https://lore.kernel.org/netdev/20240505144608.GB67882@kernel.org/ Reviewed-by: Jacob Keller Reviewed-by: Sabrina Dubroca Reviewed-by: Simon Horman Acked-by: Shannon Nelson Link: https://lore.kernel.org/r/20240506102812.3025432-1-edumazet@google.com Signed-off-by: Jakub Kicinski

net: dl2k: Use proper conversion of dev_addr before IO to device

2023-12-12T10:25:36+00:00

The driver is using iowriteXX()/ioreadXX() APIs which are LE IO accessors simplified as 1. Convert given value _from_ CPU _to_ LE 2. Write it to the device as is The dev_addr is a byte stream, but because the driver uses 16-bit IO accessors, it wants to perform double conversion on BE CPUs, but it took it wrong, as it effectivelly does two times _from_ CPU _to_ LE. What it has to do is to consider dev_addr as an array of LE16 and hence do _from_ LE _to_ CPU conversion, followed by implied _from_ CPU _to_ LE in the iowrite16(). To achieve that, use get_unaligned_le16(). This will make it correct and allows to avoid sparse warning as reported by LKP. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202312030058.hfZPTXd7-lkp@intel.com/ Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20231208153327.3306798-1-andriy.shevchenko@linux.intel.com Signed-off-by: Paolo Abeni

sundance: remove unused variable cnt

2022-11-17T12:18:30+00:00

Variable cnt is just being incremented and it's never used anywhere else. The variable and the increment are redundant so remove it. Signed-off-by: Colin Ian King Reviewed-by: Leon Romanovsky Link: https://lore.kernel.org/r/20221115093137.144002-1-colin.i.king@gmail.com Signed-off-by: Paolo Abeni

net: dl2k: remove variable tx_use

2022-10-26T02:47:30+00:00

Variable tx_use is just being incremented and it's never used anywhere else. The variable and the increment are redundant so remove it. Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20221024143501.2163720-1-colin.i.king@gmail.com Signed-off-by: Jakub Kicinski