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
WARNING: multiple messages have this Message-ID (diff)
From: greg@kroah.com (Greg KH)
To: linux-arm-kernel@lists.infradead.org
Subject: [systemd-devel] 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
next prev parent reply other threads:[~2015-01-17 13:56 UTC|newest]
Thread overview: 20+ 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 8:44 ` Hans de Goede
2015-01-17 13:56 ` Greg KH [this message]
2015-01-17 13:56 ` [systemd-devel] " Greg KH
2015-01-17 14:12 ` Mark Brown
2015-01-17 14:12 ` Mark Brown
2015-01-17 14:52 ` Hans de Goede
2015-01-17 14:52 ` [systemd-devel] " Hans de Goede
[not found] ` <20150117135630.GA25585-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-01-17 15:23 ` jonsmirl-Re5JQEeQqe8AvxtiuMwx3w
2015-01-17 15:23 ` jonsmirl at gmail.com
2015-01-17 16:03 ` David Herrmann
2015-01-17 16:03 ` David Herrmann
2015-01-17 16:03 ` Zbigniew Jędrzejewski-Szmek
2015-01-17 16:03 ` [systemd-devel] " Zbigniew Jędrzejewski-Szmek
2015-01-17 16:45 ` Kay Sievers
2015-01-17 16:45 ` Kay Sievers
2015-01-28 1:38 ` Lennart Poettering
2015-01-28 1:38 ` [systemd-devel] " Lennart Poettering
2015-02-11 5:28 ` Mark Brown
2015-02-11 5:28 ` 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 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.