Hi all,
I'm currently working on implementing support for the Management
Controller Transport Protocol (MCTP). Briefly, MCTP is a protocol for
intra-system communication between a management controller (typically a
BMC), and the devices it manages. If you're after the full details, the
DMTF have a
Hi David,
> It seems logical to me that what the chip does is align up the total
> sub-packet length to a multiple of 4 or larger, and then add those two
> prefix padding bytes. Otherwise the prefix padding won't necessarily
> and reliably align the IP header after the link level header.
Yep, th
Hi David,
> > Those last two bytes - 96 1f - aren't part of the original packet.
>
> Does this happen for non-tail packets in a multi-packet cluster?
I believe so, yes. I haven't been able to reliably reproduce the multi-
packet behaviour though, so input from ASIX would be good.
>
> Because t
the spelling of 'pseudo'.
Signed-off-by: Jeremy Kerr
---
drivers/net/usb/ax88179_178a.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 93044cf1417a..1fe4cc28d154 100644
--- a/drivers/n
Hi Louis,
> Thanks for the correction.
> Indeed, the hardware adds two bytes dummy data at beginning of
> Ethernet packet to make IP header aligned.
> The original patch made by Freddy contains the length of dummy
> header.
OK, thanks for checking. I understand this to mean that the fix is
corr
hile we're moving
> the comment around, this also fixes the spelling of 'pseudo'.
>
> Signed-off-by: Jeremy Kerr
>
> ---
> RFC: I don't have access to docs for this hardware, so this is all based
> on observed behaviour of the reported packet length.
the spelling of 'pseudo'.
Signed-off-by: Jeremy Kerr
---
RFC: I don't have access to docs for this hardware, so this is all based
on observed behaviour of the reported packet length.
---
drivers/net/usb/ax88179_178a.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-
posed fix from Finn Thain .
Signed-off-by: Jeremy Kerr
Reported-by: Stan Johnson
Tested-by: Stan Johnson
Reported-by: Finn Thain
---
drivers/net/ethernet/apple/bmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/apple/bmac.c
b/drivers/net/ether
Hi Stan,
> The new kernel compiled and booted with no errors, with these
> STACKPROTECTOR options in .config (the last two revealed the bug):
>
> CONFIG_HAVE_STACKPROTECTOR=y
> CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
> CONFIG_STACKPROTECTOR=y
> CONFIG_STACKPROTECTOR_STRONG=y
Brilliant, thanks for te
; we're
reading two bytes at a time there.
Can you try the attached patch?
Ben/Paul - any thoughts?
Cheers,
Jeremy
-
>From 141b20bcbdb3ad7c166b83b4ea61f3521d0a0679 Mon Sep 17 00:00:00 2001
From: Jeremy Kerr
Date: Mon, 18 May 2020 08:54:25 +0800
Subject: [PATCH] net: bmac: Fix r
es change, we should see an
separate AEN for that event.
Acked-by: Jeremy Kerr
However: we're looking at some behaviour of Broadcom NICs at the moment,
where the phy will be reset on link change events. We'd want to make
sure that we're not just seeing the HNCDSC events for tha
11 matches
Mail list logo
