Re: [PATCH v2 net] staging: octeon: Drop on uncorrectable alignment or FCS error

clear what is going on here. Can this > incorrectly match a destination MAC address of xD:XX:XX:XX:XX:XX. > >> /* Port received 0xd preamble */ >> work->packet_ptr.s.addr += i; >> work->word1.len -= i + 4; -- Best regards, Alexander Sverdlin.

Re: [PATCH] stating: octeon: Drop on uncorrectable alignment or FCS error

to match the old code and it no longer matches. > (Please update the whitespace). thanks to your comment I took a fresh look onto the patch and found a logic error in the change. Please ignore the whole patch for now. >> /* >> * We received a packet with either an alignment error -- Best regards, Alexander Sverdlin.

Re: [PATCH] staging: octeon: repair "fixed-link" support

Hello Greg, Dave and all, the below patch is still applicable as-is, would you please re-consider it now, as the driver has been undeleted? On 08/01/2020 17:09, Alexander X Sverdlin wrote: > From: Alexander Sverdlin > > The PHYs must be registered once in device probe function, not

Re: [PATCH] staging: octeon: Drop on uncorrectable alignment or FCS error

Hello Greg, On 10/01/2020 13:48, Greg Kroah-Hartman wrote: > On Wed, Jan 08, 2020 at 05:10:42PM +0100, Alexander X Sverdlin wrote: >> From: Alexander Sverdlin >> >> Currently in case of alignment or FCS error if the packet cannot be >> corrected it's still not dr

Multicast from underlying MACVLAN interface towards MACVLAN

0x10/0x10 ? trace_hardirqs_on+0x2c/0xe0 ? __sys_sendmsg+0x63/0xa0 __sys_sendmsg+0x63/0xa0 do_syscall_64+0x6c/0x1e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe I would appreciate any hint, how to approach this problem! I can try to come up with a patch, but as this is so central thing in the

[PATCH] net: cavium: Add fine-granular dependencies on PCI

Add dependencies on PCI where necessary. Fixes: 7e2bc7fb65 ("net: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI") Signed-off-by: Alexander Sverdlin --- drivers/net/ethernet/cavium/Kconfig | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/ne

[PATCH v2] net: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI

Octeon Ethernet drivers work perfectly without PCI. Signed-off-by: Alexander Sverdlin --- drivers/net/ethernet/cavium/Kconfig | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/cavium/Kconfig b/drivers/net/ethernet/cavium/Kconfig index

[PATCH] octeon_mgmt: Fix MIX registers configuration on MTU setup

From: Alexander Sverdlin octeon_mgmt driver doesn't drop RX frames that are 1-4 bytes bigger than MTU set for the corresponding interface. The problem is in the AGL_GMX_RX0/1_FRM_MAX register setting, which should not account for VLAN tagging. According to Octeon HW manual: "For tag

[PATCH] net: cavium: Drop dependency of NET_VENDOR_CAVIUM on PCI

Octeon Ethernet drivers work perfectly without PCI. Signed-off-by: Alexander Sverdlin --- drivers/net/ethernet/cavium/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/cavium/Kconfig b/drivers/net/ethernet/cavium/Kconfig index 043e3c11c42b..4c3a5c354497 100644

Re: [PATCH v2 net-next 06/12] ep93xx_eth: add GRO support

Hello all, On 15/05/17 23:02, Alexander Sverdlin wrote: >>> I don't know if we really care about this hardware anymore (I don't), >>> but the ep93xx platform is still listed as being maintained in the >>> MAINTAINERS file -- adding Ryan and Hartley. >> I

Re: [PATCH v2 net-next 06/12] ep93xx_eth: add GRO support

Hi! On Mon May 15 22:43:20 2017 Ryan Mallon wrote: > > I don't know if we really care about this hardware anymore (I don't), > > but the ep93xx platform is still listed as being maintained in the > > MAINTAINERS file -- adding Ryan and Hartley. > > I no longer have any ep93xx hardware to test wi

Re: [PATCH 3/4] xfrm: Prepare for CRYPTO_MAX_ALG_NAME expansion

> > Signed-off-by: Herbert Xu Acked-by: Alexander Sverdlin Tested-by: Alexander Sverdlin > --- > > net/xfrm/xfrm_user.c |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c > index 9

Re: [PATCH 4/4] crypto: api - Extend algorithm name limit to 128 bytes

limit to 128 bytes. > > Reported-by: Alexander Sverdlin > Signed-off-by: Herbert Xu Acked-by: Alexander Sverdlin Tested-by: Alexander Sverdlin > --- > > include/linux/crypto.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/cryp

Re: [PATCH 1/4] crypto: user - Prepare for CRYPTO_MAX_ALG_NAME expansion

> This way the user-space API will not be modified when we raise > the value of CRYPTO_MAX_ALG_NAME. > > Furthermore, the code has been updated to handle names longer than > the user-space API. They will be truncated. > > Signed-off-by: Herbert Xu Acked-by: Alexander Sve

Re: [PATCH 0/4] crypto: CRYPTO_MAX_ALG_NAME is too low

Hi! On 06/04/17 10:15, Herbert Xu wrote: > On Thu, Mar 16, 2017 at 03:16:29PM +0100, Alexander Sverdlin wrote: >> This is a regression caused by 856e3f4092 >> ("crypto: seqiv - Add support for new AEAD interface") >> >> As I've said above, I can offer on

Re: [PATCH 2/4] crypto: af_alg - Allow arbitrarily long algorithm names

type = alg_get_type(sa->salg_type); > if (IS_ERR(type) && PTR_ERR(type) == -ENOENT) { Why should userspace ever extend the structure if salg_name is hardcoded to 64 in if_alg.h? This patch doesn't change the behavior at all, or am I missing something? -- Best regards, Alexander Sverdlin.

Re: [PATCH] rionet: Don't try to corrupt skbuff assigning data pointer directly

arithmetics in all other cases. We cannot do better as just >> > compare them and report BUG() in case of mismatch. >> > >> > Signed-off-by: Alexander Sverdlin > BUG takes the entire machine out, which is worse than corrupting the > skb->data > > If y

[PATCH] rionet: Don't try to corrupt skbuff assigning data pointer directly

d-off-by: Alexander Sverdlin --- We came across this problem developing new code for Octeon2 RAPIDIO. For the last 10 years since original commit of the code this assignment did nothing as the pointers were always same. But the bug in the new code discovered this one. So better do BUG() immedi

[PATCH resend] sctp: Fix race between OOTB responce and route removal

- not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0x8100 (relocation range: 0x8000-0x9fff) drm_kms_helper: panic occurred, switching back to text console ---[ end Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Alexander Sverdli