linux-kernel - Re: [PATCH v14 1/2] drm: add kms driver for loongson display controller

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: <97fe7af2-0a93-3f28-db6e-40a9b0798d49@xen0n.name>
Date:   Mon, 22 May 2023 16:09:39 +0800
From:   WANG Xuerui <kernel@...0n.name>
To:     Sui Jingfeng <15330273260@....cn>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Sui Jingfeng <suijingfeng@...ngson.cn>,
        Li Yi <liyi@...ngson.cn>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Christian Koenig <christian.koenig@....com>,
        Emil Velikov <emil.l.velikov@...il.com>
Cc:     linaro-mm-sig@...ts.linaro.org, loongson-kernel@...ts.loongnix.cn,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Javier Martinez Canillas <javierm@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Liu Peibao <liupeibao@...ngson.cn>, linux-media@...r.kernel.org
Subject: Re: [PATCH v14 1/2] drm: add kms driver for loongson display
 controller

On 2023/5/22 16:02, Sui Jingfeng wrote:
> Hi,
> 
> On 2023/5/21 20:21, WANG Xuerui wrote:
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/loongson/Kconfig
>>> @@ -0,0 +1,17 @@
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +
>>> +config DRM_LOONGSON
>>> +    tristate "DRM support for Loongson Graphics"
>>> +    depends on DRM && PCI && MMU
>>> +    select DRM_KMS_HELPER
>>> +    select DRM_TTM
>>> +    select I2C
>>> +    select I2C_ALGOBIT
>>> +    help
>>> +      This is a DRM driver for Loongson Graphics, it may including
>>
>> Drop "it may"; "including" should be enough.
>>
> 'it may' is more *precise* here, because currently we don't ship with 
> the support for loongson 2K series SoC.
> 
> I'm try to be precise as far as I can, we avoid made this driver too 
> large by ignore loongson 2K series SoC temporary.

That's a good idea! For now the patch is so large that my review reply 
is said to be dropped by the lists. Focusing on one bunch of similar 
models first then adding support for the rest not-so-similar models is 
very friendly towards the reviewing process and will help code quality too.

> 
>>> +      LS7A2000, LS7A1000, LS2K2000 and LS2K1000 etc. Loongson LS7A
>>> +      series are bridge chipset, while Loongson LS2K series are SoC.
>>> +
>>> +      If "M" is selected, the module will be called loongson.
>>
>> Just "loongson"? 
> 
> Yes,  when compile this driver as module,  loongson.ko will be generated.
> 
>   drm radeon is also doing so, See drm/radeon/Kconfig.
> 
>> I know it's like this for ages (at least dating back to the MIPS days) 
>> but you really don't want to imply Loongson is mainly a GPU company. 
>> Something like "loongson_drm" or "lsdc" or "gsgpu" could be better. 
> 
> No, these name may have backward compatibility problems.
> 
> Downstream driver already taken those name.
> 
> userspace driver need to differentiate them who is who.

IMO this shouldn't be a problem. Let me try explaining this: currently, 
upstream / the "new world" doesn't have any support for this driver at 
all, so any name will work; just use whatever is appropriate from an 
upstream's perspective, then make the userspace bits recognize both 
variants, and you'll be fine. And the "existing" userspace drivers can 
also carry the change, it'll just be a branch never taken in that setup.

So, I'm still in favor of keeping the upstream "clean" without dubious 
names like this (bare "loongson"). What do you think about my suggestion 
above?

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/