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]
Date:   Wed, 23 Mar 2022 03:14:23 +0000
From:   "Jiaxun Yang" <jiaxun.yang@...goat.com>
To:     "Sui Jingfeng" <15330273260@....cn>,
        "Maxime Ripard" <mripard@...nel.org>,
        "Thomas Zimmermann" <tzimmermann@...e.de>,
        "Roland Scheidegger" <sroland@...are.com>,
        "Zack Rusin" <zackr@...are.com>,
        "Christian Gmeiner" <christian.gmeiner@...il.com>,
        "David Airlie" <airlied@...ux.ie>,
        "Daniel Vetter" <daniel@...ll.ch>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
        "Dan Carpenter" <dan.carpenter@...cle.com>,
        "Krzysztof Kozlowski" <krzk@...nel.org>,
        "Andrey Zhizhikin" <andrey.zhizhikin@...ca-geosystems.com>,
        "Sam Ravnborg" <sam@...nborg.org>,
        "David S . Miller" <davem@...emloft.net>,
        "Lucas Stach" <l.stach@...gutronix.de>,
        "Maarten Lankhorst" <maarten.lankhorst@...ux.intel.com>,
        "Ilia Mirkin" <imirkin@...m.mit.edu>,
        "Qing Zhang" <zhangqing@...ngson.cn>,
        suijingfeng <suijingfeng@...ngson.cn>
Cc:     "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        "Huacai Chen" <chenhuacai@...nel.org>,
        "Tiezhu Yang" <yangtiezhu@...ngson.cn>, liyi@...ngson.cn
Subject: Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board



在2022年3月23日三月 上午3:07,Sui Jingfeng写道:
> On 2022/3/23 10:29, Jiaxun Yang wrote:
>>
>>
>> 在 2022/3/23 1:53, Sui Jingfeng 写道:
>>> Hi, Jiaxun
>>>
>>> Build all dts into vmlinuz will make the vmlinuz bigger and bigger.
>>> How does the kernel get the dtb is another big issue, either from 
>>> built-in
>>> dtb or pass from the firmware(pmon and uefi etc). This should be
>>> solved with another patch carefully. Providing board specific dts
>>> helps to code review, it helps reviewers understand that there are
>>> variant boards and have to be express with different OF graph.
>> Hi,
>>
>> I insist my taste on those code. If the only intention is to demonstrate
>> the usage of the driver then please just leave them in dt document
>> or commit message.
>>
>>>
>>> Now, there are about 6 dts under arch/mips/boot/dts/loongson/,
>>> Suppose loongson have 1000+ different board, do you want built all
>>> of them into vmlinuz?
>> Note that we are supporting all those boards on "platform" bias. Which
>> means if they share similar design then they will use the same DTS.
>> If we have a new design then unfortunately our kernel binary must grow.
>>
>> For those who intended to build a size-optimized kernel they will be
>> able to disable unused DTS in Kconfig.
>>
>> If you want to blame somebody for the problem then please don't
>> blame us. We tried very hard to fit all those stuff into kernel's model
>> of devices. You should blame those who did the initial design of
>> Loongson's boot interface that failed to introduce a proper way
>> to describe the platform.
>>
>>>
>>> Besides, ls7a1000 and ls2k1000 lack a i2c driver, gpio driver,
>>> pwm driver, clk driver, can you pay more attention to salve those
>>> problems, please ?
>> Are you trying to make a TODO list for your colleague :-)
>>
>> We , community developers, don't owe you anything. So please
>> don't expect anything from us. I lost access to most Loongson
>> devices since I'm currently study abroad, but I'm determined to
>> keep platform code in a good shape. That's my duty as a maintainer.
>>
>> Thanks.
>> - Jiaxun
>
> Providing a few board specific dts doesn't hurt anybody.

There are a lot of things that don't hurt anybody but we shouldn't do.

The standard of reviewing the code is not "doesn't hurt anybody". It's "do the right thing".

Please reference:
https://www.kernel.org/doc/html/latest/process/6.Followthrough.html

>
> Can we leave the problem(passing correct dts to the kernel) untouched and
>
> solve it in the feature with a another patch, ok?

Then please drop platform DTS part.

I must NAK this part, sorry.

Thanks
-- 
- Jiaxun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ