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:   Wed, 2 Aug 2017 12:12:12 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Tomi Valkeinen <tomi.valkeinen@...com>
Cc:     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 Mon, Jul 31, 2017 at 04:21:51PM +0300, Tomi Valkeinen wrote:
> 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.

Please take a look at the encoder drivers both nouveau and i915 have had
(for older hw). In neither of these cases did we register an incomplete
driver.

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

We do, just register another drm_device.

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

I don't see why we should support this as a valid use-case. E.g. if i915
fails to load a component (just because it's all in the same .ko doesn't
mean it's not multiple bits, same way you can have multiple drivers in the
same .ko), we also fail the overall driver bind. Really not seeing any
difference with arm-soc vs. desktop here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch