[Letux-kernel] Pyra display driver once again broken in v5.2-rc1

H. Nikolaus Schaller hns at goldelico.com
Fri May 31 16:41:12 CEST 2019


> Am 30.05.2019 um 12:34 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi,
> 
>> Am 29.05.2019 um 11:12 schrieb Tony Lindgren <tony at atomide.com>:
>> 
>> Hi,
>> 
>> * H. Nikolaus Schaller <hns at goldelico.com> [190529 08:57]:
>>>> [    7.524125] pca953x 4-0022: failed writing register
>>>> [    7.529444] pca953x: probe of 4-0022 failed with error -22
>> 
>> I saw something similar with a BBB cape (early Baylibre
>> ACME cape) and it was device_pca95xx_init() somehow trying to
>> write to a read-only register causing an error.
>> 
>> I did not debug further and I do not have it handy, and I
>> could not easily figure out what caused the regression..
>> But maybe take a look and see if commenting out the register
>> write device_pca95xx_init() helps.
> 
> I did a quick check and there are significant recent changes
> 
> 	git diff v4.19 v5.2-rc1 drivers/gpio/gpio-pca953x.c 
> 
> even going down to register address calculations. Most changes
> were introduced in v5.0 for some regulator handling and wakeup_path,
> irq-handling and allowing to define pullup/down (if the gpio
> expander chip permits).
> 
> Maybe there is a bug that was hidden by something else before v5.2-rc1.
> 
> Anyways I seem to have found a recipe to be able to bisect.
> The problem is that mainline does not boot and the sets of LetuxOS
> patches to make it boot do either apply cleanly for v5.1 or for v5.2-rc1
> but not both. Sometimes the compile fails and sometimes the Pyra
> does not boot to login and hangs with a kernel panic.
> 
> But now I seem to have found a good mix where v5.1 boots and
> is good (4-0022 is listed as a gpiochip), while v5.2-rc1 boots
> and is bad (4-0022 missing) and intermediate bisect points
> seem to compile and boot as well.
> 
> Now, ca. 13 rounds of bisect are needed.

It is finished now but the result is not convincing:

433b8dd7672be1140ffbb17eacba776298bf4733 is the first bad commit
commit 433b8dd7672be1140ffbb17eacba776298bf4733
Author: Steve French <stfrench at microsoft.com>
Date:   Tue Mar 26 13:53:21 2019 -0500

   SMB3: Track total time spent on roundtrips for each SMB3 command

   Also track minimum and maximum time by command in /proc/fs/cifs/Stats

   Signed-off-by: Steve French <stfrench at microsoft.com>

Especially since this is not the first bad commit if I test
433b8dd7672be1140ffbb17eacba776298bf4733~1. This means git bisect
has not done its work properly (or I did report one test result
wrongly). Most likely the real bug is in a parallel branch
and older than v5.1 which was merged in by v5.1-rc1.

Unfortunately using v4.19 or v4.20 with my current Letux patch
set makes the boot process hang when trying to find the SD card.
Therefore I can not yet simply bisect between v4.19 and v5.2-rc1.

So it might be quicker to come to a solution by hacking the
register read/write in the pca953x driver to better understand
what it is trying and what it should do instead.

@Tony: if you can confirm that the omap5uevm is also broken
with mainline v5.2-rc1 we could extend the discussion to
the linux-omap list and gpio. But before it could simply be
a special Pyra effect where nobody without hardware could
easily help.

BR,
Nikolaus



More information about the Letux-kernel mailing list