kernel: bump to 7.2.6

Re-apply the drivers/net/wireless/mediatek/mt76/ portion of the
7.2.5->7.2.6 bump that was reverted in e09eeb5. Tree now matches
4565f76 exactly for this path.

Signed-off-by: Rudy Andram <[email protected]>

kernel: bump to 7.2.5

Signed-off-by: Rudy Andram <[email protected]>

kernel: bump to 7.2.4

Excluded 5 files that no longer apply cleanly against the mt76/phylink
port work (drivers/net/phy/phylink.c, mt7996/{mac,mcu,eeprom}.c,
mt7925/main.c) -- their upstream context has diverged too far for a
mechanical patch and need manual porting separately.

Signed-off-by: Rudy Andram <[email protected]>

net: mediatek: make HW LRO rings usable on netsys v3

MT7988 is the only SoC in the tree that sets both MTK_HWLRO and
rss_num, so the HW LRO paths restored with the 7.0 downstream stack
have never been exercised on a netsys v3 part. Two defects fall out of
that, plus one in the proc control interface used to drive them.

mtk_rx_alloc: the MTK_RX_FLAGS_HWLRO branch sizes the ring for
MTK_MAX_LRO_RX_LENGTH (4096 * 3 + rx_buf_len), giving a ring->buf_size
of roughly 13856 bytes, and that value is what gets programmed into the
descriptor's PLEN0 field. Since mtk_page_pool_enabled() is true for
netsys v2 and above, those buffers were then backed by order-0 page
pool pages whose usable length is MTK_PP_MAX_BUF_SIZE, 3520 bytes on a
4K page. The engine is told it has 13.8K of room in a 4K page, so any
superframe past three segments is a DMA write past the page, followed
by skb_put() on a build_skb(data, PAGE_SIZE). Upstream never hit this
because it only sets MTK_HWLRO on netsys v1 parts, where the page pool
is not used. Keep HW LRO rings on the high-order frag allocator, which
is the path they were written for. XDP is already refused when
eth->hwlro is set, and both mtk_poll_rx() and mtk_rx_clean() branch on
ring->page_pool, so nothing else needs to change.

mtk_poll_rx: hw_lro_stats_update() and hw_lro_flush_stats_update() are
defined in mtk_eth_dbg.c and declared in mtk_eth_dbg.h but have no call
site, so every counter in /proc/mtketh/hw_lro_stats reads zero whatever
the hardware does, and mtk_hwlro_stats_ebl - the gate that
"echo 5 1 > /proc/mtketh/hw_lro_auto_tlb" sets - is written and never
read. That makes the file actively misleading when debugging LRO
aggregation. Restore the accounting hook behind that gate.
MTK_HW_LRO_RING(eth, 0) is 4 on netsys v3 and 1 on v1, which selects
rings 4-7 and 1-3 respectively and matches the index arithmetic in
hw_lro_stats_update(); eth->hwlro keeps it off MT7986/MT7981, where
rings 1-3 are RSS.

hw_lro_auto_tlb_write: lro_dbg_func[x] is dereferenced before x is
bounds checked, and x is a signed long straight out of kstrtol(), so a
stray "echo 9 1" or "echo -1 1" calls through whatever lies outside the
array. Check first. While here, stop discarding the kstrtol() return
values; the old code fell through to lro_dbg_func[0] on malformed
input.

Signed-off-by: Rudy Andram <[email protected]>

kernel: bump to 7.2.3

Signed-off-by: Rudy Andram <[email protected]>

net: mediatek: fix build fallout from the 7.0 stack revert

Three build failures from replaying the 7.0 downstream ethernet and mt76
stacks onto 7.2.

mtk_eth_soc: the 7.0 revert made _mtk_mdio_{read,write}_c{22,45}() static,
but mtk_eth_dbg.h declares them extern and mtk_eth_dbg.c calls them from
nine sites. The 7.2 base had them non-static for exactly this reason.
Restore external linkage; this is a follow-up to "keep mtk_eth_dbg across
the 7.0 stack revert", which restored the file but not the linkage its
callers need.

mtk_ppe_offload: mtk_nf_conn_acct_find() tests ext->gen_id, but the
conntrack extension genid mechanism (struct nf_ct_ext.gen_id) does not
exist in 7.2. 7.1 hit the same problem and dropped the check in "kernel:
bump to 7.1.5"; that adaptation rode along with a stable bump and so was
not part of the ported series. Apply the same one-line fix, which matches
the in-tree nf_conn_acct_find() helper.

mt7921: the 7.0 alignment reverted MT7902 support out of mt792x.h and
mt7921.h and dropped the pci.c/sdio.c device entries, but the usb.c
device-table entry survived and still referenced MT7902_FIRMWARE_WM.
Remove it, leaving the mt7921 stack consistently MT7902-free and matching
the 7.1 tree, where the table also starts at 0x7961.

Signed-off-by: Rudy Andram <[email protected]>

kernel: bump to 7.2.2

Signed-off-by: Rudy Andram <[email protected]>

kernel: bump to 7.1.11

Signed-off-by: Rudy Andram <[email protected]>

kernel: bump to 7.1.10

Signed-off-by: Rudy Andram <[email protected]>

net: dsa: mxl862xx_downstream: add devlink firmware flash support

The BPI-R4 Pro 8X kernel i use, uses the downstream MxL862xx driver, which implements
neither .devlink_info_get nor .devlink_flash_update, so "devlink dev info
mdio_bus/mdio-bus:10" fails with -EOPNOTSUPP and there is no in-kernel
path to update the switch firmware.  The flash implementation only exists
in the upstream-style mxl862xx driver, which cannot be used on this board
because it follows an incompatible port numbering contract (see commit
9804cd4 "arm64: dts: restore BPI-R4 Pro 8X downstream MxL wiring").

Port the firmware update support over to the downstream driver.  The SB
PDI transfer protocol, MCUboot rescue-mode entry, CRC-32 image validation
and reprobe-after-flash handling are taken from the upstream-style driver
unchanged.  Only the driver API surface is adapted: the downstream
mxl862xx_api_wrap() takes no "quiet" argument, priv holds a struct device
pointer rather than an mdio_device, and the stats/host-flood work items
cancelled before flashing do not exist here.

The SB PDI registers live in the clause-22 paged address space rather
than in the MMD used for regular API commands, so mxl862xx_smdio_read()
and mxl862xx_smdio_write() are added alongside the existing MMD
accessors.

Guard mxl862xx_api_wrap() with block_host and skip_teardown so firmware
commands are rejected while the switch sits in MCUboot and are silently
discarded during the teardown that the post-flash reprobe triggers.  Both
flags are zero-initialised and only ever set from the flash path, so
normal operation is unaffected.

Note that the firmware can only be written, never read back: the protocol
has no dump command, so the running image cannot be backed up before an
update.

Signed-off-by: Rudy Andram <[email protected]>