test/py GPIO failure in u-boot/master

[Stephen Warren]

On 7/8/20 2:24 PM, Stephen Warren wrote:
> On 7/8/20 10:06 AM, Tom Rini wrote:
>> On Wed, Jul 08, 2020 at 09:50:06AM -0600, Stephen Warren wrote:
>>> Latest u-boot/master is failing a couple test/py test_ut tests for GPIO:
>>>
>>>> => ut dm gpio
>>>> Test: dm_test_gpio: gpio.c
>>>> extra-gpios: get_value: error: gpio b5 not reserved
>>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137, dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, & offset, & gpio): Expected 0x0 (0), got 0xffffffea (-22)
>>>> Test: dm_test_gpio: gpio.c (flat tree)
>>>> extra-gpios: get_value: error: gpio b5 not reserved
>>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137, dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, & offset, & gpio): Expected 0x0 (0), got 0xffffffea (-22)
>>>> Failures: 2
>>>
>>>
>>>> => ut dm gpio_leak
>>>> Test: dm_test_gpio_leak: gpio.c
>>>> extra-gpios: get_value: error: gpio b5 not reserved
>>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137, dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, & offset, & gpio): Expected 0x0 (0), got 0xffffffea (-22)
>>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302, dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1 (1)
>>>> Test: dm_test_gpio_leak: gpio.c (flat tree)
>>>> extra-gpios: get_value: error: gpio b5 not reserved
>>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137, dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, & offset, & gpio): Expected 0x0 (0), got 0xffffffea (-22)
>>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302, dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1 (1)
>>>> Failures: 4
>>>
>>> This was introduced by one of the following changes; I'd assume due to
>>> the GPIO patch:
>>>
>>>> cmd: part: Add subcommand to list supported partition tables (detail)
>>>> cmd: fs: Add command to list supported fs types (detail)
>>>> cmd: dm: Fixed/Added DM driver listing subcommands (detail)
>>>> cmd: blkls: Add blkls command (detail)
>>>> image: Add support for ZSTD decompression (detail)
>>>> Actions: OWL: Calculate SDRAM size (detail)
>>>> arm: actions: remove "CONFIG_SYS_SDRAM_SIZE" for Actions Owl Semi SoCs (detail)
>>>> clk: actions: Add Ethernet clocks (detail)
>>>> net: phy: realtek: Add support for RTL8201F PHY module. (detail)
>>>> net: phy: realtek: Introduce PHY_RTL8201F_S700_RMII_TIMINGS to adjust (detail)
>>>> net: designware: s700: Add glue code for S700 mac (detail)
>>>> arm: dts: s700: add node for ethernet controller (detail)
>>>> owl: Kconfig: Enable DM eth for OWL platform (detail)
>>>> configs: Enable mac and phy configs (detail)
>>>> gpio: search for gpio label if gpio is not found through bank name (detail)
>>>> test_sleep.py: make sleep time and margin configurable (detail)
>>>> fs: fat_write: fix short name creation. (detail)
>>>> trace: clang compatible handling of gd register (detail)
>>>> arm: remove outdated comment concerning -ffixed-x18 (detail)
>>>> arm: use correct argument size of special registers (detail)
>>>> arm: vexpress64: Fix counter frequency (detail)
>>>> net: dm: Remove warning about EEPROM provided MAC address (detail)
>>>> net: smc911x: Properly handle EEPROM MAC address (detail)
>>>> arm: juno: Enable DM_ETH (detail)
>>>> sata_sil: Enable DM_PCI operation (detail)
>>>> arm: juno: Enable PCI (detail)
>>>> arm: juno: Enable SATA controller (detail)
>>>
>>> I see what was probably an attempt to fix this:
>>>
>>>> commit 7012865e961ca2645d783adf4b75ca4abdbfe5a7 (u-boot/master)
>>>> Author: Heiko Schocher <hs at denx.de>
>>>> Date:   Wed Jul 8 10:24:00 2020 +0200
>>>>
>>>>     gpio: fix test.py for gpio label lookup
>>>
>>> ... but the tests are still failing after that. Did that patch edit the
>>> wrong defconfig, or is there an incremental build issue that prevented
>>> that patch being effective?
>>
>> The tests are passing here and in GitLab again, so I'm not sure what's
>> happening on your end.
> 
> Hmm. There is some kind of incremental build issue. I repro'd on a
> different system with a different OS, so it's not isolated to the system
> that I use to run Jenkins:
> 
> # Ensure clean build
> git clean -fdx
> 
> # Check out the last commit before the fix
> git checkout 526fe06a5d1d96ce22cca743576945016ec4e2ef
> ./test/py/test.py --bd sandbox --build -k test_ut
> # Tests fail here due to the original GPIO issue
> 
> # Check out the fix for the GPIO issue
> git checkout 7012865e961ca2645d783adf4b75ca4abdbfe5a7
> ./test/py/test.py --bd sandbox --build -k test_ut
> # Tests still fail!
> 
> # Ensure clean build
> rm -rf build-sandbox/
> ./test/py/test.py --bd sandbox --build -k test_ut
> # Tests now pass due to clean build
> 
> Masahiro, do you have any ideas?

Ah, I found a bug in fixdep. Look for a patch titled "fixdep: fix
CONFIG_IS_ENABLED etc. handling" in a few minutes.