* Re: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4
From: Markus Mayer @ 2026-06-22 20:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Florian Fainelli, Rob Herring, Conor Dooley,
Linux ARM Kernel List, Device Tree Mailing List,
Linux Kernel Mailing List
In-Reply-To: <CAGt4E5tGHJFXswic6vTx-ThN2K9xBtO8oA4ybrXg+q5cA6GYCA@mail.gmail.com>
On Thu, 28 May 2026 at 14:45, Markus Mayer <mmayer@broadcom.com> wrote:
> > > Thanks for providing justification, quite reasonable. A pity that none
> > > of the commit msgs answered this way.
> >
> > The real pity is how this API was designed, making all of this
> > necessary in the first place.
> >
> > We can definitely spell out more clearly in the commit messages what
> > is going on and why all of this is needed. I'll pull all the pieces
> > together from the various responses. As long as there's a way we can
> > reasonably implement what we need, we'll be happy.
>
> It has been a minute, but we'd like to resume this effort[1] to
> upstream these changes or some variation thereof.
>
> What are the best steps to resume this undertaking? There are still a
> few topics where I am not entirely clear on how to better explain
> things or how to address the feedback provided. My apologies for that.
> I will do my best to address whatever concerns there are.
>
> Should I put together a new pull request that contains improved commit
> messages and addresses some of the feedback and we hash out whatever
> questions remain on the new thread? Or would it be better for me to
> reply to the old thread with some of the questions that remain before
> sending a revised series?
Any advice on how to best proceed from here?
Thanks,
-Markus
> [1] https://lore.kernel.org/all/20231205184741.3092376-1-mmayer@broadcom.com/
^ permalink raw reply
* [PATCH 2/2] KVM: arm64: selftests: Add MMIO sign-extending load test
From: Fuad Tabba @ 2026-06-22 19:07 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, Steffen Eiden,
Catalin Marinas, Will Deacon, Shuah Khan, Christoffer Dall,
Victor Kamensky, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260622190701.2039766-1-fuad.tabba@linux.dev>
Add a test for sign-extending MMIO loads (LDRSB, LDRSH, LDRSW) into Xt
and Wt destinations, with and without the sign bit set. The host supplies
the MMIO data and checks the guest register holds the sign-extended value.
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../selftests/kvm/arm64/mmio_sign_ext.c | 133 ++++++++++++++++++
2 files changed, 134 insertions(+)
create mode 100644 tools/testing/selftests/kvm/arm64/mmio_sign_ext.c
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 9118a5a51b89f..0f5803a1092e1 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -171,6 +171,7 @@ TEST_GEN_PROGS_arm64 += arm64/hello_el2
TEST_GEN_PROGS_arm64 += arm64/host_sve
TEST_GEN_PROGS_arm64 += arm64/hypercalls
TEST_GEN_PROGS_arm64 += arm64/external_aborts
+TEST_GEN_PROGS_arm64 += arm64/mmio_sign_ext
TEST_GEN_PROGS_arm64 += arm64/page_fault_test
TEST_GEN_PROGS_arm64 += arm64/psci_test
TEST_GEN_PROGS_arm64 += arm64/sea_to_user
diff --git a/tools/testing/selftests/kvm/arm64/mmio_sign_ext.c b/tools/testing/selftests/kvm/arm64/mmio_sign_ext.c
new file mode 100644
index 0000000000000..d1efbccd1603a
--- /dev/null
+++ b/tools/testing/selftests/kvm/arm64/mmio_sign_ext.c
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * mmio_sign_ext - Test sign-extending MMIO load emulation (LDRSB/LDRSH/LDRSW)
+ *
+ * Copyright (c) 2026 Google LLC
+ */
+
+#include "processor.h"
+#include "test_util.h"
+
+#define MMIO_ADDR 0x8000000ULL
+
+struct mmio_test {
+ const char *name;
+ uint64_t data;
+ uint8_t len;
+ uint64_t expected;
+};
+
+/* Paired 1:1, in order, with the loads in guest_code() below. */
+static const struct mmio_test tests[] = {
+ /* LDRSB Xt: byte sign-extended to 64 bits */
+ { "LDRSB Xt 0xFF", 0xFF, 1, 0xFFFFFFFFFFFFFFFFULL },
+ { "LDRSB Xt 0x7F", 0x7F, 1, 0x7FULL },
+
+ /* LDRSB Wt: byte sign-extended to 32 bits, upper 32 bits zeroed */
+ { "LDRSB Wt 0xFF", 0xFF, 1, 0xFFFFFFFFULL },
+ { "LDRSB Wt 0x7F", 0x7F, 1, 0x7FULL },
+
+ /* LDRSH Xt: halfword sign-extended to 64 bits */
+ { "LDRSH Xt 0x8001", 0x8001, 2, 0xFFFFFFFFFFFF8001ULL },
+ { "LDRSH Xt 0x7FFF", 0x7FFF, 2, 0x7FFFULL },
+
+ /* LDRSH Wt: halfword sign-extended to 32 bits, upper 32 bits zeroed */
+ { "LDRSH Wt 0x8001", 0x8001, 2, 0xFFFF8001ULL },
+ { "LDRSH Wt 0x7FFF", 0x7FFF, 2, 0x7FFFULL },
+
+ /* LDRSW Xt: word sign-extended to 64 bits (no Wt form) */
+ { "LDRSW Xt 0x80000001", 0x80000001, 4, 0xFFFFFFFF80000001ULL },
+ { "LDRSW Xt 0x7FFFFFFF", 0x7FFFFFFF, 4, 0x7FFFFFFFULL },
+};
+
+static void guest_code(void)
+{
+ uint64_t val;
+
+ asm volatile("ldrsb %0, [%1]" : "=r"(val) : "r"(MMIO_ADDR) : "memory");
+ GUEST_SYNC(val);
+
+ asm volatile("ldrsb %0, [%1]" : "=r"(val) : "r"(MMIO_ADDR) : "memory");
+ GUEST_SYNC(val);
+
+ asm volatile("ldrsb %w0, [%1]" : "=r"(val) : "r"(MMIO_ADDR) : "memory");
+ GUEST_SYNC(val);
+
+ asm volatile("ldrsb %w0, [%1]" : "=r"(val) : "r"(MMIO_ADDR) : "memory");
+ GUEST_SYNC(val);
+
+ asm volatile("ldrsh %0, [%1]" : "=r"(val) : "r"(MMIO_ADDR) : "memory");
+ GUEST_SYNC(val);
+
+ asm volatile("ldrsh %0, [%1]" : "=r"(val) : "r"(MMIO_ADDR) : "memory");
+ GUEST_SYNC(val);
+
+ asm volatile("ldrsh %w0, [%1]" : "=r"(val) : "r"(MMIO_ADDR) : "memory");
+ GUEST_SYNC(val);
+
+ asm volatile("ldrsh %w0, [%1]" : "=r"(val) : "r"(MMIO_ADDR) : "memory");
+ GUEST_SYNC(val);
+
+ asm volatile("ldrsw %0, [%1]" : "=r"(val) : "r"(MMIO_ADDR) : "memory");
+ GUEST_SYNC(val);
+
+ asm volatile("ldrsw %0, [%1]" : "=r"(val) : "r"(MMIO_ADDR) : "memory");
+ GUEST_SYNC(val);
+
+ GUEST_DONE();
+}
+
+static void handle_mmio(struct kvm_run *run, const struct mmio_test *t)
+{
+ TEST_ASSERT_EQ(run->mmio.phys_addr, MMIO_ADDR);
+ TEST_ASSERT(!run->mmio.is_write, "Expected MMIO read for %s", t->name);
+ TEST_ASSERT_EQ(run->mmio.len, t->len);
+
+ memset(run->mmio.data, 0, sizeof(run->mmio.data));
+ /* Works because arm64 KVM hosts are always little-endian. */
+ memcpy(run->mmio.data, &t->data, t->len);
+}
+
+int main(void)
+{
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ struct ucall uc;
+ unsigned int i;
+
+ vm = vm_create_with_one_vcpu(&vcpu, guest_code);
+ virt_map(vm, MMIO_ADDR, MMIO_ADDR, 1);
+
+ ksft_print_header();
+ ksft_set_plan(ARRAY_SIZE(tests));
+
+ for (i = 0; i < ARRAY_SIZE(tests); i++) {
+ const struct mmio_test *t = &tests[i];
+
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_MMIO);
+
+ handle_mmio(vcpu->run, t);
+ vcpu_run(vcpu);
+
+ switch (get_ucall(vcpu, &uc)) {
+ case UCALL_SYNC:
+ TEST_ASSERT_EQ(uc.args[1], t->expected);
+ break;
+ case UCALL_ABORT:
+ REPORT_GUEST_ASSERT(uc);
+ break;
+ default:
+ TEST_FAIL("Unexpected ucall for %s", t->name);
+ }
+
+ ksft_test_result_pass("%s\n", t->name);
+ }
+
+ vcpu_run(vcpu);
+ TEST_ASSERT(get_ucall(vcpu, &uc) == UCALL_DONE, "Expected UCALL_DONE");
+
+ kvm_vm_free(vm);
+
+ ksft_finished();
+}
--
2.39.5
^ permalink raw reply related
* [PATCH 1/2] KVM: arm64: Fix sign-extension of MMIO loads
From: Fuad Tabba @ 2026-06-22 19:07 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, Steffen Eiden,
Catalin Marinas, Will Deacon, Shuah Khan, Christoffer Dall,
Victor Kamensky, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260622190701.2039766-1-fuad.tabba@linux.dev>
A sign-extending load from MMIO (LDRSB, LDRSH, LDRSW) delivers a
zero-extended value: in kvm_handle_mmio_return(), vcpu_data_host_to_guest()
masks the data to the access width after sign-extension, stripping the
sign bits.
Move vcpu_data_host_to_guest() ahead of sign-extension so the width mask
runs first. trace_kvm_mmio() moves with it and keeps reporting the raw
access-width data.
Fixes: b30070862edbd ("ARM64: KVM: MMIO support BE host running LE code")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
arch/arm64/kvm/mmio.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c
index e2285ed8c91de..d1c3a352d5a22 100644
--- a/arch/arm64/kvm/mmio.c
+++ b/arch/arm64/kvm/mmio.c
@@ -126,6 +126,10 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu)
len = kvm_vcpu_dabt_get_as(vcpu);
data = kvm_mmio_read_buf(run->mmio.data, len);
+ trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr,
+ &data);
+ data = vcpu_data_host_to_guest(vcpu, data, len);
+
if (kvm_vcpu_dabt_issext(vcpu) &&
len < sizeof(unsigned long)) {
mask = 1U << ((len * 8) - 1);
@@ -135,9 +139,6 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu)
if (!kvm_vcpu_dabt_issf(vcpu))
data = data & 0xffffffff;
- trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr,
- &data);
- data = vcpu_data_host_to_guest(vcpu, data, len);
vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data);
}
--
2.39.5
^ permalink raw reply related
* [PATCH 0/2] KVM: arm64: Fix and test MMIO sign-extending loads
From: Fuad Tabba @ 2026-06-22 19:06 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, Steffen Eiden,
Catalin Marinas, Will Deacon, Shuah Khan, Christoffer Dall,
Victor Kamensky, linux-arm-kernel, kvmarm, linux-kernel
Hi folks,
A sign-extending load (LDRSB/LDRSH/LDRSW) from emulated MMIO returns a
zero-extended value rather than the sign-extended one the architecture
requires; vcpu_data_host_to_guest() strips the sign bits when it masks
the data to the access width.
If my git archeology is right, the masking dates to 2014 (b30070862edbd,
big-endian support) and has been wrong ever since, but sign-extending
loads from device memory are rare enough that nobody hit it. Patch 1
fixes it; patch 2 adds a selftest so it doesn't regress.
Cheers,
/fuad
Fuad Tabba (2):
KVM: arm64: Fix sign-extension of MMIO loads
KVM: arm64: selftests: Add MMIO sign-extending load test
arch/arm64/kvm/mmio.c | 7 +-
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../selftests/kvm/arm64/mmio_sign_ext.c | 133 ++++++++++++++++++
3 files changed, 138 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/kvm/arm64/mmio_sign_ext.c
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
--
2.39.5
^ permalink raw reply
* Re: [PATCH 3/3] soc: samsung: exynos-pmu: fix error paths in cpuhotplug/idle states setup
From: Alexey Klimov @ 2026-06-22 18:57 UTC (permalink / raw)
To: Peter Griffin
Cc: Krzysztof Kozlowski, Alim Akhtar, Sam Protsenko,
linux-samsung-soc, linux-arm-kernel, linux-kernel, stable,
Sashiko
In-Reply-To: <CADrjBPqF6GPRLNUZtzkGUHTUQ6NOPoaRvVvF1mUUj_DJ9As1dg@mail.gmail.com>
Hi Peter,
On Thu Jun 11, 2026 at 8:07 AM BST, Peter Griffin wrote:
> Hi Alexey,
>
> On Wed, 10 Jun 2026 at 16:07, Alexey Klimov <alexey.klimov@linaro.org> wrote:
>>
>> On Wed Jun 10, 2026 at 2:34 PM BST, Peter Griffin wrote:
>> > Hi Alexey,
>>
>> Hi Peter,
>>
>> > Thanks for your patch!
>> >
>> > On Fri, 5 Jun 2026 at 21:19, Alexey Klimov <alexey.klimov@linaro.org> wrote:
>> >>
>> >> The setup_cpuhp_and_cpuidle() initialisation sequence currently ignores
>> >> the return values of cpuhp_setup_state(), cpu_pm_register_notifier(), and
>> >> register_reboot_notifier(). If any of these registrations fail during
>> >> probe() routine, the driver returns 0, leaving the driver partially
>> >> configured.
>> >
>> > I originally made the failure non-fatal because the system still boots
>> > without the notifiers registered (and all other Arm64 Exynos SoCs
>> > upstream don't register notifiers and AFAICT have broken cpu hotplug
>> > and cpu idle).
>> >
>> > In hindsight, that seems like a mistake. I think your patch to fully
>> > unwind everything in case of failure makes more sense. See small
>> > comment below about destroy_cpuhp_and_cpuidle()
>>
>> Wait, setup_cpuhp_and_cpuidle() should be non-fatal and shouldn't
>> return any errors?
>
> I suggest you re-read my above comment above ^^
Could you please clarify what specifically addresses my question about
notifiers?
Looking further into this, it seems that, for instance, if one of the
hotplug states fails to register then tracking of pmu_context->in_cpuhp
becomes broken.
If reboot notifier silently fails to be registered, then it is unclear how
this from gs101_cpu_pmu_offline() supposed to work:
/* Ignore CPU_PM_ENTER event in reboot or suspend sequence. */
if (pmu_context->sys_insuspend || pmu_context->sys_inreboot) {
raw_spin_unlock(&pmu_context->cpupm_lock);
return NOTIFY_OK;
}
If c2 idles are used during reboot/shutdown then they fail or what?
I am not saying that patch is correct and some rework is needed but I don't
get why we should completely ignore errors from hotplug states registration
and should not check registration of notifiers. At least warning should be
shown to user that pm functionality might be unreliable.
Best regards,
Alexey.
^ permalink raw reply
* [linusw-nomadik:ux500-power-domains-v7.1] BUILD REGRESSION 10278e18bc5a61397cb538310a6388075a4f21dd
From: kernel test robot @ 2026-06-22 18:42 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-power-domains-v7.1
branch HEAD: 10278e18bc5a61397cb538310a6388075a4f21dd ARM: dts: ux500: Remove DB8500 EPOD regulators
Error/Warning (recently discovered and may have been fixed):
https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com
include/linux/mfd/dbx500-prcmu.h:408:19: error: redefinition of 'prcmu_abb_read'
include/linux/mfd/dbx500-prcmu.h:413:19: error: redefinition of 'prcmu_abb_write'
include/linux/mfd/dbx500-prcmu.h:424:19: error: redefinition of 'prcmu_config_clkout'
include/linux/mfd/dbx500-prcmu.h:486:19: error: redefinition of 'prcmu_ac_wake_req'
include/linux/mfd/dbx500-prcmu.h:491:20: error: redefinition of 'prcmu_ac_sleep_req'
Error/Warning ids grouped by kconfigs:
recent_errors
|-- arc-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- arc-allyesconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- arm-randconfig-004-20260622
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- arm64-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- i386-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- i386-allyesconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- loongarch-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- loongarch-randconfig-001-20260622
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- loongarch-randconfig-002-20260622
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- mips-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- mips-allyesconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- powerpc-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- powerpc-randconfig-002-20260622
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- powerpc64-randconfig-001-20260622
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- riscv-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- riscv-allyesconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- sh-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- sh-allyesconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- sparc64-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- um-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- um-allyesconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- x86_64-allmodconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- x86_64-allyesconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
|-- xtensa-allyesconfig
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
| |-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
| `-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
`-- xtensa-randconfig-001-20260622
|-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_read
|-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_abb_write
|-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_sleep_req
|-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_ac_wake_req
`-- include-linux-mfd-dbx500-prcmu.h:error:redefinition-of-prcmu_config_clkout
elapsed time: 952m
configs tested: 148
configs skipped: 2
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260622 gcc-15.2.0
arc randconfig-002-20260622 gcc-9.5.0
arm allnoconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig clang-23
arm randconfig-001-20260622 gcc-13.4.0
arm randconfig-002-20260622 clang-23
arm randconfig-003-20260622 gcc-8.5.0
arm randconfig-004-20260622 gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260622 gcc-8.5.0
arm64 randconfig-002-20260622 gcc-13.4.0
arm64 randconfig-003-20260622 gcc-8.5.0
arm64 randconfig-004-20260622 clang-22
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260622 gcc-13.4.0
csky randconfig-002-20260622 gcc-11.5.0
hexagon allmodconfig clang-23
hexagon allnoconfig clang-23
hexagon defconfig clang-23
hexagon randconfig-001-20260622 clang-23
hexagon randconfig-002-20260622 clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260622 gcc-14
i386 buildonly-randconfig-002-20260622 clang-22
i386 buildonly-randconfig-003-20260622 gcc-14
i386 buildonly-randconfig-004-20260622 gcc-12
i386 buildonly-randconfig-005-20260622 gcc-14
i386 buildonly-randconfig-006-20260622 gcc-14
i386 defconfig clang-22
i386 randconfig-011-20260622 gcc-14
i386 randconfig-012-20260622 clang-22
i386 randconfig-013-20260622 gcc-14
i386 randconfig-014-20260622 clang-22
i386 randconfig-015-20260622 clang-22
i386 randconfig-016-20260622 clang-22
i386 randconfig-017-20260622 clang-22
loongarch allmodconfig clang-19
loongarch allnoconfig clang-20
loongarch defconfig clang-23
loongarch randconfig-001-20260622 clang-18
loongarch randconfig-002-20260622 clang-18
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig gcc-16.1.0
m68k defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260622 gcc-8.5.0
nios2 randconfig-002-20260622 gcc-8.5.0
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig gcc-16.1.0
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260622 gcc-14.3.0
parisc randconfig-002-20260622 gcc-12.5.0
parisc64 defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig gcc-16.1.0
powerpc randconfig-001-20260622 gcc-8.5.0
powerpc randconfig-002-20260622 gcc-8.5.0
powerpc64 randconfig-001-20260622 clang-21
powerpc64 randconfig-002-20260622 clang-20
riscv allmodconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig clang-23
riscv randconfig-001-20260622 clang-23
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig clang-18
s390 randconfig-001-20260622 gcc-14.3.0
s390 randconfig-002-20260622 clang-23
sh allmodconfig gcc-16.1.0
sh allnoconfig gcc-16.1.0
sh allyesconfig gcc-16.1.0
sh defconfig gcc-16.1.0
sh randconfig-001-20260622 gcc-13.4.0
sh randconfig-002-20260622 gcc-15.2.0
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-16.1.0
sparc randconfig-001-20260622 gcc-16.1.0
sparc randconfig-002 gcc-11.5.0
sparc randconfig-002-20260622 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig clang-23
sparc64 randconfig-001 gcc-12.5.0
sparc64 randconfig-001-20260622 gcc-16.1.0
sparc64 randconfig-002 clang-20
sparc64 randconfig-002-20260622 clang-23
um allmodconfig clang-23
um allnoconfig clang-16
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001 clang-23
um randconfig-001-20260622 gcc-14
um randconfig-002 clang-23
um randconfig-002-20260622 gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260622 clang-22
x86_64 buildonly-randconfig-002-20260622 clang-22
x86_64 buildonly-randconfig-003-20260622 clang-22
x86_64 buildonly-randconfig-004-20260622 clang-22
x86_64 buildonly-randconfig-005-20260622 gcc-14
x86_64 buildonly-randconfig-006-20260622 clang-22
x86_64 defconfig gcc-14
x86_64 randconfig-002-20260622 gcc-14
x86_64 randconfig-011-20260622 clang-22
x86_64 randconfig-012-20260622 clang-22
x86_64 randconfig-013-20260622 gcc-14
x86_64 randconfig-014-20260622 gcc-14
x86_64 randconfig-015-20260622 clang-22
x86_64 randconfig-016-20260622 clang-22
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig gcc-16.1.0
xtensa randconfig-001 gcc-8.5.0
xtensa randconfig-001-20260622 gcc-16.1.0
xtensa randconfig-002 gcc-13.4.0
xtensa randconfig-002-20260622 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH RFC v8 01/24] mm: Introduce kpkeys
From: David Hildenbrand (Arm) @ 2026-06-22 18:38 UTC (permalink / raw)
To: Linus Walleij
Cc: Kevin Brodsky, linux-hardening, Andrew Morton, Andy Lutomirski,
Catalin Marinas, Dave Hansen, Ira Weiny, Jann Horn, Jeff Xu,
Joey Gouly, Kees Cook, Marc Zyngier, Mark Brown, Matthew Wilcox,
Maxwell Bland, Mike Rapoport (IBM), Peter Zijlstra,
Pierre Langlois, Quentin Perret, Rick Edgecombe, Ryan Roberts,
Vlastimil Babka, Will Deacon, Yang Shi, Yeoreum Yun,
linux-arm-kernel, linux-mm, x86, Lorenzo Stoakes, Thomas Gleixner
In-Reply-To: <CAD++jL=km9hqTuTMFUhyx_QPuMEwWqmnUVQtPtMXnp8paHH1_A@mail.gmail.com>
On 6/18/26 15:22, Linus Walleij wrote:
> On Tue, Jun 16, 2026 at 5:19 PM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>
>> Looking at this, and wondering about "why do we get registers involved in this
>> API" I would probably have an interface like:
>>
>> arch_kpkeys_enter_context()
>> arch_kpkeys_leave_context()
>>
>> Whereby you return a "struct kpkeys_state" or sth like that.
>
> This is close to what I was looking for as well.
Cool :)
>
> enter/leave makes the code look more like generic entry.
>
> Passing some kind of state cookie around is inevitable in
> this design and IIUC Kevin argued that it would be inefficient
> (another level of abstraction) as opposed to just hammering
> in the context we want, where we want it.
>
> But I think the compiler will optimize that out by constant
> propagation if the backing architecture implementation is
> simple.
Yes, it should be wrapped somehow. I don't think this will be a problem
performance-wise that cannot be solved differently.
Returning an u64 ("register") here is really arm64-sepcific and should be
abstracted.
--
Cheers,
David
^ permalink raw reply
* [GIT PULL] Mailbox changes for v7.2
From: Jassi Brar @ 2026-06-22 18:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, linux-arm-kernel
Hi Linus,
The following changes since commit 5200f5f493f79f14bbdc349e402a40dfb32f23c8:
Linux 7.1-rc4 (2026-05-17 13:59:58 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox.git
tags/mailbox-v7.2
for you to fetch changes up to 36cac4b5101f8ecbc851356df175b99543c84ec6:
mailbox: imx: Don't force-thread the primary handler (2026-06-20
21:18:39 -0500)
----------------------------------------------------------------
mailbox: updates for v7.2
- core: add debugfs support for used channels, fix resource leak on
startup failure, propagate tx error codes, and clarify blocking mode
thread support
- exynos: remove unused register definitions
- imx: refactor IRQ handlers, migrate to devm helpers, and other minor
improvements
- mpfs: fix syscon presence check in inbox ISR
- mtk-adsp: fix use-after-free during device teardown
- qcom: add dt-bindings for QCOM Maili, Hawi, Shikra APCS, and Nord
CPUCP platform support
----------------------------------------------------------------
Chunkai Deng (1):
dt-bindings: mailbox: qcom: Add IPCC support for Maili Platform
Conor Dooley (1):
mailbox: mpfs: fix check for syscon presence in mpfs_mbox_inbox_isr()
Deepti Jaggi (2):
dt-bindings: mailbox: qcom: Document Nord CPUCP mailbox controller
mailbox: qcom-cpucp: Add support for Nord CPUCP mailbox controller
Joonwon Kang (2):
mailbox: Clarify multi-thread is not supported in blocking mode
mailbox: Make mbox_send_message() return error code when tx fails
Komal Bajaj (1):
dt-bindings: mailbox: qcom: Add Shikra APCS compatible
Krzysztof Kozlowski (1):
mailbox: qcom: Unify user-visible "Qualcomm" name
Mukesh Ojha (2):
dt-bindings: mailbox: qcom,cpucp-mbox: Add Hawi compatible
dt-bindings: mailbox: qcom: Add IPCC support for Hawi Platform
Sebastian Andrzej Siewior (9):
mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
mailbox: imx: Add a channel shutdown field
mailbox: imx: Use devm_pm_runtime_enable()
mailbox: imx: use devm_of_platform_populate()
mailbox: imx: Use channel index instead of zero in imx_mu_specific_rx()
mailbox: imx: Start splitting the IRQ handler in primary and
threaded handler
mailbox: imx: Move the RX part of the mailbox into the threaded handler
mailbox: imx: Move the RXDB part of the mailbox into the threaded handler
mailbox: imx: Don't force-thread the primary handler
Sergey Senozhatsky (1):
mailbox: mtk-adsp: fix UAF during device teardown
Tudor Ambarus (1):
mailbox: exynos: Drop unused register definitions
Wolfram Sang (2):
mailbox: don't free the channel if the startup callback failed
mailbox: add list of used channels to debugfs
.../bindings/mailbox/qcom,apcs-kpss-global.yaml | 1 +
.../bindings/mailbox/qcom,cpucp-mbox.yaml | 2 +
.../devicetree/bindings/mailbox/qcom-ipcc.yaml | 2 +
drivers/mailbox/Kconfig | 4 +-
drivers/mailbox/exynos-mailbox.c | 7 --
drivers/mailbox/imx-mailbox.c | 117 +++++++++++++++------
drivers/mailbox/mailbox-mpfs.c | 2 +-
drivers/mailbox/mailbox.c | 101 +++++++++++++++---
drivers/mailbox/mtk-adsp-mailbox.c | 9 +-
drivers/mailbox/qcom-cpucp-mbox.c | 35 +++++-
include/linux/mailbox_controller.h | 2 +
11 files changed, 224 insertions(+), 58 deletions(-)
^ permalink raw reply
* Re: [PATCH] arm64: mm: Defer read-only remap of data/bss linear alias
From: Fuad Tabba @ 2026-06-22 18:13 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, catalin.marinas, will,
Ard Biesheuvel
In-Reply-To: <20260619163940.3185308-2-ardb+git@google.com>
On Fri, 19 Jun 2026 at 17:40, Ard Biesheuvel <ardb+git@google.com> wrote:
>
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Fuad reports that in some cases, the KVM init code may apply relocations
> to variables that reside in .data, and does so via the linear map. This
> means that remapping .data read-only beforehand is a bad idea, and
> results in an early boot crash.
>
> These variables in .data are only present when CONFIG_NVHE_EL2_DEBUG or
> CONFIG_NVHE_EL2_TRACING are enabled, which is why it was not spotted in
> testing.
>
> So move the remap to mark_rodata_ro(), which is a reasonable place to
> put this, and ensures that it happens much later during the boot. It
> also means that rodata=off is now taken into account, and so the linear
> alias will remain writable in that case.
>
> Cc: Fuad Tabba <fuad.tabba@linux.dev>
> Fixes: f2ba877402e5 ("arm64: mm: Map the kernel data/bss read-only in the linear map")
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
This fixes it, and the changes look good to me, thanks.
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Tested-by: Fuad Tabba < fuad.tabba@linux.dev>
Cheers,
/fuad
> arch/arm64/mm/mmu.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 9f354971b7e4..1f7eca86b5c1 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1198,11 +1198,6 @@ static void __init map_mem(void)
> __map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
> flags);
> }
> -
> - /* Map the kernel data/bss read-only in the linear map */
> - __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
> - flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
> - (unsigned long)lm_alias(__bss_stop));
> }
>
> void mark_rodata_ro(void)
> @@ -1221,6 +1216,12 @@ void mark_rodata_ro(void)
> update_mapping_prot(__pa_symbol(_text), (unsigned long)_text,
> (unsigned long)_stext - (unsigned long)_text,
> PAGE_KERNEL_RO);
> +
> + /* Map the kernel data/bss read-only in the linear map */
> + update_mapping_prot(__pa_symbol(__init_end),
> + (unsigned long)lm_alias(__init_end),
> + (unsigned long)__bss_stop - (unsigned long)__init_end,
> + PAGE_KERNEL_RO);
> }
>
> static void __init declare_vma(struct vm_struct *vma,
> --
> 2.55.0.rc0.738.g0c8ab3ebcc-goog
>
^ permalink raw reply
* [PATCH v2] phy: Add USB3 PHY support to Google Tensor SoC USB PHY driver
From: RD Babiera @ 2026-06-22 17:52 UTC (permalink / raw)
To: vkoul, peter.griffin, andre.draszik, tudor.ambarus, p.zabel,
neil.armstrong
Cc: badhri, linux-arm-kernel, linux-samsung-soc, linux-phy,
linux-kernel, RD Babiera
Add USB3 PHY support for the Google Tensor G5 USB PHY driver.
This patch adds functionality for the usb3_tca register, usb3 clock,
and usb3 reset as defined in google,lga-usb-phy.yaml. Kconfig now lists
USB SuperSpeed support.
Refactor the probe sequence to initialize the USB2 and USB3 PHYs, and then
initialize clocks and resets for both PHYs afterwards.
Refactor set_vbus_valid to reduce duplicated code.
Implement USB3 phy_ops for phy_init, phy_exit, and phy_power_on.
combo_phy_state enum is added to track PHY bringup state across
PHY API calls.
Signed-off-by: RD Babiera <rdbabiera@google.com>
---
Changes since v1:
* Removed mix of goto-based and scope-based cleanup from usb3 phy_init
* Removed unused usb3_core resource from probe
* Added combo_phy_state enum to interally track ComboPHY bringup state
to allow google_usb_set_orientation() to change TCA orientation.
* Modify Kconfig documentation to reflect SuperSpeed support
---
drivers/phy/Kconfig | 2 +-
drivers/phy/phy-google-usb.c | 379 +++++++++++++++++++++++++++++++----
2 files changed, 346 insertions(+), 35 deletions(-)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 19f3b7d12b7d..d2d401129af7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -100,7 +100,7 @@ config PHY_GOOGLE_USB
the G5 generation (Laguna). This driver provides the PHY interfaces
to interact with the SNPS eUSB2 and USB 3.2/DisplayPort Combo PHY,
both of which are integrated with the DWC3 USB DRD controller.
- This driver currently supports USB high-speed.
+ This driver currently supports USB high-speed and SuperSpeed.
config USB_LGM_PHY
tristate "INTEL Lightning Mountain USB PHY Driver"
diff --git a/drivers/phy/phy-google-usb.c b/drivers/phy/phy-google-usb.c
index ab20bc20f19e..c6f4d8283e7c 100644
--- a/drivers/phy/phy-google-usb.c
+++ b/drivers/phy/phy-google-usb.c
@@ -20,6 +20,7 @@
#include <linux/reset.h>
#include <linux/usb/typec_mux.h>
+/* USB_CFG_CSR */
#define USBCS_USB2PHY_CFG19_OFFSET 0x0
#define USBCS_USB2PHY_CFG19_PHY_CFG_PLL_FB_DIV GENMASK(19, 8)
@@ -28,11 +29,41 @@
#define USBCS_USB2PHY_CFG21_REF_FREQ_SEL GENMASK(15, 13)
#define USBCS_USB2PHY_CFG21_PHY_TX_DIG_BYPASS_SEL BIT(19)
+/* USBDP_TOP */
#define USBCS_PHY_CFG1_OFFSET 0x28
+#define USBCS_PHY_CFG1_PHY0_MPLLA_SSC_EN BIT(1)
+#define USBCS_PHY_CFG1_PHY0_SRAM_BYPASS_MODE GENMASK(11, 10)
+#define SRAM_BYPASS_MODE_BYPASS_FIRMWARE BIT(0)
+#define SRAM_BYPASS_MODE_BYPASS_CONTEXT BIT(1)
#define USBCS_PHY_CFG1_SYS_VBUSVALID BIT(17)
+#define USBDP_TOP_CFG_REG_OFFSET 0x44
+#define USBDP_TOP_CFG_REG_PMGT_REF_CLK_REQ_N BIT(0)
+
+#define PHY_POWER_CONFIG_REG1_OFFSET 0x48
+#define PHY_POWER_CONFIG_REG1_PG_MODE_EN BIT(1)
+#define PHY_POWER_CONFIG_REG1_UPCS_PIPE_CONFIG GENMASK(31, 14)
+#define UPCS_PIPE_CONFIG_ISO_CPM BIT(5)
+#define UPCS_PIPE_CONFIG_PG_MODE_STATIC BIT(6)
+#define UPCS_PIPE_CONFIG_LANE_RESET_NO_PG_EXIT BIT(9)
+
+/* USB3_TCA */
+#define TCA_INTR_STS_OFFSET 0x8
+#define TCA_INTR_STS_XA_ACT_EVT BIT(0)
+#define TCA_TCPC_OFFSET 0x14
+#define TCA_TCPC_MUX_CONTROL GENMASK(2, 0)
+#define TCA_TCPC_MUX_CONTROL_USB_ONLY 0x1
+#define TCA_TCPC_CONNECTOR_ORIENTATION BIT(3)
+#define TCA_TCPC_VALID BIT(4)
+#define TCA_PSTATE_0_OFFSET 0x50
+#define TCA_PSTATE_0_UPCS_LANE0_PHYSTATUS BIT(8)
+
+#define GPHY_TCA_DELAY_US 10
+#define GPHY_TCA_TIMEOUT_US 2500000
+
enum google_usb_phy_id {
GOOGLE_USB2_PHY,
+ GOOGLE_USB3_PHY,
GOOGLE_USB_PHY_NUM,
};
@@ -46,34 +77,152 @@ struct google_usb_phy_instance {
struct reset_control_bulk_data *rsts;
};
+struct google_usb_phy_config {
+ const char * const *clk_names;
+ unsigned int num_clks;
+ const char * const *rst_names;
+ unsigned int num_rsts;
+};
+
+static const char * const u2phy_clk_names[] = {
+ "usb2",
+ "usb2_apb",
+};
+static const char * const u3phy_clk_names[] = {
+ "usb3"
+};
+static const char * const u2phy_rst_names[] = {
+ "usb2",
+ "usb2_apb",
+};
+static const char * const u3phy_rst_names[] = {
+ "usb3"
+};
+
+static const struct google_usb_phy_config phy_configs[GOOGLE_USB_PHY_NUM] = {
+ [GOOGLE_USB2_PHY] = {
+ .clk_names = u2phy_clk_names,
+ .num_clks = ARRAY_SIZE(u2phy_clk_names),
+ .rst_names = u2phy_rst_names,
+ .num_rsts = ARRAY_SIZE(u2phy_rst_names),
+ },
+ [GOOGLE_USB3_PHY] = {
+ .clk_names = u3phy_clk_names,
+ .num_clks = ARRAY_SIZE(u3phy_clk_names),
+ .rst_names = u3phy_rst_names,
+ .num_rsts = ARRAY_SIZE(u3phy_rst_names),
+ },
+};
+
+/*
+ * combo_phy_state
+ * COMBO_PHY_IDLE: The ComboPHY has been torn down and USB3 has not completed
+ * bringup
+ * COMBO_PHY_INIT_DONE: The ComboPHY bringup sequence is complete.
+ * COMBO_PHY_TCA_READY: The PoR => NC transition is complete, and the TCA can be
+ * moved into USB.
+ */
+enum combo_phy_state {
+ COMBO_PHY_IDLE,
+ COMBO_PHY_INIT_DONE,
+ COMBO_PHY_TCA_READY,
+};
+
struct google_usb_phy {
struct device *dev;
struct regmap *usb_cfg_regmap;
unsigned int usb2_cfg_offset;
void __iomem *usbdp_top_base;
+ void __iomem *usb3_tca_base;
struct google_usb_phy_instance *insts;
/*
* Protect phy registers from concurrent access, specifically via
- * google_usb_set_orientation callback.
+ * google_usb_set_orientation callback. phy_mutex also protects
+ * concurrent access to phy_state.
*/
struct mutex phy_mutex;
struct typec_switch_dev *sw;
enum typec_orientation orientation;
+ enum combo_phy_state phy_state;
};
static void set_vbus_valid(struct google_usb_phy *gphy)
{
u32 reg;
- if (gphy->orientation == TYPEC_ORIENTATION_NONE) {
- reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ if (gphy->orientation == TYPEC_ORIENTATION_NONE)
reg &= ~USBCS_PHY_CFG1_SYS_VBUSVALID;
- writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
- } else {
- reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ else
reg |= USBCS_PHY_CFG1_SYS_VBUSVALID;
- writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
- }
+ writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+}
+
+static void set_sram_bypass(struct google_usb_phy *gphy, u32 bypass)
+{
+ u32 reg;
+
+ reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ reg &= ~USBCS_PHY_CFG1_PHY0_SRAM_BYPASS_MODE;
+ reg |= FIELD_PREP(USBCS_PHY_CFG1_PHY0_SRAM_BYPASS_MODE, bypass);
+ writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+}
+
+static void set_pmgt_ref_clk_req_n(struct google_usb_phy *gphy, bool resume)
+{
+ u32 reg;
+
+ reg = readl(gphy->usbdp_top_base + USBDP_TOP_CFG_REG_OFFSET);
+ if (resume)
+ reg |= USBDP_TOP_CFG_REG_PMGT_REF_CLK_REQ_N;
+ else
+ reg &= ~USBDP_TOP_CFG_REG_PMGT_REF_CLK_REQ_N;
+ writel(reg, gphy->usbdp_top_base + USBDP_TOP_CFG_REG_OFFSET);
+}
+
+static int wait_tca_xa_ack(struct google_usb_phy *gphy)
+{
+ int ret;
+ u32 reg;
+
+ ret = readl_poll_timeout(gphy->usb3_tca_base + TCA_INTR_STS_OFFSET,
+ reg, !!(reg & TCA_INTR_STS_XA_ACT_EVT),
+ GPHY_TCA_DELAY_US, GPHY_TCA_TIMEOUT_US);
+ if (ret)
+ dev_err(gphy->dev, "tca xa_ack timeout, ret=%d", ret);
+
+ return ret;
+}
+
+static int program_tca_locked(struct google_usb_phy *gphy)
+ __must_hold(&gphy->phy_mutex)
+{
+ int ret;
+ u32 reg;
+
+ reg = readl(gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+ writel(reg, gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+
+ reg = readl(gphy->usb3_tca_base + TCA_TCPC_OFFSET);
+ reg &= ~TCA_TCPC_MUX_CONTROL;
+ reg |= FIELD_PREP(TCA_TCPC_MUX_CONTROL, TCA_TCPC_MUX_CONTROL_USB_ONLY);
+ if (gphy->orientation == TYPEC_ORIENTATION_REVERSE)
+ reg |= TCA_TCPC_CONNECTOR_ORIENTATION;
+ else
+ reg &= ~TCA_TCPC_CONNECTOR_ORIENTATION;
+ reg |= TCA_TCPC_VALID;
+ writel(reg, gphy->usb3_tca_base + TCA_TCPC_OFFSET);
+
+ ret = wait_tca_xa_ack(gphy);
+ dev_dbg(gphy->dev, "TCA switch %s, mux %lu, orientation %s",
+ ret ? "failed" : "success",
+ FIELD_GET(TCA_TCPC_MUX_CONTROL, reg),
+ FIELD_GET(TCA_TCPC_CONNECTOR_ORIENTATION, reg) ? "reverse" : "normal");
+
+ reg = readl(gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+ writel(reg, gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+
+ return ret;
}
static int google_usb_set_orientation(struct typec_switch_dev *sw,
@@ -92,6 +241,9 @@ static int google_usb_set_orientation(struct typec_switch_dev *sw,
set_vbus_valid(gphy);
+ if (gphy->phy_state == COMBO_PHY_TCA_READY && orientation != TYPEC_ORIENTATION_NONE)
+ return program_tca_locked(gphy);
+
return 0;
}
@@ -161,6 +313,118 @@ static const struct phy_ops google_usb2_phy_ops = {
.exit = google_usb2_phy_exit,
};
+static int google_usb3_phy_init(struct phy *_phy)
+{
+ struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
+ struct google_usb_phy *gphy = inst->parent;
+ int ret = 0;
+ u32 reg;
+
+ dev_dbg(gphy->dev, "initializing usb3 phy\n");
+
+ guard(mutex)(&gphy->phy_mutex);
+
+ if (gphy->phy_state != COMBO_PHY_IDLE) {
+ dev_warn(gphy->dev, "usb3 phy init called when combo phy state is not idle");
+ return 0;
+ }
+
+ reg = readl(gphy->usbdp_top_base + PHY_POWER_CONFIG_REG1_OFFSET);
+ reg |= PHY_POWER_CONFIG_REG1_PG_MODE_EN;
+ reg &= ~PHY_POWER_CONFIG_REG1_UPCS_PIPE_CONFIG;
+ reg |= FIELD_PREP(PHY_POWER_CONFIG_REG1_UPCS_PIPE_CONFIG,
+ (UPCS_PIPE_CONFIG_ISO_CPM |
+ UPCS_PIPE_CONFIG_PG_MODE_STATIC |
+ UPCS_PIPE_CONFIG_LANE_RESET_NO_PG_EXIT));
+ writel(reg, gphy->usbdp_top_base + PHY_POWER_CONFIG_REG1_OFFSET);
+
+ set_vbus_valid(gphy);
+
+ reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ reg |= USBCS_PHY_CFG1_PHY0_MPLLA_SSC_EN;
+ writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+
+ set_sram_bypass(gphy, SRAM_BYPASS_MODE_BYPASS_FIRMWARE |
+ SRAM_BYPASS_MODE_BYPASS_CONTEXT);
+ set_pmgt_ref_clk_req_n(gphy, true);
+
+ ret = clk_bulk_prepare_enable(inst->num_clks, inst->clks);
+ if (ret)
+ return ret;
+
+ ret = reset_control_bulk_deassert(inst->num_rsts, inst->rsts);
+ if (ret) {
+ clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
+ return ret;
+ }
+
+ ret = readl_poll_timeout(gphy->usb3_tca_base + TCA_PSTATE_0_OFFSET,
+ reg, !(reg & TCA_PSTATE_0_UPCS_LANE0_PHYSTATUS),
+ GPHY_TCA_DELAY_US, GPHY_TCA_TIMEOUT_US);
+ if (ret) {
+ dev_err(gphy->dev, "wait for lane0 phystatus timed out");
+ reset_control_bulk_assert(inst->num_rsts, inst->rsts);
+ clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
+ return ret;
+ }
+
+ gphy->phy_state = COMBO_PHY_INIT_DONE;
+
+ return 0;
+}
+
+static int google_usb3_phy_exit(struct phy *_phy)
+{
+ struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
+ struct google_usb_phy *gphy = inst->parent;
+
+ dev_dbg(gphy->dev, "exiting usb3 phy\n");
+
+ guard(mutex)(&gphy->phy_mutex);
+
+ set_pmgt_ref_clk_req_n(gphy, false);
+ reset_control_bulk_assert(inst->num_rsts, inst->rsts);
+ clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
+
+ gphy->phy_state = COMBO_PHY_IDLE;
+
+ return 0;
+}
+
+static int google_usb3_phy_power_on(struct phy *_phy)
+{
+ struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
+ struct google_usb_phy *gphy = inst->parent;
+ int ret;
+
+ dev_dbg(gphy->dev, "power on usb3 phy\n");
+
+ guard(mutex)(&gphy->phy_mutex);
+
+ if (gphy->phy_state == COMBO_PHY_TCA_READY) {
+ dev_warn(gphy->dev, "usb3 phy already powered on");
+ return 0;
+ }
+
+ ret = wait_tca_xa_ack(gphy);
+ if (ret) {
+ dev_err(gphy->dev, "PoR->NC transition timeout");
+ return ret;
+ }
+
+ gphy->phy_state = COMBO_PHY_TCA_READY;
+
+ ret = program_tca_locked(gphy);
+
+ return ret;
+}
+
+static const struct phy_ops google_usb3_phy_ops = {
+ .init = google_usb3_phy_init,
+ .exit = google_usb3_phy_exit,
+ .power_on = google_usb3_phy_power_on,
+};
+
static struct phy *google_usb_phy_xlate(struct device *dev,
const struct of_phandle_args *args)
{
@@ -173,14 +437,61 @@ static struct phy *google_usb_phy_xlate(struct device *dev,
return gphy->insts[args->args[0]].phy;
}
+static int google_usb_phy_parse_clocks(struct google_usb_phy *gphy)
+{
+ struct device *dev = gphy->dev;
+ int id, i, ret;
+
+ for (id = 0; id < GOOGLE_USB_PHY_NUM; id++) {
+ const struct google_usb_phy_config *cfg = &phy_configs[id];
+ struct google_usb_phy_instance *inst = &gphy->insts[id];
+
+ inst->num_clks = cfg->num_clks;
+ inst->clks = devm_kcalloc(dev, inst->num_clks, sizeof(*inst->clks), GFP_KERNEL);
+ if (!inst->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < inst->num_clks; i++)
+ inst->clks[i].id = cfg->clk_names[i];
+
+ ret = devm_clk_bulk_get(dev, inst->num_clks, inst->clks);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get phy%d clks\n", id);
+ }
+
+ return 0;
+}
+
+static int google_usb_phy_parse_resets(struct google_usb_phy *gphy)
+{
+ struct device *dev = gphy->dev;
+ int id, i, ret;
+
+ for (id = 0; id < GOOGLE_USB_PHY_NUM; id++) {
+ const struct google_usb_phy_config *cfg = &phy_configs[id];
+ struct google_usb_phy_instance *inst = &gphy->insts[id];
+
+ inst->num_rsts = cfg->num_rsts;
+ inst->rsts = devm_kcalloc(dev, inst->num_rsts, sizeof(*inst->rsts), GFP_KERNEL);
+ if (!inst->rsts)
+ return -ENOMEM;
+
+ for (i = 0; i < inst->num_rsts; i++)
+ inst->rsts[i].id = cfg->rst_names[i];
+ ret = devm_reset_control_bulk_get_exclusive(dev, inst->num_rsts, inst->rsts);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get phy%d resets\n", id);
+ }
+
+ return 0;
+}
+
static int google_usb_phy_probe(struct platform_device *pdev)
{
struct typec_switch_desc sw_desc = { };
- struct google_usb_phy_instance *inst;
struct phy_provider *phy_provider;
struct device *dev = &pdev->dev;
struct google_usb_phy *gphy;
- struct phy *phy;
u32 args[1];
int ret;
@@ -212,39 +523,39 @@ static int google_usb_phy_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(gphy->usbdp_top_base),
"invalid usbdp top\n");
+ gphy->usb3_tca_base = devm_platform_ioremap_resource_byname(pdev,
+ "usb3_tca");
+ if (IS_ERR(gphy->usb3_tca_base))
+ return dev_err_probe(dev, PTR_ERR(gphy->usb3_tca_base),
+ "invalid usb3 tca\n");
+
gphy->insts = devm_kcalloc(dev, GOOGLE_USB_PHY_NUM, sizeof(*gphy->insts), GFP_KERNEL);
if (!gphy->insts)
return -ENOMEM;
- inst = &gphy->insts[GOOGLE_USB2_PHY];
- inst->parent = gphy;
- inst->index = GOOGLE_USB2_PHY;
- phy = devm_phy_create(dev, NULL, &google_usb2_phy_ops);
- if (IS_ERR(phy))
- return dev_err_probe(dev, PTR_ERR(phy),
+ gphy->insts[GOOGLE_USB2_PHY].phy = devm_phy_create(dev, NULL, &google_usb2_phy_ops);
+ gphy->insts[GOOGLE_USB2_PHY].index = GOOGLE_USB2_PHY;
+ gphy->insts[GOOGLE_USB2_PHY].parent = gphy;
+ if (IS_ERR(gphy->insts[GOOGLE_USB2_PHY].phy))
+ return dev_err_probe(dev, PTR_ERR(gphy->insts[GOOGLE_USB2_PHY].phy),
"failed to create usb2 phy instance\n");
- inst->phy = phy;
- phy_set_drvdata(phy, inst);
+ phy_set_drvdata(gphy->insts[GOOGLE_USB2_PHY].phy, &gphy->insts[GOOGLE_USB2_PHY]);
- inst->num_clks = 2;
- inst->clks = devm_kcalloc(dev, inst->num_clks, sizeof(*inst->clks), GFP_KERNEL);
- if (!inst->clks)
- return -ENOMEM;
- inst->clks[0].id = "usb2";
- inst->clks[1].id = "usb2_apb";
- ret = devm_clk_bulk_get(dev, inst->num_clks, inst->clks);
+ gphy->insts[GOOGLE_USB3_PHY].phy = devm_phy_create(dev, NULL, &google_usb3_phy_ops);
+ gphy->insts[GOOGLE_USB3_PHY].index = GOOGLE_USB3_PHY;
+ gphy->insts[GOOGLE_USB3_PHY].parent = gphy;
+ if (IS_ERR(gphy->insts[GOOGLE_USB3_PHY].phy))
+ return dev_err_probe(dev, PTR_ERR(gphy->insts[GOOGLE_USB3_PHY].phy),
+ "failed to create usb3 phy instance\n");
+ phy_set_drvdata(gphy->insts[GOOGLE_USB3_PHY].phy, &gphy->insts[GOOGLE_USB3_PHY]);
+
+ ret = google_usb_phy_parse_clocks(gphy);
if (ret)
- return dev_err_probe(dev, ret, "failed to get u2 phy clks\n");
+ return ret;
- inst->num_rsts = 2;
- inst->rsts = devm_kcalloc(dev, inst->num_rsts, sizeof(*inst->rsts), GFP_KERNEL);
- if (!inst->rsts)
- return -ENOMEM;
- inst->rsts[0].id = "usb2";
- inst->rsts[1].id = "usb2_apb";
- ret = devm_reset_control_bulk_get_exclusive(dev, inst->num_rsts, inst->rsts);
+ ret = google_usb_phy_parse_resets(gphy);
if (ret)
- return dev_err_probe(dev, ret, "failed to get u2 phy resets\n");
+ return ret;
phy_provider = devm_of_phy_provider_register(dev, google_usb_phy_xlate);
if (IS_ERR(phy_provider))
base-commit: 2ace2e949979b82f82f12dd76d7c5a6145246ca3
--
2.55.0.rc0.786.g65d90a0328-goog
^ permalink raw reply related
* Re: [PATCH] net: stmmac: fix missed le32_to_cpu()
From: Maxime Chevallier @ 2026-06-22 17:51 UTC (permalink / raw)
To: Ben Dooks, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260622143707.497198-1-ben.dooks@codethink.co.uk>
Hi Ben,
On 6/22/26 16:37, Ben Dooks wrote:
> The print in ndesc_display_ring() sends the des2 and des3
> to the pr_info() without passing them through the relevant
> conversion to cpu order.
>
> Fix the (prototype) sparse warnings by using le32_to_cpu():
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 6 (different base types)
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des2
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 7 (different base types)
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des3
>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
I agree on the principle, but this isn't a fix so this'll have to wait
until net-next re-opens :)
Thanks,
Maxime
> ---
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> index c4b613564f87..74c9b7b1fe8f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> @@ -258,7 +258,7 @@ static void ndesc_display_ring(void *head, unsigned int size, bool rx,
> pr_info("%03d [%pad]: 0x%x 0x%x 0x%x 0x%x",
> i, &dma_addr,
> (unsigned int)x, (unsigned int)(x >> 32),
> - p->des2, p->des3);
> + le32_to_cpu(p->des2), le32_to_cpu(p->des3));
> p++;
> }
> pr_info("\n");
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Catalin Marinas @ 2026-06-22 17:13 UTC (permalink / raw)
To: Harry Yoo
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <2208123f-8a51-483b-aa93-c35d8d053d25@kernel.org>
Hi Harry,
On Mon, Jun 22, 2026 at 09:42:10PM +0900, Harry Yoo wrote:
> On 6/19/26 10:19 PM, Catalin Marinas wrote:
> > On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
> >> On 6/12/26 1:44 PM, Dev Jain wrote:
> >>> Now, when a memory object will be freed, it will retain the random tag it
> >>> had at allocation time. This compromises on catching UAF bugs, till the
> >>> time the object is not reallocated, at which point it will have a new
> >>> random tag.
> >>>
> >>> Hence, not catching "use-after-free-before-reallocation" and not catching
> >>> "double-free" will be the compromise for reduced KASAN overhead.
> >>
> >> I doubt users who care about security enough to enable HW_TAGS KASAN
> >> are willing to compromise on security just to save a few instructions
> >> to store tags in the free path.
> >>
> >> To me, it looks like too much of a compromise on security for little
> >> performance gain.
> >
> > I don't think there's much compromise on security for use-after-free.
>
> I think it depends... OH, WAIT! I see what you mean.
>
> You mean use-after-free before reallocation does not lead to much
> compromise on security because objects are initialized after allocation?
>
> You're probably right.
>
> Hmm, but stores to e.g.) free pointer, fields initialized by
> constructor or accessed by SLAB_TYPESAFE_BY_RCU semantics after free
> will be undiscovered if they happen before reallocation.
Even with SLAB_TYPESAFE_BY_RCU, the object isn't tagged on free either
(or realloc, only if the actual slab page ends up freed). But we don't
get type confusion for such slab.
However, without tagging on free, one could argue that it reduces
security for cases where the page is re-allocated as untagged - e.g. all
user pages mapped without PROT_MTE. Currently we have a deterministic
tag check fault if the page is coloured as KASAN_TAG_INVALID. I think
for this patch, it might be better to only do such skip on free in
kasan_poison_slab() rather than kasan_poison(). Freed pages would then
be tagged.
An alternative would be tagging on free only with a new tag and skipping
it on re-alloc. But we'd need to track when it's a completely new
allocation or a reused object (I haven't looked I'm pretty sure it's
doable).
--
Catalin
^ permalink raw reply
* Re: [PATCH 10/11] regulator: db8500: Add power domain regulators
From: Mark Brown @ 2026-06-22 17:17 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Vinod Koul, Frank Li, Lee Jones, linux-arm-kernel,
devicetree, linux-pm, dri-devel, dmaengine
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-10-eb5e50b1a588@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 363 bytes --]
On Thu, Jun 18, 2026 at 07:00:56AM +0200, Linus Walleij wrote:
> +static int db8500_regulator_get_voltage(struct regulator_dev *rdev)
> +{
> + struct db8500_regulator_info *info = rdev_get_drvdata(rdev);
> +
> + if (!info->desc.fixed_uV)
> + return -EINVAL;
> +
> + return info->desc.fixed_uV;
> +}
The core supports single fixed voltages, set desc->fixed_uV.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v7 0/2] PCI: Configure Root Port MPS during host probing
From: Bjorn Helgaas @ 2026-06-22 17:14 UTC (permalink / raw)
To: Hans Zhang
Cc: bhelgaas, Manivannan Sadhasivam, lpieralisi, kwilczynski, heiko,
yue.wang, pali, neil.armstrong, robh, jingoohan1, khilman,
jbrunet, martin.blumenstingl, cassel, linux-pci, linux-kernel,
linux-arm-kernel, linux-amlogic, linux-rockchip
In-Reply-To: <dae17d36-c7d2-467b-a621-3c55e08a67a8@163.com>
On Fri, Jun 19, 2026 at 11:29:39PM +0800, Hans Zhang wrote:
> On 5/6/26 22:00, Manivannan Sadhasivam wrote:
> > On Fri, Nov 28, 2025 at 01:09:06AM +0800, Hans Zhang wrote:
> > > Current PCIe initialization exhibits a key optimization gap: Root Ports
> > > may operate with non-optimal Maximum Payload Size (MPS) settings. While
> > > downstream device configuration is handled during bus enumeration, Root
> > > Port MPS values inherited from firmware or hardware defaults often fail
> > > to utilize the full capabilities supported by controller hardware. This
> > > results in suboptimal data transfer efficiency throughout the PCIe
> > > hierarchy.
> > >
> > > This patch series addresses this by:
> > >
> > > 1. Core PCI enhancement (Patch 1):
> > > - Proactively configures Root Port MPS during host controller probing
> > > - Sets initial MPS to hardware maximum (128 << dev->pcie_mpss)
> > > - Conditional on PCIe bus tuning being enabled (PCIE_BUS_TUNE_OFF unset)
> > > and not in PCIE_BUS_PEER2PEER mode (which requires default 128 bytes)
> > > - Maintains backward compatibility via PCIE_BUS_TUNE_OFF check
> > > - Preserves standard MPS negotiation during downstream enumeration
> > >
> > > 2. Driver cleanup (Patch 2):
> > > - Removes redundant MPS configuration from Meson PCIe controller driver
> > > - Functionality is now centralized in PCI core
> > > - Simplifies driver maintenance long-term
> > >
> >
> > For the series,
> >
> > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> >
> > Bjorn: Could you please take a look? This series has been floating for a
> > while...
>
> Hello Bjorn,
>
> Any chance for this series to be applied?
It's too late for v7.2; we're already more than halfway through the
merge window. We can look again for v7.3 after v7.2-rc1.
^ permalink raw reply
* Re: [PATCH 09/11] regulator: db8500-prcmu: Remove EPOD regulators
From: Mark Brown @ 2026-06-22 17:00 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Vinod Koul, Frank Li, Lee Jones, linux-arm-kernel,
devicetree, linux-pm, dri-devel, dmaengine
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-9-eb5e50b1a588@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 160 bytes --]
On Thu, Jun 18, 2026 at 07:00:55AM +0200, Linus Walleij wrote:
> Remove the obsolete DB8500 PRCMU regulator drivers.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Re: Re: [PATCH v2] PCI: host-common: Request bus reassignment when not probe-only
From: Bjorn Helgaas @ 2026-06-22 16:56 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: bjorn@helgaas.com, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, bhelgaas@google.com,
will@kernel.org, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, robh@kernel.org, vidyas@nvidia.com
In-Reply-To: <MN0PR18MB584758C9286C78B6EE947FE7D3182@MN0PR18MB5847.namprd18.prod.outlook.com>
On Fri, Jun 12, 2026 at 04:03:25AM +0000, Ratheesh Kannoth wrote:
> ...
> Kindly advise if there are any outstanding action items required
> from my side. I see that the patch is not available in net-next yet
> or backported to stable versions. I want to ensure I haven't missed
> a step, so please excuse my impatience if it is simply a matter of
> the usual release cycle.
This is queued on pci/controller/host-common and is in pci/next for
v7.2. I will ask Linus to pull that branch sometime this week. This
is separate from net-next, so it won't appear there. Backports to
stable will happen after Linus pulls the branch.
Bjorn
^ permalink raw reply
* Re: [PATCH kvmtool v2 7/7] arm64: Improve KVM_ARM_VCPU_PMU_V3_CTRL diagnostics
From: Oliver Upton @ 2026-06-22 16:55 UTC (permalink / raw)
To: Alexandru Elisei
Cc: will, julien.thierry.kdev, maz, jean-philippe.brucker,
andre.przywara, suzuki.poulose, kvm, linux-arm-kernel, kvmarm
In-Reply-To: <ajj6oGxytFm2NE4T@raptor>
On Mon, Jun 22, 2026 at 10:04:32AM +0100, Alexandru Elisei wrote:
> Hi Oliver,
>
> On Thu, Jun 18, 2026 at 12:06:12PM -0700, Oliver Upton wrote:
> > The whole if (ret) die_perror(...) thing is a bit repetetive IMO. A
> > treewide cleanup replacing this with macros would be nice, then you could
> > stringize the ioctl under the hood.
>
> Thank you for having a look, that's a great idea, it will avoid out of bounds
> array access if KVM gets a new PMU ioctl and the name array is not updated at
> the same time - that's quite possible since ioctl numbers are pulled by running
> update_headers.sh, and the dependency is not obvious.
>
> I think the compilation errors are a bit higher priority than this, and a
> treewide change would more involved, possibly involving a change in behaviour
> (the gic seems to propagate the error instead of calling die_perror(), for
> example), would you mind if for this series I'll only introduce the macro for
> the pmu and convert the rest of the code in a separate series?
Fine by me, thanks Alex :)
Best,
Oliver
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Doug Anderson @ 2026-06-22 16:52 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Marc Zyngier, Catalin Marinas, Will Deacon, James Morse,
Mark Rutland, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <ajk-Vge2qhaY-TwJ@thinkstation>
Hi,
On Mon, Jun 22, 2026 at 6:56 AM Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> The ratio is flat across the whole 1-to-72 sweep, so -- relevant to the
> scalability question -- it's a constant per-syscall tax, not a contention
> effect. The impact tracks syscall/exception density: page_fault1, a more
> realistic workload, stays within ~5%.
FWIW, I'm not sure 5% is truly a "realistic" measure of the overhead
here. While it cannot be denied that pseudo-NMI has some overhead,
every time I've seen someone study it in "real world" scenarios it
ends up being fairly negligible. Not zero, mind you. ...but some
amount below 1%. ...and by this, I mean put real-world workloads on a
system with pseudo NMI enabled and pick your favorite metric. Perhaps
measure the amount of work completed in a given time. I dunno if this
is possible for you to do in this case.
> > The direction of travel is to deprecate SDEI. I wouldn't add more stuff
> > on top of this interface.
>
> I understand FEAT_NMI is the long-term answer, and I'm not arguing against
> deprecating SDEI. My concern is the gap in between. By our estimate it's
> 10+ years before the last non-FEAT_NMI machine retires from the fleet --
> for scale, we're still running Skylake today. So there's roughly a
> decade where a large installed base has neither FEAT_NMI nor affordable
> pseudo-NMI, and no way to reach a DAIF-masked CPU for an all-CPU
> backtrace or to capture a wedged CPU in a crash dump. That's the
> functional gap this series tries to cover.
>
> Given the deprecation direction, I deliberately kept the SDEI footprint as
> small as I could. The series adds no new firmware interface and no vendor
> SMC -- it uses only the standard software-signalled event (event 0) via
> SDEI_EVENT_SIGNAL, which is already present on these systems for
> firmware-first RAS (APEI/GHES). And SDEI is only ever invoked in a "bad
> state": to deliver a backtrace signal to a CPU that a normal IPI can't
> reach, or to stop a CPU that ignored the stop IPIs. Nothing on any hot or
> steady-state path touches it.
>
> If even that minimal use is unacceptable on a deprecated interface, I'd
> rather know now and redirect the effort -- but I'd appreciate a pointer to
> what should cover this gap for existing silicon in the meantime.
FWIW, despite the fact that pseudo-NMI (in my experience) ends up
being mostly negligible, personally I'd be in favor of landing Kiryl's
patches. I dunno how many times I've had the discussion of pseudo-NMI
overhead over the years and it's certainly very easy to show that
there is _some_ overhead and that in pathological cases there is a lot
of overhead. As Kiryl says, the patches don't add a ton of extra
complexity and they even combine some of the stop/crash-stop code,
which is nice. Having them as a stop-gap until true NMI is available
seems nice to me. ...of course, I'm not an ARM maintainer, so it's
obviously not up to me. :-)
-Doug
^ permalink raw reply
* Re: [PATCH 1/6] arm64: mm: remove unreachable invalid range check in kasan_init_shadow()
From: Andrey Ryabinin @ 2026-06-22 16:52 UTC (permalink / raw)
To: Sang-Heon Jeon, Catalin Marinas, Will Deacon
Cc: Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov, kasan-dev,
linux-arm-kernel, Vincenzo Frascino
In-Reply-To: <20260621145919.1453-2-ekffu200098@gmail.com>
Sang-Heon Jeon <ekffu200098@gmail.com> writes:
> kasan_init_shadow() maps each memblock region with for_each_mem_range()
> and breaks the loop when start >= end. for_each_mem_range() never returns
> an invalid range, so start < end always.
>
> Therefore the start >= end check is unreachable, so remove it.
>
> No functional change.
>
> Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
> ---
> arch/arm64/mm/kasan_init.c | 3 ---
> 1 file changed, 3 deletions(-)
>
Reviewed-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index 3fcad956fdf7..45fbdce684c8 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -353,9 +353,6 @@ static void __init kasan_init_shadow(void)
> void *start = (void *)__phys_to_virt(pa_start);
> void *end = (void *)__phys_to_virt(pa_end);
>
> - if (start >= end)
> - break;
> -
> kasan_map_populate((unsigned long)kasan_mem_to_shadow(start),
> (unsigned long)kasan_mem_to_shadow(end),
> early_pfn_to_nid(virt_to_pfn(start)));
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Steven Rostedt @ 2026-06-22 16:51 UTC (permalink / raw)
To: Randy Dunlap
Cc: Peter Zijlstra, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Julia Lawall, Yury Norov, linux-doc,
linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <08b3c961-18bb-43d9-8d7f-8a87bcad0afa@infradead.org>
On Mon, 22 Jun 2026 09:40:45 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> > Did you forget your C 101 class? If you use a function, you gotta
> > include the relevant header.
>
> Also item #1 in Documentation/process/submit-checklist.rst.
What is that? Remove all trace_printk()s before you submit?
Because that is what you should do. But now you also need to remember
to remove the include <linux/trace_printk.h> too. Or, I guess if
someone uses it a lot, they may just keep it in their files without the
trace_printk()s.
-- Steve
^ permalink raw reply
* Re: [PATCH] arm64: mm: Defer read-only remap of data/bss linear alias
From: Ard Biesheuvel @ 2026-06-22 16:42 UTC (permalink / raw)
To: Kevin Brodsky, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, Catalin Marinas, Will Deacon, Fuad Tabba
In-Reply-To: <2deff570-0497-4438-94ba-a9691881a016@arm.com>
Hi Kevin,
On Mon, Jun 22, 2026 at 5:23 PM Kevin Brodsky <kevin.brodsky@arm.com> wrote:
>
> On 19/06/2026 18:39, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > Fuad reports that in some cases, the KVM init code may apply relocations
> > to variables that reside in .data, and does so via the linear map. This
> > means that remapping .data read-only beforehand is a bad idea, and
> > results in an early boot crash.
> >
> > These variables in .data are only present when CONFIG_NVHE_EL2_DEBUG or
> > CONFIG_NVHE_EL2_TRACING are enabled, which is why it was not spotted in
> > testing.
> >
> > So move the remap to mark_rodata_ro(), which is a reasonable place to
> > put this, and ensures that it happens much later during the boot. It
> > also means that rodata=off is now taken into account, and so the linear
> > alias will remain writable in that case.
> >
> > Cc: Fuad Tabba <fuad.tabba@linux.dev>
> > Fixes: f2ba877402e5 ("arm64: mm: Map the kernel data/bss read-only in the linear map")
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> > arch/arm64/mm/mmu.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 9f354971b7e4..1f7eca86b5c1 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1198,11 +1198,6 @@ static void __init map_mem(void)
> > __map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
> > flags);
> > }
> > -
> > - /* Map the kernel data/bss read-only in the linear map */
> > - __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
> > - flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
> > - (unsigned long)lm_alias(__bss_stop));
> > }
> >
> > void mark_rodata_ro(void)
> > @@ -1221,6 +1216,12 @@ void mark_rodata_ro(void)
> > update_mapping_prot(__pa_symbol(_text), (unsigned long)_text,
> > (unsigned long)_stext - (unsigned long)_text,
> > PAGE_KERNEL_RO);
> > +
> > + /* Map the kernel data/bss read-only in the linear map */
> > + update_mapping_prot(__pa_symbol(__init_end),
> > + (unsigned long)lm_alias(__init_end),
> > + (unsigned long)__bss_stop - (unsigned long)__init_end,
> > + PAGE_KERNEL_RO);
>
> I was rather confused by this patch until I saw in master:
>
> f102131c842d Revert "arm64: mm: Unmap kernel data/bss entirely from the
> linear map"
> 81479b6888f8 Revert "arm64: mm: Defer remap of linear alias of data/bss"
>
> ... which explains the diff, but it looks like there are multiple issues
> here. Is my understanding correct that these reverts fix kvm_arm_init()
> because it needs to *read* from the linear map, while this new patch
> fixes some KVM configurations that need to *write* to the linear map?
>
Basically, yes.
> If so it might be good to give a recap in the commit message, because
> the reverts are easy to miss.
>
Ok
> It would also be good to explain why we can't do this in
> mark_linear_text_alias_ro() (presumably because this is too early). I do
> agree that honouring rodata=off is a good thing, though.
>
I didn't consider that tbh - I'll check whether that is a more suitable
location. But generally, I think doing it later rather than earlier is
fine because it reduces the likelihood of hidden issues such as the one
being addressed by this patch, and I don't think doing this very early
makes a meaningful difference in terms of robustness.
> BTW, if only kvm_arm_init() needs to read the data/bss via the linear
> map, maybe we can still unmap it later?
>
Yes, it is still my intent to bring back the patches that unmap this alias
entirely, including some additional tweaks for the fixmap PTE level table
that I dropped after an earlier revision. But that will be 7.3 material,
whereas this fixes a regression due to the changes that were pulled for 7.2.
^ permalink raw reply
* Re: [PATCH v2 4/5] dt-bindings: dma: sun50i-a64-dma: Add allwinner,sun60i-a733-dma compatible string
From: Conor Dooley @ 2026-06-22 16:42 UTC (permalink / raw)
To: Frank Li
Cc: Yuanshen Cao, Vinod Koul, Frank Li, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, dmaengine, linux-arm-kernel, linux-sunxi,
linux-kernel, devicetree
In-Reply-To: <ajhjj7FLn136qMmt@SMW015318>
[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]
On Sun, Jun 21, 2026 at 05:19:59PM -0500, Frank Li wrote:
> On Sun, Jun 21, 2026 at 09:40:57PM +0000, Yuanshen Cao wrote:
>
> subject dt-bindings: dmaengine: ....
>
> > Add `allwinner,sun60i-a733-dma` to the list of compatible strings for the
> > `sun50i-a64-dma` dtbinding documentation.
> >
> > While the A733 DMA controller shares many similarities with the sun50i-a64
> > DMA controller, it requires a specific configuration due to differences in:
> > - Interrupt register layout and mapping.
> > - Number of channels per interrupt register.
> > - Support for higher (32G) address widths in LLI parameters.
> >
> > Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> > ---
>
> After fix subject tags,
Do not change this unless you're respinning for another reason. dma v
dmaengine is not worth resubmission, especially since dma is far more
commonly used and is the directory name.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> > Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> > index c3e14eb6cfff..1cc3304b7414 100644
> > --- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> > +++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> > @@ -25,6 +25,7 @@ properties:
> > - allwinner,sun50i-a64-dma
> > - allwinner,sun50i-a100-dma
> > - allwinner,sun50i-h6-dma
> > + - allwinner,sun60i-a733-dma
> > - items:
> > - const: allwinner,sun8i-r40-dma
> > - const: allwinner,sun50i-a64-dma
> > @@ -70,6 +71,7 @@ if:
> > - allwinner,sun20i-d1-dma
> > - allwinner,sun50i-a100-dma
> > - allwinner,sun50i-h6-dma
> > + - allwinner,sun60i-a733-dma
> >
> > then:
> > properties:
> >
> > --
> > 2.54.0
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Randy Dunlap @ 2026-06-22 16:40 UTC (permalink / raw)
To: Peter Zijlstra, Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Julia Lawall, Yury Norov, linux-doc, linux-kbuild, linuxppc-dev,
dri-devel, linux-stm32, linux-arm-kernel, linux-rdma, linux-usb,
linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260622083440.GX49951@noisy.programming.kicks-ass.net>
On 6/22/26 1:34 AM, Peter Zijlstra wrote:
> On Sun, Jun 21, 2026 at 05:34:30AM -0400, Steven Rostedt wrote:
>> There's been complaints about trace_printk() being defined in kernel.h as it
>> can increase the compilation time. As it is only used by some developers for
>> debugging purposes, it should not be in kernel.h causing lots of wasted CPU
>> cycles for those that do not ever care about it.
>>
>> Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do
>> use it can set and not have to always remember to add #include <linux/trace_printk.h>
>> to the files they add trace_printk() while debugging. It also means that
>> those that do not have that config set will not have to worry about wasted
>> CPU cycles as it is only include in the CFLAGS when the option is set, and
>> its completely ignored otherwise.
>
> Did you forget your C 101 class? If you use a function, you gotta
> include the relevant header.
Also item #1 in Documentation/process/submit-checklist.rst.
> You don't see userspace saying: 'Hey, you know what, perhaps we should
> add stdio.h to every other header, just in case someone wants to
> printf()' either.
>
> I really don't understand your argument. Yes, maybe someone will forget
> and then either their editor (if they have a halfway modern setup with
> LSP enabled) or their build will complain, but so what? This is all
> trivial stuff, surely we have more pressing matters to concern outselves
> with?
--
~Randy
^ permalink raw reply
* Re: [PATCH net v3] net: airoha: fix BQL underflow in shared QDMA TX ring
From: Simon Horman @ 2026-06-22 16:39 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260620-airoha-bql-fixes-v3-1-76b95374e63e@kernel.org>
On Sat, Jun 20, 2026 at 05:04:51PM +0200, Lorenzo Bianconi wrote:
> When multiple netdevs share a QDMA TX ring and one device is stopped,
> netdev_tx_reset_subqueue() zeroes that device's BQL counters while its
> pending skbs remain in the shared HW TX ring. When NAPI later completes
> those skbs via netdev_tx_completed_queue(), the already-zeroed
> dql->num_queued counter underflows.
>
> Fix the issue:
> - Remove netdev_tx_reset_subqueue() from airoha_dev_stop() so pending
> skbs are completed naturally by NAPI with proper BQL accounting.
> - Rework airoha_qdma_tx_cleanup() to disable TX DMA, flush BQL
> counters, DMA-unmap and free all pending skbs while skb->dev
> references are still valid. Use a per-queue flushing flag checked
> under q->lock in airoha_dev_xmit() to prevent races between teardown
> and transmit. Call airoha_qdma_stop_napi() before
> airoha_qdma_tx_cleanup() at the call sites.
> - Move DMA engine start into probe. Split DMA teardown so TX DMA is
> disabled in airoha_qdma_tx_cleanup() and RX DMA in
> airoha_qdma_cleanup().
> - Remove qdma->users counter since DMA lifetime is now tied to
> probe/cleanup rather than per-netdev open/stop.
>
> Fixes: a9c2ca61fec7 ("net: airoha: Support multiple net_devices for a single FE GDM port")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> Changes in v3:
> - Remove airoha_qdma users counter.
> - Drop DEV_STATE_FLUSH bit and add per-queue flushing bool to avoid any
> race between airoha_qdma_tx_flush() and airoha_dev_xmit().
> - Refactor airoha_qdma_cleanup_tx_queue().
> - Rename airoha_qdma_cleanup_tx_queue() in airoha_qdma_tx_cleanup().
> - Link to v2: https://lore.kernel.org/r/20260619-airoha-bql-fixes-v2-1-4351d6a24484@kernel.org
>
Thanks for the updates.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] pwm: add Axiado AX3000 PWM driver
From: Uwe Kleine-König @ 2026-06-22 16:29 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-pwm, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260618-axiado-ax3000-pwm-v1-2-c9797a909414@axiado.com>
[-- Attachment #1: Type: text/plain, Size: 9646 bytes --]
Hello Petar,
Just a very high-level review:
On Thu, Jun 18, 2026 at 05:26:57AM -0700, Petar Stepanovic wrote:
> The Axiado AX3000 and AX3005 SoCs include PWM controllers that can be
> used to generate configurable PWM output signals.
>
> Add a PWM driver with support for configuring period, duty cycle, and
> enable state through the Linux PWM framework.
>
> Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
> ---
> MAINTAINERS | 1 +
> drivers/pwm/Kconfig | 11 +++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-axiado.c | 193 +++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 206 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 394c4a3527e8..db93fc235c32 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4319,6 +4319,7 @@ M: Prasad Bolisetty <pbolisetty@axiado.com>
> L: linux-pwm@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/pwm/axiado,ax3000-pwm.yaml
> +F: drivers/pwm/pwm-axiado.c
>
> AXIS ARTPEC ARM64 SoC SUPPORT
> M: Jesper Nilsson <jesper.nilsson@axis.com>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 6f3147518376..76f6c04b0e23 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -129,6 +129,17 @@ config PWM_ATMEL_TCB
> To compile this driver as a module, choose M here: the module
> will be called pwm-atmel-tcb.
>
> +config PWM_AXIADO
> + tristate "Axiado PWM support"
> + depends on ARCH_AXIADO || COMPILE_TEST
> + depends on HAS_IOMEM
> + help
> + PWM framework driver for the PWM controller found on Axiado
> + AX3000 and AX3005 SoCs.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-axiado.
> +
> config PWM_AXI_PWMGEN
> tristate "Analog Devices AXI PWM generator"
> depends on MICROBLAZE || NIOS2 || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_INTEL_SOCFPGA || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 0dc0d2b69025..4466a29e780a 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_PWM_ARGON_FAN_HAT) += pwm-argon-fan-hat.o
> obj-$(CONFIG_PWM_ATMEL) += pwm-atmel.o
> obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM) += pwm-atmel-hlcdc.o
> obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
> +obj-$(CONFIG_PWM_AXIADO) += pwm-axiado.o
> obj-$(CONFIG_PWM_AXI_PWMGEN) += pwm-axi-pwmgen.o
> obj-$(CONFIG_PWM_BCM2835) += pwm-bcm2835.o
> obj-$(CONFIG_PWM_BCM_IPROC) += pwm-bcm-iproc.o
> diff --git a/drivers/pwm/pwm-axiado.c b/drivers/pwm/pwm-axiado.c
> new file mode 100644
> index 000000000000..db197886c5c4
> --- /dev/null
> +++ b/drivers/pwm/pwm-axiado.c
> @@ -0,0 +1,193 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2021-2026 Axiado Corporation.
Please add a Limitations paragraph here like the ones found in the newer
driver files. It should answer:
- Is a period completed on configuration change?
- Is a period completed on disable?
- How does the output behave when disabled? (Low? Inactive? Freeze? High-Z?)
Also mention special properties, like being unable to set 0% or 100%
relative duty.
> + */
> +
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/math64.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +
> +/* Register offsets */
> +#define AX_PWM_CNTRL_REG 0x0000
> +#define AX_PWM_PERIOD_REG 0x0004
> +#define AX_PWM_HIGH_REG 0x0008
> +
> +/* PWM channels */
> +#define AX_PWM_NUM 1
This is only used once, and having
chip = devm_pwmchip_alloc(dev, 1, sizeof(*axpwm));
below simplifies grepping for channel numbers.
> +
> +/* Period and duty cycle limits */
> +#define AX_PWM_PERIOD_MIN 2
> +#define AX_PWM_PERIOD_MAX 0xfffffffeU
> +#define AX_PWM_DUTY_MIN 1
> +#define AX_PWM_DUTY_MAX 0xfffffffdU
The U suffix is not needed for hex constants (AFAIK).
> +
> +/* Control register bits */
> +#define AX_PWM_CTRL_ENABLE BIT(0)
> +#define AX_PWM_CTRL_DISABLE 0x0
> +
> +struct axiado_pwm_chip {
> + struct clk *clk;
> + void __iomem *base;
> +};
If you use axiado_pwm_ as prefix for structs and functions, please use
AXIADO_PWM_ as prefix for #defines.
> +
> +static int axiado_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> + u64 duty_ns, u64 period_ns)
> +{
> + struct axiado_pwm_chip *axpwm = pwmchip_get_drvdata(chip);
> + unsigned long rate;
> + u64 period_cycles, duty_cycles;
> +
> + /*
> + * The hardware does not support a zero period, 0% duty cycle, or
> + * 100% duty cycle. The caller should handle 0% duty cycle by
> + * disabling the PWM.
> + */
> + if (!period_ns || !duty_ns || duty_ns >= period_ns)
> + return -EINVAL;
> +
> + rate = clk_get_rate(axpwm->clk);
> + if (!rate)
> + return -EINVAL;
> +
> + period_cycles = mul_u64_u64_div_u64(period_ns, rate, NSEC_PER_SEC);
> + if (period_cycles < AX_PWM_PERIOD_MIN ||
> + period_cycles > AX_PWM_PERIOD_MAX)
> + return -EINVAL;
> +
> + duty_cycles = mul_u64_u64_div_u64(duty_ns, rate, NSEC_PER_SEC);
> + if (duty_cycles < AX_PWM_DUTY_MIN ||
> + duty_cycles > AX_PWM_DUTY_MAX)
> + return -EINVAL;
> +
> + if (duty_cycles >= period_cycles)
> + return -EINVAL;
> +
> + writel((u32)period_cycles, axpwm->base + AX_PWM_PERIOD_REG);
> + writel((u32)duty_cycles, axpwm->base + AX_PWM_HIGH_REG);
> +
> + return 0;
> +}
> +
> +static int axiado_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct axiado_pwm_chip *axpwm = pwmchip_get_drvdata(chip);
> + int ret;
> +
> + if (state->polarity != PWM_POLARITY_NORMAL)
> + return -EINVAL;
> +
> + if (!state->enabled || !state->duty_cycle) {
> + if (pwm->state.enabled)
> + writel(AX_PWM_CTRL_DISABLE, axpwm->base + AX_PWM_CNTRL_REG);
> +
> + return 0;
> + }
> +
> + ret = axiado_pwm_config(chip, pwm, state->duty_cycle, state->period);
> + if (ret)
> + return ret;
> +
> + if (!pwm->state.enabled)
Ideally check hardware state and not PWM internal variables.
> + writel(AX_PWM_CTRL_ENABLE, axpwm->base + AX_PWM_CNTRL_REG);
> +
> + return 0;
> +}
> +
> +static int axiado_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct axiado_pwm_chip *axpwm = pwmchip_get_drvdata(chip);
> + unsigned long rate;
> + u32 period_cycles;
> + u32 duty_cycles;
> + u32 ctrl;
> +
> + rate = clk_get_rate(axpwm->clk);
> + if (!rate)
> + return -EINVAL;
> +
> + ctrl = readl(axpwm->base + AX_PWM_CNTRL_REG);
> + period_cycles = readl(axpwm->base + AX_PWM_PERIOD_REG);
> + duty_cycles = readl(axpwm->base + AX_PWM_HIGH_REG);
> +
> + state->enabled = !!(ctrl & AX_PWM_CTRL_ENABLE);
> + state->period = mul_u64_u64_div_u64(period_cycles, NSEC_PER_SEC, rate);
> + state->duty_cycle = mul_u64_u64_div_u64(duty_cycles, NSEC_PER_SEC, rate);
> + state->polarity = PWM_POLARITY_NORMAL;
Please test your driver with PWM_DEBUG enabled, the rounding is wrong
here.
> +
> + return 0;
> +}
> +
> +static const struct pwm_ops axiado_pwm_ops = {
> + .get_state = axiado_pwm_get_state,
> + .apply = axiado_pwm_apply,
Please implement the waveform callbacke instead of .get_state() and
.apply()
> +};
> +
> +static void axiado_pwm_disable(void *data)
> +{
> + struct axiado_pwm_chip *axpwm = data;
> +
> + writel(AX_PWM_CTRL_DISABLE, axpwm->base + AX_PWM_CNTRL_REG);
> +}
> +
> +static int axiado_pwm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct axiado_pwm_chip *axpwm;
> + struct pwm_chip *chip;
> + int ret;
> +
> + chip = devm_pwmchip_alloc(dev, AX_PWM_NUM, sizeof(*axpwm));
> + if (IS_ERR(chip))
> + return PTR_ERR(chip);
> +
> + axpwm = pwmchip_get_drvdata(chip);
> +
> + axpwm->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(axpwm->base))
> + return dev_err_probe(dev, PTR_ERR(axpwm->base),
> + "failed to map registers\n");
Start error messages with a capital letter please.
> +
> + ret = devm_add_action_or_reset(dev, axiado_pwm_disable, axpwm);
> + if (ret)
> + return ret;
This isn't supposed to happen. It's the responsibility of the consumer
to disable the PWM before it's freed.
> +
> +
Single empty line only.
> + axpwm->clk = devm_clk_get_enabled(dev, "pwm");
> + if (IS_ERR(axpwm->clk))
> + return dev_err_probe(dev, PTR_ERR(axpwm->clk),
> + "failed to get/enable clock\n");
Please ensure that the clk rate doesn't change while the PWM is enabled.
Then you can cache the clk rate and set chip->atomic.
> +
> + chip->ops = &axiado_pwm_ops;
> +
> + ret = devm_pwmchip_add(dev, chip);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to add PWM chip\n");
> +
> + return 0;
> +}
> +
> +static const struct of_device_id axiado_pwm_match[] = {
> + { .compatible = "axiado,ax3000-pwm" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, axiado_pwm_match);
> +
> +static struct platform_driver axiado_pwm_driver = {
> + .driver = {
> + .name = "axiado-pwm",
> + .of_match_table = axiado_pwm_match,
> + },
> + .probe = axiado_pwm_probe,
> +};
> +
> +module_platform_driver(axiado_pwm_driver);
No empty line between the driver struct and the module_platform helper
please.
> +
> +MODULE_AUTHOR("Axiado Corporation");
> +MODULE_DESCRIPTION("Axiado PWM driver");
> +MODULE_LICENSE("GPL");
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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