linux-kernel - Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

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:   Mon, 31 Jul 2017 16:21:51 +0300
From:   Tomi Valkeinen <tomi.valkeinen@...com>
To:     Aaro Koskinen <aaro.koskinen@....fi>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        Tony Lindgren <tony@...mide.com>, <linux-omap@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>
Subject: Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia
 N900

On 30/06/17 15:36, Daniel Vetter wrote:

> I don't think registering before everything is loaded make sense. On the
> big desktop driver chips we have all the bridge/encoder/panel drivers
> built into the driver. arm-soc loves to make everything a separate module,
> but in the end if you decided to not compile half of the driver you need,
> then it's not going to work.

I don't think that's quite the same. On the desktop you just have the
video card, and it's easy to enable that single component. On an
embedded device you have the SoC's display controller and then possibly
multiple external encoders/panels on the board. Those external
components have to be separate modules, they can't be part of the SoC
driver. The desktop video card matches only to the SoC's display controller.

> Imo the only thing we should support to be hotplugged in drm is stuff you
> can physically hotplug (like atm connectors). Everything else just
> complicates the code for no good reason at all.

"unplugging" components would not give much, I think, but allowing
adding new displays at runtime would be a very good thing.

It's not only about mistakenly having the driver disabled in the kernel
config, it could also be that some base driver failed to probe, which
then makes an encoder or a panel to defer probing as it can't get the
base resource. But HDMI or some other panel would work fine, but with
current architecture can't be used.

And if you really want to optimize, one a phone-type device you could
have the LCD driver built-in, but HDMI drivers as modules, and only load
the HDMI drivers if the user actually needs the HDMI.

 Tomi

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)