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]
Message-ID: <20180522194139.GB2299@darkstar.musicnaut.iki.fi>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ