Re: [PATCH net-next v2 2/2] net: ethernet: mtk_eth_soc: add 9K jumbo frame

[Sandeep Haemoon <sandeeph@loljews.com>]

Thanks. All ten findings are valid; v3 fixes them.  The same applies to the
two findings in the review of 1/2.

- XDP: mtk_xdp_setup() and mtk_change_mtu() now compare the shared
  mtk_rx_buf_len()/eth->rx_buf_len against MTK_PP_MAX_BUF_SIZE, so a
  program can no longer attach when the rings have no page_pool, whether
  the large MTU is set on the same MAC or on another one.
- Every SoC: the RX buffer floor stays at 2K, so MTUs up to 2K keep
  working at runtime, DSA user ports included, and mtk_change_mtu() now
  rejects only a change that needs larger buffers (-EBUSY on growth), so
  lowering an MTU no longer locks the port out of further changes.
- MT7628: the 1518 max_mtu branch is restored; dropping it was not
  intended.
- Commit message: corrected. The series does not include the runtime
  reallocation, and mtk_hw_init() uses the shared length now, so the
  description matches the three call sites.
- PDMA RX SDL: the field is masked and replaced instead of OR-ed, so it
  no longer accumulates across opens.
- XMAC_RX_CFG2: read-modify-write, so the bits outside the length field
  survive.
- MAC limits: rewritten on every mac_config(), so a reopen after a
  smaller MTU narrows the MACs that still carry the old limit.
- Order-2 buffers: acknowledged as the cost of the downstream design and
  documented; the unused QDMA ring carrying half of it is a separate
  follow-up.
- Comment and commit text: fixed.

The page_pool gate in 1/2 is also changed as suggested there: it now
tests ring->buf_size <= MTK_PP_MAX_BUF_SIZE, since frag_size is computed
with the netdev_alloc_frag() layout and does not describe what the pool
can map.

v3: https://lore.kernel.org/all/patch-aad4cfa8d9522d1f7dbc9893ea12e813@loljews.com/

pw-bot: cr