On 02/02/2023 23:27, Vladimir Zapolskiy wrote:
> Hi Krzysztof,
>
> On 2/2/23 15:53, Krzysztof Kozlowski wrote:
>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>> From: Neil Armstrong <neil.armstrong@xxxxxxxxxx>
>>>
>>> On certain Snapdragon processors, the crypto engine clocks are enabled by
>>> default by security firmware.
>>
>> Then probably we should not require them only on these variants.
>
> the rationale is clear, but here comes a minor problem, older platforms
> require clocks, when newer ones do not. When a generic SoC-specific compatible
> is introduced, let say "qcom,ipq4019-qce", it itself requires the clocks,
> but then newer platforms can not be based on this particular compatible,
> otherwise they will require clocks and this comes as invalid.
>
> How to resolve it properly, shall there be another generic SoC-specific
> compatible without clocks and NOT based on that "qcom,ipq4019-qce" compatible?
>
> By the way, QCE on SM8150 also shall not need the clocks.
Assuming you have:
1. ipq4019 requiring clocks
2. msm8996 compatible with ipq4019, requiring clocks
3. ipq6018 compatible with ipq4019, not requiring clocks
allOf:
- if:
properties:
compatible:
enum:
- ipq4019-qce
then:
required:
- clocks
- if:
properties:
compatible:
contains:
enum:
- msm8996-qce
then:
required:
- clocks
That's not pretty.
Another solution is to make non-clock-requiring variants as their own
family:
1. msm8996-qce, ipq4019-qce
2. sm8550-qce, sm8150-qce
and then in the driver you need two entries - ipq4019 and sm8150.
I like the latter, because for clock-requiring variants your driver
should actually get them and require. For non-clock-requiring variants,
you just skip the clocks (do not fail). Therefore you need different
driver data for these two families.
Best regards,
Krzysztof
