lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 5 Dec 2020 22:11:39 +0100 From: Rasmus Villemoes <rasmus.villemoes@...vas.dk> To: Jakub Kicinski <kuba@...nel.org> Cc: Li Yang <leoyang.li@....com>, "David S. Miller" <davem@...emloft.net>, Qiang Zhao <qiang.zhao@....com>, netdev@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Vladimir Oltean <vladimir.oltean@....com> Subject: Re: [PATCH 00/20] ethernet: ucc_geth: assorted fixes and simplifications On 05/12/2020 21.53, Jakub Kicinski wrote: > On Sat, 5 Dec 2020 20:17:23 +0100 Rasmus Villemoes wrote: >> While trying to figure out how to allow bumping the MTU with the >> ucc_geth driver, I fell into a rabbit hole and stumbled on a whole >> bunch of issues of varying importance - some are outright bug fixes, >> while most are a matter of simplifying the code to make it more >> accessible. >> >> At the end of digging around the code and data sheet to figure out how >> it all works, I think the MTU issue might be fixed by a one-liner, but >> I'm not sure it can be that simple. It does seem to work (ping -s X >> works for larger values of X, and wireshark confirms that the packets >> are not fragmented). >> >> Re patch 2, someone in NXP should check how the hardware actually >> works and make an updated reference manual available. > > Looks like a nice clean up on a quick look. > > Please separate patches 1 and 11 (which are the two bug fixes I see) I think patch 2 is a bug fix as well, but I'd like someone from NXP to comment. > rebase (retest) and post them against the net tree: > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/ So I thought this would go through Li Yang's tree. That's where my previous QE related patches have gone through, and at least some need some input from NXP folks - and what MAINTAINERS suggests. So not marking the patches with net or net-next was deliberate. But I'm happy to rearrange and send to net/net-next as appropriate if that's what you and Li Yang can agree to. Thanks, Rasmus
Powered by blists - more mailing lists