From: Greg KH <greg@kroah.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
Mark Brown <broonie@kernel.org>,
systemd-devel@lists.freedesktop.org,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
devicetree <devicetree@vger.kernel.org>
Subject: Re: Making udev emit a signal when it is done loading modules
Date: Sat, 17 Jan 2015 05:56:30 -0800 [thread overview]
Message-ID: <20150117135630.GA25585@kroah.com> (raw)
In-Reply-To: <54BA20D0.7060402@redhat.com>
On Sat, Jan 17, 2015 at 09:44:00AM +0100, Hans de Goede wrote:
> Dear udev developers,
>
> We (me and some kernel devs mostly) would like to add support to
> the kernel for userspace telling the kernel that it is done with
> the *initial* loading of modules, with the purpose of cleaning up
> (disabling) unused harware resources like e.g. regulators and
> clocks.
But you don't "know" when that happens. Especially with discoverable
busses (PCI, USB, etc.), you know this :)
> Currently the kernel does this cleanup just before it starts init
> (which may very well be init from a ramdisk). In some cases this
> is too early really, because later on a module may get loaded
> which needs this resources, these resources will then get turned
> on again by the loaded driver, and most of the time this is not
> an issue, but sometimes it is.
>
> I realize very well that there is no magic moment where udev is
> really ever done loading modules, but the case which we want to
> support only involves devices which are *already enumerated*, but
> may not yet have a driver loaded, when udev starts. We would like
> udev to emit a signal (ABI to be discussed) when it is done
> trying to load modules for everything which was already enumerated
> when it starts, iow when there are no new device events pending
> anymore when udev does its initial hotplug replay.
The kernel doesn't even "know" when this type of thing is, how can udev
know this?
> So the question to you is would you be willing to include such
> functionality in udev ? Note this signal would need to be emitted
> when udev from the real rootfs is done with the initial module
> loading, as the real rootfs may very well have more modules
> available then the initrd.
>
> ###
>
> With the generic story above told let me also give the concrete
> example / problem which has let to me asking this (note this has
> been brought up before on various kernel lists, it is a
> re-occuring theme, this is just an example really) :
>
> The problem at hand is a sata connector which also has a sata-power
> connector on an embedded (ish) board where the sata-power is
> controlled through a gpio. The sata-power connector is modeled
> in devicetree as a power-supply and this supply gets controlled
> by the ahci_platform driver.
>
> The disk power may very well have already been turned on by the
> bootloader, so we add a regulator-boot-on property to the regulator
> node in devicetree to make sure that it is left untouched when the
> regulator driver loads. If the ahci_platform driver is build into
> the kernel, it will then take control of the regulator and
> everything works well.
>
> If however the ahci_platform driver is a module, then as soon as
> the kernel is ready to start init, unused regulators are turned off
> and the disk looses its power while spinning and ends up doing an
> emergency heads park.
What turns off the power in this situation? The kernel? Or userspace?
Don't you have control of this?
Have you tried to even create a patch that could do this type of thing
to udev to see if it is even possible?
thanks,
greg k-h
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
next prev parent reply other threads:[~2015-01-17 13:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-17 8:44 Making udev emit a signal when it is done loading modules Hans de Goede
2015-01-17 13:56 ` Greg KH [this message]
2015-01-17 14:12 ` [systemd-devel] " Mark Brown
2015-01-17 14:52 ` Hans de Goede
[not found] ` <20150117135630.GA25585-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-01-17 15:23 ` [systemd-devel] " jonsmirl-Re5JQEeQqe8AvxtiuMwx3w
2015-01-17 16:03 ` David Herrmann
2015-01-17 16:03 ` Zbigniew Jędrzejewski-Szmek
2015-01-17 16:45 ` [systemd-devel] " Kay Sievers
2015-01-28 1:38 ` Lennart Poettering
2015-02-11 5:28 ` [systemd-devel] " Mark Brown
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=20150117135630.GA25585@kroah.com \
--to=greg@kroah.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hdegoede@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=systemd-devel@lists.freedesktop.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).