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]>
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]>
Ksawlii
pushed a commit
to Ksawlii/android_kernel_samsung_a53x-FireAsf
that referenced
this issue
Nov 19, 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]>
ethicalfighter56
pushed a commit
to ethicalfighter56/android_kernel_realme_x2pro_sm8150
that referenced
this issue
Nov 22, 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]>
fus0g
pushed a commit
to sm8350-martini/kernel_oneplus_sm8350
that referenced
this issue
Nov 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]>
XeroMz69
pushed a commit
to XeroMz69/Bumi-Kernel-Tree
that referenced
this issue
Dec 1, 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]>
pyo3377
pushed a commit
to pyo3377/kernel_xiaomi_mojito
that referenced
this issue
Dec 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]>
Anush02198
pushed a commit
to xiaomi-sdm678/android_kernel_xiaomi_mojito
that referenced
this issue
Dec 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]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
nzlnice
pushed a commit
to nzlnice/crux-marisa
that referenced
this issue
Dec 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]>
FakeShell
pushed a commit
to FuriLabs/linux-android-furiphone-krypton
that referenced
this issue
Dec 7, 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]>
build-13
pushed a commit
to build-13/kernel_xiaomi_mojito
that referenced
this issue
Dec 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]> Signed-off-by: build-13 <[email protected]>
build-13
pushed a commit
to build-13/kernel_xiaomi_mojito
that referenced
this issue
Dec 18, 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]> Signed-off-by: build-13 <[email protected]>
build-13
pushed a commit
to build-13/kernel_xiaomi_mojito
that referenced
this issue
Dec 18, 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]> Signed-off-by: build-13 <[email protected]>
build-13
pushed a commit
to build-13/kernel_xiaomi_mojito
that referenced
this issue
Dec 25, 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]> Signed-off-by: build-13 <[email protected]>
build-13
pushed a commit
to build-13/kernel_xiaomi_mojito
that referenced
this issue
Dec 25, 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]> Signed-off-by: build-13 <[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: