[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200205044352.GC2618@vkoul-mobl>
Date: Wed, 5 Feb 2020 10:13:52 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Peter Ujfalusi <peter.ujfalusi@...com>,
dmaengine <dmaengine@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH 0/3] dmaengine: Stear users towards
dma_request_slave_chan()
On 04-02-20, 13:21, Andy Shevchenko wrote:
> On Tue, Feb 4, 2020 at 8:21 AM Vinod Koul <vkoul@...nel.org> wrote:
> >
> > On 03-02-20, 12:37, Andy Shevchenko wrote:
> > > On Mon, Feb 3, 2020 at 12:32 PM Peter Ujfalusi <peter.ujfalusi@...com> wrote:
> > >
> > > > dma_request_slave_channel_reason() no longer have user in mainline, it
> > > > can be removed.
> > > >
> > > > Advise users of dma_request_slave_channel() and
> > > > dma_request_slave_channel_compat() to move to dma_request_slave_chan()
> > >
> > > How? There are legacy ARM boards you have to care / remove before.
> > > DMAengine subsystem makes a p*s off decisions without taking care of
> > > (I'm talking now about dma release callback, for example) end users.
> >
> > Can you elaborate issue you are seeing with dma_release callback?
>
>
> [ 7.980381] intel-lpss 0000:00:1e.3: WARN: Device release is not
> defined so it is not safe to unbind this driver while in use
Yes that is expected but is not valid in your case.
Anyway this will be turned off before the release.
> It's not limited to that driver, but actually all I'm maintaining.
>
> Users are not happy!
>
> --
> With Best Regards,
> Andy Shevchenko
--
~Vinod
Powered by blists - more mailing lists