[Letux-kernel] Strange problem with non-LPAE letux-4.20-rc kernels on 4GB Pyra only - PARTUUID not found

[H. Nikolaus Schaller]

Hi,

> Am 15.12.2018 um 12:04 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Ok... well Nok...
> 
>> Am 14.12.2018 um 21:19 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>>> 
>>> Hm. Shouldn't git bisect go down into the merge and look for the real patch there?
>> 
>> Some idea could to try CONFIG_USB=n in letux-4.20-rc1 since we do not need it to boot
>> from MMC. If it then works, we can prove that the USB subsystem has a side-effect.
> 
> It seems to be a false positive by git bisect (or I have wrongly reported "good" and "bad").
> 
> Using CONFIG_USB=n doesn't help.
> checkout 9703fc8caf36ac65dca1538b23dd137de0b53233 && apply patches && compile && install && boot => PARTUUID not found
> checkout 9703fc8caf36ac65dca1538b23dd137de0b53233^ && apply patches && compile && install && boot => PARTUUID not found
> 
> So I should define 4.19.0 as good and 9703fc8caf36ac65dca1538b23dd137de0b53233^ as bad and start another round of bisect...

For summary again:

bad case: kernel stops with

[    3.473657] sr_init: No PMIC hook to init smartreflex
[    3.479880] vmmcsdio_fixed: disabling
[    3.484345] ldo3: disabling
[    3.487981] ldo8: disabling
[    3.498640] ALSA device list:
[    3.501745]   No soundcards found.
[    3.505668] Waiting for root device PARTUUID=c8a507cd-02...

although U-Boot and external SD card reader confirms that the PARTUUID is c8a507cd-02

good case:

[    3.526955] sr_init: No PMIC hook to init smartreflex
[    3.533200] vmmcsdio_fixed: disabling
[    3.537948] ldo3: disabling
[    3.541893] ldo8: disabling
[    3.552425] ALSA device list:
[    3.555526]   No soundcards found.
[    3.584375] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[    3.593118] VFS: Mounted root (ext4 filesystem) on device 179:2.
[    3.609188] devtmpfs: mounted
[    3.612978] Freeing unused kernel memory: 1024K
[    3.617863] Run /sbin/init as init process

Running git bisect again (I probably did mark some commit wrongly as good/bad)
has now revealed patch:

e63201f19438372fcb45977d8e14c6ab5807d55b is the first bad commit
commit e63201f19438372fcb45977d8e14c6ab5807d55b
Author: Linus Walleij <linus.walleij at linaro.org>
Date:   Mon Sep 24 13:30:51 2018 +0200

    mmc: omap_hsmmc: Delete platform data GPIO CD and WP
    
    The OMAP HSMMC driver has some elaborate and hairy handling for
    passing GPIO card detect and write protect lines from a boardfile
    into the driver: the machine defines a struct omap2_hsmmc_info
    that is copied into struct omap_hsmmc_platform_data by
    omap_hsmmc_pdata_init() in arch/arm/mach-omap2/hsmmc.c.
    
    However the .gpio_cd and .gpio_wp fields are not copied from
    omap2_hsmmc_info to omap_hsmmc_platform_data by
    omap_hsmmc_pdata_init() so they remain unused. The only platform
    defining omap2_hsmmc_info also define both to -1, unused.
    
    It turn out there are no boardfiles passing any valid GPIO
    lines into the OMAP HSMMC driver at all. And since we are not
    going to add any more OMAP2 boardfiles, we can delete this
    card detect and write protect handling altogether.
    
    This seems to also fix a bug: the card detect callback
    mmc_gpio_get_cd() in the slot GPIO core needs to be called
    by drivers utilizing slot GPIO. It appears the the boardfile
    quirks were not doing this right, so this would only get
    called for boardfiles, i.e. since no boardfile was using it,
    never.
    
    Just assign mmc_gpio_get_cd() unconditionally to omap_hsmmc_ops
    .get_cd() so card detects from the device tree works.
    AFAICT card detect with GPIO lines assigned from
    mmc_of_parse() are not working at the moment, but that is
    no regression since it probably never worked.

Yes, that is very reasonable to be the offending patch.

And the last sentence is probably the problem!!!
It contains a lot of speculation and assumption that it does
not break anything... I am quite sure that a patch submitted by me
with this description would have been rejected...

I am tempted to propose a simple revert just because it *is* a
regression for us using a proper (at least I think so) DTS...

But it is still not clear why it works on GTA04 and the older
Pyra prototype. And why it works with the other SD slot.

Maybe they have removed some special side-effect of omap_hsmmc_gpio_init()?
Or this board has a broken gpio (returning always "1") which was ignored
before this patch because we have no board file?

At least the search for solving the problem has got a new direction.

BR,
Nikolaus