On 15/10/2024 18:46, Rob Herring wrote: >>>> >>>> How so ? Even if we assume that the device requires a specific clock >>>> frequency (which is often not the case for camera sensors, the >>>> limitation usually comes from drivers, so the constraint shouldn't be >>>> expressed in the bindings in that case), there is no overall requirement >>>> to assign a clock rate as in many cases the clock will come from a >>>> fixed-frequency oscillator. This seems to be a constraint that is >>>> outside of the scope of DT bindings. It is similar to regulators, where >>>> the regulator consumer doesn't have a way to express supported voltages >>>> in its DT bindings. >>> >>> This property does not say it comes from a fixed-frequency oscillator, >>> so I do not understand why you think it is unreasonable constraint. I >>> have no clue what the author wanted to say here, so I just explained >>> that there is a meaning behind requiring such properties. If you claim >>> device or implementations do not have such requirement, after >>> investigating each case, feel free to drop this. I think I also stated >>> this already in other reply. >> >> For camera sensor drivers I'm pretty sure we can drop those properties >> when they're marked as required, as there's no intrinsic characteristics >> of camera sensors that would require assigned-clock*. > > I tend to agree, and would take it one step further to say that applies > everywhere. Whatever clock setup needed is outside the scope of a > binding. The simplest case is all input clocks are fixed. The next > simplest case is firmware did all clock setup needed for a specific > board and the boot time default works. Ack. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> Best regards, Krzysztof
