On 13/06/2024 10:48, Aisheng Dong wrote: > Hi Krzysztof, > >> From: Krzysztof Kozlowski <krzk@xxxxxxxxxx> >> Sent: 2024年6月13日 14:14 >> >> On 12/06/2024 09:20, Aisheng Dong wrote: >>> Hi Krzysztof >>> >>>> From: Krzysztof Kozlowski <krzk@xxxxxxxxxx> >>>> Sent: 2024年6月7日 15:08 >>>> >>>> On 07/06/2024 06:58, Vabhav Sharma wrote: >>>>>> >>>>>> Missing SoC compatibles. >>>>> Ok, I will use fsl,imx8dxl-sc-secvio >>>>>> >>>>>> So no, that's just abuse of DT to instantiate driver. >>>>>> >>>>>> NAK. Drop the binding. >>>>> I will detail the dt binding to describe the real hardware >>>> >>>> Still looks like way just to instantiate driver. Why it cannot be >>>> part of existing firmware SCU node? >>>> >>> >>> Technically yes. But SCU case is a little bit complicated as there're >>> many functions and all of them are already added as sub nodes in SCU >>> node for consistency and handling platform difference. >>> >>> I guess some of them, e.g. rtc, could be part of SCU node (reuse) >>> while some couldn't. e.g. pinctrl Do you want us to only make secvio >>> reuse existing SCU node? >> >> Yes >> > > Digging a bit more on the implementation. It seems there will be a > 'parent depends on child' issue when reusing the parent SCU node for secvio. > Considering the defer probe support and ocotop could be modules, I'm still thinking > If any solution. Do you have a good suggestion? I don't see any problem there. You will have even worse if making it children and using populate - unpredictable order. Best regards, Krzysztof
