* Re: [PATCH v6 09/13] coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable
From: Yeoreum Yun @ 2026-05-15 13:35 UTC (permalink / raw)
To: Leo Yan
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <20260515093923.GJ34802@e132581.arm.com>
Hi Leo,
> On Wed, Apr 22, 2026 at 02:21:59PM +0100, Yeoreum Yun wrote:
>
> [...]
>
> > @@ -895,6 +895,8 @@ static int etm4_parse_event_config(struct coresight_device *csdev,
> > * Missing BB support could cause silent decode errors
> > * so fail to open if it's not supported.
> > */
> > + if (cfg_hash)
> > + cscfg_csdev_disable_active_config(csdev);
>
> I prefer do a bit refactoring for this.
>
> we just save cfg_hash and cfg_preset into drvdata in
> etm4_parse_event_config():
>
> drvdata->cfg_hash = ATTR_CFG_GET_FLD(attr, configid);
> if (drvdata->cfg_hash)
> drvdata->preset = ATTR_CFG_GET_FLD(attr, preset);
>
> Then create two helpers:
>
> etm4_cscfg_enable(csdev) {
> struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> return cscfg_csdev_enable_active_config(csdev, drvdata->cfg_hash,
> drvdata->preset);
> }
>
> etm4_cscfg_disable(csdev) {
> cscfg_csdev_disable_active_config(csdev);
> }
>
> These helpers will be used by etm4_{enable|disable}_perf()
> and etm4_{enable|disable}_sysfs(). This might benefit the future cscfg
> refactoring.
I think this seems some over-engineering since the
etm4_cscfg_enable/disable() just an wrapper for
cscfg_csdev_enable/disable_active_config() but just increase size of drvdata.
It's not late to delay when we do refactoring the cscfg
and at that time, we can consider some place to save cfg_hash and
preset. If we do right now, personally, there seems no benefit for this.
Am I missing something?
Thanks.
[...]
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH 1/3] iommu/io-pgtable-arm: Use consistent sizes for page allocation and freeing
From: Jason Gunthorpe @ 2026-05-15 13:36 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, linux-arm-kernel, linux-kernel, robin.murphy, will, joro
In-Reply-To: <20260513215203.3852661-2-smostafa@google.com>
On Wed, May 13, 2026 at 09:52:01PM +0000, Mostafa Saleh wrote:
> At the moment we use alloc_size to allocate memory but then there
> is a logical error where we just size in the error and free path,
> which might be smaller.
> Also we size to do DMA-API operations, which is OK, but confusing.
>
> Instead of this error-prone handling, just set size to alloc_size
> and use it everywhere.
>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
> drivers/iommu/io-pgtable-arm.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
This is similar to how iommupt works, pt_top_memsize_lg2() rounds up
the top table size to the alignment minimum and we just dma map
flush/etc the larger size everwhere.
Jason
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: ti: k3-j784s4: Add GPU node
From: Nishanth Menon @ 2026-05-15 13:33 UTC (permalink / raw)
To: Antonios Christidis
Cc: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260506-j784s4_gpu_node_upstream-v2-1-23d6a2565ac0@ti.com>
On 15:18-20260506, Antonios Christidis wrote:
> Add the Series BXS GPU node for j784s4 device tree.
>
Adding documentation why j721s2 compatible is correct for j784s4 is
needed.
[...]
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> index 78fcd0c40abc..ddb9385cd942 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> @@ -137,6 +137,20 @@ serdes2: serdes@5020000 {
> };
> };
>
> + gpu: gpu@4e20000000 {
https://docs.kernel.org/devicetree/bindings/dts-coding-style.html
"Nodes on any bus, thus using unit addresses for children, shall be
ordered by unit address in ascending order. Alternatively for some
subarchitectures, nodes of the same type can be grouped together,
e.g. all I2C controllers one after another even if this breaks unit
address ordering."
Any specific reason to keep this patch ordering?
> + compatible = "ti,j721s2-gpu", "img,img-bxs-4-64", "img,img-rogue";
^^ j721s2-gpu: please clarify in commit message.
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH 3/3] iommu/io-pgtable-arm: Use address conversion consistently
From: Jason Gunthorpe @ 2026-05-15 13:33 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, linux-arm-kernel, linux-kernel, robin.murphy, will, joro
In-Reply-To: <20260513215203.3852661-4-smostafa@google.com>
On Wed, May 13, 2026 at 09:52:03PM +0000, Mostafa Saleh wrote:
> Use consistent address conversions in the driver:
> - virt_to_phys(): For all virtual to physical address conversion,
> convert __pa users as we don’t need to rely on it type casting.
> - phys_to_virt(): For all physical to virtual address conversion,
> similarly, convert __va users.
>
> That changes nothing at all. However, it will be useful when
> compiling this file for the KVM hypervisor as it can cleanly
> replace virt_to_phys/phys_to_virt
>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
> drivers/iommu/io-pgtable-arm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm-smmu: qcom: Add compatible for IPQ9650 SoC
From: Kathiravan Thirumoorthy @ 2026-05-15 13:30 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel
In-Reply-To: <20260512-ipq9650_smmu_binding-v1-1-04defdaa140c@oss.qualcomm.com>
On 5/12/2026 12:17 PM, Kathiravan Thirumoorthy wrote:
> Qualcomm IPQ9650 SoC include APPS SMMU that implements arm,mmu-500.
> Document the compatible for the same.
Kindly ignore this patch. I will repost along with DTSI changes once it
is validated again!
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> index 06fb5c8e7547..226f16711d67 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> @@ -37,6 +37,7 @@ properties:
> - enum:
> - qcom,eliza-smmu-500
> - qcom,glymur-smmu-500
> + - qcom,ipq9650-smmu-500
> - qcom,kaanapali-smmu-500
> - qcom,milos-smmu-500
> - qcom,qcm2290-smmu-500
>
> ---
> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
> change-id: 20260512-ipq9650_smmu_binding-36dc05d39860
>
> Best regards,
> --
> Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>
^ permalink raw reply
* Re: [PATCH v6 02/13] coresight: etm4x: fix underflow for nrseqstate
From: Leo Yan @ 2026-05-15 13:29 UTC (permalink / raw)
To: Yeoreum Yun
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <agb/NdYS/2jXdog0@e129823.arm.com>
On Fri, May 15, 2026 at 12:10:45PM +0100, Yeoreum Yun wrote:
[...]
> TBH, the number of transition is determinied by the MAX number of
> SEQ_STATE that's why I think define the ETM_MAX_SEQ_TRANSITIONS with
>
> #define ETM_MAX_SEQ_TRANSITIONS (ETM_MAX_SEQ_STATE - 1)
>
> and uses ETM_MAX_SEQ_TRANSITIONS for the TCRSEQEVR and seq_ctrl.
>
> Thought?
Looks good to me.
^ permalink raw reply
* Re: [PATCH] i2c: davinci: fix division by zero on missing clock-frequency
From: Andrew Lunn @ 2026-05-15 13:16 UTC (permalink / raw)
To: Chaitanya Sabnis
Cc: brgl, andi.shyti, linux-arm-kernel, linux-i2c, linux-kernel,
Sashiko
In-Reply-To: <CABjkosFHLErOziCrYhJJxtpMg01t36LqAfr-zz1wE4HSZhfzFA@mail.gmail.com>
On Fri, May 15, 2026 at 02:12:43PM +0530, Chaitanya Sabnis wrote:
> Hi Andrew,
>
> That makes complete sense. Updating the macro to Hz is a much cleaner
> approach and aligns perfectly with the expected unit of the device
> tree property.
>
> I have track down the original commit for the Fixes: tag and send out a v2.
>
> Thanks for the review!
Please don't top post on mailing lists.
Andrew
^ permalink raw reply
* Re: Re: [PATCH net v1 1/2] dt-bindings: ethernet: eswin: refine delay model and HSP register description
From: Andrew Lunn @ 2026-05-15 13:14 UTC (permalink / raw)
To: 李志
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, netdev, devicetree, linux-kernel, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, linux-stm32,
linux-arm-kernel, ningyu, linmin, pinkesh.vaghela, pritesh.patel,
weishangjuan
In-Reply-To: <29bee81.8323.19e2a8bf746.Coremail.lizhi2@eswincomputing.com>
> This will help determine whether this change should remain in the net
> series or be moved to a follow-up net-next series.
net-next. It does not fix anything which is broken, and bothers
people.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: macb: add TX stall watchdog to recover from lost TCOMP interrupts
From: Lukasz Raczylo @ 2026-05-15 13:08 UTC (permalink / raw)
To: netdev
Cc: Theo Lebrun, Andrea della Porta, Nicolas Ferre, Claudiu Beznea,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <20260514215459.36109-4-lukasz@raczylo.com>
self NACK
This patch references netdev_warn_ratelimited(), which does not exist
in mainline net-next or in raspberrypi/linux rpi-6.18.y -- no
netdev_*_ratelimited() helper is defined. I confused it with the
existing net_warn_ratelimited() / pr_warn_ratelimited() /
dev_warn_ratelimited() family while authoring v2. The result fails
to build with implicit-function-declaration on every kernel that
includes <linux/netdevice.h>.
The bug was caught by John Laur via an independent build test on the
Talos Linux Pi 5 build and reported at:
https://github.com/siderolabs/sbc-raspberrypi/issues/91#issuecomment-4456874307
I incorrectly tried to address this by sending a standalone fix-up
patch to netdev as:
https://lore.kernel.org/netdev/20260515095336.92237-1-lukasz@raczylo.com/T/
Andrew Lunn pointed out that this is not the correct workflow on
netdev -- the right thing to do is self-NACK the broken patch on the
original thread, wait 24 hours, and resend the whole series as v3.
Apologies for the noise; this reply is that self-NACK.
Patches 1/3 and 2/3 do not reference netdev_warn_ratelimited() and
are unaffected by this build break; their content stands. In v3:
* 3/3 will use `if (printk_ratelimit()) netdev_warn(...)` in place
of the non-existent netdev_warn_ratelimited(), matching the
semantics intended in v2 (bounded log noise, retains the netdev
prefix in the message).
* The standalone fix-up patch above (Message-ID
<20260515095336.92237-1-lukasz@raczylo.com>) should be considered
withdrawn -- v3 supersedes it.
* Cover letter will carry a changelog noting the v2->v3 delta and
this self-NACK.
I will send v3 no earlier than 24 hours from this message, per
Andrew's guidance and standard netdev practice.
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
From: Vincent Donnefort @ 2026-05-15 12:58 UTC (permalink / raw)
To: Marc Zyngier
Cc: oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, linux-arm-kernel, kvmarm, kernel-team
In-Reply-To: <867bp5x9b8.wl-maz@kernel.org>
On Fri, May 15, 2026 at 11:21:15AM +0100, Marc Zyngier wrote:
> On Thu, 14 May 2026 17:26:24 +0100,
> Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > pKVM must validate the host-provided tracing buffer descriptor.
> > However, if an error is found, the hypervisor would just return 0 to the
> > host. Fix the return value on validation failure.
> >
> > While at it, rename the function to hyp_trace_desc_is_valid() and skip
> > validation for the nVHE mode as we trust host-provided data in that
> > case.
> >
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
>
> Fixes: tag? Should it be considered as a Cc: to stable?
>
> M.
Fixes: 680a04c333fa ("KVM: arm64: Add tracing capability for the nVHE/pKVM hyp")
It is only from 7.1 so no stable to fix.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 01/17] ACPI: GTDT: Account for GTDTv3 size when walking the platform timer descriptors
From: Sudeep Holla @ 2026-05-15 12:52 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Lorenzo Pieralisi, Hanjun Guo, Catalin Marinas, Will Deacon,
Rafael J. Wysocki, Mark Rutland, Daniel Lezcano, Thomas Gleixner,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Heiko Stuebner, Shawn Lin, Orson Zhai,
Baolin Wang, Michal Simek
In-Reply-To: <864ik8ykzd.wl-maz@kernel.org>
On Fri, May 15, 2026 at 12:23:50PM +0100, Marc Zyngier wrote:
> On Fri, 15 May 2026 10:51:52 +0100,
> Sudeep Holla <sudeep.holla@kernel.org> wrote:
> >
> > On Thu, May 14, 2026 at 04:09:29PM +0100, Marc Zyngier wrote:
> > > Since ARMv8.1, the architecture has grown an EL2-private virtual
> > > timer. This has been described in ACPI since ACPI v6.3 and revision
> > > 3 of the GTDT table.
> > >
> > > An aditional structure was added in ACPICA, though in a rather
> > > bizarre way, and merged in v5.1 as 8f5a14d053100 ("ACPICA: ACPI 6.3:
> > > add GTDT Revision 3 support").
> > >
> > > Finally plug the table parsing in GTDT, and correct the parsing of
> > > the platform timer subtables to account for the expanded size of
> > > the base table.
> > >
> > > Suggested-by: Sudeep Holla <sudeep.holla@kernel.org>
> > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > ---
> > > drivers/acpi/arm64/gtdt.c | 15 ++++++++++++++-
> > > 1 file changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
> > > index ffc867bac2d60..b9d9b8edf2df7 100644
> > > --- a/drivers/acpi/arm64/gtdt.c
> > > +++ b/drivers/acpi/arm64/gtdt.c
> > > @@ -32,6 +32,12 @@ struct acpi_gtdt_descriptor {
> > > struct acpi_table_gtdt *gtdt;
> > > void *gtdt_end;
> > > void *platform_timer;
> > > + bool v3;
> > > +};
> > > +
> > > +struct gtdt_v3 {
> > > + struct acpi_table_gtdt gtdt_v2;
> > > + struct acpi_gtdt_el2 el2_vtimer;
> > > };
> > >
> > > static struct acpi_gtdt_descriptor acpi_gtdt_desc __initdata;
> > > @@ -39,8 +45,14 @@ static struct acpi_gtdt_descriptor acpi_gtdt_desc __initdata;
> > > static __init bool platform_timer_valid(void *platform_timer)
> > > {
> > > struct acpi_gtdt_header *gh = platform_timer;
> > > + void *platform_timer_begin;
> > > +
> > > + if (acpi_gtdt_desc.v3)
> > > + platform_timer_begin = container_of(acpi_gtdt_desc.gtdt, struct gtdt_v3, gtdt_v2) + 1;
> > > + else
> > > + platform_timer_begin = acpi_gtdt_desc.gtdt + 1;
> > >
> > > - return (platform_timer >= (void *)(acpi_gtdt_desc.gtdt + 1) &&
> > > + return (platform_timer >= platform_timer_begin &&
> > > platform_timer < acpi_gtdt_desc.gtdt_end &&
> > > gh->length != 0 &&
> > > platform_timer + gh->length <= acpi_gtdt_desc.gtdt_end);
> > > @@ -169,6 +181,7 @@ int __init acpi_gtdt_init(struct acpi_table_header *table,
> > > acpi_gtdt_desc.gtdt = gtdt;
> > > acpi_gtdt_desc.gtdt_end = (void *)table + table->length;
> > > acpi_gtdt_desc.platform_timer = NULL;
> > > + acpi_gtdt_desc.v3 = gtdt->header.revision >= 3 && gtdt->header.length >= sizeof(struct gtdt_v3);
> >
> > Regarding Sashiko’s comment about the missing length validation for GTDT v2, I
> > realised that the current check could cause a malformed v3 table to be
> > interpreted as v2 if its length does not match the expected v3
> > length.
>
> Yeah, that's overall dodgy. As much as I hate having to write a
> validating parser for ACPI, we need to be prepared for the worst.
>
> > It would be better to fail early and return an error rather than allow
> > processing to continue with the table incorrectly interpreted as v2.
>
> How about something like the hack below?
>
LGTM and might please Sashiko too.
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v3 3/4] PCI: endpoint: Add API for DOE initialization and setup in EPC core
From: Manivannan Sadhasivam @ 2026-05-15 12:47 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <3853ba15-d096-4cf4-b52f-8a2e5f50fe53@ti.com>
On Fri, May 15, 2026 at 10:21:52AM +0530, Aksh Garg wrote:
>
>
> On 14/05/26 13:38, Manivannan Sadhasivam wrote:
> > On Mon, Apr 27, 2026 at 10:47:24AM +0530, Aksh Garg wrote:
> > > Add pci_epc_setup_doe() API in EPC core driver to initialize and setup
> > > the DOE framework for an endpoint controller. The API discovers the DOE
> > > capabilities (extended capability ID 0x2E), and registers each discovered
> > > DOE mailbox for all the functions in the endpoint controller. This API
> > > should be invoked by the controller driver during probe based on the
> > > doe_capable feature.
> > >
> > > Add pci_epc_destroy_doe() API in EPC core driver for cleanup of DOE
> > > resources, which should be invoked by the controller driver during
> > > controller cleanup based on the doe_capable feature.
> > >
> > > Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> > > Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> > > Signed-off-by: Aksh Garg <a-garg7@ti.com>
> > > ---
> > >
> > > Changes from v2 to v3:
> > > - Rebased on 7.1-rc1.
> > >
> > > Changes since v1:
> > > - New patch added to v2 (not present in v1)
> > >
> > > v2: https://lore.kernel.org/all/20260401073022.215805-4-a-garg7@ti.com/
> > >
> > > This patch is introduced based on the feedback provided by Manivannan
> > > Sadhasivam at [1].
> > >
> >
> > Sweet! But I was expecting you to add atleast one EPC driver implementation to
> > make use of these APIs.
> >
> > Also, why can't you call these APIs from the EPC core directly? Maybe during
> > pci_epc_init_notify() once the register accesses become valid.
>
> Can we add the DOE initialization API to pci_epc_init_notify()? This
> API seems to be called to notify the EPF drivers that the EPC device's
> initialization has been completed, as the name and description suggests.
That's correct. But there is no harm in calling something like
pci_epc_init_capabilities() inside its definition. Only concern would be that
pci_epc_init_notify() is mostly called from threaded IRQ handlers. So loading
the handler would not be recommended. But since it is threaded anyway and we
don't have a better place to call, it would be OK.
We could've called this from pci_epc_{create/start}, but some controllers won't
allow accessing CSRs without REFCLK. So only after pci_init_notify(), CSRs can
be accessed.
> As 'pci_epc_doe_setup' is a part of EPC initialization, I thought the
> EPC drivers should call this API before calling the pci_epc_init_notify().
>
> However, I agree with your suggestion to call the DOE setup API directly
> from the EPC core instead of sprinkling over the EPC drivers. I would
> recommend renaming the pci_epc_init_notify() API (and hence the
> pci_epc_deinit_notify() as well) to something like pci_epc_init_complete(),
> and add the DOE setup API/logic just before the
> logic of notifying the EPF devices.
>
No need to rename this API. Just use as is:
pci_epc_init_notify()
-> pci_epc_init_capabilities()
-> pci_epc_init_doe()
-> epf->event_ops->epc_init()
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH net-next] net: macb: fix build of TX stall watchdog by replacing undefined netdev_warn_ratelimited
From: Andrew Lunn @ 2026-05-15 12:47 UTC (permalink / raw)
To: Lukasz Raczylo
Cc: netdev, Theo Lebrun, Andrea della Porta, Nicolas Ferre,
Claudiu Beznea, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel, linux-arm-kernel,
linux-rpi-kernel
In-Reply-To: <20260515095336.92237-1-lukasz@raczylo.com>
On Fri, May 15, 2026 at 10:53:36AM +0100, Lukasz Raczylo wrote:
> netdev_warn_ratelimited() does not exist in this kernel -- neither
> mainline net-next nor raspberrypi/linux rpi-6.18.y define a
> netdev_*_ratelimited() family. I confused it with the existing
> net_warn_ratelimited() / pr_warn_ratelimited() macros when
> authoring v2 patch 3 of the macb silent TX stall series, and the
> result fails to build with implicit-function-declaration.
>
> Replace with the standard `if (printk_ratelimit()) netdev_warn(...)`
> pattern. Same semantics intended by v2 patch 3 (bounded log noise,
> retains the netdev prefix in the message); works in every kernel
> version.
>
> Fixes the build of patch 3/3 of:
What you should do is reply to patch 3/3 and say
self NACK
and explain why it is broken.
Then wait 24 hours, and send a new version of the patch series, with
patch 3/3 fixed.
Andrew
---
pw-bot: cr
^ permalink raw reply
* [PATCH] tty: serial: samsung: Remove redundant port lock acquisition in rx helpers
From: Tudor Ambarus @ 2026-05-15 12:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar, Greg Kroah-Hartman, Jiri Slaby,
Ben Dooks
Cc: linux-arm-kernel, linux-samsung-soc, linux-kernel, linux-serial,
john.ogness, peter.griffin, andre.draszik, jyescas, kernel-team,
stable, John Ogness, Tudor Ambarus
Sashiko identified a deadlock when the console flow is engaged [1].
When console flow control is enabled (UPF_CONS_FLOW),
s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and
s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable().
The serial core framework invokes the .stop_tx() and .start_tx()
callbacks with the port->lock spinlock already held. Furthermore, all
internal driver paths that invoke stop_tx (such as the DMA TX
completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ
handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to
calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the
serial core).
However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable()
unconditionally attempt to acquire port->lock again using
uart_port_lock_irqsave(). Since spinlocks are not recursive, this
causes a deadlock on the same CPU when console flow control is engaged.
Remove the redundant lock acquisition from both rx helper functions.
Cc: stable@vger.kernel.org
Fixes: b497549a035c ("[ARM] S3C24XX: Split serial driver into core and per-cpu drivers")
Reported-by: John Ogness <john.ogness@linutronix.de>
Closes: https://sashiko.dev/#/patchset/20260506121606.5805-1-john.ogness%40linutronix.de [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/tty/serial/samsung_tty.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 2f94fc798cff..63d0232dffc2 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -245,12 +245,9 @@ static bool s3c24xx_serial_txempty_nofifo(const struct uart_port *port)
static void s3c24xx_serial_rx_enable(struct uart_port *port)
{
struct s3c24xx_uart_port *ourport = to_ourport(port);
- unsigned long flags;
int count = 10000;
u32 ucon, ufcon;
- uart_port_lock_irqsave(port, &flags);
-
while (--count && !s3c24xx_serial_txempty_nofifo(port))
udelay(100);
@@ -263,23 +260,18 @@ static void s3c24xx_serial_rx_enable(struct uart_port *port)
wr_regl(port, S3C2410_UCON, ucon);
ourport->rx_enabled = 1;
- uart_port_unlock_irqrestore(port, flags);
}
static void s3c24xx_serial_rx_disable(struct uart_port *port)
{
struct s3c24xx_uart_port *ourport = to_ourport(port);
- unsigned long flags;
u32 ucon;
- uart_port_lock_irqsave(port, &flags);
-
ucon = rd_regl(port, S3C2410_UCON);
ucon &= ~S3C2410_UCON_RXIRQMODE;
wr_regl(port, S3C2410_UCON, ucon);
ourport->rx_enabled = 0;
- uart_port_unlock_irqrestore(port, flags);
}
static void s3c24xx_serial_stop_tx(struct uart_port *port)
---
base-commit: 16e95bfb79b5d9d01dc7651d98caf3c2ace331cd
change-id: 20260515-samsung-tty-flow-control-deadlock-1d426171bf41
Best regards,
--
Tudor Ambarus <tudor.ambarus@linaro.org>
^ permalink raw reply related
* Re: [PATCH v3 2/4] PCI: endpoint: Add DOE mailbox support for endpoint functions
From: Manivannan Sadhasivam @ 2026-05-15 12:40 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20dce1c6-d24d-4344-86a9-f434fe52038b@ti.com>
On Fri, May 15, 2026 at 11:05:29AM +0530, Aksh Garg wrote:
>
>
> On 14/05/26 13:33, Manivannan Sadhasivam wrote:
> > On Mon, Apr 27, 2026 at 10:47:23AM +0530, Aksh Garg wrote:
> > > DOE (Data Object Exchange) is a standard PCIe extended capability
> > > feature introduced in the Data Object Exchange (DOE) ECN for
> > > PCIe r5.0. It provides a communication mechanism primarily used for
> > > implementing PCIe security features such as device authentication, and
> > > secure link establishment. Think of DOE as a sophisticated mailbox
> > > system built into PCIe. The root complex can send structured requests
> > > to the endpoint device through DOE mailboxes, and the endpoint device
> > > responds with appropriate data.
> > >
> > > Add the DOE support for PCIe endpoint devices, enabling endpoint
> > > functions to process the DOE requests from the host. The implementation
> > > provides framework APIs for EPC core driver and controller drivers to
> > > register mailboxes, and request processing with workqueues ensuring
> > > sequential handling per mailbox, and parallel handling across mailboxes.
> > > The Discovery protocol is handled internally by the DOE core.
> > >
> > > This implementation complements the existing DOE implementation for
> > > root complex in drivers/pci/doe.c.
> > >
> > > Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> > > Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> > > Signed-off-by: Aksh Garg <a-garg7@ti.com>
> > > ---
> > > +
> > > +/*
> > > + * Global registry of protocol handlers.
> > > + * When a new DOE protocol, library is added, add an entry to this array.
> > > + */
> > > +static const struct pci_doe_protocol pci_doe_protocols[] = {
> > > + {
> > > + .vid = PCI_VENDOR_ID_PCI_SIG,
> > > + .type = PCI_DOE_FEATURE_DISCOVERY,
> > > + .handler = pci_ep_doe_handle_discovery,
> > > + },
> > > +};
> > > +
> > > +/*
> > > + * Combines function number and capability offset into a unique lookup key
> > > + * for storing/retrieving DOE mailboxes in an xarray.
> > > + */
> > > +#define PCI_DOE_MB_KEY(func, offset) \
> > > + (((unsigned long)(func) << 16) | (offset))
> > > +#define PCI_DOE_PROTOCOL_COUNT ARRAY_SIZE(pci_doe_protocols)
> > > +
> > > +/**
> > > + * pci_ep_doe_init() - Initialize the DOE framework for a controller in EP mode
> > > + * @epc: PCI endpoint controller
> > > + *
> > > + * Initialize the DOE framework data structures. This only initializes
> > > + * the xarray that will hold the mailboxes.
> > > + *
> > > + * RETURNS: 0 on success, -errno on failure
> >
> > kernel-doc format to describe return value is 'Return:' or 'Returns:".
>
> Thanks for pointing this out. I will update this.
>
> >
> > > + */
> > > +int pci_ep_doe_init(struct pci_epc *epc)
> > > +{
> > > + if (!epc)
> > > + return -EINVAL;
> > > +
> > > + xa_init(&epc->doe_mbs);
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(pci_ep_doe_init);
> > > +
>
> [...]
>
> > > +
> > > +/**
> > > + * pci_ep_doe_process_request() - Process DOE request on endpoint
> > > + * @epc: PCI endpoint controller
> > > + * @func_no: Physical function number
> > > + * @cap_offset: DOE capability offset
> > > + * @vendor: Vendor ID from request header
> > > + * @type: Protocol type from request header
> > > + * @request: Request payload in CPU-native format
> > > + * @request_sz: Size of request payload (bytes)
> > > + * @complete: Callback to invoke upon completion
> > > + *
> > > + * Asynchronously process a DOE request received on the endpoint. The request
> > > + * payload should not include the DOE header (vendor/type/length). The protocol
> > > + * handler will allocate the response buffer, which the caller (controller driver)
> > > + * must free after use.
> > > + *
> > > + * This function returns immediately after queuing the request. The completion
> > > + * callback will be invoked asynchronously from workqueue context once the
> > > + * request is processed. The callback receives the function number and capability
> > > + * offset to identify the mailbox, along with a status code (0 on success, -errno
> > > + * on failure), and other required arguments.
> > > + *
> > > + * As per DOE specification, a mailbox processes one request at a time.
> > > + * Therefore, this function will never be called concurrently for the same
> > > + * mailbox by different callers.
> > > + *
> > > + * The caller is responsible for the conversion of the received DOE request
> > > + * with le32_to_cpu() before calling this function.
> > > + * Similarly, it is responsible for converting the response payload with
> > > + * cpu_to_le32() before sending it back over the DOE mailbox.
> > > + *
> > > + * The caller is also responsible for ensuring that the request size
> > > + * is within the limits defined by PCI_DOE_MAX_LENGTH.
> > > + *
> > > + * RETURNS: 0 if the request was successfully queued, -errno on failure
> > > + */
> > > +int pci_ep_doe_process_request(struct pci_epc *epc, u8 func_no, u16 cap_offset,
> > > + u16 vendor, u8 type, const void *request, size_t request_sz,
> > > + pci_ep_doe_complete_t complete)
> > > +{
> > > + struct pci_ep_doe_mb *doe_mb;
> > > + struct pci_ep_doe_task *task;
> > > + int rc;
> > > +
> > > + doe_mb = pci_ep_doe_get_mailbox(epc, func_no, cap_offset);
> > > + if (!doe_mb) {
> > > + kfree(request);
> > > + return -ENODEV;
> > > + }
> > > +
> > > + task = kzalloc_obj(*task, GFP_KERNEL);
> > > + if (!task) {
> > > + kfree(request);
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + task->feat.vid = vendor;
> > > + task->feat.type = type;
> > > + task->request_pl = request;
> > > + task->request_pl_sz = request_sz;
> > > + task->response_pl = NULL;
> > > + task->response_pl_sz = 0;
> > > + task->complete = complete;
> > > +
> > > + rc = pci_ep_doe_submit_task(doe_mb, task);
> > > + if (rc) {
> > > + kfree(request);
> > > + kfree(task);
> > > + return rc;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(pci_ep_doe_process_request);
> >
> > So who is supposed to call this API? EPC driver that receives the DOE interrupt?
>
> Yes, the EPC drivers that receive the DOE interrupts are expected to
> call this API.
>
> > But I don't see the any callers of this and below exported APIs in this series.
> > Either you should add the callers or limit this series just to adding the DOE
> > skeleton implementation with a clear follow-up.
>
> I currently am working on the EPC driver implementation for a platform
> which has not been up-streamed yet. I plan to use these APIs to support
> the DOE feature for that driver. Currently, I am not aware of any
> platform whose EPC driver supports DOE feature and its interrupts, hence
> I see no real callers of these APIs to include in this patch series.
>
> Would it be appropriate to add a dummy [NOT-FOR-MERGING] demonstration
> patch over an existing EPC driver, showing how these DOE APIs would be
> integrated into an EPC driver?
>
Usually we don't add APIs without any callers. But if you have a realistic time
frame and guarantee that you are going to add EPC driver support soon, then we
can have these APIs merged first.
For demonstration purpose, you can just show the EPC integration as a snippet in
cover letter or point to the downstream driver for reference (if it is not a
secret sauce).
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v1] regulator: Use named initializers for arrays of i2c_device_data
From: Laurent Pinchart @ 2026-05-15 12:28 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Liam Girdwood, Mark Brown, Markus Schneider-Pargmann,
Michael Hennerich, Support Opensource, Ivaylo Ivanov,
Claudiu Beznea, Andrei Simion, Saravanan Sekar, Matthias Brugger,
AngeloGioacchino Del Regno, Woodrow Douglass, Jagan Teki,
Icenowy Zheng, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260515103150.164887-2-u.kleine-koenig@baylibre.com>
Hi Uwe,
Thank you for the patch.
On Fri, May 15, 2026 at 12:31:50PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> While being less compact, using named initializers allows to more easily
> see which members of the structs are assigned which value without having
> to lookup the declaration of the struct. And it's also more robust
> against changes to the struct definition.
>
> The mentioned robustness is relevant for a planned change to struct
> i2c_device_id that replaces .driver_data by an anonymous union.
>
> While touching all these arrays, unify usage of whitespace and commas.
>
> This patch doesn't modify the compiled arrays, only their representation
> in source form benefits. The former was confirmed with x86 and arm64
> builds.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
>
> the mentioned change to i2c_device_id is the following:
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 23ff24080dfd..aebd3a5e90af 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -477,7 +477,11 @@ struct rpmsg_device_id {
>
> struct i2c_device_id {
> char name[I2C_NAME_SIZE];
> - kernel_ulong_t driver_data; /* Data private to the driver */
> + union {
> + /* Data private to the driver */
> + kernel_ulong_t driver_data;
> + const void *driver_data_ptr;
> + };
> };
>
> /* pci_epf */
>
> and this requires that .driver_data is assigned via a named initializer
> for static data. This requirement isn't a bad one because named
> initializers are also much better readable than list initializers.
>
> The union added to struct i2c_device_id enables further cleanups like:
>
> diff --git a/drivers/regulator/ad5398.c b/drivers/regulator/ad5398.c
> index 0123ca8157a8..dfb0b07500a7 100644
> --- a/drivers/regulator/ad5398.c
> +++ b/drivers/regulator/ad5398.c
> @@ -207,8 +207,8 @@ struct ad5398_current_data_format {
> static const struct ad5398_current_data_format df_10_4_120 = {10, 4, 0, 120000};
>
> static const struct i2c_device_id ad5398_id[] = {
> - { .name = "ad5398", .driver_data = (kernel_ulong_t)&df_10_4_120 },
> - { .name = "ad5821", .driver_data = (kernel_ulong_t)&df_10_4_120 },
> + { .name = "ad5398", .driver_data_ptr = &df_10_4_120 },
> + { .name = "ad5821", .driver_data_ptr = &df_10_4_120 },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, ad5398_id);
> @@ -219,8 +219,7 @@ static int ad5398_probe(struct i2c_client *client)
> struct regulator_init_data *init_data = dev_get_platdata(&client->dev);
> struct regulator_config config = { };
> struct ad5398_chip_info *chip;
> - const struct ad5398_current_data_format *df =
> - (struct ad5398_current_data_format *)id->driver_data;
> + const struct ad5398_current_data_format *df = id->driver_data;
>
> chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
> if (!chip)
>
> that are an improvement for readability (again!) and it keeps some
> properties of the pointers (here: being const) without having to pay
> attention for that.
>
> My additional motivation for this effort is CHERI[1]. This is a hardware
> extension that uses 128 bit pointers but unsigned long is still 64 bit.
> So with CHERI you cannot store pointers in unsigned long variables.
>
> Best regards
> Uwe
>
> [1] https://cheri-alliance.org/discover-cheri/
> https://lwn.net/Articles/1037974/
>
> drivers/regulator/88pg86x.c | 4 +--
> drivers/regulator/ad5398.c | 4 +--
> drivers/regulator/da9121-regulator.c | 20 +++++++--------
> drivers/regulator/da9210-regulator.c | 4 +--
> drivers/regulator/da9211-regulator.c | 18 +++++++-------
> drivers/regulator/fan53880.c | 4 +--
> drivers/regulator/isl9305.c | 4 +--
> drivers/regulator/lp3971.c | 2 +-
> drivers/regulator/lp3972.c | 2 +-
> drivers/regulator/lp872x.c | 34 +++++++++++++-------------
> drivers/regulator/lp8755.c | 4 +--
> drivers/regulator/ltc3589.c | 6 ++---
> drivers/regulator/ltc3676.c | 2 +-
> drivers/regulator/max1586.c | 2 +-
> drivers/regulator/max20086-regulator.c | 8 +++---
> drivers/regulator/max20411-regulator.c | 2 +-
> drivers/regulator/max77503-regulator.c | 2 +-
> drivers/regulator/max77675-regulator.c | 2 +-
> drivers/regulator/max77826-regulator.c | 2 +-
> drivers/regulator/max77838-regulator.c | 2 +-
> drivers/regulator/max77857-regulator.c | 8 +++---
> drivers/regulator/max8649.c | 2 +-
> drivers/regulator/max8893.c | 2 +-
> drivers/regulator/max8952.c | 2 +-
> drivers/regulator/mcp16502.c | 2 +-
> drivers/regulator/mp5416.c | 6 ++---
> drivers/regulator/mp8859.c | 4 +--
> drivers/regulator/mp886x.c | 6 ++---
> drivers/regulator/mpq7920.c | 4 +--
> drivers/regulator/mt6311-regulator.c | 4 +--
> drivers/regulator/pf530x-regulator.c | 8 +++---
> drivers/regulator/pf8x00-regulator.c | 8 +++---
> drivers/regulator/pv88060-regulator.c | 4 +--
> drivers/regulator/pv88080-regulator.c | 8 +++---
> drivers/regulator/pv88090-regulator.c | 4 +--
> drivers/regulator/slg51000-regulator.c | 4 +--
> drivers/regulator/sy8106a-regulator.c | 2 +-
> drivers/regulator/sy8824x.c | 8 +++---
> drivers/regulator/sy8827n.c | 4 +--
> drivers/regulator/tps6286x-regulator.c | 10 ++++----
> drivers/regulator/tps6287x-regulator.c | 10 ++++----
> 41 files changed, 119 insertions(+), 119 deletions(-)
[snip]
> diff --git a/drivers/regulator/pf530x-regulator.c b/drivers/regulator/pf530x-regulator.c
> index f789c4b6a499..e7b13d60106b 100644
> --- a/drivers/regulator/pf530x-regulator.c
> +++ b/drivers/regulator/pf530x-regulator.c
> @@ -353,10 +353,10 @@ static const struct of_device_id pf530x_dt_ids[] = {
> MODULE_DEVICE_TABLE(of, pf530x_dt_ids);
>
> static const struct i2c_device_id pf530x_i2c_id[] = {
> - { "pf5300", 0 },
> - { "pf5301", 0 },
> - { "pf5302", 0 },
> - {},
> + { .name = "pf5300", .driver_data = 0 },
> + { .name = "pf5301", .driver_data = 0 },
> + { .name = "pf5302", .driver_data = 0 },
I think you can drop driver_data here. It doesn't appear to be used by
the driver.
I like the result overall. With this small issue addressed,
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> + { }
> };
> MODULE_DEVICE_TABLE(i2c, pf530x_i2c_id);
>
[snip]
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 3/3] interconnect: qcom: Make important drivers default
From: Krzysztof Kozlowski @ 2026-05-15 12:11 UTC (permalink / raw)
To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260515-interconnect-qcom-clean-arm64-v2-0-adeebc73596d@oss.qualcomm.com>
The interconnect drivers for Qualcomm SoC Network-on-Chip are covering a
basic or fundamental SoC feature: bandwidth management between internal
SoC blocks. SoC can boot without these, but power management or
performance will be affected. These drivers do not represent any sort
of buses visible to the board designers/configurators, thus they should
be always enabled, regardless how SoC is used in the final board.
Kernel configuration should not ask users choice of drivers when that
choice is obvious and known to the developers that answer should be
'yes' or 'module'.
Switch all almost Qualcomm interconnect drivers to a default 'yes' for
ARCH_QCOM. This has impact:
1. arm64 defconfig:
a. Enable as built-in INTERCONNECT_QCOM_SDM660,
INTERCONNECT_QCOM_SDM670, INTERCONNECT_QCOM_SM7150 and
INTERCONNECT_QCOM_SAR2130P, which were not selected before but
should be, because these platforms need them anyway for proper
functioning.
b. Switch to built-in from a module INTERCONNECT_QCOM_QCS404 and
INTERCONNECT_QCOM_MSM8916, which as modules would not make the
platform bootable in most cases, and INTERCONNECT_QCOM_OSM_L3,
which when module might slow down boot considerably by having
caches running at slow speed.
2. arm qcom_defconfig: Switch to built-in from a module
INTERCONNECT_QCOM_RPMH, INTERCONNECT_QCOM_SMD_RPM,
INTERCONNECT_QCOM_BCM_VOTER, INTERCONNECT_QCOM_MSM8974,
INTERCONNECT_QCOM_SDX55, which as modules would not make the
platform bootable in most cases.
3. arm multi_v7 defconfig: Enable drivers necessary to boot
ARM 32-bit platforms, which are already enabled on qcom_defconfig:
a. Enable as built-in INTERCONNECT_QCOM_MSM8974.
b. Enable as modules (other dependencies prevent from built-in)
INTERCONNECT_QCOM_RPMH, INTERCONNECT_QCOM_BCM_VOTER and
INTERCONNECT_QCOM_SDX55.
4. COMPILE_TEST builds: Enable by default all drivers for arm or arm64
builds, whenever ARCH_QCOM is selected. This has impact on build
time and feels logical, because if one selects ARCH_QCOM then
probably by default wants to build test it entirely. Kernels with
COMPILE_TEST are not supposed to be used for booting.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I propose the change to go via interconnect tree. It might conflict
around defconfigs, though.
---
arch/arm/configs/qcom_defconfig | 3 ---
arch/arm64/configs/defconfig | 31 -------------------------------
drivers/interconnect/qcom/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+), 34 deletions(-)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 03309b89ea4c..451f2c4cec55 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -271,9 +271,6 @@ CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2=y
CONFIG_PHY_QCOM_USB_HSIC=y
CONFIG_NVMEM_QCOM_QFPROM=y
CONFIG_INTERCONNECT=y
-CONFIG_INTERCONNECT_QCOM=y
-CONFIG_INTERCONNECT_QCOM_MSM8974=m
-CONFIG_INTERCONNECT_QCOM_SDX55=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT4_FS=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e5f1901ee408..4909a8824ec8 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1848,37 +1848,6 @@ CONFIG_INTERCONNECT_IMX8MM=m
CONFIG_INTERCONNECT_IMX8MN=m
CONFIG_INTERCONNECT_IMX8MQ=m
CONFIG_INTERCONNECT_IMX8MP=y
-CONFIG_INTERCONNECT_QCOM=y
-CONFIG_INTERCONNECT_QCOM_ELIZA=y
-CONFIG_INTERCONNECT_QCOM_GLYMUR=y
-CONFIG_INTERCONNECT_QCOM_KAANAPALI=y
-CONFIG_INTERCONNECT_QCOM_MSM8916=m
-CONFIG_INTERCONNECT_QCOM_MSM8953=y
-CONFIG_INTERCONNECT_QCOM_MSM8996=y
-CONFIG_INTERCONNECT_QCOM_OSM_L3=m
-CONFIG_INTERCONNECT_QCOM_QCM2290=y
-CONFIG_INTERCONNECT_QCOM_QCS404=m
-CONFIG_INTERCONNECT_QCOM_QCS615=y
-CONFIG_INTERCONNECT_QCOM_QCS8300=y
-CONFIG_INTERCONNECT_QCOM_QDU1000=y
-CONFIG_INTERCONNECT_QCOM_SA8775P=y
-CONFIG_INTERCONNECT_QCOM_SC7180=y
-CONFIG_INTERCONNECT_QCOM_SC7280=y
-CONFIG_INTERCONNECT_QCOM_SC8180X=y
-CONFIG_INTERCONNECT_QCOM_SC8280XP=y
-CONFIG_INTERCONNECT_QCOM_SDM845=y
-CONFIG_INTERCONNECT_QCOM_SDX75=y
-CONFIG_INTERCONNECT_QCOM_SM6115=y
-CONFIG_INTERCONNECT_QCOM_SM6350=y
-CONFIG_INTERCONNECT_QCOM_MILOS=y
-CONFIG_INTERCONNECT_QCOM_SM8150=y
-CONFIG_INTERCONNECT_QCOM_SM8250=y
-CONFIG_INTERCONNECT_QCOM_SM8350=y
-CONFIG_INTERCONNECT_QCOM_SM8450=y
-CONFIG_INTERCONNECT_QCOM_SM8550=y
-CONFIG_INTERCONNECT_QCOM_SM8650=y
-CONFIG_INTERCONNECT_QCOM_SM8750=y
-CONFIG_INTERCONNECT_QCOM_X1E80100=y
CONFIG_COUNTER=m
CONFIG_RZ_MTU3_CNT=m
CONFIG_STM32_TIMER_CNT=m
diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig
index b2c4272ae48f..dd3ef920a16a 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -2,6 +2,7 @@
config INTERCONNECT_QCOM
tristate "Qualcomm Network-on-Chip interconnect drivers"
depends on ARCH_QCOM
+ default ARCH_QCOM
help
Support for Qualcomm's Network-on-Chip interconnect hardware.
@@ -14,6 +15,7 @@ config INTERCONNECT_QCOM_ELIZA
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on Eliza-based
platforms.
@@ -24,6 +26,7 @@ config INTERCONNECT_QCOM_GLYMUR
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on glymur-based
platforms.
@@ -34,6 +37,7 @@ config INTERCONNECT_QCOM_KAANAPALI
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on kaanapali-based
platforms.
@@ -53,6 +57,7 @@ config INTERCONNECT_QCOM_MSM8916
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM if ARM64
help
This is a driver for the Qualcomm Network-on-Chip on msm8916-based
platforms.
@@ -81,6 +86,7 @@ config INTERCONNECT_QCOM_MSM8953
depends on QCOM_SMD_RPM
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on msm8953-based
platforms.
@@ -91,6 +97,7 @@ config INTERCONNECT_QCOM_MSM8974
depends on QCOM_SMD_RPM
depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on msm8974-based
platforms.
@@ -111,6 +118,7 @@ config INTERCONNECT_QCOM_MSM8996
depends on QCOM_SMD_RPM
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on msm8996-based
platforms.
@@ -119,6 +127,7 @@ config INTERCONNECT_QCOM_OSM_L3
tristate "Qualcomm OSM L3 interconnect driver"
depends on INTERCONNECT_QCOM || COMPILE_TEST
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
Say y here to support the Operating State Manager (OSM) interconnect
driver which controls the scaling of L3 caches on Qualcomm SoCs.
@@ -129,6 +138,7 @@ config INTERCONNECT_QCOM_QCM2290
depends on QCOM_SMD_RPM
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on qcm2290-based
platforms.
@@ -139,6 +149,7 @@ config INTERCONNECT_QCOM_QCS404
depends on QCOM_SMD_RPM
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on qcs404-based
platforms.
@@ -149,6 +160,7 @@ config INTERCONNECT_QCOM_QCS615
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on qcs615-based
platforms.
@@ -159,6 +171,7 @@ config INTERCONNECT_QCOM_QCS8300
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Technologies, Inc. Network-on-Chip
on QCS8300-based platforms. The interconnect provider collects and
@@ -171,6 +184,7 @@ config INTERCONNECT_QCOM_QDU1000
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on QDU1000-based
and QRU1000-based platforms.
@@ -195,6 +209,7 @@ config INTERCONNECT_QCOM_SA8775P
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sa8775p-based
platforms.
@@ -205,6 +220,7 @@ config INTERCONNECT_QCOM_SAR2130P
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SAR2130P-based
platforms.
@@ -215,6 +231,7 @@ config INTERCONNECT_QCOM_SC7180
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sc7180-based
platforms.
@@ -225,6 +242,7 @@ config INTERCONNECT_QCOM_SC7280
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sc7280-based
platforms.
@@ -235,6 +253,7 @@ config INTERCONNECT_QCOM_SC8180X
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sc8180x-based
platforms.
@@ -245,6 +264,7 @@ config INTERCONNECT_QCOM_SC8280XP
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SC8280XP-based
platforms.
@@ -255,6 +275,7 @@ config INTERCONNECT_QCOM_SDM660
depends on ARM64 || COMPILE_TEST
depends on QCOM_SMD_RPM
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sdm660-based
platforms.
@@ -265,6 +286,7 @@ config INTERCONNECT_QCOM_SDM670
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sdm670-based
platforms.
@@ -275,6 +297,7 @@ config INTERCONNECT_QCOM_SDM845
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sdm845-based
platforms.
@@ -285,6 +308,7 @@ config INTERCONNECT_QCOM_SDX55
depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sdx55-based
platforms.
@@ -305,6 +329,7 @@ config INTERCONNECT_QCOM_SDX75
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sdx75-based
platforms.
@@ -315,6 +340,7 @@ config INTERCONNECT_QCOM_SM6115
depends on QCOM_SMD_RPM
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sm6115-based
platforms.
@@ -325,6 +351,7 @@ config INTERCONNECT_QCOM_SM6350
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sm6350-based
platforms.
@@ -335,6 +362,7 @@ config INTERCONNECT_QCOM_SM7150
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sm7150-based
platforms.
@@ -345,6 +373,7 @@ config INTERCONNECT_QCOM_MILOS
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on Milos-based
platforms.
@@ -355,6 +384,7 @@ config INTERCONNECT_QCOM_SM8150
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sm8150-based
platforms.
@@ -365,6 +395,7 @@ config INTERCONNECT_QCOM_SM8250
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sm8250-based
platforms.
@@ -375,6 +406,7 @@ config INTERCONNECT_QCOM_SM8350
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SM8350-based
platforms.
@@ -385,6 +417,7 @@ config INTERCONNECT_QCOM_SM8450
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SM8450-based
platforms.
@@ -395,6 +428,7 @@ config INTERCONNECT_QCOM_SM8550
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SM8550-based
platforms.
@@ -405,6 +439,7 @@ config INTERCONNECT_QCOM_SM8650
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SM8650-based
platforms.
@@ -415,6 +450,7 @@ config INTERCONNECT_QCOM_SM8750
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SM8750-based
platforms.
@@ -425,6 +461,7 @@ config INTERCONNECT_QCOM_X1E80100
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on X1E80100-based
platforms.
--
2.51.0
^ permalink raw reply related
* [PATCH v2 1/3] interconnect: qcom: Fix indentation
From: Krzysztof Kozlowski @ 2026-05-15 12:11 UTC (permalink / raw)
To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260515-interconnect-qcom-clean-arm64-v2-0-adeebc73596d@oss.qualcomm.com>
KConfig entries should be indented starting with one tab, so replace
spaces with it.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/interconnect/qcom/Kconfig | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig
index 786b4eda44b4..871663bfd094 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -9,22 +9,22 @@ config INTERCONNECT_QCOM_BCM_VOTER
tristate
config INTERCONNECT_QCOM_ELIZA
- tristate "Qualcomm Eliza interconnect driver"
- depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
- select INTERCONNECT_QCOM_RPMH
- select INTERCONNECT_QCOM_BCM_VOTER
- help
- This is a driver for the Qualcomm Network-on-Chip on Eliza-based
- platforms.
+ tristate "Qualcomm Eliza interconnect driver"
+ depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ select INTERCONNECT_QCOM_RPMH
+ select INTERCONNECT_QCOM_BCM_VOTER
+ help
+ This is a driver for the Qualcomm Network-on-Chip on Eliza-based
+ platforms.
config INTERCONNECT_QCOM_GLYMUR
- tristate "Qualcomm Glymur interconnect driver"
- depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
- select INTERCONNECT_QCOM_RPMH
- select INTERCONNECT_QCOM_BCM_VOTER
- help
- This is a driver for the Qualcomm Network-on-Chip on glymur-based
- platforms.
+ tristate "Qualcomm Glymur interconnect driver"
+ depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ select INTERCONNECT_QCOM_RPMH
+ select INTERCONNECT_QCOM_BCM_VOTER
+ help
+ This is a driver for the Qualcomm Network-on-Chip on glymur-based
+ platforms.
config INTERCONNECT_QCOM_KAANAPALI
tristate "Qualcomm Kaanapali interconnect driver"
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/3] interconnect: qcom: Restrict drivers per ARM/ARM64
From: Krzysztof Kozlowski @ 2026-05-15 12:11 UTC (permalink / raw)
To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel,
Konrad Dybcio, Krzysztof Kozlowski
In-Reply-To: <20260515-interconnect-qcom-clean-arm64-v2-0-adeebc73596d@oss.qualcomm.com>
There is no point to allow selecting core SoC drivers like interconnects
for Qualcomm ARMv7 SoCs when building ARM64 kernel, and vice versa.
This makes kernel configuration more difficult as many do not remember
the Qualcomm SoCs model names/numbers and their properties like
architecture. No features should be lost because:
1. There won't be a single image for ARMv7 and ARMv8/9 SoCs.
2. Newer ARMv8/9 SoCs won't be running in arm32 emulation mode.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/interconnect/qcom/Kconfig | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig
index 871663bfd094..b2c4272ae48f 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -11,6 +11,7 @@ config INTERCONNECT_QCOM_BCM_VOTER
config INTERCONNECT_QCOM_ELIZA
tristate "Qualcomm Eliza interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -20,6 +21,7 @@ config INTERCONNECT_QCOM_ELIZA
config INTERCONNECT_QCOM_GLYMUR
tristate "Qualcomm Glymur interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -29,6 +31,7 @@ config INTERCONNECT_QCOM_GLYMUR
config INTERCONNECT_QCOM_KAANAPALI
tristate "Qualcomm Kaanapali interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -39,6 +42,7 @@ config INTERCONNECT_QCOM_MSM8909
tristate "Qualcomm MSM8909 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on msm8909-based
@@ -75,6 +79,7 @@ config INTERCONNECT_QCOM_MSM8953
tristate "Qualcomm MSM8953 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on msm8953-based
@@ -84,6 +89,7 @@ config INTERCONNECT_QCOM_MSM8974
tristate "Qualcomm MSM8974 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on msm8974-based
@@ -93,6 +99,7 @@ config INTERCONNECT_QCOM_MSM8976
tristate "Qualcomm MSM8976 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on msm8976-based
@@ -102,6 +109,7 @@ config INTERCONNECT_QCOM_MSM8996
tristate "Qualcomm MSM8996 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on msm8996-based
@@ -110,6 +118,7 @@ config INTERCONNECT_QCOM_MSM8996
config INTERCONNECT_QCOM_OSM_L3
tristate "Qualcomm OSM L3 interconnect driver"
depends on INTERCONNECT_QCOM || COMPILE_TEST
+ depends on ARM64 || COMPILE_TEST
help
Say y here to support the Operating State Manager (OSM) interconnect
driver which controls the scaling of L3 caches on Qualcomm SoCs.
@@ -118,6 +127,7 @@ config INTERCONNECT_QCOM_QCM2290
tristate "Qualcomm QCM2290 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on qcm2290-based
@@ -127,6 +137,7 @@ config INTERCONNECT_QCOM_QCS404
tristate "Qualcomm QCS404 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on qcs404-based
@@ -135,6 +146,7 @@ config INTERCONNECT_QCOM_QCS404
config INTERCONNECT_QCOM_QCS615
tristate "Qualcomm QCS615 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -144,6 +156,7 @@ config INTERCONNECT_QCOM_QCS615
config INTERCONNECT_QCOM_QCS8300
tristate "Qualcomm QCS8300 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -155,6 +168,7 @@ config INTERCONNECT_QCOM_QCS8300
config INTERCONNECT_QCOM_QDU1000
tristate "Qualcomm QDU1000/QRU1000 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -178,6 +192,7 @@ config INTERCONNECT_QCOM_RPMH
config INTERCONNECT_QCOM_SA8775P
tristate "Qualcomm SA8775P interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -187,6 +202,7 @@ config INTERCONNECT_QCOM_SA8775P
config INTERCONNECT_QCOM_SAR2130P
tristate "Qualcomm SAR2130P interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -196,6 +212,7 @@ config INTERCONNECT_QCOM_SAR2130P
config INTERCONNECT_QCOM_SC7180
tristate "Qualcomm SC7180 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -205,6 +222,7 @@ config INTERCONNECT_QCOM_SC7180
config INTERCONNECT_QCOM_SC7280
tristate "Qualcomm SC7280 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -214,6 +232,7 @@ config INTERCONNECT_QCOM_SC7280
config INTERCONNECT_QCOM_SC8180X
tristate "Qualcomm SC8180X interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -223,6 +242,7 @@ config INTERCONNECT_QCOM_SC8180X
config INTERCONNECT_QCOM_SC8280XP
tristate "Qualcomm SC8280XP interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -232,6 +252,7 @@ config INTERCONNECT_QCOM_SC8280XP
config INTERCONNECT_QCOM_SDM660
tristate "Qualcomm SDM660 interconnect driver"
depends on INTERCONNECT_QCOM
+ depends on ARM64 || COMPILE_TEST
depends on QCOM_SMD_RPM
select INTERCONNECT_QCOM_SMD_RPM
help
@@ -241,6 +262,7 @@ config INTERCONNECT_QCOM_SDM660
config INTERCONNECT_QCOM_SDM670
tristate "Qualcomm SDM670 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -250,6 +272,7 @@ config INTERCONNECT_QCOM_SDM670
config INTERCONNECT_QCOM_SDM845
tristate "Qualcomm SDM845 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -259,6 +282,7 @@ config INTERCONNECT_QCOM_SDM845
config INTERCONNECT_QCOM_SDX55
tristate "Qualcomm SDX55 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -268,6 +292,7 @@ config INTERCONNECT_QCOM_SDX55
config INTERCONNECT_QCOM_SDX65
tristate "Qualcomm SDX65 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -277,6 +302,7 @@ config INTERCONNECT_QCOM_SDX65
config INTERCONNECT_QCOM_SDX75
tristate "Qualcomm SDX75 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -287,6 +313,7 @@ config INTERCONNECT_QCOM_SM6115
tristate "Qualcomm SM6115 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on sm6115-based
@@ -295,6 +322,7 @@ config INTERCONNECT_QCOM_SM6115
config INTERCONNECT_QCOM_SM6350
tristate "Qualcomm SM6350 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -304,6 +332,7 @@ config INTERCONNECT_QCOM_SM6350
config INTERCONNECT_QCOM_SM7150
tristate "Qualcomm SM7150 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -313,6 +342,7 @@ config INTERCONNECT_QCOM_SM7150
config INTERCONNECT_QCOM_MILOS
tristate "Qualcomm Milos interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -322,6 +352,7 @@ config INTERCONNECT_QCOM_MILOS
config INTERCONNECT_QCOM_SM8150
tristate "Qualcomm SM8150 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -331,6 +362,7 @@ config INTERCONNECT_QCOM_SM8150
config INTERCONNECT_QCOM_SM8250
tristate "Qualcomm SM8250 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -340,6 +372,7 @@ config INTERCONNECT_QCOM_SM8250
config INTERCONNECT_QCOM_SM8350
tristate "Qualcomm SM8350 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -349,6 +382,7 @@ config INTERCONNECT_QCOM_SM8350
config INTERCONNECT_QCOM_SM8450
tristate "Qualcomm SM8450 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -358,6 +392,7 @@ config INTERCONNECT_QCOM_SM8450
config INTERCONNECT_QCOM_SM8550
tristate "Qualcomm SM8550 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -367,6 +402,7 @@ config INTERCONNECT_QCOM_SM8550
config INTERCONNECT_QCOM_SM8650
tristate "Qualcomm SM8650 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -376,6 +412,7 @@ config INTERCONNECT_QCOM_SM8650
config INTERCONNECT_QCOM_SM8750
tristate "Qualcomm SM8750 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -385,6 +422,7 @@ config INTERCONNECT_QCOM_SM8750
config INTERCONNECT_QCOM_X1E80100
tristate "Qualcomm X1E80100 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/3] interconnect: qcom: Some defconfig/defaults cleanups and improvements
From: Krzysztof Kozlowski @ 2026-05-15 12:11 UTC (permalink / raw)
To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski, Konrad Dybcio
Changes in v2:
- Patch #3: Switch to built-in for everything, with explanation in
commit msg.
- Tags
- Link to v1: https://patch.msgid.link/20260428-interconnect-qcom-clean-arm64-v1-0-e6bc3f7832db@oss.qualcomm.com
Similarly to clocks and pinctrl, interconnects should not be a user
visible choice.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (3):
interconnect: qcom: Fix indentation
interconnect: qcom: Restrict drivers per ARM/ARM64
interconnect: qcom: Make important drivers default
arch/arm/configs/qcom_defconfig | 3 --
arch/arm64/configs/defconfig | 31 ------------
drivers/interconnect/qcom/Kconfig | 103 ++++++++++++++++++++++++++++++++------
3 files changed, 89 insertions(+), 48 deletions(-)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260428-interconnect-qcom-clean-arm64-aecdaa1e531b
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Fix OOB in scmi_power_name_get()
From: Cristian Marussi @ 2026-05-15 12:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Cristian Marussi, Dan Carpenter, Sudeep Holla, arm-scmi,
linux-arm-kernel, linux-kernel
In-Reply-To: <CAMuHMdVVAioAk_3K4y-7T0MCa7L++sVcWGRfdj_ESHau0ov9eA@mail.gmail.com>
On Fri, May 15, 2026 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> Hi Cristian,
>
> On Fri, 15 May 2026 at 13:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > On Fri, May 15, 2026 at 01:29:27PM +0200, Geert Uytterhoeven wrote:
> > > On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote:
> > > > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote:
> > > > > scmi_power_name_get() does not validate the domain number passed by the
> > > > > external caller, which may lead to an out-of-bounds access.
> > > >
> > > > Is an external caller an out of tree caller? So far as I can see this
> > >
> > > I meant a caller outside drivers/firmware/arm_scmi/.
> > >
> > > > is only called by scmi_pm_domain_probe().
> > > >
> > > > scmi_pd->name = power_ops->name_get(ph, i);
> > > >
> > > > where i < num_domains.
> > >
> > > You are right. But this seems to be only API implementation in
> > > drivers/firmware/arm_scmi/ that does not validate the passed domain
> > > number.
> >
> > Yes we tend to validate protocol operations calls even if apparently
> > safe from teh caller perspective...indeed I have this fixed locally
> > since ages in an horrible patch, that does a lot more, and that I
> > never posted :P
> >
> > Usually, if it is worth, we also build an internal domain get helper to
> > reuse across the protocol unit...but here really there are only 2 call-sites.
> >
> > What I am not sure is what to return: "unknown" is safer as of now than NULL
> > for sure, but really, what happened is NOT that the name was "unknown" (which
> > by itself would be out-of-spec behaviour) it is more that the whole domain that
> > was referred to that was invalid and NOT existent...
> >
> > ....mmm I suppose we are opening another can of worms here :P
>
> Like scmi_perf_info_get() returning ERR_PTR(-EINVAL) instead of NULL,
> and scmi_perf_domain_probe() never checking the return value anyway?
...oh probably more than that...and related vendor FW that already exploits
these missing checks here and there to arbitrarily skip domains and return
out-of-spec non-contigous sets of domains becasue they cannot bother to
implement properly the spec (or they have simply forked their codebase from
an old drop and never updated it again...)...so that any kernel-side fix
you made along the road carries the risk of breaking something and a string
of possibly needed quirks...
Cheers,
Cristian
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Fix OOB in scmi_power_name_get()
From: Geert Uytterhoeven @ 2026-05-15 12:00 UTC (permalink / raw)
To: Cristian Marussi
Cc: Dan Carpenter, Sudeep Holla, arm-scmi, linux-arm-kernel,
linux-kernel
In-Reply-To: <agcHnzzdhV36j9eH@pluto>
Hi Cristian,
On Fri, 15 May 2026 at 13:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> On Fri, May 15, 2026 at 01:29:27PM +0200, Geert Uytterhoeven wrote:
> > On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote:
> > > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote:
> > > > scmi_power_name_get() does not validate the domain number passed by the
> > > > external caller, which may lead to an out-of-bounds access.
> > >
> > > Is an external caller an out of tree caller? So far as I can see this
> >
> > I meant a caller outside drivers/firmware/arm_scmi/.
> >
> > > is only called by scmi_pm_domain_probe().
> > >
> > > scmi_pd->name = power_ops->name_get(ph, i);
> > >
> > > where i < num_domains.
> >
> > You are right. But this seems to be only API implementation in
> > drivers/firmware/arm_scmi/ that does not validate the passed domain
> > number.
>
> Yes we tend to validate protocol operations calls even if apparently
> safe from teh caller perspective...indeed I have this fixed locally
> since ages in an horrible patch, that does a lot more, and that I
> never posted :P
>
> Usually, if it is worth, we also build an internal domain get helper to
> reuse across the protocol unit...but here really there are only 2 call-sites.
>
> What I am not sure is what to return: "unknown" is safer as of now than NULL
> for sure, but really, what happened is NOT that the name was "unknown" (which
> by itself would be out-of-spec behaviour) it is more that the whole domain that
> was referred to that was invalid and NOT existent...
>
> ....mmm I suppose we are opening another can of worms here :P
Like scmi_perf_info_get() returning ERR_PTR(-EINVAL) instead of NULL,
and scmi_perf_domain_probe() never checking the return value anyway?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: microchip: lan969x: add OTP node
From: Robert Marko @ 2026-05-15 11:59 UTC (permalink / raw)
To: srini, robh, krzk+dt, conor+dt, nicolas.ferre, claudiu.beznea,
horatiu.vultur, daniel.machon, devicetree, linux-kernel,
linux-arm-kernel
Cc: luka.perkov, Robert Marko
In-Reply-To: <20260515115954.701155-1-robimarko@gmail.com>
From: Robert Marko <robert.marko@sartura.hr>
Add the required OTP on LAN969x.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
arch/arm64/boot/dts/microchip/lan9691.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/microchip/lan9691.dtsi b/arch/arm64/boot/dts/microchip/lan9691.dtsi
index 235e56bebbdb..ed997d87dd09 100644
--- a/arch/arm64/boot/dts/microchip/lan9691.dtsi
+++ b/arch/arm64/boot/dts/microchip/lan9691.dtsi
@@ -100,6 +100,11 @@ usb: usb@300000 {
status = "disabled";
};
+ otp: otp@e0021000 {
+ compatible = "microchip,lan9691-otpc";
+ reg = <0xe0021000 0x1000>;
+ };
+
flx0: flexcom@e0040000 {
compatible = "microchip,lan9691-flexcom", "atmel,sama5d2-flexcom";
reg = <0xe0040000 0x100>;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/3] nvmem: lan9662-otp: add support for LAN969x
From: Robert Marko @ 2026-05-15 11:59 UTC (permalink / raw)
To: srini, robh, krzk+dt, conor+dt, nicolas.ferre, claudiu.beznea,
horatiu.vultur, daniel.machon, devicetree, linux-kernel,
linux-arm-kernel
Cc: luka.perkov, Robert Marko
In-Reply-To: <20260515115954.701155-1-robimarko@gmail.com>
From: Horatiu Vultur <horatiu.vultur@microchip.com>
Microchip LAN969x provides OTP with the same control logic, only the size
differs as LAN969x has 16KB of OTP instead of 8KB like on LAN966x.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v3:
* Rebase onto current next-20260508
drivers/nvmem/Kconfig | 2 +-
drivers/nvmem/lan9662-otpc.c | 12 +++++++++---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0..78b648e14727 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -138,7 +138,7 @@ config NVMEM_JZ4780_EFUSE
config NVMEM_LAN9662_OTPC
tristate "Microchip LAN9662 OTP controller support"
- depends on SOC_LAN966 || COMPILE_TEST
+ depends on SOC_LAN966 || ARCH_LAN969X || COMPILE_TEST
depends on HAS_IOMEM
help
This driver enables the OTP controller available on Microchip LAN9662
diff --git a/drivers/nvmem/lan9662-otpc.c b/drivers/nvmem/lan9662-otpc.c
index 56fc19f092a7..62d1d6381bf8 100644
--- a/drivers/nvmem/lan9662-otpc.c
+++ b/drivers/nvmem/lan9662-otpc.c
@@ -27,7 +27,6 @@
#define OTP_OTP_STATUS_OTP_CPUMPEN BIT(1)
#define OTP_OTP_STATUS_OTP_BUSY BIT(0)
-#define OTP_MEM_SIZE 8192
#define OTP_SLEEP_US 10
#define OTP_TIMEOUT_US 500000
@@ -176,7 +175,6 @@ static struct nvmem_config otp_config = {
.word_size = 1,
.reg_read = lan9662_otp_read,
.reg_write = lan9662_otp_write,
- .size = OTP_MEM_SIZE,
};
static int lan9662_otp_probe(struct platform_device *pdev)
@@ -196,6 +194,7 @@ static int lan9662_otp_probe(struct platform_device *pdev)
otp_config.priv = otp;
otp_config.dev = dev;
+ otp_config.size = (uintptr_t) device_get_match_data(dev);
nvmem = devm_nvmem_register(dev, &otp_config);
@@ -203,7 +202,14 @@ static int lan9662_otp_probe(struct platform_device *pdev)
}
static const struct of_device_id lan9662_otp_match[] = {
- { .compatible = "microchip,lan9662-otpc", },
+ {
+ .compatible = "microchip,lan9662-otpc",
+ .data = (const void *) SZ_8K,
+ },
+ {
+ .compatible = "microchip,lan9691-otpc",
+ .data = (const void *) SZ_16K,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, lan9662_otp_match);
--
2.54.0
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: nvmem: lan9662-otpc: Add LAN969x series
From: Robert Marko @ 2026-05-15 11:59 UTC (permalink / raw)
To: srini, robh, krzk+dt, conor+dt, nicolas.ferre, claudiu.beznea,
horatiu.vultur, daniel.machon, devicetree, linux-kernel,
linux-arm-kernel
Cc: luka.perkov, Robert Marko, Conor Dooley
From: Robert Marko <robert.marko@sartura.hr>
Unlike LAN966x series which has 8K of OTP space, LAN969x series has 16K of
OTP space, so document the compatible.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v3:
* Pick Acked-by from Conor
.../devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml
index f97c6beb4766..c03e96afe564 100644
--- a/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml
+++ b/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml
@@ -25,6 +25,7 @@ properties:
- const: microchip,lan9662-otpc
- enum:
- microchip,lan9662-otpc
+ - microchip,lan9691-otpc
reg:
maxItems: 1
--
2.54.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