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: <8cb8e7e9-7287-f8eb-e1d3-52effde0cceb@xen0n.name>
Date:   Mon, 22 May 2023 17:09:51 +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 17:05, Sui Jingfeng wrote:
> Hi,
> 
> On 2023/5/21 20:21, WANG Xuerui wrote:
>>> +++ b/drivers/gpu/drm/loongson/lsdc_debugfs.c
>>> @@ -0,0 +1,91 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2023 Loongson Technology Corporation Limited
>>> + */
>>> +
>>> +#include <drm/drm_debugfs.h>
>>> +
>>> +#include "lsdc_benchmark.h"
>>> +#include "lsdc_drv.h"
>>> +#include "lsdc_gem.h"
>>> +#include "lsdc_probe.h"
>>> +#include "lsdc_ttm.h"
>>> +
>>> +/* device level debugfs */
>>> +
>>> +static int lsdc_identify(struct seq_file *m, void *arg)
>>> +{
>>> +    struct drm_info_node *node = (struct drm_info_node *)m->private;
>>> +    struct lsdc_device *ldev = (struct lsdc_device 
>>> *)node->info_ent->data;
>>> +    const struct loongson_gfx_desc *gfx = to_loongson_gfx(ldev->descp);
>>> +    u8 impl, rev;
>>> +
>>> +    loongson_cpu_get_prid(&impl, &rev);
>>> +
>>> +    seq_printf(m, "Running on cpu 0x%x, cpu revision: 0x%x\n",
>>> +           impl, rev);
>>
>> Is this really needed/relevant for LSDC identification? AFAICS the 
>> loongson_cpu_get_prid helper has only one use (that's here), 
> 
> Yes, this is really needed, when doing the remote debugging, sometime 
> you only have a ssh login the target machine.
> 
> User of the driver could know what the host is in the DRM way.

Okay, so it's unavoidable coupling of CPU and DC models, because the DC 
hardware revision cannot be determined by looking at its revision field 
alone (i.e. multiple actual HW makes behaving differently, but sharing 
one DC revision).

I've always hoped things were different in the LoongArch era, turns out 
someone has failed me :-/ Then probably you should mention the necessity 
of the coupling somewhere with comments.

> 
>> so if it's not absolutely necessary you can just get rid of that 
>> function and lsdc_probe.h altogether.
> This function it written for the future, It will not be removed.

Usually we only introduce code when necessary. For now if others are 
fine with this then I'd be fine too.

>>
>>> +
>>> +    seq_printf(m, "Contained in: %s\n", gfx->model);
>>
>> "model: " would be more appropriate for a piece of info looking like a 
>> "gfx->model"?
> No, these are nearly equivalent.

While I don't completely get why, it's mostly a stylistic recommendation 
so maybe it's okay anyway. It's just debug information after all.

-- 
WANG "xen0n" Xuerui

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