drivers: qcom: Add QRNG and secure watchdog drivers for Bobcat family

[thariaruchamy-bit]

Implement hardware drivers for random number generation and watchdog
functionality across the Qualcomm Bobcat (IPQ) platform family.

QRNG Driver (ipq52xx):

• Implement direct QRNG hardware driver for ipq52xx platform
• Register QRNG memory regions in secure world MMU for
  proper VA mapping
• Enable CFG_HWRNG_PTA configuration for ipq52xx

Secure Watchdog Driver (Bobcat Family):

• Add QCOM APSS secure watchdog driver for Bobcat platform family
• Map APSS_WDT_TMR2_BASE into secure I/O memory
• Configure bark timeout (6s) and bite timeout (22s) using 32 KHz clock
  with millisecond-to-hardware tick conversion
• Register qcom_sec_wdog_bark_handler() for SEC_WDOG_BARK_INT_ID
  via interrupt_create_handler()
• Service watchdog in bark handler via WDOG_RESET register

Platform Configuration:

• Enable CFG_QCOM_SEC_WDOG in bobcat/arch.mk for all Bobcat targets
• Define per-target base addresses and interrupt IDs in target_config.h:
  • ipq96xx/ipq54xx:
    APSS_WDT_TMR2_BASE = 0x0F411000
    bark_int = 0x36
  • ipq52xx:
    APSS_WDT_TMR2_BASE = 0x0B117000
    bark_int = 0x23

Signed-off-by: Harikrishna hart@qti.qualcomm.com

[zelvam95]

Have shared initial review comments. Please check it out and fix them @thariaruchamy-bit

@ldts / @b49020, Please help to review the patches posted here when you guys have some time and share your feedback as well, would be really helpful.

[b49020]

@thariaruchamy-bit how is QRNG driver different from the PRNG driver? TBH, I don't see any difference. Please rather reuse the existing driver.

[zelvam95]

@thariaruchamy-bit how is QRNG driver different from the PRNG driver? TBH, I don't see any difference. Please rather reuse the existing driver.

@b49020, QRNG is a separate H/W IP thats different from PRNG H/W IP. Discussed previously with @ldts and we have certain features in QRNG like "KATS" (Known answer tests) which we can potentially add in future and hence we thought it'd be better to keep it as a separate driver based on the discussion?

Would you rather suggest to keep common driver now and split it later whenever we add those QRNG specific features? Or can we keep it this way now and add features into PRNG/QRNG later? (as required?)

Also, if we have to use the same driver, would it be an option to rename the prng/prng.c to rng/rng.c and keep the macro names generic so that each platform can define the QRNG/PRNG EE addr as applicable? Keeping the driver/config as PRNG and using it in a platform which has QRNG IP (not PRNG IP) would be confusing?

Note: If we did PRNG/QRNG init completely in OP-TEE, then the sequences would be different, here we are re-using the init done by bootloaders and in its current state, it seems like there are no major diffs.

[zelvam95]

@thariaruchamy-bit how is QRNG driver different from the PRNG driver? TBH, I don't see any difference. Please rather reuse the existing driver.

@b49020, QRNG is a separate H/W IP thats different from PRNG H/W IP. Discussed previously with @ldts and we have certain features in QRNG like "KATS" (Known answer tests) which we can potentially add in future and hence we thought it'd be better to keep it as a separate driver based on the discussion?

Would you rather suggest to keep common driver now and split it later whenever we add those QRNG specific features? Or can we keep it this way now and add features into PRNG/QRNG later? (as required?)

Also, if we have to use the same driver, would it be an option to rename the prng/prng.c to rng/rng.c and keep the macro names generic so that each platform can define the QRNG/PRNG EE addr as applicable? Keeping the driver/config as PRNG and using it in a platform which has QRNG IP (not PRNG IP) would be confusing?

Note: If we did PRNG/QRNG init completely in OP-TEE, then the sequences would be different, here we are re-using the init done by bootloaders and in its current state, it seems like there are no major diffs.

Hi @thariaruchamy-bit,

Discussed with Sumit. The suggestion is to rename the driver as qcom-rng.c and then, we can create an abstraction layer based on platform support. (i.e. qrng or prng base addresses alone can come from target specific headers that we already have). That way we can have a single driver for now. We can create more abstractions/layers later if we add QRNG/PRNG specific stuff.

[ldts]

@zelvam95 @b49020 the abstraction is a bit silly TBH (the driver is basically a single function that could be in a header file); the IPs are different, they drive different use cases (one offers crypto key generation capabilties, the other one doesnt even thought it is being used in that way because we have no other choice).

Forcing a shared abstraction for a function is really unnecessary...best is keep them as separate compilation units and let them evolve separately.

[b49020]

@ldts isn't code reuse the standard way how upstream drivers are written? These are exactly the same APIs used to fetch random numbers. Surely, they can differ on entropy estimates or certification which can be referenced.

Look for the Qcom RNG driver in the kernel: drivers/crypto/qcom-rng.c, all the Qcom chipsets use the same. I see no reason why OP-TEE should be special here.

[b49020]

It's all about maintenance and keeping code in good shape for all the targets.

[ldts]

@b49020 100% in favor of reuse in general terms. But this is a completely different IP block which as we go will probably cause us to use conditional compilation macros (maybe will need a udelay in the future, surely we will add the missing functionality and so on...and all for the sake of a loop that is simple and generic is my point (that is what I meant by silly, as in just a while loop)....IMO we should keep them separate (QRNG and PRNG even though they are initially sharing a while loop).

[b49020]

@ldts it's the same QRNG and PRNG in the Linux kernel too and they share the same qcom-rng.c driver. Why do we follow a different strategy in OP-TEE for the same IPs?

[ldts]

doesnt linux tries to ship one binary for many boards? op-tee does not therefore the split (which incidentally makes maintainance easier since a bug would not propagate).
plus anyway - at least IMO - the security boundary is better defined if we separate the rng driver from the crypto rng driver and let them evolve independently.
but if you feel strongly about it, sure merge them

[b49020]

doesnt linux tries to ship one binary for many boards? op-tee does not therefore the split (which incidentally makes maintainance easier since a bug would not propagate).

We need OP-TEE be more target independent with the migration towards DT.

plus anyway - at least IMO - the security boundary is better defined if we separate the rng driver from the crypto rng driver and let them evolve independently.

Having the common driver is better to catch any corner cases as it will be tested across targets.

[zelvam95]

doesnt linux tries to ship one binary for many boards? op-tee does not therefore the split (which incidentally makes maintainance easier since a bug would not propagate).

We need OP-TEE be more target independent with the migration towards DT.

plus anyway - at least IMO - the security boundary is better defined if we separate the rng driver from the crypto rng driver and let them evolve independently.

Having the common driver is better to catch any corner cases as it will be tested across targets.

Thanks Sumit/Jorge; For now, will go ahead with common driver and maybe in future if we have more use-cases added specific to PRNG / QRNG IP or if we in case need to do the init itself in OP-TEE for either of them, etc., we can probably think of separating them at that point (if/as required).

[zelvam95]

With above 2 comments addressed, you can post the PR to upstream OPTEE as well @thariaruchamy-bit. We can get further review comments from Sumit/Jorge/Upstream maintainers as part of the upstream review

[thariaruchamy-bit]

@zelvam95 Sure, have posted the changes in upstream optee master branch