linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: "André Przywara" <andre.przywara@arm.com>
Cc: Adam Borowski <kilobyte@angband.pl>,
	Icenowy Zheng <icenowy@aosc.xyz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349
Date: Mon, 1 May 2017 15:22:02 -0400	[thread overview]
Message-ID: <20170501192202.GE8921@htj.duckdns.org> (raw)
In-Reply-To: <043dc68f-aaec-48e8-4a92-e57d60a8ed08@arm.com>

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

  reply	other threads:[~2017-05-01 19:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170315161406.smd4na25two55jjh@angband.pl>
     [not found] ` <197431489595078@web8g.yandex.ru>
2017-03-16  1:06   ` sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349 Greg Kroah-Hartman
2017-03-17 14:08     ` Tejun Heo
     [not found]       ` <785901489760914@web50g.yandex.ru>
2017-03-17 14:44         ` Tejun Heo
2017-03-17 16:32           ` Adam Borowski
2017-04-02 23:48           ` André Przywara
2017-04-18  7:25             ` Tejun Heo
2017-04-18  9:12               ` Andre Przywara
2017-04-28 22:03                 ` Tejun Heo
2017-04-29 21:28                   ` Adam Borowski
2017-04-29 23:34                     ` André Przywara
2017-05-01 19:22                       ` Tejun Heo [this message]
2017-04-18 10:51               ` Icenowy Zheng

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=20170501192202.GE8921@htj.duckdns.org \
    --to=tj@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=icenowy@aosc.xyz \
    --cc=kilobyte@angband.pl \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).