Thread (31 messages) 31 messages, 6 authors, 2026-06-10

RE: [External Mail] Re: [PATCH 00/11] net: wwan: t9xx: Add MediaTek T9XX WWAN driver

flat view

From: Wu. JackBB (GSM) <hidden>
Date: 2026-06-10 10:57:40
Also in: linux-arm-kernel, linux-doc, linux-mediatek, lkml

let me join the discussion and put my 2c.

On 6/2/26 13:58, Wu. JackBB (GSM) wrote:
quoted
Hi Jakub,
quoted
On Fri, 29 May 2026 18:31:39 +0800 Jack Wu via B4 Relay wrote:
quoted
43 files changed, 14761 insertions(+)
Please try to cut this down to ~5kLoC for the initial submission.
Whatever the absolute minimum sensible chunk of code is.

Each patch must build cleanly with W=1
We've already reduced this significantly from the original 41k LoC
down to ~14.7k by stripping out non-essential features such as
exception handling, memory logging, devlink, statistics, debug
tracing, and others.

We even removed some arguably necessary features (PM, mdlog,
throughput optimizations) that we plan to submit as follow-up
series.
Great work. Highly appreciate!
quoted
Note that the line count may slightly increase in v2, as we plan
to add missing kdoc comments based on review feedback.

For reference, the t7xx driver (two generations older, simpler HW)
had an initial submission of ~11.3k LoC [1]. The t9xx hardware is
more complex, so we believe being in a similar range is reasonable.
Let me elaborate a bit here. The size problem is not due to a git or a
mailbox limitation. It arise due to the human limitation. The T7xx
submission review took something about 4 months and 8 iterations. And it
was 'only' 11.3k lines. Let's do some extrapolation assuming that
function is linear. 14.7k is 30% bigger, thus, estimated reviewing time
should be 5 months and 2 weeks. And this looks optimistic.

Recommendation, shared by Jakub, is practical. 5k lines might be
reviewed in a reasonable time and merged with the full confidence of the
quality.
quoted
We'd like to keep the driver functional and reviewable in its
current scope. Do you have any suggestions on how we could further
reduce the size while maintaining a working initial submission?
Off the top of my head, I would suggest joining T7xx and T9xx code
bases. It could be done through factoring out a core functionality of
T7xx into a library, or through making the driver layered.

I am not pretending being an expert in any of these drivers, but
generally divide-n-conqueror together with code reuse work reliable. As
an alternative, I could spend a couple of weeks reviewing the new
submission and will come with more specific ideas on what can be thrown
away or reused.
  Thank you again for the suggestions on reducing the submission size.

  We went with the split approach discussed earlier — v2 covers only the
  control plane (patches 1–6) plus a MAINTAINERS entry, bringing it down
  to ~7.9k LoC across 7 patches. The data plane will follow as a separate
  series once the control plane is accepted.

  v2 also addresses all review feedback from v1, including W=1 clean
  builds for each patch.

  Link to v2: https://patch.msgid.link/20260610-t9xx_driver_v1-v2-0-c65addf23b3f@compal.com (local)

  We would appreciate any further feedback you may have.

  Best regards,
  Jack
quoted
[1]
 https://patchwork.kernel.org/project/netdevbpf/cover/20220506181310.2183829-1-ricardo.martinez@linux.intel.com/

Thanks.


================================================================================================================================================================
This message may contain information which is private, privileged or
confidential of Compal Electronics, Inc. If you are not the intended
recipient of this message, please notify the sender and destroy/delete the
message. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon this information, by persons or
entities other than the intended recipient is prohibited.
================================================================================================================================================================
And this disclaimer does not facilitate the review. Am I 'intended'
recipient or should I destroy the message ASAP?
We apologize for any inconvenience this may cause.

Could I use my personal email address (wojackbb@gmail.com) to discuss code review?

This would avoid this issue.

Thanks.


================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help