Hi Vinod, Thanks for the review. On Sun, 9 May 2021 at 19:28, Vinod Koul <vkoul@xxxxxxxxxx> wrote: > > On 06-05-21, 03:07, Bhupesh Sharma wrote: > > Create a new header file for BAM DMA driver to make sure > > that it can be included in the follow-up patch to defer probing > > drivers which require BAM DMA driver to be first probed successfully. > > > > Cc: Thara Gopinath <thara.gopinath@xxxxxxxxxx> > > Cc: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> > > Cc: Rob Herring <robh+dt@xxxxxxxxxx> > > Cc: Andy Gross <agross@xxxxxxxxxx> > > Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > > Cc: David S. Miller <davem@xxxxxxxxxxxxx> > > Cc: Stephen Boyd <sboyd@xxxxxxxxxx> > > Cc: Michael Turquette <mturquette@xxxxxxxxxxxx> > > Cc: Vinod Koul <vkoul@xxxxxxxxxx> > > Cc: dmaengine@xxxxxxxxxxxxxxx > > Cc: linux-clk@xxxxxxxxxxxxxxx > > Cc: linux-crypto@xxxxxxxxxxxxxxx > > Cc: devicetree@xxxxxxxxxxxxxxx > > Cc: linux-kernel@xxxxxxxxxxxxxxx > > Cc: bhupesh.linux@xxxxxxxxx > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@xxxxxxxxxx> > > --- > > drivers/dma/qcom/bam_dma.c | 283 +----------------------------------- > > include/soc/qcom/bam_dma.h | 290 +++++++++++++++++++++++++++++++++++++ > > 1. Please use -M with move patches... Oops, will do. > 2. susbsytem is dmaengine > > 3. Why move..? These things are internal to the driver and I dont think > it is wise for clients to use everything here... If the client needs to > know defer probe, it should request a channel and check the status > returned for EPROBE_DEFER Yes, the main intent is to defer the probe of the calling client driver in case the BAM DMA is not probed() yet. Sure, I will make the suggested change in v3, Regards, Bhupesh
