Hi Krzysztof, On Mon, Feb 06, 2023 at 07:20:21PM +0100, Krzysztof Kozlowski wrote: > On 06/02/2023 11:45, Laurent Pinchart wrote: > > On Thu, Jul 14, 2022 at 01:56:13PM +0200, Krzysztof Kozlowski wrote: > >> On 14/07/2022 13:29, Laurent Pinchart wrote: > >>> On Thu, Jul 14, 2022 at 01:23:41PM +0200, Krzysztof Kozlowski wrote: > >>>> On 14/07/2022 13:12, Laurent Pinchart wrote: > >>>>>>>>> One option would be to support the following three compatible values: > >>>>>>>>> > >>>>>>>>> compatible = "melexis,mlx75026", "melexis,mlx7502x"; > >>>>>>>>> compatible = "melexis,mlx75027", "melexis,mlx7502x"; > >>>>>>>>> compatible = "melexis,mlx7502x"; > >>>>>>>>> > >>>>>>>>> The last one only would trigger autodetection. I'm still not sure how to > >>>>>>>>> document that properly in bindings though. > >>>>>>>> > >>>>>>>> I missed that part of binding. > >>>>>>>> > >>>>>>>> Wildcards are not allowed in compatible, so mlx7502x has to go. > >>>>>>> > >>>>>>> Really ? We've had fallback generic compatible strings since the > >>>>>>> beginning. > >>>>>> > >>>>>> Fallback generic compatibles are allowed. Wildcards not. Wildcards were > >>>>>> actually never explicitly allowed, they just slipped in to many > >>>>>> bindings... We have several discussions on this on mailing list, so no > >>>>>> real point to repeat the arguments. > >>>>>> > >>>>>> There is a difference between generic fallback. If the device follows > >>>>>> clear specification and version, e.g. "foo-bar-v4", you can use it for > >>>>>> generic compatible. This is more common in SoC components. Requirement - > >>>>>> there is a clear mapping between versions and SoCs. > >>>>> > >>>>> I'm not sure to see a clear difference between the two concepts. > >>>> > >>>> The clear difference is that you have a versioned and re-usable hardware > >>>> block plus clear mapping which version goes to which SoC. Version > >>>> numbers usually start with 1, not with 75025. 75025 is a model name. > >>> > >>> How about Documentation/devicetree/bindings/serial/renesas,scif.yaml for > >>> instance, where the version number isn't known and the SoC name is used > >>> instead ? Is that acceptable ? > >> > >> This is the second case I mentioned - family of devices where the family > >> fallback is not allowed to be alone. You cannot use just "renesas,scif" > >> in DTS. > > > > OK. Does this mean you are fine with > > > > compatible = "melexis,mlx75026", "melexis,mlx7502x"; > > compatible = "melexis,mlx75027", "melexis,mlx7502x"; > > > > where "melexis,mlx7502x" is considered to be the family fallback, but > > not > > > > compatible = "melexis,mlx7502x"; > > > > alone ? > > Correct. > > (...) > > >>> > >>> In a laptop or tablet with a camera sensor, you likely don't want > >>> autodetection. In an industrial device, you don't care, and having the > >>> ability to auto-detect the exact sensor model when booting saves cost in > >>> the production chain as a single image can work across different models. > >> > >> We talk about the case here, not generic. Do you want to have > >> autodetection possible here or not? > > > > I'd like to support auto-detection, but not make it mandatory. Assuming > > a family of chips supported by one driver with hardware that makes > > auto-detection possible, I have use cases where I specifically don't > > want auto-detection as it would have undesirable side effects at probe > > time, and other use cases where I want auto-detection as it lowers the > > costs in the production chain. I thus need to be able to specify, in DT, > > whether to use auto-detection or not, and when not using auto-detection, > > specify the exact chip model. > > OK, I understand. This however stretches the Devicetree approach - you > are putting OS policy of device probing into the DT binding. What's > more, it serves only Linux' purpose. If other OS/software is fine with > auto-detection on first use (thus no privacy concerns), then all this > discussion is not relevant. The binding is independent of OS, thus we > should not align it to our specific OS behavior. > > Maybe Linux needs some generic runtime knob to turn on/off autodetection > for all devices. It does not look like a job for DT. If we want to be able to run without auto-detection, regardless of the operating system, we need to specify the exact model in DT, otherwise a driver wouldn't be able to identify the device. If we want to use auto-detection, that's for the purpose of simplifying system integration, with a single DT that covers multiple device variants. Those two use cases thus require DT binding that allow for both options, specifying an exact model, or being more generic. I agree that deciding to auto-detect based on what compatible strings are specified may be specific to a particular Linux driver, but the fact that we need the two options to support both use cases isn't OS-specific in my opinion. -- Regards, Laurent Pinchart
