<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/net, branch v5.4.150</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.150</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.150'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2021-09-30T08:09:26Z</updated>
<entry>
<title>net: 6pack: Fix tx timeout and slot time</title>
<updated>2021-09-30T08:09:26Z</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2021-09-09T03:57:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d193f7dbf4ec520e1ca8f11667fe929ec4c0becc'/>
<id>urn:sha1:d193f7dbf4ec520e1ca8f11667fe929ec4c0becc</id>
<content type='text'>
[ Upstream commit 3c0d2a46c0141913dc6fd126c57d0615677d946e ]

tx timeout and slot time are currently specified in units of HZ.  On
Alpha, HZ is defined as 1024.  When building alpha:allmodconfig, this
results in the following error message.

  drivers/net/hamradio/6pack.c: In function 'sixpack_open':
  drivers/net/hamradio/6pack.c:71:41: error:
  	unsigned conversion from 'int' to 'unsigned char'
  	changes value from '256' to '0'

In the 6PACK protocol, tx timeout is specified in units of 10 ms and
transmitted over the wire:

    https://www.linux-ax25.org/wiki/6PACK

Defining a value dependent on HZ doesn't really make sense, and
presumably comes from the (very historical) situation where HZ was
originally 100.

Note that the SIXP_SLOTTIME use explicitly is about 10ms granularity:

        mod_timer(&amp;sp-&gt;tx_t, jiffies + ((when + 1) * HZ) / 100);

and the SIXP_TXDELAY walue is sent as a byte over the wire.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: i825xx: Use absolute_pointer for memcpy from fixed memory location</title>
<updated>2021-09-30T08:09:25Z</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2021-09-15T03:52:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=113a8edfb9c9fbdc16d967f2a0b539266e999f94'/>
<id>urn:sha1:113a8edfb9c9fbdc16d967f2a0b539266e999f94</id>
<content type='text'>
[ Upstream commit dff2d13114f0beec448da9b3716204eb34b0cf41 ]

gcc 11.x reports the following compiler warning/error.

  drivers/net/ethernet/i825xx/82596.c: In function 'i82596_probe':
  arch/m68k/include/asm/string.h:72:25: error:
	'__builtin_memcpy' reading 6 bytes from a region of size 0 [-Werror=stringop-overread]

Use absolute_pointer() to work around the problem.

Cc: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: stmmac: allow CSR clock of 300MHz</title>
<updated>2021-09-30T08:09:24Z</updated>
<author>
<name>Jesper Nilsson</name>
<email>jesper.nilsson@axis.com</email>
</author>
<published>2021-09-10T19:55:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=29c70b0d335a2f5d1a8a2e7dad2b50f80d71b8aa'/>
<id>urn:sha1:29c70b0d335a2f5d1a8a2e7dad2b50f80d71b8aa</id>
<content type='text'>
[ Upstream commit 08dad2f4d541fcfe5e7bfda72cc6314bbfd2802f ]

The Synopsys Ethernet IP uses the CSR clock as a base clock for MDC.
The divisor used is set in the MAC_MDIO_Address register field CR
(Clock Rate)

The divisor is there to change the CSR clock into a clock that falls
below the IEEE 802.3 specified max frequency of 2.5MHz.

If the CSR clock is 300MHz, the code falls back to using the reset
value in the MAC_MDIO_Address register, as described in the comment
above this code.

However, 300MHz is actually an allowed value and the proper divider
can be estimated quite easily (it's just 1Hz difference!)

A CSR frequency of 300MHz with the maximum clock rate value of 0x5
(STMMAC_CSR_250_300M, a divisor of 124) gives somewhere around
~2.42MHz which is below the IEEE 802.3 specified maximum.

For the ARTPEC-8 SoC, the CSR clock is this problematic 300MHz,
and unfortunately, the reset-value of the MAC_MDIO_Address CR field
is 0x0.

This leads to a clock rate of zero and a divisor of 42, and gives an
MDC frequency of ~7.14MHz.

Allow CSR clock of 300MHz by making the comparison inclusive.

Signed-off-by: Jesper Nilsson &lt;jesper.nilsson@axis.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: macb: fix use after free on rmmod</title>
<updated>2021-09-30T08:09:24Z</updated>
<author>
<name>Tong Zhang</name>
<email>ztong0001@gmail.com</email>
</author>
<published>2021-09-08T19:02:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1da750d1e2140ef43d64d17f301ff6f41b45541e'/>
<id>urn:sha1:1da750d1e2140ef43d64d17f301ff6f41b45541e</id>
<content type='text'>
[ Upstream commit d82d5303c4c539db86588ffb5dc5b26c3f1513e8 ]

plat_dev-&gt;dev-&gt;platform_data is released by platform_device_unregister(),
use of pclk and hclk is a use-after-free. Since device unregister won't
need a clk device we adjust the function call sequence to fix this issue.

[   31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci]
[   31.275563] Freed by task 306:
[   30.276782]  platform_device_release+0x25/0x80

Suggested-by: Nicolas Ferre &lt;Nicolas.Ferre@microchip.com&gt;
Signed-off-by: Tong Zhang &lt;ztong0001@gmail.com&gt;
Acked-by: Nicolas Ferre &lt;nicolas.ferre@microchip.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/mlx4_en: Don't allow aRFS for encapsulated packets</title>
<updated>2021-09-30T08:09:23Z</updated>
<author>
<name>Aya Levin</name>
<email>ayal@nvidia.com</email>
</author>
<published>2021-09-23T06:51:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d0f4a2eeebbe0cbdb0e493733f8578e334074cb4'/>
<id>urn:sha1:d0f4a2eeebbe0cbdb0e493733f8578e334074cb4</id>
<content type='text'>
[ Upstream commit fdbccea419dc782079ce5881d2705cc9e3881480 ]

Driver doesn't support aRFS for encapsulated packets, return early error
in such a case.

Fixes: 1eb8c695bda9 ("net/mlx4_en: Add accelerated RFS support")
Signed-off-by: Aya Levin &lt;ayal@nvidia.com&gt;
Signed-off-by: Tariq Toukan &lt;tariqt@nvidia.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>qed: rdma - don't wait for resources under hw error recovery flow</title>
<updated>2021-09-30T08:09:23Z</updated>
<author>
<name>Shai Malin</name>
<email>smalin@marvell.com</email>
</author>
<published>2021-09-22T10:53:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ae7b957ef0032bc0267aac9476dec7cfd00a9dde'/>
<id>urn:sha1:ae7b957ef0032bc0267aac9476dec7cfd00a9dde</id>
<content type='text'>
[ Upstream commit 1ea7812326004afd2803cc968a4776ae5120a597 ]

If the HW device is during recovery, the HW resources will never return,
hence we shouldn't wait for the CID (HW context ID) bitmaps to clear.
This fix speeds up the error recovery flow.

Fixes: 64515dc899df ("qed: Add infrastructure for error detection and recovery")
Signed-off-by: Michal Kalderon &lt;mkalderon@marvell.com&gt;
Signed-off-by: Ariel Elior &lt;aelior@marvell.com&gt;
Signed-off-by: Shai Malin &lt;smalin@marvell.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>bnxt_en: Fix TX timeout when TX ring size is set to the smallest</title>
<updated>2021-09-30T08:09:23Z</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2021-09-20T06:51:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=363438ed5de0479dea926667a6abe6043eda3e66'/>
<id>urn:sha1:363438ed5de0479dea926667a6abe6043eda3e66</id>
<content type='text'>
[ Upstream commit 5bed8b0704c9ecccc8f4a2c377d7c8e21090a82e ]

The smallest TX ring size we support must fit a TX SKB with MAX_SKB_FRAGS
+ 1.  Because the first TX BD for a packet is always a long TX BD, we
need an extra TX BD to fit this packet.  Define BNXT_MIN_TX_DESC_CNT with
this value to make this more clear.  The current code uses a minimum
that is off by 1.  Fix it using this constant.

The tx_wake_thresh to determine when to wake up the TX queue is half the
ring size but we must have at least BNXT_MIN_TX_DESC_CNT for the next
packet which may have maximum fragments.  So the comparison of the
available TX BDs with tx_wake_thresh should be &gt;= instead of &gt; in the
current code.  Otherwise, at the smallest ring size, we will never wake
up the TX queue and will cause TX timeout.

Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadocm.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>enetc: Fix illegal access when reading affinity_hint</title>
<updated>2021-09-30T08:09:22Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@nxp.com</email>
</author>
<published>2021-09-17T10:22:05Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4c4c3052911b577920353a7646e4883d5da40c28'/>
<id>urn:sha1:4c4c3052911b577920353a7646e4883d5da40c28</id>
<content type='text'>
[ Upstream commit 7237a494decfa17d0b9d0076e6cee3235719de90 ]

irq_set_affinity_hit() stores a reference to the cpumask_t
parameter in the irq descriptor, and that reference can be
accessed later from irq_affinity_hint_proc_show(). Since
the cpu_mask parameter passed to irq_set_affinity_hit() has
only temporary storage (it's on the stack memory), later
accesses to it are illegal. Thus reads from the corresponding
procfs affinity_hint file can result in paging request oops.

The issue is fixed by the get_cpu_mask() helper, which provides
a permanent storage for the cpumask_t parameter.

Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@nxp.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: hso: fix muxed tty registration</title>
<updated>2021-09-30T08:09:22Z</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2021-09-17T10:12:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=acce91ba0d9fcb07d38977ed3315d4e79e5d320c'/>
<id>urn:sha1:acce91ba0d9fcb07d38977ed3315d4e79e5d320c</id>
<content type='text'>
commit e8f69b16ee776da88589b5271e3f46020efc8f6c upstream.

If resource allocation and registration fail for a muxed tty device
(e.g. if there are no more minor numbers) the driver should not try to
deregister the never-registered (or already-deregistered) tty.

Fix up the error handling to avoid dereferencing a NULL pointer when
attempting to remove the character device.

Fixes: 72dc1c096c70 ("HSO: add option hso driver")
Cc: stable@vger.kernel.org	# 2.6.27
Signed-off-by: Johan Hovold &lt;johan@kernel.org&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: stmmac: reset Tx desc base address before restarting Tx</title>
<updated>2021-09-26T12:07:09Z</updated>
<author>
<name>Jongsung Kim</name>
<email>neidhard.kim@lge.com</email>
</author>
<published>2019-12-06T11:40:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3c1d9b650c0802c003ed70bab4fc01476000bb46'/>
<id>urn:sha1:3c1d9b650c0802c003ed70bab4fc01476000bb46</id>
<content type='text'>
commit f421031e3ff0dd288a6e1bbde9aa41a25bb814e6 upstream.

Refer to the databook of DesignWare Cores Ethernet MAC Universal:

6.2.1.5 Register 4 (Transmit Descriptor List Address Register

If this register is not changed when the ST bit is set to 0, then
the DMA takes the descriptor address where it was stopped earlier.

The stmmac_tx_err() does zero indices to Tx descriptors, but does
not reset HW current Tx descriptor address. To fix inconsistency,
the base address of the Tx descriptors should be rewritten before
restarting Tx.

Signed-off-by: Jongsung Kim &lt;neidhard.kim@lge.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Macpaul Lin &lt;macpaul.lin@mediatek.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
