linux-kernel - Re: v4.17-rc1: regressions on N900, N950

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 May 2018 22:41:39 +0300
From:   Aaro Koskinen <aaro.koskinen@....fi>
To:     Pali Rohár <pali.rohar@...il.com>
Cc:     Pavel Machek <pavel@....cz>, sre@...nel.org,
        kernel list <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-omap@...r.kernel.org, tony@...mide.com, khilman@...nel.org,
        ivo.g.dimitrov.75@...il.com, patrikbachan@...il.com,
        serge@...lyn.com, abcloriens@...il.com, clayton@...ftyguy.net,
        martijn@...xit.nl, sakari.ailus@...ux.intel.com,
        Filip Matijević <filip.matijevic.pz@...il.com>,
        Thorsten Leemhuis <regressions@...mhuis.info>
Subject: Re: v4.17-rc1: regressions on N900, N950

Hi,

On Tue, May 22, 2018 at 10:02:50AM +0200, Pali Rohár wrote:
> Hi! I remember that in time of migration from platform board code to
> device tree structures there appeared some bug which caused that
> sometimes display were not initialized. And somebody figured out that
> display initialization is failing when some other SPI devices are
> initialized before or after display... This behavior was observed only
> on real N900 hardware, not in qemu.

Touchscreen needs to be initialized before display. This is documented
in the DTS, see arch/arm/boot/dts/omap3-n900.dts:

	* For some reason, touchscreen is necessary for screen to work at
	* all on real hw. It works well without it on emulator.
	*
	* Also... order in the device tree actually matters here.

> Real reason was never explained. In old platform board code there was
> hardcoded order of SPI devices in which initialization happened. And in
> device tree it is probably in (pseudo)-random order. Enabling/disabling
> various config option can affect some timings and order in which kernel
> starts probing and initializing devices...

The issue was also somewhat present with platform/board code, see e.g.
commit e65f131a14726e5f1b880a528271a52428e5b3a5.

My device worked with v4.17-rc1 (haven't found time to test newer kernels),
but if you say the probe order is random then we must find some proper way
to express the dependency.

A.