Re: [PATCH 1/4] dt-bindings: display: panel: Add Novatek NT37705

[Krzysztof Kozlowski <krzk@kernel.org>]

On 08/05/2026 09:44, Luca Weiss wrote:
> Hi Krzysztof,
> 
> On Tue May 5, 2026 at 9:25 AM CEST, Krzysztof Kozlowski wrote:
>> On 05/05/2026 08:40, Luca Weiss wrote:
>>>>>>> +  compatible:
>>>>>>> +    contains:
>>>>>>> +      const: boe,bj631jhm-t71-d900
>>>>>>
>>>>>> Compatible doesn't match the filename, nor does the commit message match
>>>>>> what you've got here. Sounds like you're missing a fallback to
>>>>>> $filename.
>>>>>
>>>>> The last times I was upstreaming panel drivers (Feb 2024 and June 2025),
>>>>> this was the requested way of doing things.
>>>>
>>>> So this was requested that time and is requested now. What is here
>>>> uncertain?
>>>>
>>>>>
>>>>> Compatible being the company and model number making the actual panel
>>>>> assembly (driver IC + touchscreen + glass etc), while the rest being
>>>>> named after the driver IC manufacturer & number.
>>>>
>>>> So exactly what was asked for...
>>>
>>> I don't quite understand what is asked for now, that's my issue.
>>>
>>> 1. Change the filename to boe,bj631jhm-t71-d900.yaml and leave the rest
>>>    as-is.
>>>
>>> 2. Add a fallback compatible for novatek,nt37705. IIRC last time it was
>>>    argued that a "generic" nt37705 driver will never be correct for a
>>>    specific panel since it's missing a bunch of panel-specific init. So
>>>    that's why there should not be a fallback to nt37705.
>>
>> To my limited knowledge the (2) with fallback describing the specific IC
>> is preferred, because that compatible although not currently usable is
>> still specific and describes actual IC used. I imagine that such
>> fallback still could be useful to some SW implementation to determine
>> the IC and act based on that.
>>
>> If you have sources of other preference, please share, but I just gave
>> same review to Neil for his ayaneo,wt0600-2k panels.
> 
> I found the discussion from 2024 for the Fairphone 4 panel:
> 
> https://lore.kernel.org/lkml/f9164049-6529-42c1-a35a-e91132c823b9@linaro.org/
> 
> (quoting)
> 
> '''
>   Not sure if "himax,hx83112a" is needed here, the "djn,9a-3r063-1102b"
>   is enough to know the IC is hx83112a.
> 
>   I don't think you'll ever find a "djn,9a-3r063-1102b" with another
>   controller IC ?
> 
>   And "himax,hx83112a" alone as fallback is not enough to describe the
>   panel hardware, so I think it should be dropped.
> '''
> 
> With Konrad replying "+1" to that.

The arguments from Linux drivers point of view are correct. And you can
apply the same to board-level compatibles. Each most-specific board
level compatible already defines the soc, thus soc-compatible fallback
is redundant, right?

And also the soc-compatible fallback is too generic to be used alone by
the SW in many cases.

Yet we use it. Same here. Why? For the same reasons as we use for
board-level compatibles. Because that's convenient way for defining
quirks for the controller IC which otherwise would need to match all
panel compatibles.

I do not insist on this (for panels, of course), however I would prefer
consistency in the code and in the reviews. Heh, I bet you too would
prefer consistency. :) All my recent reviews were proposing to have the
fallback, thus I consistently propose one here, but I won't object for
the patch in current form, thus:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

But please also add Link to this exact email I am writing.

( Link: ....)

Best regards,
Krzysztof