kernel/include/soc/fsl/qman.h, branch 0x221E-v0.0.1-v6.19

soc: fsl_qbman: use be16_to_cpu() in qm_sg_entry_get_off()

2024-11-05T02:44:43Z

struct qm_sg_entry :: offset is a 13-bit field, declared as __be16. When using be32_to_cpu(), a wrong value will be calculated on little endian systems (Arm), because type promotion from 16-bit to 32-bit, which is done before the byte swap and always in the CPU native endianness, changes the value of the scatter/gather list entry offset in big-endian interpretation (adds two zero bytes in the LSB interpretation). The result of the byte swap is ANDed with GENMASK(12, 0), so the result is always zero, because only those bytes added by type promotion remain after the application of the bit mask. The impact of the bug is that scatter/gather frames with a non-zero offset into the buffer are treated by the driver as if they had a zero offset. This is all in theory, because in practice, qm_sg_entry_get_off() has a single caller, where the bug is inconsequential, because at that call site the buffer offset will always be zero, as will be explained in the subsequent change. Flagged by sparse: warning: cast to restricted __be32 warning: cast from restricted __be16 Signed-off-by: Vladimir Oltean Reviewed-by: Breno Leitao Acked-by: Christophe Leroy Acked-by: Madalin Bucur Link: https://patch.msgid.link/20241029164317.50182-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski

soc: fsl: qbman: Add CGR update function

2022-09-05T13:27:39Z

This adds a function to update a CGR with new parameters. qman_create_cgr can almost be used for this (with flags=0), but it's not suitable because it also registers the callback function. The _safe variant was modeled off of qman_cgr_delete_safe. However, we handle multiple arguments and a return value. Signed-off-by: Sean Anderson Acked-by: Camelia Groza Signed-off-by: David S. Miller

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

2020-11-04T01:41:03Z

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

soc: fsl: qman: fix -Wpacked-not-aligned warnings

2020-09-22T22:38:21Z

This fixes compile warnings from the -Wpacked-not-aligned option. In file included from ../drivers/crypto/caam/qi.c:12: ../include/soc/fsl/qman.h:259:1: warning: alignment 1 of ‘struct qm_dqrr_entry’ is less than 8 [-Wpacked-not-aligned] } __packed; ^ ../include/soc/fsl/qman.h:292:2: warning: alignment 1 of ‘struct ’ is less than 8 [-Wpacked-not-aligned] } __packed ern; ^ Reported-by: Herbert Xu Signed-off-by: Li Yang

dpaa_eth: register a device link for the qman portal used

2019-10-31T19:13:34Z

Before this change, unbinding the QMan portals did not trigger a corresponding unbinding of the dpaa_eth making use of it; the first QMan portal related operation issued afterwards crashed the kernel. The device link ensures the dpaa_eth dependency upon the qman portal used is honoured at the QMan portal removal. Signed-off-by: Madalin Bucur Signed-off-by: David S. Miller

soc: fsl: qbman: allow registering a device link for the portal user

2019-10-31T19:13:34Z

Introduce the API required to make sure that the devices that use the QMan portal are unbound when the portal is unbound. Signed-off-by: Madalin Bucur Signed-off-by: David S. Miller

soc: fsl: qbman_portals: add APIs to retrieve the probing status

2019-05-20T19:28:16Z

Add a couple of new APIs to check the probing status of the required cpu bound qman and bman portals: 'int bman_portals_probed()' and 'int qman_portals_probed()'. They return the following values. * 1 if qman/bman portals were all probed correctly * 0 if qman/bman portals were not yet probed * -1 if probing of qman/bman portals failed Portals are considered successful probed if no error occurred during the probing of any of the portals and if enough portals were probed to have one available for each cpu. The error handling paths were slightly rearranged in order to fit this new functionality without being too intrusive. Drivers that use qman/bman portal driver services are required to use these APIs before calling any functions exported by these drivers or otherwise they will crash the kernel. First user will be the dpaa1 ethernet driver, coming in a subsequent patch. Signed-off-by: Laurentiu Tudor Signed-off-by: Li Yang

soc/qman: add return value to interrupt coalesce changing APIs

2018-11-23T19:17:06Z

Check that the values received by the portal interrupt coalesce change APIs are in range. Signed-off-by: Madalin Bucur Signed-off-by: Roy Pledge Signed-off-by: David S. Miller

soc: fsl: qbman: add interrupt coalesce changing APIs

2018-10-05T19:06:56Z

Add the APIs required to control the QMan portal interrupt coalescing settings. Signed-off-by: Madalin Bucur Signed-off-by: Li Yang

soc: fsl: qbman: add APIs to retrieve the probing status

2018-09-27T20:43:35Z

Add a couple of new APIs to check the probing status of qman and bman: 'int bman_is_probed()' and 'int qman_is_probed()'. They return the following values. * 1 if qman/bman were probed correctly * 0 if qman/bman were not yet probed * -1 if probing of qman/bman failed Drivers that use qman/bman driver services are required to use these APIs before calling any functions exported by qman or bman drivers or otherwise they will crash the kernel. The APIs will be used in the following couple of qbman portal patches and later in the series in the dpaa1 ethernet driver. Signed-off-by: Laurentiu Tudor Signed-off-by: Li Yang