Re: [PATCH v4 2/2] dmaengine: dw-edma: Add changes to support Channel Separation
"Verma, Devendra" <[email protected]>
| Newsgroups | org.kernel.vger.dmaengine,dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-pci |
|---|---|
| Message-ID | <[email protected]> |
On 19-Aug-26 12:49, [email protected] wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > > Pre-existing issues: > - [High] Error paths in `dw_edma_pcie_probe()` return directly without freeing IRQ vectors allocated by `pci_alloc_irq_vectors()`, causing an IRQ resource leak. > -- > > --- Patch [2]: [PATCH v4 2/2] dmaengine: dw-edma: Add changes to support Channel Separation --- > commit 801adc5a7230cabb747f37d2920f39c45fa66b9a > Author: Devendra K Verma <[email protected]> > > dmaengine: dw-edma: Add changes to support Channel Separation > > HDMA supports configurable DMA channel register space separation which ranges > from 256B to 32KB. Current implementation supports 256B as default for DMA > channel register space, while CPM6 uses 512B by default. > >> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c >> index f287879b2cb9e..2eb8293b87b4c 100644 >> --- a/drivers/dma/dw-edma/dw-edma-pcie.c >> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c > > [ ... ] > >> @@ -436,6 +439,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev, >> chip->nr_irqs = nr_irqs; >> chip->ops = &dw_edma_pcie_plat_ops; >> chip->cfg_non_ll = non_ll; >> + chip->ch_space_sz = vsec_data->ch_space_sz; >> >> chip->ll_wr_cnt = vsec_data->wr_ch_cnt; >> chip->ll_rd_cnt = vsec_data->rd_ch_cnt; > > [Severity: High] > This isn't a bug introduced by this patch, but looking at the error paths > just below this addition in dw_edma_pcie_probe(): > > chip->reg_base = pcim_iomap_table(pdev)[vsec_data->rg.bar]; > if (!chip->reg_base) > return -ENOMEM; > > Does this return directly without freeing the IRQ vectors allocated earlier > by pci_alloc_irq_vectors()? Failing to call pci_free_irq_vectors() in error > paths leaks IRQ resources, which can prevent future allocations and > potentially exhaust system IRQ capacity. > This is an issue and shall be taken up in a separate patch series.