On 31 July 2018 at 19:17, Jeremy Linton <lintonrjeremy@xxxxxxxxx> wrote:
> 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.
Sounds like the exact same problem as we have for build in drivers as well.
Hence we just try all of them and when they fails with -EPROBE_DEFER
we re-try later.
So whats wrong with that here?
>
> 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.
I think you are simplifying this.
The dw_mmc k3 needs other resources besides the reset to work. In
needs regulators, clocks, etc as well.
SOFTDEP don't sounds like the solution to list all these.
>
>>
>>>
>>> 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
No, dwmmc_k3 is not a platform specific driver. It's being used on
more than one Hisilicon SoC.
> 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.
Unfortunate, neither do I. Except that you can add more modules to
your initrd and insmod and try...
Kind regards
Uffe
--
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
