* Re: [PATCH] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Dmitry Baryshkov @ 2026-03-23 22:12 UTC (permalink / raw)
To: Ayushi Makhija
Cc: andersson, konrad.dybcio, robh+dt, krzysztof.kozlowski+dt,
conor+dt, dmitry.baryshkov, linux-arm-msm, devicetree,
linux-kernel, linux-arm-kernel, quic_rajeevny, quic_vproddut
In-Reply-To: <20260323102229.1546504-1-quic_amakhija@quicinc.com>
On Mon, Mar 23, 2026 at 03:52:29PM +0530, Ayushi Makhija wrote:
> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
>
> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
Please switch to oss.qualcomm.com
Other than that:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] iommu/arm-smmu-v3: Fix typos introduced by arm_smmu_invs
From: Jason Gunthorpe @ 2026-03-23 22:11 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <20260321225041.11090-3-nicolinc@nvidia.com>
On Sat, Mar 21, 2026 at 03:50:41PM -0700, Nicolin Chen wrote:
> These are introduced by separate commits, so not submitting with a "Fixes"
> line, since they aren't critical.
>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 +++---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
Some of those might have come from me
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v1] PCI: imx6: Add force_suspend flag to override L1SS suspend skip
From: Bjorn Helgaas @ 2026-03-23 22:08 UTC (permalink / raw)
To: Hongxing Zhu
Cc: Frank Li, jingoohan1@gmail.com, l.stach@pengutronix.de,
lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
robh@kernel.org, bhelgaas@google.com, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <AS8PR04MB8833061F34B9BEFC9D19764A8C4EA@AS8PR04MB8833.eurprd04.prod.outlook.com>
On Wed, Mar 18, 2026 at 02:55:45AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas@kernel.org>
> ... [messed up quoting]
> > On Tue, Mar 17, 2026 at 02:12:56PM +0800, Richard Zhu wrote:
> > > Add a force_suspend flag to allow platform drivers to force the PCIe
> > > link into L2 state during suspend, even when L1SS (ASPM L1 Sub-States)
> > > is enabled.
> > >
> > > By default, the DesignWare PCIe host controller skips L2 suspend when
> > > L1SS is supported to meet low resume latency requirements for devices
> > > like NVMe. However, some platforms like i.MX PCIe need to enter L2
> > > state for proper power management regardless of L1SS support.
> > >
> > > Enable force_suspend for i.MX PCIe to ensure the link enters L2 during
> > > system suspend.
> >
> > I'm a little bit skeptical about this.
> >
> > What exactly does a "low resume latency requirement" mean? Is
> > this an actual functional requirement that's special to NVMe, or
> > is it just the desire for low resume latency that everybody has
> > for all devices?
>
> From my understanding, L1SS mode is characterized by lower latency
> when compared to L2 or L3 modes.
>
> It can be used on all devices, avoiding frequent power on/off
> cycles. NVMe can also extend the service life of the equipment.
All the above applies to all platforms, so it's not an argument for
i.MX-specific code here.
> > Is there something special about i.MX here? Why do we want i.MX
> > to be different from other host controllers?
>
> i.MX PCIe loses power supply during Deep Sleep Mode (DSM), requiring
> full reinitialization after system wake-up.
I don't know what DSM means in PCIe or how it would help justify this
change.
> Removing the L1SS check allows the suspend process to complete
> successfully and ensures the pci->suspended flag is set to true,
> which triggers the proper resume sequence during system wake-up for
> i.MX PCIes.
> > > Cc: stable@vger.kernel.org
> > > Fixes: 4774faf854f5 ("PCI: dwc: Implement generic suspend/resume
> > > functionality")
> > > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 1 +
> > > drivers/pci/controller/dwc/pcie-designware-host.c | 4 +++-
> > > drivers/pci/controller/dwc/pcie-designware.h | 1 +
> > > 3 files changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 81a7093494c8..7902d39185a5 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -1831,6 +1831,7 @@ static int imx_pcie_probe(struct platform_device
> > *pdev)
> > > if (imx_check_flag(imx_pcie, IMX_PCIE_FLAG_SKIP_L23_READY))
> > > pci->pp.skip_l23_ready = true;
> > > pci->pp.use_atu_msg = true;
> > > + pci->pp.force_l2_suspend = true;
> > > ret = dw_pcie_host_init(&pci->pp);
> > > if (ret < 0)
> > > return ret;
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > index a74339982c24..720154fd4ff0 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > @@ -1229,7 +1229,9 @@ int dw_pcie_suspend_noirq(struct dw_pcie *pci)
> > > * If L1SS is supported, then do not put the link into L2 as some
> > > * devices such as NVMe expect low resume latency.
> > > */
> > > - if (dw_pcie_readw_dbi(pci, offset + PCI_EXP_LNKCTL) &
> > PCI_EXP_LNKCTL_ASPM_L1)
> > > + if (!pci->pp.force_l2_suspend &&
> > > + (dw_pcie_readw_dbi(pci, offset + PCI_EXP_LNKCTL) &
> > > + PCI_EXP_LNKCTL_ASPM_L1))
> > > return 0;
> > >
> > > if (pci->pp.ops->pme_turn_off) {
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > > b/drivers/pci/controller/dwc/pcie-designware.h
> > > index ae6389dd9caa..5261036bbe6e 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > @@ -447,6 +447,7 @@ struct dw_pcie_rp {
> > > bool ecam_enabled;
> > > bool native_ecam;
> > > bool skip_l23_ready;
> > > + bool force_l2_suspend;
> > > };
> > >
> > > struct dw_pcie_ep_ops {
> > > --
> > > 2.37.1
> > >
^ permalink raw reply
* [GIT PULL v2] Rockchip dts fixes for 7.0 #1
From: Heiko Stuebner @ 2026-03-23 21:58 UTC (permalink / raw)
To: arm; +Cc: soc, linux-rockchip, linux-arm-kernel
Hi SoC maintainers,
As requested by Krzysztof, here is a more condensed PR.
Changes in v2 are that I dropped fixes for dt-schema errors and fixes
for commits introduced not closesly to the current release. These have
been moved to the current branches.
The Pinebook regression fix actually also is for a commit from august
last year, but fixes an actively tracked regression, so maybe carries
a bit more weight.
Please pull
Thanks
Heiko
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v7.0-rockchip-dtsfixes1-v2
for you to fetch changes up to 29d1f56c4f3001b7f547123e0a307c009ac717f8:
Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro" (2026-02-22 23:28:06 +0100)
----------------------------------------------------------------
Revert to fix a regression that breaks Wifi support for a large part
of Pinebook Pro users (multiple Wifi chipsets).
----------------------------------------------------------------
Heiko Stuebner (1):
Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro"
arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 18 ------------------
1 file changed, 18 deletions(-)
^ permalink raw reply
* Re: [PATCH v5 15/17] spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
From: Mark Brown @ 2026-03-23 21:49 UTC (permalink / raw)
To: Pei Xiao
Cc: linux-spi, linux-arm-kernel, linux-kernel, imx, openbmc,
linux-rockchip, linux-riscv, linux-mediatek, linux-stm32,
Frank.Li, amelie.delaunay
In-Reply-To: <bcfc4a5191976b2ada9cd4094b61ac67a0ea9da7.1773885292.git.xiaopei01@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
On Thu, Mar 19, 2026 at 10:04:11AM +0800, Pei Xiao wrote:
> Replace devm_clk_get() followed by clk_prepare_enable() with
> devm_clk_get_enabled() for the clock. This removes the need for
> explicit clock enable and disable calls, as the managed API automatically
> handles clock disabling on device removal or probe failure.
This breaks an allmodconfig build:
/build/stage/linux/drivers/spi/spi-uniphier.c: In function ‘uniphier_spi_remove’
:
/build/stage/linux/drivers/spi/spi-uniphier.c:773:35: error: unused variable ‘pr
iv’ [-Werror=unused-variable]
773 | struct uniphier_spi_priv *priv = spi_controller_get_devdata(host
);
| ^~~~
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: Reset PPE cpu port configuration in airoha_ppe_hw_init()
From: Jakub Kicinski @ 2026-03-23 21:42 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <ab6R4krBRy5dycb-@lore-desk>
On Sat, 21 Mar 2026 13:41:06 +0100 Lorenzo Bianconi wrote:
> What do you think?
> I noticed commit f44218cd5e6a is already applied to net-next. I will post a
> follow-up patch, agree?
Sounds good, and yes please.
^ permalink raw reply
* [PATCH] arm64: vdso: fix AArch32 compat init allocation leaks
From: Osama Abdelkader @ 2026-03-23 21:41 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Kees Cook, Osama Abdelkader,
Andrew Morton, Liam R. Howlett, Jeff Xu, linux-arm-kernel,
linux-kernel
aarch32_alloc_vdso_pages() allocates the AA32 vdso pagelist, the compat
sigpage, then the kuser vectors page. If aarch32_alloc_sigpage() or
aarch32_alloc_kuser_vdso_page() fails, earlier allocations were not freed.
Unwind in reverse order: drop the sigpage when kuser setup fails, and
kfree the vdso pagelist when either later step fails (only when
CONFIG_COMPAT_VDSO allocated it).
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
---
arch/arm64/kernel/vdso.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 592dd8668de4..9903bfdfd45e 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -236,9 +236,27 @@ static int __init aarch32_alloc_vdso_pages(void)
ret = aarch32_alloc_sigpage();
if (ret)
- return ret;
+ goto free_vdso;
+
+ ret = aarch32_alloc_kuser_vdso_page();
+ if (ret)
+ goto free_sig;
+
+ return 0;
- return aarch32_alloc_kuser_vdso_page();
+free_sig:
+ if (aarch32_sig_page) {
+ __free_page(aarch32_sig_page);
+ aarch32_sig_page = NULL;
+ }
+free_vdso:
+#ifdef CONFIG_COMPAT_VDSO
+ if (vdso_info[VDSO_ABI_AA32].cm && vdso_info[VDSO_ABI_AA32].cm->pages) {
+ kfree(vdso_info[VDSO_ABI_AA32].cm->pages);
+ vdso_info[VDSO_ABI_AA32].cm->pages = NULL;
+ }
+#endif
+ return ret;
}
arch_initcall(aarch32_alloc_vdso_pages);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/4] dt-bindings: iio: adc: amlogic,meson-saradc: add S4 compatible
From: Martin Blumenstingl @ 2026-03-23 21:39 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Nick Xie, neil.armstrong, khilman, jbrunet, jic23, dlechner, andy,
krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260323-saffron-cobra-of-perfection-731c8d@quoll>
On Mon, Mar 23, 2026 at 8:53 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Mon, Mar 23, 2026 at 09:34:05AM +0800, Nick Xie wrote:
> > Add the compatible string for the SARADC (Successive Approximation
> > Register ADC) IP block found in the Amlogic Meson S4 SoC.
> >
> > There are no known differences between the SARADC on S4 and the one
> > on G12A. Therefore, it uses "amlogic,meson-g12a-saradc" as a proper
> > specific fallback.
>
> You should explain here why you are adding that comment.
What do you think about:
Also add a comment indicating that "amlogic,meson-saradc" must not be
used for new devices. It's a made up compatible string that does not
correspond to a specific hardware generation and is not used to match
any driver. For old devices we keep it as it's part of the ABI.
^ permalink raw reply
* Re: [PATCH v1 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Yang Shi @ 2026-03-23 21:34 UTC (permalink / raw)
To: Ryan Roberts, Catalin Marinas, Will Deacon,
David Hildenbrand (Arm), Dev Jain, Suzuki K Poulose, Jinjiang Tu,
Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260323130317.1737522-2-ryan.roberts@arm.com>
On 3/23/26 6:03 AM, Ryan Roberts wrote:
> Commit a166563e7ec37 ("arm64: mm: support large block mapping when
> rodata=full") enabled the linear map to be mapped by block/cont while
> still allowing granular permission changes on BBML2_NOABORT systems by
> lazily splitting the live mappings. This mechanism was intended to be
> usable by realm guests since they need to dynamically share dma buffers
> with the host by "decrypting" them - which for Arm CCA, means marking
> them as shared in the page tables.
>
> However, it turns out that the mechanism was failing for realm guests
> because realms need to share their dma buffers (via
> __set_memory_enc_dec()) much earlier during boot than
> split_kernel_leaf_mapping() was able to handle. The report linked below
> showed that GIC's ITS was one such user. But during the investigation I
> found other callsites that could not meet the
> split_kernel_leaf_mapping() constraints.
>
> The problem is that we block map the linear map based on the boot CPU
> supporting BBML2_NOABORT, then check that all the other CPUs support it
> too when finalizing the caps. If they don't, then we stop_machine() and
> split to ptes. For safety, split_kernel_leaf_mapping() previously
> wouldn't permit splitting until after the caps were finalized. That
> ensured that if any secondary cpus were running that didn't support
> BBML2_NOABORT, we wouldn't risk breaking them.
>
> I've fix this problem by reducing the black-out window where we refuse
> to split; there are now 2 windows. The first is from T0 until the page
> allocator is inititialized. Splitting allocates memory for the page
> allocator so it must be in use. The second covers the period between
> starting to online the secondary cpus until the system caps are
> finalized (this is a very small window).
>
> All of the problematic callers are calling __set_memory_enc_dec() before
> the secondary cpus come online, so this solves the problem. However, one
> of these callers, swiotlb_update_mem_attributes(), was trying to split
> before the page allocator was initialized. So I have moved this call
> from arch_mm_preinit() to mem_init(), which solves the ordering issue.
>
> I've added warnings and return an error if any attempt is made to split
> in the black-out windows.
>
> Note there are other issues which prevent booting all the way to user
> space, which will be fixed in subsequent patches.
Hi Ryan,
Thanks for putting everything to together to have the patches so
quickly. It basically looks good to me. However, I'm thinking about
whether we should have split_kernel_leaf_mapping() call for different
memory allocators in different stages. If buddy has been initialized, it
can call page allocator, otherwise, for example, in early boot stage, it
can call memblock allocator. So split_kernel_leaf_mapping() should be
able to be called anytime and we don't have to rely on the boot order of
subsystems.
Thanks,
Yang
>
> Reported-by: Jinjiang Tu <tujinjiang@huawei.com>
> Closes: https://lore.kernel.org/all/0b2a4ae5-fc51-4d77-b177-b2e9db74f11d@huawei.com/
> Fixes: a166563e7ec37 ("arm64: mm: support large block mapping when rodata=full")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> arch/arm64/mm/init.c | 9 ++++++++-
> arch/arm64/mm/mmu.c | 35 +++++++++++++++++++++++++++--------
> 2 files changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 96711b8578fd0..b9b248d24fd10 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -350,7 +350,6 @@ void __init arch_mm_preinit(void)
> }
>
> swiotlb_init(swiotlb, flags);
> - swiotlb_update_mem_attributes();
>
> /*
> * Check boundaries twice: Some fundamental inconsistencies can be
> @@ -377,6 +376,14 @@ void __init arch_mm_preinit(void)
> }
> }
>
> +bool page_alloc_available __ro_after_init;
> +
> +void __init mem_init(void)
> +{
> + page_alloc_available = true;
> + swiotlb_update_mem_attributes();
> +}
> +
> void free_initmem(void)
> {
> void *lm_init_begin = lm_alias(__init_begin);
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index a6a00accf4f93..5b6a8d53e64b7 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -773,14 +773,33 @@ int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
> {
> int ret;
>
> - /*
> - * !BBML2_NOABORT systems should not be trying to change permissions on
> - * anything that is not pte-mapped in the first place. Just return early
> - * and let the permission change code raise a warning if not already
> - * pte-mapped.
> - */
> - if (!system_supports_bbml2_noabort())
> - return 0;
> + if (!system_supports_bbml2_noabort()) {
> + /*
> + * !BBML2_NOABORT systems should not be trying to change
> + * permissions on anything that is not pte-mapped in the first
> + * place. Just return early and let the permission change code
> + * raise a warning if not already pte-mapped.
> + */
> + if (system_capabilities_finalized() ||
> + !cpu_supports_bbml2_noabort())
> + return 0;
> +
> + /*
> + * Boot-time: split_kernel_leaf_mapping_locked() allocates from
> + * page allocator. Can't split until it's available.
> + */
> + extern bool page_alloc_available;
> + if (WARN_ON(!page_alloc_available))
> + return -EBUSY;
> +
> + /*
> + * Boot-time: Started secondary cpus but don't know if they
> + * support BBML2_NOABORT yet. Can't allow splitting in this
> + * window in case they don't.
> + */
> + if (WARN_ON(num_online_cpus() > 1))
> + return -EBUSY;
> + }
>
> /*
> * If the region is within a pte-mapped area, there is no need to try to
^ permalink raw reply
* [PATCH 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read
From: Lothar Rubusch @ 2026-03-23 21:27 UTC (permalink / raw)
To: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
In-Reply-To: <20260323212755.687342-1-l.rubusch@gmail.com>
The ATSHA204A returns a 35-byte packet consisting of a 1-byte count,
32 bytes of entropy, and a 2-byte CRC. The current blocking read
implementation was incorrectly copying data starting from the
count byte, leading to offset data and truncated entropy.
Additionally, the chip requires significant execution time to
generate random numbers, going by the datasheet. Reading the I2C bus
too early results in the chip NACK-ing or returning a partial buffer
followed by zeros.
Verification:
Tests before showed repeadetly reading only 8 bytes of entropy:
$ head -c 32 /dev/hwrng | hexdump -C
00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
After this patch applied, the result will be as follows:
$ head -c 32 /dev/hwrng | hexdump -C
00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
00000020
Fix these issues by:
Increase cmd.msecs to 30ms to provide sufficient execution time. Then
set cmd.rxsize to RANDOM_RSP_SIZE (35 bytes) to capture the entire
hardware response. Eventually, correct the memcpy() offset to index 1 of
the data buffer to skip the count byte and retrieve exactly 32 bytes of
entropy.
Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/crypto/atmel-sha204a.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index 1baf4750d311..350ba8618c69 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -18,6 +18,9 @@
#include <linux/workqueue.h>
#include "atmel-i2c.h"
+#define ATMEL_RNG_BLOCK_SIZE 32
+#define ATMEL_RNG_EXEC_TIME 30
+
static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
void *areq, int status)
{
@@ -91,13 +94,15 @@ static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
atmel_i2c_init_random_cmd(&cmd);
+ cmd.msecs = ATMEL_RNG_EXEC_TIME;
+ cmd.rxsize = RANDOM_RSP_SIZE;
ret = atmel_i2c_send_receive(i2c_priv->client, &cmd);
if (ret)
return ret;
- max = min(sizeof(cmd.data), max);
- memcpy(data, cmd.data, max);
+ max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
+ memcpy(data, &cmd.data[1], max);
return max;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 3/3] crypto: atmel-sha204a - fix non-blocking read logic
From: Lothar Rubusch @ 2026-03-23 21:27 UTC (permalink / raw)
To: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
In-Reply-To: <20260323212755.687342-1-l.rubusch@gmail.com>
The non-blocking path was (also) failing to provide valid entropy
due to improper buffer management and a lack of hardware execution
time.
Ensure cmd.msecs (30ms) and cmd.rxsize (35ms) are initialized before
enqueuing the background work. Fix the data offset to skip the
1-byte hardware count header when copying bits to the caller. Correctly
return 0 (busy) to the hwrng core while hardware execution is in
progress, preventing zero-filled buffers, which was the situation
before.
With this fix applied, tests will look similar to this:
$ socat -u OPEN:/dev/hwrng,nonblock - | head -c 32 | hexdump -C
00000000 23 cc 42 3c 90 b1 38 fc 54 37 35 4b 09 c5 e1 0d |#.B<..8.T75K....|
2026/03/23 14:30:18 socat[858] E read(5, 0x55be363000, 8192): Resource temporarily unavailable
00000010 73 3b af d9 02 70 76 bd 2d 59 4b 12 01 ac ae 2b |s;...pv.-YK....+|
00000020
Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/crypto/atmel-sha204a.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index 350ba8618c69..6700847c56a3 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -32,7 +32,6 @@ static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
"i2c transaction failed (%d)\n",
status);
kfree(work_data);
- rng->priv = 0;
atomic_dec(&i2c_priv->tfm_count);
return;
}
@@ -49,20 +48,19 @@ static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
- /* Verify if data available from last run */
if (rng->priv) {
work_data = (struct atmel_i2c_work_data *)rng->priv;
- max = min(sizeof(work_data->cmd.data), max);
- memcpy(data, &work_data->cmd.data, max);
+ max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
+ memcpy(data, &work_data->cmd.data[1], max); // Note the [1] index
- /* Now, free memory */
+ /* Free memory and clear the in-flight flag */
kfree(work_data);
rng->priv = 0;
atomic_dec(&i2c_priv->tfm_count);
return max;
}
- /* When a request is still in-flight but not processed */
+ /* If a request is still in-flight, return 0 (busy) */
if (atomic_read(&i2c_priv->tfm_count) > 0)
return 0;
@@ -76,8 +74,14 @@ static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
work_data->client = i2c_priv->client;
atmel_i2c_init_random_cmd(&work_data->cmd);
+
+ /* Set the execution time for the RNG command (from datasheet) */
+ work_data->cmd.msecs = ATMEL_RNG_EXEC_TIME;
+ work_data->cmd.rxsize = RANDOM_RSP_SIZE;
+
atmel_i2c_enqueue(work_data, atmel_sha204a_rng_done, rng);
+ /* Return 0 to indicate 'busy', data will be ready on next call */
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 1/3] crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data
From: Lothar Rubusch @ 2026-03-23 21:27 UTC (permalink / raw)
To: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
In-Reply-To: <20260323212755.687342-1-l.rubusch@gmail.com>
The driver allocated memory for work_data in the non-blocking read
path but never free'd it again. After first read-out the memory pointer
seemed to be recycled and never was allocated again, due to some errors
in the logic, so that the leak was not growing.
Add kfree(work_data) in the completion callback on error. then add
kfree(work_data) after the data is consumed in the subsequent read
call. Finally ensure atomic_dec() is called only after the data has
been consumed or an error occurred to prevent race conditions.
Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/crypto/atmel-sha204a.c | 44 +++++++++++++++++++++-------------
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index 98d1023007e3..1baf4750d311 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -24,15 +24,20 @@ static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
struct atmel_i2c_client_priv *i2c_priv = work_data->ctx;
struct hwrng *rng = areq;
- if (status)
+ if (status) {
dev_warn_ratelimited(&i2c_priv->client->dev,
"i2c transaction failed (%d)\n",
status);
+ kfree(work_data);
+ rng->priv = 0;
+ atomic_dec(&i2c_priv->tfm_count);
+ return;
+ }
rng->priv = (unsigned long)work_data;
- atomic_dec(&i2c_priv->tfm_count);
}
+
static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
size_t max)
{
@@ -41,31 +46,36 @@ static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
- /* keep maximum 1 asynchronous read in flight at any time */
- if (!atomic_add_unless(&i2c_priv->tfm_count, 1, 1))
- return 0;
-
+ /* Verify if data available from last run */
if (rng->priv) {
work_data = (struct atmel_i2c_work_data *)rng->priv;
max = min(sizeof(work_data->cmd.data), max);
memcpy(data, &work_data->cmd.data, max);
- rng->priv = 0;
- } else {
- work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
- if (!work_data) {
- atomic_dec(&i2c_priv->tfm_count);
- return -ENOMEM;
- }
- work_data->ctx = i2c_priv;
- work_data->client = i2c_priv->client;
- max = 0;
+ /* Now, free memory */
+ kfree(work_data);
+ rng->priv = 0;
+ atomic_dec(&i2c_priv->tfm_count);
+ return max;
}
+ /* When a request is still in-flight but not processed */
+ if (atomic_read(&i2c_priv->tfm_count) > 0)
+ return 0;
+
+ /* Start a new request */
+ work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
+ if (!work_data)
+ return -ENOMEM;
+
+ atomic_inc(&i2c_priv->tfm_count);
+ work_data->ctx = i2c_priv;
+ work_data->client = i2c_priv->client;
+
atmel_i2c_init_random_cmd(&work_data->cmd);
atmel_i2c_enqueue(work_data, atmel_sha204a_rng_done, rng);
- return max;
+ return 0;
}
static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
--
2.53.0
^ permalink raw reply related
* [PATCH 0/3] crypto: atmel-sha204a - multiple RNG fixes
From: Lothar Rubusch @ 2026-03-23 21:27 UTC (permalink / raw)
To: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
When testing the RNG functionality on the Atmel SHA204a hardware, I
found the following issues: rngtest reported failures and hexdump
reveiled only the first 8 bytes out of 32 provided actually entropy.
Having a closer look into it, I found a (small) memory leak, missing
to free work_data, miss-reading of the count field into the entropy
fields and parts of the 32 random bytes staying 0 due to reading the
slow i2c device.
The series proposes fixes and how fixed functionality can be/was
verified. Executing rngtest afterward showed a decent result, due
to the i2c bus a bit slow.
All setups require selecting the Atmel-sha204a as active RNG.
$ cat /sys/class/misc/hw_random/rng_available
3f104000.rng 1-0064 none
$ echo 1-0064 > /sys/class/misc/hw_random/rng_current
$ cat /sys/class/misc/hw_random/rng_current
1-0064
Testing RNG properties currently shows problematic results:
$ rngtest < /dev/hwrng
rngtest 2.6
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests...
rngtest: bits received from input: 1040032
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 52
rngtest: FIPS 140-2(2001-10-10) Monobit: 52
rngtest: FIPS 140-2(2001-10-10) Poker: 52
rngtest: FIPS 140-2(2001-10-10) Runs: 52
rngtest: FIPS 140-2(2001-10-10) Long run: 52
rngtest: FIPS 140-2(2001-10-10) Continuous run: 52
rngtest: input channel speed: (min=7.631; avg=7.804; max=7.827)Kibits/s
rngtest: FIPS tests speed: (min=32.273; avg=32.701; max=33.056)Mibits/s
rngtest: Program run time: 130177956 microseconds
---
Lothar Rubusch (3):
crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data
crypto: atmel-sha204a - fix truncated 32-byte blocking read
crypto: atmel-sha204a - fix non-blocking read logic
drivers/crypto/atmel-sha204a.c | 61 ++++++++++++++++++++++------------
1 file changed, 40 insertions(+), 21 deletions(-)
base-commit: 5c52607c43c397b79a9852ce33fc61de58c3645c
--
2.53.0
^ permalink raw reply
* Re: [PATCH v2 4/4] iommu: Get DT/ACPI parsing into the proper probe path
From: Robin Murphy @ 2026-03-23 20:49 UTC (permalink / raw)
To: Tudor Ambarus, Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla,
Rafael J. Wysocki, Len Brown, Russell King, Greg Kroah-Hartman,
Danilo Krummrich, Stuart Yoder, Laurentiu Tudor, Nipun Gupta,
Nikhil Agarwal, Joerg Roedel, Will Deacon, Rob Herring,
Bjorn Helgaas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, iommu, devicetree,
linux-pci, Charan Teja Kalla, Peter Griffin, André Draszik,
Juan Yescas, kernel-team
In-Reply-To: <67b32e90-1f60-4bf5-b534-b4a901d5a796@linaro.org>
On 23/03/2026 5:18 pm, Tudor Ambarus wrote:
> Hi, Robin,
>
> On 2/28/25 5:46 PM, Robin Murphy wrote:
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index a3b45b84f42b..1cec7074367a 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -414,9 +414,21 @@ static int iommu_init_device(struct device *dev)
>> if (!dev_iommu_get(dev))
>> return -ENOMEM;
>> /*
>> - * For FDT-based systems and ACPI IORT/VIOT, drivers register IOMMU
>> - * instances with non-NULL fwnodes, and client devices should have been
>> - * identified with a fwspec by this point. Otherwise, we can currently
>> + * For FDT-based systems and ACPI IORT/VIOT, the common firmware parsing
>> + * is buried in the bus dma_configure path. Properly unpicking that is
>> + * still a big job, so for now just invoke the whole thing. The device
>> + * already having a driver bound means dma_configure has already run and
>> + * either found no IOMMU to wait for, or we're in its replay call right
>> + * now, so either way there's no point calling it again.
>> + */
>> + if (!dev->driver && dev->bus->dma_configure) {
>> + mutex_unlock(&iommu_probe_device_lock);
>> + dev->bus->dma_configure(dev);
>> + mutex_lock(&iommu_probe_device_lock);
>> + }
>
> I was chasing the "something fishy" dev_WARN on a 6.19+ downstream
> android kernel and while looking at the IOMMU code I couldn't help
> myself and ask whether we shall prevent concurrent execution of
> dma_configure().
>
> It seems to me that while the IOMMU subsystem is executing
> dma_configure(), the deferred probe workqueue can concurrently pick up
> the same device, enter really_probe(), set dev->driver, and execute
> dma_configure(). Is it worth protecting against this?
Yes, it's certainly still possible to hit a false-positive if thread A
in iommu_device_register()->bus_iommu_probe() races against thread B
attempting to bind, simply because thread B can set dev->driver long
before it gets to any point where ends up serialising on
iommu_probe_device_lock again, so thread A can observe that even while
it is doing the IOMMU probe in the "correct" context. Other than the
warning though, it's still functionally OK even if the "wrong" thread
does end up finishing the probe, at least after 0c8e9c148e29 ("iommu:
Avoid introducing more races").
> I can try to prove it if needed, using a downstream iommu driver (sigh).
>
> Thanks!
> ta
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index e61927b4d41f..5f0c1a8064b5 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -461,9 +461,19 @@ static int iommu_init_device(struct device *dev)
> * already having a driver bound means dma_configure has already run and
> * found no IOMMU to wait for, so there's no point calling it again.
> */
> - if (!dev->iommu->fwspec && !dev->driver && dev->bus->dma_configure) {
> + if (!dev->iommu->fwspec && !READ_ONCE(dev->driver) &&
> + dev->bus->dma_configure) {
> mutex_unlock(&iommu_probe_device_lock);
> - dev->bus->dma_configure(dev);
> +
> + /*
> + * Serialize with really_probe(). Recheck dev->driver in case a
> + * driver bound while we were waiting for the lock.
> + */
> + device_lock(dev);
> + if (!dev->driver)
> + dev->bus->dma_configure(dev);
> + device_unlock(dev);
Much as I can't wait to get rid of iommu_probe_device_lock, the main
reason we still can't rely on device_lock() at the moment is not
actually the remaining sketchy replay-dependers per the comment in
__iommu_probe_device(), but more fundamentally that for most IOMMU
drivers this will deadlock in that same
iommu_device_register()->bus_iommu_probe() path, when the bus walk
happens to stumble across the IOMMU device itself, which of course is
already locked as it's still in the middle of its own driver bind. I
couldn't see an easy, clean and reliable way to get around that, so that
can got kicked down the road in order to get the "call of_xlate in the
right order and make iommu_device_register() actually work" basics
landed (and start shaking out all these other problems...)
Thanks,
Robin.
> +
> mutex_lock(&iommu_probe_device_lock);
> /* If another instance finished the job for us, skip it */
> if (!dev->iommu || dev->iommu_group)
> (END)
^ permalink raw reply
* Re: [PATCH v2 3/4] iio: adc: xilinx-xadc: Add I2C interface support
From: Jonathan Cameron @ 2026-03-23 20:26 UTC (permalink / raw)
To: Sai Krishna Potthuri
Cc: David Lechner, Nuno Sa, Andy Shevchenko, Michal Simek,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-arm-kernel, linux-kernel, saikrishna12468, git
In-Reply-To: <20260323074505.3853353-4-sai.krishna.potthuri@amd.com>
On Mon, 23 Mar 2026 13:15:04 +0530
Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> wrote:
> Add I2C interface support for Xilinx System Management Wizard IP along
> with the existing AXI memory-mapped interface. This support enables
> monitoring the voltage and temperature on UltraScale+ devices where the
> System Management Wizard is connected via I2C.
>
> Key changes:
> - Implement 32-bit DRP(Dynamic Reconfiguration Port) packet format as per
> Xilinx PG185 specification.
> - Add separate I2C probe with xadc_i2c_of_match_table to handle same
> compatible string("xlnx,system-management-wiz-1.3") on I2C bus.
> - Implement delayed version of hardware initialization for I2C interface
> to handle the case where System Management Wizard IP is not ready during
> the I2C probe.
> - Add NULL checks for get_dclk_rate callback function in sampling rate
> functions to support interfaces without clock control
> - Create separate iio_info structure(xadc_i2c_info) without event
> callbacks for I2C devices
> - Add xadc_i2c_transaction() function to handle I2C read/write operations
> - Add XADC_TYPE_US_I2C type to distinguish I2C interface from AXI
>
> Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
Hi.
A few minor things inline.
Thanks,
Jonathan
> ---
> drivers/iio/adc/Kconfig | 15 ++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/xilinx-xadc-core.c | 28 +++-
> drivers/iio/adc/xilinx-xadc-i2c.c | 215 +++++++++++++++++++++++++++++
> drivers/iio/adc/xilinx-xadc.h | 1 +
> 5 files changed, 256 insertions(+), 4 deletions(-)
> create mode 100644 drivers/iio/adc/xilinx-xadc-i2c.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index a4a7556f4016..5a3956a5c086 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -1767,6 +1767,21 @@ config XILINX_XADC
> The driver can also be build as a module. If so, the module will be called
> xilinx-xadc.
>
> +config XILINX_XADC_I2C
> + tristate "Xilinx System Management Wizard I2C Interface support"
> + depends on I2C
> + select XILINX_XADC_CORE
> + help
> + Say yes here to allow accessing the System Management
> + Wizard on UltraScale+ devices via I2C.
> +
> + This provides voltage and temperature monitoring capabilities
> + through the same IIO sysfs interface, but using I2C communication
> + protocol.
> +
> + The driver can also be build as a module. If so, the module will be called
line is a little too long for Kconfig.
> + xilinx-xadc-i2c.
> +
>
> diff --git a/drivers/iio/adc/xilinx-xadc-i2c.c b/drivers/iio/adc/xilinx-xadc-i2c.c
> new file mode 100644
> index 000000000000..3d802b907260
> --- /dev/null
> +++ b/drivers/iio/adc/xilinx-xadc-i2c.c
> @@ -0,0 +1,215 @@
> +static int xadc_i2c_read_transaction(struct xadc *xadc, unsigned int reg, u16 *val)
> +{
> + struct xadc_i2c *xadc_i2c = container_of(xadc, struct xadc_i2c, xadc);
> + char write_buffer[XADC_I2C_WRITE_DATA_SIZE] = { 0 };
> + struct i2c_client *client = xadc_i2c->client;
> + char read_buffer[XADC_I2C_READ_DATA_SIZE];
> + int ret;
> +
> + write_buffer[2] = FIELD_GET(XADC_I2C_DRP_ADDR_MASK, reg);
> + write_buffer[3] = XADC_I2C_INSTR_READ;
> +
> + ret = i2c_master_send(client, write_buffer, XADC_I2C_WRITE_DATA_SIZE);
> + if (ret < 0)
> + return ret;
> +
> + ret = i2c_master_recv(client, read_buffer, XADC_I2C_READ_DATA_SIZE);
> + if (ret < 0)
> + return ret;
> +
> + *val = FIELD_PREP(XADC_I2C_DRP_DATA0_MASK, read_buffer[0]) |
> + FIELD_PREP(XADC_I2C_DRP_DATA1_MASK, read_buffer[1]);
> +
> + return 0;
> +}
> +
> +static int xadc_i2c_write_transaction(struct xadc *xadc, unsigned int reg, u16 val)
> +{
> + struct xadc_i2c *xadc_i2c = container_of(xadc, struct xadc_i2c, xadc);
> + struct i2c_client *client = xadc_i2c->client;
> + char write_buffer[XADC_I2C_WRITE_DATA_SIZE];
> + int ret;
> +
> + write_buffer[0] = FIELD_GET(XADC_I2C_DRP_DATA0_MASK, val);
> + write_buffer[1] = FIELD_GET(XADC_I2C_DRP_DATA1_MASK, val);
This is odd enough it might be useful to have some comments. Why do
we need to write the value to two places for instance?
> + write_buffer[2] = FIELD_GET(XADC_I2C_DRP_ADDR_MASK, reg);
> + write_buffer[3] = XADC_I2C_INSTR_WRITE;
> +
> + ret = i2c_master_send(client, write_buffer, XADC_I2C_WRITE_DATA_SIZE);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int xadc_hardware_init(struct xadc *xadc)
> +{
> + struct xadc_i2c *xadc_i2c = container_of(xadc, struct xadc_i2c, xadc);
> + int ret;
> + u32 i;
> +
> + for (i = 0; i < ARRAY_SIZE(xadc->threshold); i++) {
for (u32 i = 0;
Though why a u32? If size doesn't matter, convention is pretty much always
use a unsigned int for the iterator.
> + ret = xadc_i2c_read_transaction(xadc, XADC_REG_THRESHOLD(i),
> + &xadc->threshold[i]);
> + if (ret)
> + return ret;
> + }
> +
> + ret = xadc_i2c_write_transaction(xadc, XADC_REG_CONF0, xadc_i2c->conf0);
> + if (ret)
> + return ret;
> +
> + ret = xadc_i2c_write_transaction(xadc, XADC_REG_INPUT_MODE(0),
> + xadc_i2c->bipolar_mask);
> + if (ret)
> + return ret;
> +
> + ret = xadc_i2c_write_transaction(xadc, XADC_REG_INPUT_MODE(1),
> + xadc_i2c->bipolar_mask >> XADC_INPUT_MODE_BITS);
> + if (ret)
> + return ret;
> +
> + xadc_i2c->hw_initialized = true;
> +
> + return 0;
> +}
> +
> +static int xadc_i2c_read_reg(struct xadc *xadc, unsigned int reg, u16 *val)
> +{
> + struct xadc_i2c *xadc_i2c = container_of(xadc, struct xadc_i2c, xadc);
> +
> + if (!xadc_i2c->hw_initialized) {
> + int ret;
> +
> + ret = xadc_hardware_init(xadc);
> + if (ret)
> + return ret;
> + }
> +
> + return xadc_i2c_read_transaction(xadc, reg, val);
> +}
> +
> +static int xadc_i2c_write_reg(struct xadc *xadc, unsigned int reg, u16 val)
> +{
> + struct xadc_i2c *xadc_i2c = container_of(xadc, struct xadc_i2c, xadc);
> +
> + if (!xadc_i2c->hw_initialized) {
Seems like this is always called once on first access?
If so just do it form probe and simplify the read/ write_reg() functions.
> + int ret;
> +
> + ret = xadc_hardware_init(xadc);
> + if (ret)
> + return ret;
> + }
> +
> + return xadc_i2c_write_transaction(xadc, reg, val);
> +}
> +static int xadc_i2c_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + unsigned int conf0, bipolar_mask;
> + const struct xadc_ops *ops;
> + struct iio_dev *indio_dev;
> + struct xadc_i2c *xadc_i2c;
> + struct xadc *xadc;
> + int ret;
> +
> + indio_dev = xadc_device_setup(dev, sizeof(*xadc_i2c), &ops);
> + if (IS_ERR(indio_dev))
> + return PTR_ERR(indio_dev);
> +
> + xadc_i2c = iio_priv(indio_dev);
> + xadc_i2c->client = client;
> + xadc = &xadc_i2c->xadc;
> + xadc->clk = NULL;
> + xadc->ops = ops;
> + mutex_init(&xadc->mutex);
For new code (feel free to update the other code in a separate patch).
ret = devm_mutex_init(xadc->mutex);
if (ret)
return ret;
As gives a small amount of lock debugging infrastructure and is now
cheap to do. The devm form didn't used to exist.
> + spin_lock_init(&xadc->lock);
> +
> + ret = xadc_device_configure(dev, indio_dev, 0, &conf0, &bipolar_mask);
> + if (ret) {
> + dev_err(dev, "Failed to setup the device: %d\n", ret);
> + return ret;
return dev_err_probe(dev, "Failed to setup the device.\n");
Which will pretty print the error and hide it if -EPROBEDEFER (because that should
be silent) or -ENOMEM (because memory allocation errors are very noisy anyway!)
> + }
> +
> + i2c_set_clientdata(client, indio_dev);
> + xadc_i2c->conf0 = conf0;
> + xadc_i2c->bipolar_mask = bipolar_mask;
> + xadc_i2c->hw_initialized = false;
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
^ permalink raw reply
* Re: [PATCH net-next 0/8] net: stmmac: improve PCS support
From: Mohd Ayaan Anwar @ 2026-03-23 20:23 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Konrad Dybcio, Andrew Lunn, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-arm-msm, linux-stm32, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <abwSHGw39FTJGNb7@shell.armlinux.org.uk>
Hi,
On Thu, Mar 19, 2026 at 03:11:24PM +0000, Russell King (Oracle) wrote:
> On Thu, Mar 19, 2026 at 02:50:29PM +0100, Konrad Dybcio wrote:
> > On 3/19/26 1:58 PM, Russell King (Oracle) wrote:
> > > On Thu, Mar 19, 2026 at 11:09:33AM +0100, Konrad Dybcio wrote:
> > >> On 3/19/26 10:24 AM, Russell King (Oracle) wrote:
> > >>> On Thu, Mar 19, 2026 at 12:35:58AM +0000, Russell King (Oracle) wrote:
> > >>>> On Thu, Mar 19, 2026 at 03:42:05AM +0530, Mohd Ayaan Anwar wrote:
> > >>>>> [ 8.650486] qcom-ethqos 23040000.ethernet: clk_csr value out of range (0xffffff00 exceeds mask 0x00000f00), truncating
> > >>>>
> > >>>> Please look into this first - with the MDIO bus operating at
> > >>>> who-knows-what frequency, this could make reading from the PHY
> > >>>> unreliable.
> > >>>
> > >>> My guess is clk_get_rate(priv->plat->stmmac_clk) is returning zero,
> > >>> which means we don't know the rate of the CSR clock.
> > >>>
> > >>> From what I can see in drivers/clk/qcom/gcc-qcs404.c and
> > >>> drivers/clk/qcom/gcc-sdx55.c, this looks like this case - the
> > >>> struct clk_branch makes no mention of any clock rate, nor does it
> > >>> have any parent. From what I can see, neither of these drivers
> > >>> specify any rates for any of their clocks, which likely means that
> > >>> clk_get_rate() will be zero for all of them.
> > >>>
> > >>> Sadly, when I designed the clk API, I didn't think that people would
> > >>> be stupid enough not to implement the API properly, more fool me.
> > >>>
> > >>> Under the old code, we would've used STMMAC_CSR_20_35M, which means
> > >>> we're assuming that the CSR clock is between 20 and 35MHz, even
> > >>> though the value is zero. Is that the case? If it's higher than
> > >>> 35MHz, then you've been operating the MDIO bus out of IEEE 802.3
> > >>> specification, which can make PHY access unrealible.
> > >>>
> > >>> In any case, please fix your clock drivers.
> > >>
> > >> I'm not 100% sure the currently-passed AXI clock is what we want
> > >> there and the docs aren't super helpful.. is there a synopsys-name
> > >> for it? What rates would you expect it to run at?
> > >
> > > There is no easy answer to that - it depends on the bus interfaces
> > > and whether the CSR (register) clock is separate.
> > >
> > > The likely possible names are hclk_i (for AHB master), aclk_i (for
> > > AXI master), or clk_csr_i.
> > >
> > > It does state that the CSR clock should have a minimum frequency of
> > > 25MHz to allow all statistics to be properly collected.
> > >
> > > The rate of the CSR clock needs to be known, as selecting the divider
> > > for generating MDC within IEEE 802.3 specifications is rather
> > > fundamental. You may find something there which hints at what rate
> > > the dwmac's CSR clock runs at.
> >
> > If it's either AXI or AHB, in both cases their direct parent is controlled
> > by an entity external to Linux and their rates may change at runtime,
> > based on aggregated needs of the bus. They're defined as levels/corners
> > (abstract term for a hidden volt+freq combo).
> >
> > It may be that the operating range for the EMAC removes that variability,
> > but with no concrete evidence and just anecdotal experience, that's only
> > the case for the AHB clock
>
> The important thing is that the MDC doesn't exceed the max clock
> frequency for the PHY and any other device connected to the MDIO
> bus. IEEE 802.3 specifies a max frequency of 2.5MHz (minimum period
> for MDC shall be 400 ns). Some PHYs can operate in excess of this,
> but one would need to confirm that all devices on the MDIO bus
> supports higher frequencies before using them. In the kernel, we
> generally err on the side of caution and stick to IEEE 802.3.
>
> There are two ways to achieve the divider value with stmmac.
>
> 1. if priv->plat->csr_clk is set to a value other than -1, this
> configures the hardware divisor (for "normal" cores, it takes
> STMMAC_CSR_* constants that can be found in include/linux/stmmac.h)
>
> 2. otherwise, the rate of priv->plat->stmmac_clk is used as the CSR
> clock value, which is the reference clock for the divider that
> generates the MDC clock, and an appropriate divider is selected.
> Given the available dividers, it works out at between 1.25MHz for
> a CSR clock of just over 20MHz and 2.47MHz for 800MHz. (I have a
> patch which documents the ranges for each of the STMMAC_CSR_xxx
> values.)
>
> Note that the dividier constants are not the actual divider itself,
> as can be seen in include/linux/stmmac.h
>
As noted by Konrad, the AXI and AHB clock rates are indeed unknown to
the Linux kernel:
[ 7.739389] [DBG] priv->plat->stmmac_clk rate = 0
[ 7.739391] [DBG] priv->plat->pclk rate = 0
Additionally, here's what I found (focusing on QCS9100 Ride R3, but
most of this should be applicable to all qcom-ethqos consumers):
1. clk_csr_i is connected to the SLV_AHB clock, named "pclk" in the
devicetree. This is the source for the MDC. The "stmmaceth" clock,
provided by AXI, is used for data transfers. It appears that the
devicetree gets it in reverse as per the stmmac clock
documentation added by Russell, i.e., the right order would be:
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 147ebf9b1ac6..f1aa2490bf6b 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -7111,10 +7111,10 @@ ethernet0: ethernet@23040000 {
interrupts = <GIC_SPI 946 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 782 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "macirq", "sfty";
- clocks = <&gcc GCC_EMAC0_AXI_CLK>,
- <&gcc GCC_EMAC0_SLV_AHB_CLK>,
+ clocks = <&gcc GCC_EMAC0_SLV_AHB_CLK>,
+ <&gcc GCC_EMAC0_AXI_CLK>,
<&gcc GCC_EMAC0_PTP_CLK>,
<&gcc GCC_EMAC0_PHY_AUX_CLK>;
clock-names = "stmmaceth",
"pclk",
2. However, even with the correct naming, clk_get_rate() would return
0 for both clocks since they are firmware-managed.
3. For GCC_EMAC0_SLV_AHB_CLK, the hardware documentation mentions the
range of 50 - 100 MHz. I am trying to check if there's any chance
of it turboing to a higher rate. For now, I think we can assume
this to be the working range.
In view of this, would setting priv->plat->clk_csr to
STMMAC_CSR_60_100M from the glue layer be correct?
Ayaan
^ permalink raw reply related
* Re: [PATCH 1/4] dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
From: Daniel Baluta @ 2026-03-23 20:20 UTC (permalink / raw)
To: Rob Herring
Cc: Peng Fan (OSS), Bjorn Andersson, Mathieu Poirier,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260323191529.GA1054724-robh@kernel.org>
On Mon, Mar 23, 2026 at 9:16 PM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Mar 12, 2026 at 08:36:56PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > Cortex-M[7,33] processors use a fixed reset vector table format:
> >
> > 0x00 Initial SP value
> > 0x04 Reset vector
> > 0x08 NMI
> > 0x0C ...
> > ...
> > IRQ[n]
> >
> > In ELF images, the corresponding layout is:
> >
> > reset_vectors: --> hardware reset address
> > .word __stack_end__
> > .word Reset_Handler
> > .word NMI_Handler
> > .word HardFault_Handler
> > ...
> > .word UART_IRQHandler
> > .word SPI_IRQHandler
> > ...
> >
> > Reset_Handler: --> ELF entry point address
> > ...
> >
> > The hardware fetches the first two words from reset_vectors and populates
> > SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
> > Reset_Handler.
> >
> > However, the ELF entry point does not always match the hardware reset
> > address. For example, on i.MX94 CM33S:
> >
> > ELF entry point: 0x0ffc211d
> > CM33S hardware reset base: 0x0ffc0000
> >
> > To derive the correct hardware reset address, the unused lower bits must
> > be masked off. The boot code should apply a SoC‑specific mask before
> > programming the reset address registers, e.g.:
> >
> > reset_address = entry & reset-vector-mask
> >
> > This reset address derivation method is also applicable to i.MX8M
> > Cortex-M7/4 cores.
> >
> > Introduces the optional DT property `fsl,reset-vector-mask` to specify the
> > mask used for deriving the hardware reset address from
> > the ELF entry point.
>
> Why can't you fix the ELF image to have the right address?
This is a good suggestion! Or parse the ELF file and figure out the
reset address at runtime.
>
> Or just imply the reset address from the compatible? It's fixed per SoC,
> right?
This won't work because for the same SoC depending on where you want
to boot from (e.g ITCM, DRAM)
the reset address might be different.
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: adc: meson-saradc: add support for Meson S4
From: Jonathan Cameron @ 2026-03-23 20:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Nick Xie, neil.armstrong, khilman, martin.blumenstingl, jbrunet,
dlechner, andy, krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260323-quizzical-striped-husky-68e24e@quoll>
On Mon, 23 Mar 2026 08:54:21 +0100
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Mar 23, 2026 at 09:34:06AM +0800, Nick Xie wrote:
> > Add support for the SARADC found on the Amlogic Meson S4 SoC.
> > According to the documentation and current testing, it is fully
> > compatible with the G12A parameter set, so we reuse
> > `meson_sar_adc_g12a_data` for this new compatible string.
> >
> > Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > Signed-off-by: Nick Xie <nick@khadas.com>
> > ---
> > drivers/iio/adc/meson_saradc.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> > index 47cd350498a0d..3ac48b7842c4f 100644
> > --- a/drivers/iio/adc/meson_saradc.c
> > +++ b/drivers/iio/adc/meson_saradc.c
> > @@ -1313,6 +1313,11 @@ static const struct meson_sar_adc_data meson_sar_adc_g12a_data = {
> > .name = "meson-g12a-saradc",
> > };
> >
> > +static const struct meson_sar_adc_data meson_sar_adc_s4_data = {
> > + .param = &meson_sar_adc_g12a_param,
> > + .name = "meson-s4-saradc",
> > +};
> > +
> > static const struct of_device_id meson_sar_adc_of_match[] = {
> > {
> > .compatible = "amlogic,meson8-saradc",
> > @@ -1341,6 +1346,9 @@ static const struct of_device_id meson_sar_adc_of_match[] = {
> > }, {
> > .compatible = "amlogic,meson-g12a-saradc",
> > .data = &meson_sar_adc_g12a_data,
> > + }, {
> > + .compatible = "amlogic,meson-s4-saradc",
>
> The point of compatible devices is to not add such entries. Drop.
It's used for naming in the userspace ABI which is supposed to reflect the part number.
I don't hugely mind the names reported showing the compatible part.
Jonathan
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v3 01/12] dt-bindings: phy: rockchip-usbdp: add improved ports scheme
From: Rob Herring (Arm) @ 2026-03-23 20:00 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Yubing Zhang, Heiko Stuebner, linux-arm-kernel, Neil Armstrong,
Conor Dooley, Alexey Charkov, linux-phy, linux-rockchip,
linux-kernel, Andy Yan, kernel, Krzysztof Kozlowski, devicetree,
Frank Wang, Dmitry Baryshkov, Vinod Koul
In-Reply-To: <20260313-rockchip-usbdp-cleanup-v3-1-3e8fe89a35b5@collabora.com>
On Fri, 13 Mar 2026 18:57:10 +0100, Sebastian Reichel wrote:
> Currently the Rockchip USBDP PHY is missing a documented port scheme.
> Meanwhile upstream RK3588 DTS files are a bit messy and use different
> port schemes. The upstream USBDP PHY Linux kernel driver does not yet
> parse the ports at all and thus does not create any implicit ABI either.
>
> But with the current mess it is not possible to properly support USB-C
> DP AltMode. Thus this introduces a proper port scheme following roughly
> the ports design of the Qualcomm QMP USB4-USB3-DP PHY controller binding
> with a slight difference that there is an additional port for the
> USB-C SBU port as the Rockchip USB-DP PHY also contains the SBU mux.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> .../bindings/phy/phy-rockchip-usbdp.yaml | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: mm: Handle invalid large leaf mappings correctly
From: Kevin Brodsky @ 2026-03-23 19:56 UTC (permalink / raw)
To: Ryan Roberts, Catalin Marinas, Will Deacon,
David Hildenbrand (Arm), Dev Jain, Yang Shi, Suzuki K Poulose,
Jinjiang Tu
Cc: linux-arm-kernel, linux-kernel, stable
In-Reply-To: <e36d3b17-dc66-466e-9446-692592e5d7f2@arm.com>
On 23/03/2026 18:25, Ryan Roberts wrote:
>>> @@ -132,11 +137,12 @@ static int __change_memory_common(unsigned long start, unsigned long size,
>>> ret = update_range_prot(start, size, set_mask, clear_mask);
>>>
>>> /*
>>> - * If the memory is being made valid without changing any other bits
>>> - * then a TLBI isn't required as a non-valid entry cannot be cached in
>>> - * the TLB.
>>> + * If the memory is being switched from present-invalid to valid without
>>> + * changing any other bits then a TLBI isn't required as a non-valid
>>> + * entry cannot be cached in the TLB.
>>> */
>>> - if (pgprot_val(set_mask) != PTE_VALID || pgprot_val(clear_mask))
>>> + if (pgprot_val(set_mask) != (PTE_MAYBE_NG | PTE_VALID) ||
>> It isn't obvious to understand where all those PTE_MAYBE_NG come from if
>> one hasn't realised that PTE_PRESENT_INVALID overlays PTE_NG.
>>
>> Since for this purpose we always set/clear both PTE_VALID and
>> PTE_MAYBE_NG, maybe we could define some macro as PTE_VALID |
>> PTE_MAYBE_NG, as a counterpart to PTE_PRESENT_INVALID?
> How about:
>
> #define PTE_PRESENT_VALID_KERNEL (PTE_VALID | PTE_MAYBE_NG)
>
> The user space equivalent has NG clear, so important to clarify that this is the
> kernel value, I think.
Sounds good to me.
- Kevin
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
From: Conor Dooley @ 2026-03-23 19:48 UTC (permalink / raw)
To: nick.hawkins
Cc: Catalin Marinas, Will Deacon, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jean-Marie Verdun, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260323194223.683487-2-nick.hawkins@hpe.com>
[-- Attachment #1: Type: text/plain, Size: 2446 bytes --]
On Mon, Mar 23, 2026 at 02:42:21PM -0500, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Add the HPE GSC ARM64 BMC SoC compatibles to the existing
> hpe,gxp.yaml binding.
>
> The initial board compatible is hpe,gsc-dl340gen12 for the DL340 Gen12
> server platform.
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
> Documentation/devicetree/bindings/arm/hpe,gxp.yaml | 7 ++++++-
> MAINTAINERS | 7 +++++++
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/hpe,gxp.yaml b/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
> index 224bbcb93f95..6f057cd58571 100644
> --- a/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
> +++ b/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/arm/hpe,gxp.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: HPE BMC GXP platforms
> +title: HPE BMC GXP and GSC platforms
>
> maintainers:
> - Nick Hawkins <nick.hawkins@hpe.com>
> @@ -18,6 +18,11 @@ properties:
> - enum:
> - hpe,gxp-dl360gen10
> - const: hpe,gxp
> + - description: GSC Based Boards
> + items:
> + - enum:
> + - hpe,gsc-dl340gen12
> + - const: hpe,gsc
>
> required:
> - compatible
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2265e2c9bfbe..33e4357f9011 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2859,6 +2859,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git
> F: arch/arm/mach-sa1100/include/mach/jornada720.h
> F: arch/arm/mach-sa1100/jornada720.c
>
> +ARM64/HPE GSC ARCHITECTURE
> +M: Nick Hawkins <nick.hawkins@hpe.com>
> +S: Maintained
> +F: Documentation/devicetree/bindings/arm/hpe,gxp.yaml
> +F: arch/arm64/Kconfig.platforms
That doesn't look like a file that "belongs" to you.
> +F: arch/arm64/boot/dts/hpe/
And both of the other two belong to the entry right below this one, that
already has your name on it. I don't understand why this MAINTAINERS
entry is needed.
> +
> ARM/HPE GXP ARCHITECTURE
Couldn't you just modify this to "GXP/GSC"?
Binding change looks fine...
Conor.
> M: Jean-Marie Verdun <verdun@hpe.com>
> M: Nick Hawkins <nick.hawkins@hpe.com>
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 17/17] spi: zynqmp-gqspi: Simplify clock handling with devm_clk_get_enabled()
From: Mark Brown @ 2026-03-23 19:46 UTC (permalink / raw)
To: Pei Xiao
Cc: linux-spi, linux-arm-kernel, linux-kernel, imx, openbmc,
linux-rockchip, linux-riscv, linux-mediatek, linux-stm32,
Frank.Li, amelie.delaunay
In-Reply-To: <611b4c4b67aaa8d86a7aeba9707ada47e6fd5dc3.1773885292.git.xiaopei01@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
On Thu, Mar 19, 2026 at 10:04:13AM +0800, Pei Xiao wrote:
> Replace devm_clk_get() followed by clk_prepare_enable() with
> devm_clk_get_enabled() for both "pclk" and "ref_clk". This removes
> the need for explicit clock enable and disable calls, as the managed
> API automatically disables the clocks on device removal or probe
> failure.
Another runtime PM.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 2/2] arm64: dts: hisilicon: Rename dwmmc nodes to mmc
From: Bhargav Joshi @ 2026-03-23 19:44 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, xuwei5, robh, krzk+dt, conor+dt,
ulf.hansson, zhangfei.gao, linux-mmc
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, rougueprince47
In-Reply-To: <20260323194400.22886-1-rougueprince47@gmail.com>
The core mmc devicetree schema expects mmc controller nodes to be named
using '^mmc(@.*)?$' pattern.
The legacy Hisilicon SoC files (hi3660, hi3670, and hi6220) previously
used the 'dwmmc' prefix for their nodes. This caused warnings during
dtbs_check.
Rename the 'dwmmc' nodes to 'mmc' to comply with the standard schema and
dtbs_check warnings. The legacy phandle labels are kept intact.
Signed-off-by: Bhargav Joshi <rougueprince47@gmail.com>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 ++--
arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 4 ++--
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 957a1b41f19b..374aa173bec6 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -1057,7 +1057,7 @@ ufs: ufs@ff3b0000 {
};
/* SD */
- dwmmc1: dwmmc1@ff37f000 {
+ dwmmc1: mmc@ff37f000 {
compatible = "hisilicon,hi3660-dw-mshc";
reg = <0x0 0xff37f000 0x0 0x1000>;
#address-cells = <1>;
@@ -1075,7 +1075,7 @@ dwmmc1: dwmmc1@ff37f000 {
};
/* SDIO */
- dwmmc2: dwmmc2@ff3ff000 {
+ dwmmc2: mmc@ff3ff000 {
compatible = "hisilicon,hi3660-dw-mshc";
reg = <0x0 0xff3ff000 0x0 0x1000>;
#address-cells = <0x1>;
diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
index 886b93c5893a..0db1849a2878 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
@@ -679,7 +679,7 @@ ufs: ufs@ff3c0000 {
};
/* SD */
- dwmmc1: dwmmc1@ff37f000 {
+ dwmmc1: mmc@ff37f000 {
compatible = "hisilicon,hi3670-dw-mshc",
"hisilicon,hi3660-dw-mshc";
reg = <0x0 0xff37f000 0x0 0x1000>;
@@ -698,7 +698,7 @@ dwmmc1: dwmmc1@ff37f000 {
};
/* SDIO */
- dwmmc2: dwmmc2@fc183000 {
+ dwmmc2: mmc@fc183000 {
compatible = "hisilicon,hi3670-dw-mshc",
"hisilicon,hi3660-dw-mshc";
reg = <0x0 0xfc183000 0x0 0x1000>;
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index f8b56d443850..61eaa7f8c1c9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -799,7 +799,7 @@ mailbox: mailbox@f7510000 {
#mbox-cells = <3>;
};
- dwmmc_0: dwmmc0@f723d000 {
+ dwmmc_0: mmc@f723d000 {
compatible = "hisilicon,hi6220-dw-mshc";
reg = <0x0 0xf723d000 0x0 0x1000>;
interrupts = <0x0 0x48 0x4>;
@@ -812,7 +812,7 @@ dwmmc_0: dwmmc0@f723d000 {
&emmc_cfg_func &emmc_rst_cfg_func>;
};
- dwmmc_1: dwmmc1@f723e000 {
+ dwmmc_1: mmc@f723e000 {
compatible = "hisilicon,hi6220-dw-mshc";
hisilicon,peripheral-syscon = <&ao_ctrl>;
reg = <0x0 0xf723e000 0x0 0x1000>;
@@ -828,7 +828,7 @@ dwmmc_1: dwmmc1@f723e000 {
pinctrl-1 = <&sd_pmx_idle &sd_clk_cfg_idle &sd_cfg_idle>;
};
- dwmmc_2: dwmmc2@f723f000 {
+ dwmmc_2: mmc@f723f000 {
compatible = "hisilicon,hi6220-dw-mshc";
reg = <0x0 0xf723f000 0x0 0x1000>;
interrupts = <0x0 0x4a 0x4>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 12/17] spi: stm32-qspi: Simplify clock handling with devm_clk_get_enabled()
From: Mark Brown @ 2026-03-23 19:44 UTC (permalink / raw)
To: Pei Xiao
Cc: linux-spi, linux-arm-kernel, linux-kernel, imx, openbmc,
linux-rockchip, linux-riscv, linux-mediatek, linux-stm32,
Frank.Li, amelie.delaunay
In-Reply-To: <333b09950ee5c2fc0e560536281afb33f92288d1.1773885292.git.xiaopei01@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
On Thu, Mar 19, 2026 at 10:04:08AM +0800, Pei Xiao wrote:
> Replace devm_clk_get() followed by clk_prepare_enable() with
> devm_clk_get_enabled() for the clock. This removes the need for
> explicit clock enable and disable calls, as the managed API automatically
> handles clock disabling on device removal or probe failure.
More runtime PM.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 1/2] dt-bindings: mmc: hisilicon,hi3660-dw-mshc: Convert to DT schema
From: Bhargav Joshi @ 2026-03-23 19:43 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, xuwei5, robh, krzk+dt, conor+dt,
ulf.hansson, zhangfei.gao, linux-mmc
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, rougueprince47
In-Reply-To: <20260323194400.22886-1-rougueprince47@gmail.com>
Convert the Hisilicon DesignWare Mobile Storage Host Controller
(dw-mshc) bindings from text format to DT schema.
As part of this conversion, the binding file is renamed from
k3-dw-mshc.txt to hisilicon,hi3660-dw-mshc.yaml to align with compatible
string naming conventions.
Examples have been updated to pass schema validation.
Signed-off-by: Bhargav Joshi <rougueprince47@gmail.com>
---
.../mmc/hisilicon,hi3660-dw-mshc.yaml | 111 ++++++++++++++++++
.../devicetree/bindings/mmc/k3-dw-mshc.txt | 73 ------------
2 files changed, 111 insertions(+), 73 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml
delete mode 100644 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml
new file mode 100644
index 000000000000..6ba1a42a27ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/hisilicon,hi3660-dw-mshc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon specific extensions to the Synopsys Designware Mobile Storage Host Controller
+
+maintainers:
+ - Zhangfei Gao <zhangfei.gao@linaro.org>
+
+description:
+ The Synopsys designware mobile storage host controller is used to interface
+ a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+ differences between the core Synopsys dw mshc controller properties described
+ by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific
+ extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+allOf:
+ - $ref: /schemas/mmc/synopsys-dw-mshc-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: hisilicon,hi3660-dw-mshc
+ - items:
+ - const: hisilicon,hi3670-dw-mshc
+ - const: hisilicon,hi3660-dw-mshc
+ - const: hisilicon,hi4511-dw-mshc
+ - const: hisilicon,hi6220-dw-mshc
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: card interface unit clock
+ - description: bus interface unit clock
+
+ clock-names:
+ items:
+ - const: ciu
+ - const: biu
+
+ hisilicon,peripheral-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle of syscon used to control peripheral.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/hi3620-clock.h>
+
+ mmc@fcd03000 {
+ compatible = "hisilicon,hi4511-dw-mshc";
+ reg = <0xfcd03000 0x1000>;
+ interrupts = <0 16 4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&mmc_clock HI3620_SD_CIUCLK>, <&clock HI3620_DDRC_PER_CLK>;
+ clock-names = "ciu", "biu";
+ vmmc-supply = <&ldo12>;
+ fifo-depth = <0x100>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd_pmx_pins &sd_cfg_func1 &sd_cfg_func2>;
+ bus-width = <4>;
+ disable-wp;
+ cd-gpios = <&gpio10 3 0>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ };
+
+ - |
+ #include <dt-bindings/clock/hi6220-clock.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mmc@f723e000 {
+ compatible = "hisilicon,hi6220-dw-mshc";
+ bus-width = <0x4>;
+ disable-wp;
+ cap-sd-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ card-detect-delay = <200>;
+ hisilicon,peripheral-syscon = <&ao_ctrl>;
+ reg = <0x0 0xf723e000 0x0 0x1000>;
+ interrupts = <0x0 0x49 0x4>;
+ clocks = <&clock_sys HI6220_MMC1_CIUCLK>,
+ <&clock_sys HI6220_MMC1_CLK>;
+ clock-names = "ciu", "biu";
+ cd-gpios = <&gpio1 0 1>;
+ pinctrl-names = "default", "idle";
+ pinctrl-0 = <&sd_pmx_func &sd_clk_cfg_func &sd_cfg_func>;
+ pinctrl-1 = <&sd_pmx_idle &sd_clk_cfg_idle &sd_cfg_idle>;
+ vqmmc-supply = <&ldo7>;
+ vmmc-supply = <&ldo10>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
deleted file mode 100644
index 36c4bea675d5..000000000000
--- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Hisilicon specific extensions to the Synopsys Designware Mobile
- Storage Host Controller
-
-Read synopsys-dw-mshc.txt for more details
-
-The Synopsys designware mobile storage host controller is used to interface
-a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
-differences between the core Synopsys dw mshc controller properties described
-by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific
-extensions to the Synopsys Designware Mobile Storage Host Controller.
-
-Required Properties:
-
-* compatible: should be one of the following.
- - "hisilicon,hi3660-dw-mshc": for controllers with hi3660 specific extensions.
- - "hisilicon,hi3670-dw-mshc", "hisilicon,hi3660-dw-mshc": for controllers
- with hi3670 specific extensions.
- - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions.
- - "hisilicon,hi6220-dw-mshc": for controllers with hi6220 specific extensions.
-
-Optional Properties:
-- hisilicon,peripheral-syscon: phandle of syscon used to control peripheral.
-
-Example:
-
- /* for Hi3620 */
-
- /* SoC portion */
- dwmmc_0: dwmmc0@fcd03000 {
- compatible = "hisilicon,hi4511-dw-mshc";
- reg = <0xfcd03000 0x1000>;
- interrupts = <0 16 4>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&mmc_clock HI3620_SD_CIUCLK>, <&clock HI3620_DDRC_PER_CLK>;
- clock-names = "ciu", "biu";
- };
-
- /* Board portion */
- dwmmc0@fcd03000 {
- vmmc-supply = <&ldo12>;
- fifo-depth = <0x100>;
- pinctrl-names = "default";
- pinctrl-0 = <&sd_pmx_pins &sd_cfg_func1 &sd_cfg_func2>;
- bus-width = <4>;
- disable-wp;
- cd-gpios = <&gpio10 3 0>;
- cap-mmc-highspeed;
- cap-sd-highspeed;
- };
-
- /* for Hi6220 */
-
- dwmmc_1: dwmmc1@f723e000 {
- compatible = "hisilicon,hi6220-dw-mshc";
- bus-width = <0x4>;
- disable-wp;
- cap-sd-highspeed;
- sd-uhs-sdr12;
- sd-uhs-sdr25;
- card-detect-delay = <200>;
- hisilicon,peripheral-syscon = <&ao_ctrl>;
- reg = <0x0 0xf723e000 0x0 0x1000>;
- interrupts = <0x0 0x49 0x4>;
- clocks = <&clock_sys HI6220_MMC1_CIUCLK>, <&clock_sys HI6220_MMC1_CLK>;
- clock-names = "ciu", "biu";
- cd-gpios = <&gpio1 0 1>;
- pinctrl-names = "default", "idle";
- pinctrl-0 = <&sd_pmx_func &sd_clk_cfg_func &sd_cfg_func>;
- pinctrl-1 = <&sd_pmx_idle &sd_clk_cfg_idle &sd_cfg_idle>;
- vqmmc-supply = <&ldo7>;
- vmmc-supply = <&ldo10>;
- };
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox