* Re: [PATCH] arm64: patching: replace min_t with min in __text_poke
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: Catalin Marinas, Thorsten Blum
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-kernel
In-Reply-To: <20260531220817.738904-2-thorsten.blum@linux.dev>
On Mon, 01 Jun 2026 00:08:16 +0200, Thorsten Blum wrote:
> Use the simpler min() macro since both values are unsigned and
> compatible.
>
>
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: patching: replace min_t with min in __text_poke
https://git.kernel.org/arm64/c/6c2ccb4979b2
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] perf/arm-cmn: Fix DVM node events
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: Robin Murphy
Cc: catalin.marinas, kernel-team, Will Deacon, mark.rutland,
linux-perf-users, linux-arm-kernel, stable
In-Reply-To: <1af20ba3fb35cc507e0d74408675b50340feca39.1780065225.git.robin.murphy@arm.com>
On Fri, 29 May 2026 15:33:45 +0100, Robin Murphy wrote:
> The new DVM node events added in CMN-700 also apply to CMN S3; fix
> the model encoding so that we can expose the aliases and handle
> occupancy filtering on newer CMNs too.
>
>
Applied to will (for-next/perf), thanks!
[1/1] perf/arm-cmn: Fix DVM node events
https://git.kernel.org/will/c/5936245125f7
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v4 00/20] arm64+KVM: FPSIMD/SVE/SME cleanups
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, Mark Rutland
Cc: catalin.marinas, kernel-team, Will Deacon, broonie, james.morse,
maz, oupton, stable, tabba, vladimir.murzin
In-Reply-To: <20260603110630.1027435-1-mark.rutland@arm.com>
On Wed, 03 Jun 2026 12:06:10 +0100, Mark Rutland wrote:
> This series cleans up low-level FPSIMD/SVE/SME state management code,
> making it easier to maintain and extend (e.g. adding SME support to
> KVM), and enabling better debugging (e.g. by making SVE/SME save/restore
> visible to KASAN and KCSAN).
>
> The first two patches fix a couple of latent issues that don't seem to
> have occurred in practice so far, but would be good to fix for stable to
> avoid any future issues. The rest of the series is purely cleanup.
>
> [...]
Applied to arm64 (for-next/fpsimd-cleanups), thanks!
[01/20] arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()
https://git.kernel.org/arm64/c/ae24f6b06e90
[02/20] arm64: fpsimd: Fix type mismatch in sme_{save,load}_state()
https://git.kernel.org/arm64/c/247bd1539050
[03/20] KVM: arm64: Don't include <asm/fpsimdmacros.h>
https://git.kernel.org/arm64/c/79e66bb7e8b4
[04/20] KVM: arm64: Don't override FFR save/restore argument
https://git.kernel.org/arm64/c/dc2337625880
[05/20] KVM: arm64: pkvm: Save host FPMR in host cpu context
https://git.kernel.org/arm64/c/da20bb4bc5e6
[06/20] KVM: arm64: pkvm: Remove struct cpu_sve_state
https://git.kernel.org/arm64/c/afd7af2b56ec
[07/20] arm64: fpsimd: Fold sve_init_regs() into do_sve_acc()
https://git.kernel.org/arm64/c/3efb6c7f22c6
[08/20] arm64: fpsimd: Remove sve_set_vq() and sme_set_vq()
https://git.kernel.org/arm64/c/e0cde2d2bb1b
[09/20] arm64: fpsimd: Use assembler for SVE instructions
https://git.kernel.org/arm64/c/f27fe9aa2d06
[10/20] arm64: fpsimd: Use assembler for baseline SME instructions
https://git.kernel.org/arm64/c/db9d63eafeba
[11/20] arm64: fpsimd: Move sve_get_vl() and sme_get_vl() inline
https://git.kernel.org/arm64/c/3f26d7c6544c
[12/20] arm64: sysreg: Add FPCR and FPSR
https://git.kernel.org/arm64/c/36a1d1726634
[13/20] arm64: fpsimd: Split FPSR/FPCR from SVE save/restore
https://git.kernel.org/arm64/c/1277531fca43
[14/20] arm64: fpsimd: Move fpsimd save/restore inline
https://git.kernel.org/arm64/c/890712d4507b
[15/20] arm64: fpsimd: Use opaque type for SVE state
https://git.kernel.org/arm64/c/e1b163e40553
[16/20] arm64: fpsimd: Use opaque type for SME state
https://git.kernel.org/arm64/c/eb1a68a00c0a
[17/20] arm64: fpsimd: Move SVE save/restore inline
https://git.kernel.org/arm64/c/2768101b3976
[18/20] arm64: fpsimd: Move sve_flush_live() inline
https://git.kernel.org/arm64/c/18618d9ea1fb
[19/20] arm64: fpsimd: Move SME save/restore inline
https://git.kernel.org/arm64/c/bfdfafd90720
[20/20] arm64: fpsimd: Remove <asm/fpsimdmacros.h>
https://git.kernel.org/arm64/c/987ec51e1841
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] arm64: Document SVE constraints on new hwcaps
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Shuah Khan, Mark Brown
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-doc,
linux-kernel
In-Reply-To: <20260522-arm64-elf-hwcaps-sve-cleanup-v1-1-07b0cedfc6fa@kernel.org>
On Fri, 22 May 2026 18:50:28 +0100, Mark Brown wrote:
> Two of the SVE hwcaps added for the SVE features in the 2025 dpISA did
> not explicitly call out their dependency on SVE in the ABI documentation.
> Do so.
>
> While we're here reorder the SVE and fature specific ID registers for
> HWCAP3_SVE_LUT6 which did have the SVE dependency but listed it second
> unlike the other SVE specific ID registers.
>
> [...]
Applied to arm64 (for-next/cpufeature), thanks!
[1/1] arm64: Document SVE constraints on new hwcaps
https://git.kernel.org/arm64/c/f20f8fe086b2
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH RFC v3 3/5] clk: zte: Introduce a driver for zx297520v3 top clocks and resets.
From: Stefan Dösinger @ 2026-06-03 20:49 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney, Philipp Zabel
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <99743c29fe81a90d3c1f51889d42ef9d4766de3c.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
Hi,
Thanks for the comments!
Am Mittwoch, 3. Juni 2026, 12:14:21 Ostafrikanische Zeit schrieb Philipp
Zabel:
> Is this delay long enough for all potential users of reset_control_reset()?
> Are there actually any at all?
You mean drivers that are in use on this SoC that call reset_control_reset?
Afaics not, they all call reset_assert/reset_deassert, or only ever deassert a
reset that is set on boot. It isn't called at runtime and the only driver
calling it that is in use on zx297520v3 is stmmac, which only calls it if
assert/deassert aren't available.
I implemented the reset() callback because other drivers had it and grabbed
the magic usleep(100) from ZTE's USB code. It looks like I should just /dev/
null it.
> I'd move the spinlock in here ...
>
> > ```
>
> + /* This is a special case used only by USB reset */
> + if (data->resets[id].wait_mask) {
> + return readl_poll_timeout(data->resets[id].reg + 4, val,
> + val & data-
>resets[id].wait_mask, 1, 100);
> ```
>
>
> ... because this might sleep.
Ack
> + return val & data->resets[id].mask;
> ```
>
>
> This will return a negative value for bit BIT(31), I'd wrap this with a
> double negation.
Sounds good
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v3 0/5] ZTE zx297520v3 clock bindings and driver
From: Stefan Dösinger @ 2026-06-03 20:49 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney, Philipp Zabel
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <5620a8969da87612a2d89578be656b5d00662635.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
Hi Philipp,
Am Mittwoch, 3. Juni 2026, 11:50:14 Ostafrikanische Zeit schrieben Sie:
> When there is no interaction required when operating the clk/reset
> bits, I prefer the reset driver sitting in drivers/reset as an aux
> device, especially when register access can be abstracted via a shared
> regmap. Some of the reset drivers under drivers/clk just predate the
> aux bus.
There are two interactions:
The register lock because all LSP and at least one TOP register contains both
clocks and resets.
Shared register definition: in the case of the LSP clocks breaking up the
composite definition would sacrifice readability.
Neither of them are insurmountable and I can certainly arrange a separation if
asked to - but my preference is to keep them together.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* [PATCH v1] EDAC/synopsys: Fix cleanup on injection sysfs failure
From: Yuho Choi @ 2026-06-03 20:47 UTC (permalink / raw)
To: Borislav Petkov, Tony Luck, Michal Simek
Cc: linux-edac, linux-arm-kernel, linux-kernel, Yuho Choi
edac_create_sysfs_attributes() creates inject_data_error before
inject_data_poison. If the second file creation fails, the first file is
left behind.
The same failure path runs after edac_mc_add_mc() has registered the
memory controller with the EDAC core. Jumping directly to edac_mc_free()
skips edac_mc_del_mc() and leaves the registered controller state
unwound incorrectly.
Remove inject_data_error when inject_data_poison creation fails, and
route the probe failure through edac_mc_del_mc() before freeing mci.
Fixes: 1a81361f75d8 ("EDAC, synopsys: Add Error Injection support for ZynqMP DDR controller")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
drivers/edac/synopsys_edac.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/synopsys_edac.c b/drivers/edac/synopsys_edac.c
index 51143b3257de..c395a1e97a36 100644
--- a/drivers/edac/synopsys_edac.c
+++ b/drivers/edac/synopsys_edac.c
@@ -1120,8 +1120,10 @@ static int edac_create_sysfs_attributes(struct mem_ctl_info *mci)
if (rc < 0)
return rc;
rc = device_create_file(&mci->dev, &dev_attr_inject_data_poison);
- if (rc < 0)
+ if (rc < 0) {
+ device_remove_file(&mci->dev, &dev_attr_inject_data_error);
return rc;
+ }
return 0;
}
@@ -1431,7 +1433,7 @@ static int mc_probe(struct platform_device *pdev)
if (rc) {
edac_printk(KERN_ERR, EDAC_MC,
"Failed to create sysfs entries\n");
- goto free_edac_mc;
+ goto del_mc;
}
}
@@ -1448,6 +1450,10 @@ static int mc_probe(struct platform_device *pdev)
return rc;
+#ifdef CONFIG_EDAC_DEBUG
+del_mc:
+ edac_mc_del_mc(&pdev->dev);
+#endif
free_edac_mc:
edac_mc_free(mci);
--
2.43.0
^ permalink raw reply related
* Re: (subset) [PATCH v1 0/6] power: Use named initializers for platform_device_id arrays
From: Sebastian Reichel @ 2026-06-03 20:46 UTC (permalink / raw)
To: Sebastian Reichel, Uwe Kleine-König (The Capable Hub)
Cc: Kuan-Wei Chiu, Benson Leung, Guenter Roeck, Thomas Weißschuh,
Krzysztof Kozlowski, Matthias Brugger, AngeloGioacchino Del Regno,
linux-pm, linux-kernel, chrome-platform, linux-arm-kernel,
linux-mediatek, Hans de Goede, Marek Szyprowski,
Sebastian Krzyszkowiak, Purism Kernel Team, Yixun Lan,
Andreas Kemnade, Matti Vaittinen, Sven Peter, Janne Grunau,
Neal Gompa, Amit Sunil Dhamne, Samuel Kayode, linux-riscv,
spacemit, asahi, imx, Chen-Yu Tsai
In-Reply-To: <cover.1780048925.git.u.kleine-koenig@baylibre.com>
On Fri, 29 May 2026 12:18:15 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> this series targets to use named initializers for platform_device_id
> arrays. In general these are better readable for humans and more robust
> to changes in the respective struct definition.
>
> This robustness is needed as I want to do
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -610,4 +610,7 @@ struct dmi_system_id {
> struct platform_device_id {
> char name[PLATFORM_NAME_SIZE];
> - kernel_ulong_t driver_data;
> + union {
> + kernel_ulong_t driver_data;
> + const void *driver_data_ptr;
> + };
> };
>
> [...]
Applied, thanks!
[1/6] power: Drop unused assignment of platform_device_id driver data
commit: 75a0e1e0b86078687c3c6a05107a98c7e59a65a8
[2/6] power: supply: max14577: Drop driver data in of and platform device id arrays
commit: 37258ad1f3a52ea442c32b3c92ad7146e74050c7
[4/6] power: Use named initializers for platform_device_id arrays
commit: e28f7498dd819878b8acacb89c4c073a646feea0
[5/6] power: supply: mt6360_charger: Use of match table unconditionally
commit: eb7ed650e5960fc303130704d1e29d18a7d0e1df
[6/6] power: Unify code style for platform_device_id arrays
commit: e3f669bed32287ae72c05a4ddab4a6687b0e62ca
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* Re: [PATCH v8 11/12] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Daniel Mentz @ 2026-06-03 20:28 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <20260601215909.3958732-12-praan@google.com>
On Mon, Jun 1, 2026 at 2:59 PM Pranjal Shrivastava <praan@google.com> wrote:
> @@ -2361,8 +2394,33 @@ static irqreturn_t arm_smmu_handle_gerror(struct arm_smmu_device *smmu)
> static irqreturn_t arm_smmu_gerror_handler(int irq, void *dev)
> {
> struct arm_smmu_device *smmu = dev;
> + irqreturn_t ret;
> +
> + /*
> + * Global Errors are only processed if the SMMU is active.
> + *
> + * If the STOP_FLAG is set (can_elide == true), the hardware is
> + * either already disabled or in the process of being disabled.
> + * Any errors captured during the quiesce/drain phase will be
> + * handled by the explicit arm_smmu_handle_gerror() call at the
> + * end of arm_smmu_runtime_suspend() callback. On resume, the
> + * STOP_FLAG is cleared before interrupts are re-enabled, ensuring
> + * no valid errors are missed.
> + *
> + * A lockless check is favoured here over a dynamic PM core check
> + * since the runtime_pm_get_if_active would return false during
> + * transient states like RPM_RESUMING & ignore level-triggered
> + * interrupts.
> + */
> + if (arm_smmu_cmdq_can_elide(smmu)) {
> + dev_err(smmu->dev,
> + "Ignoring gerror interrupt because the SMMU is suspended\n");
> + return IRQ_NONE;
> + }
Have you considered using arm_smmu_rpm_get() here instead?
I can see two issues with the currenlty proposal:
* Returning IRQ_NONE when an interrupt is indeed active and needs to
be handled. This might be interpreted as a spurious interrupt
* Nothing is preventing the suspend handler from running while
arm_smmu_gerror_handler is in the middle of handling an interrupt
I understand that using arm_smmu_rpm_get() also has downsides,
including an unnecessary resume operation when the SMMU is already in
RPM_SUSPENDING state. However, using arm_smmu_rpm_get() would make it
easier to ensure correctness.
> +
> + ret = arm_smmu_handle_gerror(smmu);
>
> - return arm_smmu_handle_gerror(smmu);
> + return ret;
> }
^ permalink raw reply
* Re: [PATCH 0/2] drivers/perf: hisi: Updates for HiSilicon uncore PMUs
From: Will Deacon @ 2026-06-03 19:57 UTC (permalink / raw)
To: Yushan Wang
Cc: mark.rutland, robin.murphy, linux-arm-kernel, linux-kernel,
fanghao11, linuxarm, liuyonglong, prime.zeng, wangzhou1
In-Reply-To: <001403a3-513a-4c17-b2ec-2beafbf221fd@huawei.com>
On Tue, May 19, 2026 at 04:42:32PM +0800, Yushan Wang wrote:
> Hi all, a gentle ping on this.
>
> All comments are welcomed
Sashiko has a few (some of which are bogus):
https://sashiko.dev/#/patchset/20260423152959.1458563-1-wangyushan12@huawei.com
Will
^ permalink raw reply
* Re: [PATCH] char: xilinx_hwicap: replace in_be32/out_be32 with ioread32be/iowrite32be
From: Rosen Penev @ 2026-06-03 19:52 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel, Arnd Bergmann, chleroy, Greg Kroah-Hartman,
moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <878fd338-b4d0-4e46-987c-5a0ee52989dc@amd.com>
On Mon, Jun 1, 2026 at 11:22 PM Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 6/2/26 05:57, Rosen Penev wrote:
> > Mechanical conversion of the ppc4xx-specific accessors to the generic
> > portable helpers.
> >
> > As a result, COMPILE_TEST is added for extra compile coverage.
> >
> > Assisted-by: opencode:big-pickle
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> > drivers/char/Kconfig | 2 +-
> > drivers/char/xilinx_hwicap/buffer_icap.c | 16 +++++------
> > drivers/char/xilinx_hwicap/fifo_icap.c | 34 +++++++++++-------------
> > 3 files changed, 24 insertions(+), 28 deletions(-)
>
> I don't really mind about this because I think that we can also remove the whole
> driver.
I looked into this. The problem here is that there are actual users
arch/microblaze/boot/dts/system.dts
and
arch/mips/boot/dts/xilfpga/nexys4ddr.dts
> Thanks,
> Michal
^ permalink raw reply
* [PATCH 2/2] crypto: atmel-ecc - clean up and improve ECDH comments
From: Thorsten Blum @ 2026-06-03 19:27 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260603192708.1237715-4-thorsten.blum@linux.dev>
Improve the kerneldoc for struct atmel_ecdh_ctx by removing the stale
"unsupported curves" wording, since the device only supports a single
curve (P-256), and move the set_secret() constraint to the description.
In atmel_ecdh_set_secret(), clarify that the device generates the
private key, and drop the redundant "only supports NIST P256" comment.
In atmel_ecdh_done() and atmel_ecdh_generate_public_key(), clarify the
truncation comments. Also note that a P-256 public key consists of two
32-byte coordinates in atmel_ecdh_compute_shared_secret(), and remove
the unnecessary fall-through comment and other redundant comments.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-ecc.c | 37 ++++++++++++++-----------------------
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 9387eea4513d..1443e18a9cee 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -27,15 +27,15 @@ static struct atmel_ecc_driver_data driver_data;
/**
* struct atmel_ecdh_ctx - transformation context
- * @client : pointer to i2c client device
- * @fallback : used for unsupported curves or when user wants to use its own
- * private key.
- * @public_key : generated when calling set_secret(). It's the responsibility
- * of the user to not call set_secret() while
- * generate_public_key() or compute_shared_secret() are in flight.
+ * @client : I2C client device
+ * @fallback : ECDH fallback used for caller-provided private keys
+ * @public_key : cached public key corresponding to the device-generated
+ * private key
* @curve_id : elliptic curve id
- * @do_fallback: true when the device doesn't support the curve or when the user
- * wants to use its own private key.
+ * @do_fallback: true when ECDH operations should use @fallback
+ *
+ * The caller must not invoke set_secret() while generate_public_key()
+ * or compute_shared_secret() are in flight.
*/
struct atmel_ecdh_ctx {
struct i2c_client *client;
@@ -55,7 +55,7 @@ static void atmel_ecdh_done(struct atmel_i2c_work_data *work_data, void *areq,
if (status)
goto free_work_data;
- /* might want less than we've got */
+ /* copy only as much as requested, capped at 32 bytes */
n_sz = min(ATMEL_ECC_NIST_P256_N_SIZE, req->dst_len);
/* copy the shared secret */
@@ -64,15 +64,15 @@ static void atmel_ecdh_done(struct atmel_i2c_work_data *work_data, void *areq,
if (copied != n_sz)
status = -EINVAL;
- /* fall through */
free_work_data:
kfree_sensitive(work_data);
kpp_request_complete(req, status);
}
/*
- * A random private key is generated and stored in the device. The device
- * returns the pair public key.
+ * If no private key is provided, generate one in the device and cache
+ * the corresponding public key. The generated private key never leaves
+ * the device.
*/
static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
unsigned int len)
@@ -83,9 +83,7 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
struct ecdh params;
int ret = -ENOMEM;
- /* free the old public key, if any */
kfree(ctx->public_key);
- /* make sure you don't free the old public key twice */
ctx->public_key = NULL;
if (crypto_ecdh_decode_key(buf, len, ¶ms) < 0) {
@@ -94,7 +92,6 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
}
if (params.key_size) {
- /* fallback to ecdh software implementation */
ctx->do_fallback = true;
return crypto_kpp_set_secret(ctx->fallback, buf, len);
}
@@ -103,11 +100,6 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
if (!cmd)
return -ENOMEM;
- /*
- * The device only supports NIST P256 ECC keys. The public key size will
- * always be the same. Use a macro for the key size to avoid unnecessary
- * computations.
- */
public_key = kmalloc(ATMEL_ECC_PUBKEY_SIZE, GFP_KERNEL);
if (!public_key)
goto free_cmd;
@@ -120,7 +112,6 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
if (ret)
goto free_public_key;
- /* save the public key */
memcpy(public_key, &cmd->data[RSP_DATA_IDX], ATMEL_ECC_PUBKEY_SIZE);
ctx->public_key = public_key;
@@ -149,7 +140,7 @@ static int atmel_ecdh_generate_public_key(struct kpp_request *req)
if (!ctx->public_key)
return -EINVAL;
- /* might want less than we've got */
+ /* copy only as much as requested, capped at 64 bytes */
nbytes = min(ATMEL_ECC_PUBKEY_SIZE, req->dst_len);
/* public key was saved at private key generation */
@@ -175,7 +166,7 @@ static int atmel_ecdh_compute_shared_secret(struct kpp_request *req)
return crypto_kpp_compute_shared_secret(req);
}
- /* must have exactly two points to be on the curve */
+ /* A P-256 public key must contain two 32-byte coordinates */
if (req->src_len != ATMEL_ECC_PUBKEY_SIZE)
return -EINVAL;
^ permalink raw reply related
* [PATCH 1/2] crypto: atmel-i2c - improve comment in atmel_i2c_init_ecdh_cmd
From: Thorsten Blum @ 2026-06-03 19:27 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: Thorsten Blum, linux-crypto, linux-arm-kernel, linux-kernel
Clarify that a P-256 public key is encoded as two 32-byte coordinates.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-i2c.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/atmel-i2c.c b/drivers/crypto/atmel-i2c.c
index ff19857894d0..24bded47a32b 100644
--- a/drivers/crypto/atmel-i2c.c
+++ b/drivers/crypto/atmel-i2c.c
@@ -138,9 +138,8 @@ int atmel_i2c_init_ecdh_cmd(struct atmel_i2c_cmd *cmd,
cmd->param2 = cpu_to_le16(DATA_SLOT_2);
/*
- * The device only supports NIST P256 ECC keys. The public key size will
- * always be the same. Use a macro for the key size to avoid unnecessary
- * computations.
+ * The device only supports P-256. Its public key is encoded as
+ * two 32-byte coordinates.
*/
copied = sg_copy_to_buffer(pubkey,
sg_nents_for_len(pubkey,
^ permalink raw reply related
* [PATCH v6 0/3] arm64: dts/bindings: Add support for BeagleBadge
From: Judith Mendez @ 2026-06-03 19:23 UTC (permalink / raw)
To: Judith Mendez, Nishanth Menon, Vignesh Raghavendra
Cc: Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel, Andrew Davis,
Bryan Brattlof, Jason Kridner, Robert Nelson, Conor Dooley
Hi,
BeagleBoard.org BeagleBadge[1] is a compact, affordable open source
hardware [2] single board computer based on the Texas Instruments AM62L3
SoC designed for IoT and embedded applications. Add base support for
the same.
SD boot:
Link: https://gist.github.com/jmenti/e9e95848336fda0e4b5acb37f2fe64a0
This patch series adds:
- Device tree bindings update for am62l3-badge
- Device tree source for BeagleBadge board
- Defconfig: drivers for BeagleBadge
Changelog since v5:
DTS
- Fixed aliases/chosen nodes
- Sort Makefile items alphabetically
- Use dual license: GPL-2.0-only or MIT
v5
Link: https://lore.kernel.org/all/20260526235417.1326187-1-jm@ti.com/
v4
Link: https://lore.kernel.org/all/20260515153541.294698-1-jm@ti.com/
v3
Link: https://lore.kernel.org/all/20260513233447.2713737-1-jm@ti.com/
V2
Link: https://lore.kernel.org/all/20260508230341.1891450-1-jm@ti.com/
V1
Link: https://lore.kernel.org/all/20260501233148.4180391-1-jm@ti.com/
Patch series depends on:
Link: https://lore.kernel.org/all/20260513231154.2703292-1-jm@ti.com/
[1] https://www.beagleboard.org/boards/beaglebadge
[2] https://github.com/beagleboard/BeagleBadge/blob/main/design/BeagleBadge_RevA_V0.7_SCH_251107.pdf
Judith Mendez (3):
dt-bindings: arm: ti: Add am62l3-beaglebadge
arm64: dts: ti: Add k3-am62l3-beaglebadge
arm64: defconfig: Enable drivers for BeagleBadge
.../devicetree/bindings/arm/ti/k3.yaml | 1 +
arch/arm64/boot/dts/ti/Makefile | 1 +
.../boot/dts/ti/k3-am62l3-beaglebadge.dts | 657 ++++++++++++++++++
arch/arm64/configs/defconfig | 5 +
4 files changed, 664 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
--
2.54.0
^ permalink raw reply
* [PATCH v6 1/3] dt-bindings: arm: ti: Add am62l3-beaglebadge
From: Judith Mendez @ 2026-06-03 19:23 UTC (permalink / raw)
To: Judith Mendez, Nishanth Menon, Vignesh Raghavendra
Cc: Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel, Andrew Davis,
Bryan Brattlof, Jason Kridner, Robert Nelson, Conor Dooley
In-Reply-To: <20260603192305.1347908-1-jm@ti.com>
This board is based on ti,am62l3.
https://www.beagleboard.org/boards/beaglebadge
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes since v5:
- No change
---
Documentation/devicetree/bindings/arm/ti/k3.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 2a6a9441c23de..d9cd3fb712fdd 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -40,6 +40,7 @@ properties:
- description: K3 AM62L3 SoC and Boards
items:
- enum:
+ - beagle,am62l3-beaglebadge
- ti,am62l3-evm
- const: ti,am62l3
--
2.54.0
^ permalink raw reply related
* [PATCH v6 2/3] arm64: dts: ti: Add k3-am62l3-beaglebadge
From: Judith Mendez @ 2026-06-03 19:23 UTC (permalink / raw)
To: Judith Mendez, Nishanth Menon, Vignesh Raghavendra
Cc: Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel, Andrew Davis,
Bryan Brattlof, Jason Kridner, Robert Nelson, Conor Dooley
In-Reply-To: <20260603192305.1347908-1-jm@ti.com>
BeagleBoard.org BeagleBadge is a compact, affordable open source
hardware single board computer based on the Texas Instruments AM62L3
SoC designed for IoT and embedded applications with low power
consumption. Expansion is provided over open standards based headers
including QWIIC and GPIO interfaces.
https://www.beagleboard.org/boards/beaglebadge
Co-developed-by: Andrew Davis <afd@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
Changes since v5:
- Fixed aliases/chosen nodes
- Sort Makefile items alphabetically
- Use dual license: GPL-2.0-only or MIT
---
arch/arm64/boot/dts/ti/Makefile | 1 +
.../boot/dts/ti/k3-am62l3-beaglebadge.dts | 657 ++++++++++++++++++
2 files changed, 658 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 5269c9619b65c..3f1904a5b622f 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -40,6 +40,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62a7-phyboard-lyra-rdk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am62d2-evm.dtb
# Boards with AM62Lx SoCs
+dtb-$(CONFIG_ARCH_K3) += k3-am62l3-beaglebadge.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am62l3-evm.dtb
# Boards with AM62Px SoC
diff --git a/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts b/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
new file mode 100644
index 0000000000000..ee2d562baf51a
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
@@ -0,0 +1,657 @@
+// SPDX-License-Identifier: GPL-2.0-only or MIT
+/*
+ * https://www.beagleboard.org/boards/beaglebadge
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include "k3-am62l3.dtsi"
+#include "k3-pinctrl.h"
+
+/ {
+ compatible = "beagle,am62l3-beaglebadge", "ti,am62l3";
+ model = "BeagleBoard.org BeagleBadge";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c4 = &wkup_i2c0;
+ mmc1 = &sdhci1;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ };
+
+ memory@80000000 {
+ /* 256MB */
+ reg = <0x00000000 0x80000000 0x00000000 0x10000000>;
+ device_type = "memory";
+ bootph-all;
+ };
+
+ thermal-zones {
+ wkup0-thermal {
+ polling-delay-passive = <250>; /* milliSeconds */
+ polling-delay = <500>; /* milliSeconds */
+ thermal-sensors = <&vtm0 0>;
+
+ trips {
+ crit0 {
+ temperature = <125000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
+ gpio_keys: gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ button-select {
+ label = "SELECT";
+ linux,code = <KEY_SELECT>;
+ gpios = <&gpio0 26 GPIO_ACTIVE_LOW>;
+ };
+
+ button-back {
+ label = "BACK";
+ linux,code = <KEY_BACK>;
+ gpios = <&gpio0 104 GPIO_ACTIVE_LOW>;
+ };
+
+ button-up {
+ label = "UP";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio0 32 GPIO_ACTIVE_LOW>;
+ };
+
+ button-down {
+ label = "DOWN";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio0 42 GPIO_ACTIVE_LOW>;
+ };
+
+ button-left {
+ label = "LEFT";
+ linux,code = <KEY_LEFT>;
+ gpios = <&gpio0 31 GPIO_ACTIVE_LOW>;
+ };
+
+ button-right {
+ label = "RIGHT";
+ linux,code = <KEY_RIGHT>;
+ gpios = <&gpio0 95 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ multicolor-led {
+ compatible = "pwm-leds-multicolor";
+
+ multi-led {
+ color = <LED_COLOR_ID_RGB>;
+ max-brightness = <255>;
+
+ led-red {
+ pwms = <&ecap2 0 10000000 0>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led-green {
+ pwms = <&ecap1 0 10000000 0>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led-blue {
+ pwms = <&epwm1 1 10000000 0>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+
+ seven-segment-left {
+ compatible = "gpio-7-segment";
+ segment-gpios = <&mcp23s18 0 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 1 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 2 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 3 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 4 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 5 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 6 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 7 GPIO_ACTIVE_LOW>;
+ };
+
+ seven-segment-right {
+ compatible = "gpio-7-segment";
+ segment-gpios = <&mcp23s18 8 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 9 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 10 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 11 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 12 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 13 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 14 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 15 GPIO_ACTIVE_LOW>;
+ };
+
+ pwm-beeper {
+ compatible = "pwm-beeper";
+ pwms = <&epwm0 1 1000000 0>;
+ amp-supply = <&sensor_3v3>;
+ };
+
+ vsys_out: regulator-0 {
+ /* output of BQ24070 */
+ compatible = "regulator-fixed";
+ regulator-name = "VSYS_OUT";
+ regulator-min-microvolt = <4400000>;
+ regulator-max-microvolt = <4400000>;
+ regulator-always-on;
+ regulator-boot-on;
+ bootph-all;
+ };
+
+ vcc_3v3_main: regulator-1 {
+ /* output of TPS62A06 */
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_MAIN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys_out>;
+ regulator-always-on;
+ regulator-boot-on;
+ bootph-all;
+ };
+
+ vdd_3v3: regulator-2 {
+ /* output of TPS22965 */
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_3v3_main>;
+ regulator-always-on;
+ regulator-boot-on;
+ bootph-all;
+ };
+
+ vdd_3v3_sd: regulator-3 {
+ /* TPS22918DBVR */
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_3V3_SD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-boot-on;
+ enable-active-high;
+ gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vdd_3v3_sd_ena_pins_default>;
+ bootph-all;
+ };
+
+ sensor_3v3: regulator-4 {
+ /* TPS22918DBVR */
+ compatible = "regulator-fixed";
+ regulator-name = "Sensor_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-boot-on;
+ enable-active-high;
+ gpios = <&wkup_gpio0 1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sensor_3v3_ena_pins_default>;
+ bootph-all;
+ };
+};
+
+&pmx0 {
+ uart0_pins_default: uart0-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01b8, PIN_OUTPUT, 0) /* (C13) UART0_TXD */
+ AM62LX_IOPAD(0x01b4, PIN_INPUT, 0) /* (D13) UART0_RXD */
+ >;
+ bootph-all;
+ };
+
+ uart0_pins_wakeup: uart0-wakeup-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01b8, PIN_OUTPUT, 0) /* (C13) UART0_TXD */
+ AM62LX_IOPAD(0x01b4, PIN_INPUT | PIN_WKUP_EN, 0) /* (D13) UART0_RXD */
+ >;
+ bootph-all;
+ };
+
+ uart1_pins_default: uart1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x019c, PIN_OUTPUT, 2) /* (A12) MCASP0_ACLKR.UART1_TXD */
+ AM62LX_IOPAD(0x0198, PIN_INPUT, 2) /* (C11) MCASP0_AFSR.UART1_RXD */
+ AM62LX_IOPAD(0x0180, PIN_INPUT, 2) /* (A8) MCASP0_AXR3.UART1_CTSn */
+ AM62LX_IOPAD(0x0184, PIN_OUTPUT, 2) /* (B10) MCASP0_AXR2.UART1_RTSn */
+ >;
+ bootph-all;
+ };
+
+ usr_button_pins_default: usr-button-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00a4, PIN_INPUT, 7) /* (H18) GPMC0_AD11.GPIO0_26 */
+ AM62LX_IOPAD(0x01e4, PIN_INPUT, 7) /* (D16) EXT_REFCLK1.GPIO0_104 */
+ AM62LX_IOPAD(0x00c0, PIN_INPUT, 7) /* (N19) GPMC0_ADVn_ALE.GPIO0_32 */
+ AM62LX_IOPAD(0x00e8, PIN_INPUT, 7) /* (L19) GPMC0_CSn1.GPIO0_42 */
+ AM62LX_IOPAD(0x00b8, PIN_INPUT, 7) /* (L21) GPMC0_CLK.GPIO0_31 */
+ AM62LX_IOPAD(0x01c0, PIN_INPUT, 7) /* (B13) UART0_RTSn.GPIO0_95 */
+ >;
+ bootph-all;
+ };
+
+ i2c0_pins_default: i2c0-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01cc, PIN_INPUT_PULLUP, 0) /* (B7) I2C0_SCL */
+ AM62LX_IOPAD(0x01d0, PIN_INPUT_PULLUP, 0) /* (A7) I2C0_SDA */
+ >;
+ bootph-all;
+ };
+
+ i2c1_pins_default: i2c1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01d4, PIN_INPUT_PULLUP, 0) /* (D7) I2C1_SCL */
+ AM62LX_IOPAD(0x01d8, PIN_INPUT_PULLUP, 0) /* (A6) I2C1_SDA */
+ >;
+ bootph-all;
+ };
+
+ i2c2_qwiic_pins_default: i2c2-qwiic-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01dc, PIN_INPUT_PULLUP, 0) /* (B8) I2C2_SCL */
+ AM62LX_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D8) I2C2_SDA */
+ >;
+ bootph-all;
+ };
+
+ vdd_3v3_sd_ena_pins_default: vdd-3v3-sd-ena-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x07c, PIN_OUTPUT, 7) /* (L23) GPMC0_AD1.GPIO0_16 */
+ >;
+ bootph-all;
+ };
+
+ sensor_3v3_ena_pins_default: sensor-3v3-ena-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x004, PIN_OUTPUT, 7) /* (AA23) WKUP_UART0_TXD.WKUP_GPIO0_1 */
+ >;
+ bootph-all;
+ };
+
+ mmc1_pins_default: mmc1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0230, PIN_INPUT, 0) /* (Y3) MMC1_CMD */
+ AM62LX_IOPAD(0x0228, PIN_OUTPUT, 0) /* (Y2) MMC1_CLK */
+ AM62LX_IOPAD(0x0224, PIN_INPUT, 0) /* (AA1) MMC1_DAT0 */
+ AM62LX_IOPAD(0x0220, PIN_INPUT, 0) /* (Y4) MMC1_DAT1 */
+ AM62LX_IOPAD(0x021c, PIN_INPUT, 0) /* (AA2) MMC1_DAT2 */
+ AM62LX_IOPAD(0x0218, PIN_INPUT, 0) /* (AB2) MMC1_DAT3 */
+ AM62LX_IOPAD(0x0234, PIN_INPUT, 7) /* (B6) MMC1_SDCD.GPIO0_122 */
+ >;
+ bootph-all;
+ };
+
+ usb1_pins_default: usb1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0248, PIN_INPUT | PIN_DS_PULLUD_ENABLE |
+ PIN_DS_PULL_UP, 0) /* (A5) USB1_DRVVBUS */
+ >;
+ bootph-all;
+ };
+
+ pwm_beeper_pins_default: pwm-beeper-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00b0, PIN_OUTPUT, 4) /* (F22) GPMC0_AD14.EHRPWM0_B */
+ >;
+ };
+
+ pmic_irq_pins_default: pmic-irq-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01e8, PIN_INPUT, 0) /* (C8) EXTINTn */
+ >;
+ bootph-all;
+ };
+
+ wkup_i2c0_pins_default: wkup-i2c0-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0010, PIN_INPUT_PULLUP, 0) /* (AB22) WKUP_I2C0_SCL */
+ AM62LX_IOPAD(0x0014, PIN_INPUT_PULLUP, 0) /* (AA22) WKUP_I2C0_SDA */
+ >;
+ bootph-all;
+ };
+
+ rgb_led_ecap2_pins_default: rgb-led-ecap2-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0190, PIN_OUTPUT, 2) /* (A11) MCASP0_ACLKX.ECAP2_IN_APWM_OUT */
+ >;
+ };
+
+ rgb_led_ecap1_pins_default: rgb-led-ecap1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0188, PIN_OUTPUT, 2) /* (A9) MCASP0_AXR1.ECAP1_IN_APWM_OUT */
+ >;
+ };
+
+ rgb_led_epwm1_pins_default: rgb-led-epwm1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x018c, PIN_OUTPUT, 5) /* (B9) MCASP0_AXR0.EHRPWM1_B */
+ >;
+ };
+
+ spi1_pins_default: spi1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x008c, PIN_OUTPUT, 4) /* (H22) GPMC0_AD5.SPI1_CLK */
+ AM62LX_IOPAD(0x0088, PIN_OUTPUT, 4) /* (K23) GPMC0_AD4.SPI1_CS0 */
+ AM62LX_IOPAD(0x0080, PIN_INPUT, 4) /* (K22) GPMC0_AD2.SPI1_D0 */
+ AM62LX_IOPAD(0x0084, PIN_OUTPUT, 4) /* (J23) GPMC0_AD3.SPI1_D1 */
+ >;
+ bootph-all;
+ };
+
+ spi3_pins_default: spi3-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00d0, PIN_OUTPUT, 5) /* (P22) GPMC0_BE1n.SPI3_CLK */
+ AM62LX_IOPAD(0x00cc, PIN_OUTPUT, 5) /* (P23) GPMC0_BE0n_CLE.SPI3_CS0 */
+ AM62LX_IOPAD(0x00d4, PIN_INPUT, 5) /* (N23) GPMC0_WAIT0.SPI3_D0 */
+ AM62LX_IOPAD(0x00d8, PIN_OUTPUT, 5) /* (N22) GPMC0_WAIT1.SPI3_D1 */
+ >;
+ };
+
+ mcp23s18_reset_pins_default: mcp23s18-reset-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00a0, PIN_OUTPUT, 7) /* (H21) GPMC0_AD10.GPIO0_25 */
+ >;
+ };
+
+ epwm2_pins_default: epwm2-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00c4, PIN_OUTPUT, 4) /* (N20) GPMC0_OEn_REn.EHRPWM2_A */
+ >;
+ };
+
+ lora_control_pins_default: lora-control-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00c8, PIN_OUTPUT, 7) /* (M19) GPMC0_WEn.GPIO0_34 */
+ AM62LX_IOPAD(0x00e4, PIN_OUTPUT, 7) /* (L20) GPMC0_CSn0.GPIO0_41 */
+ AM62LX_IOPAD(0x01a4, PIN_INPUT, 7) /* (D11) SPI0_CS1.GPIO0_88 */
+ AM62LX_IOPAD(0x01bc, PIN_INPUT, 7) /* (B14) UART0_CTSn.GPIO0_94 */
+ >;
+ bootph-all;
+ };
+
+ gpio0_pins_default: gpio0-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0078, PIN_OUTPUT, 7) /* (L22) GPMC0_AD0.GPIO0_15 */
+ AM62LX_IOPAD(0x00e0, PIN_INPUT, 7) /* (M21) GPMC0_DIR.GPIO0_40 */
+ AM62LX_IOPAD(0x00ec, PIN_OUTPUT, 7) /* (M23) GPMC0_CSn2.GPIO0_43 */
+ AM62LX_IOPAD(0x00f0, PIN_INPUT, 7) /* (M22) GPMC0_CSn3.GPIO0_44 */
+ AM62LX_IOPAD(0x0194, PIN_OUTPUT, 7) /* (B11) MCASP0_AFSX.GPIO0_84 */
+ >;
+ bootph-all;
+ };
+};
+
+&uart0 {
+ wakeup-source;
+ pinctrl-0 = <&uart0_pins_default>;
+ pinctrl-1 = <&uart0_pins_wakeup>;
+ pinctrl-names = "default", "wakeup";
+ bootph-all;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_default>;
+ bootph-all;
+ status = "okay";
+
+ /* T&H Sensor */
+ th-sensor@44 {
+ compatible = "sensirion,sht4x";
+ reg = <0x44>;
+ };
+
+ /* EEPROM */
+ eeprom@50 {
+ /* FT24C32A-ELRT */
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
+
+ /* Fuel Gauge */
+ fuel-gauge@55 {
+ compatible = "ti,bq27541";
+ reg = <0x55>;
+ };
+
+ /* IMU Sensor */
+ accelerometer@6a {
+ compatible = "st,lsm6ds3tr-c";
+ reg = <0x6a>;
+ vdd-supply = <&vcc_3v3_main>;
+ vddio-supply = <&vcc_3v3_main>;
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_qwiic_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&wkup_i2c0 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_i2c0_pins_default>;
+ bootph-all;
+ status = "okay";
+
+ tps65214: pmic@30 {
+ compatible = "ti,tps65214";
+ reg = <0x30>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+ buck1-supply = <&vcc_3v3_main>;
+ buck2-supply = <&vcc_3v3_main>;
+ buck3-supply = <&vcc_3v3_main>;
+ ldo1-supply = <&vcc_3v3_main>;
+ ldo2-supply = <&vcc_3v3_main>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_irq_pins_default>;
+ ti,power-button;
+ bootph-all;
+
+ regulators {
+ buck1_reg: buck1 {
+ regulator-name = "VDD_CORE";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck2_reg: buck2 {
+ regulator-name = "VDD_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck3_reg: buck3 {
+ regulator-name = "VDD_LPDDR4";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = "VDDA_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = "PMIC_VDD_RTC";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+};
+
+&gpio0 {
+ gpio-line-names = "","","","","","","","","","", /* 0-9 */
+ "","","","","","BOOST_5V_ENA","VDD_3V3_SD_ENA","","","", /* 10-19 */
+ "","","","","","MCP23S18_RESET","BTN_SELECT","","","", /* 20-29 */
+ "","BTN_LEFT","BTN_UP","","LORA_RESET","","","","","", /* 30-39 */
+ "GAUGE_BATLOW","LORA_RFSW","BTN_DOWN","USB_RST","MBUS_INT","","","","","", /* 40-49 */
+ "","WLAN_EN","","","","","","","","", /* 50-59 */
+ "","","","","","","","","","", /* 60-69 */
+ "","","","","","","","","","", /* 70-79 */
+ "","","","","MBUS_RST","","","","LORA_BUSY","", /* 80-89 */
+ "","","","","LORA_DIO","BTN_RIGHT","","","","", /* 90-99 */
+ "","","","","BTN_BACK","","","","","", /* 100-109 */
+ "","","","","","","","","","", /* 110-119 */
+ "","","SD_CD","","",""; /* 120-125 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio0_pins_default>, <&usr_button_pins_default>, <&lora_control_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&wkup_gpio0 {
+ gpio-line-names = "","SENSOR_3V3_ENA","","","","","",""; /* 0-7 */
+ bootph-all;
+ status = "okay";
+};
+
+&sdhci1 {
+ /* SD/MMC */
+ vmmc-supply = <&vdd_3v3_sd>;
+ disable-wp;
+ cd-gpios = <&gpio0 122 GPIO_ACTIVE_LOW>;
+ cd-debounce-delay-ms = <100>;
+ ti,fails-without-test-cd;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&epwm0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_beeper_pins_default>;
+ status = "okay";
+};
+
+&epwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgb_led_epwm1_pins_default>;
+ status = "okay";
+};
+
+&epwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&epwm2_pins_default>;
+ status = "okay";
+};
+
+&ecap1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgb_led_ecap1_pins_default>;
+ status = "okay";
+};
+
+&ecap2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgb_led_ecap2_pins_default>;
+ status = "okay";
+};
+
+&usbss0 {
+ ti,vbus-divider;
+ status = "okay";
+};
+
+&usb0 {
+ usb-role-switch;
+ bootph-all;
+ status = "okay";
+};
+
+&usbss1 {
+ ti,vbus-divider;
+ bootph-all;
+ status = "okay";
+};
+
+&usb1 {
+ dr_mode = "host";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&spi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins_default>;
+ status = "okay";
+
+ mcp23s18: gpio@0 {
+ compatible = "microchip,mcp23s18";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ reset-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcp23s18_reset_pins_default>;
+ microchip,spi-present-mask = /bits/ 8 <0x01>;
+ };
+};
+
+&spi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi3_pins_default>;
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v6 3/3] arm64: defconfig: Enable drivers for BeagleBadge
From: Judith Mendez @ 2026-06-03 19:23 UTC (permalink / raw)
To: Judith Mendez, Nishanth Menon, Vignesh Raghavendra
Cc: Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel, Andrew Davis,
Bryan Brattlof, Jason Kridner, Robert Nelson, Conor Dooley
In-Reply-To: <20260603192305.1347908-1-jm@ti.com>
Enable drivers used on BeagleBadge[1]:
- LED PWM Multicolor driver as a module
- MCP SPI IO Expander driver as a module
- Seven Segment display GPIO driver as module
- Temperature Sensor driver as a module
[1] https://www.beagleboard.org/boards/beaglebadge
Signed-off-by: Judith Mendez <jm@ti.com>
---
Changes since v5:
- No change
---
arch/arm64/configs/defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d905a0777f939..5cfb7f6f2ae78 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -634,6 +634,7 @@ CONFIG_PINCTRL_BRCMSTB=y
CONFIG_PINCTRL_BCM2712=y
CONFIG_PINCTRL_DA9062=m
CONFIG_PINCTRL_MAX77620=y
+CONFIG_PINCTRL_MCP23S08=m
CONFIG_PINCTRL_RK805=m
CONFIG_PINCTRL_SINGLE=y
CONFIG_PINCTRL_SX150X=m
@@ -766,6 +767,7 @@ CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_PWM_FAN=m
CONFIG_SENSORS_RASPBERRYPI_HWMON=m
CONFIG_SENSORS_SL28CPLD=m
+CONFIG_SENSORS_SHT4x=m
CONFIG_SENSORS_AMC6821=m
CONFIG_SENSORS_INA2XX=m
CONFIG_SENSORS_INA3221=m
@@ -955,6 +957,8 @@ CONFIG_VIDEO_IMX412=m
CONFIG_VIDEO_OV5640=m
CONFIG_VIDEO_OV5645=m
CONFIG_VIDEO_S5KJN1=m
+CONFIG_AUXDISPLAY=y
+CONFIG_SEG_LED_GPIO=m
CONFIG_DRM=m
CONFIG_DRM_I2C_NXP_TDA998X=m
CONFIG_DRM_HDLCD=m
@@ -1332,6 +1336,7 @@ CONFIG_LEDS_GPIO=y
CONFIG_LEDS_PWM=y
CONFIG_LEDS_SYSCON=y
CONFIG_LEDS_QCOM_FLASH=m
+CONFIG_LEDS_PWM_MULTICOLOR=m
CONFIG_LEDS_QCOM_LPG=m
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_DISK=y
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] arm: gen-mach-types: don't include absolute filename
From: Ryan Eatmon @ 2026-06-03 18:58 UTC (permalink / raw)
To: Uwe Kleine-König, Sascha Hauer
Cc: Russell King, linux-arm-kernel, linux-kernel, Marco Felsch,
Alexander Stein, kernel
In-Reply-To: <aiBDAQmQFKeN033y@monoceros>
On 6/3/2026 10:09 AM, Uwe Kleine-König wrote:
> Hello Sascha,
>
> On Wed, Jun 03, 2026 at 04:12:10PM +0200, Sascha Hauer wrote:
>> mach-types.h is part of the kapi and as such shipped in the
>> linux-headers package. The embedded build path makes that package
>> non-reproducible without going through an extra step of normalizing the
>> path. YOCTO has similar problems in the kernel debug source package.
>>
>> Make the path relative to the kernel source tree which is enough to
>> find the tool that has generated the file.
>>
>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> Compared to my old patch this is simpler, I like it.
>
> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Agreed.
Acked-by: Ryan Eatmon <reatmon@ti.com>
> Thanks
> Uwe
--
Ryan Eatmon reatmon@ti.com
-----------------------------------------
Texas Instruments, Inc. - LCPD - MGTS
^ permalink raw reply
* Re: [PATCH] arm64: dts: hisilicon: hi3660-hikey960: move role-switch endpoint into connector
From: Akash Sukhavasi @ 2026-06-03 18:54 UTC (permalink / raw)
To: xuwei5; +Cc: krzk+dt, robh, conor+dt, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260520215325.55353-1-akash.sukhavasi@gmail.com>
On Wed, May 20, 2026 at 04:53:25PM -0500, Akash Sukhavasi wrote:
> The rt1711h Type-C controller on the HiKey960 has the USB role-switch
> endpoint placed as a top-level 'port' node, outside the connector
> subnode. This triggers two dtbs_check warnings against
> richtek,rt1711h.yaml:
>
> - 'port' does not match any of the regexes: '^pinctrl-[0-9]+$'
> - connector:ports: 'port@0' is a required property
>
> Move the role-switch endpoint into the connector's port@0, which is
> where usb-connector.yaml expects it. Update the DWC3 remote-endpoint
> phandle accordingly.
>
> The TCPM core (tcpm.c) looks up the role switch starting from the
> connector fwnode via fwnode_usb_role_switch_get(). With the endpoint
> inside the connector's port@0, it is found through the primary lookup
> path rather than the device-level fallback.
>
> Cross-compiled for arm64. Verified with dt_binding_check and
> dtbs_check. Not runtime-tested on hardware.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> .../boot/dts/hisilicon/hi3660-hikey960.dts | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> index c6056a85c..27fb08d34 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -550,6 +550,12 @@ usb_con: connector {
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + usb_con_hs: endpoint {
> + remote-endpoint = <&dwc3_role_switch>;
> + };
> + };
> port@1 {
> reg = <1>;
> usb_con_ss: endpoint {
> @@ -558,15 +564,6 @@ usb_con_ss: endpoint {
> };
> };
> };
> - port {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - rt1711h_ep: endpoint@0 {
> - reg = <0>;
> - remote-endpoint = <&dwc3_role_switch>;
> - };
> - };
> };
>
> adv7533: adv7533@39 {
> @@ -683,7 +680,7 @@ port {
> #size-cells = <0>;
> dwc3_role_switch: endpoint@0 {
> reg = <0>;
> - remote-endpoint = <&rt1711h_ep>;
> + remote-endpoint = <&usb_con_hs>;
> };
>
> dwc3_ss: endpoint@1 {
> --
Hi Wei,
Friendly ping on this one.
Also, is the hikey960 board still actively taking fixes?
--
Thanks,
Akash
^ permalink raw reply
* Re: [PATCH v6 1/4] firmware: smccc: Add an Arm SMCCC bus
From: Sudeep Holla @ 2026-06-03 18:52 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: linux-coco, linux-arm-kernel, linux-kernel, Catalin Marinas,
Greg KH, Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi,
Mark Rutland, Will Deacon, Steven Price, Suzuki K Poulose
In-Reply-To: <20260527100233.428018-2-aneesh.kumar@kernel.org>
On Wed, May 27, 2026 at 03:32:30PM +0530, Aneesh Kumar K.V (Arm) wrote:
> SMCCC-discovered firmware services are currently represented by separate
> platform devices, such as smccc_trng and arm-cca-dev. Those devices do not
> represent independent DT/ACPI-described platform resources; they are
> features of the SMCCC firmware interface.
>
> Add an Arm SMCCC bus for services discovered through the SMCCC firmware
> interface. The bus provides SMCCC device and driver registration helpers,
> name-based matching, modalias generation, and a sysfs modalias attribute so
> SMCCC service drivers can bind to discovered firmware services and autoload
> as modules.
>
> Follow-up changes can then register SMCCC firmware services as arm-smccc
> devices instead of creating independent per-feature platform devices.
>
This looks good to me.
> Based on arm_ffa code
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> drivers/firmware/smccc/smccc.c | 158 ++++++++++++++++++++++++++++++
I think it is better to keep it separate say bus.c ?
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCHv2] i2c: mxs: add missing kernel-doc for struct mxs_i2c_dev members
From: Frank Li @ 2026-06-03 18:51 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-i2c, Andi Shyti, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20260603031135.289302-1-rosenp@gmail.com>
On Tue, Jun 02, 2026 at 08:11:35PM -0700, Rosen Penev wrote:
> Add kernel-doc documentation for the struct members that were previously
> undocumented. This fixes warnings when building with W=1 and ensures
> the struct is fully documented per kernel-doc conventions.
>
> Assisted-by: opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> v2: fixed Signed-off-by.
> drivers/i2c/busses/i2c-mxs.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
> index 08c9091a1e35..4e07babea9c3 100644
> --- a/drivers/i2c/busses/i2c-mxs.c
> +++ b/drivers/i2c/busses/i2c-mxs.c
> @@ -108,6 +108,14 @@ enum mxs_i2c_devtype {
> * @cmd_complete: completion object for transaction wait
> * @cmd_err: error code for last transaction
> * @adapter: i2c subsystem adapter node
> + * @timing0: I2C TIMING0 register value
> + * @timing1: I2C TIMING1 register value
> + * @timing2: I2C TIMING2 register value
> + * @dmach: DMA channel
> + * @pio_data: PIO data for DMA
> + * @addr_data: address data for DMA
> + * @sg_io: scatterlist for I/O
> + * @dma_read: flag indicating DMA read
> */
> struct mxs_i2c_dev {
> struct device *dev;
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Shivendra Pratap @ 2026-06-03 18:51 UTC (permalink / raw)
To: Lee Jones, Bartosz Golaszewski
Cc: Sebastian Reichel, Mark Rutland, Lorenzo Pieralisi,
Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer, Sudeep Holla,
linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Bartosz Golaszewski
In-Reply-To: <c034a7c5-7215-4e96-80cf-ef0c51f8291b@oss.qualcomm.com>
On 25-05-2026 15:04, Shivendra Pratap wrote:
>
>
> On 22-05-2026 14:38, Bartosz Golaszewski wrote:
>> On Thu, May 21, 2026 at 6:27 PM Lee Jones <lee@kernel.org> wrote:
>>>
>>> On Thu, 21 May 2026, Bartosz Golaszewski wrote:
>>>
>>>> On Thu, May 21, 2026 at 3:24 PM Lee Jones <lee@kernel.org> wrote:
>>>>>
>>>>>>
>>>>>> I suggested it because of its flexibility. The alternative I had in
>>>>>> mind is something like a new field in mfd_cell:
>>>>>>
>>>>>> const char *cell_node_name;
>>>>>>
>>>>>> Which - if set - would tell MFD to look up an fwnode that's a
>>>>>> child of
>>>>>> the parent device's node by name - as it may not have a compatible.
>>>>>
>>>>> Remind me why the chlid device can't look-up its own fwnode?
>>>>>
>>>>
>>>> Oh sure it can, but should it? I'm not sure it's logically sound to
>>>> have the child device reach into the parent, look up the fwnode and
>>>> then assign it to itself after it's already attached to the driver.
>>>> This should be done at the subsystem level before the device is
>>>> registered.
>>>
>>> Leaf drivers reach back into the parent all the time.
>>>
>>
>> But drivers don't generally assign firmware nodes to devices they are
>> already bound to. This is racy as in probe() the device is already
>> visible to the system. There's no synchronization of device property
>> access - properties are assumed to be read-only for a registered
>> device.
>
> thanks Bart/Lee. Any pointers to take this from here?
Hi Lee,
To take this patchset forward, it would be helpful to get your views on
fwnode based addition in mfd-core. Maybe, a member like "*named_fwnode"
in mfd-core and then a lookup logic, or any alternatives?
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH 2/3] serial: mxs-auart: use devm resources for iomem and GPIO IRQs
From: Frank Li @ 2026-06-03 18:48 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-serial, Greg Kroah-Hartman, Jiri Slaby, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260603025857.287148-3-rosenp@gmail.com>
On Tue, Jun 02, 2026 at 07:58:56PM -0700, Rosen Penev wrote:
> Replace platform_get_resource + ioremap with
> devm_platform_get_and_ioremap_resource and convert GPIO IRQ
> request_irq/free_irq to devm_request_irq. This eliminates the
> mxs_auart_free_gpio_irq function and its call sites, and the
> out_iounmap error label. Simplify the remove function accordingly.
>
> Assisted-by: opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/tty/serial/mxs-auart.c | 55 ++++++++--------------------------
> 1 file changed, 12 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 1390fa000a5b..4499e3206e85 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -1517,15 +1517,6 @@ static int mxs_auart_init_gpios(struct mxs_auart_port *s, struct device *dev)
> return 0;
> }
>
> -static void mxs_auart_free_gpio_irq(struct mxs_auart_port *s)
> -{
> - enum mctrl_gpio_idx i;
> -
> - for (i = 0; i < UART_GPIO_MAX; i++)
> - if (s->gpio_irq[i] >= 0)
> - free_irq(s->gpio_irq[i], s);
> -}
> -
> static int mxs_auart_request_gpio_irq(struct mxs_auart_port *s)
> {
> int *irq = s->gpio_irq;
> @@ -1537,21 +1528,13 @@ static int mxs_auart_request_gpio_irq(struct mxs_auart_port *s)
> continue;
>
> irq_set_status_flags(irq[i], IRQ_NOAUTOEN);
> - err = request_irq(irq[i], mxs_auart_irq_handle,
> - IRQ_TYPE_EDGE_BOTH, dev_name(s->dev), s);
> + err = devm_request_irq(s->dev, irq[i], mxs_auart_irq_handle,
> + IRQ_TYPE_EDGE_BOTH, dev_name(s->dev), s);
> if (err)
> dev_err(s->dev, "%s - Can't get %d irq\n",
> __func__, irq[i]);
> }
>
> - /*
> - * If something went wrong, rollback.
> - * Be careful: i may be unsigned.
> - */
> - while (err && (i-- > 0))
> - if (irq[i] >= 0)
> - free_irq(irq[i], s);
> -
> return err;
> }
>
> @@ -1586,7 +1569,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - s->devtype = (enum mxs_auart_type)of_device_get_match_data(&pdev->dev);
> + s->devtype = (unsigned long)of_device_get_match_data(&pdev->dev);
This change need seperate patch
Frank
>
> ret = mxs_get_clks(s, pdev);
> if (ret)
> @@ -1596,18 +1579,12 @@ static int mxs_auart_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!r) {
> - ret = -ENXIO;
> + s->port.membase = devm_platform_get_and_ioremap_resource(pdev, 0, &r);
> + if (IS_ERR(s->port.membase)) {
> + ret = PTR_ERR(s->port.membase);
> goto out_disable_clk;
> }
> -
> s->port.mapbase = r->start;
> - s->port.membase = ioremap(r->start, resource_size(r));
> - if (!s->port.membase) {
> - ret = -ENOMEM;
> - goto out_disable_clk;
> - }
> s->port.ops = &mxs_auart_ops;
> s->port.iotype = UPIO_MEM;
> s->port.fifosize = MXS_AUART_FIFO_SIZE;
> @@ -1622,21 +1599,21 @@ static int mxs_auart_probe(struct platform_device *pdev)
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> ret = irq;
> - goto out_iounmap;
> + goto out_disable_clk;
> }
>
> s->port.irq = irq;
> ret = devm_request_irq(&pdev->dev, irq, mxs_auart_irq_handle, 0,
> dev_name(&pdev->dev), s);
> if (ret)
> - goto out_iounmap;
> + goto out_disable_clk;
>
> platform_set_drvdata(pdev, s);
>
> ret = mxs_auart_init_gpios(s, &pdev->dev);
> if (ret) {
> dev_err(&pdev->dev, "Failed to initialize GPIOs.\n");
> - goto out_iounmap;
> + goto out_disable_clk;
> }
>
> /*
> @@ -1644,7 +1621,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
> */
> ret = mxs_auart_request_gpio_irq(s);
> if (ret)
> - goto out_iounmap;
> + goto out_disable_clk;
>
> auart_port[s->port.line] = s;
>
> @@ -1667,11 +1644,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
> return 0;
>
> out_free_qpio_irq:
> - mxs_auart_free_gpio_irq(s);
> - auart_port[pdev->id] = NULL;
> -
> -out_iounmap:
> - iounmap(s->port.membase);
> + auart_port[s->port.line] = NULL;
>
> out_disable_clk:
> clk_disable_unprepare(s->clk);
> @@ -1683,11 +1656,7 @@ static void mxs_auart_remove(struct platform_device *pdev)
> struct mxs_auart_port *s = platform_get_drvdata(pdev);
>
> uart_remove_one_port(&auart_driver, &s->port);
> - auart_port[pdev->id] = NULL;
> - mxs_auart_free_gpio_irq(s);
> - iounmap(s->port.membase);
> - if (is_asm9260_auart(s))
> - clk_disable_unprepare(s->clk);
> + auart_port[s->port.line] = NULL;
> }
>
> static struct platform_driver mxs_auart_driver = {
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH 1/3] serial: mxs-auart: rework clock handling in mxs_get_clks and probe
From: Frank Li @ 2026-06-03 18:45 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-serial, Greg Kroah-Hartman, Jiri Slaby, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260603025857.287148-2-rosenp@gmail.com>
On Tue, Jun 02, 2026 at 07:58:55PM -0700, Rosen Penev wrote:
> Use devm_clk_get_enabled for the AHB clock so its enable/disable
> lifetime is managed by the driver model. Move the mod clock
> (clk) prepare_enable out of mxs_get_clks and into probe so that
> clk_set_rate is called while the clock is still disabled, avoiding
> CLK_SET_RATE_GATE failures. Clean up the error labels accordingly.
>
> Assisted-by: opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/tty/serial/mxs-auart.c | 47 ++++++++++++----------------------
> 1 file changed, 17 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 697318dbb146..1390fa000a5b 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -1470,34 +1470,22 @@ static int mxs_get_clks(struct mxs_auart_port *s,
> return PTR_ERR(s->clk);
> }
>
> - s->clk_ahb = devm_clk_get(s->dev, "ahb");
> + s->clk_ahb = devm_clk_get_enabled(s->dev, "ahb");
> if (IS_ERR(s->clk_ahb)) {
> dev_err(s->dev, "Failed to get \"ahb\" clk\n");
> return PTR_ERR(s->clk_ahb);
> }
>
> - err = clk_prepare_enable(s->clk_ahb);
> - if (err) {
> - dev_err(s->dev, "Failed to enable ahb_clk!\n");
> - return err;
> - }
> -
> + /*
> + * Set mod clock rate while it is still disabled so
> + * CLK_SET_RATE_GATE does not cause clk_set_rate to fail.
> + * The mod clock will be enabled in mxs_auart_startup()
> + * and in probe after mxs_get_clks returns.
> + */
> err = clk_set_rate(s->clk, clk_get_rate(s->clk_ahb));
> - if (err) {
> + if (err)
> dev_err(s->dev, "Failed to set rate!\n");
> - goto disable_clk_ahb;
> - }
>
> - err = clk_prepare_enable(s->clk);
> - if (err) {
> - dev_err(s->dev, "Failed to enable clk!\n");
> - goto disable_clk_ahb;
> - }
> -
> - return 0;
> -
> -disable_clk_ahb:
> - clk_disable_unprepare(s->clk_ahb);
> return err;
> }
>
> @@ -1604,17 +1592,21 @@ static int mxs_auart_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = clk_prepare_enable(s->clk);
> + if (ret)
> + return ret;
> +
why not direct enable clock when get?
s->clk = devm_clk_get(s->dev, "mod");
Frank
> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!r) {
> ret = -ENXIO;
> - goto out_disable_clks;
> + goto out_disable_clk;
> }
>
> s->port.mapbase = r->start;
> s->port.membase = ioremap(r->start, resource_size(r));
> if (!s->port.membase) {
> ret = -ENOMEM;
> - goto out_disable_clks;
> + goto out_disable_clk;
> }
> s->port.ops = &mxs_auart_ops;
> s->port.iotype = UPIO_MEM;
> @@ -1681,11 +1673,8 @@ static int mxs_auart_probe(struct platform_device *pdev)
> out_iounmap:
> iounmap(s->port.membase);
>
> -out_disable_clks:
> - if (is_asm9260_auart(s)) {
> - clk_disable_unprepare(s->clk);
> - clk_disable_unprepare(s->clk_ahb);
> - }
> +out_disable_clk:
> + clk_disable_unprepare(s->clk);
> return ret;
> }
>
> @@ -1697,10 +1686,8 @@ static void mxs_auart_remove(struct platform_device *pdev)
> auart_port[pdev->id] = NULL;
> mxs_auart_free_gpio_irq(s);
> iounmap(s->port.membase);
> - if (is_asm9260_auart(s)) {
> + if (is_asm9260_auart(s))
> clk_disable_unprepare(s->clk);
> - clk_disable_unprepare(s->clk_ahb);
> - }
> }
>
> static struct platform_driver mxs_auart_driver = {
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v3 0/5] arm64: dts: imx93-var-som-symphony: align DTS with hardware revision
From: Frank.Li @ 2026-06-03 18:39 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel, Stefano Radaelli
Cc: Frank Li, pierluigi.p, Stefano Radaelli, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <cover.1780474803.git.stefano.r@variscite.com>
From: Frank Li <Frank.Li@nxp.com>
On Wed, 03 Jun 2026 10:24:59 +0200, Stefano Radaelli wrote:
> This series updates the i.MX93 VAR-SOM Symphony device tree to match the
> latest carrier board hardware revision.
>
> The changes add support for onboard peripherals and complete the board
> configuration with the required GPIO, pinctrl and PWM settings.
>
> v2->v3:
> - Use reset-gpios for the TPM instead of a GPIO hog
> - Add ADC1 support
>
> [...]
Applied, thanks!
[1/5] arm64: dts: imx93-var-som-symphony: add TPM support
commit: ff36dd3052902fb9beb0aae9890f4e48dd1dbb17
[2/5] arm64: dts: imx93-var-som-symphony: enable UART7
commit: 787bd1ec71cf1b176e4e89c26940790891a53a6a
[3/5] arm64: dts: imx93-var-som-symphony: keep RGB_SEL low
commit: 5def8bdea91aa39b7eb87b513eb8c509f7125d2c
[4/5] arm64: dts: imx93-var-som-symphony: enable TPM3 PWM
commit: 35aa71e7bee68b00291949d091c1f1b8f783b63e
[5/5] arm64: dts: imx93-var-som-symphony: enable ADC
commit: ebb039d82a1b8f2d1ed3c98cc404a17e266e54a8
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ 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