Comment # 6 on bug 998440 from Takashi Iwai

(In reply to Giacomo Comes from comment #5)
> I have tested your dracut module script on three cherryview PC.
> Acer Aspire R11, Intel compute stick STK1AW32SC, Dell Inspiron 11-3168
> In every PC /sys/bus/acpi/devices/INT33FF:00 is present so the module
> pinctrl-cherryview is inserted in the initrd and the sd card is working.
> However, the Dell Inspiron 11-3168 does not need such module. The SD card
> is not accessed as /dev/mmcblk0 but as /dev/sdb. Actually on such laptop 
> the sd card reader has always worked and because of that I was not aware
> that 
> it was a cherryview system.
> 
> I have tested a modified version of the module script. This one checks the
> presence of /sys/bus/mmc/drivers/mmcblk which does exist if the card is
> accessed as /dev/mmcmlk0 and is missing if the sd card is accessed as
> /dev/sdb
> 
> Here is the modified check function I have tested.
> 
> check() {
>   test -d /sys/bus/acpi/devices/INT33FF:00 && test -d
> /sys/bus/mmc/drivers/mmcblk
> }
> 
> With this modified check, the pinctrl-cherryview module is inserted in the
> initrd
> only for the PC that really needs it.

This won't work because mmcblk appears only after binding with mmc driver, and
the binding happens only *after* pinctrl driver is initialized.  So it's a
chicken-and-egg problem.  You have to load pinctrl at first so that mmcblk
appears.

Putting pinctrl-cherryview in initrd itself should be harmless except for a
unused memory footprint.  And INT33FF is the only matching criteria the
pinctrl-cherryview driver exposes.  So in principle, it's correct to have only
this check in dracut.

Of course, we may add yet more fine check (e.g. checking DMI).

If your Dell machine, check again the initrd without this hack, and see whether
pinctrl-cherryview is loaded even without it or not.  The module should be
picked up due to ACPI INT33FF match.