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 <h...@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.