On Sat, 11 Oct 2014 11:37:31 +0100 Ian Campbell <ijc@debian.org> wrote:
> On Thu, 2014-09-18 at 00:17 +0100, Ian Campbell wrote:
> > The xgene_ahci driver requires phy-xgene in order to be able to function (i.e. to mount rootfs). It was not included in the
> > initramfs by default. Adding it to /etc/initramfs-tools/modules allowed the system to boot but ideally this would happen
> > automatically.
>
> I also have a similar issue on the arndale platform which requires
> i2c-s3c2410 and phy-exynos5250-sata to be listed
> in /etc/initramfs-tools/modules in order to boot from the SATA disk.
> (I've a feeling a different non-overlapping set will be required to boot
> from MMC, but I'll have to perform that experiment later).
Uh... so an *internal* PHY is controlled over I2C? That's a bit crazy
but perhaps this IP block is also to be usable as an external PHY.
> It seems that at least with current kernels there is no way to trace
> from a block device back to the set of clocks, regulators and phys which
> it needs. Yet I expect it is likely we will see this sort of thing on
> other platforms too (especially arm ones).
>
> I'm wondering if we ought to include
> kernel/drivers/{clk,i2c,phy,regulator}/*.ko in the base set of modules
> (at least for MODULES=most)?
>
> For the current armmp kernel those are:
> 276K i2c/
> 24K clk/
> 160K regulator/
> 124K phy/
> 584K total
>
> Or maybe just include the ones which are needed by various platforms on
> an ad-hoc basis? (by listing in auto_add_modules). That might have less
> overall impact (since not all of those modules are needed for boot) but
> does mean we need to play whack-a-mole as new platforms arrive which use
> a different set of clk controllers etc.
I think we should do this for all but I2C adapters. For any platform
where we build clk, phy or regulator drivers we can probably expect to
need them at boot. The same is not generally true for I2C adapters.
I would also add gpio and pinctrl to the list.
> We could start building more of these modules into the kernel
> statically. Same whack-a-mole issue as the above though.
>
> I'm leaning towards an adhoc list in auto_add_modules. I'll knock up a
> patch to that affect unless I hear some objections.
I'm objecting as I don't think this is appropriate in auto_add_modules.
> > I've had a dig through /sys looking for something which would link the AHCI driver to the phy driver, but I couldn't find
> > anything. If you have some ideas/clues where to look I'd be happy to have another dig. In the meantime I've attached the output
> > of "find /sys -ls".
I think the only way to do that is to look at the Device Tree, and I
don't fancy doing that to initramfs-tools. Even then I'm not sure how
much you can get from a DTB as it doesn't have explicit type
information.
How about putting the weird dependencies in hidden_dep_add_modules?
> I've attached the same for arndale (for what its worth...)
>
> Ian.
Here are my generic changes, untested as I don't have such boards to
test with. They aren't going to cover i2c-s3c2410 (I think) or
USB-PHYs.
For USB-PHYs, if MODULES=most then we would do:
copy_modules_dir kernel/drivers/usb/phy
or if MODULES=dep then:
add_loaded_modules 'phy[-_]*'
Ben.
---
Subject: hook-functions: Add modules for various important device types
Storage and networking devices may depend on PHYs that aren't clearly
linked to them in the device model, so add those drivers. If
MODULES=most then add all of them. Note this doesn't cover USB-PHY
drivers, only generic PHY drivers.
On ARM systems without useful firmware we may also need to
do a lot more chip/board configuration, so also add clk,
gpio, pinctrl and regulator drivers.
If MODULES=most then add all drivers built from the corresponding
source directories. If MODULES=dep then add drivers for the visible
devices in these classes. As clk and regulator don't have real device
classes but do have driver names beginning with common prefixes, add
modules based on the current loaded or built-in modules matching these
prefixes.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
hook-functions | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/hook-functions b/hook-functions
index 2a421cf..9a5155e 100644
--- a/hook-functions
+++ b/hook-functions
@@ -230,6 +230,28 @@ sys_walk_modalias()
done
}
+# Copy all loaded or built-in modules matching the given pattern.
+# Pattern mustn't include directory or '.ko' suffix but should use
+# '[-_]' to allow for differences in naming between /sys/module and
+# modules.builtin.
+add_loaded_modules()
+{
+ local pattern="$1"
+ local module
+ for module in /sys/module/$pattern; do
+ if [ -d "$module" ]; then
+ manual_add_modules $(basename $module)
+ fi
+ done
+ while read module; do
+ case "$module" in
+ */$pattern.ko)
+ manual_add_modules $(basename $module .ko)
+ ;;
+ esac
+ done < <(cat 2>/dev/null /lib/modules/$(uname -r)/modules.builtin)
+}
+
# find and only copy root relevant modules
dep_add_modules()
{
@@ -417,6 +439,19 @@ dep_add_modules()
root_dev_path=$(readlink -f /sys/block/${block}/device)
sys_walk_mod_add ${root_dev_path}
+ # sys walk some important device classes
+ for class in gpio phy regulator; do
+ for device in /sys/class/$class/*; do
+ device="$(readlink -f "$device")" \
+ && sys_walk_mod_add "$device"
+ done
+ done
+
+ # clk and pinctrl devices are outside the device model (!) so
+ # match loaded modules by name
+ add_loaded_modules 'clk[-_]*'
+ add_loaded_modules 'pinctrl[-_]*'
+
# catch old-style IDE
if [ -e /sys/bus/ide/devices/ ]; then
sys_walk_modalias ${root_dev_path}
@@ -489,6 +524,13 @@ auto_add_modules()
hid-speedlink.ko hid-tivo.ko hid-twinhan.ko \
hid-uclogic.ko hid-wacom.ko hid-waltop.ko \
hid-wiimote.ko hid-zydacron.ko
+
+ # Any of these might be needed by other drivers
+ copy_modules_dir kernel/drivers/clk
+ copy_modules_dir kernel/drivers/gpio
+ copy_modules_dir kernel/drivers/phy
+ copy_modules_dir kernel/drivers/pinctrl
+ copy_modules_dir kernel/drivers/regulator
;;
net)
copy_modules_dir kernel/drivers/net \
--
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.
Attachment:
signature.asc
Description: This is a digitally signed message part