From: Hans de Goede <hdegoede@redhat.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org
Subject: Re: [RFC 1/2] pwrseq: Add subsystem to handle complex power sequences
Date: Thu, 19 Jun 2014 16:23:26 +0200 [thread overview]
Message-ID: <53A2F25E.80200@redhat.com> (raw)
In-Reply-To: <53A2EDCA.8080000@redhat.com>
Hi,
On 06/19/2014 04:03 PM, Hans de Goede wrote:
> Hi,
>
<snip>
> Also I'm not sold on how you're making this a devm only thing, and
> are using devres_alloc to not only allocate memory for resource tracking,
> but also the actual backing struct, that is not how devres_alloc is
> intended to be used AFAIK.
>
> A problem with having this one always devm managed is that it makes it
> hard to use in library functions without side effects.
>
> e.g. if you look at how your using this in mmc_of_parse in the next
> patch, this gives mmc_of_parse the side-effect of having allocated
> and bound the power-seq method, even if mmc_of_parse later
> fails on e.g. gpio binding. If then for some reason the mmc host
> probe method decides to not propagate the mmc_of_parse method
> error (leading to freeing of all devm managed resources), then this is
> undesirable.
>
> Where as with a non devm version, it would be clear that on error
> mmc_of_parse would need to explicitly release the pwrseq again.
>
> I realize that pwrseq implementations likely will want to use
> devm functions too, and I'm a great fan of devm. But this is something
> to keep in mind. At a minimum the description of of_mmc_parse needs
> to get updated with info about it having potential side-effects even
> when it fails, and that failure should always be treated as a fatal
> error and cause the host probe method to fail.
Thinking more about this, it may be a good idea to give the pwrseq
its own struct device, turning it into a virtual device, this way the
pwrseq-method can use devm managed resources bound to this device,
we can set the of_node of this device to the actual powerseq
childnode and it gets its own sysfs dir in which we could do useful things
such as have an attribute to query the current power state.
This would also mean introducing a non devm version of devm_pwrseq_get
+ an explicit release, which would be useful to avoid the side-effects
mentioned above when used in library functions such as mmc_of_parse.
Regards,
Hans
next prev parent reply other threads:[~2014-06-19 14:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-19 13:04 [RFC 0/2] pwrseq: Add subsystem for power sequences Ulf Hansson
2014-06-19 13:04 ` [RFC 1/2] pwrseq: Add subsystem to handle complex " Ulf Hansson
2014-06-19 14:03 ` Hans de Goede
2014-06-19 14:23 ` Hans de Goede [this message]
2014-07-01 16:33 ` Ulf Hansson
2014-06-19 17:18 ` Olof Johansson
2014-06-20 7:27 ` Hans de Goede
2014-06-20 8:02 ` Olof Johansson
2014-06-20 8:14 ` Hans de Goede
[not found] ` <53A3ED65.80605-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-07-01 16:42 ` Ulf Hansson
2014-07-01 16:51 ` Arnd Bergmann
2014-07-01 16:56 ` Arend van Spriel
2014-06-20 15:42 ` Arnd Bergmann
2014-07-01 16:56 ` Ulf Hansson
2014-06-19 13:04 ` [RFC 2/2] mmc: core: Add support for " Ulf Hansson
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=53A2F25E.80200@redhat.com \
--to=hdegoede@redhat.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=ulf.hansson@linaro.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).