From: Thierry Reding <thierry.reding@gmail.com>
To: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Stephen Warren <swarren@wwwdotorg.org>,
Hiroshi Doyu <hdoyu@nvidia.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC 0/4] Early device registration
Date: Fri, 16 Aug 2013 22:39:19 +0200 [thread overview]
Message-ID: <1376685563-1053-1-git-send-email-treding@nvidia.com> (raw)
This patch series is the result of some earlier discussion[0]. Some
drivers need to probe their devices very early in the boot process (such
as IRQ chip drivers). However there is no struct device available at
that time because they are added a lot later.
The most notable case where this happens is for systems that are booted
using a device tree. A lot of those early drivers work around the issue
by "binding" themselves to the struct device_node. One disadvantage of
that is that they cannot use APIs that require a struct device (such as
regmap). Another downside is that it introduces inconsistencies in how
drivers are written.
In order to remedy that situation, this patch series introduces a way to
register devices earlier. This is more difficult than it sounds. One of
the problems is that kmalloc() is required during device registration.
Another prerequisite is sysfs since every device is represented in the
sysfs tree. To allow a device to be created before sysfs is available,
only the very minimal set of operations are performed at the early stage
and the device is added to a list of early devices that will be fully
registered once all the necessary infrastructure is available. This is
somewhat inspired by and therefore similar to deferred driver probing.
By no means is this patch series complete. I was able to boot a Tegra
device to a boot prompt without any serious regressions. One thing I did
notice is that somehow this series causes udev not to rename ethernet
devices (f.e. eth0 to enp1s0) which it does without that patch set.
One thing that this set of patches doesn't address yet is a way to probe
devices early, which might be required for some use-cases. However I'm
looking for some feedback before going further down this road.
Thierry
[0]: https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html
Thierry Reding (4):
driver core: Register SoC bus after platform bus
driver core: Allow early registration of devices
ARM: tegra: Call of_platform_populate() early
OF: Add device pointer to struct device_node
arch/arm/mach-tegra/common.c | 33 +++++++++++++
arch/arm/mach-tegra/tegra.c | 32 -------------
drivers/base/base.h | 8 ++++
drivers/base/core.c | 107 +++++++++++++++++++++++++++++++++++++++++++
drivers/base/init.c | 3 ++
drivers/base/soc.c | 11 +----
drivers/of/device.c | 2 +
drivers/of/platform.c | 10 +---
include/linux/of.h | 2 +
9 files changed, 157 insertions(+), 51 deletions(-)
--
1.8.3.4
next reply other threads:[~2013-08-16 22:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 20:39 Thierry Reding [this message]
2013-08-16 20:39 ` [RFC 1/4] driver core: Register SoC bus after platform bus Thierry Reding
2013-08-16 20:39 ` [RFC 2/4] driver core: Allow early registration of devices Thierry Reding
2013-08-16 21:06 ` Greg Kroah-Hartman
2013-08-16 21:55 ` Thierry Reding
2013-08-16 22:08 ` Greg Kroah-Hartman
2013-08-17 11:17 ` Thierry Reding
2013-08-19 19:43 ` Stephen Warren
2013-08-19 20:10 ` Thierry Reding
2013-08-19 20:53 ` Stephen Warren
2013-08-19 21:41 ` Thierry Reding
2013-08-16 22:20 ` Grant Likely
2013-08-16 22:35 ` Greg Kroah-Hartman
2013-08-17 10:26 ` Tomasz Figa
2013-08-19 19:49 ` Stephen Warren
2013-08-19 20:04 ` Thierry Reding
2013-08-17 11:07 ` Thierry Reding
2013-08-16 20:39 ` [RFC 3/4] ARM: tegra: Call of_platform_populate() early Thierry Reding
2013-08-16 20:39 ` [RFC 4/4] OF: Add device pointer to struct device_node Thierry Reding
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=1376685563-1053-1-git-send-email-treding@nvidia.com \
--to=thierry.reding@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=hdoyu@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=rob.herring@calxeda.com \
--cc=sebastian.hesselbarth@gmail.com \
--cc=swarren@wwwdotorg.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
Powered by JetHome