On 04/04/2023 10:59, Abel Vesa wrote: > On 23-04-04 07:41:55, Krzysztof Kozlowski wrote: >> On 03/04/2023 22:05, Abel Vesa wrote: >>> Starting with SM8550, the ICE will have its own devicetree node >>> so add the qcom,ice property to reference it. >>> >>> Signed-off-by: Abel Vesa <abel.vesa@xxxxxxxxxx> >>> --- >>> >>> The v4 is here: >>> https://lore.kernel.org/all/20230327134734.3256974-4-abel.vesa@xxxxxxxxxx/ >>> >>> Changes since v4: >>> * Added check for sm8550 compatible w.r.t. qcom,ice in order to enforce >>> it while making sure none of the other platforms are allowed to use it >> >> Why? > > SM8550 will be the first platform to use the new DT bindings w.r.t ICE. This I understand, but why other platforms cannot use it? > >> >> Also, this does not solve my previous question still. > > Well, the clocks are not added for the a few platforms (which include > SM8550). Same for 'ice' reg range.. So the only thing left is to > enforce the qcom,ice property availability only for SM8550. I believe > it solves the mutual exclusiveness of the "ice" reg range along with the > clocks versus the qcom,ice property, by enforcing at compatible level. Ah, I think I understand. That would work except I don't understand why enforcing qcom,qce only for specific, new SoCs. Assuming it is a correct hardware representation, we want it for everyone, don't we? Best regards, Krzysztof
