RE: [External Mail] Re: [PATCH v8 1/6] net: wwan: t9xx: Add PCIe core

["Wu. JackBB (GSM)" <JackBB_Wu@compal.com>]

On Sun, 20 Sep 2026 07:54:00 +0800 Jakub Kicinski wrote:

> > +struct mtk_dev_ops {
> > +     u32 (*get_dev_state)(struct mtk_md_dev *mdev);
[...]
> > +     int (*send_dev_evt)(struct mtk_md_dev *mdev, u32 dev_evt);
> > +};
>
> Please remove the abstractions which are not necessary in the initial
> version of the driver. If you have access to a good LLM these prompts
> will probably do a better job preparing the patches than you:
>
> https://github.com/kuba-moo/ai-prompts/blob/main/driver-upstreaming-prompts.md

Will fix in v9.  struct mtk_dev_ops has one implementation, pci_hw_ops,
reached through nine pass-through inlines in mtk_dev.h; both go away and
the PCIe functions are called directly.  Same treatment for
cldma_drv_ops and mtk_ctrl_hif_ops, also single-implementation, for the
mtk_t9xx.ko/mtk_t9xx_pcie.ko split, which drops nine EXPORT_SYMBOL_GPL()s
and mtk_dev.c, and for the three _m9xx files, which parameterise a single
struct mtk_pci_dev_cfg shared by both PCI IDs.  port_ops stays: two
implementations here, three with the follow-up work.  We checked the
whole out-of-tree tree, not just this series - none of the removed ones
gains a second implementation later.

Two questions on the prompts document.

Are the following hard requirements the series has to meet, or targets
for the tool?

 - line 44: "Ideal patches are between 200 and 700 LoC (added +
   removed, not counting context)."
 - line 46: "Avoid series larger than 2.5k LoC. The first series is
   usually larger, but must not exceed 4k LoC."
 - lines 57-58: "Series 1 should aim to add the simplest possible
   version of the driver which nonetheless can send and receive a
   trivial (no offloads) packet."
 - line 117: "Avoid the use of managed APIs (``devm_``, ``pcim_``)."

On the packet one: this series carries no netdev because an earlier
review found the driver too large to submit at once, so the network
functionality was split into follow-up series.

The document also asks for no defensive checks (lines 119-120) and few
code comments (line 124).  That runs against the direction of the AI review
we have been getting, where both have been growing.  Is the current
direction still fine?

Thanks,
Jack