linux-kernel - Re: [PATCH 11/60] drm/gud: Add support for the nomodeset kernel parameter

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: <4059e488-38fe-2b79-191c-6e921f262c9f@tronnes.org>
Date:   Thu, 16 Dec 2021 16:47:49 +0100
From:   Noralf Trønnes <noralf@...nnes.org>
To:     Thomas Zimmermann <tzimmermann@...e.de>,
        Javier Martinez Canillas <javierm@...hat.com>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 11/60] drm/gud: Add support for the nomodeset kernel
 parameter



Den 16.12.2021 09.20, skrev Thomas Zimmermann:
> Hi
> 
> Am 15.12.21 um 22:37 schrieb Noralf Trønnes:
>>
>>
>> Den 15.12.2021 01.59, skrev 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.
>>>
>>> But only a few DRM drivers currently check for nomodeset, make this
>>> driver
>>> to also support the command line parameter.
>>>
>>> Signed-off-by: Javier Martinez Canillas <javierm@...hat.com>
>>> ---
>>>
>>
>> I don't understand why this is applicable to USB drivers, there's no way
>> the firmware can setup a framebuffer and continue pushing pixels over
>> USB when Linux has been given control over the USB bus?
>>
>> The same argument goes for the SPI drivers in drm/tiny/ as well.
> 
> The intended semantics of the option is to disable every display output
> except for the buffer provided by the firmware.
> 

If that's the case this patch is:

Acked-by: Noralf Trønnes <noralf@...nnes.org>

> With USB it still would still disable the driver. That's useful if only
> for debugging. There are also systems with hard-wired USB displays where
> one cannot just unplug the adapter.
> 
> Admittedly, USB graphics is a bit of an odd use case, but neither is it
> too far fetched IMHO.
> 
> Best regards
> Thomas
> 
>>
>> Noralf.
>>
>>>   drivers/gpu/drm/gud/gud_drv.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/gud/gud_drv.c
>>> b/drivers/gpu/drm/gud/gud_drv.c
>>> index 3f9d4b9a1e3d..4d253d249512 100644
>>> --- a/drivers/gpu/drm/gud/gud_drv.c
>>> +++ b/drivers/gpu/drm/gud/gud_drv.c
>>> @@ -446,6 +446,9 @@ static int gud_probe(struct usb_interface *intf,
>>> const struct usb_device_id *id)
>>>       u32 *formats;
>>>       int ret, i;
>>>   +    if (drm_firmware_drivers_only())
>>> +        return -ENODEV;
>>> +
>>>       ret = usb_find_bulk_out_endpoint(intf->cur_altsetting, &bulk_out);
>>>       if (ret)
>>>           return ret;
>>>
>