lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 21 May 2020 19:30:04 +0800
From:   Shengjiu Wang <>
To:     Mark Brown <>
Cc:     Lucas Stach <>,
        Shengjiu Wang <>,
        Timur Tabi <>,
        Nicolin Chen <>,
        Xiubo Li <>,
        Fabio Estevam <>,
        Liam Girdwood <>,,
        Takashi Iwai <>,,,,,
        Sumit Semwal <>,
        Linux-ALSA <>,,,
        linux-kernel <>,,,
Subject: Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe

On Wed, May 20, 2020 at 8:38 PM Mark Brown <> wrote:
> On Wed, May 20, 2020 at 07:22:19PM +0800, Shengjiu Wang wrote:
> > I see some driver also request dma channel in open() or hw_params().
> > how can they avoid the defer probe issue?
> > for example´╝Ü
> > sound/arm/pxa2xx-pcm-lib.c
> > sound/soc/sprd/sprd-pcm-dma.c
> Other drivers having problems means those drivers should be fixed, not
> that we should copy the problems.  In the case of the PXA driver that's
> very old code which predates deferred probe by I'd guess a decade.


For the FE-BE case, do you have any suggestion for how fix it?

With DMA1->ASRC->DMA2->ESAI case, the DMA1->ASRC->DMA2
is in FE,  ESAI is in BE.  When ESAI drvier probe,  DMA3 channel is
created with ESAI's "dma:tx" (DMA3 channel
is not used in this FE-BE case).    When FE-BE startup, DMA2
channel is created, it needs the ESAI's "dma:tx", so the warning
comes out.

best regards
wang shengjiu

Powered by blists - more mailing lists