[PATCH 00/11] net: wwan: t9xx: Add MediaTek T9XX WWAN driver

Sergey Ryazanov ryazanov.s.a at gmail.com
Tue Jun 2 13:46:59 PDT 2026


Hi,

let me join the discussion and put my 2c.

On 6/2/26 13:58, Wu. JackBB (GSM) wrote:
> Hi Jakub,
> 
>> On Fri, 29 May 2026 18:31:39 +0800 Jack Wu via B4 Relay wrote:
>>> 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!

> 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.

> 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.

> [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?

--
Sergey



More information about the linux-arm-kernel mailing list