Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349

From	Tejun Heo <tj@kernel.org>
Newsgroups	linux.kernel
Subject	Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349
Date	2017-05-01 21:30 +0200
Message-ID	<tCpbb-4FA-1@gated-at.bofh.it> (permalink)
References	(5 earlier) <txvKi-3lc-15@gated-at.bofh.it> <txxsK-4oB-21@gated-at.bofh.it> <tBmfn-5oV-1@gated-at.bofh.it> <tBIfU-2Xk-7@gated-at.bofh.it> <tBK82-46a-1@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

Hello,

On Sun, Apr 30, 2017 at 12:34:40AM +0100, André Przywara wrote:
> >> If this is a valid use case, we can change devm to repeat till empty
> >> but it's a weird thing to do to allocate from a release function.
> >>
> >> So, something like this.  Only compile tested.
> 
> I was wondering if using devm_*alloc in a _release_ function is valid at
> all, given that it is called as part of the DEFER clean-up routine.
> Looking at pinmux_generic_free_functions() it looks like we could
> replace it with a (non-devm_) kmalloc version and it would still work
> (given we add a kfree at the end).
> Either that or we bail out early if pctldev->num_functions is zero.

I was just throwing the idea but the more I think about it, the less
sense it makes to me.  So, I really think this should be fixed by
dropping dev_kzalloc() call from the release function.  It makes no
sense.

Thanks.

-- 
tejun

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349 Tejun Heo <tj@kernel.org> - 2017-04-29 00:10 +0200
  Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349 André Przywara <andre.przywara@arm.com> - 2017-04-30 01:40 +0200
    Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349 Tejun Heo <tj@kernel.org> - 2017-05-01 21:30 +0200

csiph-web