disable genet receiver when disabling dma in firmware instead of linux genet reset #1882
Comments
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 1, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 1, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 1, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 2, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 2, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 2, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 2, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 2, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 2, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 2, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 2, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 3, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 3, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 3, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Apr 3, 2024
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 10, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 10, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 10, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 10, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 10, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 10, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 10, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 11, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 11, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 11, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 11, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 11, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 11, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
May 11, 2024
[ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
hoaysly
pushed a commit
to hoaysly/android_kernel_oneplus_msm8998-4.14
that referenced
this issue
Jul 6, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/linux-mvista
that referenced
this issue
Jul 9, 2024
Source: Kernel.org MR: 143707 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.4.y ChangeID: c0edb6797bdfbeb975ab8367a368ccf4068802bd Description: [ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Armin Kuster <[email protected]>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/linux-mvista
that referenced
this issue
Jul 9, 2024
Source: Kernel.org MR: 143210 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.10.y ChangeID: 1fb7ab9a6e3eb4ea71a02b8b27fe2a95cc1213af Description: [ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Armin Kuster <[email protected]>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/linux-mvista
that referenced
this issue
Jul 9, 2024
Source: Kernel.org MR: 143210 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.10.y ChangeID: 1fb7ab9a6e3eb4ea71a02b8b27fe2a95cc1213af Description: [ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Armin Kuster <[email protected]>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/linux-mvista
that referenced
this issue
Jul 9, 2024
Source: Kernel.org MR: 143210 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.10.y ChangeID: 1fb7ab9a6e3eb4ea71a02b8b27fe2a95cc1213af Description: [ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Armin Kuster <[email protected]>
sparkstar
pushed a commit
to sparkstar/jammy-stable
that referenced
this issue
Jul 10, 2024
BugLink: https://bugs.launchpad.net/bugs/2070028 [ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Manuel Diewald <[email protected]> Signed-off-by: Stefan Bader <[email protected]>
FerryAr
pushed a commit
to FerryAr/kernel_xiaomi_mojito
that referenced
this issue
Jul 10, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
zahid5656
pushed a commit
to zahid5656/android_kernel_realme_x2pro_sm8150
that referenced
this issue
Jul 12, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
tuxedo-bot
pushed a commit
to tuxedocomputers/linux
that referenced
this issue
Jul 17, 2024
BugLink: https://bugs.launchpad.net/bugs/2070028 [ Upstream commit 0a6380c ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Manuel Diewald <[email protected]> Signed-off-by: Stefan Bader <[email protected]>
ZorEl212
pushed a commit
to ZorEl212/android_kernel_xiaomi_ginkgo
that referenced
this issue
Jul 27, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
FerryAr
pushed a commit
to FerryAr/kernel_xiaomi_mojito
that referenced
this issue
Jul 27, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
FerryAr
pushed a commit
to FerryAr/kernel_xiaomi_mojito
that referenced
this issue
Jul 29, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
FerryAr
pushed a commit
to FerryAr/kernel_xiaomi_mojito
that referenced
this issue
Jul 29, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
ShujathMohd
pushed a commit
to ShujathMohd/kernel
that referenced
this issue
Jul 29, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
romgharti
pushed a commit
to romgharti/kernel_xiaomi_mojito
that referenced
this issue
Jul 30, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
LucasBlackLu
pushed a commit
to LucasBlackLu/kernel_google_msm-4.14
that referenced
this issue
Aug 9, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
mcf1y
pushed a commit
to mcf1y/android_kernel_xiaomi_sdm660
that referenced
this issue
Aug 15, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
wcedla
pushed a commit
to wcedla/kernel_xiaomi_sm8250_immens1ty_mod
that referenced
this issue
Aug 20, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
xt0032rus
pushed a commit
to xt0032rus/kernel_xiaomi_sm8550
that referenced
this issue
Aug 30, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: xt0032rus <[email protected]>
ahnet-69
pushed a commit
to ahnet-69/android_kernel_samsung_a32
that referenced
this issue
Sep 5, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
backslashxx
pushed a commit
to backslashxx/mojito_krenol
that referenced
this issue
Oct 2, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
fluffball3
pushed a commit
to fluffball3/android_kernel_samsung_m33x
that referenced
this issue
Oct 4, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
wanghao75
pushed a commit
to openeuler-mirror/kernel
that referenced
this issue
Oct 15, 2024
stable inclusion from stable-v5.10.217 commit 1fb7ab9a6e3eb4ea71a02b8b27fe2a95cc1213af category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAWLXC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1fb7ab9a6e3eb4ea71a02b8b27fe2a95cc1213af -------------------------------- [ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: sanglipeng1 <[email protected]>
noticesax
pushed a commit
to noticesax/sphinx_kernel_xiaomi_rosemary
that referenced
this issue
Oct 17, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
noticesax
pushed a commit
to noticesax/sphinx_kernel_xiaomi_rosemary
that referenced
this issue
Oct 17, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
noticesax
pushed a commit
to noticesax/hydrogen_kernel_xiaomi_selene
that referenced
this issue
Oct 20, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
noticesax
pushed a commit
to noticesax/hydrogen_kernel_xiaomi_selene
that referenced
this issue
Oct 20, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
hoaysly
pushed a commit
to hoaysly/android_kernel_oneplus_msm8998-4.14
that referenced
this issue
Nov 3, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
hoaysly
pushed a commit
to hoaysly/android_kernel_oneplus_msm8998-4.14
that referenced
this issue
Nov 3, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
backslashxx
pushed a commit
to backslashxx/mojito_krenol
that referenced
this issue
Nov 9, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was trying to upstream raspberrypi/linux@b65b82f (net: bcmgenet: Reset RBUF on first open) ( context: https://lore.kernel.org/netdev/[email protected]/T/ ):
And there was discussion of that it would be better to fix this in firmware, rather than try to make the workaround in kernel.
The suggestion is that likely DMA disable is not enough, and receiver reset is necessary too.
Would it be possible to try to get this fix in the firmware? I can easily test a firmware build of this (without the reset patch).
The text was updated successfully, but these errors were encountered: