linux-kernel - Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-tmds181: Add TI TMDS181 and SN65DP159 bindings

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: <3a4448a5-a01f-4d4e-a890-56eb9357abd3@topic.nl>
Date: Wed, 20 Aug 2025 11:37:24 +0200
From: Mike Looijmans <mike.looijmans@...ic.nl>
To: Krzysztof Kozlowski <krzk@...nel.org>, 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


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 consider the environment before printing this e-mail
On 20-08-2025 08:44, Krzysztof Kozlowski wrote:
> On 19/08/2025 10:26, Mike Looijmans wrote:
>> On 19-08-2025 09:51, Krzysztof Kozlowski wrote:
>>> On 19/08/2025 09:46, Mike Looijmans wrote:
>>>>>> +
>>>>>> +properties:
>>>>>> +  compatible:
>>>>>> +    enum:
>>>>>> +      - ti,tmds181
>>>>>> +      - ti,sn65dp159
>>>>> The driver contains:
>>>>> +	{ .compatible = "ti,tmds181", },
>>>>> +	{ .compatible = "ti,sn65dp159", },
>>>>> +	{}
>>>>> so why is a fallback compatible not suitable here?
>>>> I don't understand the question. The two are slightly different chips,
>>> Your driver says they are compatible. No one said the same, but compatible.
>>>
>>>> so it makes sense to describe that in the DT.
>>> Compatible devices should use fallback. There is plenty of examples (90%
>>> of all binding files?) including example-schema describing this.
>> Please help me out here, I'm happy to oblige, but I don't understand
>> what you're asking.
>>
>> To the best of my knowledge "fallback" compatible is when you write
>> something like this in the device-tree:
>>      compatible = "st,m25p80", "jedec,spi-nor";
>> Which means that we can use the "jedec,spi-nor" driver if there's no
>> specific match for "st,m25p80", correct?
> Yes.
>
>> I don't understand how that relates to your request, this is the first
>> time I ever got this particular feedback. Looking at say the
>> ti,sn65dsi83 driver, it does the same thing (supports the ti,sn65dsi83
>> and ti,sn65dsi84).
>>
>> Please explain or point me somewhere where I can find this?
> I already pointed out to example-schema.
>
> 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 
compatibles, right?