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: <5af90b60-d65b-4e80-9a27-44938bbd450b@kernel.org>
Date: Fri, 15 Aug 2025 11:09:36 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Rob Herring <robh@...nel.org>, Icenowy Zheng <uwu@...nowy.me>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Drew Fustini <fustini@...nel.org>,
 Guo Ren <guoren@...nel.org>, Fu Wei <wefu@...hat.com>,
 Philipp Zabel <p.zabel@...gutronix.de>, Heiko Stuebner <heiko@...ech.de>,
 Andrzej Hajda <andrzej.hajda@...el.com>,
 Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
 Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
 Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>,
 Michal Wilczynski <m.wilczynski@...sung.com>, Han Gao
 <rabenda.cn@...il.com>, Yao Zi <ziyao@...root.org>,
 dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [RFC PATCH 2/8] dt-bindings: display: add versilicon,dc

On 15/08/2025 00:04, Rob Herring wrote:
>> +
>> +maintainers:
>> +  - Icenowy Zheng <uwu@...nowy.me>
>> +
>> +properties:
>> +  $nodename:
>> +    pattern: "^display@[0-9a-f]+$"
>> +
>> +  compatible:
>> +    const: verisilicon,dc
> 
> If the clocks or resets varies by platform, then you need an SoC 
> specific compatible still. If these clocks/resets are straight from the 
> RTL and any other number of clocks/resets is wrong, then we can stick 
> with just this compatible.

Shouldn't we have here always SoC compatible? Can it be ever used alone,
outside of given SoC?

I could imagine now:

items:
  - {}
  - const: verisilicon,dc


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ