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/[email protected]/ >> >> (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 <[email protected]> > > But please also add Link to this exact email I am writing. > > ( Link: ....)
Link: https://lore.kernel.org/r/[email protected]/ Best regards, Krzysztof
