linux-toradex.git/include/soc/fsl, branch v6.0-rc1

crypto: caam - add in-kernel interface for blob generator

2022-05-23T15:47:50+00:00

The NXP Cryptographic Acceleration and Assurance Module (CAAM)
can be used to protect user-defined data across system reboot:

  - When the system is fused and boots into secure state, the master
    key is a unique never-disclosed device-specific key
  - random key is encrypted by key derived from master key
  - data is encrypted using the random key
  - encrypted data and its encrypted random key are stored alongside
  - This blob can now be safely stored in non-volatile memory

On next power-on:
  - blob is loaded into CAAM
  - CAAM writes decrypted data either into memory or key register

Add functions to realize encrypting and decrypting into memory alongside
the CAAM driver.

They will be used in a later commit as a source for the trusted key
seal/unseal mechanism.

Reviewed-by: David Gstir 
Reviewed-by: Pankaj Gupta 
Tested-by: Tim Harvey 
Tested-by: Matthias Schiffer 
Tested-by: Pankaj Gupta 
Tested-by: Michael Walle  # on ls1028a (non-E and E)
Tested-by: John Ernberg  # iMX8QXP
Signed-off-by: Steffen Trumtrar 
Signed-off-by: Ahmad Fatoum 
Signed-off-by: Jarkko Sakkinen

soc: fsl: Replace kernel.h with the necessary inclusions

2022-02-18T23:11:17+00:00

When kernel.h is used in the headers it adds a lot into dependency hell,
especially when there are circular dependencies are involved.

Replace kernel.h inclusion with the list of what is really being used.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Li Yang

soc: fsl: dpio: add Net DIM integration

2021-10-15T13:32:41+00:00

Use the generic dynamic interrupt moderation (dim) framework to
implement adaptive interrupt coalescing on Rx. With the per-packet
interrupt scheme, a high interrupt rate has been noted for moderate
traffic flows leading to high CPU utilization.

The dpio driver exports new functions to enable/disable adaptive IRQ
coalescing on a DPIO object, to query the state or to update Net DIM
with a new set of bytes and frames dequeued.

Signed-off-by: Ioana Ciornei 
Signed-off-by: David S. Miller

soc: fsl: dpio: add support for irq coalescing per software portal

2021-10-15T13:32:40+00:00

In DPAA2 based SoCs, the IRQ coalesing support per software portal has 2
configurable parameters:
 - the IRQ timeout period (QBMAN_CINH_SWP_ITPR): how many 256 QBMAN
   cycles need to pass until a dequeue interrupt is asserted.
 - the IRQ threshold (QBMAN_CINH_SWP_DQRR_ITR): how many dequeue
   responses in the DQRR ring would generate an IRQ.

Add support for setting up and querying these IRQ coalescing related
parameters.

Signed-off-by: Ioana Ciornei 
Signed-off-by: David S. Miller

soc: fsl: dpio: extract the QBMAN clock frequency from the attributes

2021-10-15T13:32:40+00:00

Through the dpio_get_attributes() firmware call the dpio driver has
access to the QBMAN clock frequency. Extend the structure which holds
the firmware's response so that we can have access to this information.

This will be needed in the next patches which also add support for
interrupt coalescing which needs to be configured based on the
frequency.

Signed-off-by: Ioana Ciornei 
Signed-off-by: David S. Miller

Revert "soc: fsl: qe: introduce qe_io{read,write}* wrappers"

2021-04-06T20:40:48+00:00

This reverts commit 6ac9b61786cc64ae5cbfb69413137656f72e8204.

This commit was required because at that time, ioread/iowrite
functions were sub-optimal on powerpc/32 compared to the
architecture specific in_/out_ IO accessors.

But there are now equivalent since
commit 894fa235eb4c ("powerpc: inline iomap accessors").

Signed-off-by: Christophe Leroy 
Signed-off-by: Li Yang

ethernet: ucc_geth: remove bd_mem_part and all associated code

2021-01-21T20:19:56+00:00

The bd_mem_part member of ucc_geth_info always has the value
MEM_PART_SYSTEM, and AFAICT, there has never been any code setting it
to any other value. Moreover, muram is a somewhat precious resource,
so there's no point using that when normal memory serves just as well.

Apart from removing a lot of dead code, this is also motivated by
wanting to clean up the "store result from kmalloc() in a u32" mess.

Signed-off-by: Rasmus Villemoes 
Signed-off-by: Jakub Kicinski

soc: fsl: qe: add cpm_muram_free_addr() helper

2021-01-21T20:19:55+00:00

Add a helper that takes a virtual address rather than the muram
offset. This will be used in a couple of places to avoid having to
store both the offset and the virtual address, as well as removing
NULL checks from the callers.

Signed-off-by: Rasmus Villemoes 
Acked-by: Li Yang 
Signed-off-by: Jakub Kicinski

soc: fsl: qe: make cpm_muram_offset take a const void* argument

2021-01-21T20:19:55+00:00

Allow passing const-qualified pointers without requiring a cast in the
caller.

Signed-off-by: Rasmus Villemoes 
Acked-by: Li Yang 
Signed-off-by: Jakub Kicinski

soc/fsl/qbman: Add an argument to signal if NAPI processing is required.

2020-11-04T01:41:03+00:00

dpaa_eth_napi_schedule() and caam_qi_napi_schedule() schedule NAPI if
invoked from:

 - Hard interrupt context
 - Any context which is not serving soft interrupts

Any context which is not serving soft interrupts includes hard interrupts
so the in_irq() check is redundant. caam_qi_napi_schedule() has a comment
about this:

        /*
         * In case of threaded ISR, for RT kernels in_irq() does not return
         * appropriate value, so use in_serving_softirq to distinguish between
         * softirq and irq contexts.
         */
         if (in_irq() || !in_serving_softirq())

This has nothing to do with RT. Even on a non RT kernel force threaded
interrupts run obviously in thread context and therefore in_irq() returns
false when invoked from the handler.

The extension of the in_irq() check with !in_serving_softirq() was there
when the drivers were added, but in the out of tree FSL BSP the original
condition was in_irq() which got extended due to failures on RT.

The usage of in_xxx() in drivers is phased out and Linus clearly requested
that code which changes behaviour depending on context should either be
separated or the context be conveyed in an argument passed by the caller,
which usually knows the context. Right he is, the above construct is
clearly showing why.

The following callchains have been analyzed to end up in
dpaa_eth_napi_schedule():

qman_p_poll_dqrr()
  __poll_portal_fast()
    fq->cb.dqrr()
       dpaa_eth_napi_schedule()

portal_isr()
  __poll_portal_fast()
    fq->cb.dqrr()
       dpaa_eth_napi_schedule()

Both need to schedule NAPI.
The crypto part has another code path leading up to this:
  kill_fq()
     empty_retired_fq()
       qman_p_poll_dqrr()
         __poll_portal_fast()
            fq->cb.dqrr()
               dpaa_eth_napi_schedule()

kill_fq() is called from task context and ends up scheduling NAPI, but
that's pointless and an unintended side effect of the !in_serving_softirq()
check.

The code path:
  caam_qi_poll() -> qman_p_poll_dqrr()

is invoked from NAPI and I *assume* from crypto's NAPI device and not
from qbman's NAPI device. I *guess* it is okay to skip scheduling NAPI
(because this is what happens now) but could be changed if it is wrong
due to `budget' handling.

Add an argument to __poll_portal_fast() which is true if NAPI needs to be
scheduled. This requires propagating the value to the caller including
`qman_cb_dqrr' typedef which is used by the dpaa and the crypto driver.

Signed-off-by: Sebastian Andrzej Siewior 
Cc: Aymen Sghaier 
Cc: Herbert XS 
Cc: Li Yang 
Reviewed-by: Horia Geantă 
Signed-off-by: Jakub Kicinski 
Reviewed-by: Madalin Bucur 
Tested-by: Camelia Groza