On 06/02/2023 11:45, Laurent Pinchart wrote: > Hi Krzysztof, > > Very late reply, this had fallen through the cracks. > > 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. Best regards, Krzysztof
