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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 16 Dec 2021 01:13:56 +0100
From:   Javier Martinez Canillas <javierm@...hat.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Heiko Stübner <heiko@...ech.de>,
        "James (Qian) Wang" <james.qian.wang@....com>,
        Noralf Trønnes <noralf@...nnes.org>,
        Alexey Brodkin <abrodkin@...opsys.com>,
        Alison Wang <alison.wang@....com>,
        Anitha Chrisanthus <anitha.chrisanthus@...el.com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Boris Brezillon <bbrezillon@...nel.org>,
        Brian Starkey <brian.starkey@....com>,
        Chen-Yu Tsai <wens@...e.org>,
        Chun-Kuang Hu <chunkuang.hu@...nel.org>,
        David Lechner <david@...hnology.com>,
        Deepak Rawat <drawat.floss@...il.com>,
        Edmund Dea <edmund.j.dea@...el.com>,
        Emma Anholt <emma@...olt.net>,
        Erico Nunes <nunes.erico@...il.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Hyun Kwon <hyun.kwon@...inx.com>,
        Inki Dae <inki.dae@...sung.com>, Joel Stanley <joel@....id.au>,
        Joonyoung Shim <jy0922.shim@...sung.com>,
        Jyri Sarha <jyri.sarha@....fi>,
        Kamlesh Gurudasani <kamlesh.gurudasani@...il.com>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        Laurentiu Palcu <laurentiu.palcu@....nxp.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Liviu Dudau <liviu.dudau@....com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Marek Vasut <marex@...x.de>,
        Maxime Ripard <mripard@...nel.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>,
        Patrik Jakobsson <patrik.r.jakobsson@...il.com>,
        Paul Cercueil <paul@...pouillou.net>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Philippe Cornu <philippe.cornu@...s.st.com>,
        Qiang Yu <yuq825@...il.com>, Rob Clark <robdclark@...il.com>,
        Rob Herring <robh@...nel.org>,
        Russell King <linux+etnaviv@...linux.org.uk>,
        Russell King <linux@...linux.org.uk>,
        Sam Ravnborg <sam@...nborg.org>,
        Sandy Huang <hjc@...k-chips.com>, Sean Paul <sean@...rly.run>,
        Stefan Agner <stefan@...er.ch>,
        Thierry Reding <thierry.reding@...il.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Tian Tao <tiantao6@...ilicon.com>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Tomi Valkeinen <tomba@...nel.org>,
        Xinliang Liu <xinliang.liu@...aro.org>,
        Yannick Fertre <yannick.fertre@...s.st.com>
Subject: Re: [PATCH 00/60] drm: Make all drivers to honour the nomodeset
 parameter

Hello Laurent,

On 12/16/21 00:35, Laurent Pinchart wrote:

[snip]

>>
>> I've built tested with 'make allmodconfig && make M=drivers/gpu/drm/', but
>> only booted in a few devices with and without nomodeset in the cmdline. So
>> testing and reviewing for all the drivers would be highly appreciated.
> 
> The fact that the series is so big makes me think it would be better to
> handle this in the DRM core. Is there any way we could do so ? Otherwise
> we'll chase this issue forever in new drivers, and will be plagued with
> cargo cult problems.
> 

Yes, what Thomas suggested is to add a set of drm_module_{pci,platform}_driver()
macros in include/drm/drm_drv.h, that will just check whether the driver should
be registered or not and call the {pci,platform}_register_driver() functions.

That way the change in the drivers would just be something like the following:

-module_platform_driver(malidp_platform_driver);
+drm_module_platform_driver(malidp_platform_driver);

There are some drivers that still need a custom module init functions for various
reasons (e.g: register a set of devices/drivers, need to be a late init call, etc)
but at least for most drivers this should be handled transparently as long as they
use these drm_*_register_driver() macros.

So just ignore this series and I'll post a v2 soon.

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ