From: Viresh Kumar <viresh.kumar@linaro.org>
To: Vinod Koul <vinod.koul@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dan Williams <dan.j.williams@intel.com>,
linaro-kernel@lists.linaro.org, dmaengine@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dmaengine: device must have at least one channel
Date: Mon, 8 Aug 2016 08:24:49 -0700 [thread overview]
Message-ID: <20160808152448.GA4798@ubuntu> (raw)
In-Reply-To: <20160808081754.GW9681@localhost>
On 08-08-16, 13:47, Vinod Koul wrote:
> On Fri, Aug 05, 2016 at 09:30:50AM -0700, Viresh Kumar wrote:
> > On 03-08-16, 21:34, Greg Kroah-Hartman wrote:
>
> > > To follow up on this, as you found out, this patch breaks working
> > > hardware, so please don't apply it anywhere. It needs more debugging to
> > > figure out exactly what is going on with some very strange hardware that
> > > seems to be relying on some strange code...
> >
> > Thanks for your email Greg, and I know what the issue is.
> >
> > So, the dmaengine core actually allows registering a device without any channels
> > and the dma driver can add channels later (directly to the dma-device channel
> > list), for example, from the of-xlate callback once someone requests for a
> > channel.
>
> I do not think that is good idea
>
> > Though its not the right way of doing things, but it still works. The only thing
> > which breaks in that case is sysfs interface to dmaengine as the channels aren't
> > registered as devices and so they aren't visible in userspace, as that code is
> > *only* executed while the dma-device is registered.
> >
> > I think its dmaengine core's decision to keep supporting such drivers or not and
> > so I would like Vinod to comment on that..
>
> My view would be to ensure that controllers have channels before they
> register. If they dont, then please register later.
>
> > But if we do want to support such drivers, then the core must be updated to fix
> > the memleak I reported here, as idr_ref is allocated and not used at all (also
> > dma-id allocated for it).
> >
> > Or provide another API to properly and fully add channels at a later point of
> > time.
>
> And looking at drivers, I am not seeing anyone who needs such a support, so
> am not inclined to support such a feature atm.
Right and so I believe that applying this patch is the right thing to do..
--
viresh
next prev parent reply other threads:[~2016-08-08 15:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-27 21:32 [PATCH] dmaengine: device must have at least one channel Viresh Kumar
2016-07-28 3:48 ` Vinod Koul
2016-07-28 4:48 ` Viresh Kumar
2016-08-03 19:34 ` Greg Kroah-Hartman
2016-08-05 16:30 ` Viresh Kumar
2016-08-08 8:17 ` Vinod Koul
2016-08-08 15:24 ` Viresh Kumar [this message]
2016-08-08 17:06 ` Greg Kroah-Hartman
2016-08-08 17:08 ` Viresh Kumar
2016-08-22 6:19 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160808152448.GA4798@ubuntu \
--to=viresh.kumar@linaro.org \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.