* Re: [PATCH] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Krzysztof Kozlowski @ 2026-03-30 11:01 UTC (permalink / raw)
To: Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <02927f87-fa91-457d-af2b-a7610ef481e8@aliel.fr>
On 30/03/2026 13:01, Ronald Claveau wrote:
> On 3/30/26 12:38 PM, Krzysztof Kozlowski wrote:
>> On 30/03/2026 12:21, Ronald Claveau wrote:
>>> Fix introduced invalid property for Khadas VIM4 sdcard regulator.
>>>
>>> arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
>>>
>>
>> Fixes commit?
>>
>
> Thanks for your review I will add a Fixes tag like that:
> Fixes: 60eff75ac67b ("arm64: dts: amlogic: t7: khadas-vim4: Add power
> regulators")
>
>> Why there is no such change in recent next? Was it just merged?
>>
>
> Yes it is in next-20260327
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts?h=next-20260327&id=60eff75ac67bbf5445bdbd2842b0109ac591441c
Thanks, With fixes tag added:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 2/2] ARM: dts: gemini: Rename power controller node to poweroff
From: Khushal Chitturi @ 2026-03-30 11:01 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260330110135.10316-1-khushalchitturi@gmail.com>
Update the node name for the Cortina Gemini power controller from
power-controller to poweroff since node "power controller" is
reserved for power domain controller.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v2 -> v3:
- Used generic node name "poweroff" instead of "gemini-poweroff".
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/gemini/gemini.dtsi b/arch/arm/boot/dts/gemini/gemini.dtsi
index befe322bd7de..910faabf76ef 100644
--- a/arch/arm/boot/dts/gemini/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini/gemini.dtsi
@@ -228,7 +228,7 @@ intcon: interrupt-controller@48000000 {
#interrupt-cells = <2>;
};
- power-controller@4b000000 {
+ poweroff@4b000000 {
compatible = "cortina,gemini-power-controller";
reg = <0x4b000000 0x100>;
interrupts = <26 IRQ_TYPE_EDGE_RISING>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: Krzysztof Kozlowski @ 2026-03-30 11:03 UTC (permalink / raw)
To: André Draszik
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm
In-Reply-To: <abeff7983dc08c3aeee8b504f34b71b1a2fcdb78.camel@linaro.org>
On 30/03/2026 12:59, André Draszik wrote:
> On Mon, 2026-03-30 at 12:55 +0200, Krzysztof Kozlowski wrote:
>> On 30/03/2026 12:52, André Draszik wrote:
>>>> Your patchset is organized in odd way - first patch for me, then not for
>>>> me, then again two patches for me. Please keep it consistent. Or better,
>>>> decouple since there are no dependencies according to cover letter.
>>>
>>> I'll update the cover letter to describe the dependencies. 4 depends on 2,
>>
>>
>> How 4 (soc) patch depends on 2 (pm domains)? What is exactly the dependency?
>
> 4 updates the soc-level pmu binding of gs101 to have gs101-power-domain
> child-nodes, which are introduced in 2
>
You described what the patch is doing, but that was not my question.
What is the dependency exactly.
This is ping pong, so I finish discussions here, but to be clear -
entire patchset cannot be merged.
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-30 11:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <3bb6b71e-947b-4248-95ba-79852f743c1d@kernel.org>
On Mon, 30 Mar 2026 at 12:17, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/03/2026 12:13, Ulf Hansson wrote:
> > On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On 23/03/2026 12:13, Ulf Hansson wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>>
> >>>>
> >>>> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
> >>>>> This series adds support for the power domains on Google GS101.
> >>>>>
> >>>>> There are a few differences compared to SoCs already supported by this
> >>>>> driver:
> >>>>> * register access does not work via plain ioremap() / readl() /
> >>>>> writel().
> >>>>> Instead, the regmap created by the PMU driver must be used (which
> >>>>> uses Arm SMCC calls under the hood).
> >>>>> * DTZPC: a call needs to be made before and after power domain off/on,
> >>>>> to inform the EL3 firmware of the request.
> >>>>> * power domains can and are fed by a regulator rail and therefore
> >>>>> regulator control needed be implemented.
> >>>>>
> >>>>> [...]
> >>>>
> >>>> Applied, thanks!
> >>>>
> >>>> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
> >>>> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
> >>>> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
> >>>> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
> >>>> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
> >>>> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
> >>>>
> >>>> Best regards,
> >>>
> >>> Usually I pick up the power-domain related changes for the DT bindings
> >>> and host them via an immutable branch called "dt". If needed, SOC
> >>> maintainers can pull it to apply/test the corresponding DTS changes.
> >>>
> >>> That said, I am open to whatever you think is best here. Perhaps it's
> >>> easier if you can drop the DT patches and provide your acks instead or
> >>> if you can share them via an immutable branch for me to pull?
> >>
> >>
> >> I did not pick up any pmdomain binding patches. I picked up only soc and
> >> according to cover letter there are no dependencies between anything here.
> >
> > As I understand it, they are all related and some even depend on each
>
> I raised exactly that questions but no answers.
>
> > other. I think keeping all four DT patches together makes sense.
>
> Why? What is the dependency?
I defer to André to clarify this for us.
>
> >
> > Although, as I said, if you think it's best to funnel them through
> > your tree, please do and then share them via an immutable branch, so I
> > can apply the pmdomain driver changes.
>
> soc must go via my tree, but there is no reason to take the pmdomain
> binding patch. So I did not take.
Yes, they belong to soc/platform, which is common for most
power-domain providers.
To allow us to merge/maintain power-domain provider *driver* changes
separately, we needed a way to manage the corresponding DT bindings.
That's why I am hosting the immutable "dt" branch for these, which
soc/platform maintainers can pull-in when they need it.
Of course, doing it the other way around is also possible. Just let me
know what you prefer.
>
> But anyway, I just noticed that I dropped everything: this introduces
> new warnings which were nowhere addressed or explained. So regardless
> how this should go, please do not apply anything - it's broken and
> author is silent.
Right, I will await your confirmation!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH RFC net-next] net: stmmac: qcom-ethqos: set clk_csr
From: Konrad Dybcio @ 2026-03-30 11:18 UTC (permalink / raw)
To: Russell King (Oracle), Mohd Ayaan Anwar
Cc: Alexandre Torgue, Andrew Lunn, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-stm32, netdev, Paolo Abeni
In-Reply-To: <E1w6AZm-0000000E54W-1F6E@rmk-PC.armlinux.org.uk>
On 3/27/26 6:02 PM, Russell King (Oracle) wrote:
> The clocks for qcom-ethqos return a rate of zero as firmware manages
> their rate. According to hardware documentation, the clock which is
> fed to the slave AHB interface can crange between 50 and 100MHz.
FWIW this __may__ possibly differ between platforms, but I'm not sure
to what degree. Will there be visible impact if we e.g. have a 200 or
300 MHz clock somewhere?
Konrad
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 11:24 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFpOPC2stAJ262jdap-=ByY09AeQ0kj6p_9FTGJBx+Tu-Q@mail.gmail.com>
On 30/03/2026 13:12, Ulf Hansson wrote:
>
>>
>>>
>>> Although, as I said, if you think it's best to funnel them through
>>> your tree, please do and then share them via an immutable branch, so I
>>> can apply the pmdomain driver changes.
>>
>> soc must go via my tree, but there is no reason to take the pmdomain
>> binding patch. So I did not take.
>
> Yes, they belong to soc/platform, which is common for most
> power-domain providers.
What does belong to soc/platform? pmdomain changes? No, they do not...
>
> To allow us to merge/maintain power-domain provider *driver* changes
> separately, we needed a way to manage the corresponding DT bindings.
Nothing stops that, there is no dependency. For a week I am saying there
are no dependencies. If there are, please provide any sort of
argument/proof, otherwise there is nothing to do here.
> That's why I am hosting the immutable "dt" branch for these, which
> soc/platform maintainers can pull-in when they need it.
>
> Of course, doing it the other way around is also possible. Just let me
> know what you prefer.
Nothing like that is necessary.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH v2 2/5] iommu/arm-smmu-v3: Add register display to debugfs
From: Nicolin Chen @ 2026-03-30 11:25 UTC (permalink / raw)
To: Qinxin Xia
Cc: robin.murphy, will, jpb, linux-arm-kernel, iommu, wangzhou1,
prime.zeng, fanghao11, jonathan.cameron, wuyifan50, linuxarm
In-Reply-To: <20260328101706.3448655-3-xiaqinxin@huawei.com>
On Sat, Mar 28, 2026 at 06:17:03PM +0800, Qinxin Xia wrote:
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-debugfs.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-debugfs.c
> @@ -5,13 +5,18 @@
> * Directory Structure:
> * /sys/kernel/debug/iommu/arm_smmu_v3/
> * └── smmu<ioaddr>/
> - * └── capabilities # SMMU feature capabilities and configuration
Nit: perhaps the last line in every patch could start with '|-',
so we wouldn't need to update it every time.
> + * ├── capabilities # SMMU feature capabilities and configuration
> + * └── registers # SMMU Key registers
Maybe replace '\t' with whitespaces? The final file doesn't seem
to have this line properly aligned with others also.
Nicolin
^ permalink raw reply
* [GIT PULL] arm64: dts: socfpga: updates for v7.1
From: Dinh Nguyen @ 2026-03-30 11:28 UTC (permalink / raw)
To: linux-arm-kernel, soc; +Cc: dinguyen
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_updates_for_v7.1
for you to fetch changes up to 9d29bcefcdbec4498fe0539e6d8a4e7962d92489:
arm64: dts: intel: agilex5: Drop CPU masks from GICv3 PPI interrupts (2026-03-10 21:10:05 -0500)
----------------------------------------------------------------
SoCFPGA DTS updates for v7.1
- dt-bindings updates:
- Document fallback compatible for Stratix10 SoCDK eMMC board
- Document compatible for the Agilex5 SoCFPGA modular board
- Add emmc support for the Stratix10
- Drop CPU masks from the GICv3 PPI interrupts for Agilex5
----------------------------------------------------------------
Dinh Nguyen (1):
dt-bindings: intel: Add Agilex5 SoCFPGA modular board
Geert Uytterhoeven (1):
arm64: dts: intel: agilex5: Drop CPU masks from GICv3 PPI interrupts
Ng Tze Yee (2):
dt-bindings: altera: Add fallback compatible for Stratix 10 SoCDK eMMC variant
arm64: dts: socfpga: stratix10: Add emmc support
Documentation/devicetree/bindings/arm/altera.yaml | 7 ++
arch/arm64/boot/dts/altera/Makefile | 1 +
.../boot/dts/altera/socfpga_stratix10_socdk.dts | 67 +-----------------
.../boot/dts/altera/socfpga_stratix10_socdk.dtsi | 71 +++++++++++++++++++
.../dts/altera/socfpga_stratix10_socdk_emmc.dts | 81 ++++++++++++++++++++++
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 8 +--
6 files changed, 166 insertions(+), 69 deletions(-)
create mode 100755 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dtsi
create mode 100755 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk_emmc.dts
^ permalink raw reply
* Re: [PATCH v3 4/5] KVM: arm64: Enable HDBSS support and handle HDBSSF events
From: Leonardo Bras @ 2026-03-30 11:31 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
will, yuzenghui, wangzhou1, liuyonglong, Jonathan.Cameron,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <4e800c1e-25db-4aa2-b100-63434973de93@huawei.com>
On Sat, Mar 28, 2026 at 02:05:25PM +0800, Tian Zheng wrote:
>
> On 3/27/2026 11:00 PM, Leonardo Bras wrote:
> > On Fri, Mar 27, 2026 at 03:35:29PM +0800, Tian Zheng wrote:
> > > On 3/26/2026 2:05 AM, Leonardo Bras wrote:
> > > > Hello Tian,
> > > >
> > > > I am currently working on HACDBS enablement(which will be rebased on top of
> > > > this patchset) and due to the fact HACDBS and HDBSS are kind of
> > > > complementary I will sometimes come with some questions for issues I have
> > > > faced myself on that part. :)
> > > >
> > > > (see below)
> > >
> > > Of course! Happy to exchange ideas and learn together.
> > :)
> >
> > >
> > > > On Wed, Feb 25, 2026 at 12:04:20PM +0800, Tian Zheng wrote:
> > > > > From: eillon <yezhenyu2@huawei.com>
> > > > >
> > > > > HDBSS is enabled via an ioctl from userspace (e.g. QEMU) at the start of
> > > > > migration. This feature is only supported in VHE mode.
> > > > >
> > > > > Initially, S2 PTEs doesn't contain the DBM attribute. During migration,
> > > > > write faults are handled by user_mem_abort, which relaxes permissions
> > > > > and adds the DBM bit when HDBSS is active. Once DBM is set, subsequent
> > > > > writes no longer trap, as the hardware automatically transitions the page
> > > > > from writable-clean to writable-dirty.
> > > > >
> > > > > KVM does not scan S2 page tables to consume DBM. Instead, when HDBSS is
> > > > > enabled, the hardware observes the clean->dirty transition and records
> > > > > the corresponding page into the HDBSS buffer.
> > > > >
> > > > > During sync_dirty_log, KVM kicks all vCPUs to force VM-Exit, ensuring
> > > > > that check_vcpu_requests flushes the HDBSS buffer and propagates the
> > > > > accumulated dirty information into the userspace-visible dirty bitmap.
> > > > >
> > > > > Add fault handling for HDBSS including buffer full, external abort, and
> > > > > general protection fault (GPF).
> > > > >
> > > > > Signed-off-by: eillon <yezhenyu2@huawei.com>
> > > > > Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
> > > > > ---
> > > > > arch/arm64/include/asm/esr.h | 5 ++
> > > > > arch/arm64/include/asm/kvm_host.h | 17 +++++
> > > > > arch/arm64/include/asm/kvm_mmu.h | 1 +
> > > > > arch/arm64/include/asm/sysreg.h | 11 ++++
> > > > > arch/arm64/kvm/arm.c | 102 ++++++++++++++++++++++++++++++
> > > > > arch/arm64/kvm/hyp/vhe/switch.c | 19 ++++++
> > > > > arch/arm64/kvm/mmu.c | 70 ++++++++++++++++++++
> > > > > arch/arm64/kvm/reset.c | 3 +
> > > > > 8 files changed, 228 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> > > > > index 81c17320a588..2e6b679b5908 100644
> > > > > --- a/arch/arm64/include/asm/esr.h
> > > > > +++ b/arch/arm64/include/asm/esr.h
> > > > > @@ -437,6 +437,11 @@
> > > > > #ifndef __ASSEMBLER__
> > > > > #include <asm/types.h>
> > > > >
> > > > > +static inline bool esr_iss2_is_hdbssf(unsigned long esr)
> > > > > +{
> > > > > + return ESR_ELx_ISS2(esr) & ESR_ELx_HDBSSF;
> > > > > +}
> > > > > +
> > > > > static inline unsigned long esr_brk_comment(unsigned long esr)
> > > > > {
> > > > > return esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
> > > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > > index 5d5a3bbdb95e..57ee6b53e061 100644
> > > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > > @@ -55,12 +55,17 @@
> > > > > #define KVM_REQ_GUEST_HYP_IRQ_PENDING KVM_ARCH_REQ(9)
> > > > > #define KVM_REQ_MAP_L1_VNCR_EL2 KVM_ARCH_REQ(10)
> > > > > #define KVM_REQ_VGIC_PROCESS_UPDATE KVM_ARCH_REQ(11)
> > > > > +#define KVM_REQ_FLUSH_HDBSS KVM_ARCH_REQ(12)
> > > > >
> > > > > #define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
> > > > > KVM_DIRTY_LOG_INITIALLY_SET)
> > > > >
> > > > > #define KVM_HAVE_MMU_RWLOCK
> > > > >
> > > > > +/* HDBSS entry field definitions */
> > > > > +#define HDBSS_ENTRY_VALID BIT(0)
> > > > > +#define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
> > > > > +
> > > > > /*
> > > > > * Mode of operation configurable with kvm-arm.mode early param.
> > > > > * See Documentation/admin-guide/kernel-parameters.txt for more information.
> > > > > @@ -84,6 +89,7 @@ int __init kvm_arm_init_sve(void);
> > > > > u32 __attribute_const__ kvm_target_cpu(void);
> > > > > void kvm_reset_vcpu(struct kvm_vcpu *vcpu);
> > > > > void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu);
> > > > > +void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu);
> > > > >
> > > > > struct kvm_hyp_memcache {
> > > > > phys_addr_t head;
> > > > > @@ -405,6 +411,8 @@ struct kvm_arch {
> > > > > * the associated pKVM instance in the hypervisor.
> > > > > */
> > > > > struct kvm_protected_vm pkvm;
> > > > > +
> > > > > + bool enable_hdbss;
> > > > > };
> > > > >
> > > > > struct kvm_vcpu_fault_info {
> > > > > @@ -816,6 +824,12 @@ struct vcpu_reset_state {
> > > > > bool reset;
> > > > > };
> > > > >
> > > > > +struct vcpu_hdbss_state {
> > > > > + phys_addr_t base_phys;
> > > > > + u32 size;
> > > > > + u32 next_index;
> > > > > +};
> > > > > +
> > > > > struct vncr_tlb;
> > > > >
> > > > > struct kvm_vcpu_arch {
> > > > > @@ -920,6 +934,9 @@ struct kvm_vcpu_arch {
> > > > >
> > > > > /* Per-vcpu TLB for VNCR_EL2 -- NULL when !NV */
> > > > > struct vncr_tlb *vncr_tlb;
> > > > > +
> > > > > + /* HDBSS registers info */
> > > > > + struct vcpu_hdbss_state hdbss;
> > > > > };
> > > > >
> > > > > /*
> > > > > diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> > > > > index d968aca0461a..3fea8cfe8869 100644
> > > > > --- a/arch/arm64/include/asm/kvm_mmu.h
> > > > > +++ b/arch/arm64/include/asm/kvm_mmu.h
> > > > > @@ -183,6 +183,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> > > > >
> > > > > int kvm_handle_guest_sea(struct kvm_vcpu *vcpu);
> > > > > int kvm_handle_guest_abort(struct kvm_vcpu *vcpu);
> > > > > +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu);
> > > > >
> > > > > phys_addr_t kvm_mmu_get_httbr(void);
> > > > > phys_addr_t kvm_get_idmap_vector(void);
> > > > > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> > > > > index f4436ecc630c..d11f4d0dd4e7 100644
> > > > > --- a/arch/arm64/include/asm/sysreg.h
> > > > > +++ b/arch/arm64/include/asm/sysreg.h
> > > > > @@ -1039,6 +1039,17 @@
> > > > >
> > > > > #define GCS_CAP(x) ((((unsigned long)x) & GCS_CAP_ADDR_MASK) | \
> > > > > GCS_CAP_VALID_TOKEN)
> > > > > +
> > > > > +/*
> > > > > + * Definitions for the HDBSS feature
> > > > > + */
> > > > > +#define HDBSS_MAX_SIZE HDBSSBR_EL2_SZ_2MB
> > > > > +
> > > > > +#define HDBSSBR_EL2(baddr, sz) (((baddr) & GENMASK(55, 12 + sz)) | \
> > > > > + FIELD_PREP(HDBSSBR_EL2_SZ_MASK, sz))
> > > > > +
> > > > > +#define HDBSSPROD_IDX(prod) FIELD_GET(HDBSSPROD_EL2_INDEX_MASK, prod)
> > > > > +
> > > > > /*
> > > > > * Definitions for GICv5 instructions]
> > > > > */
> > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > > index 29f0326f7e00..d64da05e25c4 100644
> > > > > --- a/arch/arm64/kvm/arm.c
> > > > > +++ b/arch/arm64/kvm/arm.c
> > > > > @@ -125,6 +125,87 @@ int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
> > > > > return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
> > > > > }
> > > > >
> > > > > +void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu)
> > > > > +{
> > > > > + struct page *hdbss_pg;
> > > > > +
> > > > > + hdbss_pg = phys_to_page(vcpu->arch.hdbss.base_phys);
> > > > > + if (hdbss_pg)
> > > > > + __free_pages(hdbss_pg, vcpu->arch.hdbss.size);
> > > > > +
> > > > > + vcpu->arch.hdbss.size = 0;
> > > > > +}
> > > > > +
> > > > > +static int kvm_cap_arm_enable_hdbss(struct kvm *kvm,
> > > > > + struct kvm_enable_cap *cap)
> > > > > +{
> > > > > + unsigned long i;
> > > > > + struct kvm_vcpu *vcpu;
> > > > > + struct page *hdbss_pg = NULL;
> > > > > + __u64 size = cap->args[0];
> > > > > + bool enable = cap->args[1] ? true : false;
> > > > > +
> > > > > + if (!system_supports_hdbss())
> > > > > + return -EINVAL;
> > > > > +
> > > > > + if (size > HDBSS_MAX_SIZE)
> > > > > + return -EINVAL;
> > > > > +
> > > > > + if (!enable && !kvm->arch.enable_hdbss) /* Already Off */
> > > > > + return 0;
> > > > > +
> > > > > + if (enable && kvm->arch.enable_hdbss) /* Already On, can't set size */
> > > > > + return -EINVAL;
> > > > > +
> > > > > + if (!enable) { /* Turn it off */
> > > > > + kvm->arch.mmu.vtcr &= ~(VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA);
> > > > > +
> > > > > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > > > > + /* Kick vcpus to flush hdbss buffer. */
> > > > > + kvm_vcpu_kick(vcpu);
> > > > > +
> > > > > + kvm_arm_vcpu_free_hdbss(vcpu);
> > > > > + }
> > > > > +
> > > > > + kvm->arch.enable_hdbss = false;
> > > > > +
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > + /* Turn it on */
> > > > > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > > > > + hdbss_pg = alloc_pages(GFP_KERNEL_ACCOUNT, size);
> > > > > + if (!hdbss_pg)
> > > > > + goto error_alloc;
> > > > > +
> > > > > + vcpu->arch.hdbss = (struct vcpu_hdbss_state) {
> > > > > + .base_phys = page_to_phys(hdbss_pg),
> > > > > + .size = size,
> > > > > + .next_index = 0,
> > > > > + };
> > > > > + }
> > > > > +
> > > > > + kvm->arch.enable_hdbss = true;
> > > > > + kvm->arch.mmu.vtcr |= VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA;
> > > > > +
> > > > > + /*
> > > > > + * We should kick vcpus out of guest mode here to load new
> > > > > + * vtcr value to vtcr_el2 register when re-enter guest mode.
> > > > > + */
> > > > > + kvm_for_each_vcpu(i, vcpu, kvm)
> > > > > + kvm_vcpu_kick(vcpu);
> > > > > +
> > > > > + return 0;
> > > > > +
> > > > > +error_alloc:
> > > > > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > > > > + if (vcpu->arch.hdbss.base_phys)
> > > > > + kvm_arm_vcpu_free_hdbss(vcpu);
> > > > > + }
> > > > > +
> > > > > + return -ENOMEM;
> > > > > +}
> > > > > +
> > > > > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > > > struct kvm_enable_cap *cap)
> > > > > {
> > > > > @@ -182,6 +263,11 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > > > r = 0;
> > > > > set_bit(KVM_ARCH_FLAG_EXIT_SEA, &kvm->arch.flags);
> > > > > break;
> > > > > + case KVM_CAP_ARM_HW_DIRTY_STATE_TRACK:
> > > > > + mutex_lock(&kvm->lock);
> > > > > + r = kvm_cap_arm_enable_hdbss(kvm, cap);
> > > > > + mutex_unlock(&kvm->lock);
> > > > > + break;
> > > > > default:
> > > > > break;
> > > > > }
> > > > > @@ -471,6 +557,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > > > r = kvm_supports_cacheable_pfnmap();
> > > > > break;
> > > > >
> > > > > + case KVM_CAP_ARM_HW_DIRTY_STATE_TRACK:
> > > > > + r = system_supports_hdbss();
> > > > > + break;
> > > > > default:
> > > > > r = 0;
> > > > > }
> > > > > @@ -1120,6 +1209,9 @@ static int check_vcpu_requests(struct kvm_vcpu *vcpu)
> > > > > if (kvm_dirty_ring_check_request(vcpu))
> > > > > return 0;
> > > > >
> > > > > + if (kvm_check_request(KVM_REQ_FLUSH_HDBSS, vcpu))
> > > > > + kvm_flush_hdbss_buffer(vcpu);
> > > > > +
> > > > > check_nested_vcpu_requests(vcpu);
> > > > > }
> > > > >
> > > > > @@ -1898,7 +1990,17 @@ long kvm_arch_vcpu_unlocked_ioctl(struct file *filp, unsigned int ioctl,
> > > > >
> > > > > void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
> > > > > {
> > > > > + /*
> > > > > + * Flush all CPUs' dirty log buffers to the dirty_bitmap. Called
> > > > > + * before reporting dirty_bitmap to userspace. Send a request with
> > > > > + * KVM_REQUEST_WAIT to flush buffer synchronously.
> > > > > + */
> > > > > + struct kvm_vcpu *vcpu;
> > > > > +
> > > > > + if (!kvm->arch.enable_hdbss)
> > > > > + return;
> > > > >
> > > > > + kvm_make_all_cpus_request(kvm, KVM_REQ_FLUSH_HDBSS);
> > > > > }
> > > > >
> > > > > static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
> > > > > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> > > > > index 9db3f11a4754..600cbc4f8ae9 100644
> > > > > --- a/arch/arm64/kvm/hyp/vhe/switch.c
> > > > > +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> > > > > @@ -213,6 +213,23 @@ static void __vcpu_put_deactivate_traps(struct kvm_vcpu *vcpu)
> > > > > local_irq_restore(flags);
> > > > > }
> > > > >
> > > > > +static void __load_hdbss(struct kvm_vcpu *vcpu)
> > > > > +{
> > > > > + struct kvm *kvm = vcpu->kvm;
> > > > > + u64 br_el2, prod_el2;
> > > > > +
> > > > > + if (!kvm->arch.enable_hdbss)
> > > > > + return;
> > > > > +
> > > > > + br_el2 = HDBSSBR_EL2(vcpu->arch.hdbss.base_phys, vcpu->arch.hdbss.size);
> > > > > + prod_el2 = vcpu->arch.hdbss.next_index;
> > > > > +
> > > > > + write_sysreg_s(br_el2, SYS_HDBSSBR_EL2);
> > > > > + write_sysreg_s(prod_el2, SYS_HDBSSPROD_EL2);
> > > > > +
> > > > > + isb();
> > > > > +}
> > > > > +
> > > > I see in the code below you trust that the tracking will happen with
> > > > PAGE_SIZE granularity (you track with PAGE_SHIFT).
> > > >
> > > > That may be a problem when we have guest memory backed by hugepages or
> > > > transparent huge pages.
> > > >
> > > > When we are using HDBSS, there is no fault happening, so we have no way of
> > > > doing on-demand block splitting, so we need to make use of eager block
> > > > splitting, _before_ we start to track anything, or else we may have
> > > > different-sized pages in the HDBSS buffer, which is harder to deal with.
> > > >
> > > > Suggestion: do the eager splitting before we enable HDBSS.
> > > >
> > > > For this to happen, we have to enable the EAGER_SPLIT_CHUNK_SIZE
> > > > capability, which can only be enabled when all memslots are empty.
> > > >
> > > > I suggest doing that at kvm_init_stage2_mmu(), and checking if HDBSS is
> > > > in which case we set mmu->split_page_chunk_size to PAGESIZE.
> > > >
> > > > I will send a patch you can put before this one to make sure it works :)
> > > >
> > > > Thanks!
> > > > Leo
> > > Hi Leo,
> > >
> > > Thanks for the helpful suggestion. I had previously traced the
> > > hugepage-splitting path
> > >
> > > during live migration and found that when migration starts, enabling dirty
> > > logging
> > >
> > > triggers the splitting path. I also tested HDBSS with traditional hugepages
> > > and haven't
> > >
> > > observed any issues yet.
> > >
> > >
> > > However, your concern is valid — there may be cases not covered, especially
> > > when the
> > >
> > > VMM uses transparent hugepages. I'll integrate your patch into the next
> > > version and
> > >
> > > run some tests.
> > >
> > >
> > > For reference, here's the path I traced:
> > >
> > > ```
> > >
> > > - userspace, e.g., QEMU
> > >
> > > kvm_log_start
> > > +-> kvm_section_update_flags
> > > +-> kvm_slot_update_flags
> > > |
> > > | // For each memory region, QEMU issues a
> > > KVM_SET_USER_MEMORY_REGION ioctl.
> > > | // Before issuing it, flags are updated to include
> > > KVM_MEM_LOG_DIRTY_PAGES.
> > > +-> kvm_mem_flags
> > > +-> kvm_set_user_memory_region // ioctl that enables dirty logging
> > > on the memslot
> > >
> > > - KVM
> > >
> > > KVM_SET_USER_MEMORY_REGION
> > > +-> kvm_vm_ioctl_set_memory_region
> > > +-> kvm_set_memory_region / __kvm_set_memory_region
> > > +-> kvm_set_memslot
> > > +-> kvm_commit_memory_region
> > > +-> kvm_arch_commit_memory_region
> > > +-> kvm_mmu_split_memory_region
> > > // Splits Stage-2 hugepages/contiguous mappings into
> > > 4KB PTEs.
> > Right, except on a case we have dirty_log_manual_protect and init_set, when
> > it returns before splitting pages:
> >
> > ```
> > if (kvm_dirty_log_manual_protect_and_init_set(kvm))
> > return;
> > ```
> >
> > IIUC, that's desired to avoid holding the lock for a long time while it
> > cleans every page in the beginning, and instead do it in a per dirty-page
> > basis. I guess it may benefit guests with very little dirty pages, as it
> > does not have to split/dirty everything at the start.
> > (Its a pain for my HACDBS routines, though)
> >
> > > +-> kvm_mmu_split_huge_pages
> > Other important point here:
> > You can see in this function it skips splitting if chunk_size == 0.
> > This value is set by a capability that configures EAGER_SPLIT, meaning
> > splitting before the guest have write faults, which is nice as the
> > write-fault is faster.
> >
> > Two points in this capability:
> > - It's optional, if it's not set, only on-demand splitting (on fault) will
> > happen, and since HDBSS removes the write-fault, we have no splitting
> > - It can be set to any valid block size, not only 4K, nor PAGE_SIZE, it can
> > be set to PMD_SIZE, PUD_SIZE, and so on, which will depend on the
> > PAGE_SIZE the kernel was compiled to.
> > That's only some points to keep in mind :)
> >
> > if (kvm_dirty_log_manual_protect_and_init_set(kvm))
> > return;
> >
> > > +-> kvm_pgtable_stage2_split
> > >
> > > ```
> > >
> > > Thanks again for the detailed explanation and for sending the patch.
> > >
> > Thank you for the collaboration on this!
> > Leo
>
>
> Thanks for the detailed explanation — very helpful. My earlier tests missed
> cases like lazy splitting
>
> and manual‑protect mode, and your patch addresses them perfectly.
>
> I'll adopt it in the next version and test the corner cases you mentioned.
Awesome, thanks!
Leo
^ permalink raw reply
* Re: [PATCH v7] arm64: implement support for static call trampolines
From: Will Deacon @ 2026-03-30 11:34 UTC (permalink / raw)
To: Carlos Llamas
Cc: linux-arm-kernel, Sami Tolvanen, Catalin Marinas, Peter Zijlstra,
Josh Poimboeuf, Ard Biesheuvel, Mark Rutland, Kees Cook,
Quentin Perret, Steven Rostedt, Will McVicker,
Sean Christopherson, kernel-team, linux-kernel
In-Reply-To: <20260313061852.4025964-1-cmllamas@google.com>
Hi Carlos,
On Fri, Mar 13, 2026 at 06:18:52AM +0000, Carlos Llamas wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Implement arm64 support for the 'unoptimized' static call variety, which
> routes all calls through a single trampoline that is patched to perform a
> tail call to the selected function.
>
> Since static call targets may be located in modules loaded out of direct
> branching range, we need to use a ADRP/ADD pair to load the branch target
> into R16 and use a branch-to-register (BR) instruction to perform an
> indirect call. Unlike on x86, there is no pressing need on arm64 to avoid
> indirect calls at all cost, but hiding it from the compiler as is done
> here does have some benefits:
> - the literal is located in .rodata, which gives us the same robustness
> advantage that code patching does;
> - no performance hit on CFI enabled Clang builds that decorate compiler
> emitted indirect calls with branch target validity checks.
>
> Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Carlos Llamas <cmllamas@google.com>
> ---
> v7:
> - Took Ard's v3 patch (as it leaves the code patching logic out) and
> rebased it on top of mainline 7.0-rc3.
> - Dropped the changes to arch/arm64/lib/insn.c and instead switched to
> the (now) existing aarch64_insn_write_literal_u64().
> - Added the RET0 trampoline define which points to the generic stub
> __static_call_return0.
> - Made the HAVE_STATIC_CALL conditional on CFI as suggested by Ard.
> - Added .type and .size sections to the trampoline definition to
> support ABI tools.
Are you planning to respin this based on Ard's comments?
Cheers,
Will
^ permalink raw reply
* Re: [GIT PULL 1/7] dt-bindings: Changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-30 11:39 UTC (permalink / raw)
To: Thierry Reding, arm, soc
Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-1-thierry.reding@kernel.org>
On 29/03/2026 17:10, Thierry Reding wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
>
> Hi ARM SoC maintainers,
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-dt-bindings
>
> for you to fetch changes up to bed2f5b4de6c6fd8f8928f6373ad92e8795c370f:
>
> dt-bindings: arm: tegra: Document Jetson AGX Thor DevKit (2026-03-28 01:05:24 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> dt-bindings: Changes for v7.1-rc1
>
> This contains a few conversions to DT schema along with various
> additions and fixes to reduce the amount of validation warnings.
>
> Included are also a new binding for the PCIe controller found on
> Tegra264 as well as compatible strings for the Jetson AGX Thor
> Developer Kit.
>
> ----------------------------------------------------------------
> Sumit Gupta (1):
> dt-bindings: arm: tegra: Add Tegra238 CBB compatible strings
>
> Svyatoslav Ryhel (1):
> dt-bindings: display: tegra: Document Tegra20 HDMI port
>
> Thierry Reding (9):
> dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
Why are you taking subsystem patches? This was posted on 26th of March
and was not acked by PCI maintainers.
How the bindings should go is already documented, so there is no
question here.
The question was whether you can take them if subsystem maintainer is
non-responsive and yes, you can. You gave PCI maintainers one day before
applying it.
> dt-bindings: phy: tegra-xusb: Document Type C support
No acks, but that is waiting for one month so it is fine.
> dt-bindings: clock: tegra124-dfll: Convert to json-schema
> dt-bindings: interrupt-controller: tegra: Fix reg entries
> dt-bindings: arm: tegra: Add missing compatible strings
> dt-bindings: phy: tegra: Document Tegra210 USB PHY
> dt-bindings: memory: Add Tegra210 memory controller bindings
> dt-bindings: memory: tegra210: Mark EMC as cooling device
That's even my subsystem and I did not ack it. You did not even sent it
to me as requested by MAINTAINERS file (+dt is ignore alias), so
obviously I did not even had a chance to ack it.
And we even had few days ago talk were I explained you how these
bindings must go. Seeing pull request completely ignoring that
discussion is just huge surprise.
No, it cannot go in. Send patches to proper maintainers first.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 1/7] dt-bindings: Changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-30 11:40 UTC (permalink / raw)
To: Thierry Reding, arm, soc
Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <406ca5ed-4a3e-48ba-94ad-d88c53b09299@kernel.org>
On 30/03/2026 13:39, Krzysztof Kozlowski wrote:
> On 29/03/2026 17:10, Thierry Reding wrote:
>> From: Thierry Reding <thierry.reding@gmail.com>
>>
>> Hi ARM SoC maintainers,
>>
>> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>>
>> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-dt-bindings
>>
>> for you to fetch changes up to bed2f5b4de6c6fd8f8928f6373ad92e8795c370f:
>>
>> dt-bindings: arm: tegra: Document Jetson AGX Thor DevKit (2026-03-28 01:05:24 +0100)
>>
>> Thanks,
>> Thierry
>>
>> ----------------------------------------------------------------
>> dt-bindings: Changes for v7.1-rc1
>>
>> This contains a few conversions to DT schema along with various
>> additions and fixes to reduce the amount of validation warnings.
>>
>> Included are also a new binding for the PCIe controller found on
>> Tegra264 as well as compatible strings for the Jetson AGX Thor
>> Developer Kit.
>>
>> ----------------------------------------------------------------
>> Sumit Gupta (1):
>> dt-bindings: arm: tegra: Add Tegra238 CBB compatible strings
>>
>> Svyatoslav Ryhel (1):
>> dt-bindings: display: tegra: Document Tegra20 HDMI port
>>
>> Thierry Reding (9):
>> dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
>
> Why are you taking subsystem patches? This was posted on 26th of March
> and was not acked by PCI maintainers.
>
> How the bindings should go is already documented, so there is no
> question here.
>
> The question was whether you can take them if subsystem maintainer is
> non-responsive and yes, you can. You gave PCI maintainers one day before
> applying it.
>
>
>> dt-bindings: phy: tegra-xusb: Document Type C support
>
> No acks, but that is waiting for one month so it is fine.
Ha, no, you did not even send it to maintainers, so how they could ack it?
Nothing here was sent to the right people.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64,ppc64le/kdump: pass dm-crypt keys to kdump kernel
From: Rob Herring @ 2026-03-30 11:44 UTC (permalink / raw)
To: Coiby Xu
Cc: kexec, linux-arm-kernel, linuxppc-dev, devicetree,
Arnaud Lefebvre, Baoquan he, Dave Young, Kairui Song, Pingfan Liu,
Andrew Morton, Krzysztof Kozlowski, Thomas Staudt, Sourabh Jain,
Will Deacon, Christophe Leroy (CS GROUP), Catalin Marinas,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Saravana Kannan, open list
In-Reply-To: <20260225060347.718905-4-coxu@redhat.com>
On Wed, Feb 25, 2026 at 12:04 AM Coiby Xu <coxu@redhat.com> wrote:
>
> CONFIG_CRASH_DM_CRYPT has been introduced to support LUKS-encrypted
> device dump target by addressing two challenges [1],
> - Kdump kernel may not be able to decrypt the LUKS partition. For some
> machines, a system administrator may not have a chance to enter the
> password to decrypt the device in kdump initramfs after the 1st kernel
> crashes
>
> - LUKS2 by default use the memory-hard Argon2 key derivation function
> which is quite memory-consuming compared to the limited memory reserved
> for kdump.
>
> To also enable this feature for ARM64 and PowerPC, the missing piece is
> to let the kdump kernel know where to find the dm-crypt keys which are
> randomly stored in memory reserved for kdump. Introduce a new device
> tree property dmcryptkeys [2] as similar to elfcorehdr to pass the
> memory address of the stored info of dm-crypt keys to the kdump kernel.
> Since this property is only needed by the kdump kernel, it won't be
> exposed to user space.
>
> [1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/
> [2] https://github.com/devicetree-org/dt-schema/pull/181
>
> Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com>
> Cc: Baoquan he <bhe@redhat.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Kairui Song <ryncsn@gmail.com>
> Cc: Pingfan Liu <kernelfans@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Thomas Staudt <tstaudt@de.ibm.com>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> arch/arm64/kernel/machine_kexec_file.c | 4 ++++
> arch/powerpc/kexec/elf_64.c | 4 ++++
> drivers/of/fdt.c | 21 +++++++++++++++++++++
> drivers/of/kexec.c | 19 +++++++++++++++++++
> 4 files changed, 48 insertions(+)
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-30 11:45 UTC (permalink / raw)
To: Thierry Reding, arm, soc
Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-6-thierry.reding@kernel.org>
On 29/03/2026 17:10, Thierry Reding wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
>
> Hi ARM SoC maintainers,
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-arm64-dt
>
> for you to fetch changes up to c70e6bc11d2008fbb19695394b69fd941ab39030:
>
> arm64: tegra: Add Tegra264 GPIO controllers (2026-03-28 01:36:46 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> arm64: tegra: Device tree changes for v7.1-rc1
>
> Various fixes and new additions across a number of devices. GPIO and PCI
> are enabled on Tegra264 and the Jetson AGX Thor Developer Kit, allowing
> it to boot via network and mass storage.
>
> ----------------------------------------------------------------
> Diogo Ivo (1):
> arm64: tegra: smaug: Enable SPI-NOR flash
>
> Jon Hunter (1):
> arm64: tegra: Fix RTC aliases
>
> Prathamesh Shete (1):
> arm64: tegra: Add Tegra264 GPIO controllers
>
> Thierry Reding (6):
> dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
This is unreviewed/unacked binding where PCI maintainers had 1 day to
react to your v3. Maybe they had more time for previous versions, but
nevertheless it is also part of other patchset, so it will get into the
kernel other tree and nothing on v3 posting:
https://lore.kernel.org/all/20260326135855.2795149-4-thierry.reding@kernel.org/
gives hints that there will be cross tree merge.
So no, that branch cannot be taken.
Please get your code first reviewed with subsystem maintainers.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 4/7] ARM: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-30 11:46 UTC (permalink / raw)
To: Thierry Reding, arm, soc
Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-4-thierry.reding@kernel.org>
On 29/03/2026 17:10, Thierry Reding wrote:
> ----------------------------------------------------------------
> ARM: tegra: Device tree changes for v7.1-rc1
>
> Various improvements for Tegra114 boards, as well as some legacy cleanup
> for PAZ00 and Transformers devices.
>
> ----------------------------------------------------------------
> Dmitry Torokhov (1):
> ARM: tegra: paz00: Configure WiFi rfkill switch through device tree
>
> Svyatoslav Ryhel (8):
> ARM: tegra: Add SOCTHERM support on Tegra114
> ARM: tn7: Adjust panel node
> ARM: tegra: lg-x3: Add panel and bridge nodes
> ARM: tegra: lg-x3: Add USB and power related nodes
> ARM: tegra: lg-x3: Add node for capacitive buttons
> ARM: tegra: Add ACTMON node to Tegra114 device tree
> ARM: tegra: Add External Memory Controller node on Tegra114
> ARM: tegra: transformers: Add connector node
>
> arch/arm/boot/dts/nvidia/tegra114-tn7.dts | 13 +-
> arch/arm/boot/dts/nvidia/tegra114.dtsi | 221 +++++++++++++++++++++++
> arch/arm/boot/dts/nvidia/tegra20-paz00.dts | 8 +
> arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts | 21 ++-
> arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 23 +++
> arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 33 ++++
> arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 174 +++++++++++++++++-
> arch/arm/mach-tegra/Makefile | 2 -
> arch/arm/mach-tegra/board-paz00.c | 56 ------
> arch/arm/mach-tegra/board.h | 2 -
> arch/arm/mach-tegra/tegra.c | 4 -
Why does the DTS branch has mach code? Tag message mentions legacy
cleanup only and such cleanup should not cause mixing independent
hardware description (DTS) with drivers.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive
From: Vishnu Pajjuri @ 2026-03-30 11:51 UTC (permalink / raw)
To: Marc Zyngier, Fuad Tabba
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Christoffer Dall, Mark Brown, kvm, linux-arm-kernel, kvmarm
In-Reply-To: <20251120172540.2267180-36-maz@kernel.org>
Hi Fuad Tabba,
I'm trying to run nested VMs on Ampere platforms after this patch
series(v6.19+) but nested VMs are not booting and triggering soft
lockups on L0 and L0 hang. But just before this patch I could able to
successfully boot the Nested VMs.
I bisected the failure to a single commit which is this patch which is
causing the issue.
I would like to understand from you that did you observed anything like
that?
Were you able to boot Nested VMs successfully after v6.19+?
LOG:
[ 164.647367] Call trace:
[ 164.647368] smp_call_function_many_cond+0x334/0x7a0 (P)
[ 164.647372] smp_call_function_many+0x20/0x40
[ 164.647374] kvm_make_all_cpus_request+0xec/0x1b8
[ 164.647377] vgic_queue_irq_unlock+0x1c8/0x2c8
[ 164.647380] kvm_vgic_inject_irq+0x194/0x1e0
[ 164.647381] kvm_vm_ioctl_irq_line+0x170/0x400
[ 164.647386] kvm_vm_ioctl+0x7b8/0xc88
[ 164.647389] __arm64_sys_ioctl+0xb4/0x118
[ 164.647393] invoke_syscall+0x6c/0x100
[ 164.647397] el0_svc_common.constprop.0+0x48/0xf0
[ 164.647398] do_el0_svc+0x24/0x38
[ 164.647400] el0_svc+0x3c/0x170
[ 164.647403] el0t_64_sync_handler+0xa0/0xe8
[ 164.647405] el0t_64_sync+0x1b0/0x1b8
Regards,
-Vishnu.
On 20-11-2025 22:55, Marc Zyngier wrote:
> Pretty much like the rest of the LR handling, deactivation of an
> L2 interrupt gets reflected in the L1 LRs, and therefore must be
> propagated into the L1 shadow state if the interrupt is HW-bound.
>
> Instead of directly handling the active state (which looks a bit
> off as it ignores locking and L1->L0 HW propagation), use the new
> deactivation primitive to perform the deactivation and deal with
> the required maintenance.
>
> Tested-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/vgic/vgic-v3-nested.c | 19 +++++++++----------
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v3-nested.c b/arch/arm64/kvm/vgic/vgic-v3-nested.c
> index 40f7a37e0685c..15e7033a7937e 100644
> --- a/arch/arm64/kvm/vgic/vgic-v3-nested.c
> +++ b/arch/arm64/kvm/vgic/vgic-v3-nested.c
> @@ -280,7 +280,6 @@ void vgic_v3_sync_nested(struct kvm_vcpu *vcpu)
>
> for_each_set_bit(i, &shadow_if->lr_map, kvm_vgic_global_state.nr_lr) {
> u64 val, host_lr, lr;
> - struct vgic_irq *irq;
>
> host_lr = __gic_v3_get_lr(lr_map_idx_to_shadow_idx(shadow_if, i));
>
> @@ -290,7 +289,14 @@ void vgic_v3_sync_nested(struct kvm_vcpu *vcpu)
> val |= host_lr & ICH_LR_STATE;
> __vcpu_assign_sys_reg(vcpu, ICH_LRN(i), val);
>
> - if (!(lr & ICH_LR_HW) || !(lr & ICH_LR_STATE))
> + /*
> + * Deactivation of a HW interrupt: the LR must have the HW
> + * bit set, have been in a non-invalid state before the run,
> + * and now be in an invalid state. If any of that doesn't
> + * hold, we're done with this LR.
> + */
> + if (!((lr & ICH_LR_HW) && (lr & ICH_LR_STATE) &&
> + !(host_lr & ICH_LR_STATE)))
> continue;
>
> /*
> @@ -298,14 +304,7 @@ void vgic_v3_sync_nested(struct kvm_vcpu *vcpu)
> * need to emulate the HW effect between the guest hypervisor
> * and the nested guest.
> */
> - irq = vgic_get_vcpu_irq(vcpu, FIELD_GET(ICH_LR_PHYS_ID_MASK, lr));
> - if (WARN_ON(!irq)) /* Shouldn't happen as we check on load */
> - continue;
> -
> - if (!(host_lr & ICH_LR_STATE))
> - irq->active = false;
> -
> - vgic_put_irq(vcpu->kvm, irq);
> + vgic_v3_deactivate(vcpu, FIELD_GET(ICH_LR_PHYS_ID_MASK, lr));
> }
>
> /* We need these to be synchronised to generate the MI */
^ permalink raw reply
* Re: [PATCH v8 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
From: André Draszik @ 2026-03-30 12:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown
Cc: Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm
In-Reply-To: <355b2f8f-0a3e-4209-8b1e-10600c2b3df9@kernel.org>
On Sat, 2026-03-21 at 20:14 +0100, Krzysztof Kozlowski wrote:
>
> This causes warnings, so I dropped the patches.
I assume warnings are because I didn't make it clear enough that patch
2 is actually required?
> I really do not
> understand how this is organized. This is not a dependency for pm
> domains driver but it is included here.
The binding is being updated, and the driver follows suit.
I particular, the driver needs to be aware that pd is (can be) a child
of pmu.
Yes, the driver does not depend on this binding update, but it shows what
the driver must support. I believe this is what we have done in the past:
binding and driver updates in same series.
I could move patches 3 and 4 from this series together with a DTS
update patch into a separate series, if that would be deemed a better
approach?
> It is a soft dependency for DTS,
> but that is nowhere to be found.
I was waiting for review of all binding changes before posting DTS.
Cheers,
Andre'
^ permalink raw reply
* [PATCH 0/5] cpufreq: ti: Fix probe ordering and add device link support for K3 SoCs
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
For K3 SoCs, ti-cpufreq depends on k3-socinfo to provide SoC revision
information via soc_device_match(). If ti-cpufreq probes before
k3-socinfo, soc_device_match() returns NULL, causing incorrect
revision detection and OPP table initialization failures.
Add EPROBE_DEFER handling in ti-cpufreq when soc_device_match() fails
for K3 SoCs, ensuring k3-socinfo probes first.
Add device link support via a new DT property "ti,soc-info" in CPU
OPP tables. Device links prevent unbinding k3-socinfo while
ti-cpufreq is using it.
EPROBE_DEFER handles first-boot probe ordering, while device links
provide runtime dependency management.
For backward compatibility, the DT property is optional.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
Akashdeep Kaur (5):
cpufreq: ti: Add EPROBE_DEFER for K3 SoCs
arm64: dts: ti: k3-am625: Add ti,soc-info to OPP table
arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
arm64: dts: ti: k3-am62p5: Add ti,soc-info to OPP table
cpufreq: ti: Add device link to k3-socinfo
arch/arm64/boot/dts/ti/k3-am625.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 1 +
drivers/cpufreq/ti-cpufreq.c | 57 +++++++++++++++++++++++++++
4 files changed, 60 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH 1/5] cpufreq: ti: Add EPROBE_DEFER for K3 SoCs
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Defer probe when k3-socinfo hasn't registered the SoC device yet.
Fixes incorrect revision detection when ti-cpufreq probes first.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 3d1129aeed02..88f7912ef6a8 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -441,6 +441,15 @@ static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
*/
*revision_value = 0x1;
goto done;
+ } else if (opp_data->soc_data == &am625_soc_data ||
+ opp_data->soc_data == &am62a7_soc_data ||
+ opp_data->soc_data == &am62l3_soc_data ||
+ opp_data->soc_data == &am62p5_soc_data) {
+ /*
+ * For K3 SoCs, if soc_device_match fails, socinfo hasn't
+ * probed yet. Defer probe to wait for it.
+ */
+ return -EPROBE_DEFER;
}
ret = regmap_read(opp_data->syscon, opp_data->soc_data->rev_offset,
--
2.34.1
^ permalink raw reply related
* [PATCH 2/5] arm64: dts: ti: k3-am625: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am625.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am625.dtsi b/arch/arm64/boot/dts/ti/k3-am625.dtsi
index c249883a8a8d..b0020e667882 100644
--- a/arch/arm64/boot/dts/ti/k3-am625.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am625.dtsi
@@ -109,6 +109,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
index b6e5eee99370..6d1459e9ea71 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
@@ -109,6 +109,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Create explicit device link when OPP table has ti,soc-info property.
Prevents unbinding k3-socinfo while ti-cpufreq is using it.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 48 ++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 88f7912ef6a8..60c34b0da0c5 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/of.h>
+#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/pm_opp.h>
#include <linux/regmap.h>
@@ -111,6 +112,7 @@ struct ti_cpufreq_data {
struct device_node *opp_node;
struct regmap *syscon;
const struct ti_cpufreq_soc_data *soc_data;
+ struct device_link *soc_link;
};
static unsigned long amx3_efuse_xlate(struct ti_cpufreq_data *opp_data,
@@ -542,6 +544,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
return -ENOMEM;
opp_data->soc_data = match->data;
+ platform_set_drvdata(pdev, opp_data);
opp_data->cpu_dev = get_cpu_device(0);
if (!opp_data->cpu_dev) {
@@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
if (ret)
goto fail_put_node;
+ /* Create device link to k3-socinfo if specified in DT */
+ if (opp_data->soc_data == &am625_soc_data ||
+ opp_data->soc_data == &am62a7_soc_data ||
+ opp_data->soc_data == &am62l3_soc_data ||
+ opp_data->soc_data == &am62p5_soc_data) {
+ struct device_node *socinfo_np;
+
+ socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
+ if (socinfo_np) {
+ struct platform_device *socinfo_pdev;
+ struct device_link *link;
+
+ socinfo_pdev = of_find_device_by_node(socinfo_np);
+ of_node_put(socinfo_np);
+
+ if (!socinfo_pdev) {
+ ret = -EPROBE_DEFER;
+ goto fail_put_node;
+ }
+
+ if (!socinfo_pdev->dev.driver) {
+ put_device(&socinfo_pdev->dev);
+ ret = -EPROBE_DEFER;
+ goto fail_put_node;
+ }
+
+ link = device_link_add(opp_data->cpu_dev,
+ &socinfo_pdev->dev,
+ DL_FLAG_STATELESS);
+ if (link)
+ opp_data->soc_link = link;
+
+ put_device(&socinfo_pdev->dev);
+ }
+ }
+
/*
* OPPs determine whether or not they are supported based on
* two metrics:
@@ -600,6 +639,14 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
return ret;
}
+static void ti_cpufreq_remove(struct platform_device *pdev)
+{
+ struct ti_cpufreq_data *opp_data = platform_get_drvdata(pdev);
+
+ if (opp_data && opp_data->soc_link)
+ device_link_del(opp_data->soc_link);
+}
+
static int __init ti_cpufreq_init(void)
{
const struct of_device_id *match;
@@ -616,6 +663,7 @@ module_init(ti_cpufreq_init);
static struct platform_driver ti_cpufreq_driver = {
.probe = ti_cpufreq_probe,
+ .remove = ti_cpufreq_remove,
.driver = {
.name = "ti-cpufreq",
},
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v8 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
From: Krzysztof Kozlowski @ 2026-03-30 12:10 UTC (permalink / raw)
To: André Draszik, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown
Cc: Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm
In-Reply-To: <dcf2c447d9bbe16e800a4dd7e74ecc26d3ade3db.camel@linaro.org>
On 30/03/2026 14:00, André Draszik wrote:
> On Sat, 2026-03-21 at 20:14 +0100, Krzysztof Kozlowski wrote:
>>
>> This causes warnings, so I dropped the patches.
>
> I assume warnings are because I didn't make it clear enough that patch
> 2 is actually required?
No, these are obvious errors coming from bindings. You can try yourself
instead of asking maintainer to run the commands for you...
>
>> I really do not
>> understand how this is organized. This is not a dependency for pm
>> domains driver but it is included here.
>
> The binding is being updated, and the driver follows suit.
> I particular, the driver needs to be aware that pd is (can be) a child
> of pmu.
>
> Yes, the driver does not depend on this binding update, but it shows what
> the driver must support. I believe this is what we have done in the past:
> binding and driver updates in same series.
Yes, foo-binding goes with foo-driver to foo-subsystem. It does not mean
you put here completely different bindings. Why? Because just like foo
goes to foo-subsystem, then bar-binding goes with bar-driver to
bar-subsystem.
>
> I could move patches 3 and 4 from this series together with a DTS
> update patch into a separate series, if that would be deemed a better
> approach?
I asked you what are the dependencies and you answer there are some but
you can move it outside of patchset. So are there or are there not
dependencies? If there are, then you cannot move out. But then I ask
what are the dependencies.
It feels like question to trick the maintainer. Maintainer complained,
so you propose whatever he objected to without understanding whether
this is correct or not correct approach.
>
>> It is a soft dependency for DTS,
>> but that is nowhere to be found.
>
> I was waiting for review of all binding changes before posting DTS.
That would be fine explanation, if you also read maintainer soc profile
for Samsung and try what is written there. You would see that you
introduced new warnings without any fix possible as far as next is
concerned.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Geert Uytterhoeven @ 2026-03-30 12:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King, Christian Schrefl, Miguel Ojeda, Alice Ryhl,
Ard Biesheuvel, Jamie Cunliffe, Will Deacon, Catalin Marinas,
Miguel Ojeda, Andreas Hindborg, acourbot, Andrew Morton,
Anton Ivanov, Björn Roy Baron, Boqun Feng, Danilo Krummrich,
David Gow, Gary Guo, Johannes Berg, Justin Stitt,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-mm, linux-um,
llvm, Benno Lossin, Mark Rutland, mmaurer, Bill Wendling,
Nathan Chancellor, Nick Desaulniers, Nicolas Schier,
Nicolas Schier, Peter Zijlstra, Richard Weinberger,
rust-for-linux, Trevor Gross, Uladzislau Rezki (Sony),
John Paul Adrian Glaubitz
In-Reply-To: <93439e91-cf81-477b-b880-a813bb01ad7c@app.fastmail.com>
Hi Arnd,
On Fri, 27 Mar 2026 at 10:02, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Mar 27, 2026, at 08:56, Geert Uytterhoeven wrote:
> >> I noticed a similar issue with m68k-linux, which has a bitfield
> >> alignment different from anything else on gcc, but uses the normal
> >> behavior on clang.
> >
> > Ugh, I wasn't aware of that. Adrian, did you know?
>
> To clarify, this illustrates what I mean here:
>
> echo 'struct { short a : 3; short b :15; short c :14; } x; int y = sizeof(x);' | m68k-linux-gcc -xc - -S -o-
>
> this produces '4' on m68k-linux-gcc, but '6' everywhere else. I originally
> thought this was related to this 2009 change in both compilers
Oh, now I remember. AFAIK (holding wood and a rabbit leg) we don't
have any bitfield members spanning multiple base type instances in
the kernel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Arnd Bergmann @ 2026-03-30 12:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Christian Schrefl, Miguel Ojeda, Alice Ryhl,
Ard Biesheuvel, Jamie Cunliffe, Will Deacon, Catalin Marinas,
Miguel Ojeda, Andreas Hindborg, acourbot, Andrew Morton,
Anton Ivanov, Björn Roy Baron, Boqun Feng, Danilo Krummrich,
David Gow, Gary Guo, Johannes Berg, Justin Stitt,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-mm, linux-um,
llvm, Benno Lossin, Mark Rutland, mmaurer, Bill Wendling,
Nathan Chancellor, Nick Desaulniers, Nicolas Schier,
Nicolas Schier, Peter Zijlstra, Richard Weinberger,
rust-for-linux, Trevor Gross, Uladzislau Rezki (Sony),
John Paul Adrian Glaubitz
In-Reply-To: <CAMuHMdU-+dm83TVttfarT7QxE5ySpQ2LJ_k6oFKMWRcbaWcCdA@mail.gmail.com>
On Mon, Mar 30, 2026, at 14:03, Geert Uytterhoeven wrote:
> On Fri, 27 Mar 2026 at 10:02, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> echo 'struct { short a : 3; short b :15; short c :14; } x; int y = sizeof(x);' | m68k-linux-gcc -xc - -S -o-
>>
>> this produces '4' on m68k-linux-gcc, but '6' everywhere else. I originally
>> thought this was related to this 2009 change in both compilers
>
> Oh, now I remember. AFAIK (holding wood and a rabbit leg) we don't
> have any bitfield members spanning multiple base type instances in
> the kernel.
There are certainly very few of those, but two example I found in
UAPI are
struct dvd_layer {
__u8 book_version : 4;
__u8 book_type : 4;
__u8 min_rate : 4;
__u8 disc_size : 4;
__u8 layer_type : 4;
__u8 track_path : 1;
__u8 nlayers : 2;
__u8 track_density : 4; // crosses u8 boundary
__u8 linear_density : 4;
__u8 bca : 1;
__u32 start_sector;
__u32 end_sector;
__u32 end_sector_l0;
};
struct usb_raw_ep_caps {
__u32 type_control : 1;
__u32 type_iso : 1;
__u32 type_bulk : 1;
__u32 type_int : 1;
__u32 dir_in : 1;
__u32 dir_out : 1;
// 2 bit padding on m68k, 26 bits elsewhere
};
Arnd
^ 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