> On Mon, Sep 28, 2026 at 08:25:55PM +0000, Manish Awasthi wrote:
> > thanks for review. Comments inline.
> >
> > > Thank you for your contribution! Sashiko AI review found 3 potential
> > > issue(s) to consider.
> > >
> > > Critical: 0 · High: 0 (1) · Medium: 1 · Low: 2
> > >
> > > If you believe none of the issues are legitimate, please reply to each
> > > issue of Medium severity or higher and explain why the AI is wrong.
> > > If any of them are legitimate and you plan to respin, please let patchwork
> > > know by including "pw-bot: cr" as a separate line at the end of your reply
> > > (one such reply per series is enough).
> > >
> > > - [Medium] The CDX transport installs `.dev_reset = mana_cdx_dev_reset`
> > > (-> `cdx_dev_reset()`) but has no way to recover afterwards.
> > > - [Low] `mana_cdx_setup_hwc_irqs()` skips IRQ affinity hints.
> > > - [Low] The comment in `mana_gd_query_max_resources()` (gdma_main.c)
> > > says: "Only reset on platforms that support dynamic MSI-X allocation;…
> > >
> > > Pre-existing issues:
> > > - [High] This problem wasn't introduced by this patch, but the shared HWC
> > > bootstrap path that the new CDX transport now reaches trusts a device-…
> > >
> > > --
> > >
> > > net: mana: Add support for CDX device ID 0x00C2
> > >
> > > This adds a CDX bus transport for MANA, built as mana_cdx.ko on top of
> > > the shared gdma_core.ko, for device ID 0x00C2. It allocates the whole MSI
> > > pool at probe time, limits the queue count to the available vectors,
> > > restricts DMA to 32 bits, and adds a per-bus auxiliary device name prefix
> > > so the CDX auxiliary devices stay separate from the PCI ones.
> > >
> > > > diff --git a/drivers/net/ethernet/microsoft/mana/gdma_cdx.c
> > > > b/drivers/net/ethernet/microsoft/mana/gdma_cdx.c
> > > > new file mode 100644
> > > > index 0000000000000..0d01e3d2f0d96
> > > > --- /dev/null
> > > > +++ b/drivers/net/ethernet/microsoft/mana/gdma_cdx.c
> > > > @@ -0,0 +1,340 @@
> > >
> > > [ ... ]
> > >
> > > > +static int mana_cdx_dev_reset(struct gdma_context *gc)
> > > > +{
> > > > + return cdx_dev_reset(gc->dev);
> > > > +}
> > >
> > > [Severity: Medium]
> > > Can this reset leave the whole function unusable, with no recovery short
> > > of a manual rebind?
> > >
> > > mana_dealloc_queues() calls it when a TX queue still has pending_sends
> > > after the drain timeout:
> > >
> > > mana_tx_timeout()
> > > -> queue_reset_work
> > > -> mana_per_port_queue_reset_work_handler()
> > > -> mana_dealloc_queues()
> > > -> mana_gd_dev_reset()
> > > -> mana_cdx_dev_reset()
> > > -> cdx_dev_reset()
> > >
> > This version of the driver doesn't support recovery after
> > mana_cdx_dev_reset.
>
> I don't think it needs to delay progress of this patchset.
> But I am curious to know if there are plans to add such support.
>
It is possible to have similar recovery support as the pci in this path
after cdx_dev_reset() and we do have plans to add it in future.
> ...
