Hi,
Thanks for looking at this!
On Mon, Jul 30, 2018 at 10:06 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> On 18 July 2018 at 02:49, Jeremy Linton <lintonrjeremy@xxxxxxxxx> wrote:
>> The mmc/k3 driver is dependent on a number of other linux modules
>> which must be built into the initrd in order to use the mmc/sd
>> as a boot device for initrd/module based distros.
>>
>> Normally this would be taken care of with linux's modules.deps
>> based on symbolic dependencies but the dwmmc drivers have
>> particularly complex relationships that are based on soft
>> callback APIs. The result is that dracut and other initrd builders
>
> If I understand correctly, this is about clock and resets. It doesn't
> sound like a special complex relationship, but rather a quite common.
Yes...
>
>> are unable to determine the module dependencies directly.
>>
>> To solve this problem linux has MODULE_SOFTDEP() so lets softdep
>> the hisi clock and reset drivers associated with the k3 implementation.
>
> Why doesn't the -EPROBE_DEFER mechanism help here? Or you simply don't
> want to load modules that isn't needed?
The problem happens when you want to boot from the mmc device, and
everything is built as modules, with an initrd containing the minimum
module set to bring the rootfs/etc online.
An initrd builder can't determine the subset of modules required to
get this driver to work based solely on the module dependencies and
the boot device description. It places the
mmc/designware/filesystem/etc modules in the initrd and when the
machine boots the designware driver loads but can't start the sd/mmc
because the reset driver is missing from the initrd.
ARM's already have a special case to include the clk drivers even
though on arm/ACPI platforms they are unnecessary. In this case, its
really the reset driver which is problematic, because most boot
devices don't require them, and its not possible to tell programatically
what the dependency tree is.
This isn't really unique to the k3 driver, and is fairly common with a
few of these other dw_mmc modules (try playing with `udevadm info -a
-n /dev/somedevice` looking at DRIVERS and SUBSYSTEM) which are
themselves somewhat unusual because USB/SATA/SCSI/etc device
dependencies tend to be fairly clear.. Put another way, the problem is
basically that given a block device/driver we need an accurate view of
what drivers are required for it to work.
AFAIK, when that can't be determined by the symbolic dependencies,
that is what SOFTDEP is for.
>
>>
>> Signed-off-by: Jeremy Linton <lintonrjeremy@xxxxxxxxx>
>> ---
>> drivers/mmc/host/dw_mmc-k3.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
>> index 89cdb3d533bb..cd8f545fa30d 100644
>> --- a/drivers/mmc/host/dw_mmc-k3.c
>> +++ b/drivers/mmc/host/dw_mmc-k3.c
>> @@ -487,3 +487,4 @@ module_platform_driver(dw_mci_k3_pltfm_driver);
>> MODULE_DESCRIPTION("K3 Specific DW-MSHC Driver Extension");
>> MODULE_LICENSE("GPL v2");
>> MODULE_ALIAS("platform:dwmmc_k3");
>> +MODULE_SOFTDEP("pre: hi6220_reset clk_hi655x");
>
> These are platform specific dependencies, but added as generic module
> dependencies. It doesn't seem right to me.
I agree, its not optimal but In this case, the dwmmc_k3 is the
platform specific driver, and its
being softdep'ed to its platform requirements. That avoids having to
hard-code SOC specific rules. I'm not sure how else to describe these
relationships with this driver.
Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
