* Re: [PATCH v2 1/2] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Bradley Morgan @ 2026-06-23 18:51 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, kvmarm, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <86pl1hqiwj.wl-maz@kernel.org>
On June 23, 2026 6:13:48 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
>On Tue, 23 Jun 2026 18:04:07 +0100,
>Bradley Morgan <include@grrlz.net> wrote:
>>
>> I'll go and do V3 with another sashiko suggestion. I'll fix your path
>too.
>
>Before you do that, please verify that whatever Sashiko spits out
>makes any sense. I'm not convinced by its reply on v1 at all.
>
> M.
>
>
Marc,
hi, I have verified sashikos concern.
I am out right now. So I will give a very short result.
Sashiko is being bit dramatic with the whole "Critical" rating, but it
is real in another way
I'll explain it in the code in about 30-40 mins.
Thanks!
^ permalink raw reply
* Re: [PATCH v2 05/12] nvmem: microchip-otpc: add tag-based packet lookup
From: Andy Shevchenko @ 2026-06-23 18:31 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623105944.128840-6-varshini.rajendran@microchip.com>
On Tue, Jun 23, 2026 at 04:29:37PM +0530, Varshini Rajendran wrote:
> Add support for accessing OTP packets by their 4-byte ASCII tag while
> preserving backward compatibility with the existing ID-based lookup.
>
> The OTP memory layout can vary across devices and may change over time,
> making the packet ID approach unreliable when the memory map is not
> known in advance. The packet tag provides a reliable way to identify
> and access packets without prior knowledge of the OTP memory layout.
>
> Two offset encoding are now supported:
> 1. Legacy ID-based: offset = OTP_PKT(id) = id * 4
> Used in DT as: reg = <OTP_PKT(1) 76>;
> 2. TAG-based: offset = 4-byte ASCII packet tag
> Used in DT as: reg = <0x41435354 0x4c>; (tag "ACST")
>
> The driver resolves offsets matching valid legacy selectors (multiples
> of 4 within the packet count) through ID lookup, falling back to tag
> lookup for other values. This ensures existing device trees continue
> to work while enabling new tag-based access.
>
> During probe, packet meta data including the tag is read and cached.
> The driver also validates OTP memory accessibility and emulation mode
> status. When the boot packet is not configured, emulation mode allows
> access to the other packets. When both are not available an
> informational message is logged.
>
> The stride of the nvmem memory is set to 1 in order to support tag based
> offsets, comment in the header file is updated accordingly.
...
> #define MCHP_OTPC_SIZE (11 * 1024)
Side note: At some point maybe (11 * SZ_1K) with help of sizes.h?
...
> +/**
> + * mchp_otpc_resolve_packet() - resolve offset to packet
> + * @otpc: OTPC private data
> + * @off: NVMEM offset (legacy ID-based or TAG-based)
> + *
> + * Legacy offsets (multiples of 4 within valid ID range) are resolved
> + * through ID lookup. Other offsets are treated as 4-byte ASCII tags.
> + *
> + * Return: pointer to packet if found, NULL otherwise
> + */
> +static struct mchp_otpc_packet *mchp_otpc_resolve_packet(struct mchp_otpc *otpc,
> + u32 off)
> +{
> + /*
> + * Legacy id based packet access: offset = id * 4
> + * Inside the driver we use continuous unsigned integer numbers
> + * for packet id, thus divide off by 4 before passing it to
> + * mchp_otpc_id_to_packet().
> + */
> +
> + if (!(off % 4) && (off / 4) < otpc->npackets)
> + return mchp_otpc_id_to_packet(otpc, off / 4);
Hmm... I was thinking about something like temporary variables for these two.
Note, in some cases the compiler may issue a single instruction when it sees
both together. That's why in many GPIO drivers we use something like
unsigned int offset = foo / 8;
unsigned int shift = foo % 8;
or similar.
> + /*
> + * TAG-based packet access: offset is a 4-byte ASCII tag
> + */
> + return mchp_otpc_tag_to_packet(otpc, off);
> +}
...
> {
> struct nvmem_device *nvmem;
> struct mchp_otpc *otpc;
> - u32 size;
> + u32 size, tmp;
> int ret;
> + bool emul_enable;
Perhaps keep the reversed xmas tree order?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 03/12] iio: adc: at91-sama5d2_adc: adapt the driver for sama7d65
From: Andy Shevchenko @ 2026-06-23 18:22 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623105944.128840-4-varshini.rajendran@microchip.com>
On Tue, Jun 23, 2026 at 04:29:35PM +0530, Varshini Rajendran wrote:
> Add support for sama7d65 ADC. The differences are highlighted with the
> compatible. The calibration data layout is the main difference.
Do you need to update a Kconfig help text?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 02/12] iio: adc: at91-sama5d2_adc: rework temp calibration layout handling
From: Andy Shevchenko @ 2026-06-23 18:15 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623105944.128840-3-varshini.rajendran@microchip.com>
On Tue, Jun 23, 2026 at 04:29:34PM +0530, Varshini Rajendran wrote:
> Extend support to handle different temperature calibration layouts.
>
> Add a temperature calibration data layout structure to describe indexes
> of the factors P1, P4, P6, tag, minimum length of the packet and the
> scaling factors for P1 (mul, div) which are SoC-specific instead of the
> older non scalable id structure. This helps handle the differences in the
> same function flow and prepare the calibration data to be applied. Add
> additional condition to validate the calibration data read from the
> NVMEM cell using the TAG of the packet.
>
> Use cleanup helpers for NVMEM data buffer wherever applicable.
> +#define AT91_TEMP_CALIB_TAG_ACST 0x41435354
This seems like FourCC that can be represented in ASCII (I suppose "ACST").
Can you add a short comment on top to decode that?
/* ...blablabla... in ASCII "ACST" */
...
> struct at91_adc_platform {
> const struct at91_adc_reg_layout *layout;
> @@ -481,6 +504,7 @@ struct at91_adc_platform {
> unsigned int chan_realbits;
> unsigned int temp_chan;
> bool temp_sensor;
> + const struct at91_adc_temp_calib_layout *temp_calib_layout;
> };
Is this the best placement in accordance with `pahole` tool?
...
> - u32 *buf;
> + u32 *buf __free(kfree) = NULL;
This looks like a separate change. Why is it in this patch?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 6/8] iommu/qcom: Add NULL ctx check in TLB invalidation paths
From: Robin Murphy @ 2026-06-23 17:08 UTC (permalink / raw)
To: Mukesh Ojha, Rob Clark, Will Deacon, Joerg Roedel (AMD)
Cc: iommu, linux-arm-msm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623122034.1166295-7-mukesh.ojha@oss.qualcomm.com>
On 23/06/2026 1:20 pm, Mukesh Ojha wrote:
> to_ctx() returns qcom_iommu->ctxs[asid], which can be NULL if the
> corresponding context bank failed to probe or was already removed.
> qcom_iommu_tlb_sync(), qcom_iommu_tlb_inv_context(), and
> qcom_iommu_tlb_inv_range_nosync() all dereference the returned pointer
> directly, risking a NULL pointer dereference.
But if there's no context bank, then how has a domain been allocated in
order to permit io-pgtable operations that would eventually call into
qcom_flush_ops at all? Can you please clarify whether you've actually
observed a real-world issue here, and if so how?
Thanks,
Robin.
> Add WARN_ON(!ctx) guards with continue so TLB operations skip
> broken context banks without crashing.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/iommu/arm/arm-smmu/qcom_iommu.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> index 40fb0408dc07..51b60b296bb8 100644
> --- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> @@ -121,6 +121,9 @@ static void qcom_iommu_tlb_sync(void *cookie)
> struct qcom_iommu_ctx *ctx = to_ctx(qcom_domain, fwspec->ids[i]);
> unsigned int val, ret;
>
> + if (WARN_ON(!ctx))
> + continue;
> +
> iommu_writel(ctx, ARM_SMMU_CB_TLBSYNC, 0);
>
> ret = readl_poll_timeout(ctx->base + ARM_SMMU_CB_TLBSTATUS, val,
> @@ -138,6 +141,10 @@ static void qcom_iommu_tlb_inv_context(void *cookie)
>
> for (i = 0; i < fwspec->num_ids; i++) {
> struct qcom_iommu_ctx *ctx = to_ctx(qcom_domain, fwspec->ids[i]);
> +
> + if (WARN_ON(!ctx))
> + continue;
> +
> iommu_writel(ctx, ARM_SMMU_CB_S1_TLBIASID, ctx->asid);
> }
>
> @@ -157,6 +164,9 @@ static void qcom_iommu_tlb_inv_range_nosync(unsigned long iova, size_t size,
> struct qcom_iommu_ctx *ctx = to_ctx(qcom_domain, fwspec->ids[i]);
> size_t s = size;
>
> + if (WARN_ON(!ctx))
> + continue;
> +
> iova = (iova >> 12) << 12;
> iova |= ctx->asid;
> do {
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Diederik de Haas @ 2026-06-23 17:42 UTC (permalink / raw)
To: Daniele Briguglio, Diederik de Haas, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <20260623140958.4181297-1-hello@superkali.me>
Hi,
On Tue Jun 23, 2026 at 4:10 PM CEST, Daniele Briguglio wrote:
>> So IIUC that means I'd be testing both variants.
>
> Right, that covers both: the mux path and the consumer path. Looking
> forward to the results.
Analog audio works on both. Plus with _TO_IO and LTS without in their
respective DTS's. So I guess CLK_IGNORE_UNUSED works.
Whether it's a good/right fix, I'll leave up to others.
Cheers,
Diederik
^ permalink raw reply
* Re: [PATCH v2 04/12] dt-bindings: nvmem: microchip,sama7g5-otpc: add sama7d65 and dt node example
From: Conor Dooley @ 2026-06-23 17:28 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623105944.128840-5-varshini.rajendran@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]
On Tue, Jun 23, 2026 at 04:29:36PM +0530, Varshini Rajendran wrote:
> Add support for sama7d65 and a dt node example that shows tag can be used
> to reference a packet stored in the OTP memory.
>
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> ---
> .../nvmem/microchip,sama7g5-otpc.yaml | 28 +++++++++++++++++--
> 1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
> index cc25f2927682..3cc16b0044a6 100644
> --- a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
> @@ -20,9 +20,15 @@ allOf:
>
> properties:
> compatible:
> - items:
> - - const: microchip,sama7g5-otpc
> - - const: syscon
> + oneOf:
> + - items:
> + - const: microchip,sama7g5-otpc
> + - const: syscon
> + - items:
> + - enum:
> + - microchip,sama7d65-otpc
> + - const: microchip,sama7g5-otpc
> + - const: syscon
>
> reg:
> maxItems: 1
> @@ -48,4 +54,20 @@ examples:
> };
> };
>
> + - |
> + otp_controller: efuse@e8c00000 {
Drop the unused label since you have to respin the series.
With it gone
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
Cheers,
Conor.
> + compatible = "microchip,sama7d65-otpc", "microchip,sama7g5-otpc", "syscon";
> + reg = <0xe8c00000 0x100>;
> +
> + nvmem-layout {
> + compatible = "fixed-layout";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + temp_calib: calib@41435354 {
> + reg = <0x41435354 0x2c>; /* Temp calib data packet TAG */
> + };
> + };
> + };
> +
> ...
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/12] dt-bindings: iio: adc: at91-sama5d2: document sama7d65
From: Conor Dooley @ 2026-06-23 17:26 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260623105944.128840-2-varshini.rajendran@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
On Tue, Jun 23, 2026 at 04:29:33PM +0530, Varshini Rajendran wrote:
> Add dt-binding documentation for sama7d65 ADC.
Commit message is missing an explanation of why a fallback is not
suitable.
pw-bot: changes-requested
Thanks,
Conor
>
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
> index 4817b840977a..e8a65fdcd018 100644
> --- a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
> @@ -15,6 +15,7 @@ properties:
> - atmel,sama5d2-adc
> - microchip,sam9x60-adc
> - microchip,sama7g5-adc
> + - microchip,sama7d65-adc
>
> reg:
> maxItems: 1
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] remoteproc: xlnx: refactor start & stop ops
From: Mathieu Poirier @ 2026-06-23 17:21 UTC (permalink / raw)
To: Tanmay Shah
Cc: michal.simek, andersson, linux-arm-kernel, linux-kernel,
linux-remoteproc
In-Reply-To: <20260619163854.410392-1-tanmay.shah@amd.com>
On Fri, Jun 19, 2026 at 09:38:54AM -0700, Tanmay Shah wrote:
> Current _start and _stop ops are implemented using various APIs from the
> platform management firmware driver. Instead provide respective RPU
> start and stop API in the firmware driver and move the logic to interact
> with the PM firmware in the firmware driver. The remoteproc driver doesn't
> need to know actual logic, but only the final result i.e. RPU start/stop
> was success or not. This refactor keeps the remoteproc driver simple and
> moves firmware interaction logic to the firmware driver.
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> drivers/firmware/xilinx/zynqmp.c | 93 +++++++++++++++++++++++++
> drivers/remoteproc/xlnx_r5_remoteproc.c | 68 ++----------------
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> include/linux/firmware/xlnx-zynqmp.h | 12 ++++
> 3 files changed, 110 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index af838b2dc327..f9a3a95b0638 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -1513,6 +1513,99 @@ int zynqmp_pm_request_wake(const u32 node,
> }
> EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
>
> +/**
> + * zynqmp_pm_start_rpu - Boot Real-time Processing Unit (Cortex-R) on SoC
> + *
> + * @node: power-domains id of the core
> + * @bootaddr: Boot address of elf
> + *
> + * Return: status, either success or error+reason
> + */
> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
> +{
> + enum rpu_boot_mem bootmem;
> + int ret;
> +
> + /*
> + * The exception vector pointers (EVP) refer to the base-address of
> + * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
> + * starts at the base-address and subsequent vectors are on 4-byte
> + * boundaries.
> + *
> + * Exception vectors can start either from 0x0000_0000 (LOVEC) or
> + * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
> + *
> + * Usually firmware will put Exception vectors at LOVEC.
> + *
> + * It is not recommend that you change the exception vector.
> + * Changing the EVP to HIVEC will result in increased interrupt latency
> + * and jitter. Also, if the OCM is secured and the Cortex-R5F processor
> + * is non-secured, then the Cortex-R5F processor cannot access the
> + * HIVEC exception vectors in the OCM.
> + */
> + bootmem = (bootaddr >= 0xFFFC0000) ?
> + PM_RPU_BOOTMEM_HIVEC : PM_RPU_BOOTMEM_LOVEC;
> +
> + pr_debug("RPU boot addr 0x%llx from %s.", bootaddr,
> + bootmem == PM_RPU_BOOTMEM_HIVEC ? "OCM" : "TCM");
> +
> + /* Request node before starting RPU core if new version of API is supported */
> + if (zynqmp_pm_feature(PM_REQUEST_NODE) > PM_API_VERSION_1) {
> + ret = zynqmp_pm_request_node(node,
> + ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> + ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + if (ret < 0) {
> + pr_err("failed to request 0x%x", node);
> + return ret;
> + }
> + }
> +
> + ret = zynqmp_pm_request_wake(node, true,
> + bootmem, ZYNQMP_PM_REQUEST_ACK_NO);
> + if (ret)
> + pr_err("failed to start RPU = 0x%x\n", node);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_start_rpu);
> +
> +/**
> + * zynqmp_pm_stop_rpu - Stop Real-time Processing Unit (Cortex-R) on SoC
> + *
> + * @node: power-domains id of the core
> + *
> + * Return: status, either success or error+reason
> + */
> +int zynqmp_pm_stop_rpu(const u32 node)
> +{
> + int ret;
> +
> + /* Use release node API to stop core if new version of API is supported */
> + if (zynqmp_pm_feature(PM_RELEASE_NODE) > PM_API_VERSION_1) {
> + ret = zynqmp_pm_release_node(node);
> + if (ret)
> + pr_err("failed to stop remoteproc RPU %d\n", ret);
> + return ret;
> + }
> +
> + /*
> + * Check expected version of EEMI call before calling it. This avoids
> + * any error or warning prints from firmware as it is expected that fw
> + * doesn't support it.
> + */
> + if (zynqmp_pm_feature(PM_FORCE_POWERDOWN) != PM_API_VERSION_1) {
> + pr_debug("EEMI interface %d ver 1 not supported\n",
> + PM_FORCE_POWERDOWN);
> + return -EOPNOTSUPP;
> + }
> +
> + /* maintain force pwr down for backward compatibility */
> + ret = zynqmp_pm_force_pwrdwn(node, ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + if (ret)
> + pr_err("core force power down failed\n");
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_stop_rpu);
> +
> /**
> * zynqmp_pm_set_requirement() - PM call to set requirement for PM slaves
> * @node: Node ID of the slave
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 3349d1877751..dcd8a93f031c 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -364,49 +364,12 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
> static int zynqmp_r5_rproc_start(struct rproc *rproc)
> {
> struct zynqmp_r5_core *r5_core = rproc->priv;
> - enum rpu_boot_mem bootmem;
> int ret;
>
> - /*
> - * The exception vector pointers (EVP) refer to the base-address of
> - * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
> - * starts at the base-address and subsequent vectors are on 4-byte
> - * boundaries.
> - *
> - * Exception vectors can start either from 0x0000_0000 (LOVEC) or
> - * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
> - *
> - * Usually firmware will put Exception vectors at LOVEC.
> - *
> - * It is not recommend that you change the exception vector.
> - * Changing the EVP to HIVEC will result in increased interrupt latency
> - * and jitter. Also, if the OCM is secured and the Cortex-R5F processor
> - * is non-secured, then the Cortex-R5F processor cannot access the
> - * HIVEC exception vectors in the OCM.
> - */
> - bootmem = (rproc->bootaddr >= 0xFFFC0000) ?
> - PM_RPU_BOOTMEM_HIVEC : PM_RPU_BOOTMEM_LOVEC;
> -
> - dev_dbg(r5_core->dev, "RPU boot addr 0x%llx from %s.", rproc->bootaddr,
> - bootmem == PM_RPU_BOOTMEM_HIVEC ? "OCM" : "TCM");
> -
> - /* Request node before starting RPU core if new version of API is supported */
> - if (zynqmp_pm_feature(PM_REQUEST_NODE) > 1) {
> - ret = zynqmp_pm_request_node(r5_core->pm_domain_id,
> - ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> - ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> - if (ret < 0) {
> - dev_err(r5_core->dev, "failed to request 0x%x",
> - r5_core->pm_domain_id);
> - return ret;
> - }
> - }
> -
> - ret = zynqmp_pm_request_wake(r5_core->pm_domain_id, 1,
> - bootmem, ZYNQMP_PM_REQUEST_ACK_NO);
> + ret = zynqmp_pm_start_rpu(r5_core->pm_domain_id, rproc->bootaddr);
> if (ret)
> - dev_err(r5_core->dev,
> - "failed to start RPU = 0x%x\n", r5_core->pm_domain_id);
> + dev_err(&rproc->dev, "failed to start RPU\n");
> +
> return ret;
> }
>
> @@ -423,30 +386,9 @@ static int zynqmp_r5_rproc_stop(struct rproc *rproc)
> struct zynqmp_r5_core *r5_core = rproc->priv;
> int ret;
>
> - /* Use release node API to stop core if new version of API is supported */
> - if (zynqmp_pm_feature(PM_RELEASE_NODE) > 1) {
> - ret = zynqmp_pm_release_node(r5_core->pm_domain_id);
> - if (ret)
> - dev_err(r5_core->dev, "failed to stop remoteproc RPU %d\n", ret);
> - return ret;
> - }
> -
> - /*
> - * Check expected version of EEMI call before calling it. This avoids
> - * any error or warning prints from firmware as it is expected that fw
> - * doesn't support it.
> - */
> - if (zynqmp_pm_feature(PM_FORCE_POWERDOWN) != 1) {
> - dev_dbg(r5_core->dev, "EEMI interface %d ver 1 not supported\n",
> - PM_FORCE_POWERDOWN);
> - return -EOPNOTSUPP;
> - }
> -
> - /* maintain force pwr down for backward compatibility */
> - ret = zynqmp_pm_force_pwrdwn(r5_core->pm_domain_id,
> - ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + ret = zynqmp_pm_stop_rpu(r5_core->pm_domain_id);
> if (ret)
> - dev_err(r5_core->dev, "core force power down failed\n");
> + dev_err(&rproc->dev, "failed to stop RPU\n");
>
> return ret;
> }
> diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
> index 7e27b0f7bf7e..347df66ee176 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -644,6 +644,8 @@ int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
> u32 *const requirements, u32 *const usage);
> int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
> u32 *const requirements, u32 *const usage);
> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr);
> +int zynqmp_pm_stop_rpu(const u32 node);
> int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value);
> int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
> u32 value);
> @@ -960,6 +962,16 @@ static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const statu
> return -ENODEV;
> }
>
> +static inline int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int zynqmp_pm_stop_rpu(const u32 node)
> +{
> + return -ENODEV;
> +}
> +
> static inline int zynqmp_pm_set_sd_config(u32 node,
> enum pm_sd_config_type config,
> u32 value)
>
> base-commit: 721396afea31eac476d88f5db10ba111ba4b8382
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 1/2] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Marc Zyngier @ 2026-06-23 17:13 UTC (permalink / raw)
To: Bradley Morgan
Cc: Oliver Upton, kvmarm, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <5925B41F-0F57-4BCB-9F93-7600878ECA27@grrlz.net>
On Tue, 23 Jun 2026 18:04:07 +0100,
Bradley Morgan <include@grrlz.net> wrote:
>
> I'll go and do V3 with another sashiko suggestion. I'll fix your path too.
Before you do that, please verify that whatever Sashiko spits out
makes any sense. I'm not convinced by its reply on v1 at all.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Catalin Marinas @ 2026-06-23 17:11 UTC (permalink / raw)
To: Dev Jain
Cc: Harry Yoo, ryabinin.a.a, akpm, corbet, glider, andreyknvl,
dvyukov, vincenzo.frascino, kasan-dev, linux-mm, linux-kernel,
skhan, workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <78d97371-b477-4230-8690-ac870a7bab3b@arm.com>
On Tue, Jun 23, 2026 at 10:32:16AM +0530, Dev Jain wrote:
> On 22/06/26 10:43 pm, Catalin Marinas wrote:
> > On Mon, Jun 22, 2026 at 09:42:10PM +0900, Harry Yoo wrote:
> >> On 6/19/26 10:19 PM, Catalin Marinas wrote:
> >>> On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
> >>>> On 6/12/26 1:44 PM, Dev Jain wrote:
> >>>>> Now, when a memory object will be freed, it will retain the random tag it
> >>>>> had at allocation time. This compromises on catching UAF bugs, till the
> >>>>> time the object is not reallocated, at which point it will have a new
> >>>>> random tag.
> >>>>>
> >>>>> Hence, not catching "use-after-free-before-reallocation" and not catching
> >>>>> "double-free" will be the compromise for reduced KASAN overhead.
> >>>>
> >>>> I doubt users who care about security enough to enable HW_TAGS KASAN
> >>>> are willing to compromise on security just to save a few instructions
> >>>> to store tags in the free path.
> >>>>
> >>>> To me, it looks like too much of a compromise on security for little
> >>>> performance gain.
> >>>
> >>> I don't think there's much compromise on security for use-after-free.
> >>
> >> I think it depends... OH, WAIT! I see what you mean.
> >>
> >> You mean use-after-free before reallocation does not lead to much
> >> compromise on security because objects are initialized after allocation?
> >>
> >> You're probably right.
> >>
> >> Hmm, but stores to e.g.) free pointer, fields initialized by
> >> constructor or accessed by SLAB_TYPESAFE_BY_RCU semantics after free
> >> will be undiscovered if they happen before reallocation.
> >
> > Even with SLAB_TYPESAFE_BY_RCU, the object isn't tagged on free either
> > (or realloc, only if the actual slab page ends up freed). But we don't
> > get type confusion for such slab.
> >
> > However, without tagging on free, one could argue that it reduces
> > security for cases where the page is re-allocated as untagged - e.g. all
> > user pages mapped without PROT_MTE. Currently we have a deterministic
> > tag check fault if the page is coloured as KASAN_TAG_INVALID. I think
>
> So you are saying that a stale kernel pointer can continue to use the
> reallocated page, because for non-PROT_MTE case the page does not get
> a new tag. Makes sense.
Yes.
> > for this patch, it might be better to only do such skip on free in
> > kasan_poison_slab() rather than kasan_poison(). Freed pages would then
> > be tagged.
>
> I think you mean to say, "skip tag on free when freeing pages into buddy"?
No, I meant always poison via kasan_poison_pages(), as we currently do
with KASAN_PAGE_FREE being set.
> So that would mean, kasan_poison() will do the poisoning also in the
> case of value == KASAN_PAGE_FREE.
>
> > An alternative would be tagging on free only with a new tag and skipping
> > it on re-alloc. But we'd need to track when it's a completely new
> > allocation or a reused object (I haven't looked I'm pretty sure it's
> > doable).
>
> That was our original approach, and IIRC we had concluded there was no
> security compromise. However it is difficult to implement - it has cases
> like, what happens when two differently tagged pages are coalesced by
> buddy and someone gets that large page as an allocation.
Yeah, it's fairly complex.
I think the more problematic case is when we can't detect
use-after-reallocation and this happens when a page is reused untagged
(probabilistically, also when the page is reused with the old tag). As
an optimisation, it might be sufficient to skip poisoning when freeing
an object into the slab but keep the poisoning when freeing a slab page
into the buddy allocator. That's where the page may end up in a place
untagged.
Also for your optimisation to only tag on reallocation, do you have any
code to read the current tag and avoid reusing it? That's useful for
kmalloc caches or other merged kmem caches where we can have type
confusion.
--
Catalin
^ permalink raw reply
* Re: [PATCH v2 1/2] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Bradley Morgan @ 2026-06-23 17:04 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, kvmarm, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <86qzlxqjf3.wl-maz@kernel.org>
On June 23, 2026 6:02:40 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
>Bradley,
>
>Just a few things to keep in mind for your next contributions:
>
>- If you are sending more than a single patch, add a cover letter.
>
>- Don't send a v2 in reply to a v1. It messes the threading we are
> relying on, and makes it hard to ignore replies to an older version.
> Always send new series standalone.
>
>- Don't immediately send a V2, even if (especially if!) a bot is
> pestering you. 34 minutes between versions is way too short (at
> least a few days is the norm).
>
>On Tue, 23 Jun 2026 17:37:55 +0100,
>Bradley Morgan <include@grrlz.net> wrote:
>>
>> pKVM keeps its own mapping list for stage 2 operations. Its flush path
>> uses that list directly, so it lost the PTE attribute check done by the
>> generic stage 2 walker.
>>
>> Record whether a mapping is cacheable and skip cache maintenance for
>> mappings that are not cacheable.
>>
>> Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
>> Cc: stable@vger.kernel.org
>
>What device memory gets mapped in an upstream pKVM guest that would
>require a backport to stable?
>
>> Signed-off-by: Bradley Morgan <include@grrlz.net>
>> ---
>> Changes in v2:
>> - Add patch 2 for the pKVM permission fault mapping cache bug.
>
>This is the sort of information that goes in the cover letter.
>
>>
>> arch/arm64/include/asm/kvm_pkvm.h | 1 +
>> arch/arm64/kvm/pkvm.c | 8 +++++++-
>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_pkvm.h
>b/arch/arm64/include/asm/kvm_pkvm.h
>> index 74fedd9c5ff0..d9dd8239910d 100644
>> --- a/arch/arm64/include/asm/kvm_pkvm.h
>> +++ b/arch/arm64/include/asm/kvm_pkvm.h
>> @@ -196,6 +196,7 @@ struct pkvm_mapping {
>> u64 gfn;
>> u64 pfn;
>> u64 nr_pages;
>> + bool cacheable;
>
>Errr, no. That's a terrible idea.
>
>This thing is already big enough, let's not add a bool right in the
>middle (use pahole to find out why this is bad). Given that nr_pages
>is for a range, and that the minimum page size uses 12 bits, the
>largest number of pages you can have here is 56-12=48 bit wide. That's
>another 16 bits worth of flags you can use.
>
>Thanks,
>
> M.
>
>
thanks.
I'll go and do V3 with another sashiko suggestion. I'll fix your path too.
I'll park V3 for a bit.
Thanks!
^ permalink raw reply
* Re: [PATCH v2 1/2] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Marc Zyngier @ 2026-06-23 17:02 UTC (permalink / raw)
To: Bradley Morgan
Cc: Oliver Upton, kvmarm, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <20260623163756.4591-1-include@grrlz.net>
Bradley,
Just a few things to keep in mind for your next contributions:
- If you are sending more than a single patch, add a cover letter.
- Don't send a v2 in reply to a v1. It messes the threading we are
relying on, and makes it hard to ignore replies to an older version.
Always send new series standalone.
- Don't immediately send a V2, even if (especially if!) a bot is
pestering you. 34 minutes between versions is way too short (at
least a few days is the norm).
On Tue, 23 Jun 2026 17:37:55 +0100,
Bradley Morgan <include@grrlz.net> wrote:
>
> pKVM keeps its own mapping list for stage 2 operations. Its flush path
> uses that list directly, so it lost the PTE attribute check done by the
> generic stage 2 walker.
>
> Record whether a mapping is cacheable and skip cache maintenance for
> mappings that are not cacheable.
>
> Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
> Cc: stable@vger.kernel.org
What device memory gets mapped in an upstream pKVM guest that would
require a backport to stable?
> Signed-off-by: Bradley Morgan <include@grrlz.net>
> ---
> Changes in v2:
> - Add patch 2 for the pKVM permission fault mapping cache bug.
This is the sort of information that goes in the cover letter.
>
> arch/arm64/include/asm/kvm_pkvm.h | 1 +
> arch/arm64/kvm/pkvm.c | 8 +++++++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
> index 74fedd9c5ff0..d9dd8239910d 100644
> --- a/arch/arm64/include/asm/kvm_pkvm.h
> +++ b/arch/arm64/include/asm/kvm_pkvm.h
> @@ -196,6 +196,7 @@ struct pkvm_mapping {
> u64 gfn;
> u64 pfn;
> u64 nr_pages;
> + bool cacheable;
Errr, no. That's a terrible idea.
This thing is already big enough, let's not add a bool right in the
middle (use pahole to find out why this is bad). Given that nr_pages
is for a range, and that the minimum page size uses 12 bits, the
largest number of pages you can have here is 56-12=48 bit wide. That's
another 16 bits worth of flags you can use.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: stmmac: dwmac-spacemit: Fix wrong irq definition
From: Maxime Chevallier @ 2026-06-23 16:54 UTC (permalink / raw)
To: Inochi Amaoto, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Yixun Lan, Russell King (Oracle)
Cc: netdev, linux-stm32, linux-arm-kernel, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Longbin Li
In-Reply-To: <20260623074637.503864-3-inochiama@gmail.com>
Hi,
On 6/23/26 09:46, Inochi Amaoto wrote:
> The current irq definition of the wake irq and the lpi irq
> is wrong, replace them with the right number and name.
>
> Fixes: 30f0ba420ed3 ("net: stmmac: Add glue layer for Spacemit K3 SoC")
> Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> index 3bfb6d49be6c..322bdf167a4a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> @@ -22,8 +22,8 @@
> #define CTRL_PHY_INTF_RMII FIELD_PREP(CTRL_PHY_INTF_MODE, 0)
> #define CTRL_PHY_INTF_RGMII FIELD_PREP(CTRL_PHY_INTF_MODE, 1)
> #define CTRL_PHY_INTF_MII FIELD_PREP(CTRL_PHY_INTF_MODE, 3)
> -#define CTRL_WAKE_IRQ_EN BIT(9)
> -#define CTRL_PHY_IRQ_EN BIT(12)
> +#define CTRL_LPI_IRQ_EN BIT(9)
> +#define CTRL_WAKE_IRQ_EN BIT(12)
>
> /* dline register bits */
> #define RGMII_RX_DLINE_EN BIT(0)
^ permalink raw reply
* Re: [PATCH net v2 1/2] net: stmmac: dwmac-spacemit: Fix wrong phy interface definition
From: Maxime Chevallier @ 2026-06-23 16:53 UTC (permalink / raw)
To: Inochi Amaoto, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Yixun Lan, Russell King (Oracle)
Cc: netdev, linux-stm32, linux-arm-kernel, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Longbin Li
In-Reply-To: <20260623074637.503864-2-inochiama@gmail.com>
Hello,
On 6/23/26 09:46, Inochi Amaoto wrote:
> The current MII interface register definition from the vendor is wrong,
> use the right number for the macro. Also, correct the interface mask
> in spacemit_set_phy_intf_sel() so it can update the register with the
> right number
>
> Fixes: 30f0ba420ed3 ("net: stmmac: Add glue layer for Spacemit K3 SoC")
> Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> index 223754cc5c79..3bfb6d49be6c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> @@ -18,8 +18,10 @@
> #include "stmmac_platform.h"
>
> /* ctrl register bits */
> -#define CTRL_PHY_INTF_RGMII BIT(3)
> -#define CTRL_PHY_INTF_MII BIT(4)
> +#define CTRL_PHY_INTF_MODE GENMASK(4, 3)
> +#define CTRL_PHY_INTF_RMII FIELD_PREP(CTRL_PHY_INTF_MODE, 0)
> +#define CTRL_PHY_INTF_RGMII FIELD_PREP(CTRL_PHY_INTF_MODE, 1)
> +#define CTRL_PHY_INTF_MII FIELD_PREP(CTRL_PHY_INTF_MODE, 3)
> #define CTRL_WAKE_IRQ_EN BIT(9)
> #define CTRL_PHY_IRQ_EN BIT(12)
>
> @@ -118,7 +120,7 @@ static void spacemit_get_interfaces(struct stmmac_priv *priv, void *bsp_priv,
>
> static int spacemit_set_phy_intf_sel(void *bsp_priv, u8 phy_intf_sel)
> {
> - unsigned int mask = CTRL_PHY_INTF_MII | CTRL_PHY_INTF_RGMII;
> + unsigned int mask = CTRL_PHY_INTF_MODE;
> struct spacmit_dwmac *dwmac = bsp_priv;
> unsigned int val = 0;
>
> @@ -128,6 +130,7 @@ static int spacemit_set_phy_intf_sel(void *bsp_priv, u8 phy_intf_sel)
> break;
>
> case PHY_INTF_SEL_RMII:
> + val = CTRL_PHY_INTF_RMII;
This isn't strictly-speaking necessary as this is 0 and val is already 0, maybe
compilers can figure it out and this leaves us with more self-documenting code ?
So I'm ok with that personally,
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
> break;
>
> case PHY_INTF_SEL_RGMII:
^ permalink raw reply
* Re: [PATCH 6/8] iommu/qcom: Add NULL ctx check in TLB invalidation paths
From: Konrad Dybcio @ 2026-06-23 16:47 UTC (permalink / raw)
To: Mukesh Ojha, Rob Clark, Will Deacon, Joerg Roedel (AMD)
Cc: Robin Murphy, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260623122034.1166295-7-mukesh.ojha@oss.qualcomm.com>
On 6/23/26 2:20 PM, Mukesh Ojha wrote:
> to_ctx() returns qcom_iommu->ctxs[asid], which can be NULL if the
> corresponding context bank failed to probe or was already removed.
> qcom_iommu_tlb_sync(), qcom_iommu_tlb_inv_context(), and
> qcom_iommu_tlb_inv_range_nosync() all dereference the returned pointer
> directly, risking a NULL pointer dereference.
>
> Add WARN_ON(!ctx) guards with continue so TLB operations skip
> broken context banks without crashing.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/iommu/arm/arm-smmu/qcom_iommu.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> index 40fb0408dc07..51b60b296bb8 100644
> --- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> @@ -121,6 +121,9 @@ static void qcom_iommu_tlb_sync(void *cookie)
> struct qcom_iommu_ctx *ctx = to_ctx(qcom_domain, fwspec->ids[i]);
> unsigned int val, ret;
>
> + if (WARN_ON(!ctx))
> + continue;
I'm rather unamused that we have to deal with this in the first
place.. I don't know if this can be easily reworked to be more
predictable, but this works in the interim
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 8/8] iommu/qcom: Document why sec_ptbl allocated flag needs no locking
From: Konrad Dybcio @ 2026-06-23 16:41 UTC (permalink / raw)
To: Mukesh Ojha, Rob Clark, Will Deacon, Joerg Roedel (AMD)
Cc: Robin Murphy, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260623122034.1166295-9-mukesh.ojha@oss.qualcomm.com>
On 6/23/26 2:20 PM, Mukesh Ojha wrote:
> qcom_iommu_sec_ptbl_init() uses a function-static bool to track whether
> the secure page table has been initialized, with no locking around it.
>
> Only one IOMMU device per SoC has secure context banks (the others have
> only non-secure context banks), and platform devices probe serially since
> the driver does not set PROBE_PREFER_ASYNCHRONOUS. Concurrent calls to
This may be influenced by cmdline, so I'd rather not take it for granted
although I'm not sure how this plays out with the context bank device
always being a child of the IOMMU
Konrad
^ permalink raw reply
* [PATCH v2 2/2] KVM: arm64: top up pKVM mapping cache for permission faults
From: Bradley Morgan @ 2026-06-23 16:37 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, kvmarm
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Quentin Perret,
Vincent Donnefort, linux-arm-kernel, linux-kernel, Bradley Morgan,
stable
In-Reply-To: <20260623163756.4591-1-include@grrlz.net>
Permission faults normally only relax an existing leaf, so the fault path
does not top up the memcache.
With pKVM, a permission fault can also replace page mappings with a
PMD mapping. That path needs a fresh pkvm_mapping object, and can
dereference a NULL cache->mapping if the cache was not topped up.
Allocate just that object for pKVM permission faults.
The issue was discovered [1] by Sashiko.
Link: https://lore.kernel.org/all/20260623161545.EA08E1F000E9@smtp.kernel.org/ [1]
Fixes: db14091d8f75 ("KVM: arm64: Stage-2 huge mappings for np-guests")
Cc: stable@vger.kernel.org
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
Changes in v2:
- New patch.
arch/arm64/kvm/mmu.c | 29 ++++++++++++++++++++++-------
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 6c941aaa10c6..3f57f6825a33 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1177,17 +1177,26 @@ void free_hyp_memcache(struct kvm_hyp_memcache *mc)
__free_hyp_memcache(mc, hyp_mc_free_fn, kvm_host_va, mc);
}
+static int topup_hyp_memcache_mapping(struct kvm_hyp_memcache *mc)
+{
+ if (mc->mapping)
+ return 0;
+
+ mc->mapping = kzalloc_obj(struct pkvm_mapping,
+ GFP_KERNEL_ACCOUNT);
+ return mc->mapping ? 0 : -ENOMEM;
+}
+
int topup_hyp_memcache(struct kvm_hyp_memcache *mc, unsigned long min_pages)
{
+ int ret;
+
if (!is_protected_kvm_enabled())
return 0;
- if (!mc->mapping) {
- mc->mapping = kzalloc_obj(struct pkvm_mapping,
- GFP_KERNEL_ACCOUNT);
- if (!mc->mapping)
- return -ENOMEM;
- }
+ ret = topup_hyp_memcache_mapping(mc);
+ if (ret)
+ return ret;
return __topup_hyp_memcache(mc, min_pages, hyp_mc_alloc_fn,
kvm_host_pa, mc);
@@ -2113,7 +2122,9 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
* Permission faults just need to update the existing leaf entry,
* and so normally don't require allocations from the memcache. The
* only exception to this is when dirty logging is enabled at runtime
- * and a write fault needs to collapse a block entry into a table.
+ * and a write fault needs to collapse a block entry into a table. With
+ * pKVM, they may still need a fresh mapping object if the fault turns
+ * page entries into a block entry.
*/
memcache = get_mmu_memcache(s2fd->vcpu);
if (!perm_fault || (memslot_is_logging(s2fd->memslot) &&
@@ -2121,6 +2132,10 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
ret = topup_mmu_memcache(s2fd->vcpu, memcache);
if (ret)
return ret;
+ } else if (is_protected_kvm_enabled()) {
+ ret = topup_hyp_memcache_mapping(memcache);
+ if (ret)
+ return ret;
}
/*
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Bradley Morgan @ 2026-06-23 16:37 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, kvmarm
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Quentin Perret,
Vincent Donnefort, linux-arm-kernel, linux-kernel, Bradley Morgan,
stable
In-Reply-To: <20260623160339.15143-1-include@grrlz.net>
pKVM keeps its own mapping list for stage 2 operations. Its flush path
uses that list directly, so it lost the PTE attribute check done by the
generic stage 2 walker.
Record whether a mapping is cacheable and skip cache maintenance for
mappings that are not cacheable.
Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
Cc: stable@vger.kernel.org
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
Changes in v2:
- Add patch 2 for the pKVM permission fault mapping cache bug.
arch/arm64/include/asm/kvm_pkvm.h | 1 +
arch/arm64/kvm/pkvm.c | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
index 74fedd9c5ff0..d9dd8239910d 100644
--- a/arch/arm64/include/asm/kvm_pkvm.h
+++ b/arch/arm64/include/asm/kvm_pkvm.h
@@ -196,6 +196,7 @@ struct pkvm_mapping {
u64 gfn;
u64 pfn;
u64 nr_pages;
+ bool cacheable;
u64 __subtree_last; /* Internal member for interval tree */
};
diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
index 428723b1b0f5..105ab1258066 100644
--- a/arch/arm64/kvm/pkvm.c
+++ b/arch/arm64/kvm/pkvm.c
@@ -473,6 +473,8 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
mapping->gfn = gfn;
mapping->pfn = pfn;
mapping->nr_pages = size / PAGE_SIZE;
+ mapping->cacheable = !(prot & (KVM_PGTABLE_PROT_DEVICE |
+ KVM_PGTABLE_PROT_NORMAL_NC));
pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
return ret;
@@ -517,9 +519,13 @@ int pkvm_pgtable_stage2_flush(struct kvm_pgtable *pgt, u64 addr, u64 size)
struct pkvm_mapping *mapping;
lockdep_assert_held(&kvm->mmu_lock);
- for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
+ for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
+ if (!mapping->cacheable)
+ continue;
+
__clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
PAGE_SIZE * mapping->nr_pages);
+ }
return 0;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 7/8] iommu/qcom: Enable clocks before hardware access in qcom_iommu_ctx_probe()
From: Konrad Dybcio @ 2026-06-23 16:36 UTC (permalink / raw)
To: Mukesh Ojha, Rob Clark, Will Deacon, Joerg Roedel (AMD)
Cc: Robin Murphy, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260623122034.1166295-8-mukesh.ojha@oss.qualcomm.com>
On 6/23/26 2:20 PM, Mukesh Ojha wrote:
> qcom_iommu_ctx_probe() reads and writes the CB_FSR register to clear any
> stale IRQ left by the bootloader. This happens during
> devm_of_platform_populate() which is called from the parent device's
> probe before any pm_runtime_get(). The parent's clocks (iface, bus, tbu)
> are therefore not guaranteed to be on, making the register access
> unreliable on rebind or after a suspend cycle.
>
> Use pm_runtime_resume_and_get() on the parent device to ensure clocks
> are enabled before the register access, and release the reference
> immediately after.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH 5/7] i2c: nomadik: change print level for fault messages to debug
From: Dmitry Guzman @ 2026-06-23 16:31 UTC (permalink / raw)
To: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Linus Walleij
Cc: linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel,
Dmitry Guzman
In-Reply-To: <20260623-i2c-fault-reporting-v1-0-6db1a8aabf18@mobileye.com>
i2c-nomadik driver prints error message on every faulted message. This
is not a good practice, because in I2C a fault not always is an error,
sometimes it is the expected result. For example, scanning bus with
`i2cdetects` prints over 100 messages in dmesg (two messages per each
target address).
To avoid excessive prints in the log, change the print level from err to
debug.
Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
---
drivers/i2c/busses/i2c-nomadik.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index e19ace904e79cd2d83171d9f38fc103a6c5e023b..7d93fb3876dc1324003dd19884e3fd5cbba9cfbb 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -627,7 +627,7 @@ static int write_i2c(struct nmk_i2c_dev *priv, u16 flags)
if (!xfer_done) {
/* Controller timed out */
- dev_err(&priv->adev->dev, "write to slave 0x%x timed out\n",
+ dev_dbg(&priv->adev->dev, "write to slave 0x%x timed out\n",
priv->cli.slave_adr);
status = -ETIMEDOUT;
}
@@ -661,7 +661,7 @@ static int nmk_i2c_xfer_one(struct nmk_i2c_dev *priv, u16 flags)
i2c_sr = readl(priv->virtbase + I2C_SR);
if (FIELD_GET(I2C_SR_STATUS, i2c_sr) == I2C_ABORT) {
cause = FIELD_GET(I2C_SR_CAUSE, i2c_sr);
- dev_err(&priv->adev->dev, "%s\n",
+ dev_dbg(&priv->adev->dev, "%s\n",
cause >= ARRAY_SIZE(abort_causes) ?
"unknown reason" :
abort_causes[cause]);
--
2.43.0
^ permalink raw reply related
* [PATCH 6/7] i2c: nomadik: add quirks max_len=2047 and no_zero_len_read
From: Dmitry Guzman @ 2026-06-23 16:31 UTC (permalink / raw)
To: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Linus Walleij
Cc: linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel,
Dmitry Guzman
In-Reply-To: <20260623-i2c-fault-reporting-v1-0-6db1a8aabf18@mobileye.com>
In Nomadik I2c controller, register I2C_MCR has 11-bit wide LENGTH
field. Its maximum value is 2047, so this is the maximum length of a
single message. It is less than the common maximum I2C message length in
I2C subsystem (8192), so define a quirk in order to report the
unsupported message without any attempt to transfer it.
Zero length reading doesn't work properly on this controller, so add
`I2C_AQ_NO_ZERO_LEN_READ` quirk flag.
Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
---
drivers/i2c/busses/i2c-nomadik.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 7d93fb3876dc1324003dd19884e3fd5cbba9cfbb..9cff0c2757fafeaf809395e02a5e754570f65e08 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -79,6 +79,9 @@
#define I2C_MCR_STOP BIT(14) /* Stop condition */
#define I2C_MCR_LENGTH GENMASK(25, 15) /* Transaction length */
+/* Controller hardware limitation of the message length */
+#define I2C_MAX_MSG_LENGTH (I2C_MCR_LENGTH >> 15)
+
/* Status register (SR) */
#define I2C_SR_OP GENMASK(1, 0) /* Operation */
#define I2C_SR_STATUS GENMASK(3, 2) /* controller status */
@@ -238,6 +241,12 @@ static int fault_codes[] = {
EIO
};
+static const struct i2c_adapter_quirks nmk_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN_READ,
+ .max_read_len = I2C_MAX_MSG_LENGTH,
+ .max_write_len = I2C_MAX_MSG_LENGTH,
+};
+
static inline void i2c_set_bit(void __iomem *reg, u32 mask)
{
writel(readl(reg) | mask, reg);
@@ -1162,6 +1171,7 @@ static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
adap->class = I2C_CLASS_DEPRECATED;
adap->algo = &nmk_i2c_algo;
adap->timeout = usecs_to_jiffies(priv->timeout_usecs);
+ adap->quirks = &nmk_i2c_quirks;
snprintf(adap->name, sizeof(adap->name),
"Nomadik I2C at %pR", &adev->res);
--
2.43.0
^ permalink raw reply related
* [PATCH 7/7] i2c: nomadik: add support for I2C_XFER_V2 - detailed fault reporting
From: Dmitry Guzman @ 2026-06-23 16:31 UTC (permalink / raw)
To: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Linus Walleij
Cc: linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel,
Dmitry Guzman
In-Reply-To: <20260623-i2c-fault-reporting-v1-0-6db1a8aabf18@mobileye.com>
I2C_XFER_V2 is a new API that allows I2C clients to get the detailed
report in case of transmission failure. Previously, the only information
returned by I2C bus controller was the error code; there was no way to
find out how many messages or bytes in a certain message have been sent
or received until the fault condition occurred.
This commit introduces support of this feature in i2c-nomadik driver.
Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
---
drivers/i2c/busses/i2c-nomadik.c | 37 +++++++++++++++++++++++++++++++------
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 9cff0c2757fafeaf809395e02a5e754570f65e08..1cf03d634fdc856dc335a58597e0fd31ab077078 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -197,6 +197,7 @@ struct i2c_nmk_client {
* @stop: stop condition.
* @xfer_wq: xfer done wait queue.
* @result: controller propogated result.
+ * @bytes_cplt: number of bytes completed in the message that caused a fault.
*/
struct nmk_i2c_dev {
struct i2c_vendor_data *vendor;
@@ -216,6 +217,7 @@ struct nmk_i2c_dev {
int stop;
struct wait_queue_head xfer_wq;
int result;
+ int bytes_cplt;
};
/* controller's abort causes */
@@ -529,6 +531,8 @@ static int read_i2c(struct nmk_i2c_dev *priv, u16 flags)
int status = 0;
bool xfer_done;
+ priv->cli.xfer_bytes = 0;
+
mcr = load_i2c_mcr_reg(priv, flags);
writel(mcr, priv->virtbase + I2C_MCR);
@@ -653,6 +657,7 @@ static int nmk_i2c_xfer_one(struct nmk_i2c_dev *priv, u16 flags)
{
int status;
+ priv->bytes_cplt = 0;
if (flags & I2C_M_RD) {
/* read operation */
priv->cli.operation = I2C_READ;
@@ -678,6 +683,16 @@ static int nmk_i2c_xfer_one(struct nmk_i2c_dev *priv, u16 flags)
status = priv->result;
}
+ if (flags & I2C_M_RD) {
+ /* For READ messages, return the number of bytes read from FIFO */
+ priv->bytes_cplt = priv->cli.xfer_bytes;
+ } else {
+ /* For WRITE messages, return the number of bytes sent on bus */
+ priv->bytes_cplt = FIELD_GET(I2C_SR_LENGTH, i2c_sr);
+ /* LENGTH value includes the last byte that has not been sent or ACKed */
+ if (priv->bytes_cplt > 0)
+ priv->bytes_cplt--;
+ }
init_hw(priv);
status = status ? status : priv->result;
@@ -687,10 +702,11 @@ static int nmk_i2c_xfer_one(struct nmk_i2c_dev *priv, u16 flags)
}
/**
- * nmk_i2c_xfer() - I2C transfer function used by kernel framework
+ * nmk_i2c_xfer_v2() - I2C transfer function used by kernel framework
* @i2c_adap: Adapter pointer to the controller
* @msgs: Pointer to data to be written.
* @num_msgs: Number of messages to be executed
+ * @report: Pointer to transfer report to be written.
*
* This is the function called by the generic kernel i2c_transfer()
* or i2c_smbus...() API calls. Note that this code is protected by the
@@ -733,14 +749,16 @@ static int nmk_i2c_xfer_one(struct nmk_i2c_dev *priv, u16 flags)
* please use the i2c_smbus_read_i2c_block_data()
* or i2c_smbus_write_i2c_block_data() API
*/
-static int nmk_i2c_xfer(struct i2c_adapter *i2c_adap,
- struct i2c_msg msgs[], int num_msgs)
+static int nmk_i2c_xfer_v2(struct i2c_adapter *i2c_adap,
+ struct i2c_msg msgs[], int num_msgs,
+ struct i2c_transfer_report *report)
{
int status = 0;
int i;
struct nmk_i2c_dev *priv = i2c_get_adapdata(i2c_adap);
pm_runtime_get_sync(&priv->adev->dev);
+ priv->bytes_cplt = 0;
/* setup the i2c controller */
setup_i2c_controller(priv);
@@ -760,10 +778,17 @@ static int nmk_i2c_xfer(struct i2c_adapter *i2c_adap,
pm_runtime_put_sync(&priv->adev->dev);
/* return the no. messages processed */
- if (status)
+ if (status) {
+ report->msgs_cplt = i;
+ report->bytes_cplt = priv->bytes_cplt;
+ report->fault_msg_idx = i;
return status;
- else
+ } else {
+ report->msgs_cplt = num_msgs;
+ report->bytes_cplt = 0;
+ report->fault_msg_idx = num_msgs;
return num_msgs;
+ }
}
/**
@@ -1014,7 +1039,7 @@ static unsigned int nmk_i2c_functionality(struct i2c_adapter *adap)
}
static const struct i2c_algorithm nmk_i2c_algo = {
- .xfer = nmk_i2c_xfer,
+ .xfer_v2 = nmk_i2c_xfer_v2,
.functionality = nmk_i2c_functionality
};
--
2.43.0
^ permalink raw reply related
* [PATCH 3/7] i2c: nomadik: do not try to retransmit I2C message series on errors
From: Dmitry Guzman @ 2026-06-23 16:31 UTC (permalink / raw)
To: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Linus Walleij
Cc: linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel,
Dmitry Guzman
In-Reply-To: <20260623-i2c-fault-reporting-v1-0-6db1a8aabf18@mobileye.com>
i2c-nomadik driver of I2C bus controller in `xfer` callback retransmits
the whole message series in cause of any fault, and returns fault only
after third failed attempt. This behavior contradicts with API because
not only it hides hardware faults, but also re-sends messages, while
they are not guaranteed to be idempotent.
Remove the triple attempt to send messages in `xfer` callback.
Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
---
drivers/i2c/busses/i2c-nomadik.c | 30 ++++++++++++------------------
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index e4e5c6943c66144058fba857d7bf6c0be79ed5bd..3eb06988c026e5c573fcf55d83de7136b5ca7ac9 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -716,27 +716,21 @@ static int nmk_i2c_xfer(struct i2c_adapter *i2c_adap,
int status = 0;
int i;
struct nmk_i2c_dev *priv = i2c_get_adapdata(i2c_adap);
- int j;
pm_runtime_get_sync(&priv->adev->dev);
- /* Attempt three times to send the message queue */
- for (j = 0; j < 3; j++) {
- /* setup the i2c controller */
- setup_i2c_controller(priv);
-
- for (i = 0; i < num_msgs; i++) {
- priv->cli.slave_adr = msgs[i].addr;
- priv->cli.buffer = msgs[i].buf;
- priv->cli.count = msgs[i].len;
- priv->stop = (i < (num_msgs - 1)) ? 0 : 1;
- priv->result = 0;
-
- status = nmk_i2c_xfer_one(priv, msgs[i].flags);
- if (status != 0)
- break;
- }
- if (status == 0)
+ /* setup the i2c controller */
+ setup_i2c_controller(priv);
+
+ for (i = 0; i < num_msgs; i++) {
+ priv->cli.slave_adr = msgs[i].addr;
+ priv->cli.buffer = msgs[i].buf;
+ priv->cli.count = msgs[i].len;
+ priv->stop = (i < (num_msgs - 1)) ? 0 : 1;
+ priv->result = 0;
+
+ status = nmk_i2c_xfer_one(priv, msgs[i].flags);
+ if (status != 0)
break;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 4/7] i2c: nomadik: return proper fault codes
From: Dmitry Guzman @ 2026-06-23 16:31 UTC (permalink / raw)
To: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Linus Walleij
Cc: linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel,
Dmitry Guzman
In-Reply-To: <20260623-i2c-fault-reporting-v1-0-6db1a8aabf18@mobileye.com>
I2C documentation Documentation/i2c/fault-codes.rst defines fault codes
for different negative results in I2C transmittion. Previously,
i2c-nomadik driver didn't implement them properly - it returned
ETIMEDOUT on most errors and EIO on master arbitration lost.
To comply with the documentation, return the proper fault codes for
different conditions, namely:
- EAGAIN if arbitration lost
- EOVERFLOW if message is too long (>2047 bytes)
- ENXIO if target address is not acknowledged
- EIO on other errors detected by controller (for example, NACK on data)
- ETIMEDOUT if driver gets timeout waiting for message completion
without any fault condition detected by the controller (for example,
too long message, or SDA/SCL line stuck on 0).
Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
---
drivers/i2c/busses/i2c-nomadik.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 3eb06988c026e5c573fcf55d83de7136b5ca7ac9..e19ace904e79cd2d83171d9f38fc103a6c5e023b 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -226,6 +226,18 @@ static const char *abort_causes[] = {
"overflow, maxsize is 2047 bytes",
};
+/* Linux fault codes for controller abort causes */
+static int fault_codes[] = {
+ ENXIO,
+ EIO,
+ EIO,
+ EAGAIN,
+ EIO,
+ EIO,
+ EOVERFLOW,
+ EIO
+};
+
static inline void i2c_set_bit(void __iomem *reg, u32 mask)
{
writel(readl(reg) | mask, reg);
@@ -653,6 +665,8 @@ static int nmk_i2c_xfer_one(struct nmk_i2c_dev *priv, u16 flags)
cause >= ARRAY_SIZE(abort_causes) ?
"unknown reason" :
abort_causes[cause]);
+ priv->result = -fault_codes[cause];
+ status = priv->result;
}
init_hw(priv);
@@ -865,7 +879,7 @@ static irqreturn_t i2c_irq_handler(int irq, void *arg)
/* Master Arbitration lost interrupt */
case I2C_IT_MAL:
- priv->result = -EIO;
+ priv->result = -EAGAIN;
init_hw(priv);
i2c_set_bit(priv->virtbase + I2C_ICR, I2C_IT_MAL);
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox