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: <2e16f923-5dad-4c8d-80d7-667dbece92c9@kernel.org>
Date: Wed, 20 Aug 2025 13:35:48 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Mike Looijmans <mike.looijmans@...ic.nl>, Conor Dooley <conor@...nel.org>
Cc: dri-devel@...ts.freedesktop.org, Andrzej Hajda <andrzej.hajda@...el.com>,
 Conor Dooley <conor+dt@...nel.org>, David Airlie <airlied@...il.com>,
 Jernej Skrabec <jernej.skrabec@...il.com>, Jonas Karlman <jonas@...boo.se>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>,
 Neil Armstrong <neil.armstrong@...aro.org>, Rob Herring <robh@...nel.org>,
 Robert Foss <rfoss@...nel.org>, Simona Vetter <simona@...ll.ch>,
 Thomas Zimmermann <tzimmermann@...e.de>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-tmds181: Add TI TMDS181
 and SN65DP159 bindings

On 20/08/2025 11:37, Mike Looijmans wrote:
> 
> Met vriendelijke groet / kind regards,
> 
> Mike Looijmans
> System Expert
> 
> 
> TOPIC Embedded Products B.V.
> Materiaalweg 4, 5681 RJ Best
> The Netherlands
> 
> T: +31 (0) 499 33 69 69
> E: mike.looijmans@...ic.nl
> W: www.topic.nl

Please fix your email client not to attach such top signature.

...

>>
>> Also, e.g. first file in iio/adc:
>> adi,ad4000.yaml
>>
> I think I get it. Instead of having compatibles "a" and "b" the driver only 
> supports "a" in its match table, and the devicetree entry must be either 
> compatible="a"; or compatible="b","a". Using compatible="b"; would be disallowed.
> 
> I actually planned (I have implemented it locally already for v3) for the 
> driver to check the chip type and complain if it doesn't match the devicetree. 
> If the wrong device is there, the most likely cause is that the input and 
> output buses got mixed up. That would also justify having separate 

I don't understand why. I don't get what is input and output bus.

Either devices are compatible or not.

If you can check which device you have via registers, then usually they
are compatible.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ