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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 14/05/2026 17:11, Krzysztof Kozlowski wrote:
> 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: ....)

Link: https://lore.kernel.org/r/81a3c207-4d8f-490f-8e2a-6f3f4c2acd35@kernel.org/

Best regards,
Krzysztof