Hi Krzysztof,
On 2/3/23 10:17, Krzysztof Kozlowski wrote:
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.
many thanks for the detailed explanation, the first of two solutions will
be even more clumsy and convoluted, since there should be lists split into
two baskets.
Thus I will go with the second variant and add two family compatibles.
--
Best wishes,
Vladimir
