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: <a919884b-1e28-bf49-5de6-5cc2b6329969@redhat.com>
Date:   Wed, 15 Dec 2021 10:45:05 +0100
From:   Javier Martinez Canillas <javierm@...hat.com>
To:     Thomas Zimmermann <tzimmermann@...e.de>,
        Lucas Stach <l.stach@...gutronix.de>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Cc:     Russell King <linux+etnaviv@...linux.org.uk>,
        Maxime Ripard <mripard@...nel.org>,
        Erico Nunes <ernunes@...hat.com>
Subject: Re: [PATCH 07/60] drm/etnaviv: Add support for the nomodeset kernel
 parameter

[adding Erico Nunes to Cc list]

On 12/15/21 10:39, Thomas Zimmermann wrote:
> (cc'ing Maxime)
> 
> Hi
> 
> Am 15.12.21 um 10:18 schrieb Lucas Stach:
>> Hi Javier,
>>
>> Am Mittwoch, dem 15.12.2021 um 01:59 +0100 schrieb Javier Martinez Canillas:
>>> According to disable Documentation/admin-guide/kernel-parameters.txt, this
>>> parameter can be used to disable kernel modesetting.
>>>
>>> DRM drivers will not perform display-mode changes or accelerated rendering
>>> and only the systewm system framebuffer will be available if it was set-up.
>>>
>> Etnaviv is a render-only driver, so will no perform any modesetting on
>> a display device, so I'm not sure if it's sensible to cover it under
>> the nomodeset parameter. I see that it is consistent with the other
>> drivers that deal with a combined render/display device, where the
>> render device also gets disabled with the nomodeset param, but it
>> doesn't really match the description of what the parameter is supposed
>> to do.
>>
>> I'm not opposed to take this patch for consistency reasons, but I would
>> like to hear some more opinions from other DRM folks.
> 
> Our assumption is that we want to disable all DRM drivers; except those 
> that operate on the firmware's original framebuffer. That's why the the 
> test is called drm_firmware_drivers_only().
> 

Yes, we tried to document the implicit "nomodeset" semantics to make that
clear: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b22a15a5aca34c8f59b770f858b1c21d347175e0

> We know that nomodeset is a terrible name. We only kept it because it 
> was already there, widely used, and already does what we need.
> 
> We had similar concerns with the v3d driver of vc4. Javier, maybe we 
> should leave-out such special cases for now and discuss them separately?
>

I was discussing the same with Erico (one of the lima driver developers).

Agree that we could leave those for now. Will drop from the patch-set all
the DRM drivers that don't have the DRIVER_MODESET .driver_features flag. 
 
> Best regards
> Thomas
> 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ