On Tue, Dec 12, 2023 at 11:06:42AM -0800, Nikunj Kela wrote: > + Linaro team > > On 12/12/2023 11:01 AM, Krzysztof Kozlowski wrote: > > On 12/12/2023 18:45, Nikunj Kela wrote: > > > We are abstracting some resources(ex. clocks) under new firmware on an > > > existing platform therefore need to make changes in certain drivers to > > > work with that firmware. We need to make a distinction between two > > > different variants of the FW. In one case, some resources will be > > > abstracted while in other case, they won't be abstracted. My query is - > > > "should we define a new compatible string for the variant with > > > abstracted resources(in FW) or we should add a new DT property keeping > > > the compatible same?" > > Hi, > > > > Usually change in the interface or behavior warrants new compatible. > > Property would be suitable if the same device, e.g. same SoC component > > with same FW, was configured differently on different boards. > > Here, the hardware is going to be the same, but the resources (clocks, regulators, etc...) will be controlled by the firmware instead of OS. Should we still use a different compatible? For the similar usecase, we already have properties like 'qcom,controlled-remotely' to let the OS know that it should not configure the hardware and just consume it. To me both usecases sounds similar. - Mani > > Best regards, > > Krzysztof > > Thank you for your prompt response! Will use different compatible as > advised. > -- மணிவண்ணன் சதாசிவம்
