* [PATCH 02/10] spi: amlogic-spisg: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-amlogic-spisg.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-amlogic-spisg.c b/drivers/spi/spi-amlogic-spisg.c
index 19c5eba412ef..4c9f4088cb37 100644
--- a/drivers/spi/spi-amlogic-spisg.c
+++ b/drivers/spi/spi-amlogic-spisg.c
@@ -601,14 +601,11 @@ static int aml_spisg_prepare_message(struct spi_controller *ctlr,
spisg->bytes_per_word = spi->bits_per_word >> 3;
- spisg->cfg_spi &= ~CFG_SLAVE_SELECT;
- spisg->cfg_spi |= FIELD_PREP(CFG_SLAVE_SELECT, spi_get_chipselect(spi, 0));
-
- spisg->cfg_bus &= ~(CFG_CPOL | CFG_CPHA | CFG_B_L_ENDIAN | CFG_HALF_DUPLEX);
- spisg->cfg_bus |= FIELD_PREP(CFG_CPOL, !!(spi->mode & SPI_CPOL)) |
- FIELD_PREP(CFG_CPHA, !!(spi->mode & SPI_CPHA)) |
- FIELD_PREP(CFG_B_L_ENDIAN, !!(spi->mode & SPI_LSB_FIRST)) |
- FIELD_PREP(CFG_HALF_DUPLEX, !!(spi->mode & SPI_3WIRE));
+ FIELD_MODIFY(CFG_SLAVE_SELECT, &spisg->cfg_spi, spi_get_chipselect(spi, 0));
+ FIELD_MODIFY(CFG_CPOL, &spisg->cfg_bus, !!(spi->mode & SPI_CPOL));
+ FIELD_MODIFY(CFG_CPHA, &spisg->cfg_bus, !!(spi->mode & SPI_CPHA));
+ FIELD_MODIFY(CFG_B_L_ENDIAN, &spisg->cfg_bus, !!(spi->mode & SPI_LSB_FIRST));
+ FIELD_MODIFY(CFG_HALF_DUPLEX, &spisg->cfg_bus, !!(spi->mode & SPI_3WIRE));
return 0;
}
--
2.34.1
^ permalink raw reply related
* [PATCH 07/10] spi: stm32-ospi: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-stm32-ospi.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-stm32-ospi.c b/drivers/spi/spi-stm32-ospi.c
index 4461c6e24b9e..3757f6ba8fc6 100644
--- a/drivers/spi/spi-stm32-ospi.c
+++ b/drivers/spi/spi-stm32-ospi.c
@@ -470,10 +470,9 @@ static int stm32_ospi_send(struct spi_device *spi, const struct spi_mem_op *op)
u8 cs = spi->chip_select[ffs(spi->cs_index_mask) - 1];
cr = readl_relaxed(ospi->regs_base + OSPI_CR);
- cr &= ~CR_CSSEL;
- cr |= FIELD_PREP(CR_CSSEL, cs);
- cr &= ~CR_FMODE_MASK;
- cr |= FIELD_PREP(CR_FMODE_MASK, ospi->fmode);
+ FIELD_MODIFY(CR_CSSEL, &cr, cs);
+
+ FIELD_MODIFY(CR_FMODE_MASK, &cr, ospi->fmode);
writel_relaxed(cr, regs_base + OSPI_CR);
if (op->data.nbytes)
--
2.34.1
^ permalink raw reply related
* [PATCH 08/10] spi: stm32-qspi: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-stm32-qspi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index df1bbacec90a..ea69fe25686f 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -374,9 +374,8 @@ static int stm32_qspi_send(struct spi_device *spi, const struct spi_mem_op *op)
int timeout, err = 0, err_poll_status = 0;
cr = readl_relaxed(qspi->io_base + QSPI_CR);
- cr &= ~CR_PRESC_MASK & ~CR_FSEL;
- cr |= FIELD_PREP(CR_PRESC_MASK, flash->presc);
- cr |= FIELD_PREP(CR_FSEL, flash->cs);
+ FIELD_MODIFY(CR_PRESC_MASK, &cr, flash->presc);
+ FIELD_MODIFY(CR_FSEL, &cr, flash->cs);
writel_relaxed(cr, qspi->io_base + QSPI_CR);
if (op->data.nbytes)
--
2.34.1
^ permalink raw reply related
* [PATCH 01/10] spi: amlogic-spifc-a1: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-amlogic-spifc-a1.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-amlogic-spifc-a1.c b/drivers/spi/spi-amlogic-spifc-a1.c
index 7ee4c92e6e09..77a2c11bec5e 100644
--- a/drivers/spi/spi-amlogic-spifc-a1.c
+++ b/drivers/spi/spi-amlogic-spifc-a1.c
@@ -206,10 +206,9 @@ static int amlogic_spifc_a1_read(struct amlogic_spifc_a1 *spifc, void *buf,
u32 val = readl(spifc->base + SPIFC_A1_USER_CTRL3_REG);
int ret;
- val &= ~(SPIFC_A1_USER_DIN_MODE | SPIFC_A1_USER_DIN_BYTES);
val |= SPIFC_A1_USER_DIN_ENABLE;
- val |= FIELD_PREP(SPIFC_A1_USER_DIN_MODE, mode);
- val |= FIELD_PREP(SPIFC_A1_USER_DIN_BYTES, size);
+ FIELD_MODIFY(SPIFC_A1_USER_DIN_MODE, &val, mode);
+ FIELD_MODIFY(SPIFC_A1_USER_DIN_BYTES, &val, size);
writel(val, spifc->base + SPIFC_A1_USER_CTRL3_REG);
ret = amlogic_spifc_a1_request(spifc, true);
--
2.34.1
^ permalink raw reply related
* [PATCH 06/10] spi: sn-f-ospi: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-sn-f-ospi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-sn-f-ospi.c b/drivers/spi/spi-sn-f-ospi.c
index b459d51cb3a8..f0320e96fe23 100644
--- a/drivers/spi/spi-sn-f-ospi.c
+++ b/drivers/spi/spi-sn-f-ospi.c
@@ -222,9 +222,8 @@ static void f_ospi_config_clk(struct f_ospi *ospi, u32 device_hz)
*/
val = readl(ospi->base + OSPI_CLK_CTL);
- val &= ~(OSPI_CLK_CTL_PHA | OSPI_CLK_CTL_DIV);
- val |= FIELD_PREP(OSPI_CLK_CTL_PHA, OSPI_CLK_CTL_PHA_180)
- | FIELD_PREP(OSPI_CLK_CTL_DIV, div_reg);
+ FIELD_MODIFY(OSPI_CLK_CTL_PHA, &val, OSPI_CLK_CTL_PHA_180);
+ FIELD_MODIFY(OSPI_CLK_CTL_DIV, &val, div_reg);
writel(val, ospi->base + OSPI_CLK_CTL);
}
--
2.34.1
^ permalink raw reply related
* [PATCH 09/10] spi: sunplus-sp7021: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-sunplus-sp7021.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/spi-sunplus-sp7021.c b/drivers/spi/spi-sunplus-sp7021.c
index 35601212fb78..c1870322d976 100644
--- a/drivers/spi/spi-sunplus-sp7021.c
+++ b/drivers/spi/spi-sunplus-sp7021.c
@@ -290,8 +290,7 @@ static void sp7021_spi_setup_clk(struct spi_controller *ctlr, struct spi_transfe
div = max(2U, clk_rate / xfer->speed_hz);
clk_sel = (div / 2) - 1;
- pspim->xfer_conf &= ~SP7021_CLK_MASK;
- pspim->xfer_conf |= FIELD_PREP(SP7021_CLK_MASK, clk_sel);
+ FIELD_MODIFY(SP7021_CLK_MASK, &pspim->xfer_conf, clk_sel);
writel(pspim->xfer_conf, pspim->m_base + SP7021_SPI_CONFIG_REG);
}
--
2.34.1
^ permalink raw reply related
* [PATCH 04/10] spi: meson-spicc: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-meson-spicc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-meson-spicc.c b/drivers/spi/spi-meson-spicc.c
index b80f9f457b66..682dda114412 100644
--- a/drivers/spi/spi-meson-spicc.c
+++ b/drivers/spi/spi-meson-spicc.c
@@ -539,9 +539,8 @@ static void meson_spicc_setup_xfer(struct meson_spicc_device *spicc,
conf = conf_orig = readl_relaxed(spicc->base + SPICC_CONREG);
/* Setup word width */
- conf &= ~SPICC_BITLENGTH_MASK;
- conf |= FIELD_PREP(SPICC_BITLENGTH_MASK,
- (spicc->bytes_per_word << 3) - 1);
+ FIELD_MODIFY(SPICC_BITLENGTH_MASK, &conf,
+ (spicc->bytes_per_word << 3) - 1);
/* Ignore if unchanged */
if (conf != conf_orig)
--
2.34.1
^ permalink raw reply related
* [PATCH 03/10] spi: cadence-xspi: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-cadence-xspi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/spi-cadence-xspi.c b/drivers/spi/spi-cadence-xspi.c
index 895b4b3276a5..32fa19ebf7a9 100644
--- a/drivers/spi/spi-cadence-xspi.c
+++ b/drivers/spi/spi-cadence-xspi.c
@@ -453,8 +453,7 @@ static bool cdns_mrvl_xspi_setup_clock(struct cdns_xspi_dev *cdns_xspi,
writel(clk_reg,
cdns_xspi->auxbase + MRVL_XSPI_CLK_CTRL_AUX_REG);
clk_reg = FIELD_PREP(MRVL_XSPI_CLK_DIV, i);
- clk_reg &= ~MRVL_XSPI_CLK_DIV;
- clk_reg |= FIELD_PREP(MRVL_XSPI_CLK_DIV, i);
+ FIELD_MODIFY(MRVL_XSPI_CLK_DIV, &clk_reg, i);
clk_reg |= MRVL_XSPI_CLK_ENABLE;
clk_reg |= MRVL_XSPI_IRQ_ENABLE;
update_clk = true;
--
2.34.1
^ permalink raw reply related
* [PATCH 10/10] spi: uniphier: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-uniphier.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index eac6c3e8908b..846f65ba9495 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -184,14 +184,12 @@ static void uniphier_spi_set_transfer_size(struct spi_device *spi, int size)
u32 val;
val = readl(priv->base + SSI_TXWDS);
- val &= ~(SSI_TXWDS_WDLEN_MASK | SSI_TXWDS_DTLEN_MASK);
- val |= FIELD_PREP(SSI_TXWDS_WDLEN_MASK, size);
- val |= FIELD_PREP(SSI_TXWDS_DTLEN_MASK, size);
+ FIELD_MODIFY(SSI_TXWDS_WDLEN_MASK, &val, size);
+ FIELD_MODIFY(SSI_TXWDS_DTLEN_MASK, &val, size);
writel(val, priv->base + SSI_TXWDS);
val = readl(priv->base + SSI_RXWDS);
- val &= ~SSI_RXWDS_DTLEN_MASK;
- val |= FIELD_PREP(SSI_RXWDS_DTLEN_MASK, size);
+ FIELD_MODIFY(SSI_RXWDS_DTLEN_MASK, &val, size);
writel(val, priv->base + SSI_RXWDS);
}
@@ -308,9 +306,8 @@ static void uniphier_spi_set_fifo_threshold(struct uniphier_spi_priv *priv,
u32 val;
val = readl(priv->base + SSI_FC);
- val &= ~(SSI_FC_TXFTH_MASK | SSI_FC_RXFTH_MASK);
- val |= FIELD_PREP(SSI_FC_TXFTH_MASK, SSI_FIFO_DEPTH - threshold);
- val |= FIELD_PREP(SSI_FC_RXFTH_MASK, threshold);
+ FIELD_MODIFY(SSI_FC_TXFTH_MASK, &val, SSI_FIFO_DEPTH - threshold);
+ FIELD_MODIFY(SSI_FC_RXFTH_MASK, &val, threshold);
writel(val, priv->base + SSI_FC);
}
--
2.34.1
^ permalink raw reply related
* [PATCH 00/10] spi: Use FIELD_MODIFY() for bitfield operations
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
Replace open-coded bitfield modifications with the standard FIELD_MODIFY()
macro across multiple SPI controller drivers. This improves readability and
adds compile-time checking without functional changes.
Each patch modifies a single driver, allowing independent review and
application.
Hans Zhang (10):
spi: amlogic-spifc-a1: Use FIELD_MODIFY()
spi: amlogic-spisg: Use FIELD_MODIFY()
spi: cadence-xspi: Use FIELD_MODIFY()
spi: meson-spicc: Use FIELD_MODIFY()
spi: nxp-xspi: Use FIELD_MODIFY()
spi: sn-f-ospi: Use FIELD_MODIFY()
spi: stm32-ospi: Use FIELD_MODIFY()
spi: stm32-qspi: Use FIELD_MODIFY()
spi: sunplus-sp7021: Use FIELD_MODIFY()
spi: uniphier: Use FIELD_MODIFY()
drivers/spi/spi-amlogic-spifc-a1.c | 5 ++---
drivers/spi/spi-amlogic-spisg.c | 13 +++++--------
drivers/spi/spi-cadence-xspi.c | 3 +--
drivers/spi/spi-meson-spicc.c | 5 ++---
drivers/spi/spi-nxp-xspi.c | 12 ++++--------
drivers/spi/spi-sn-f-ospi.c | 5 ++---
drivers/spi/spi-stm32-ospi.c | 7 +++----
drivers/spi/spi-stm32-qspi.c | 5 ++---
drivers/spi/spi-sunplus-sp7021.c | 3 +--
drivers/spi/spi-uniphier.c | 13 +++++--------
10 files changed, 27 insertions(+), 44 deletions(-)
base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
--
2.34.1
^ permalink raw reply
* [PATCH] KVM: arm64: Work around C1-Pro erratum 4193714 for protected guests
From: Catalin Marinas @ 2026-04-30 15:59 UTC (permalink / raw)
To: Will Deacon, Marc Zyngier
Cc: linux-arm-kernel, James Morse, Catalin Marinas, Mark Rutland,
Oliver Upton, Vincent Donnefort, Lorenzo Pieralisi, Sudeep Holla
From: James Morse <james.morse@arm.com>
C1-Pro cores with SME have an erratum where TLBI+DSB does not complete
all outstanding SME accesses. Instead a DSB needs to be executed on the
affected CPUs. The implication is pages cannot be unmapped from the
host Stage 2 then provided to the guest. Host SME accesses may occur
after this point.
This erratum breaks pKVM's guarantees, and the workaround is hard to
implement as EL2 and EL1 share a security state meaning EL1 can mask
IPIs sent by EL2, leading to interrupt blackouts.
Instead, do this in EL3. This has the advantage of a separate security
state, meaning lower EL cannot mask the IPI. It is also simpler for EL3
to know about CPUs that are off or in PSCI's CPU_SUSPEND.
Add the needed hook to host_stage2_set_owner_metadata_locked(). This
covers the cases where the host loses access to a page:
__pkvm_host_donate_guest()
__pkvm_guest_unshare_host()
host_stage2_set_owner_locked() when owner_id == PKVM_ID_HYP
Signed-off-by: James Morse <james.morse@arm.com>
[catalin.marinas@arm.com: move the hook to host_stage2_set_owner_metadata_locked()]
[catalin.marinas@arm.com: use hyp_smccc_1_1_smc()]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Vincent Donnefort <vdonnefort@google.com>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Sudeep Holla <sudeep.holla@kernel.org>
---
That's a rebase to 7.1-rc1 together with a few tweaks. The initial
workaround for pKVM was posted here:
https://lore.kernel.org/r/20260323162408.4163113-6-catalin.marinas@arm.com
I dropped the vN numbering since the original series evolved a bit. I
also changed the subject here, more suitable for a stand-alone patch.
Changes since last time:
- Use hyp_smccc_1_1_smc() instead of arm_smccc_1_1_smc() as suggested by
Vincent
- Do the SMC only when the host loses access to a page and not when the
ownership transition happens in the other direction. Guests do not
have access to SME in current mainline
I looked at the Android16 backport from Vincent and it covers more
cases but they do not apply to mainline (sglists, donate to FF-A). I
could not figure out why changing a host permission from RW to R or
!valid matters for this workaround, so that's not done here either.
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 20 +++++++++++++++++++-
include/linux/arm-smccc.h | 6 ++++++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 28a471d1927c..75977179c9d1 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -5,6 +5,8 @@
*/
#include <linux/kvm_host.h>
+#include <linux/arm-smccc.h>
+
#include <asm/kvm_emulate.h>
#include <asm/kvm_hyp.h>
#include <asm/kvm_mmu.h>
@@ -14,6 +16,7 @@
#include <hyp/fault.h>
+#include <nvhe/arm-smccc.h>
#include <nvhe/gfp.h>
#include <nvhe/memory.h>
#include <nvhe/mem_protect.h>
@@ -29,6 +32,15 @@ static struct hyp_pool host_s2_pool;
static DEFINE_PER_CPU(struct pkvm_hyp_vm *, __current_vm);
#define current_vm (*this_cpu_ptr(&__current_vm))
+static void pkvm_sme_dvmsync_fw_call(void)
+{
+ if (alternative_has_cap_unlikely(ARM64_WORKAROUND_4193714)) {
+ struct arm_smccc_res res;
+
+ hyp_smccc_1_1_smc(ARM_SMCCC_CPU_WORKAROUND_4193714, &res);
+ }
+}
+
static void guest_lock_component(struct pkvm_hyp_vm *vm)
{
hyp_spin_lock(&vm->lock);
@@ -574,8 +586,14 @@ static int host_stage2_set_owner_metadata_locked(phys_addr_t addr, u64 size,
ret = host_stage2_try(kvm_pgtable_stage2_annotate, &host_mmu.pgt,
addr, size, &host_s2_pool,
KVM_HOST_INVALID_PTE_TYPE_DONATION, annotation);
- if (!ret)
+ if (!ret) {
+ /*
+ * After stage2 maintenance has happened, but before the page
+ * owner has changed.
+ */
+ pkvm_sme_dvmsync_fw_call();
__host_update_page_state(addr, size, PKVM_NOPAGE);
+ }
return ret;
}
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 50b47eba7d01..e7195750d21b 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -105,6 +105,12 @@
ARM_SMCCC_SMC_32, \
0, 0x3fff)
+/* C1-Pro erratum 4193714: SME DVMSync early acknowledgement */
+#define ARM_SMCCC_CPU_WORKAROUND_4193714 \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_CPU, 0x10)
+
#define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
ARM_SMCCC_SMC_32, \
^ permalink raw reply related
* [PATCH v2 0/2] arm_ffa, KVM: Fix FF-A emad offset calculations
From: Sebastian Ene @ 2026-04-30 16:02 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, sudeep.holla, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Hi all,
This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations
and adds the necessary bounds checks for both the core FF-A driver and the pKVM
hypervisor.
Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset
for the EMADs, leading to the assumption that they immediately follow the header.
However, from v1.1 onwards, the specification dictates using the `ep_mem_offset` field
to determine the start of the memory access array.
The patches in this series address this by:
1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor
offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`.
It also introduces bounds checking against `max_fragsize`.
2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that
the descriptor strictly follows the header, aligning it with the driver behavior
and the FF-A specification, while also ensuring the offset falls within the mailbox
buffer bounds.
Changes since v1:
- For pKVM, removed the strict placement enforcement for `ep_mem_offset` as it is not
compliant with the spec, and avoids making assumptions about the driver's memory
layout.
Link to v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t
Sebastian Ene (2):
firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset
calculation
KVM: arm64: Validate the offset to the mem access descriptor
arch/arm64/kvm/hyp/nvhe/ffa.c | 24 ++++++++++++++++++------
drivers/firmware/arm_ffa/driver.c | 14 ++++++++++----
include/linux/arm_ffa.h | 2 +-
3 files changed, 29 insertions(+), 11 deletions(-)
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply
* [PATCH v2 1/2] firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation
From: Sebastian Ene @ 2026-04-30 16:02 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, sudeep.holla, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260430160241.1934777-1-sebastianene@google.com>
Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint
memory access array and to comply with the FF-A spec instead of defaulting
to `sizeof(struct ffa_mem_region)`.
This requires moving `ffa_mem_region_additional_setup()` earlier in the setup
flow.
Also, add sanity checks to ensure the calculated descriptor offsets do not
exceed `max_fragsize`.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
drivers/firmware/arm_ffa/driver.c | 14 ++++++++++----
include/linux/arm_ffa.h | 2 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index eb2782848283..56b166290b24 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -685,18 +685,25 @@ ffa_setup_and_transmit(u32 func_id, void *buffer, u32 max_fragsize,
struct ffa_composite_mem_region *composite;
struct ffa_mem_region_addr_range *constituents;
struct ffa_mem_region_attributes *ep_mem_access;
- u32 idx, frag_len, length, buf_sz = 0, num_entries = sg_nents(args->sg);
+ u32 idx, frag_len, length, buf_sz = 0, num_entries = sg_nents(args->sg), ep_offset;
mem_region->tag = args->tag;
mem_region->flags = args->flags;
mem_region->sender_id = drv_info->vm_id;
mem_region->attributes = ffa_memory_attributes_get(func_id);
+
+ ffa_mem_region_additional_setup(drv_info->version, mem_region);
composite_offset = ffa_mem_desc_offset(buffer, args->nattrs,
drv_info->version);
+ if (composite_offset > max_fragsize - sizeof(struct ffa_composite_mem_region))
+ return -ENXIO;
for (idx = 0; idx < args->nattrs; idx++) {
- ep_mem_access = buffer +
- ffa_mem_desc_offset(buffer, idx, drv_info->version);
+ ep_offset = ffa_mem_desc_offset(buffer, idx, drv_info->version);
+ if (ep_offset > max_fragsize - sizeof(struct ffa_mem_region_attributes))
+ return -ENXIO;
+
+ ep_mem_access = buffer + ep_offset;
ep_mem_access->receiver = args->attrs[idx].receiver;
ep_mem_access->attrs = args->attrs[idx].attrs;
ep_mem_access->composite_off = composite_offset;
@@ -708,7 +715,6 @@ ffa_setup_and_transmit(u32 func_id, void *buffer, u32 max_fragsize,
}
mem_region->handle = 0;
mem_region->ep_count = args->nattrs;
- ffa_mem_region_additional_setup(drv_info->version, mem_region);
composite = buffer + composite_offset;
composite->total_pg_cnt = ffa_get_num_pages_sg(args->sg);
diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index 81e603839c4a..62d67dae8b70 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -445,7 +445,7 @@ ffa_mem_desc_offset(struct ffa_mem_region *buf, int count, u32 ffa_version)
if (!FFA_MEM_REGION_HAS_EP_MEM_OFFSET(ffa_version))
offset += offsetof(struct ffa_mem_region, ep_mem_offset);
else
- offset += sizeof(struct ffa_mem_region);
+ offset += buf->ep_mem_offset;
return offset;
}
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v2 2/2] KVM: arm64: Validate the offset to the mem access descriptor
From: Sebastian Ene @ 2026-04-30 16:02 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, sudeep.holla, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260430160241.1934777-1-sebastianene@google.com>
Prevent the pKVM hypervisor from making assumptions that the
endpoint memory access descriptor (EMAD) comes right after the
FF-A memory region header.
Prior to FF-A version 1.1 the header of the memory region
didn't contain an offset to the endpoint memory access descriptor.
The layout of a memory transaction looks like this from 1.1 onward:
Type | Field name | Offset
[ Header | ffa_mem_region | 0
EMAD 1 | ffa_mem_region_attributes) | ffa_mem_region.ep_mem_offset
]
Verify that the offset to the first endpoint memory access descriptor
is within the mailbox buffer bounds.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
v1 -> v2:
* don't enforce a strict placement for the ep_mem_offset since this is
not compliant with the spec and we should not make assumptions about
the driver.
Link to v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t
---
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 1af722771178..8e9017fc8e39 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -479,7 +479,7 @@ static void __do_ffa_mem_xfer(const u64 func_id,
struct ffa_mem_region_attributes *ep_mem_access;
struct ffa_composite_mem_region *reg;
struct ffa_mem_region *buf;
- u32 offset, nr_ranges, checked_offset;
+ u32 offset, nr_ranges, checked_offset, em_mem_access_off;
int ret = 0;
if (addr_mbz || npages_mbz || fraglen > len ||
@@ -508,8 +508,14 @@ static void __do_ffa_mem_xfer(const u64 func_id,
buf = hyp_buffers.tx;
memcpy(buf, host_buffers.tx, fraglen);
- ep_mem_access = (void *)buf +
- ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ if (em_mem_access_off >
+ KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE - (struct ffa_mem_region_attributes)) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out_unlock;
+ }
+
+ ep_mem_access = (void *)buf + em_mem_access_off;
offset = ep_mem_access->composite_off;
if (!offset || buf->ep_count != 1 || buf->sender_id != HOST_FFA_ID) {
ret = FFA_RET_INVALID_PARAMETERS;
@@ -576,7 +582,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
DECLARE_REG(u32, flags, ctxt, 3);
struct ffa_mem_region_attributes *ep_mem_access;
struct ffa_composite_mem_region *reg;
- u32 offset, len, fraglen, fragoff;
+ u32 offset, len, fraglen, fragoff, em_mem_access_off;
struct ffa_mem_region *buf;
int ret = 0;
u64 handle;
@@ -599,8 +605,14 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
len = res->a1;
fraglen = res->a2;
- ep_mem_access = (void *)buf +
- ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ if (em_mem_access_off >
+ KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE - (struct ffa_mem_region_attributes)) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out_unlock;
+ }
+
+ ep_mem_access = (void *)buf + em_mem_access_off;
offset = ep_mem_access->composite_off;
/*
* We can trust the SPMD to get this right, but let's at least
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH] irqchip/gic-v3-its: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 16:29 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/irqchip/irq-gic-v3-its.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 291d7668cc8d..e78795b7acfd 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -4784,8 +4784,7 @@ static bool __maybe_unused its_enable_quirk_cavium_22375(void *data)
struct its_node *its = data;
/* erratum 22375: only alloc 8MB table size (20 bits) */
- its->typer &= ~GITS_TYPER_DEVBITS;
- its->typer |= FIELD_PREP(GITS_TYPER_DEVBITS, 20 - 1);
+ FIELD_MODIFY(GITS_TYPER_DEVBITS, &its->typer, 20 - 1);
its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_22375;
return true;
@@ -4805,8 +4804,7 @@ static bool __maybe_unused its_enable_quirk_qdf2400_e0065(void *data)
struct its_node *its = data;
/* On QDF2400, the size of the ITE is 16Bytes */
- its->typer &= ~GITS_TYPER_ITT_ENTRY_SIZE;
- its->typer |= FIELD_PREP(GITS_TYPER_ITT_ENTRY_SIZE, 16 - 1);
+ FIELD_MODIFY(GITS_TYPER_ITT_ENTRY_SIZE, &its->typer, 16 - 1);
return true;
}
@@ -4840,10 +4838,8 @@ static bool __maybe_unused its_enable_quirk_socionext_synquacer(void *data)
its->get_msi_base = its_irq_get_msi_base_pre_its;
ids = ilog2(pre_its_window[1]) - 2;
- if (device_ids(its) > ids) {
- its->typer &= ~GITS_TYPER_DEVBITS;
- its->typer |= FIELD_PREP(GITS_TYPER_DEVBITS, ids - 1);
- }
+ if (device_ids(its) > ids)
+ FIELD_MODIFY(GITS_TYPER_DEVBITS, &its->typer, ids - 1);
/* the pre-ITS breaks isolation, so disable MSI remapping */
its->msi_domain_flags &= ~IRQ_DOMAIN_FLAG_ISOLATED_MSI;
base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
--
2.34.1
^ permalink raw reply related
* [PATCH 0/6] usb: Use FIELD_MODIFY() for bitfield operations
From: Hans Zhang @ 2026-04-30 16:39 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, peter.griffin, andre.draszik, tudor.ambarus,
mathias.nyman, chunfeng.yun, matthias.bgg,
angelogioacchino.delregno, badhri, heikki.krogerus
Cc: linux-usb, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-mediatek, Hans Zhang
Replace open-coded bitfield modifications with the standard FIELD_MODIFY()
macro across multiple USB drivers (dwc3, xhci, typec). This improves
readability and adds compile-time checking without functional changes.
---
Hi, If the Maintainers think it's not necessary, please ignore it.
---
Hans Zhang (6):
usb: dwc3: Use FIELD_MODIFY()
usb: dwc3: google: Use FIELD_MODIFY()
usb: dwc3: dwc3-octeon: Use FIELD_MODIFY()
usb: xhci: Use FIELD_MODIFY()
usb: xhci-mtk: Use FIELD_MODIFY()
usb: typec: Use FIELD_MODIFY()
drivers/usb/dwc3/core.c | 12 ++++--------
drivers/usb/dwc3/dwc3-google.c | 5 ++---
drivers/usb/dwc3/dwc3-octeon.c | 11 ++++-------
drivers/usb/host/xhci-hub.c | 5 ++---
drivers/usb/host/xhci-mtk.c | 6 +++---
drivers/usb/typec/tcpm/tcpci.c | 11 ++++-------
6 files changed, 19 insertions(+), 31 deletions(-)
base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
--
2.34.1
^ permalink raw reply
* [PATCH 5/6] usb: xhci-mtk: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 16:39 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, peter.griffin, andre.draszik, tudor.ambarus,
mathias.nyman, chunfeng.yun, matthias.bgg,
angelogioacchino.delregno, badhri, heikki.krogerus
Cc: linux-usb, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-mediatek, Hans Zhang
In-Reply-To: <20260430163919.47372-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/usb/host/xhci-mtk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 06043c7c3100..d9b865546a67 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -185,9 +185,9 @@ static void xhci_mtk_rxfifo_depth_set(struct xhci_hcd_mtk *mtk)
return;
value = readl(hcd->regs + HSCH_CFG1);
- value &= ~SCH3_RXFIFO_DEPTH_MASK;
- value |= FIELD_PREP(SCH3_RXFIFO_DEPTH_MASK,
- SCH_FIFO_TO_KB(mtk->rxfifo_depth) - 1);
+ FIELD_MODIFY(SCH3_RXFIFO_DEPTH_MASK, &value,
+ SCH_FIFO_TO_KB(mtk->rxfifo_depth) - 1);
+
writel(value, hcd->regs + HSCH_CFG1);
}
--
2.34.1
^ permalink raw reply related
* [PATCH 2/6] usb: dwc3: google: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 16:39 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, peter.griffin, andre.draszik, tudor.ambarus,
mathias.nyman, chunfeng.yun, matthias.bgg,
angelogioacchino.delregno, badhri, heikki.krogerus
Cc: linux-usb, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-mediatek, Hans Zhang
In-Reply-To: <20260430163919.47372-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/usb/dwc3/dwc3-google.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-google.c b/drivers/usb/dwc3/dwc3-google.c
index 4ca567ec01d0..60ee4cc99b28 100644
--- a/drivers/usb/dwc3/dwc3-google.c
+++ b/drivers/usb/dwc3/dwc3-google.c
@@ -104,9 +104,8 @@ static int dwc3_google_set_pmu_state(struct dwc3_google *google, int state)
regmap_read(google->usb_cfg_regmap,
google->host_cfg_offset + HOST_CFG1_OFFSET, ®);
- reg &= ~HOST_CFG1_PM_POWER_STATE_REQUEST;
- reg |= (FIELD_PREP(HOST_CFG1_PM_POWER_STATE_REQUEST, state) |
- HOST_CFG1_PME_EN);
+ FIELD_MODIFY(HOST_CFG1_PM_POWER_STATE_REQUEST, ®, state);
+ reg |= HOST_CFG1_PME_EN;
regmap_write(google->usb_cfg_regmap,
google->host_cfg_offset + HOST_CFG1_OFFSET, reg);
--
2.34.1
^ permalink raw reply related
* [PATCH 4/6] usb: xhci: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 16:39 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, peter.griffin, andre.draszik, tudor.ambarus,
mathias.nyman, chunfeng.yun, matthias.bgg,
angelogioacchino.delregno, badhri, heikki.krogerus
Cc: linux-usb, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-mediatek, Hans Zhang
In-Reply-To: <20260430163919.47372-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/usb/host/xhci-hub.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index bacd0ddd0d09..3830d4123961 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -226,9 +226,8 @@ static int xhci_create_usb3x_bos_desc(struct xhci_hcd *xhci, char *buf,
USB_SSP_SUBLINK_SPEED_ST_SYM_RX);
ssp_cap->bmSublinkSpeedAttr[offset++] = cpu_to_le32(attr);
- attr &= ~USB_SSP_SUBLINK_SPEED_ST;
- attr |= FIELD_PREP(USB_SSP_SUBLINK_SPEED_ST,
- USB_SSP_SUBLINK_SPEED_ST_SYM_TX);
+ FIELD_MODIFY(USB_SSP_SUBLINK_SPEED_ST, &attr,
+ USB_SSP_SUBLINK_SPEED_ST_SYM_TX);
ssp_cap->bmSublinkSpeedAttr[offset++] = cpu_to_le32(attr);
break;
case PLT_ASYM_RX:
--
2.34.1
^ permalink raw reply related
* [PATCH 3/6] usb: dwc3: dwc3-octeon: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 16:39 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, peter.griffin, andre.draszik, tudor.ambarus,
mathias.nyman, chunfeng.yun, matthias.bgg,
angelogioacchino.delregno, badhri, heikki.krogerus
Cc: linux-usb, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-mediatek, Hans Zhang
In-Reply-To: <20260430163919.47372-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/usb/dwc3/dwc3-octeon.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-octeon.c b/drivers/usb/dwc3/dwc3-octeon.c
index 42bfc14ae0c4..2201f0f34abb 100644
--- a/drivers/usb/dwc3/dwc3-octeon.c
+++ b/drivers/usb/dwc3/dwc3-octeon.c
@@ -296,8 +296,7 @@ static int dwc3_octeon_setup(struct dwc3_octeon *octeon,
return div;
}
val = dwc3_octeon_readq(uctl_ctl_reg);
- val &= ~USBDRD_UCTL_CTL_H_CLKDIV_SEL;
- val |= FIELD_PREP(USBDRD_UCTL_CTL_H_CLKDIV_SEL, div);
+ FIELD_MODIFY(USBDRD_UCTL_CTL_H_CLKDIV_SEL, &val, div);
val |= USBDRD_UCTL_CTL_H_CLK_EN;
dwc3_octeon_writeq(uctl_ctl_reg, val);
val = dwc3_octeon_readq(uctl_ctl_reg);
@@ -314,14 +313,11 @@ static int dwc3_octeon_setup(struct dwc3_octeon *octeon,
/* Step 5a: Reference clock configuration. */
val = dwc3_octeon_readq(uctl_ctl_reg);
val &= ~USBDRD_UCTL_CTL_REF_CLK_DIV2;
- val &= ~USBDRD_UCTL_CTL_REF_CLK_SEL;
- val |= FIELD_PREP(USBDRD_UCTL_CTL_REF_CLK_SEL, ref_clk_sel);
+ FIELD_MODIFY(USBDRD_UCTL_CTL_REF_CLK_SEL, &val, ref_clk_sel);
- val &= ~USBDRD_UCTL_CTL_REF_CLK_FSEL;
- val |= FIELD_PREP(USBDRD_UCTL_CTL_REF_CLK_FSEL, ref_clk_fsel);
+ FIELD_MODIFY(USBDRD_UCTL_CTL_REF_CLK_FSEL, &val, ref_clk_fsel);
- val &= ~USBDRD_UCTL_CTL_MPLL_MULTIPLIER;
- val |= FIELD_PREP(USBDRD_UCTL_CTL_MPLL_MULTIPLIER, mpll_mul);
+ FIELD_MODIFY(USBDRD_UCTL_CTL_MPLL_MULTIPLIER, &val, mpll_mul);
/* Step 5b: Configure and enable spread-spectrum for SuperSpeed. */
val |= USBDRD_UCTL_CTL_SSC_EN;
--
2.34.1
^ permalink raw reply related
* [PATCH 1/6] usb: dwc3: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 16:39 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, peter.griffin, andre.draszik, tudor.ambarus,
mathias.nyman, chunfeng.yun, matthias.bgg,
angelogioacchino.delregno, badhri, heikki.krogerus
Cc: linux-usb, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-mediatek, Hans Zhang
In-Reply-To: <20260430163919.47372-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/usb/dwc3/core.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 58899b1fa96d..f95201470ab2 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -425,8 +425,7 @@ static void dwc3_ref_clk_period(struct dwc3 *dwc)
}
reg = dwc3_readl(dwc, DWC3_GUCTL);
- reg &= ~DWC3_GUCTL_REFCLKPER_MASK;
- reg |= FIELD_PREP(DWC3_GUCTL_REFCLKPER_MASK, period);
+ FIELD_MODIFY(DWC3_GUCTL_REFCLKPER_MASK, ®, period);
dwc3_writel(dwc, DWC3_GUCTL, reg);
if (DWC3_VER_IS_PRIOR(DWC3, 250A))
@@ -456,12 +455,9 @@ static void dwc3_ref_clk_period(struct dwc3 *dwc)
decr = 480000000 / rate;
reg = dwc3_readl(dwc, DWC3_GFLADJ);
- reg &= ~DWC3_GFLADJ_REFCLK_FLADJ_MASK
- & ~DWC3_GFLADJ_240MHZDECR
- & ~DWC3_GFLADJ_240MHZDECR_PLS1;
- reg |= FIELD_PREP(DWC3_GFLADJ_REFCLK_FLADJ_MASK, fladj)
- | FIELD_PREP(DWC3_GFLADJ_240MHZDECR, decr >> 1)
- | FIELD_PREP(DWC3_GFLADJ_240MHZDECR_PLS1, decr & 1);
+ FIELD_MODIFY(DWC3_GFLADJ_REFCLK_FLADJ_MASK, ®, fladj);
+ FIELD_MODIFY(DWC3_GFLADJ_240MHZDECR, ®, decr >> 1);
+ FIELD_MODIFY(DWC3_GFLADJ_240MHZDECR_PLS1, ®, decr & 1);
if (dwc->gfladj_refclk_lpm_sel)
reg |= DWC3_GFLADJ_REFCLK_LPM_SEL;
--
2.34.1
^ permalink raw reply related
* [PATCH 6/6] usb: typec: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 16:39 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, peter.griffin, andre.draszik, tudor.ambarus,
mathias.nyman, chunfeng.yun, matthias.bgg,
angelogioacchino.delregno, badhri, heikki.krogerus
Cc: linux-usb, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-mediatek, Hans Zhang
In-Reply-To: <20260430163919.47372-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/usb/typec/tcpm/tcpci.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index 0148b8f50412..24c87dfa6b64 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -141,13 +141,10 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum typec_cc_status cc)
}
if (vconn_pres) {
- if (polarity == TYPEC_POLARITY_CC2) {
- reg &= ~TCPC_ROLE_CTRL_CC1;
- reg |= FIELD_PREP(TCPC_ROLE_CTRL_CC1, TCPC_ROLE_CTRL_CC_OPEN);
- } else {
- reg &= ~TCPC_ROLE_CTRL_CC2;
- reg |= FIELD_PREP(TCPC_ROLE_CTRL_CC2, TCPC_ROLE_CTRL_CC_OPEN);
- }
+ if (polarity == TYPEC_POLARITY_CC2)
+ FIELD_MODIFY(TCPC_ROLE_CTRL_CC1, ®, TCPC_ROLE_CTRL_CC_OPEN);
+ else
+ FIELD_MODIFY(TCPC_ROLE_CTRL_CC2, ®, TCPC_ROLE_CTRL_CC_OPEN);
}
ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Arnaud POULIQUEN @ 2026-04-30 16:40 UTC (permalink / raw)
To: Beleswar Prasad Padhi, Mathieu Poirier
Cc: Shenwei Wang, Andrew Lunn, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <21de8440-adf7-454b-acfc-06e50882e075@ti.com>
On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> Hello Arnaud,
>
> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>> Hello,
>>
>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>
>>>> Hi Mathieu,
>>>>
>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>> GPIO driver
>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>> __u8 status;
>>>>>>>>>>> __u8 value;
>>>>>>>>>>> };
>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>
>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>>>>>>
>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>
>>>>>>>> Virtio uses two communication channels (virtqueues): one for requests and
>>>>>>> replies, and a second one for events.
>>>>>>>> In contrast, rpmsg provides only a single communication channel, so a
>>>>>>>> type field is required to distinguish between different kinds of messages.
>>>>>>>>
>>>>>>>> Since rpmsg replies and events share the same message format, an additional
>>>>>>> line is introduced to handle both cases.
>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
>>>>>>> uniquely identify the target controller.
>>>>>>>
>>>>>>> I have commented on this before - RPMSG is already providing multiplexing
>>>>>>> capability by way of endpoints. There is no need for a port field. One endpoint,
>>>>>>> one GPIO controller.
>>>>>>>
>>>>>> You still need a way to let the remote side know which port the endpoint maps to, either
>>>>>> by embedding the port information in the message (the current way), or by sending it
>>>>>> separately.
>>>>>>
>>>>> An endpoint is created with every namespace request. There should be
>>>>> one namespace request for every GPIO controller, which yields a unique
>>>>> endpoint for each controller and eliminates the need for an extra
>>>>> field to identify them.
>>>>
>>>>
>>>> Right, but this can still be done by just having one namespace request.
>>>> We can create new endpoints bound to an existing namespace/channel by
>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>> https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/
>>>>
>>>
>>> I will look at your suggestion (i.e link above) later this week or next week.
>>>
>>>> My mental model looks like this for the complete picture:
>>>>
>>>> 1. namespace/channel#1 = rpmsg-io
>>>> a. ept1 -> gpio-controller@1
>>>> b. ept2 -> gpio-controller@2
>>>>
>>>
>>> I've asked for one endpoint per GPIO controller since the very
>>> beginning. I don't yet have a strong opinion on whether to use one
>>> namespace request per GPIO controller or a single request that spins
>>> off multiple endpoints. I'll have to look at your link and reflect on
>>> that. Regardless of how we proceed on that front, multiplexing needs
>>> to happen at the endpoint level rather than the packet level. This is
>>> the only way this work can move forward.
>>>
>>
>> I would be more in favor of Mathieu’s proposal: “An endpoint is created with every namespace request.”
>>
>> If the endpoint is created only on the Linux side, how do we match the Linux endpoint address with the local port field on the remote side?
>
>
> Simply by sending a message to the remote containing the newly created
> endpoint and the port idx. Note that is this done just one time, after this
> Linux need not have the port field in the message everytime its sending
> a message.
>
>>
>> With a multi-namespace approach, the namespace could be rpmsg-io-[addr], where [addr] corresponds to the GPIO controller address in the DT. This would:
>
>
> You will face the same problem in this case also that you asked above:
> "how do we match the Linux endpoint address with the local port field
> on the remote side?"
Sorry I probably introduced confusion here
my sentence should be;
With a multi-namespace approach, the namespace could be rpmsg-io-[port],
where [port] corresponds to the GPIO controller port in the DT.
For instance:
rpmsg {
rpmsg-io {
#address-cells = <1>;
#size-cells = <0>;
gpio@25 {
compatible = "rpmsg-gpio";
reg = <25>;
gpio-controller;
#gpio-cells = <2>;
#interrupt-cells = <2>;
interrupt-controller;
};
gpio@32 {
compatible = "rpmsg-gpio";
reg = <32>;
gpio-controller;
#gpio-cells = <2>;
#interrupt-cells = <2>;
interrupt-controller;
};
};
};
rpmsg-io-25 would match with gpio@25
rpmsg-io-32 would match with gpio@32
>
> Because the endpoint that is created on a namespace request is also
> dynamic in nature. How will the remote know which endpoint addr
> Linux allocated for a namespace that it announced?
>
> As an example/PoC, I created a firmware example which announces
> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
> the other is a TI specific name service "ti.ipc4.ping-pong". You can
> see it created 2 different addresses (0x400 and 0x401) for each of
> the name service request from the same firmware:
>
> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel formed from src = 0x400 to dst = 0xe
> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new channel: 0x401 -> 0xd!
>
> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
> Back to same problem. Simple solution is to reply to remote with the
> created ept addr and the index.
That why I would like to suggest to use the name service field to
identify the port/controller, instead of the endpoint address.
>
>
>>
>> - match the RPMsg probe with the DT,
>
>
> We can probe from all controllers with a single name service
> announcement too.
>
>> - provide a simple mapping between the port and the endpoint on both sides,
>
>
> We are trying to get rid of this mapping from Linux side to adapt
> the gpio-virtio design.
>
>> - allow multiple endpoints on the remote side,
>
>
> We can support this as well with single nameservice model.
> There is no limitation. Remote has to send a message with
> its newly created ept that's all.
>
>> - provide a simple discovery mechanism for remote capabilities.
>
>
> A single announcement: "rpmsg-io" is also discovery mechanism.
>
> Feel free to let me know if you have concerns with any of the
> suggestions!
My only concern, whatever the solution, is that we find a smart
solution to associate the correct endpoint with the correct GPIO
port/controller defined in the DT.
I may have misunderstood your solution. Could you please help me
understand your proposal by explaining how you would handle three
GPIO ports defined in the DT, considering that the endpoint
addresses on the Linux side can be random?
If I assume there is a unique endpoint on the remote side,
I do not understand how you can match, on the firmware side,
the Linux endpoint address to the GPIO port.
Thanks and Regards,Arnaud
>
> Thanks,
> Beleswar
>
>>
>> Regards,
>> Arnaud
>>
>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>> a. ept1 -> i2c@1
>>>> b. ept2 -> i2c@2
>>>> c. ept3 -> i2c@3
>>>>
>>>> etc...
>>>>
>>>> This way device groups are isolated with each channel/namespace, and
>>>> instances within each device groups are also respected with specific
>>>> endpoints.
>>>>
>>>> Thanks,
>>>> Beleswar
>>>>
>>>
>>
^ permalink raw reply
* [PATCH 1/2] iommu/arm-smmu-qcom: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 16:45 UTC (permalink / raw)
To: will, robin.murphy, joro
Cc: iommu, linux-arm-msm, linux-kernel, linux-arm-kernel, Hans Zhang
In-Reply-To: <20260430164545.49637-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
index 65e0ef6539fe..99469c4ebac2 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
@@ -208,8 +208,7 @@ static phys_addr_t qcom_tbu_trigger_atos(struct arm_smmu_domain *smmu_domain,
/* Set address and stream-id */
val = readq_relaxed(tbu->base + DEBUG_SID_HALT_REG);
- val &= ~DEBUG_SID_HALT_SID;
- val |= FIELD_PREP(DEBUG_SID_HALT_SID, sid);
+ FIELD_MODIFY(DEBUG_SID_HALT_SID, &val, sid);
writeq_relaxed(val, tbu->base + DEBUG_SID_HALT_REG);
writeq_relaxed(iova, tbu->base + DEBUG_VA_ADDR_REG);
val = FIELD_PREP(DEBUG_AXUSER_CDMID, DEBUG_AXUSER_CDMID_VAL);
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] iommu/arm-smmu: Use FIELD_MODIFY() for bitfield operations
From: Hans Zhang @ 2026-04-30 16:45 UTC (permalink / raw)
To: will, robin.murphy, joro
Cc: iommu, linux-arm-msm, linux-kernel, linux-arm-kernel, Hans Zhang
Replace open-coded bitfield modifications with the standard FIELD_MODIFY()
macro. This improves code readability and adds type/range checking without
functional changes.
FIELD_MODIFY() internally performs the same mask-clear + set operation but
eliminates repetitive boilerplate.
---
Hi, If the Maintainers think it's not necessary, please ignore it.
---
Hans Zhang (2):
iommu/arm-smmu-qcom: Use FIELD_MODIFY()
iommu/arm-smmu-v3: Use FIELD_MODIFY()
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 5 ++---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
--
2.34.1
^ permalink raw reply
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