* Re: [PATCH] pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins 34-39
From: Linus Walleij @ 2026-06-08 21:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Fabien Parent, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260531162237.5290-1-l.scorcia@gmail.com>
On Sun, May 31, 2026 at 6:23 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> The correct Schmitt trigger register offset for pins 34-39 is 0xA00.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Fixes: 264667112ef0 ("pinctrl: mediatek: Add MT8516 Pinctrl driver")
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH net-next] net: airoha: move get_sport() callback at the beginning of airoha_enable_gdm2_loopback()
From: Lorenzo Bianconi @ 2026-06-08 21:24 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Move the get_sport() callback invocation at the beginning of
airoha_enable_gdm2_loopback() routine in order to avoid leaving the
hardware in a partially configured state if get_sport() fails.
Previously, get_sport() was called after GDM2 forwarding, loopback,
channel, length, VIP and IFC registers had already been programmed.
A failure at that point would return an error leaving GDM2 with
loopback enabled but WAN port, PPE CPU port and flow control mappings
not configured.
Performing the get_sport() lookup before any register write guarantees
the routine either completes the full configuration sequence or exits
with no side effects on the hardware.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 5a8e84fa9918..cbc0f4079df0 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1905,6 +1905,10 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
u32 val, pse_port, chan;
int i, src_port;
+ src_port = eth->soc->ops.get_sport(port, dev->nbq);
+ if (src_port < 0)
+ return src_port;
+
airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
FE_PSE_PORT_DROP);
airoha_fe_clear(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
@@ -1934,10 +1938,6 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
- src_port = eth->soc->ops.get_sport(port, dev->nbq);
- if (src_port < 0)
- return src_port;
-
airoha_fe_rmw(eth, REG_FE_WAN_PORT,
WAN1_EN_MASK | WAN1_MASK | WAN0_MASK,
FIELD_PREP(WAN0_MASK, src_port));
---
base-commit: 903db046d5579bef0ea699eae4b279dd6455fc9f
change-id: 20260608-airoha_enable_gdm2_loopback-minor-change-fda3a3351a06
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Expose PMMIR_EL1.SLOTS to guests
From: Congkai Tan @ 2026-06-08 21:03 UTC (permalink / raw)
To: oupton
Cc: blakgeof, catalin.marinas, congkai, harisokn, joey.gouly, kvmarm,
linux-arm-kernel, linux-kernel, mark.rutland, maz, suzuki.poulose,
will, yuzenghui
In-Reply-To: <ah3mObchzwb80_3S@kernel.org>
On Mon, Jun 01, 2026 at 01:06:17PM -0700, Oliver Upton wrote:
> We can't change the value of PMMIR_EL1 unconditionally since older KVM
> treated this register as RAZ/WI. This also mixes poorly with the default
> PMU garbage that we have since as the value of the register can change
> based on where KVM_ARM_VCPU_INIT gets called...
>
> Considering everything, I'd like to see this wired up where:
>
> - PMMIR_EL1.SLOTS takes the value of the underlying hardware PMU only
> if the VMM explicitly selects a particular PMU implementation
>
> - KVM allows userspace to set PMMIR_EL1.SLOTS=0 for backwards
> compatibility
Thanks a lot for the review! Makes sense. We'll work on v2, and here is
the high-level design we plan to follow:
- Introduce a new VM-wide field, e.g. kvm->arch.pmmir_slots.
- Seed it from the underlying hardware value only when handling
KVM_ARM_VCPU_PMU_V3_SET_PMU; otherwise it stays 0.
- access_pmmir() returns whatever is in pmmir_slots.
- set_pmmir() writes pmmir_slots to 0 if the user input is 0;
otherwise it no-ops or rejects.
This way the guest only sees the underlying hardware value if the VMM
selects a PMU via KVM_ARM_VCPU_PMU_V3_SET_PMU, and userspace can pin
SLOTS = 0 through KVM_SET_ONE_REG for backwards compatibility.
Please let me know if there are any concerns. I'll send v2 once it's
ready.
Thanks,
Congkai
^ permalink raw reply
* [PATCH v2] gpiolib: handle gpio-hogs only once
From: Daniel Drake @ 2026-06-08 21:01 UTC (permalink / raw)
To: linusw, brgl; +Cc: linux-gpio, linux-arm-kernel, Daniel Drake
Commit d1d564ec49929 ("gpio: move hogs into GPIO core") introduced a
behaviour change that breaks boot on Raspberry Pi 5 when using the
firmware-supplied device tree:
gpiochip_add_data_with_key: GPIOs 544..575
(/soc@107c000000/gpio@7d517c00) failed to register, -22
brcmstb-gpio 107d517c00.gpio: Could not add gpiochip for bank 1
brcmstb-gpio 107d517c00.gpio: probe with driver brcmstb-gpio failed
with error -22
gpio-brcmstb registers two gpio_chips against the device tree
node gpio@7d517c00, one for each bank. The firmware-supplied DT includes
a gpio-hog on RP1 RUN, and this gpio-hog is attempted to be applied to
*both* gpio_chips. This succeeds against bank 0 (which hosts the GPIO)
and fails for bank 1 (which does not).
In the previous implementation, failures to apply gpio-hogs were
quietly ignored. In the new code, the error code propagates and causes
probe to fail.
Closely approximate the previous behaviour by using the OF_POPULATED flag
to ensure that each gpio-hog is processed only once. The flag was
previously being set before the gpio-hogs were processed, so as part
of this change, the flag now gets set only after the gpio-hog is actioned.
The handling of gpio-hogs on a DT node with multiple gpio_chips remains a
bit incomplete/unclear, but this at least retains the ability to apply
hogs to the first gpio_chip per node.
Signed-off-by: Daniel Drake <dan@reactivated.net>
---
drivers/gpio/gpiolib-of.c | 5 -----
drivers/gpio/gpiolib.c | 8 ++++++++
2 files changed, 8 insertions(+), 5 deletions(-)
v2: move OF_POPULATED flag setting to happen after the gpio-hog has
been applied (otherwise all hogs were considered already-applied
and never applied at all, oops!)
This bug is only exposed by the RPi5 firmware-provided DT that has the
gpio-hog. The DT shipped in the mainline kernel does not have the hog
here. I'm not sure to what extent Linux cares about supporting the
downstream firmware DT.
I'm also happy to consider other approaches. This multi-gpiochip setup is
a bit weird and gpio-brcmstb could perhaps be converted to register only a
single gpio_chip covering all banks. I verified that the other drivers
that obviously follow this same multiple-gpiochip pattern
(pinctrl-amlogic-a4, pinctrl-st and pinctrl-stm32) do not seem to be used by
any board DTs that include gpio-hogs.
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 2c923d17541f..813dbcb91f6f 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -1066,11 +1066,6 @@ int of_gpiochip_add(struct gpio_chip *chip)
of_node_get(np);
- for_each_available_child_of_node_scoped(np, child) {
- if (of_property_read_bool(child, "gpio-hog"))
- of_node_set_flag(child, OF_POPULATED);
- }
-
return ret;
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1e6dce430dca..b02d711289d0 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1031,9 +1031,17 @@ static int gpiochip_hog_lines(struct gpio_chip *gc)
if (!fwnode_property_present(fwnode, "gpio-hog"))
continue;
+ /* The hog may have been handled by another gpio_chip on the same fwnode */
+ if (is_of_node(fwnode) &&
+ of_node_check_flag(to_of_node(fwnode), OF_POPULATED))
+ continue;
+
ret = gpiochip_add_hog(gc, fwnode);
if (ret)
return ret;
+
+ if (is_of_node(fwnode))
+ of_node_set_flag(to_of_node(fwnode), OF_POPULATED);
}
return 0;
--
2.54.0
^ permalink raw reply related
* Re: -next boot failures during KVM setup
From: Ard Biesheuvel @ 2026-06-08 20:56 UTC (permalink / raw)
To: Marc Zyngier, Mark Brown, Will Deacon, Catalin Marinas
Cc: Oliver Upton, Aishwarya.TCV, linux-arm-kernel
In-Reply-To: <87tsrc946i.wl-maz@kernel.org>
On Mon, 8 Jun 2026, at 22:18, Marc Zyngier wrote:
> [+ Will, Catalin, Ard]
>
> On Mon, 08 Jun 2026 20:19:37 +0100,
> Mark Brown <broonie@kernel.org> wrote:
>>
>> I'm seeing boot failures on a range of physical arm64 platforms in
>> today's -next. Turning on earlycon it looks like we're getting bad
>> pointer dereferences during KVM initialisation:
>>
>> [ 0.728923] kvm [1]: nv: 570 coarse grained trap handlers
>> [ 0.735138] kvm [1]: nv: 710 fine grained trap handlers
>> [ 0.741326] kvm [1]: IPA Size Limit: 40 bits
>> [ 0.748840] Unable to handle kernel paging request at virtual address ffff00000478e000
>
> That really doesn't look like a duff pointer.
>
>> [ 0.757027] Mem abort info:
>> [ 0.759917] ESR = 0x0000000096000147
>
> Translation fault, level 3. My take is that something is getting
> unmapped.
>
...
> I've reproduced with -next on an A72 platform. But it doesn't happen
> with kvmarm/next on its own. So it is likely something coming from
> another tree that messes up with CMOs, or .
>
> The stack trace here is slightly better:
>
> [ 0.099138] Unable to handle kernel paging request at virtual
> address ffff0023d9ead000
...
> [ 2.136462] Call trace:
> [ 2.138896] dcache_clean_inval_poc+0x24/0x48 (P)
> [ 2.143592] init_hyp_mode+0x644/0x960
> [ 2.147333] kvm_arm_init+0x128/0x280
> [ 2.150987] do_one_initcall+0x4c/0x458
> [ 2.154813] kernel_init_freeable+0x1f4/0x2a0
> [ 2.159161] kernel_init+0x2c/0x150
> [ 2.162642] ret_from_fork+0x10/0x20
> [ 2.166210] Code: 9ac32042 d1000443 8a230000 d503201f (d50b7e20)
> [ 2.172292] ---[ end trace 0000000000000000 ]---
> [ 2.176958] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
> [ 2.184608] SMP: stopping secondary CPUs
> [ 2.188523] Kernel Offset: 0x47dbd5dc0000 from 0xffff800080000000
> [ 2.194604] PHYS_OFFSET: 0x80000000
> [ 2.198080] CPU features: 0x04000000,804b0008,00040001,0400421b
> [ 2.203988] Memory Limit: none
> [ 2.207031] ---[ end Kernel panic - not syncing: Attempted to kill
> init! exitcode=0x0000000b ]---
>
> This points to the following code in kvm_hyp_init_symbols():
>
> <quote>
> /*
> * Flush entire BSS since part of its data containing init symbols is read
> * while the MMU is off.
> */
> kvm_flush_dcache_to_poc(kvm_ksym_ref(__hyp_bss_start),
> kvm_ksym_ref(__hyp_bss_end) - kvm_ksym_ref(__hyp_bss_start))
>
> </quote>
>
> which I suspect is related to some of the new BSS related code in
> arm64/for-next/mm.
>
> Ard, does this ring a bell?
>
Haven't seen this myself, surprisingly, but yeah, this is obviously related.
By now, I am wondering if unmapping that region entirely is really worth the
hassle, or whether we'd be better off just remapping it read-only.
Given we're at -rc7, I'd lean towards dropping the whole branch for now, or
alternatively, only drop/revert "arm64: mm: Unmap kernel data/bss entirely from the
linear map" (and its followup fix "arm64: mm: Defer remap of linear alias of
data/bss") so that the region always remains readable via the linear map.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Hold kvm->mmu_lock while initialising vcpu->arch.vncr_tlb
From: Yosry Ahmed @ 2026-06-08 20:55 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, kvm, linux-arm-kernel, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Oliver Upton, Zenghui Yu
In-Reply-To: <20260608081108.2244133-1-maz@kernel.org>
On Mon, Jun 08, 2026 at 09:11:08AM +0100, Marc Zyngier wrote:
> Sashiko reports that there is a race between initialising vncr_tlb
> and making use of it, as we don't hold the mmu_lock at this point.
>
> Additionally, it identifies a memory leak, should userspace repeatedly
> invokes the KVM_RUN ioctl after a failure of kvm_arch_vcpu_run_pid_change(),
> as we assign vncr_tlb blindly on first run, irrespective of prior
> allocations.
>
> Slap the two bugs in one go by taking the kvm->mmu_lock on assigning
> vncr_tlb, preventing the race for good, and by checking that vncr_tlb
> is indeed NULL prior to allocation.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Link: https://lore.kernel.org/r/20260607180815.85FBC1F00893@smtp.kernel.org
> ---
> arch/arm64/kvm/nested.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 690b8e8564166..d11e36b3cfcc2 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -1253,8 +1253,14 @@ int kvm_vcpu_allocate_vncr_tlb(struct kvm_vcpu *vcpu)
> if (!kvm_has_feat(vcpu->kvm, ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY))
> return 0;
>
> - vcpu->arch.vncr_tlb = kzalloc_obj(*vcpu->arch.vncr_tlb,
> - GFP_KERNEL_ACCOUNT);
> + if (!vcpu->arch.vncr_tlb) {
> + struct vncr_tlb *vt = kzalloc_obj(*vcpu->arch.vncr_tlb,
> + GFP_KERNEL_ACCOUNT);
> +
> + scoped_guard(write_lock, &vcpu->kvm->mmu_lock)
> + vcpu->arch.vncr_tlb = vt;
> + }
(I am not familiar with this code at all, so apologies in advance if I
am making an idiot out of myself here)
IIUC, the point of holding the lock here is *not* to protect against
concurrent initialization, as in this case the NULL check needs to be
done under the lock.
Rather, the goal is to prevent re-ordering of zeroing from kzalloc and
the assignment to vcpu->arch.vncr_tlb, by depending on the barriers
provided by the lock. The lock is held by the readers so holding it here
conviently means we do not need to add any barriers to the readers.
Is my understanding correct?
If yes, I think the code looks confusing, at least to a layman like
myself. It initially seems like the lock protects against concurrent
initializations, but then the NULL check is not done again under the
lock. The goal of the lock is not clear without the original report.
Mayeb it's clearer to explicitly use barriers if the goal is preventing
reordering?
^ permalink raw reply
* Re: [PATCH v2 0/2] watchdog: sama5d4_wdt: Fix WDDIS handling for SAM9X60 and SAMA7G5
From: Guenter Roeck @ 2026-06-08 20:53 UTC (permalink / raw)
To: Balakrishnan.S, linux-watchdog
Cc: wim, alexandre.belloni, andrei.simion, linux-kernel,
linux-arm-kernel
In-Reply-To: <322c623a-0da8-4821-b0d9-ba2c96bf62ca@microchip.com>
Hi,
On 5/27/26 06:04, Balakrishnan.S@microchip.com wrote:
> Hi Wim,
>
> Gentle ping — both patches have been reviewed. Could this be queued for
> the next cycle?
>
Please check linux-next to determine if patches are queued for the next
commit window.
Thanks,
Guenter
> Thanks,
> Balakrishnan
>
> On 02/03/26 5:03 pm, Balakrishnan Sambath wrote:
>> The sama5d4_wdt driver hardcodes AT91_WDT_WDDIS (bit 15) for WDDIS
>> detection, which is incorrect for SAM9X60 and SAMA7G5 that use bit 12
>> (AT91_SAM9X60_WDDIS). This series fixes the detection by introducing
>> a per-device wddis_mask and documents the bit position difference in
>> the header.
>>
>> Changes in v2:
>> - Reorder patches: fix first, documentation second
>> - Drop patch 3/3, not needed with wddis_mask approach
>> - Keep AT91_SAM9X60_* register names, drop _LEGACY/_MODERN naming
>> - Limit header changes to WDDIS comments and datasheet references
>>
>> Balakrishnan Sambath (2):
>> watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5
>> watchdog: at91sam9_wdt.h: Document WDDIS bit position per SoC family
>>
>> drivers/watchdog/at91sam9_wdt.h | 6 +++--
>> drivers/watchdog/sama5d4_wdt.c | 48 +++++++++++++++------------------
>> 2 files changed, 25 insertions(+), 29 deletions(-)
>>
>
^ permalink raw reply
* Re: [RFC PATCH 2/2] firmware: arm_scmi: Add bus support for autoloading
From: Cristian Marussi @ 2026-06-08 20:53 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Cristian Marussi, arm-scmi, guomin_chen, linux-arm-kernel,
peng.fan, quic_xinqzhan, sudeep.holla
In-Reply-To: <256c182e-a093-4bf5-a353-ca5c06eff489@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 07:06:42PM +0200, Daniel Lezcano wrote:
>
> Hi Cristian,
>
> thanks for your answer
>
> On 6/8/26 18:51, Cristian Marussi wrote:
> > On Mon, Jun 08, 2026 at 04:51:03PM +0200, Daniel Lezcano wrote:
> > > On Mon, Feb 03, 2025 at 10:01:54AM +0000, Cristian Marussi wrote:
> > > > Emit proper MODALIAS uevents when SCMI devices are created and make sure
> > > > all the standard protocol devices are requested when the bus is
> > > > initialized.
> > > >
> > > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > > > ---
> > >
> > > Hi Cristian,
Hi,
> > >
> >
> > Hi Daniel,
> >
> > nice to hear from you in the SCMI land :P
> >
> > > what is the status of this patch ?
> >
> > ....I'd say forgotten/abandoned...I worked on that a bit when I realized
> > only part of the stack was autoloaded...then it did NOT received much
> > love and then I forgot it....buried by other prios....
> >
> > Indeed I have still the local branch...but after a quick check I think
> > is the same as the RFC posted.
> >
> > bbd14b0f7733 firmware: arm_scmi: Add bus support for autoloading
> > 8d982393b505 firmware: arm_scmi: Generate aliases for SCMI modules
> > 383c127faa97 (scmi_vendors_autoload_V2) firmware: arm_scmi: Add aliases to transport modules
> > 00caa894bce2 firmware: arm_scmi: Add module aliases to i.MX vendor protocols
> > d900620c46bb firmware: arm_scmi: Support vendor protocol modules autoloading
> > 4fe57bbeb6dc firmware: arm_scmi: Allow transport properties for multiple instances
> > ad236e5a7f01 Linux 6.13-rc1
> >
> > ...where scmi_vendors_autoload_V2 is merged already...
>
> Actually, I'm puzzled.
>
> On our platform, until 7.1-rc1 we had to add a modprobe.d script to load the
> scmi_cpufreq driver because autoload was not suppported.
>
> Now (7.1-rc1) it seems to be automatically loaded.
>
mmm...I am not sure....but I have a memory to have seen this behaviour
with cpufreq...on some more full-fledged distro (not the usual bare
minimum deboostrapped thing...)...never fully investigated though...
> I imagined the autoload module has been added between 7.0 and 7.1, but the
> series you are mentioning is from 6.13.
Not sure when effectively merged BUT definitely NOT 7.0/7.1...
>
> What I am missing ?
Any chance that on a more complete kernel/distro some symbol dependencies
in modules.dep kicks in, unknowingly, that triggers the load of
scmi-coufreq ?
Not sure if it make any sense...since I miss anyway where the
SCMI-cpufreq <---> cpufreq-driver association is baked in with the current
module device tables...
Not so much of an help here...sorry.
Anyway, I may respin this in the future if there is some interest...unless
someone precedes me :D
Thanks
Cristian
^ permalink raw reply
* Re: [PATCHv2] dmaengine: st_fdma: simplify allocation
From: Rosen Penev @ 2026-06-08 20:52 UTC (permalink / raw)
To: Frank Li
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: <aibs9gb5M4-gbCFY@SMW015318>
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.
>
> 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
* Re: [PATCH v2 1/7] dt-bindings: media: qcom: Add Shikra CAMSS compatible
From: Krzysztof Kozlowski @ 2026-06-08 20:46 UTC (permalink / raw)
To: Nihal Kumar Gupta
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-msm,
linux-media, devicetree, linux-kernel, linux-i2c, imx,
linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-1-ca1936bf1219@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 07:36:38PM +0530, Nihal Kumar Gupta wrote:
> Shikra contains the same Camera Subsystem IP as QCM2290. Document the
> platform-specific compatible string, using qcom,qcm2290-camss as
> fallback.
>
> Unlike QCM2290, Shikra omits the CDM and OPE blocks, requiring only a
> single IOMMU context bank instead of four.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> .../devicetree/bindings/media/qcom,qcm2290-camss.yaml | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> index 391d0f6f67ef5fdfea31dd3683477561516b1556..4f39eefb4898ebc22117407f26cfb4f41deb111b 100644
> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> @@ -14,8 +14,11 @@ description:
>
> properties:
> compatible:
> - const: qcom,qcm2290-camss
> -
Do not remove blank lines.
> + oneOf:
> + - items:
> + - const: qcom,shikra-camss
> + - const: qcom,qcm2290-camss
> + - const: qcom,qcm2290-camss
> reg:
With this fixed:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 3/3] ARM: dts: ti: Add specific compatibles for SCM conf nodes
From: Krzysztof Kozlowski @ 2026-06-08 20:44 UTC (permalink / raw)
To: 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
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-rockchip, linux-omap,
Krzysztof Kozlowski
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-0-4eba9ec1212a@oss.qualcomm.com>
writing-bindings.rst rules dictate that "syscon" must come with a
specific compatible identifying the register layout. Add specific
compatibles for these devices.
This also allows to solve a different problem: "syscon" is contradictory
to "simple-bus". A system controller with registers having their own
functions is not really a trivial MMIO simple bus. These two cannot be
used together, unless listed as an exception.
Reviewed-by: Andreas Kemnade <andreas@kemnade.info>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v3:
1. s/ti,omap5-scm-conf/ti,omap5-sysc-padconf-global/ because it is more
appropriate (specific)
---
arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/am437x-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dm814x.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dm816x.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap2430.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap3.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 6 +++---
9 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi b/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
index 89d16fcc773e..1e09d2b48925 100644
--- a/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
@@ -308,7 +308,7 @@ am33xx_pinmux: pinmux@800 {
};
scm_conf: scm_conf@0 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,am3352-scm-conf", "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/am437x-l4.dtsi b/arch/arm/boot/dts/ti/omap/am437x-l4.dtsi
index e08f356e71cb..30fcce33f4b7 100644
--- a/arch/arm/boot/dts/ti/omap/am437x-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am437x-l4.dtsi
@@ -301,7 +301,7 @@ am43xx_pinmux: pinmux@800 {
};
scm_conf: scm_conf@0 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,am4372-scm-conf", "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/dm814x.dtsi b/arch/arm/boot/dts/ti/omap/dm814x.dtsi
index 27d1f35a31fd..9e02bfa5c3a2 100644
--- a/arch/arm/boot/dts/ti/omap/dm814x.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dm814x.dtsi
@@ -432,7 +432,7 @@ control: control@140000 {
ranges = <0 0x140000 0x20000>;
scm_conf: scm_conf@0 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,dm814-scm-conf", "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/dm816x.dtsi b/arch/arm/boot/dts/ti/omap/dm816x.dtsi
index a1e0e904e0f0..ee0090f7aa64 100644
--- a/arch/arm/boot/dts/ti/omap/dm816x.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dm816x.dtsi
@@ -100,7 +100,7 @@ dm816x_pinmux: pinmux@800 {
/* Device Configuration Registers */
scm_conf: syscon@600 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,dm8168-scm-conf", "syscon", "simple-bus";
reg = <0x600 0x110>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
index c8d325b0f57b..9df7648c4b79 100644
--- a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
@@ -64,7 +64,7 @@ scm: scm@0 {
ranges = <0 0 0x2000>;
scm_conf: scm_conf@0 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,dra7-scm-conf", "syscon", "simple-bus";
reg = <0x0 0x1400>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/omap2430.dtsi b/arch/arm/boot/dts/ti/omap/omap2430.dtsi
index 222613d2a4d1..01bd471f9223 100644
--- a/arch/arm/boot/dts/ti/omap/omap2430.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap2430.dtsi
@@ -50,7 +50,7 @@ omap2430_pmx: pinmux@30 {
};
scm_conf: scm_conf@270 {
- compatible = "syscon",
+ compatible = "ti,omap2-scm-conf", "syscon",
"simple-bus";
reg = <0x270 0x240>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/omap3.dtsi b/arch/arm/boot/dts/ti/omap/omap3.dtsi
index 959069e24730..447736d2e53c 100644
--- a/arch/arm/boot/dts/ti/omap/omap3.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap3.dtsi
@@ -116,7 +116,7 @@ omap3_pmx_core: pinmux@30 {
};
scm_conf: scm_conf@270 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,omap3-scm-conf", "syscon", "simple-bus";
reg = <0x270 0x330>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
index 4c78a0b28fab..c1afc49f456c 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
@@ -681,7 +681,7 @@ omap4_pmx_core: pinmux@40 {
};
omap4_padconf_global: omap4_padconf_global@5a0 {
- compatible = "syscon",
+ compatible = "ti,omap4-sysc-padconf-global", "syscon",
"simple-bus";
reg = <0x5a0 0x170>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
index 915870eb5c99..72849e1c95b0 100644
--- a/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
@@ -96,8 +96,7 @@ omap5_pmx_core: pinmux@40 {
};
omap5_padconf_global: omap5_padconf_global@5a0 {
- compatible = "syscon",
- "simple-bus";
+ compatible = "ti,omap5-sysc-padconf-global", "syscon", "simple-bus";
reg = <0x5a0 0xec>;
#address-cells = <1>;
#size-cells = <1>;
@@ -2311,7 +2310,8 @@ omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@da0 {
ranges = <0 0 0x60>;
scm_wkup_pad_conf: scm_conf@0 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,omap5-scm-wkup-conf",
+ "syscon", "simple-bus";
reg = <0x0 0x60>;
#address-cells = <1>;
#size-cells = <1>;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/3] dt-bindings: mfd: syscon: Drop custom select for older dtschema
From: Krzysztof Kozlowski @ 2026-06-08 20:44 UTC (permalink / raw)
To: 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
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-rockchip, linux-omap,
Krzysztof Kozlowski
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-0-4eba9ec1212a@oss.qualcomm.com>
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.
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
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: mfd: syscon: Disallow simple-bus with syscon
From: Krzysztof Kozlowski @ 2026-06-08 20:44 UTC (permalink / raw)
To: 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
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-rockchip, linux-omap,
Krzysztof Kozlowski
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-0-4eba9ec1212a@oss.qualcomm.com>
"syscon" is a system controller with registers having their own
functions, thus not really a trivial MMIO simple bus. "simple-bus" on
the other hand is just a bus on which multiple devices sit and the
"simple" means no functions are allowed here.
Combination of both "syscon" and "simple-bus" is abuse of DT for easier
instantiating of Linux device drivers so add a schema to disallow that.
Unfortunately there are a few old cases of that patterns, so add
exceptions:
1. "cznic,turris1x-cpld" and "img,pistachio-cr-periph" are already used
in upstream DTS.
2. TI has several DTSI with a child of SCM device (e.g. "ti,am3-scm")
using "syscon" and "simple-bus" but without a dedicated compatible
documented anywhere. Add new compatibles for such cases.
Additionally, add comments around code enforcing two or three
compatibles: it is similar safeguard detecting incorrect bindings.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v3:
1. s/ti,omap5-scm-conf/ti,omap5-sysc-padconf-global/ because it is more
appropriate (specific)
2. Add comments, why simple-mfd+syscon has dedicated if:then:
Changes in v2:
1. Complete patch. I accidentally sent only part of it, built on top of
internal WIP which I forgot to squash.
I received Ack from Rob, but change is significant, so please kindly
re-review.
---
.../devicetree/bindings/mfd/syscon-common.yaml | 34 ++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/syscon-common.yaml b/Documentation/devicetree/bindings/mfd/syscon-common.yaml
index 14a08e7bc8bd..2d5eef5add54 100644
--- a/Documentation/devicetree/bindings/mfd/syscon-common.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon-common.yaml
@@ -32,6 +32,7 @@ properties:
compatible:
contains:
const: syscon
+ # Always require a specific compatible for syscon
minItems: 2
maxItems: 5 # Should be enough
@@ -52,11 +53,44 @@ allOf:
contains:
const: simple-mfd
then:
+ # Always require a specific compatible for syscon with simple-mfd
properties:
compatible:
minItems: 3
maxItems: 5
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: simple-bus
+ then:
+ # simple-bus conflicts with syscon - if a device is a system controller
+ # with miscellaneous registers, then it has at least one dedicated
+ # function thus it is not a simple bus. Allow existing exceptions.
+ if:
+ properties:
+ compatible:
+ not:
+ contains:
+ # This list CANNOT grow
+ enum:
+ - cznic,turris1x-cpld
+ - img,pistachio-cr-periph
+ - ti,am3352-scm-conf
+ - ti,am4372-scm-conf
+ - ti,dm814-scm-conf
+ - ti,dm8168-scm-conf
+ - ti,dra7-scm-conf
+ - ti,omap2-scm-conf
+ - ti,omap3-scm-conf
+ - ti,omap4-sysc-padconf-global
+ - ti,omap5-scm-wkup-conf
+ - ti,omap5-sysc-padconf-global
+ then:
+ required:
+ - incorrect-usage-of-simple-bus-and-syscon
+
additionalProperties: true
examples:
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/3] dt-bindings: mfd: syscon: Tighten checks
From: Krzysztof Kozlowski @ 2026-06-08 20:44 UTC (permalink / raw)
To: 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
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-rockchip, linux-omap,
Krzysztof Kozlowski
Changes in v3:
- Drop patch #2:
dt-bindings: mfd: syscon: Drop unneeded case for syscon + simple-mfd
- Bump dtschema requirement
- Link to v2: https://patch.msgid.link/20260608-n-dt-bindings-simple-bus-syscon-v2-0-0203e6c249dc@oss.qualcomm.com
Changes in v2:
1. New patches #2 and #3
1. Add missing part of patch #1, thus not adding Rob's Ack.
https://lore.kernel.org/all/20260531110404.12768-3-krzysztof.kozlowski@oss.qualcomm.com/
I tested dt_binding_check and dtbs_check for arm, arm64 and riscv and I
think I did not introduce new dtbs_check warnings. Old code anyway has
multiple abuses of syscon, thus tricky to judge for arm at least.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (3):
dt-bindings: mfd: syscon: Disallow simple-bus with syscon
dt-bindings: mfd: syscon: Drop custom select for older dtschema
ARM: dts: ti: Add specific compatibles for SCM conf nodes
Documentation/devicetree/bindings/Makefile | 2 +-
.../devicetree/bindings/mfd/syscon-common.yaml | 34 ++++++
Documentation/devicetree/bindings/mfd/syscon.yaml | 116 ---------------------
arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/am437x-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dm814x.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dm816x.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap2430.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap3.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 6 +-
12 files changed, 46 insertions(+), 128 deletions(-)
---
base-commit: 78f5e68a8d0a1123dd1b007688ccf0e6876a5c15
change-id: 20260608-n-dt-bindings-simple-bus-syscon-e39df408a02d
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCHv2 0/3] watchdog: sama5d4: fix IRQ and timeout bugs, use platform_get_irq_optional
From: Rosen Penev @ 2026-06-08 20:42 UTC (permalink / raw)
To: Nicolas Ferre
Cc: linux-watchdog, Alexandre Belloni, Claudiu Beznea,
Wim Van Sebroeck, Guenter Roeck,
moderated list:ARM/Microchip (AT91) SoC support, open list
In-Reply-To: <10b595d3-d44b-4fbb-a834-a94b154a0381@microchip.com>
On Mon, Jun 8, 2026 at 1:38 PM Nicolas Ferre
<nicolas.ferre@microchip.com> wrote:
>
> On 08/06/2026 at 13:09, Rosen Penev wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > This series fixes three issues in the sama5d4 watchdog driver:
> >
> > Patch 1: Return IRQ_NONE when the status register indicates no watchdog
> > interrupt is pending, and pass the configured timeout (not the hardcoded
> > default) to sama5d4_wdt_init().
> >
> > Patch 2: Replace irq_of_parse_and_map() with platform_get_irq_optional()
> > for simpler error handling and EPROBE_DEFER support.
> >
> > Patch 3: Move platform_set_drvdata() before devm_request_irq() to prevent
> > a NULL pointer dereference in the interrupt handler if the shared System
> > IRQ fires immediately after registration.
> >
> > v2: address sashiko review
>
> Rosen,
>
> I'd like to hear how these issues where found and how the patches were
> tested.
They were not. Maintainer has explicitly asked me to fix issues
discovered by https://sashiko.dev
I originally only had patch 2, which is true of multiple places.
>
> Best regards,
> Nicolas
>
> > Rosen Penev (3):
> > watchdog: sama5d4: fix shared IRQ and hardcoded timeout issues
> > watchdog: sama5d4: use platform_get_irq_optional()
> > watchdog: sama5d4: fix NULL deref in irq handler
> >
> > drivers/watchdog/sama5d4_wdt.c | 32 +++++++++++++++++---------------
> > 1 file changed, 17 insertions(+), 15 deletions(-)
> >
> > --
> > 2.54.0
> >
>
^ permalink raw reply
* Re: [PATCHv2 0/3] watchdog: sama5d4: fix IRQ and timeout bugs, use platform_get_irq_optional
From: Nicolas Ferre @ 2026-06-08 20:38 UTC (permalink / raw)
To: Rosen Penev, linux-watchdog
Cc: Alexandre Belloni, Claudiu Beznea, Wim Van Sebroeck,
Guenter Roeck, moderated list:ARM/Microchip (AT91) SoC support,
open list
In-Reply-To: <20260608200933.18669-1-rosenp@gmail.com>
On 08/06/2026 at 13:09, Rosen Penev wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This series fixes three issues in the sama5d4 watchdog driver:
>
> Patch 1: Return IRQ_NONE when the status register indicates no watchdog
> interrupt is pending, and pass the configured timeout (not the hardcoded
> default) to sama5d4_wdt_init().
>
> Patch 2: Replace irq_of_parse_and_map() with platform_get_irq_optional()
> for simpler error handling and EPROBE_DEFER support.
>
> Patch 3: Move platform_set_drvdata() before devm_request_irq() to prevent
> a NULL pointer dereference in the interrupt handler if the shared System
> IRQ fires immediately after registration.
>
> v2: address sashiko review
Rosen,
I'd like to hear how these issues where found and how the patches were
tested.
Best regards,
Nicolas
> Rosen Penev (3):
> watchdog: sama5d4: fix shared IRQ and hardcoded timeout issues
> watchdog: sama5d4: use platform_get_irq_optional()
> watchdog: sama5d4: fix NULL deref in irq handler
>
> drivers/watchdog/sama5d4_wdt.c | 32 +++++++++++++++++---------------
> 1 file changed, 17 insertions(+), 15 deletions(-)
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [GIT PULL] coresight: Updates for Linux v7.2
From: Greg KH @ 2026-06-08 19:37 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: linux-arm-kernel, coresight, james.clark, leo.yan, mike.leach
In-Reply-To: <20260608125424.283998-1-suzuki.poulose@arm.com>
On Mon, Jun 08, 2026 at 01:54:24PM +0100, Suzuki K Poulose wrote:
> Hi Greg
>
> Please find the updates for CoreSight self hosted tracing subsystem targeting
> Linux v7.2
>
> Kindly pull,
>
> Suzuki
>
> ---
>
>
> The following changes since commit 7fd2df204f342fc17d1a0bfcd474b24232fb0f32:
>
> Linux 7.1-rc2 (2026-05-03 14:21:25 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v7.2
Pulled and pushed out, thanks.
greg k-h
^ permalink raw reply
* Re: -next boot failures during KVM setup
From: Marc Zyngier @ 2026-06-08 20:18 UTC (permalink / raw)
To: Mark Brown, Will Deacon, Catalin Marinas, Ard Biesheuvel
Cc: Oliver Upton, Aishwarya.TCV, linux-arm-kernel
In-Reply-To: <aicVyebkEMs6w6UV@sirena.co.uk>
[+ Will, Catalin, Ard]
On Mon, 08 Jun 2026 20:19:37 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> I'm seeing boot failures on a range of physical arm64 platforms in
> today's -next. Turning on earlycon it looks like we're getting bad
> pointer dereferences during KVM initialisation:
>
> [ 0.728923] kvm [1]: nv: 570 coarse grained trap handlers
> [ 0.735138] kvm [1]: nv: 710 fine grained trap handlers
> [ 0.741326] kvm [1]: IPA Size Limit: 40 bits
> [ 0.748840] Unable to handle kernel paging request at virtual address ffff00000478e000
That really doesn't look like a duff pointer.
> [ 0.757027] Mem abort info:
> [ 0.759917] ESR = 0x0000000096000147
Translation fault, level 3. My take is that something is getting
unmapped.
> [ 0.763772] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 0.851526] pc : dcache_clean_inval_poc+0x24/0x48
> [ 0.856367] lr : kvm_arm_init+0xbb0/0x13f0
> ...
>
> [ 0.937120] Call trace:
> [ 0.939628] dcache_clean_inval_poc+0x24/0x48 (P)
> [ 0.944457] do_one_initcall+0x60/0x1d4
> [ 0.948393] kernel_init_freeable+0x250/0x2d8
>
> https://lava.sirena.org.uk/scheduler/job/2849583#L848
>
> (with other platforms I've got earlycon logs showing basically the same
> thing). I have some bisects but they seem to have been confused by
> earlier driver core issues, I've tweaked to try to avoid that and am
> retrying. FVP and qemu seem unaffected:
>
> https://lava.sirena.org.uk/scheduler/job/2848374#L888
> https://lava.sirena.org.uk/scheduler/job/2848966#L447
>
> The affected platforms thus far are all SMP Cortex A53/5 systems, but
> that's the vast majority of my lab. They have both GICv3 and GICv2.
I've reproduced with -next on an A72 platform. But it doesn't happen
with kvmarm/next on its own. So it is likely something coming from
another tree that messes up with CMOs, or .
The stack trace here is slightly better:
[ 0.099138] Unable to handle kernel paging request at virtual address ffff0023d9ead000
[ 0.099141] Mem abort info:
[ 0.099142] ESR = 0x0000000096000147
[ 0.099144] EC = 0x25: DABT (current EL), IL = 32 bits
[ 0.099146] SET = 0, FnV = 0
[ 0.099148] EA = 0, S1PTW = 0
[ 0.099150] FSC = 0x07: level 3 translation fault
[ 0.099151] Data abort info:
[ 0.099153] ISV = 0, ISS = 0x00000147, ISS2 = 0x00000000
[ 0.099155] CM = 1, WnR = 1, TnD = 0, TagAccess = 0
[ 0.099157] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 0.099159] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000245983b000
[ 0.099162] [ffff0023d9ead000] pgd=18000027fffff403, p4d=18000027fffff403, pud=18000027ffffe403, pmd=18000027fffed403, pte=00e8002459eadf06
[ 0.099173] Internal error: Oops: 0000000096000147 [#1] SMP
[ 0.582137] Freeing initrd memory: 29068K
[ 2.025400] Modules linked in:
[ 2.028447] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.1.0-rc7-next-20260608 #6265 PREEMPT
[ 2.037482] Hardware name: SolidRun Ltd. SolidRun CEX7 Platform, BIOS EDK II May 30 2024
[ 2.045559] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2.052510] pc : dcache_clean_inval_poc+0x24/0x48
[ 2.057210] lr : kvm_hyp_init_symbols+0x370/0x388
[ 2.061904] sp : ffff80008009bd00
[ 2.065206] x29: ffff80008009bd00 x28: 0000000000000000 x27: 0000002022116000
[ 2.072332] x26: ffff0020232967f0 x25: 00000020a2116000 x24: 00000000000038b0
[ 2.079458] x23: 0000000000000030 x22: ffffc7dc575880c8 x21: ffffc7dc57948fb0
[ 2.086584] x20: 0000000000000001 x19: 0000000001002222 x18: 00000000ffffffff
[ 2.093709] x17: 000000007a3345b6 x16: 0000000073a611dd x15: 0000000000000000
[ 2.100835] x14: 0000000000000000 x13: 0000000000000000 x12: fffffffffffff800
[ 2.107960] x11: 00000000000007ff x10: 0000000000000000 x9 : fffffffffffff800
[ 2.115086] x8 : 00000000000007ff x7 : 0000000000000000 x6 : ffffc7dc5740af58
[ 2.122211] x5 : 0000000080000000 x4 : ffffc7b87de00000 x3 : 000000000000003f
[ 2.129336] x2 : 0000000000000040 x1 : ffff0023d9eaf000 x0 : ffff0023d9ead000
[ 2.136462] Call trace:
[ 2.138896] dcache_clean_inval_poc+0x24/0x48 (P)
[ 2.143592] init_hyp_mode+0x644/0x960
[ 2.147333] kvm_arm_init+0x128/0x280
[ 2.150987] do_one_initcall+0x4c/0x458
[ 2.154813] kernel_init_freeable+0x1f4/0x2a0
[ 2.159161] kernel_init+0x2c/0x150
[ 2.162642] ret_from_fork+0x10/0x20
[ 2.166210] Code: 9ac32042 d1000443 8a230000 d503201f (d50b7e20)
[ 2.172292] ---[ end trace 0000000000000000 ]---
[ 2.176958] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2.184608] SMP: stopping secondary CPUs
[ 2.188523] Kernel Offset: 0x47dbd5dc0000 from 0xffff800080000000
[ 2.194604] PHYS_OFFSET: 0x80000000
[ 2.198080] CPU features: 0x04000000,804b0008,00040001,0400421b
[ 2.203988] Memory Limit: none
[ 2.207031] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
This points to the following code in kvm_hyp_init_symbols():
<quote>
/*
* Flush entire BSS since part of its data containing init symbols is read
* while the MMU is off.
*/
kvm_flush_dcache_to_poc(kvm_ksym_ref(__hyp_bss_start),
kvm_ksym_ref(__hyp_bss_end) - kvm_ksym_ref(__hyp_bss_start))
</quote>
which I suspect is related to some of the new BSS related code in
arm64/for-next/mm.
Ard, does this ring a bell?
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* [PATCHv2 2/3] watchdog: sama5d4: use platform_get_irq_optional()
From: Rosen Penev @ 2026-06-08 20:09 UTC (permalink / raw)
To: linux-watchdog
Cc: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Wim Van Sebroeck, Guenter Roeck,
moderated list:ARM/Microchip (AT91) SoC support, open list
In-Reply-To: <20260608200933.18669-1-rosenp@gmail.com>
irq_of_parse_and_map() requires irq_dispose_mapping() on failure. Don't
bother with it as platform_get_irq_optional() doesn't need it.
Also handle EPROBE_DEFER.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/watchdog/sama5d4_wdt.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index f74f1e8956b5..2536e2f2ab32 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -11,7 +11,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_irq.h>
#include <linux/platform_device.h>
#include <linux/reboot.h>
#include <linux/watchdog.h>
@@ -245,7 +244,7 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
struct watchdog_device *wdd;
struct sama5d4_wdt *wdt;
void __iomem *regs;
- u32 irq = 0;
+ int irq = 0;
u32 reg;
int ret;
@@ -281,8 +280,11 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
return ret;
if (wdt->need_irq) {
- irq = irq_of_parse_and_map(dev->of_node, 0);
- if (!irq) {
+ irq = platform_get_irq_optional(pdev, 0);
+ if (irq == -EPROBE_DEFER)
+ return irq;
+
+ if (irq < 0) {
dev_warn(dev, "failed to get IRQ from DT\n");
wdt->need_irq = false;
}
--
2.54.0
^ permalink raw reply related
* [PATCHv2 0/3] watchdog: sama5d4: fix IRQ and timeout bugs, use platform_get_irq_optional
From: Rosen Penev @ 2026-06-08 20:09 UTC (permalink / raw)
To: linux-watchdog
Cc: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Wim Van Sebroeck, Guenter Roeck,
moderated list:ARM/Microchip (AT91) SoC support, open list
This series fixes three issues in the sama5d4 watchdog driver:
Patch 1: Return IRQ_NONE when the status register indicates no watchdog
interrupt is pending, and pass the configured timeout (not the hardcoded
default) to sama5d4_wdt_init().
Patch 2: Replace irq_of_parse_and_map() with platform_get_irq_optional()
for simpler error handling and EPROBE_DEFER support.
Patch 3: Move platform_set_drvdata() before devm_request_irq() to prevent
a NULL pointer dereference in the interrupt handler if the shared System
IRQ fires immediately after registration.
v2: address sashiko review
Rosen Penev (3):
watchdog: sama5d4: fix shared IRQ and hardcoded timeout issues
watchdog: sama5d4: use platform_get_irq_optional()
watchdog: sama5d4: fix NULL deref in irq handler
drivers/watchdog/sama5d4_wdt.c | 32 +++++++++++++++++---------------
1 file changed, 17 insertions(+), 15 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCHv2 3/3] watchdog: sama5d4: fix NULL deref in irq handler
From: Rosen Penev @ 2026-06-08 20:09 UTC (permalink / raw)
To: linux-watchdog
Cc: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Wim Van Sebroeck, Guenter Roeck,
moderated list:ARM/Microchip (AT91) SoC support, open list
In-Reply-To: <20260608200933.18669-1-rosenp@gmail.com>
Move platform_set_drvdata() before devm_request_irq() so that the
interrupt handler can safely dereference the driver data via
platform_get_drvdata(). An interrupt on the shared System IRQ line
(SAM9X60/SAM9X7) could fire between request_irq and the late
platform_set_drvdata() call, causing the handler to dereference NULL.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/watchdog/sama5d4_wdt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index 2536e2f2ab32..7cd6f35c8e21 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -268,6 +268,7 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
: AT91_WDT_WDDIS;
watchdog_set_drvdata(wdd, wdt);
+ platform_set_drvdata(pdev, wdt);
regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(regs))
@@ -319,8 +320,6 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
if (ret)
return ret;
- platform_set_drvdata(pdev, wdt);
-
dev_info(dev, "initialized (timeout = %d sec, nowayout = %d)\n",
wdd->timeout, nowayout);
--
2.54.0
^ permalink raw reply related
* [PATCHv2 1/3] watchdog: sama5d4: fix shared IRQ and hardcoded timeout issues
From: Rosen Penev @ 2026-06-08 20:09 UTC (permalink / raw)
To: linux-watchdog
Cc: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Wim Van Sebroeck, Guenter Roeck,
moderated list:ARM/Microchip (AT91) SoC support, open list
In-Reply-To: <20260608200933.18669-1-rosenp@gmail.com>
Fix three pre-existing issues in the sama5d4 watchdog driver:
1. Unsafe IRQF_SHARED | IRQF_NO_SUSPEND combination: The watchdog
interrupt is a dedicated peripheral line, not shared with other
devices.
2. Unconditional IRQ_HANDLED on shared line: The handler returned
IRQ_HANDLED even when the status register indicated no watchdog
interrupt was pending. Return IRQ_NONE in that case so the kernel
can properly detect spurious interrupts on the line.
3. Hardcoded 16-second timeout: sama5d4_wdt_init() unconditionally
used WDT_DEFAULT_TIMEOUT (16s) for the hardware timeout, ignoring
any timeout configured via device tree (watchdog_init_timeout) or
userspace. Pass wdd->timeout to sama5d4_wdt_init() so the
configured timeout is honored during probe and resume.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/watchdog/sama5d4_wdt.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index 704b786cc2ec..f74f1e8956b5 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -169,11 +169,12 @@ static irqreturn_t sama5d4_wdt_irq_handler(int irq, void *dev_id)
else
reg = wdt_read(wdt, AT91_WDT_SR);
- if (reg) {
- pr_crit("Atmel Watchdog Software Reset\n");
- emergency_restart();
- pr_crit("Reboot didn't succeed\n");
- }
+ if (!reg)
+ return IRQ_NONE;
+
+ pr_crit("Atmel Watchdog Software Reset\n");
+ emergency_restart();
+ pr_crit("Reboot didn't succeed\n");
return IRQ_HANDLED;
}
@@ -197,11 +198,11 @@ static int of_sama5d4_wdt_init(struct device_node *np, struct sama5d4_wdt *wdt)
return 0;
}
-static int sama5d4_wdt_init(struct sama5d4_wdt *wdt)
+static int sama5d4_wdt_init(struct sama5d4_wdt *wdt, unsigned int timeout)
{
u32 reg, val;
- val = WDT_SEC2TICKS(WDT_DEFAULT_TIMEOUT);
+ val = WDT_SEC2TICKS(timeout);
/*
* When booting and resuming, the bootloader may have changed the
* watchdog configuration.
@@ -305,7 +306,7 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
set_bit(WDOG_HW_RUNNING, &wdd->status);
}
- ret = sama5d4_wdt_init(wdt);
+ ret = sama5d4_wdt_init(wdt, wdd->timeout);
if (ret)
return ret;
@@ -358,7 +359,7 @@ static int sama5d4_wdt_resume_early(struct device *dev)
* This should only be done when the registers are lost on suspend but
* there is no way to get this information right now.
*/
- sama5d4_wdt_init(wdt);
+ sama5d4_wdt_init(wdt, wdt->wdd.timeout);
if (watchdog_active(&wdt->wdd))
sama5d4_wdt_start(&wdt->wdd);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] nvme-apple: Prevent shared tags across queues on Apple A11
From: Keith Busch @ 2026-06-08 19:45 UTC (permalink / raw)
To: Nick Chan
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jens Axboe,
Christoph Hellwig, Sagi Grimberg, asahi, linux-arm-kernel,
linux-nvme, linux-kernel, stable
In-Reply-To: <20260607-prevent-tag-collision-t8015-v2-1-dc4ef4fb42bc@gmail.com>
On Sun, Jun 07, 2026 at 02:10:58PM +0800, Nick Chan wrote:
> On Apple A11, tags of pending commands must be unique across the admin
> and IO queues, else the firmware crashes with
> "duplicate tag error for tag N", with N being the tag.
>
> Apply the existing workaround for M1 of reserving two tags for the admin
> queue to A11.
Thanks, applied to nvme-7.2.
^ permalink raw reply
* Re: [PATCH v8 6/6] pinctrl: mediatek: Add MT6735 pinctrl driver
From: Linus Walleij @ 2026-06-08 19:41 UTC (permalink / raw)
To: Yassine Oudjana
Cc: Sean Wang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Andy Teng,
Yassine Oudjana, linux-mediatek, linux-gpio, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260530145800.1029920-7-y.oudjana@protonmail.com>
Hi Yassine,
thanks for your patch!
On Sat, May 30, 2026 at 4:58 PM Yassine Oudjana
<yassine.oudjana@gmail.com> wrote:
> From: Yassine Oudjana <y.oudjana@protonmail.com>
>
> Add a driver for the MediaTek MT6735 SoC pin controller. This driver
> also supports the pin controller on MT6735M, which lacks 6 physical
> pins (198-203) used for MSDC2 on MT6735.
>
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
Sashiko has good comments on this driver, look into them!
> +config PINCTRL_MT6735
> + bool "MediaTek MT6735(M) pin control"
> + depends on OF
> + default ARM64 && ARCH_MEDIATEK
> + select PINCTRL_MTK_PARIS
There are in-flight patches to make MTK drivers tristate for
the Android GKI. Do you want to use tristate for this driver too?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/2] pinctrl: mediatek: Enable MT8189 as loadable module
From: Linus Walleij @ 2026-06-08 19:29 UTC (permalink / raw)
To: Justin Yeh
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260529100308.51271-1-justin.yeh@mediatek.com>
On Fri, May 29, 2026 at 12:04 PM Justin Yeh <justin.yeh@mediatek.com> wrote:
> This series enables PINCTRL_MT8189 to be built as a loadable kernel
> module, which is required for GKI (Generic Kernel Image) + vendor_dlkm
> deployments where vendor-specific drivers must be kept separate from
> the GKI vmlinux.
Maybe tell us that this is for Android?
> Patch 1 restores the tristate option that was recently changed to bool,
No the driver was merged with tristate.
See
commit a3fe1324c3c5c292ec79bd756497c1c44ff247d2 (tag: pinctrl-v6.17-1)
"pinctrl: mediatek: Add pinctrl driver for mt8189"
> preventing module builds. Patch 2 adds the missing MODULE_LICENSE macro
> that's required when building as a module.
So that should be squashed into one patch or it will not bisect.
> Together these changes allow MT8189 pinctrl to be properly packaged as
> a vendor kernel module while maintaining the existing built-in option.
So why do we change this only for MT8189 and not for all
Mediatek pinctrl drivers?
I would just add this tristate option and license to all of them while
you're at it or I will get like 20 identical patches and it's a waste
of time for me.
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox