- Bump kernel to 6.12.21, same as other tier one boards
- Fix#1006 byt enabling netlink for ethtool (now works!)
- Sync defconfigs:
- LIBXCRYPT now in an rdep of another package
- Disable FORCE check hashes for now
- Drop patches for 6.10 tree (r2s kernel)
- Port RTL8153b patch for R2S LAN LED support
Fixes#1006
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Only the most important bridge and usb fixes have been ported in this
commit, and a new patch for the r8153 link/traffic LEDs, ported from
the FriendlyELEC/Rockchip kernel tree.
Fixes#274
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Enable BR2_DOWNLOAD_FORCE_CHECK_HASHES for R2S
- Relocate VisionFive2 patches to global patch dir for sharing with R2S
- Add hash for ATF v2.9
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Just like other packages we should version our Linux patches as well,
even though it may be painful and cause some extra overhead, in the
end it allows multi-kernel setups and compatibility with customer's
using Infix as a BR2_EXTERNAL.
Fixes#489
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Add missing locking around standard counter groups
- Fix reference counting issue with IGMPv3/MLDv2 reports
Found as part of debugging the regression test suite on hardware.
The fact that a USB device currently is not authorized is not an error.
This patch adjusts the log level to slip below 'quiet' to prevent logs
to console at boot.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Even when `managed = "in-band-status";` was specified on a port,
mv88e6xxx would insist on forcing the values that were supposed to be
automatically picked up by the MAC via in-band signaling.
In the case of USXGMII links on 6393X, forcing the link bit would
sometimes, for reasons that are not understood, cause the SERDES to
reset its USXGMII link partner base page (register 4.0xf0a2) to 0,
which it would then interpret as 10M/half-duplex. As a result, the
SERDES would erroneously perform rate-matching to 10M on egress
towards the PHY (which is configured for 10G/full-duplex), leading to
nothing but dropped packets and much sadness.
This can most easily be reproduced by the following setup:
.------------.
| .-----. .-------.
| | p9 +---+ 3310P +--.
| 6393X :-----: :-------: | T- or X-Units looped via external cable
| | p10 +---+ 3310P +--'
| '-----' '-------'
'------------'
Make sure that neither p9 nor p10 are managed using in-band-status.
1. ip link set dev p9 up; ip link set dev p10 up
2. ip link set dev p9 down
3. ip link set dev p9 up
After step (3), p10 will experience the failure described above in
about 3/4 of the cases. In the cases where the issue does not arise,
simply repeat steps (2) and (3).
This is a forward-port of one of my bridge patches to handle RFC4541
style flooding of unknown multicast.
https://lore.kernel.org/netdev/20220411133837.318876-9-troglobit@gmail.com/
Changes since this thread: use inferred mctx (VLAN multicast context)
from br_handle_frame_finish() and br_dev_xmit(), which should fix the
per-VLAN multicast handling issue pointed out by Nikolay.
Todo before next patch series, add new option instead of breaking the
existing functionality for the current mcast_flood flag. E.g., add a
mcast_flood_always, since the current flag stops flooding when there is
a known querier on the LAN.
See the above thread for details.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Fixes the locking warnings when configuring LEDs on 6393X
- Correctly power up 3310X PHYs strapped to start powered down
- Fix kernel oops when reading from blank NVMEM configured with an
ONIE layout
In order get the ONIE EEPROM support and some mv88e6xxx related fixes,
move to 6.5.6, with the intention of upgrading again, to the next
longterm kernel, as soon as one becomes available.
Also, import patches from kkit-linux-6.5.y.
Our custom version has gone from being newer than Buildroot's default
to being older, so there is no reason for us override it anymore.
The kernel has become a bit more picky and will give nasty error
messages if a link's PHY connection is not explicitly defined, but
instead relies on implicit defaults. This was missing from the CPU
port of the CRB, so we supply a small patch to fix that.
