* Re: [PATCH v3 3/3] ARM: dts: ti: Add specific compatibles for SCM conf nodes
From: Conor Dooley @ 2026-06-09 16:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-renesas-soc, linux-rockchip, linux-omap
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-3-4eba9ec1212a@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 56 bytes --]
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Diederik de Haas @ 2026-06-09 16:32 UTC (permalink / raw)
To: Jonas Karlman, Heiko Stuebner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman
Cc: Diederik de Haas, devicetree, linux-rockchip, linux-usb,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260609154124.445182-2-jonas@kwiboo.se>
Hi Jonas,
On Tue Jun 9, 2026 at 5:41 PM CEST, Jonas Karlman wrote:
> The Rockchip RK3568 EHCI/OHCI controller depends on clk_usbphy1_480m
> being enabled, or the system may freeze when registers are accessed.
>
> Add Rockchip RK3568 EHCI and OHCI compatibles with a similar four-clock
> constraint as RK3588.
>
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> ---
> Existing DTs for RK3568 use the plain generic-ehci/ohci compatible,
> next patch make use of these new compatibles and adds the missing
> clk_usbphy1_480m clock references.
> ---
> .../devicetree/bindings/usb/generic-ehci.yaml | 10 ++++++++++
> .../devicetree/bindings/usb/generic-ohci.yaml | 5 ++++-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> index 55a5aa7d7a54..c49a1bbc8cfd 100644
> --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> @@ -52,6 +52,7 @@ properties:
> - ibm,476gtr-ehci
> - nxp,lpc1850-ehci
> - qca,ar7100-ehci
> + - rockchip,rk3568-ehci
> - rockchip,rk3588-ehci
> - snps,hsdk-v1.0-ehci
> - socionext,uniphier-ehci
> @@ -186,6 +187,15 @@ allOf:
> required:
> - clocks
> - clock-names
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: rockchip,rk3568-ehci
> + then:
> + properties:
> + clocks:
> + minItems: 4
I think that the constraint for rk3588 is this:
- minItems: 1
- maxItems: 4
Like ~ every other compatible; there's no 'branch' for rk3588-ehci.
That's different from what you add for rk3568. Is that deliberate?
Because from the commit message I assumed they should be the same.
> unevaluatedProperties: false
>
> diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
> index d42f448fa204..5f1b4d2bff89 100644
> --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
> +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
> @@ -47,6 +47,7 @@ properties:
> - hpe,gxp-ohci
> - ibm,476gtr-ohci
> - ingenic,jz4740-ohci
> + - rockchip,rk3568-ohci
> - rockchip,rk3588-ohci
> - snps,hsdk-v1.0-ohci
> - const: generic-ohci
> @@ -198,7 +199,9 @@ allOf:
> properties:
> compatible:
> contains:
> - const: rockchip,rk3588-ohci
> + enum:
> + - rockchip,rk3568-ohci
> + - rockchip,rk3588-ohci
Here they clearly do have the same constraint.
Cheers,
Diederik
> then:
> properties:
> clocks:
^ permalink raw reply
* Re: [PATCH 1/2] KVM: arm64: Replace memslot_is_logging() with kvm_slot_dirty_track_enabled()
From: Leonardo Bras @ 2026-06-09 16:31 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: Leonardo Bras, linux-arm-kernel, kvmarm, linux-kernel,
Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Gavin Shan
In-Reply-To: <aibmALTEbc7gzSZj@devkitleo>
On Mon, Jun 08, 2026 at 04:55:45PM +0100, Leonardo Bras wrote:
> Hi Wei Lin,
>
> On Fri, Jun 05, 2026 at 04:32:47PM +0100, Wei-Lin Chang wrote:
> > When checking whether a memslot has dirty logging enabled, the
> > KVM_MEM_LOG_DIRTY_PAGES flag is the source of truth. Previously we were
> > using memslot_is_logging() which only tests dirty bitmap and did not
> > consider dirty ring. This was not detected because
> > KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP was introduced together with KVM
> > arm64 dirty ring, and users need to enable it to ensure dirty
> > information is not lost for the case of VGIC LPI/ITS table changes.
> >
> > Fix this by using kvm_slot_dirty_track_enabled() instead which checks
> > KVM_MEM_LOG_DIRTY_PAGES.
> >
> > Note that memslot_is_logging() also treats a memslot as not logging if
> > KVM_MEM_READONLY is set, hence a memslot with both dirty logging and
> > read only would be seen as not logging for memslot_is_logging(), but
> > logging for kvm_slot_dirty_track_enabled(). This allows a read only
> > mapping of size > PAGE_SIZE to be built when memslot_is_logging() is
> > used, leading to a better read performance compared to
> > kvm_slot_dirty_track_enabled(). However memslots that have both
> > KVM_MEM_LOG_DIRTY_PAGES and KVM_MEM_READONLY set do not really make
> > sense as dirty logging is essentially nop for a read only memslot, so
> > this shouldn't affect real workloads much.
>
>
> It worries me a bit that we are ignoring the KVM_MEM_READONLY flag...
> I have not yet gone through the whole s2_mmu code but IIUC we can have
> scenarios on which a memslot can be read-only and have dirty-logging
> enabled.
> If a memslot is not faulted yet, IIUC it is marked as read-only
> (so it can be mapped on write fault), and we can have dirty-logging
> enabled for it as well (as the VMM has no idea).
>
Ignore above bit, I confused memslot with block/page entry.
Looking a bit more, my viewpoint is that:
- Due to dirty_ring, checking memslot.dirty_bitmap should be done only to
detect the existence of a dirty_bitmap, not the migration process.
- This changes how detection works, in regardas to read-only blocks:
memslot_is_logging() -> Checks dirty-bitmap + read-only memslot
kvm_slot_dirty_track_enabled() -> Checks only memslot flag
- As a simpler change, we could have:
~~~
- return memslot->dirty_bitmap && !(memslot->flags & KVM_MEM_READONLY);
+ return kvm_slot_dirty_track_enabled(memslot) && !(memslot->flags & KVM_MEM_READONLY);
~~~
Both are cheking memslot->flags, so it will be probably optimized by the
compiler as:
~~~
return memslot->flags & 3 == 1
~~~
My main worry was that in the curent patch we are changing the behavior
on skipping read-only memslots. So going through the users, we can see:
> >
> > Fixes: 9cb1096f8590 ("KVM: arm64: Enable ring-based dirty memory tracking")
> > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > ---
> > It took me a long investigation to acquire the context needed to
> > understand this change, however the reason for this problem not being
> > detected is an educated guess. Please let me know if this is wrong or
> > if there are other issues, thanks!
> >
> > arch/arm64/kvm/mmu.c | 11 +++--------
> > 1 file changed, 3 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 4da9281312eb..06c46124d3e7 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -161,11 +161,6 @@ static int kvm_mmu_split_huge_pages(struct kvm *kvm, phys_addr_t addr,
> > return ret;
> > }
> >
> > -static bool memslot_is_logging(struct kvm_memory_slot *memslot)
> > -{
> > - return memslot->dirty_bitmap && !(memslot->flags & KVM_MEM_READONLY);
> > -}
> > -
> > /**
> > * kvm_arch_flush_remote_tlbs() - flush all VM TLB entries for v7/8
> > * @kvm: pointer to kvm structure.
> > @@ -1748,7 +1743,7 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
> > {
> > short vma_shift;
> >
> > - if (memslot_is_logging(s2fd->memslot)) {
> > + if (kvm_slot_dirty_track_enabled(s2fd->memslot)) {
> > s2vi->max_map_size = PAGE_SIZE;
> > vma_shift = PAGE_SHIFT;
> > } else {
On the case dirty_track is enabled in a read-only slot, it will resolve to
a smaller vma_size. The fault granule will be smaller here. This could be
bad for performance, so maybe we could add a check for read-only block
here:
~~~
- if (memslot_is_logging(s2fd->memslot)) {
+ if (kvm_slot_dirty_track_enabled(s2fd->memslot) &&
+ !memslot_is_readonly(s2fd->memslot) {
~~~
> > @@ -1953,7 +1948,7 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
> > *prot = KVM_PGTABLE_PROT_R;
> >
> > if (s2vi->map_writable && (s2vi->device ||
> > - !memslot_is_logging(s2fd->memslot) ||
> > + !kvm_slot_dirty_track_enabled(s2fd->memslot) ||
> > kvm_is_write_fault(s2fd->vcpu)))
> > *prot |= KVM_PGTABLE_PROT_W;
> >
On the same scenario (dirty_track enabled on readonly memslot):
This one should be safe, as kvm_is_write_fault() will check if the memslot
is readonly and return false in this case. But then, it will have to
actually call kvm_is_write_fault(), as the previous version would not even
call it in that scenario.
Not sure how would that impact perforformance, though.
> > @@ -2084,7 +2079,7 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
> > * and a write fault needs to collapse a block entry into a table.
> > */
> > memcache = get_mmu_memcache(s2fd->vcpu);
> > - if (!perm_fault || (memslot_is_logging(s2fd->memslot) &&
> > + if (!perm_fault || (kvm_slot_dirty_track_enabled(s2fd->memslot) &&
> > kvm_is_write_fault(s2fd->vcpu))) {
> > ret = topup_mmu_memcache(s2fd->vcpu, memcache);
> > if (ret)
Same thing, if memslot is tracking and is readonly, topup_*() would be
called with the new patch, but not with the old behavior.
All of that depends on how the VMM uses dirty_tracking: does it enable for
all memory, or only for memory that is writable?
I could not find anything that would prevent user from enabling
dirty_tracking on read-only memslots, so we can either ignore this
scenario, apply those patches and let those users carry the extra overhead,
or do an extra test to make sure it's doing the same thing as before.
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: mfd: syscon: Drop custom select for older dtschema
From: Conor Dooley @ 2026-06-09 16:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-renesas-soc, linux-rockchip, linux-omap
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-2-4eba9ec1212a@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 6856 bytes --]
On Mon, Jun 08, 2026 at 10:44:25PM +0200, Krzysztof Kozlowski wrote:
> Older dtschema <2024.02 required custom select to avoid applying this
> binding to anything having "syscon" compatible. That's not the case
> anymore and this additional select has two headaches:
>
> 1. Duplicates all the compatibles listed in the schema.
>
> 2. Is error-prone, because it requires contributor to add the compatible
> in two places, otherwise the schema will be silently ignored.
> The select list already misses mentioning compatibles:
> mediatek,mt8365-infracfg-nao and renesas,r9a08g046-lvds-cmn (with the
> latter being reverted for different reasons).
>
> This requires bumping minimum dtschema requirement to v2024.04, which
> feels old enough to be a safe requirement.
I agree, seems reasonable enough given it's a jump from 2023.09 and not
some large jump.
The diff is nice too!
I assume Rob will be taking it, but just in case..
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Cheers,
Conor.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Changes in v3:
> 1. Bump dtschema requirement
>
> Changes in v2:
> 1. New patch
> ---
> Documentation/devicetree/bindings/Makefile | 2 +-
> Documentation/devicetree/bindings/mfd/syscon.yaml | 116 ----------------------
> 2 files changed, 1 insertion(+), 117 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
> index 7b668f7fd400..40c2094f47c2 100644
> --- a/Documentation/devicetree/bindings/Makefile
> +++ b/Documentation/devicetree/bindings/Makefile
> @@ -6,7 +6,7 @@ DT_MK_SCHEMA ?= dt-mk-schema
> DT_SCHEMA_LINT = $(shell which yamllint || \
> echo "warning: python package 'yamllint' not installed, skipping" >&2)
>
> -DT_SCHEMA_MIN_VERSION = 2023.9
> +DT_SCHEMA_MIN_VERSION = 2024.4
>
> PHONY += check_dtschema_version
> check_dtschema_version:
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
> index 9c81010d5a74..b70018bf1bcf 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
> @@ -19,122 +19,6 @@ description: |
> maintainers:
> - Lee Jones <lee@kernel.org>
>
> -# Need a select with all compatibles listed for compatibility with older
> -# dtschema (<2024.02), so this will not be selected for other schemas having
> -# syscon fallback.
> -select:
> - properties:
> - compatible:
> - contains:
> - enum:
> - - airoha,en7581-pbus-csr
> - - al,alpine-sysfabric-service
> - - allwinner,sun8i-a83t-system-controller
> - - allwinner,sun8i-h3-system-controller
> - - allwinner,sun8i-v3s-system-controller
> - - allwinner,sun50i-a64-system-controller
> - - altr,l3regs
> - - altr,sdr-ctl
> - - amd,pensando-elba-syscon
> - - amlogic,meson-mx-assist
> - - amlogic,meson-mx-bootrom
> - - amlogic,meson8-analog-top
> - - amlogic,meson8b-analog-top
> - - amlogic,meson8-pmu
> - - amlogic,meson8b-pmu
> - - apm,merlin-poweroff-mailbox
> - - apm,mustang-poweroff-mailbox
> - - apm,xgene-csw
> - - apm,xgene-efuse
> - - apm,xgene-mcb
> - - apm,xgene-rb
> - - apm,xgene-scu
> - - atmel,sama5d2-sfrbu
> - - atmel,sama5d3-nfc-io
> - - atmel,sama5d3-sfrbu
> - - atmel,sama5d4-sfrbu
> - - axis,artpec6-syscon
> - - brcm,cru-clkset
> - - brcm,sr-cdru
> - - brcm,sr-mhb
> - - cirrus,ep7209-syscon1
> - - cirrus,ep7209-syscon2
> - - cirrus,ep7209-syscon3
> - - cnxt,cx92755-uc
> - - econet,en751221-chip-scu
> - - freecom,fsg-cs2-system-controller
> - - fsl,imx93-aonmix-ns-syscfg
> - - fsl,imx93-wakeupmix-syscfg
> - - fsl,ls1088a-reset
> - - fsl,vf610-anatop
> - - fsl,vf610-mscm-cpucfg
> - - hisilicon,dsa-subctrl
> - - hisilicon,hi6220-sramctrl
> - - hisilicon,hip04-ppe
> - - hisilicon,pcie-sas-subctrl
> - - hisilicon,peri-subctrl
> - - hpe,gxp-sysreg
> - - loongson,ls1b-syscon
> - - loongson,ls1c-syscon
> - - lsi,axxia-syscon
> - - marvell,armada-3700-cpu-misc
> - - marvell,armada-3700-nb-pm
> - - marvell,armada-3700-avs
> - - marvell,armada-3700-usb2-host-device-misc
> - - marvell,armada-3700-usb2-host-misc
> - - marvell,dove-global-config
> - - mediatek,mt2701-pctl-a-syscfg
> - - mediatek,mt2712-pctl-a-syscfg
> - - mediatek,mt6397-pctl-pmic-syscfg
> - - mediatek,mt7981-topmisc
> - - mediatek,mt7988-topmisc
> - - mediatek,mt8135-pctl-a-syscfg
> - - mediatek,mt8135-pctl-b-syscfg
> - - mediatek,mt8173-pctl-a-syscfg
> - - mediatek,mt8365-syscfg
> - - microchip,lan966x-cpu-syscon
> - - microchip,mpfs-control-scb
> - - microchip,mpfs-sysreg-scb
> - - microchip,sam9x60-sfr
> - - microchip,sama7d65-ddr3phy
> - - microchip,sama7d65-sfrbu
> - - microchip,sama7g5-ddr3phy
> - - mscc,ocelot-cpu-syscon
> - - mstar,msc313-pmsleep
> - - nuvoton,ma35d1-sys
> - - nuvoton,wpcm450-shm
> - - nxp,s32g2-gpr
> - - nxp,s32g3-gpr
> - - qcom,apq8064-mmss-sfpb
> - - qcom,apq8064-sps-sic
> - - rockchip,px30-qos
> - - rockchip,rk3036-qos
> - - rockchip,rk3066-qos
> - - rockchip,rk3128-qos
> - - rockchip,rk3228-qos
> - - rockchip,rk3288-qos
> - - rockchip,rk3368-qos
> - - rockchip,rk3399-qos
> - - rockchip,rk3528-qos
> - - rockchip,rk3562-qos
> - - rockchip,rk3568-qos
> - - rockchip,rk3576-qos
> - - rockchip,rk3588-qos
> - - rockchip,rv1126-qos
> - - st,spear1340-misc
> - - stericsson,nomadik-pmu
> - - starfive,jh7100-sysmain
> - - ti,am62-opp-efuse-table
> - - ti,am62-usb-phy-ctrl
> - - ti,am625-dss-oldi-io-ctrl
> - - ti,am62p-cpsw-mac-efuse
> - - ti,am654-dss-oldi-io-ctrl
> - - ti,j784s4-acspcie-proxy-ctrl
> - - ti,j784s4-pcie-ctrl
> - - ti,keystone-pllctrl
> - required:
> - - compatible
> -
> properties:
> compatible:
> oneOf:
>
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] PCI: meson: Propagate devm_add_action_or_reset() failure
From: Manivannan Sadhasivam @ 2026-06-09 16:25 UTC (permalink / raw)
To: Yue Wang, Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Shuvam Pandey
Cc: linux-pci, linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <177909148011.9588.6639767953842842291@gmail.com>
On Mon, 18 May 2026 13:49:40 +0545, Shuvam Pandey wrote:
> meson_pcie_probe_clock() enables a clock and then registers a devres
> action to disable it during teardown. If devm_add_action_or_reset()
> fails, it runs the action immediately, disabling the clock.
>
> The return value is currently ignored, so on that failure path
> meson_pcie_probe_clock() returns the disabled clock and probe continues.
> Return the error so the existing probe error path unwinds normally.
>
> [...]
Applied, thanks!
[1/1] PCI: meson: Propagate devm_add_action_or_reset() failure
commit: b12341b98d5ac52f48ca1390e1e371aed81346c8
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* [PATCH v2 5/7] clk: qcom: Add defaults for desired arm64 drivers
From: Krzysztof Kozlowski @ 2026-06-09 15:32 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260609-clk-qcom-defaults-v2-0-0c67c06dca11@oss.qualcomm.com>
Clock controller drivers are essential for booting up SoCs and are not
really optional for a given platform. Kernel should not ask users
choice of drivers when that choice is obvious and known to the
developers that answer should be 'yes' or 'module'.
Enable drivers for upstreamed or being upstreamed SoCs, which are not
yed enabled in defconfig: Glymur, Hawi, Nord, MSM8976, MSM8998 (GPU CC),
SC7180, SC8180X, SC8280XP, SC7280, SDM660, QDU1000, SM4450, SM7150,
SM8150, SM8450, SM6125, SM6375. Note that main GCC clock controller
drivers are usually already enabled for these.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
1. Add defaults for: MSM_GCC_8976, MSM_GPUCC_8998, SDM_GCC_660,
SDM_MMCC_660, SDM_GPUCC_660, HAWI
2. Drop the Konrad RB tag, considering above a significant change.
---
drivers/clk/qcom/Kconfig | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index ed969553649c..9afd4d752f3a 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -73,6 +73,7 @@ config CLK_GLYMUR_GPUCC
tristate "GLYMUR Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_GLYMUR_GCC
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on GLYMUR devices.
Say Y if you want to support graphics controller devices and
@@ -91,6 +92,7 @@ config CLK_GLYMUR_VIDEOCC
tristate "Glymur Video Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_GLYMUR_GCC
+ default m if ARCH_QCOM
help
Support for the video clock controller on Glymur devices.
Say Y if you want to support video devices and functionality such as
@@ -161,6 +163,7 @@ config CLK_NORD_GCC
tristate "Nord Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on Nord devices.
Say Y if you want to use peripheral devices such as UART,
@@ -328,6 +331,7 @@ config CLK_HAWI_GCC
tristate "Hawi Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on Hawi devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -336,6 +340,7 @@ config CLK_HAWI_GCC
config CLK_HAWI_TCSRCC
tristate "Hawi TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for the TCSR clock controller on Hawi devices.
Say Y if you want to use peripheral devices such as PCIe, USB, UFS.
@@ -661,6 +666,7 @@ config MSM_MMCC_8974
config MSM_GCC_8976
tristate "MSM8956/76 Global Clock Controller"
select QCOM_GDSC
+ default ARCH_QCOM if ARM64
help
Support for the global clock controller on msm8956/76 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -716,6 +722,7 @@ config MSM_GPUCC_8998
tristate "MSM8998 Graphics Clock Controller"
select MSM_GCC_8998
select QCOM_GDSC
+ default m if ARCH_QCOM && ARM64
help
Support for the graphics clock controller on MSM8998 devices.
Say Y if you want to support graphics controller devices and
@@ -785,6 +792,7 @@ config QCS_GCC_404
config CLK_NORD_TCSRCC
tristate "Nord TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for the TCSR clock controller on Nord devices.
Say Y if you want to use peripheral devices such as PCIe, USB, UFS etc.
@@ -845,6 +853,7 @@ config SC_CAMCC_7180
tristate "SC7180 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7180
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
SC7180 devices.
@@ -866,6 +875,7 @@ config SC_CAMCC_8180X
tristate "SC8180X Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_8180X
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
SC8180X devices.
@@ -898,6 +908,7 @@ config SC_DISPCC_7180
tristate "SC7180 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7180
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SC7180 devices.
@@ -1014,6 +1025,7 @@ config SC_GPUCC_7180
tristate "SC7180 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7180
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SC7180 devices.
Say Y if you want to support graphics controller devices and
@@ -1043,6 +1055,7 @@ config SC_LPASSCC_7280
tristate "SC7280 Low Power Audio Subsystem (LPASS) Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7280
+ default m if ARCH_QCOM
help
Support for the LPASS clock controller on SC7280 devices.
Say Y if you want to use the LPASS branch clocks of the LPASS clock
@@ -1084,6 +1097,7 @@ config SC_VIDEOCC_7180
tristate "SC7180 Video Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7180
+ default m if ARCH_QCOM
help
Support for the video clock controller on SC7180 devices.
Say Y if you want to support video devices and functionality such as
@@ -1112,6 +1126,7 @@ config SDM_GCC_660
tristate "SDM660 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the global clock controller on SDM660 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -1122,6 +1137,7 @@ config SDM_MMCC_660
depends on ARM64 || COMPILE_TEST
select SDM_GCC_660
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the multimedia clock controller on SDM660 devices.
Say Y if you want to support multimedia devices such as display,
@@ -1132,6 +1148,7 @@ config SDM_GPUCC_660
depends on ARM64 || COMPILE_TEST
select SDM_GCC_660
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SDM630/636/660 devices.
Say Y if you want to support graphics controller devices and
@@ -1165,6 +1182,7 @@ config QDU_ECPRICC_1000
tristate "QDU1000/QRU1000 ECPRI Clock Controller"
depends on ARM64 || COMPILE_TEST
select QDU_GCC_1000
+ default m if ARCH_QCOM
help
Support for the ECPRI clock controller on QDU1000 and
QRU1000 devices. Say Y if you want to support the ECPRI
@@ -1254,6 +1272,7 @@ config SM_CAMCC_4450
tristate "SM4450 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_4450
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM4450 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1271,6 +1290,7 @@ config SM_CAMCC_7150
tristate "SM7150 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_7150
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM7150 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1288,6 +1308,7 @@ config SM_CAMCC_8150
tristate "SM8150 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8150
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
SM8150 devices.
@@ -1307,6 +1328,7 @@ config SM_CAMCC_8450
tristate "SM8450 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8450
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM8450 or SM8475 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1344,6 +1366,7 @@ config SM_DISPCC_4450
tristate "SM4450 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_4450
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM4450 devices.
@@ -1365,6 +1388,7 @@ config SM_DISPCC_6125
tristate "SM6125 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_6125
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM6125 devices.
@@ -1375,6 +1399,7 @@ config SM_DISPCC_7150
tristate "SM7150 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_7150
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM7150 devices.
@@ -1407,6 +1432,7 @@ config SM_DISPCC_6375
tristate "SM6375 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_6375
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM6375 devices.
@@ -1482,6 +1508,7 @@ config SM_GCC_6125
tristate "SM6125 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM6125 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1501,6 +1528,7 @@ config SM_GCC_6375
tristate "SM6375 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM6375 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1510,6 +1538,7 @@ config SM_GCC_7150
tristate "SM7150 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM7150 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1600,6 +1629,7 @@ config SM_GPUCC_4450
tristate "SM4450 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_4450
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM4450 devices.
Say Y if you want to support graphics controller devices and
@@ -1619,6 +1649,7 @@ config SM_GPUCC_6125
tristate "SM6125 Graphics Clock Controller"
select SM_GCC_6125
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM6125 devices.
Say Y if you want to support graphics controller devices and
@@ -1628,6 +1659,7 @@ config SM_GPUCC_6375
tristate "SM6375 Graphics Clock Controller"
select SM_GCC_6375
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM6375 devices.
Say Y if you want to support graphics controller devices and
@@ -1728,6 +1760,7 @@ config SM_LPASSCC_6115
tristate "SM6115 Low Power Audio Subsystem (LPASS) Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_6115
+ default m if ARCH_QCOM
help
Support for the LPASS clock controller on SM6115 devices.
Say Y if you want to toggle LPASS-adjacent resets within
@@ -1788,6 +1821,7 @@ config SM_VIDEOCC_7150
depends on ARM64 || COMPILE_TEST
select SM_GCC_7150
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on SM7150 devices.
Say Y if you want to support video devices and functionality such as
@@ -1810,6 +1844,7 @@ config SM_VIDEOCC_8150
depends on ARM64 || COMPILE_TEST
select SM_GCC_8150
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on SM8150 devices.
Say Y if you want to support video devices and functionality such as
@@ -1831,6 +1866,7 @@ config SM_VIDEOCC_8350
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_8350 || SC_GCC_8280XP
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on SM8350 or SC8280XP devices.
Say Y if you want to support video devices and functionality such as
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v6 02/12] net: phylink: introduce internal phylink PCS handling
From: Christian Marangi @ 2026-06-09 15:11 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Christian Marangi,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260609151212.29469-1-ansuelsmth@gmail.com>
Introduce internal handling of PCS for phylink. This is an alternative
way to .mac_select_pcs that moves the selection logic of the PCS entirely
to phylink with the usage of the supported_interface value in the PCS
struct.
MAC should now provide a callback to fill the available PCS in
phylink_config in .fill_available_pcs and fill the .num_available_pcs with
the number of elements in the array. MAC should also define a new bitmap,
pcs_interfaces, in phylink_config to define for what interface mode a
dedicated PCS is required.
On phylink_create(), an array of PCS pointer is allocated of size
.num_available_pcs from phylink_config and .fill_available_pcs from
phylink_config is called passing as args the just allocated array and
the number of available element in it.
MAC will fill this passed array with all the available PCS.
This array is then parsed and a linked list of PCS is created based on
the allocated PCS array filled by MAC via .fill_available_pcs().
Also the supported_interface value in phylink struct is updated with the
new supported_interface from the provided PCS.
On phylink_start() every PCS in phylink PCS list gets attached to the
phylink instance. This is done by setting the phylink value in
phylink_pcs struct to the phylink instance.
On phylink_stop(), every PCS in phylink PCS list is detached from the
phylink instance. This is done by setting the phylink value in
phylink_pcs struct to NULL.
phylink_validate_mac_and_pcs(), phylink_major_config() and
phylink_inband_caps() are updated to support this new implementation
with the PCS list stored in phylink.
They will make use of phylink_validate_pcs_interface() that will loop
for every PCS in the phylink PCS available list and find one that supports
the passed interface.
phylink_validate_pcs_interface() applies the same logic of .mac_select_pcs
where if a supported_interface value is not set for the PCS struct, then
it's assumed every interface is supported.
A MAC is required to implement either a .mac_select_pcs or make use of
the PCS list implementation. Implementing both will result in a fail
on MAC/PCS validation.
A MAC defining .num_available_pcs in phylink_config MUST also define a
.fill_available_pcs or phylink_create() will fail with an negative error.
phylink value in phylink_pcs struct with this implementation is used to
track from PCS side when it's attached to a phylink instance. PCS driver
will make use of this information to correctly detach from a phylink
instance if needed.
The .mac_select_pcs implementation is not changed but it's expected that
every MAC driver migrates to the new implementation to later deprecate
and remove .mac_select_pcs.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/net/phy/phylink.c | 185 ++++++++++++++++++++++++++++++++++----
include/linux/phylink.h | 16 ++++
2 files changed, 183 insertions(+), 18 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 4d59c0dd78db..4d6ffda0cdd6 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -60,6 +60,9 @@ struct phylink {
/* The link configuration settings */
struct phylink_link_state link_config;
+ /* List of available PCS */
+ struct list_head pcs_list;
+
/* What interface are supported by the current link.
* Can change on removal or addition of new PCS.
*/
@@ -154,6 +157,8 @@ static const phy_interface_t phylink_sfp_interface_preference[] = {
static DECLARE_PHY_INTERFACE_MASK(phylink_sfp_interfaces);
+static void phylink_run_resolve(struct phylink *pl);
+
/**
* phylink_set_port_modes() - set the port type modes in the ethtool mask
* @mask: ethtool link mode mask
@@ -518,22 +523,59 @@ static void phylink_validate_mask_caps(unsigned long *supported,
linkmode_and(state->advertising, state->advertising, mask);
}
+static int phylink_validate_pcs_interface(struct phylink_pcs *pcs,
+ phy_interface_t interface)
+{
+ /* If PCS define an empty supported_interfaces value, assume
+ * all interface are supported.
+ */
+ if (phy_interface_empty(pcs->supported_interfaces))
+ return 0;
+
+ /* Ensure that this PCS supports the interface mode */
+ if (!test_bit(interface, pcs->supported_interfaces))
+ return -EINVAL;
+
+ return 0;
+}
+
static int phylink_validate_mac_and_pcs(struct phylink *pl,
unsigned long *supported,
struct phylink_link_state *state)
{
- struct phylink_pcs *pcs = NULL;
unsigned long capabilities;
+ struct phylink_pcs *pcs;
+ bool pcs_found = false;
int ret;
/* Get the PCS for this interface mode */
if (pl->mac_ops->mac_select_pcs) {
+ /* Make sure either PCS internal validation or .mac_select_pcs
+ * is used. Return error if both are defined.
+ */
+ if (!list_empty(&pl->pcs_list)) {
+ phylink_err(pl, "either phylink_pcs_add() or .mac_select_pcs must be used\n");
+ return -EINVAL;
+ }
+
pcs = pl->mac_ops->mac_select_pcs(pl->config, state->interface);
if (IS_ERR(pcs))
return PTR_ERR(pcs);
+
+ pcs_found = !!pcs;
+ } else {
+ /* Check every assigned PCS and search for one that supports
+ * the interface.
+ */
+ list_for_each_entry(pcs, &pl->pcs_list, list) {
+ if (!phylink_validate_pcs_interface(pcs, state->interface)) {
+ pcs_found = true;
+ break;
+ }
+ }
}
- if (pcs) {
+ if (pcs_found) {
/* The PCS, if present, must be setup before phylink_create()
* has been called. If the ops is not initialised, print an
* error and backtrace rather than oopsing the kernel.
@@ -545,13 +587,10 @@ static int phylink_validate_mac_and_pcs(struct phylink *pl,
return -EINVAL;
}
- /* Ensure that this PCS supports the interface which the MAC
- * returned it for. It is an error for the MAC to return a PCS
- * that does not support the interface mode.
- */
- if (!phy_interface_empty(pcs->supported_interfaces) &&
- !test_bit(state->interface, pcs->supported_interfaces)) {
- phylink_err(pl, "MAC returned PCS which does not support %s\n",
+ /* Recheck PCS to handle legacy way for .mac_select_pcs */
+ ret = phylink_validate_pcs_interface(pcs, state->interface);
+ if (ret) {
+ phylink_err(pl, "selected PCS does not support %s\n",
phy_modes(state->interface));
return -EINVAL;
}
@@ -965,12 +1004,22 @@ static unsigned int phylink_inband_caps(struct phylink *pl,
phy_interface_t interface)
{
struct phylink_pcs *pcs;
+ bool pcs_found = false;
- if (!pl->mac_ops->mac_select_pcs)
- return 0;
+ if (pl->mac_ops->mac_select_pcs) {
+ pcs = pl->mac_ops->mac_select_pcs(pl->config,
+ interface);
+ pcs_found = !!pcs;
+ } else {
+ list_for_each_entry(pcs, &pl->pcs_list, list) {
+ if (!phylink_validate_pcs_interface(pcs, interface)) {
+ pcs_found = true;
+ break;
+ }
+ }
+ }
- pcs = pl->mac_ops->mac_select_pcs(pl->config, interface);
- if (!pcs)
+ if (!pcs_found)
return 0;
return phylink_pcs_inband_caps(pcs, interface);
@@ -1265,10 +1314,36 @@ static void phylink_major_config(struct phylink *pl, bool restart,
pl->major_config_failed = true;
return;
}
+ /* Find a PCS in available PCS list for the requested interface.
+ * This doesn't overwrite the previous .mac_select_pcs as either
+ * .mac_select_pcs or PCS list implementation are permitted.
+ *
+ * Skip searching if the MAC doesn't require a dedicaed PCS for
+ * the requested interface.
+ */
+ } else if (test_bit(state->interface, pl->config->pcs_interfaces)) {
+ bool pcs_found = false;
+
+ list_for_each_entry(pcs, &pl->pcs_list, list) {
+ if (!phylink_validate_pcs_interface(pcs,
+ state->interface)) {
+ pcs_found = true;
+ break;
+ }
+ }
- pcs_changed = pl->pcs != pcs;
+ if (!pcs_found) {
+ phylink_err(pl,
+ "couldn't find a PCS for %s\n",
+ phy_modes(state->interface));
+
+ pl->major_config_failed = true;
+ return;
+ }
}
+ pcs_changed = pl->pcs != pcs;
+
phylink_pcs_neg_mode(pl, pcs, state->interface, state->advertising);
phylink_dbg(pl, "major config, active %s/%s/%s\n",
@@ -1295,11 +1370,13 @@ static void phylink_major_config(struct phylink *pl, bool restart,
if (pcs_changed) {
phylink_pcs_disable(pl->pcs);
- if (pl->pcs)
- pl->pcs->phylink = NULL;
+ if (pl->mac_ops->mac_select_pcs) {
+ if (pl->pcs)
+ pl->pcs->phylink = NULL;
- if (pcs)
- pcs->phylink = pl;
+ if (pcs)
+ pcs->phylink = pl;
+ }
pl->pcs = pcs;
}
@@ -1834,6 +1911,44 @@ int phylink_set_fixed_link(struct phylink *pl,
}
EXPORT_SYMBOL_GPL(phylink_set_fixed_link);
+static int phylink_fill_available_pcs(struct phylink *pl,
+ struct phylink_config *config)
+{
+ struct phylink_pcs **pcss;
+ int i, ret;
+
+ if (!config->num_available_pcs)
+ return 0;
+
+ if (!config->fill_available_pcs) {
+ dev_err(config->dev,
+ "phylink: error: num_available_pcs defined but no fill_available_pcs\n");
+ return -EINVAL;
+ }
+
+ pcss = kzalloc_objs(*pcss, config->num_available_pcs);
+ if (!pcss)
+ return -ENOMEM;
+
+ ret = config->fill_available_pcs(config, pcss, config->num_available_pcs);
+ if (ret)
+ goto out;
+
+ for (i = 0; i < config->num_available_pcs; i++) {
+ struct phylink_pcs *pcs = pcss[i];
+
+ if (!pcs)
+ continue;
+
+ list_add(&pcs->list, &pl->pcs_list);
+ }
+
+out:
+ kfree(pcss);
+
+ return ret;
+}
+
/**
* phylink_create() - create a phylink instance
* @config: a pointer to the target &struct phylink_config
@@ -1855,6 +1970,7 @@ struct phylink *phylink_create(struct phylink_config *config,
phy_interface_t iface,
const struct phylink_mac_ops *mac_ops)
{
+ struct phylink_pcs *pcs;
struct phylink *pl;
int ret;
@@ -1872,9 +1988,21 @@ struct phylink *phylink_create(struct phylink_config *config,
mutex_init(&pl->phydev_mutex);
mutex_init(&pl->state_mutex);
INIT_WORK(&pl->resolve, phylink_resolve);
+ INIT_LIST_HEAD(&pl->pcs_list);
+
+ /* Fill the PCS list with available PCS from phylink config */
+ ret = phylink_fill_available_pcs(pl, config);
+ if (ret) {
+ kfree(pl);
+ return ERR_PTR(ret);
+ }
phy_interface_copy(pl->supported_interfaces,
config->supported_interfaces);
+ list_for_each_entry(pcs, &pl->pcs_list, list)
+ phy_interface_or(pl->supported_interfaces,
+ pl->supported_interfaces,
+ pcs->supported_interfaces);
pl->config = config;
if (config->type == PHYLINK_NETDEV) {
@@ -1953,10 +2081,16 @@ EXPORT_SYMBOL_GPL(phylink_create);
*/
void phylink_destroy(struct phylink *pl)
{
+ struct phylink_pcs *pcs, *tmp;
+
sfp_bus_del_upstream(pl->sfp_bus);
if (pl->link_gpio)
gpiod_put(pl->link_gpio);
+ /* Remove every PCS from phylink PCS list */
+ list_for_each_entry_safe(pcs, tmp, &pl->pcs_list, list)
+ list_del(&pcs->list);
+
cancel_work_sync(&pl->resolve);
kfree(pl);
}
@@ -2437,6 +2571,7 @@ static irqreturn_t phylink_link_handler(int irq, void *data)
*/
void phylink_start(struct phylink *pl)
{
+ struct phylink_pcs *pcs;
bool poll = false;
ASSERT_RTNL();
@@ -2463,6 +2598,10 @@ void phylink_start(struct phylink *pl)
pl->pcs_state = PCS_STATE_STARTED;
+ /* link available PCS to phylink struct */
+ list_for_each_entry(pcs, &pl->pcs_list, list)
+ pcs->phylink = pl;
+
phylink_enable_and_run_resolve(pl, PHYLINK_DISABLE_STOPPED);
if (pl->cfg_link_an_mode == MLO_AN_FIXED && pl->link_gpio) {
@@ -2507,6 +2646,8 @@ EXPORT_SYMBOL_GPL(phylink_start);
*/
void phylink_stop(struct phylink *pl)
{
+ struct phylink_pcs *pcs;
+
ASSERT_RTNL();
if (pl->sfp_bus)
@@ -2524,6 +2665,14 @@ void phylink_stop(struct phylink *pl)
pl->pcs_state = PCS_STATE_DOWN;
phylink_pcs_disable(pl->pcs);
+
+ /* Drop link between phylink and PCS */
+ list_for_each_entry(pcs, &pl->pcs_list, list)
+ pcs->phylink = NULL;
+
+ /* Restore original supported interfaces */
+ phy_interface_copy(pl->supported_interfaces,
+ pl->config->supported_interfaces);
}
EXPORT_SYMBOL_GPL(phylink_stop);
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index 2bc0db3d52ac..3387d308c4ad 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -12,6 +12,7 @@ struct ethtool_cmd;
struct fwnode_handle;
struct net_device;
struct phylink;
+struct phylink_pcs;
enum {
MLO_PAUSE_NONE,
@@ -151,6 +152,8 @@ enum phylink_op_type {
* if MAC link is at %MLO_AN_FIXED mode.
* @supported_interfaces: bitmap describing which PHY_INTERFACE_MODE_xxx
* are supported by the MAC/PCS.
+ * @pcs_interfaces: bitmap describing for which PHY_INTERFACE_MODE_xxx a
+ * dedicated PCS is required.
* @lpi_interfaces: bitmap describing which PHY interface modes can support
* LPI signalling.
* @mac_capabilities: MAC pause/speed/duplex capabilities.
@@ -160,6 +163,10 @@ enum phylink_op_type {
* @wol_phy_legacy: Use Wake-on-Lan with PHY even if phy_can_wakeup() is false
* @wol_phy_speed_ctrl: Use phy speed control on suspend/resume
* @wol_mac_support: Bitmask of MAC supported %WAKE_* options
+ * @num_available_pcs: num of available phylink_pcs PCS
+ * @fill_available_pcs: callback to fill the available PCS in the passed
+ * array struct of phylink_pcs PCS available_pcs up to
+ * num_available_pcs.
*/
struct phylink_config {
struct device *dev;
@@ -172,6 +179,7 @@ struct phylink_config {
void (*get_fixed_state)(struct phylink_config *config,
struct phylink_link_state *state);
DECLARE_PHY_INTERFACE_MASK(supported_interfaces);
+ DECLARE_PHY_INTERFACE_MASK(pcs_interfaces);
DECLARE_PHY_INTERFACE_MASK(lpi_interfaces);
unsigned long mac_capabilities;
unsigned long lpi_capabilities;
@@ -182,6 +190,11 @@ struct phylink_config {
bool wol_phy_legacy;
bool wol_phy_speed_ctrl;
u32 wol_mac_support;
+
+ unsigned int num_available_pcs;
+ int (*fill_available_pcs)(struct phylink_config *config,
+ struct phylink_pcs **available_pcs,
+ unsigned int num_available_pcs);
};
void phylink_limit_mac_speed(struct phylink_config *config, u32 max_speed);
@@ -497,6 +510,9 @@ struct phylink_pcs {
struct phylink *phylink;
bool poll;
bool rxc_always_on;
+
+ /* private: */
+ struct list_head list;
};
/**
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
From: Conor Dooley @ 2026-06-09 16:15 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Daniel Baluta, Josua Mayer, Dario Binacchi,
Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve, Conor Dooley
In-Reply-To: <c65129896fc6ce80044ee1d89e12dcdff34945be.1780998600.git.stefano.r@variscite.com>
[-- Attachment #1: Type: text/plain, Size: 4029 bytes --]
On Tue, Jun 09, 2026 at 11:51:18AM +0200, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> Add DT compatible strings for Variscite DART-MX8MP SoM and Variscite
> development carrier Board.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
My mailbox looking like
| 169 ND Jun 09 Stefano Radaell ( 27K) ┌─>[PATCH v5 3/3] arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
| 170 ND Jun 09 sashiko-bot@ker (7.2K) │ ┌─>
| 171 ND Jun 09 Stefano Radaell ( 24K) ├─>[PATCH v5 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS
| 172 D Jun 09 Stefano Radaell ( 43) ├─>[PATCH v5 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
| 173 ND Jun 09 Stefano Radaell ( 10K) [PATCH v5 0/3] Add support for Variscite DART-MX8M-PLUS and Sonata board
| 174 ND Jun 09 sashiko-bot@ker (7.1K) ┌─>
| 175 ND Jun 09 Hongliang Wang (7.8K) ┌─>[PATCH v1 2/3] LoongArch: dts: i2c: Add clocks and clock-frequency properties to 2K1000
| 176 ND Jun 09 Hongliang Wang (8.9K) ├─>[PATCH v1 1/3] LoongArch: dts: i2c: Add clocks and clock-frequency properties to 2K0500
| 177 ND Jun 09 Hongliang Wang (7.7K) ├─>[PATCH v1 3/3] LoongArch: dts: i2c: Add clocks and clock-frequency properties to 2K2000
| 178 ND Jun 09 Hongliang Wang (7.0K) [PATCH v1 0/3] LoongArch: dts: i2c: Add clocks and clock-frequency properties
| 179 ND Jun 09 Stefano Radaell ( 27K) ┌─>[PATCH v4 3/3] arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
| 180 ND Jun 09 sashiko-bot@ker (7.7K) │ ┌─>
| 181 ND Jun 09 Stefano Radaell ( 24K) ├─>[PATCH v4 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS
| 182 D Jun 09 Stefano Radaell ( 40) ├─>[PATCH v4 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
| 183 ND Jun 09 Stefano Radaell ( 10K) [PATCH v4 0/3] Add support for Variscite DART-MX8M-PLUS and Sonata board
| 184 D Jun 09 Paolo Abeni ( 19) Re: [PATCH v2 1/1] dt-bindings: net: dsa: Convert lan9303.txt to yaml format
| 185 N Jun 09 Stefano Radaell ( 27K) ┌─>[PATCH v3 3/3] arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
| 186 N Jun 09 sashiko-bot@ker (7.1K) │ ┌─>
| 187 N Jun 09 Stefano Radaell ( 24K) ├─>[PATCH v3 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS
| 188 Jun 09 Stefano Radaell ( 36) ├─>[PATCH v3 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
| 189 N Jun 09 Stefano Radaell ( 10K) [PATCH v3 0/3] Add support for Variscite DART-MX8M-PLUS and Sonata board
is a pretty clear indication that you're iterating too quickly.
Try to slow down and leave people time to respond before sending new
versions, not just respin for every automated response you get.
Cheers,
Conor.
> ---
> v4->v5:
> -
>
> v3->v4:
> -
>
> v2->v3:
> -
>
> v1->v2:
> -
>
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 86876311ec59..11629b9eafc5 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -1310,6 +1310,12 @@ properties:
> - const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
> - const: fsl,imx8mp
>
> + - description: Variscite DART-MX8M Plus based boards
> + items:
> + - const: variscite,var-dart-mx8mp-sonata # Variscite DART-MX8MP on Sonata Development Board
> + - const: variscite,var-dart-mx8mp # Variscite DART-MX8MP SOM
> + - const: fsl,imx8mp
> +
> - description: Variscite VAR-SOM-MX8M Plus based boards
> items:
> - const: variscite,var-som-mx8mp-symphony
> --
> 2.47.3
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt64 for v7.2 (#1)
From: Arnd Bergmann @ 2026-06-09 16:11 UTC (permalink / raw)
To: Gregory Clement, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel,
Aleksander Jan Bajkowski
In-Reply-To: <8733z1c8uj.fsf@BLaptop.bootlin.com>
On Fri, Jun 5, 2026, at 17:20, Gregory CLEMENT wrote:
>
> ----------------------------------------------------------------
> mvebu dt64 for 7.2 (part 1)
>
> Mark EIP97 as dma-coherent for Armada 3720
>
> ----------------------------------------------------------------
> Aleksander Jan Bajkowski (1):
> arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
Hi Gregory and Aleksander,
I'm a bit surprised by this oneline change. Since you successfully tested
this, I assume the change is correct, but I have two questions that
I would like to have an answer for before I pull it.
- I would expect a missing 'dma-coherent' property to cause data
corruption, as the DMA master may write directly into the L2
cache, which is then invalidated before the CPU accesses it.
Do you have any idea how this one ends up working even when
the property is missing?
- I see that the Product Brief for Armada 37xx mentions that it
has a "High-bandwidth, low-latency IO Cache Coherency" interconnect,
which also indicates that the patch is correct. However I don't
see why it's only the crypto engine that needs it. What about
the other high-speed DMA masters (neta, xhci, pcie, sata, ...)?
Arnd
^ permalink raw reply
* [PATCH net-next v6 06/12] net: Document PCS subsystem
From: Christian Marangi @ 2026-06-09 15:12 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Christian Marangi,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260609151212.29469-1-ansuelsmth@gmail.com>
Add extensive documentation of the new PCS subsystem and the fwnode
implementation with producer/consumer API.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
Documentation/networking/index.rst | 1 +
Documentation/networking/pcs.rst | 228 +++++++++++++++++++++++++++++
2 files changed, 229 insertions(+)
create mode 100644 Documentation/networking/pcs.rst
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 44a422ad3b05..3fce8f6ac089 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -28,6 +28,7 @@ Contents:
net_failover
page_pool
phy
+ pcs
sfp-phylink
alias
bridge
diff --git a/Documentation/networking/pcs.rst b/Documentation/networking/pcs.rst
new file mode 100644
index 000000000000..9436ba43cebd
--- /dev/null
+++ b/Documentation/networking/pcs.rst
@@ -0,0 +1,228 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+PCS Subsystem
+=============
+
+The PCS (Physical Coding Sublayer) subsystem handles the registration and lookup
+of PCS devices. These devices contain the upper sublayers of the Ethernet
+physical layer, generally handling framing, scrambling, and encoding tasks. PCS
+devices may also include PMA (Physical Medium Attachment) components. PCS
+devices transfer data between the Link-layer MAC device, and the rest of the
+physical layer, typically via a serdes. The output of the serdes may be
+connected more-or-less directly to the medium when using fiber-optic or
+backplane connections (1000BASE-SX, 1000BASE-KX, etc). It may also communicate
+with a separate PHY (such as over SGMII) which handles the connection to the
+medium (such as 1000BASE-T).
+
+Remark on usage of .mac_select_pcs and fw_node PCS
+--------------------------------------------------
+
+There are generally two ways to look up a PCS device.
+
+1. MAC OP struct .mac_select_pcs (considered legacy)
+2. firmware node (fwnode) PCS entirely handled by phylink
+
+Implementation 1 leaves the entire handling of the PCS to the MAC
+driver with the selection of the PCS driven by .mac_select_pcs.
+Custom implementations are required if the PCS is external to the MAC
+and needs to be handled by a separate driver.
+
+This implementation is considered legacy and it's suggested to
+switch to the new fwnode PCS.
+
+Looking up PCS Devices (fwnode implementation)
+-----------------------------------------------
+
+The lookup of a PCS device follows the common producer/consumer implementation
+used by similar subsystem with a ``#pcs-cells`` on the producer and a
+``pcs-handle`` property on the consumer::
+
+ pcs: pcs {
+ // ...
+ #pcs-cells = <0>;
+ };
+
+ ethernet-controller {
+ // ...
+ pcs-handle = <&pcs>;
+ };
+
+On :c:func:`phylink_create`, phylink will use the ``num_available_pcs``
+value and ``fill_available_pcs`` helper function in
+:c:struct:`phylink_config` to compose the list of available PCS that can be
+used for the phylink instance.
+
+Phylink will then internally handle the selection of the correct PCS for
+the requested interface mode based on the interface modes configured in
+``pcs_interfaces`` in :c:struct:`phylink_config` struct and
+``supported_interfaces`` in :c:struct:`phylink_pcs` struct.
+
+A PCS is considered eligible when the requested interface mode is present
+in both ``pcs_interfaces`` in :c:struct:`phylink_config` struct and
+``supported_interfaces`` in :c:struct:`phylink_pcs` struct.
+
+``supported_interfaces`` describes all interface modes supported by the MAC,
+whereas ``pcs_interfaces`` identifies the subset that require PCS selection.
+
+For the special implementation where the PCS is internal or part of the MAC
+and a dedicated driver is not needed, it's possible to leave the implementation
+of the PCS to the MAC driver and just implement the ``num_available_pcs``
+value and ``fill_available_pcs`` helper function in
+:c:struct:`phylink_config` referencing the local :c:struct:`phylink_pcs`
+struct allocated from the MAC driver.
+
+Using PCS Devices
+-----------------
+
+It's mandatory to either implement the ``mac_select_pcs`` callback
+of :c:struct:`phylink_mac_ops` or ``num_available_pcs`` and ``fill_available_pcs`` of :c:struct:`phylink_config` to use a PCS
+for a MAC.
+
+The fwnode implementation expose a simple helper to parse the PCS from
+the fwnode :c:func:`fwnode_phylink_pcs_parse`. The helper takes three arguments,
+the fwnode where the ``pcs-handle`` should be parsed, an allocated array
+of :c:struct:`phylink_pcs` pointer where to put the parsed PCS from the fwnode
+and a pointer to the maximum number of PCS to parse. The helper can also be used
+to obtain the number of PCS parsed (without filling the array) by passing
+``NULL`` for the second arg. In such case, the third arg will be set to the
+number of PCS parsed in the fwnode.
+
+A phylink instance may use multiple PCS devices. The maximum number is reported
+through ``num_available_pcs``.
+
+It's mandatory to specify for what interface a PCS is needed. This can be done
+by filling the ``pcs_interfaces`` in :c:struct:`phylink_config` struct.
+If the requested interface mode is not present in this bitmask, phylink does
+not search for a PCS for that specific mode. (example MAC doesn't need a PCS
+for SGMII but require one for USXGMII)
+
+With the use of the :c:func:`fwnode_phylink_pcs_parse` a common implementation
+is the following::
+
+ static int mac_fill_available_pcs(struct phylink_config *config,
+ struct phylink_pcs **available_pcs,
+ unsigned int num_available_pcs)
+ {
+ struct device *dev = config->dev;
+
+ return fwnode_phylink_pcs_parse(dev_fwnode(dev), available_pcs,
+ &num_available_pcs);
+ }
+
+ static int mac_setup_phylink(struct net_device *netdev)
+ {
+ struct phylink_config *config;
+
+ // ...
+
+ config->dev = &netdev->dev;
+
+ // ...
+
+ // Parse available PCS and fill num_available_pcs.
+ err = fwnode_phylink_pcs_parse(dev_fwnode(&netdev->dev), NULL,
+ &config->num_available_pcs);
+ if (err)
+ return err;
+
+ config->fill_available_pcs = mac_fill_available_pcs;
+
+ __set_bit(PHY_INTERFACE_MODE_INTERNAL, config->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_SGMII, config->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_1000BASEX, config->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_USXGMII, config->supported_interfaces);
+
+ // PCS required only for USXGMII
+ __set_bit(PHY_INTERFACE_MODE_USXGMII, config->pcs_interfaces);
+
+ phylink = phylink_create(config, //...
+
+It's worth to mention that it's phylink code that takes care of allocating
+the array of :c:struct:`phylink_pcs` pointer for ``fill_available_pcs``
+callback based on the value set in ``num_available_pcs`` for
+:c:struct:`phylink_config` struct.
+
+The ``fill_available_pcs`` callback must not write more than
+``num_available_pcs`` entries. The third argument may be used to validate
+that there is enough space to fill all the available PCS in the passed array
+of :c:struct:`phylink_pcs` pointer.
+
+The ``fill_available_pcs`` callback is called only on :c:func:`phylink_create`
+and is used only to compose the initial available PCS list. Ownership of PCS
+is held by phylink and :c:func:`phylink_release_pcs` should be used to relase
+them.
+
+Writing PCS Drivers
+-------------------
+
+To write a PCS driver, first implement :c:struct:`phylink_pcs_ops`. Then,
+register your PCS in your probe function using :c:func:`fwnode_pcs_add_provider`.
+The :c:func:`fwnode_pcs_add_provider` takes three arg, the fwnode where the PCS
+provider should be registered to, a get function to return the requested PCS
+based on ``#pcs-cells`` and a pointer to reference private data for the get
+function.
+
+The PCS will then be registered to a global list of PCS provider that the
+PCS fwnode implementation will use to parse it.
+
+For the simple case where the PCS driver expose a single PCS,
+:c:func:`fwnode_pcs_simple_get` can be used as the get function.
+
+You must call :c:func:`fwnode_pcs_del_provider` from your remove function and
+release the PCS from any phylink instance under RTNL lock with
+:c:func:`phylink_release_pcs`::
+
+ fwnode_pcs_del_provider(dev_fwnode(&pdev->dev));
+
+ rtnl_lock();
+
+ for (i = 0; i < data->num_port; i++) {
+ struct pcs_port *port = &priv->ports[i];
+
+ phylink_release_pcs(&port->pcs);
+ }
+
+ rtnl_unlock();
+
+Late PCS registration handling
+------------------------------
+
+It's possible that a PCS becomes available after the MAC finished probing.
+Contrary to the usual producer/consumer implementation, when a PCS is not
+registered and can't be found, the fwnode parser helper returns ``-EINVAL``
+instead of ``-EPROBE_DEFER``.
+
+This is to prevent race condition with particular devices that register
+MAC and PCS with USB or PCIe and require the MAC to be registered before
+the PCS.
+
+The phylink logic correctly handle this special case and keep the phylink
+instance in a fail condition.
+
+The PCS fwnode implementation provides a notifier to which each phylink
+instance with a non-empty ``pcs_interfaces`` in :c:type:`phylink_config`
+registers. When a new PCS provider is registered, the notifier is called
+triggering the :c:func:`pcs_provider_notify` function.
+
+Function :c:func:`pcs_provider_notify` will check if the just added PCS
+should be used by the phylink instance. If it should be used then,
+it's added to the internal list of available PCS and a phylink major
+config is forced.
+
+If a phylink instance was in a failure state, with the just added PCS
+now part of the available PCS internal phylink list, provided all other
+conditions are satisfied, the configuration is retried and the failure
+condition is cleared.
+
+API Reference
+-------------
+
+.. kernel-doc:: include/linux/phylink.h
+ :identifiers: phylink_pcs
+
+.. kernel-doc:: include/linux/pcs/pcs.h
+ :internal:
+
+.. kernel-doc:: include/linux/pcs/pcs-provider.h
+ :internal:
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Conor Dooley @ 2026-06-09 16:01 UTC (permalink / raw)
To: rva333
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260609-mt6323-adc-v2-1-aa93a22309f9@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3739 bytes --]
On Tue, Jun 09, 2026 at 04:31:58PM +0300, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
> temperature, and other internal measurements.
>
> Add the devicetree binding documentation and the associated header file
> defining the ADC channel constants.
>
> Also change the description to 'MT6350 series and similar' because
> the binding already includes more than mt635x series PMICs.
>
> Finally, add the MAINTAINERS entry for the header with ADC constants.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> .../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 ++-
> MAINTAINERS | 6 ++++++
> .../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++++++++++++++++++++++
> 3 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> index 5d4ab701f51a..852eb7336a5a 100644
> --- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: MediaTek MT6350 series PMIC AUXADC
> +title: MediaTek MT6350 series and similar PMIC AUXADC
>
> maintainers:
> - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> @@ -19,6 +19,7 @@ description:
> properties:
> compatible:
> enum:
> + - mediatek,mt6323-auxadc
Commit message needs to explain why a fallback is not suitable.
pw-bot: changes-requested
> - mediatek,mt6357-auxadc
> - mediatek,mt6358-auxadc
> - mediatek,mt6359-auxadc
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d1cc0e12fe1f..2551c8cd9e9d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16256,6 +16256,12 @@ S: Maintained
> F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
> F: drivers/mmc/host/mtk-sd.c
>
> +MEDIATEK MT6323 PMIC AUXADC DRIVER
> +M: Roman Vivchar <rva333@protonmail.com>
> +L: linux-iio@vger.kernel.org
> +S: Maintained
> +F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
Why is the binding not being included here?
Cheers,
Conor.
> +
> MEDIATEK MT6735 CLOCK & RESET DRIVERS
> M: Yassine Oudjana <y.oudjana@protonmail.com>
> L: linux-clk@vger.kernel.org
> diff --git a/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
> new file mode 100644
> index 000000000000..6ee9a9ecffc1
> --- /dev/null
> +++ b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +#ifndef _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
> +#define _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
> +
> +#define MT6323_AUXADC_BATON2 0
> +#define MT6323_AUXADC_CH6 1
> +#define MT6323_AUXADC_BAT_TEMP 2
> +#define MT6323_AUXADC_CHIP_TEMP 3
> +#define MT6323_AUXADC_VCDT 4
> +#define MT6323_AUXADC_BATON1 5
> +#define MT6323_AUXADC_ISENSE 6
> +#define MT6323_AUXADC_BATSNS 7
> +#define MT6323_AUXADC_ACCDET 8
> +#define MT6323_AUXADC_AUDIO0 9
> +#define MT6323_AUXADC_AUDIO1 10
> +#define MT6323_AUXADC_AUDIO2 11
> +#define MT6323_AUXADC_AUDIO3 12
> +#define MT6323_AUXADC_AUDIO4 13
> +#define MT6323_AUXADC_AUDIO5 14
> +#define MT6323_AUXADC_AUDIO6 15
> +#define MT6323_AUXADC_AUDIO7 16
> +
> +#endif
>
> --
> 2.54.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Conor Dooley @ 2026-06-09 15:56 UTC (permalink / raw)
To: Jonas Karlman
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Diederik de Haas, devicetree, linux-rockchip,
linux-usb, linux-arm-kernel, linux-kernel
In-Reply-To: <20260609154124.445182-2-jonas@kwiboo.se>
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
On Tue, Jun 09, 2026 at 03:41:22PM +0000, Jonas Karlman wrote:
> The Rockchip RK3568 EHCI/OHCI controller depends on clk_usbphy1_480m
> being enabled, or the system may freeze when registers are accessed.
>
> Add Rockchip RK3568 EHCI and OHCI compatibles with a similar four-clock
> constraint as RK3588.
>
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> ---
> Existing DTs for RK3568 use the plain generic-ehci/ohci compatible,
> next patch make use of these new compatibles and adds the missing
> clk_usbphy1_480m clock references.
Reasonable complaint here from Sashiko.
pw-bot: changes-requested
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset
From: Frank Li @ 2026-06-09 15:51 UTC (permalink / raw)
To: Felix Gu
Cc: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Liu Ying, linux-phy, imx,
linux-arm-kernel, linux-kernel, sashiko
In-Reply-To: <20260609-lvds-phy-v1-1-6ad790c6d0ea@gmail.com>
On Tue, Jun 09, 2026 at 10:48:50PM +0800, Felix Gu wrote:
>
> The mixel_lvds_phy_reset() function pairs pm_runtime_resume_and_get()
> with pm_runtime_put(). The asynchronous variant queues a work item
> to handle the idle check and potential suspend, which can be cancelled
> by a subsequent pm_runtime_disable() call if probe fails after the reset.
>
> Switch to pm_runtime_put_sync() to run the idle check and suspend
> synchronously.
>
> Fixes: 06ff622d61d2 ("phy: freescale: Add i.MX8qm Mixel LVDS PHY support")
> Reported-by: sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260605-lvds-v2-1-3ce7539d1104%40gmail.com
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c b/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
> index ece357443521..e2a1645000ae 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
> @@ -286,7 +286,7 @@ static int mixel_lvds_phy_reset(struct device *dev)
>
> regmap_write(priv->regmap, PHY_CTRL, CTRL_RESET_VAL);
>
> - pm_runtime_put(dev);
> + pm_runtime_put_sync(dev);
>
> return 0;
> }
>
> ---
> base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
> change-id: 20260609-lvds-phy-6328389a2cf1
>
> Best regards,
> --
> Felix Gu <ustc.gu@gmail.com>
>
>
^ permalink raw reply
* Re: [PATCH v2 1/2] PCI: imx6: Configure REF_USE_PAD before PHY reset for i.MX95
From: Manivannan Sadhasivam @ 2026-06-09 15:47 UTC (permalink / raw)
To: Richard Zhu
Cc: frank.li, l.stach, lpieralisi, kwilczynski, robh, bhelgaas,
s.hauer, kernel, festevam, linux-pci, linux-arm-kernel, imx,
linux-kernel, stable
In-Reply-To: <20260518072715.3166514-2-hongxing.zhu@nxp.com>
On Mon, May 18, 2026 at 03:27:14PM +0800, Richard Zhu wrote:
> According to the i.MX95 PCIe PHY Databook, the ref_use_pad signal in the
> Common Block Signals section selects the reference clock source connected
> to the PHY pads. Per the specification, any change to this input must be
> followed by a PHY reset assertion to take effect.
>
> Move the REF_USE_PAD configuration before the PHY reset toggle to comply
> with the required initialization sequence.
>
> Fixes: 47f54a902dcd ("PCI: imx6: Toggle the core reset for i.MX95 PCIe")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 27 ++++++++++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 002e0a0d9382..66e760015c92 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -138,6 +138,7 @@ struct imx_pcie_drvdata {
> const u32 mode_off[IMX_PCIE_MAX_INSTANCES];
> const u32 mode_mask[IMX_PCIE_MAX_INSTANCES];
> const struct pci_epc_features *epc_features;
> + int (*init_pre_reset)(struct imx_pcie *pcie);
I renamed the callback and helper while applying:
s/init_pre_reset/select_ref_clk_src
- Mani
> int (*init_phy)(struct imx_pcie *pcie);
> int (*enable_ref_clk)(struct imx_pcie *pcie, bool enable);
> int (*core_reset)(struct imx_pcie *pcie, bool assert);
> @@ -249,6 +250,24 @@ static unsigned int imx_pcie_grp_offset(const struct imx_pcie *imx_pcie)
> return imx_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
> }
>
> +static int imx95_pcie_init_pre_reset(struct imx_pcie *imx_pcie)
> +{
> + bool ext = imx_pcie->enable_ext_refclk;
> +
> + /*
> + * Regarding the Signal Descriptions of i.MX95 PCIe PHY, ref_use_pad is
> + * used to select reference clock connected to a pair of pads.
> + *
> + * Any change in this input must be followed by phy_reset assertion.
> + */
> +
> + regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_PHY_GEN_CTRL,
> + IMX95_PCIE_REF_USE_PAD,
> + ext ? IMX95_PCIE_REF_USE_PAD : 0);
> +
> + return 0;
> +}
> +
> static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
> {
> bool ext = imx_pcie->enable_ext_refclk;
> @@ -271,9 +290,6 @@ static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
> IMX95_PCIE_PHY_CR_PARA_SEL,
> IMX95_PCIE_PHY_CR_PARA_SEL);
>
> - regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_PHY_GEN_CTRL,
> - IMX95_PCIE_REF_USE_PAD,
> - ext ? IMX95_PCIE_REF_USE_PAD : 0);
> regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_0,
> IMX95_PCIE_REF_CLKEN,
> ext ? 0 : IMX95_PCIE_REF_CLKEN);
> @@ -1348,6 +1364,9 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> pp->bridge->disable_device = imx_pcie_disable_device;
> }
>
> + if (imx_pcie->drvdata->init_pre_reset)
> + imx_pcie->drvdata->init_pre_reset(imx_pcie);
> +
> imx_pcie_assert_core_reset(imx_pcie);
>
> if (imx_pcie->drvdata->init_phy)
> @@ -2047,6 +2066,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
> .mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
> .core_reset = imx95_pcie_core_reset,
> .init_phy = imx95_pcie_init_phy,
> + .init_pre_reset = imx95_pcie_init_pre_reset,
> .wait_pll_lock = imx95_pcie_wait_for_phy_pll_lock,
> .enable_ref_clk = imx95_pcie_enable_ref_clk,
> .clr_clkreq_override = imx95_pcie_clr_clkreq_override,
> @@ -2102,6 +2122,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
> .ltssm_mask = IMX95_PCIE_LTSSM_EN,
> .mode_off[0] = IMX95_PE0_GEN_CTRL_1,
> .mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
> + .init_pre_reset = imx95_pcie_init_pre_reset,
> .init_phy = imx95_pcie_init_phy,
> .core_reset = imx95_pcie_core_reset,
> .wait_pll_lock = imx95_pcie_wait_for_phy_pll_lock,
>
> base-commit: 40b7f61a1a4d7fd18188f3f87e15ff5a90ce1d31
> --
> 2.37.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 0/2] PCI: imx6: Fix i.MX95 PCIe PHY initialization sequence
From: Manivannan Sadhasivam @ 2026-06-09 15:46 UTC (permalink / raw)
To: frank.li, l.stach, lpieralisi, kwilczynski, robh, bhelgaas,
s.hauer, kernel, festevam, Richard Zhu
Cc: linux-pci, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20260518072715.3166514-1-hongxing.zhu@nxp.com>
On Mon, 18 May 2026 15:27:13 +0800, Richard Zhu wrote:
> This series addresses PHY initialization sequence issues for i.MX95 PCIe
> that were identified through careful review of the i.MX95 PCIe PHY Databook.
>
> The current implementation does not strictly follow the timing requirements
> specified in the PHY documentation for reference clock configuration and
> PHY reset sequencing. These violations can potentially lead to unreliable
> PHY initialization.
>
> [...]
Applied, thanks!
[1/2] PCI: imx6: Configure REF_USE_PAD before PHY reset for i.MX95
commit: 0c26b1c34d12d4debfb5363cc0be6cdf68e87ba2
[2/2] PCI: imx6: Assert ref_clk_en after reference clock stabilizes on i.MX95
commit: 9dda3f83ba677b9cc2613cecd9120123000ae50f
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCHv2] dmaengine: st_fdma: simplify allocation
From: Frank Li @ 2026-06-09 15:42 UTC (permalink / raw)
To: Rosen Penev
Cc: dmaengine, Patrice Chotard, Vinod Koul, Frank Li, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/STI ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be|_ptr)?b
In-Reply-To: <CAKxU2N9cTuhj4WAu98+6m3qb4Yy5NwZQHcnKUa4ra86+M-S-cg@mail.gmail.com>
On Mon, Jun 08, 2026 at 01:52:09PM -0700, Rosen Penev wrote:
> On Mon, Jun 8, 2026 at 9:25 AM Frank Li <Frank.li@oss.nxp.com> wrote:
> >
> > On Sun, Jun 07, 2026 at 10:18:29PM -0700, Rosen Penev wrote:
> >
> > Nit: dmaengine: st_fdma: simplify allocation by using flexible array
> that's in the description. Did it that was to not have it as long,
>
> flexible array member is the proper terminology.
subject should provide most important information and summary what you did.
prefer pattern is
do what for ...
It is too general (simplify allocation\fix wraning\....)
Frank
> >
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> >
> > > Use a flexible array member to combine kzalloc and kcalloc to a single
> > > allocation.
> > >
> > > Add __counted_by for extra runtime analysis. Assign counting variable
> > > after allocation before any array accesses.
> > >
> > > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > > ---
> > >
^ permalink raw reply
* [PATCH v2 2/7] clk: qcom: Restrict A7PLL and IPQ4019 GCC to ARM
From: Krzysztof Kozlowski @ 2026-06-09 15:32 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260609-clk-qcom-defaults-v2-0-0c67c06dca11@oss.qualcomm.com>
IPQ4019 is ARM 32-bit only SoC and QCOM_A7PLL is used only on SDX55 and
SDX65, which are 32-bit as well.
Do not allow building them for ARM64 to make built kernels smaller and
user choices easier.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
1. New patch
---
drivers/clk/qcom/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 799de35c5ee8..3b8768d80d89 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -228,6 +228,7 @@ config QCOM_A53PLL
config QCOM_A7PLL
tristate "A7 PLL driver for SDX55 and SDX65"
+ depends on ARM || COMPILE_TEST
help
Support for the A7 PLL on SDX55 and SDX65 devices. It provides the CPU with
frequencies above 1GHz.
@@ -374,6 +375,7 @@ config IPQ_CMN_PLL
config IPQ_GCC_4019
tristate "IPQ4019 Global Clock Controller"
+ depends on ARM || COMPILE_TEST
help
Support for the global clock controller on ipq4019 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: power: imx93: Add MIPI PHY power domain
From: Krzysztof Kozlowski @ 2026-06-09 15:13 UTC (permalink / raw)
To: Guoniu Zhou, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ulf Hansson, Peng Fan, Shawn Guo
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux-pm
In-Reply-To: <20260609-pm_imx93-v1-1-d06c004b0f51@oss.nxp.com>
On 09/06/2026 08:26, Guoniu Zhou wrote:
> Add MIPI PHY power domain for shared PHY resources used by both
> MIPI DSI and CSI blocks.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> include/dt-bindings/power/fsl,imx93-power.h | 1 +
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] arm64: dts: rockchip: Fix devices suspend freeze on RK3568/RK3566
From: Jonas Karlman @ 2026-06-09 15:41 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Geis, Michael Riesch
Cc: Diederik de Haas, Greg Kroah-Hartman, devicetree, linux-rockchip,
linux-usb, linux-arm-kernel, linux-kernel, Jonas Karlman
In-Reply-To: <20260609154124.445182-1-jonas@kwiboo.se>
The EHCI/OHCI controller depends on clk_usbphy1_480m being enabled, or
the system may freeze when registers are accessed, i.e. during suspend
in ohci_suspend().
Add the missing clk_usbphy1_480m clocks reference to EHCI/OHCI
controllers to ensure the clock is enabled when ECHI/OHCI registers are
accessed to prevent a system freeze.
Fixes suspend pm_test issue with EHCI/OHCI devices due to the missing
clk_usbphy1_480m reference and makes following pm_test modes work:
echo N > /sys/module/printk/parameters/console_suspend
echo devices > /sys/power/pm_test
echo platform > /sys/power/pm_test
echo processors > /sys/power/pm_test
echo core > /sys/power/pm_test
echo mem > /sys/power/state
Fixes: 91c4c3e06a25 ("arm64: dts: rockchip: add usb2 nodes to rk3568 device tree")
Fixes: 78f7186095db ("arm64: dts: rockchip: rename and sort the rk356x usb2 phy handles")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
---
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
index a5832895bd39..c930a6fd6ea0 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
@@ -321,44 +321,44 @@ its: msi-controller@fd440000 {
};
usb_host0_ehci: usb@fd800000 {
- compatible = "generic-ehci";
+ compatible = "rockchip,rk3568-ehci", "generic-ehci";
reg = <0x0 0xfd800000 0x0 0x40000>;
interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru HCLK_USB2HOST0>, <&cru HCLK_USB2HOST0_ARB>,
- <&cru PCLK_USB>;
+ <&cru PCLK_USB>, <&usb2phy1>;
phys = <&usb2phy1_otg>;
phy-names = "usb";
status = "disabled";
};
usb_host0_ohci: usb@fd840000 {
- compatible = "generic-ohci";
+ compatible = "rockchip,rk3568-ohci", "generic-ohci";
reg = <0x0 0xfd840000 0x0 0x40000>;
interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru HCLK_USB2HOST0>, <&cru HCLK_USB2HOST0_ARB>,
- <&cru PCLK_USB>;
+ <&cru PCLK_USB>, <&usb2phy1>;
phys = <&usb2phy1_otg>;
phy-names = "usb";
status = "disabled";
};
usb_host1_ehci: usb@fd880000 {
- compatible = "generic-ehci";
+ compatible = "rockchip,rk3568-ehci", "generic-ehci";
reg = <0x0 0xfd880000 0x0 0x40000>;
interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru HCLK_USB2HOST1>, <&cru HCLK_USB2HOST1_ARB>,
- <&cru PCLK_USB>;
+ <&cru PCLK_USB>, <&usb2phy1>;
phys = <&usb2phy1_host>;
phy-names = "usb";
status = "disabled";
};
usb_host1_ohci: usb@fd8c0000 {
- compatible = "generic-ohci";
+ compatible = "rockchip,rk3568-ohci", "generic-ohci";
reg = <0x0 0xfd8c0000 0x0 0x40000>;
interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru HCLK_USB2HOST1>, <&cru HCLK_USB2HOST1_ARB>,
- <&cru PCLK_USB>;
+ <&cru PCLK_USB>, <&usb2phy1>;
phys = <&usb2phy1_host>;
phy-names = "usb";
status = "disabled";
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Jonas Karlman @ 2026-06-09 15:41 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman
Cc: Diederik de Haas, devicetree, linux-rockchip, linux-usb,
linux-arm-kernel, linux-kernel, Jonas Karlman
In-Reply-To: <20260609154124.445182-1-jonas@kwiboo.se>
The Rockchip RK3568 EHCI/OHCI controller depends on clk_usbphy1_480m
being enabled, or the system may freeze when registers are accessed.
Add Rockchip RK3568 EHCI and OHCI compatibles with a similar four-clock
constraint as RK3588.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
---
Existing DTs for RK3568 use the plain generic-ehci/ohci compatible,
next patch make use of these new compatibles and adds the missing
clk_usbphy1_480m clock references.
---
.../devicetree/bindings/usb/generic-ehci.yaml | 10 ++++++++++
.../devicetree/bindings/usb/generic-ohci.yaml | 5 ++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
index 55a5aa7d7a54..c49a1bbc8cfd 100644
--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -52,6 +52,7 @@ properties:
- ibm,476gtr-ehci
- nxp,lpc1850-ehci
- qca,ar7100-ehci
+ - rockchip,rk3568-ehci
- rockchip,rk3588-ehci
- snps,hsdk-v1.0-ehci
- socionext,uniphier-ehci
@@ -186,6 +187,15 @@ allOf:
required:
- clocks
- clock-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3568-ehci
+ then:
+ properties:
+ clocks:
+ minItems: 4
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
index d42f448fa204..5f1b4d2bff89 100644
--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -47,6 +47,7 @@ properties:
- hpe,gxp-ohci
- ibm,476gtr-ohci
- ingenic,jz4740-ohci
+ - rockchip,rk3568-ohci
- rockchip,rk3588-ohci
- snps,hsdk-v1.0-ohci
- const: generic-ohci
@@ -198,7 +199,9 @@ allOf:
properties:
compatible:
contains:
- const: rockchip,rk3588-ohci
+ enum:
+ - rockchip,rk3568-ohci
+ - rockchip,rk3588-ohci
then:
properties:
clocks:
--
2.54.0
^ permalink raw reply related
* [PATCH 0/2] rockchip: Fix devices suspend freeze on RK3568/RK3566
From: Jonas Karlman @ 2026-06-09 15:41 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Diederik de Haas, Greg Kroah-Hartman, devicetree, linux-rockchip,
linux-usb, linux-arm-kernel, linux-kernel, Jonas Karlman
This series fixes a system freeze during suspend in ohci_suspend() due
to clk_usbphy1_480m not being enabled when EHCI/OHCI registers are
accessed on e.g. a Raxa ROCK 3C board.
Following pm_test modes work on my ROCK 3C with the missing usbphy clk
refs added:
echo N > /sys/module/printk/parameters/console_suspend
echo devices > /sys/power/pm_test
echo platform > /sys/power/pm_test
echo processors > /sys/power/pm_test
echo core > /sys/power/pm_test
echo mem > /sys/power/state
Jonas Karlman (2):
dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
arm64: dts: rockchip: Fix devices suspend freeze on RK3568/RK3566
.../devicetree/bindings/usb/generic-ehci.yaml | 10 ++++++++++
.../devicetree/bindings/usb/generic-ohci.yaml | 5 ++++-
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 16 ++++++++--------
3 files changed, 22 insertions(+), 9 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH] firmware: imx: sm-misc: Add NULL check for kmalloc in syslog_show
From: Frank Li @ 2026-06-09 15:38 UTC (permalink / raw)
To: Li Jun
Cc: Frank.Li, s.hauer, imx, linux-kernel, kernel, festevam, peng.fan,
shawnguo, krzysztof.kozlowski, linux-arm-kernel
In-Reply-To: <20260609004504.3402281-1-lijun01@kylinos.cn>
On Tue, Jun 09, 2026 at 08:45:04AM +0800, Li Jun wrote:
>
> Add a proper NULL check for the kmalloc() return value in syslog_show().
> If memory allocation fails, syslog would be NULL and passing it to
> misc_syslog() could lead to a NULL pointer dereference.
>
> Signed-off-by: Li Jun <lijun01@kylinos.cn>
> ---
Add a fix tags
Frank
> drivers/firmware/imx/sm-misc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/firmware/imx/sm-misc.c b/drivers/firmware/imx/sm-misc.c
> index ac9af824c2d4..fb8d7bdb5b08 100644
> --- a/drivers/firmware/imx/sm-misc.c
> +++ b/drivers/firmware/imx/sm-misc.c
> @@ -79,6 +79,9 @@ static int syslog_show(struct seq_file *file, void *priv)
> u16 size = SZ_4K / 4;
> int ret;
>
> + if (!syslog)
> + return -ENOMEM;
> +
> if (!ph)
> return -ENODEV;
>
> --
> 2.25.1
>
>
^ permalink raw reply
* Re: [PATCH v4 1/2] i2c: imx-lpi2c: properly unwind resources on probe failure
From: Frank Li @ 2026-06-09 15:35 UTC (permalink / raw)
To: carlos.song
Cc: aisheng.dong, andi.shyti, Frank.Li, s.hauer, kernel, festevam,
linux-i2c, imx, linux-arm-kernel, linux-kernel, Carlos Song
In-Reply-To: <20260609095119.924029-2-carlos.song@oss.nxp.com>
On Tue, Jun 09, 2026 at 05:51:18PM +0800, carlos.song@oss.nxp.com wrote:
> [You don't often get email from carlos.song@oss.nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> From: Carlos Song <carlos.song@nxp.com>
>
> When probe fails after clk_bulk_prepare_enable() succeeds but before
> runtime PM is initialized, the enabled clocks are never disabled.
> Additionally, calling pm_runtime_put_sync() in the error path can
> trigger the runtime suspend callback, which may attempt to disable
> clocks that have not been fully set up, leading to potential issues
> during error unwinding.
>
> Introduce two new error labels: clk_disable to explicitly invoke
> clk_bulk_disable_unprepare(), and free_irq to release the IRQ via
> devm_free_irq(). Replace pm_runtime_put_sync() with the sequence of
> pm_runtime_disable(), pm_runtime_set_suspended() and
> pm_runtime_put_noidle() to bypass the runtime suspend callback during
> error recovery. Update all goto targets so that each failure site
> releases only the resources acquired up to that point.
>
> Signed-off-by: Carlos Song <carlos.song@nxp.com>
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 25 +++++++++++++++++--------
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index cd4da50c4dd9..fbb9c0b0a99c 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -1520,21 +1520,25 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
>
> ret = clk_bulk_prepare_enable(lpi2c_imx->num_clks, lpi2c_imx->clks);
> if (ret)
> - return ret;
> + goto free_irq;
If you use runtime pm, you should not manually manange clock again.
generally method is
devm_clk_get()
devm_runtime_pm_enable()
call runtime_pm_get_sync(), \\there are PM AQUIRE help macro to help
elimiate goto branch.
... // if need clock enable to do some works.
call runtime_pm_put()
...
and needn't call devm_free_irq().
Frank
>
> /*
> * Lock the parent clock rate to avoid getting parent clock upon
> * each transfer
> */
> ret = devm_clk_rate_exclusive_get(&pdev->dev, lpi2c_imx->clks[0].clk);
> - if (ret)
> - return dev_err_probe(&pdev->dev, ret,
> - "can't lock I2C peripheral clock rate\n");
> + if (ret) {
> + dev_err_probe(&pdev->dev, ret,
> + "can't lock I2C peripheral clock rate\n");
> + goto clk_disable;
> + }
>
> lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk);
> - if (!lpi2c_imx->rate_per)
> - return dev_err_probe(&pdev->dev, -EINVAL,
> - "can't get I2C peripheral clock rate\n");
> + if (!lpi2c_imx->rate_per) {
> + ret = dev_err_probe(&pdev->dev, -EINVAL,
> + "can't get I2C peripheral clock rate\n");
> + goto clk_disable;
> + }
>
> if (lpi2c_imx->hwdata->need_prepare_unprepare_clk)
> pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_LONG_TIMEOUT_MS);
> @@ -1576,8 +1580,13 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
>
> rpm_disable:
> pm_runtime_dont_use_autosuspend(&pdev->dev);
> - pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> + pm_runtime_set_suspended(&pdev->dev);
> + pm_runtime_put_noidle(&pdev->dev);
> +clk_disable:
> + clk_bulk_disable_unprepare(lpi2c_imx->num_clks, lpi2c_imx->clks);
> +free_irq:
> + devm_free_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx);
>
> return ret;
> }
> --
> 2.43.0
>
>
^ permalink raw reply
* [PATCH v2 6/7] ARM/arm64: defconfig: Drop redundant Qualcomm clock entries
From: Krzysztof Kozlowski @ 2026-06-09 15:32 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260609-clk-qcom-defaults-v2-0-0c67c06dca11@oss.qualcomm.com>
Drop all drivers from defconfig which have defaults in Kconfig. Drop
also MDM_LCC_9615 which is gone since commit bac4675a4d1b ("clk: qcom:
drop lcc-mdm9615 in favour of lcc-msm8960").
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Depends on clock patches - this can wait a cycle.
Changes in v2:
1. New patch (split from previous)
---
arch/arm/configs/multi_v7_defconfig | 9 ---
arch/arm/configs/qcom_defconfig | 14 -----
arch/arm64/configs/defconfig | 112 ------------------------------------
3 files changed, 135 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 2891eeba9032..e075da05c7e0 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1095,15 +1095,6 @@ CONFIG_COMMON_CLK_S2MPS11=m
CONFIG_CLK_TWL=m
CONFIG_CLK_RASPBERRYPI=y
CONFIG_COMMON_CLK_QCOM=y
-CONFIG_QCOM_A53PLL=y
-CONFIG_QCOM_CLK_APCS_MSM8916=y
-CONFIG_QCOM_CLK_RPM=y
-CONFIG_QCOM_CLK_SMD_RPM=y
-CONFIG_APQ_MMCC_8084=y
-CONFIG_MSM_GCC_8660=y
-CONFIG_MSM_GCC_8916=y
-CONFIG_MSM_MMCC_8960=y
-CONFIG_MSM_MMCC_8974=y
CONFIG_HWSPINLOCK=y
CONFIG_HWSPINLOCK_OMAP=y
CONFIG_HWSPINLOCK_QCOM=y
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 03309b89ea4c..5316126fb41e 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -205,20 +205,6 @@ CONFIG_DMADEVICES=y
CONFIG_QCOM_BAM_DMA=y
CONFIG_STAGING=y
CONFIG_COMMON_CLK_QCOM=y
-CONFIG_QCOM_A7PLL=y
-CONFIG_QCOM_CLK_APCS_SDX55=y
-CONFIG_QCOM_CLK_RPM=y
-CONFIG_QCOM_CLK_SMD_RPM=y
-CONFIG_QCOM_CLK_RPMH=y
-CONFIG_APQ_MMCC_8084=y
-CONFIG_IPQ_GCC_4019=y
-CONFIG_IPQ_LCC_806X=y
-CONFIG_MSM_GCC_8660=y
-CONFIG_MSM_LCC_8960=y
-CONFIG_MDM_LCC_9615=y
-CONFIG_MSM_MMCC_8960=y
-CONFIG_MSM_MMCC_8974=y
-CONFIG_SDX_GCC_55=y
CONFIG_HWSPINLOCK=y
CONFIG_HWSPINLOCK_QCOM=y
CONFIG_MAILBOX=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index cb753cc0f5a4..91c8e9435dd6 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1458,126 +1458,14 @@ CONFIG_COMMON_CLK_MT8192_SCP_ADSP=y
CONFIG_COMMON_CLK_MT8192_VDECSYS=y
CONFIG_COMMON_CLK_MT8192_VENCSYS=y
CONFIG_COMMON_CLK_QCOM=y
-CONFIG_CLK_ELIZA_DISPCC=m
-CONFIG_CLK_ELIZA_GCC=y
-CONFIG_CLK_ELIZA_TCSRCC=m
-CONFIG_CLK_GLYMUR_DISPCC=m
-CONFIG_CLK_GLYMUR_GCC=y
-CONFIG_CLK_GLYMUR_TCSRCC=m
-CONFIG_CLK_KAANAPALI_CAMCC=m
-CONFIG_CLK_KAANAPALI_DISPCC=m
-CONFIG_CLK_KAANAPALI_GCC=y
-CONFIG_CLK_KAANAPALI_GPUCC=m
-CONFIG_CLK_KAANAPALI_TCSRCC=m
-CONFIG_CLK_KAANAPALI_VIDEOCC=m
-CONFIG_CLK_X1E80100_CAMCC=m
-CONFIG_CLK_X1E80100_DISPCC=m
-CONFIG_CLK_X1E80100_GCC=y
-CONFIG_CLK_X1E80100_GPUCC=m
-CONFIG_CLK_X1E80100_TCSRCC=y
-CONFIG_CLK_X1P42100_GPUCC=m
-CONFIG_CLK_QCM2290_GPUCC=m
-CONFIG_QCOM_A53PLL=y
-CONFIG_QCOM_CLK_APCS_MSM8916=y
-CONFIG_QCOM_CLK_APCC_MSM8996=y
-CONFIG_QCOM_CLK_SMD_RPM=y
-CONFIG_QCOM_CLK_RPMH=y
-CONFIG_IPQ_APSS_6018=y
-CONFIG_IPQ_CMN_PLL=m
-CONFIG_IPQ_GCC_5018=y
-CONFIG_IPQ_GCC_5210=y
-CONFIG_IPQ_GCC_5332=y
-CONFIG_IPQ_GCC_5424=y
-CONFIG_IPQ_GCC_6018=y
-CONFIG_IPQ_GCC_8074=y
-CONFIG_IPQ_GCC_9574=y
-CONFIG_IPQ_NSSCC_5424=m
-CONFIG_IPQ_NSSCC_9574=m
-CONFIG_MSM_GCC_8916=y
-CONFIG_MSM_GCC_8953=y
-CONFIG_MSM_MMCC_8994=m
-CONFIG_MSM_GCC_8994=y
-CONFIG_MSM_GCC_8996=y
-CONFIG_MSM_MMCC_8996=m
-CONFIG_MSM_GCC_8998=y
-CONFIG_MSM_MMCC_8998=m
-CONFIG_QCM_GCC_2290=y
-CONFIG_QCM_DISPCC_2290=m
-CONFIG_QCS_DISPCC_615=m
-CONFIG_QCS_CAMCC_615=m
-CONFIG_QCS_GCC_404=y
-CONFIG_SA_CAMCC_8775P=m
-CONFIG_QCS_GCC_8300=y
-CONFIG_QCS_GCC_615=y
-CONFIG_QCS_GPUCC_615=m
-CONFIG_QCS_VIDEOCC_615=m
-CONFIG_SC_CAMCC_7280=m
-CONFIG_SC_CAMCC_8280XP=m
-CONFIG_SA_DISPCC_8775P=m
-CONFIG_SC_DISPCC_7280=m
-CONFIG_SC_DISPCC_8280XP=m
-CONFIG_SA_GCC_8775P=y
-CONFIG_SA_GPUCC_8775P=m
-CONFIG_SC_GCC_7180=y
-CONFIG_SC_GCC_7280=y
-CONFIG_SC_GCC_8180X=y
-CONFIG_SC_GCC_8280XP=y
-CONFIG_SC_GPUCC_7280=m
-CONFIG_SC_GPUCC_8280XP=m
-CONFIG_SC_LPASSCC_8280XP=m
-CONFIG_SC_LPASS_CORECC_7280=m
-CONFIG_SC_VIDEOCC_7280=m
-CONFIG_SDM_CAMCC_845=m
-CONFIG_QDU_GCC_1000=y
CONFIG_SDM_GPUCC_845=y
CONFIG_SDM_VIDEOCC_845=y
CONFIG_SDM_DISPCC_845=y
-CONFIG_SDM_LPASSCC_845=m
-CONFIG_SDX_GCC_75=y
-CONFIG_SM_CAMCC_6350=m
-CONFIG_SM_CAMCC_MILOS=m
-CONFIG_SM_CAMCC_8250=m
-CONFIG_SM_CAMCC_8550=m
-CONFIG_SM_CAMCC_8650=m
-CONFIG_SM_CAMCC_8750=m
-CONFIG_SM_DISPCC_6115=m
CONFIG_SM_DISPCC_8250=y
-CONFIG_SM_DISPCC_6350=m
-CONFIG_SM_DISPCC_MILOS=m
-CONFIG_SM_DISPCC_8450=m
-CONFIG_SM_DISPCC_8550=m
-CONFIG_SM_DISPCC_8750=m
-CONFIG_SM_GCC_4450=y
-CONFIG_SM_GCC_6115=y
-CONFIG_SM_GCC_6350=y
-CONFIG_SM_GCC_MILOS=y
-CONFIG_SM_GCC_8350=y
-CONFIG_SM_GCC_8450=y
-CONFIG_SM_GCC_8550=y
-CONFIG_SM_GCC_8650=y
-CONFIG_SM_GCC_8750=y
-CONFIG_SM_GPUCC_6115=m
-CONFIG_SM_GPUCC_6350=m
-CONFIG_SM_GPUCC_MILOS=m
CONFIG_SM_GPUCC_8150=y
CONFIG_SM_GPUCC_8250=y
-CONFIG_SM_GPUCC_8350=m
-CONFIG_SM_GPUCC_8450=m
-CONFIG_SM_GPUCC_8550=m
-CONFIG_SM_GPUCC_8650=m
-CONFIG_SM_GPUCC_8750=m
-CONFIG_SM_TCSRCC_8550=y
-CONFIG_SM_TCSRCC_8650=y
-CONFIG_SM_TCSRCC_8750=m
-CONFIG_SA_VIDEOCC_8775P=m
-CONFIG_SM_VIDEOCC_6350=m
-CONFIG_SM_VIDEOCC_MILOS=m
CONFIG_SM_VIDEOCC_8250=y
-CONFIG_SM_VIDEOCC_8550=m
-CONFIG_SM_VIDEOCC_8750=m
CONFIG_QCOM_HFPLL=y
-CONFIG_CLK_GFM_LPASS_SM8250=m
-CONFIG_SM_VIDEOCC_8450=m
CONFIG_CLK_RCAR_USB2_CLOCK_SEL=y
CONFIG_CLK_RENESAS_VBATTB=m
CONFIG_EXYNOS_ACPM_CLK=m
--
2.53.0
^ permalink raw reply related
* [PATCH v2 3/7] clk: qcom: Make important ARM64 drivers default
From: Krzysztof Kozlowski @ 2026-06-09 15:32 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260609-clk-qcom-defaults-v2-0-0c67c06dca11@oss.qualcomm.com>
Clock controller drivers are essential for booting up SoCs and are not
really optional for a given platform. Kernel 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 Qualcomm clock controller drivers which are chosen in
defconfig to respective default 'yes' or 'module'.
This has no impact on ARM64 defconfig include/generated/autoconf.h,
however changes few drivers for ARM 32-bit:
1. multi_v7_defconfig: Enable QCOM_CLK_RPMH as module, because SDX55
(ARM 32-bit) uses it.
2. qcom_defconfig: Enable QCOM_A53PLL, QCOM_CLK_APCS_MSM8916 and
MSM_GCC_8916 as built-in, because MSM8916 is also used ARM 32-bit.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
1. Add defaults for msm8994-8996-8998.
2. Move defconfig change to separate commit.
3. Drop Rb tag becauase of above.
---
drivers/clk/qcom/Kconfig | 122 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 122 insertions(+)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 3b8768d80d89..d8281ed68dc5 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -23,6 +23,7 @@ config CLK_ELIZA_DISPCC
tristate "Eliza Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_ELIZA_GCC
+ default m if ARCH_QCOM
help
Support for the display clock controllers on Eliza SoCs.
Say Y if you want to support display devices and functionality such as
@@ -32,6 +33,7 @@ config CLK_ELIZA_GCC
tristate "Eliza Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on Eliza devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -41,6 +43,7 @@ config CLK_ELIZA_TCSRCC
tristate "Eliza TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the TCSR clock controller on Eliza devices.
Say Y if you want to use peripheral devices such as USB/PCIe/UFS.
@@ -49,6 +52,7 @@ config CLK_GLYMUR_DISPCC
tristate "Glymur Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_GLYMUR_GCC
+ default m if ARCH_QCOM
help
Support for the display clock controllers on Qualcomm
Technologies, Inc. Glymur devices.
@@ -59,6 +63,7 @@ config CLK_GLYMUR_GCC
tristate "Glymur Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on Glymur devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -77,6 +82,7 @@ config CLK_GLYMUR_TCSRCC
tristate "Glymur TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the TCSR clock controller on Glymur devices.
Say Y if you want to use peripheral devices such as USB/PCIe/EDP.
@@ -94,6 +100,7 @@ config CLK_KAANAPALI_CAMCC
tristate "Kaanapali Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_KAANAPALI_GCC
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
Kaanapali devices.
@@ -104,6 +111,7 @@ config CLK_KAANAPALI_DISPCC
tristate "Kaanapali Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_KAANAPALI_GCC
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
Kaanapali devices.
@@ -114,6 +122,7 @@ config CLK_KAANAPALI_GCC
tristate "Kaanapali Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on Kaanapali devices.
Say Y if you want to use peripheral devices such as UART,
@@ -123,6 +132,7 @@ config CLK_KAANAPALI_GPUCC
tristate "Kaanapali Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_KAANAPALI_GCC
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on Kaanapali devices.
Say Y if you want to support graphics controller devices and
@@ -132,6 +142,7 @@ config CLK_KAANAPALI_TCSRCC
tristate "Kaanapali TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the TCSR clock controller on Kaanapali devices.
Say Y if you want to use peripheral devices such as PCIe, USB, UFS.
@@ -140,6 +151,7 @@ config CLK_KAANAPALI_VIDEOCC
tristate "Kaanapali Video Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_KAANAPALI_GCC
+ default m if ARCH_QCOM
help
Support for the video clock controller on Kaanapali devices.
Say Y if you want to support video devices and functionality such as
@@ -159,6 +171,7 @@ config CLK_X1E80100_CAMCC
tristate "X1E80100 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_X1E80100_GCC
+ default m if ARCH_QCOM
help
Support for the camera clock controller on X1E80100 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -167,6 +180,7 @@ config CLK_X1E80100_DISPCC
tristate "X1E80100 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_X1E80100_GCC
+ default m if ARCH_QCOM
help
Support for the two display clock controllers on Qualcomm
Technologies, Inc. X1E80100 devices.
@@ -177,6 +191,7 @@ config CLK_X1E80100_GCC
tristate "X1E80100 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on Qualcomm Technologies, Inc
X1E80100 devices.
@@ -187,6 +202,7 @@ config CLK_X1E80100_GPUCC
tristate "X1E80100 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_X1E80100_GCC
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on X1E80100 devices.
Say Y if you want to support graphics controller devices and
@@ -196,6 +212,7 @@ config CLK_X1E80100_TCSRCC
tristate "X1E80100 TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the TCSR clock controller on X1E80100 devices.
Say Y if you want to use peripheral devices such as SD/UFS.
@@ -204,6 +221,7 @@ config CLK_X1P42100_GPUCC
tristate "X1P42100 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_X1E80100_GCC
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on X1P42100 devices.
Say Y if you want to support graphics controller devices and
@@ -213,6 +231,7 @@ config CLK_QCM2290_GPUCC
tristate "QCM2290 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCM_GCC_2290
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on QCM2290 devices.
Say Y if you want to support graphics controller devices and
@@ -220,6 +239,7 @@ config CLK_QCM2290_GPUCC
config QCOM_A53PLL
tristate "MSM8916 A53 PLL"
+ default ARCH_QCOM
help
Support for the A53 PLL on MSM8916 devices. It provides
the CPU with frequencies above 1GHz.
@@ -238,6 +258,7 @@ config QCOM_A7PLL
config QCOM_CLK_APCS_MSM8916
tristate "MSM8916 APCS Clock Controller"
depends on QCOM_APCS_IPC || COMPILE_TEST
+ default ARCH_QCOM
help
Support for the APCS Clock Controller on msm8916 devices. The
APCS is managing the mux and divider which feeds the CPUs.
@@ -249,6 +270,7 @@ config QCOM_CLK_APCC_MSM8996
select QCOM_KRYO_L2_ACCESSORS
select INTERCONNECT_CLK if INTERCONNECT
depends on ARM64
+ default ARCH_QCOM
help
Support for the CPU clock controller on msm8996 devices.
Say Y if you want to support CPU clock scaling using CPUfreq
@@ -279,6 +301,7 @@ config QCOM_CLK_RPM
config QCOM_CLK_SMD_RPM
tristate "RPM over SMD based Clock Controller"
depends on QCOM_SMD_RPM
+ default ARCH_QCOM
help
The RPM (Resource Power Manager) is a dedicated hardware engine for
managing the shared SoC resources in order to keep the lowest power
@@ -291,6 +314,7 @@ config QCOM_CLK_SMD_RPM
config QCOM_CLK_RPMH
tristate "RPMh Clock Driver"
depends on QCOM_RPMH
+ default ARCH_QCOM
help
RPMh manages shared resources on some Qualcomm Technologies, Inc.
SoCs. It accepts requests from other hardware subsystems via RSC.
@@ -356,6 +380,7 @@ config IPQ_APSS_6018
depends on ARM64 || COMPILE_TEST
depends on QCOM_APCS_IPC || COMPILE_TEST
depends on QCOM_SMEM
+ default ARCH_QCOM
help
Support for APSS clock controller on IPQ platforms. The
APSS clock controller manages the Mux and enable block that feeds the
@@ -366,6 +391,7 @@ config IPQ_APSS_6018
config IPQ_CMN_PLL
tristate "IPQ CMN PLL Clock Controller"
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for CMN PLL clock controller on IPQ platform. The
CMN PLL consumes the AHB/SYS clocks from GCC and supplies
@@ -384,6 +410,7 @@ config IPQ_GCC_4019
config IPQ_GCC_5018
tristate "IPQ5018 Global Clock Controller"
depends on ARM || ARM64 || COMPILE_TEST
+ default ARCH_QCOM && ARM64
help
Support for global clock controller on ipq5018 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -392,6 +419,7 @@ config IPQ_GCC_5018
config IPQ_GCC_5210
tristate "IPQ5210 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
Support for the global clock controller on ipq5210 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -400,6 +428,7 @@ config IPQ_GCC_5210
config IPQ_GCC_5332
tristate "IPQ5332 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
Support for the global clock controller on ipq5332 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -408,6 +437,7 @@ config IPQ_GCC_5332
config IPQ_GCC_5424
tristate "IPQ5424 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
Support for the global clock controller on ipq5424 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -416,6 +446,7 @@ config IPQ_GCC_5424
config IPQ_GCC_6018
tristate "IPQ6018 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
Support for global clock controller on ipq6018 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -443,6 +474,7 @@ config IPQ_GCC_8074
tristate "IPQ8074 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for global clock controller on ipq8074 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -452,6 +484,7 @@ config IPQ_GCC_8074
config IPQ_GCC_9574
tristate "IPQ9574 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
Support for global clock controller on ipq9574 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -472,6 +505,7 @@ config IPQ_NSSCC_5424
tristate "IPQ5424 NSS Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on IPQ_GCC_5424
+ default m if ARCH_QCOM
help
Support for NSS clock controller on ipq5424 devices.
NSSCC receives the clock sources from GCC, CMN PLL and UNIPHY (PCS).
@@ -483,6 +517,7 @@ config IPQ_NSSCC_9574
tristate "IPQ9574 NSS Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on IPQ_GCC_9574
+ default m if ARCH_QCOM
help
Support for NSS clock controller on ipq9574 devices.
@@ -515,6 +550,7 @@ config MSM_GCC_8909
config MSM_GCC_8916
tristate "MSM8916 Global Clock Controller"
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on msm8916 devices.
Say Y if you want to use devices such as UART, SPI i2c, USB,
@@ -583,6 +619,7 @@ config MSM_MMCC_8960
config MSM_GCC_8953
tristate "MSM8953 Global Clock Controller"
select QCOM_GDSC
+ default ARCH_QCOM if ARM64
help
Support for the global clock controller on msm8953 devices.
Say Y if you want to use devices such as UART, SPI i2c, USB,
@@ -619,6 +656,7 @@ config MSM_MMCC_8994
tristate "MSM8994 Multimedia Clock Controller"
select MSM_GCC_8994
select QCOM_GDSC
+ default m if ARCH_QCOM && ARM64
help
Support for the multimedia clock controller on msm8994 devices.
Say Y if you want to support multimedia devices such as display,
@@ -626,6 +664,7 @@ config MSM_MMCC_8994
config MSM_GCC_8994
tristate "MSM8994 Global Clock Controller"
+ default ARCH_QCOM if ARM64
help
Support for the global clock controller on msm8994 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -634,6 +673,7 @@ config MSM_GCC_8994
config MSM_GCC_8996
tristate "MSM8996 Global Clock Controller"
select QCOM_GDSC
+ default ARCH_QCOM if ARM64
help
Support for the global clock controller on msm8996 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -643,6 +683,7 @@ config MSM_MMCC_8996
tristate "MSM8996 Multimedia Clock Controller"
select MSM_GCC_8996
select QCOM_GDSC
+ default m if ARCH_QCOM && ARM64
help
Support for the multimedia clock controller on msm8996 devices.
Say Y if you want to support multimedia devices such as display,
@@ -651,6 +692,7 @@ config MSM_MMCC_8996
config MSM_GCC_8998
tristate "MSM8998 Global Clock Controller"
select QCOM_GDSC
+ default ARCH_QCOM if ARM64
help
Support for the global clock controller on msm8998 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -669,6 +711,7 @@ config MSM_MMCC_8998
tristate "MSM8998 Multimedia Clock Controller"
select MSM_GCC_8998
select QCOM_GDSC
+ default m if ARCH_QCOM && ARM64
help
Support for the multimedia clock controller on msm8998 devices.
Say Y if you want to support multimedia devices such as display,
@@ -678,6 +721,7 @@ config QCM_GCC_2290
tristate "QCM2290 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on QCM2290 devices.
Say Y if you want to use multimedia devices or peripheral
@@ -687,6 +731,7 @@ config QCM_DISPCC_2290
tristate "QCM2290 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCM_GCC_2290
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
QCM2290 devices.
@@ -697,6 +742,7 @@ config QCS_DISPCC_615
tristate "QCS615 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCS_GCC_615
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
QCS615 devices.
@@ -707,6 +753,7 @@ config QCS_CAMCC_615
tristate "QCS615 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCS_GCC_615
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
QCS615 devices.
@@ -715,6 +762,7 @@ config QCS_CAMCC_615
config QCS_GCC_404
tristate "QCS404 Global Clock Controller"
+ default y if ARCH_QCOM && ARM64
help
Support for the global clock controller on QCS404 devices.
Say Y if you want to use multimedia devices or peripheral
@@ -731,6 +779,7 @@ config SA_CAMCC_8775P
tristate "SA8775P Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SA_GCC_8775P
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
SA8775P devices.
@@ -741,6 +790,7 @@ config QCS_GCC_8300
tristate "QCS8300 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on Qualcomm Technologies, Inc
QCS8300 devices.
@@ -751,6 +801,7 @@ config QCS_GCC_615
tristate "QCS615 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on QCS615 devices.
Say Y if you want to use multimedia devices or peripheral
@@ -760,6 +811,7 @@ config QCS_GPUCC_615
tristate "QCS615 Graphics clock controller"
depends on ARM64 || COMPILE_TEST
select QCS_GCC_615
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on QCS615 devices.
Say Y if you want to support graphics controller devices and
@@ -769,6 +821,7 @@ config QCS_VIDEOCC_615
tristate "QCS615 Video Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCS_GCC_615
+ default m if ARCH_QCOM
help
Support for the video clock controller on QCS615 devices.
Say Y if you want to support video devices and functionality such as
@@ -788,6 +841,7 @@ config SC_CAMCC_7280
tristate "SC7280 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7280
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
SC7280 devices.
@@ -808,6 +862,7 @@ config SC_CAMCC_8280XP
tristate "SC8280XP Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_8280XP
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
SC8280XP devices.
@@ -818,6 +873,7 @@ config SA_DISPCC_8775P
tristate "SA8775P Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select SA_GCC_8775P
+ default m if ARCH_QCOM
help
Support for the two display clock controllers on Qualcomm
Technologies, Inc. SA8775P devices.
@@ -838,6 +894,7 @@ config SC_DISPCC_7280
tristate "SC7280 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7280
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc.
SC7280 devices.
@@ -848,6 +905,7 @@ config SC_DISPCC_8280XP
tristate "SC8280XP Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_8280XP
+ default m if ARCH_QCOM
help
Support for the two display clock controllers on Qualcomm
Technologies, Inc. SC8280XP devices.
@@ -859,6 +917,7 @@ config SA_GCC_8775P
select QCOM_GDSC
depends on ARM64 || COMPILE_TEST
depends on COMMON_CLK_QCOM
+ default ARCH_QCOM
help
Support for the global clock controller on SA8775 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -869,6 +928,7 @@ config SA_GPUCC_8775P
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
select SA_GCC_8775P
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SA8775P devices.
Say Y if you want to support graphics controller devices and
@@ -897,6 +957,7 @@ config SC_GCC_7180
select QCOM_GDSC
depends on COMMON_CLK_QCOM
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
Support for the global clock controller on SC7180 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -907,6 +968,7 @@ config SC_GCC_7280
select QCOM_GDSC
depends on COMMON_CLK_QCOM
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
Support for the global clock controller on SC7280 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -917,6 +979,7 @@ config SC_GCC_8180X
select QCOM_GDSC
depends on COMMON_CLK_QCOM
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
Support for the global clock controller on SC8180X devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -927,6 +990,7 @@ config SC_GCC_8280XP
select QCOM_GDSC
depends on COMMON_CLK_QCOM
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
Support for the global clock controller on SC8280XP devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -945,6 +1009,7 @@ config SC_GPUCC_7280
tristate "SC7280 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7280
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SC7280 devices.
Say Y if you want to support graphics controller devices and
@@ -954,6 +1019,7 @@ config SC_GPUCC_8280XP
tristate "SC8280XP Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_8280XP
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SC8280XP devices.
Say Y if you want to support graphics controller devices and
@@ -972,6 +1038,7 @@ config SC_LPASSCC_8280XP
tristate "SC8280 Low Power Audio Subsystem (LPASS) Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_8280XP
+ default m if ARCH_QCOM
help
Support for the LPASS clock controller on SC8280XP devices.
Say Y if you want to use the LPASS branch clocks of the LPASS clock
@@ -992,6 +1059,7 @@ config SC_LPASS_CORECC_7280
depends on ARM64 || COMPILE_TEST
select SC_GCC_7280
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the LPASS(Low Power Audio Subsystem) core and audio clock
controller on SC7280 devices.
@@ -1011,6 +1079,7 @@ config SC_VIDEOCC_7280
tristate "SC7280 Video Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7280
+ default m if ARCH_QCOM
help
Support for the video clock controller on SC7280 devices.
Say Y if you want to support video devices and functionality such as
@@ -1020,6 +1089,7 @@ config SDM_CAMCC_845
tristate "SDM845 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SDM_GCC_845
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SDM845 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1071,6 +1141,7 @@ config QDU_GCC_1000
tristate "QDU1000/QRU1000 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on QDU1000 and
QRU1000 devices. Say Y if you want to use peripheral
@@ -1089,6 +1160,7 @@ config SDM_GCC_845
tristate "SDM845/SDM670 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SDM845 and SDM670 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -1098,6 +1170,7 @@ config SDM_GPUCC_845
tristate "SDM845 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SDM_GCC_845
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SDM845 devices.
Say Y if you want to support graphics controller devices and
@@ -1108,6 +1181,7 @@ config SDM_VIDEOCC_845
depends on ARM64 || COMPILE_TEST
select SDM_GCC_845
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on SDM845 devices.
Say Y if you want to support video devices and functionality such as
@@ -1117,6 +1191,7 @@ config SDM_DISPCC_845
tristate "SDM845 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select SDM_GCC_845
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SDM845 devices.
@@ -1127,6 +1202,7 @@ config SDM_LPASSCC_845
tristate "SDM845 Low Power Audio Subsystem (LPAAS) Clock Controller"
depends on ARM64 || COMPILE_TEST
select SDM_GCC_845
+ default m if ARCH_QCOM
help
Support for the LPASS clock controller on SDM845 devices.
Say Y if you want to use the LPASS branch clocks of the LPASS clock
@@ -1153,6 +1229,7 @@ config SDX_GCC_65
config SDX_GCC_75
tristate "SDX75 Global Clock Controller"
select QCOM_GDSC
+ default ARCH_QCOM if ARM64
help
Support for the global clock controller on SDX75 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1170,6 +1247,7 @@ config SM_CAMCC_6350
tristate "SM6350 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_6350
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM6350 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1186,6 +1264,7 @@ config SM_CAMCC_MILOS
tristate "Milos Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_MILOS
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Milos devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1204,6 +1283,7 @@ config SM_CAMCC_8250
tristate "SM8250 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8250
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM8250 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1220,6 +1300,7 @@ config SM_CAMCC_8550
tristate "SM8550 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8550
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM8550 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1228,6 +1309,7 @@ config SM_CAMCC_8650
tristate "SM8650 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8650
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM8650 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1236,6 +1318,7 @@ config SM_CAMCC_8750
tristate "SM8750 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8750
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM8750 devices.
The camera clock controller has a separate cambist controller which
@@ -1256,6 +1339,7 @@ config SM_DISPCC_6115
tristate "SM6115 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_6115
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM6115/SM4250 devices.
@@ -1286,6 +1370,7 @@ config SM_DISPCC_8250
tristate "SM8150/SM8250/SM8350 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_8150 || SM_GCC_8250 || SM_GCC_8350
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM8150/SM8250/SM8350 devices.
@@ -1296,6 +1381,7 @@ config SM_DISPCC_6350
tristate "SM6350 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_6350
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM6350 devices.
@@ -1316,6 +1402,7 @@ config SM_DISPCC_MILOS
tristate "Milos Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_MILOS
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
Milos devices.
@@ -1326,6 +1413,7 @@ config SM_DISPCC_8450
tristate "SM8450 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_8450
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM8450 or SM8475 devices.
@@ -1336,6 +1424,7 @@ config SM_DISPCC_8550
tristate "SM8550 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_8550 || SM_GCC_8650 || SAR_GCC_2130P
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SAR2130P, SM8550 or SM8650 devices.
@@ -1347,6 +1436,7 @@ config SM_DISPCC_8750
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_8750
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM8750 devices.
@@ -1357,6 +1447,7 @@ config SM_GCC_4450
tristate "SM4450 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM4450 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -1366,6 +1457,7 @@ config SM_GCC_6115
tristate "SM6115 and SM4250 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM6115 and SM4250 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -1384,6 +1476,7 @@ config SM_GCC_6350
tristate "SM6350 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM6350 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1411,6 +1504,7 @@ config SM_GCC_MILOS
tristate "Milos Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on Milos devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1420,6 +1514,7 @@ config SM_GCC_8150
tristate "SM8150 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM8150 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1429,6 +1524,7 @@ config SM_GCC_8250
tristate "SM8250 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM8250 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1438,6 +1534,7 @@ config SM_GCC_8350
tristate "SM8350 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM8350 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1447,6 +1544,7 @@ config SM_GCC_8450
tristate "SM8450 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM8450 or SM8475
devices.
@@ -1457,6 +1555,7 @@ config SM_GCC_8550
tristate "SM8550 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM8550 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1466,6 +1565,7 @@ config SM_GCC_8650
tristate "SM8650 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM8650 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1475,6 +1575,7 @@ config SM_GCC_8750
tristate "SM8750 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM8750 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1493,6 +1594,7 @@ config SM_GPUCC_6115
tristate "SM6115 Graphics Clock Controller"
select SM_GCC_6115
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM6115 devices.
Say Y if you want to support graphics controller devices and
@@ -1520,6 +1622,7 @@ config SM_GPUCC_6350
tristate "SM6350 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_6350
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM6350 devices.
Say Y if you want to support graphics controller devices and
@@ -1529,6 +1632,7 @@ config SM_GPUCC_MILOS
tristate "Milos Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_MILOS
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on Milos devices.
Say Y if you want to support graphics controller devices and
@@ -1538,6 +1642,7 @@ config SM_GPUCC_8150
tristate "SM8150 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8150
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM8150 devices.
Say Y if you want to support graphics controller devices and
@@ -1547,6 +1652,7 @@ config SM_GPUCC_8250
tristate "SM8250 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8250
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM8250 devices.
Say Y if you want to support graphics controller devices and
@@ -1556,6 +1662,7 @@ config SM_GPUCC_8350
tristate "SM8350 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8350
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM8350 devices.
Say Y if you want to support graphics controller devices and
@@ -1565,6 +1672,7 @@ config SM_GPUCC_8450
tristate "SM8450 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8450
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM8450 or SM8475
devices.
@@ -1575,6 +1683,7 @@ config SM_GPUCC_8550
tristate "SM8550 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8550
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM8550 devices.
Say Y if you want to support graphics controller devices and
@@ -1584,6 +1693,7 @@ config SM_GPUCC_8650
tristate "SM8650 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8650
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM8650 devices.
Say Y if you want to support graphics controller devices and
@@ -1593,6 +1703,7 @@ config SM_GPUCC_8750
tristate "SM8750 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8750
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM8750 devices.
Say Y if you want to support graphics controller devices and
@@ -1611,6 +1722,7 @@ config SM_TCSRCC_8550
tristate "SM8550 TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the TCSR clock controller on SM8550 devices.
Say Y if you want to use peripheral devices such as SD/UFS.
@@ -1619,6 +1731,7 @@ config SM_TCSRCC_8650
tristate "SM8650 TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the TCSR clock controller on SM8650 devices.
Say Y if you want to use peripheral devices such as SD/UFS.
@@ -1627,6 +1740,7 @@ config SM_TCSRCC_8750
tristate "SM8750 TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the TCSR clock controller on SM8750 devices.
Say Y if you want to use peripheral devices such as UFS/USB/PCIe.
@@ -1636,6 +1750,7 @@ config SA_VIDEOCC_8775P
depends on ARM64 || COMPILE_TEST
select SA_GCC_8775P
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on Qualcomm Technologies, Inc.
SA8775P devices.
@@ -1647,6 +1762,7 @@ config SM_VIDEOCC_6350
depends on ARM64 || COMPILE_TEST
select SM_GCC_6350
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on SM6350 devices.
Say Y if you want to support video devices and functionality such as
@@ -1667,6 +1783,7 @@ config SM_VIDEOCC_MILOS
depends on ARM64 || COMPILE_TEST
select SM_GCC_MILOS
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on Qualcomm Technologies, Inc.
Milos devices.
@@ -1688,6 +1805,7 @@ config SM_VIDEOCC_8250
depends on ARM64 || COMPILE_TEST
select SM_GCC_8250
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on SM8250 devices.
Say Y if you want to support video devices and functionality such as
@@ -1707,6 +1825,7 @@ config SM_VIDEOCC_8550
tristate "SM8550 Video Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on Qualcomm Technologies, Inc.
SM8550 or SM8650 or X1E80100 devices.
@@ -1718,6 +1837,7 @@ config SM_VIDEOCC_8750
depends on ARM64 || COMPILE_TEST
select SM_GCC_8750
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on Qualcomm Technologies, Inc.
SM8750 devices.
@@ -1758,6 +1878,7 @@ config KRAITCC
config CLK_GFM_LPASS_SM8250
tristate "SM8250 GFM LPASS Clocks"
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for the Glitch Free Mux (GFM) Low power audio
subsystem (LPASS) clocks found on SM8250 SoCs.
@@ -1767,6 +1888,7 @@ config SM_VIDEOCC_8450
depends on ARM64 || COMPILE_TEST
select SM_GCC_8450
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on Qualcomm Technologies, Inc.
SM8450 or SM8475 devices.
--
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