* Re: [PATCH v8 00/21] ARM64 PMU Partitioning
From: James Clark @ 2026-07-27 11:04 UTC (permalink / raw)
To: Colton Lewis
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, linux-doc,
linux-kernel, linux-arm-kernel, kvmarm, linux-perf-users,
linux-kselftest
In-Reply-To: <gsnt33x95sra.fsf@coltonlewis-kvm.c.googlers.com>
On 23/07/2026 9:57 pm, Colton Lewis wrote:
> James Clark <james.clark@linaro.org> writes:
>
>> On 22/07/2026 12:03 am, Colton Lewis wrote:
>>> Hi James, thanks for the review.
>
>>> James Clark <james.clark@linaro.org> writes:
>>>> Hi Colton,
>
>>>> The existence of the parameter makes sense, but can't the default be
>>>> arm_pmuv3.reserved_host_counters=0 instead of -1 (partition disabled)?
>
>>> How would you interpret reserved_host_counters=0? Because that would
>>> express that the host should have zero counters and the guest gets them
>>> all. I remember in early versions of this series last year I did use 0
>>> as the default but reviewers asked for a way to express the scenario of
>>> of zero counters for the host.
>
>
>> I think I would interpret it as it is now. Can't the host still use them
>> until the guest does and then they only get squeezed if there is a
>> collision? That doesn't sound too bad to me. And if a host wants
>> reserved counters they can set a positive number.
>
> Yeah that makes sense. I was thinking in an old headspace when it was
> just a static reservation instead of changing when a guest is loaded.
>
>> Is reserved_host_counters==max_counters equivalent to -1? And there's no
>> overview in the cover letter or documentation about how it interacts
>> with the dynamic guest counter reservations. A bit more detail or a few
>> paragraphs in one place would help users, maybe with examples so they
>> don't have to piece together all the commit messages to work it out.
>
> It's not equivalent since we need a case where the guest only has access
> to the fixed-purpose counters like the dedicated cycle
> counter. reserved_host_counters specifies the number of general purpose
> counters.
>
> I'll document the operation more clearly. In the future please feel free
> to email me to ask if you are confused about something.
>
>>>> It's still a bit fiddly having to do two things to make it work, and
>>>> there's no documentation about what the defaults or other prerequisites
>>>> are. IMO it's not even trivial to work out that you need to prefix it
>>>> with "arm_pmuv3.", which documentation would improve.
>
>>> It is fiddly, which is why the more I think about it the more I'd rather
>>> ditch the kernel cmdline entirely and leave it up to KVM. That's the
>>> most flexible approach. There isn't a good way to change the cmdline
>>> after boot. Trying to make it writeable via sysfs runs into the problem
>>> of when is it safe to apply the change.
>
>>> I thought it was commonly understood module parameters need to be
>>> prefixed by the module name, but I can add better documentation to that
>>> effect.
>
>
>
>> People just want it written out fully somewhere so they can copy paste
>> it. Kernel developers might be able to piece it together, but not
>> everyone will.
>
> This is the KVM mailing list. Kernel developers are the primary
> audience, but I will make reasonable efforts to include others in the
> future.
>
I'm more thinking of the users of this after it gets merged, rather than
just for the review.
>>>> Testing the whole set I ran into a few issues:
>
>>>> This warn is hit when there is some kind of interaction with
>>>> sleeping. I
>>>> tried to bisect it but it only appears on the last commit when the
>>>> option to enable partitioning is added.
>
>>>> /*
>>>> * ARM pmu always has to reprogram the period, so ignore
>>>> * PERF_EF_RELOAD, see the comment below.
>>>> */
>>>> if (flags & PERF_EF_RELOAD)
>>>> WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
>
>>>> Steps to reproduce:
>
>>>> Host (arm_pmuv3.reserved_host_counters=0):
>>>> $ sudo perf stat -C 2 -e \
>>>> 'branches,branches,branches,branches,branches,branches'
>>>> $ sudo taskset --cpu-list 2 ./lkvm run --kernel \
>>>> /boot/vmlinux-7.1.0-rc7+ -m 1024 -c 1 --pmu
>
>>>> Guest:
>>>> $ sleep 1
>
>>>> WARNING: drivers/perf/arm_pmu.c:302 at
>>>> cpu_pm_pmu_notify+0x278/0x2c0,
>>>> CPU#2: swapper/2/0
>>>> Call trace:
>>>> cpu_pm_pmu_notify+0x278/0x2c0 (P)
>>>> notifier_call_chain+0x84/0x1d0
>>>> raw_notifier_call_chain+0x24/0x38
>>>> cpu_pm_exit+0x34/0x68
>>>> acpi_processor_ffh_lpi_enter+0x40/0x78
>>>> acpi_idle_lpi_enter+0x54/0x78
>>>> cpuidle_enter_state+0xb4/0x248
>>>> cpuidle_enter+0x44/0x68
>>>> do_idle+0x21c/0x300
>>>> cpu_startup_entry+0x40/0x50
>>>> secondary_start_kernel+0x120/0x150
>>>> __secondary_switched+0xc0/0xc8
>
>
>>> I'll attempt to reproduce that. I've never seen it myself but I've
>>> mainly been using QEMU for my testing.
>
>
>> The newest Arm FVP should have cpuidle enabled if you boot it with ACPI,
>> but I hit this on a Radxa Orion O6 board.
>
> Noted. Thanks.
>
>
>>>> When running the guest on a single CPU I get different counts for the
>>>> same event for a single process, although this never happens on a host.
>>>> I think there might even be some Perf tests which expect them to be the
>>>> same, and this doesn't depend on whether any events are running on the
>>>> host or not. Not sure if you ran all the Perf selftests in a guest or
>>>> not?
>
>>> I'll investigate but I'm not sure perf is intended to guarantee
>>> that. perf stat just runs the event counters but may not write or read
>>> them at exactly the same time.
>
>
>> Is that true? The perf core calls perf_pmu_disable() when a process is
>> scheduled out before reading the count of each event of that process in
>> an inner loop. The perf_pmu_disable() clears PMCR_EL0.E which freezes
>> all of the counters so they can be read out in a consistent state.
>
>> It's important that they're all stopped at the same time because
>> counters might be used in metrics as ratios of each other. So I think
>> it's deliberately designed that way and appears to not be working in a
>> guest now.
>
> By default I think perf assumes events can be measured independently, If
> you want to guarantee events are scheduled together to avoid measurement
> skew you need to make sure the events are grouped.
>
> The common way to do that is with {} around the event list:
>
> perf stat -e {branches,branches}
>
> Please see if that resolves the issue.
>
Groups only change how the events are scheduled, not how the driver
starts or stops multiple events running on the same PMU (grouped or
ungrouped). In my repro I had less events than counters in HW, so they
will always be scheduled at the same time regardless of grouping.
I did notice something extra though, you have to first open some amount
of counters, and then open more than that. Then the second time the ones
with different counts will be however many were opened first time, as if
some state has stuck.
For example if I open two counters then 6, the first two always have
different counts the second time:
$ perf stat -e branches,branches true
Performance counter stats for 'true':
106129 branches
106129 branches
$ perf stat -e
'{branches,branches,branches,branches,branches,branches}' true
Performance counter stats for 'true':
117013 branches
117013 branches
110364 branches
110364 branches
110364 branches
110364 branches
After opening 6 again a third time they'll all have the same counts.
>>>> I'm not sure if the exception level filtering isn't working or there is
>>>> something wrong with freezing. Doesn't the host PMU driver need to
>>>> freeze with HPME? I see it's still doing it with PMCR_EL0.E which
>>>> freezes the guest's counters now doesn't it?
>
>>> HPME only has any effect while HPMN is programmed to a value different
>>> than the number of counters on the system. That is only true in a guest
>>> context. As I understand it, that means HPME has no effect anywhere the
>>> host driver needs to freeze counters since that happens in host context.
>
>
>> Oh yeah that makes sense, I didn't think about that. I'm not sure if my
>> other idea about exception level filtering being responsible makes sense
>> either.
>
> I'll check that too.
>
>>> Maybe HPMN stays programmed during interrupt handling though. I'll
>>> confirm.
>
>
>>>> Host (arm_pmuv3.reserved_host_counters=0):
>>>> $ sudo taskset --cpu-list 2 ./lkvm run --kernel \
>>>> /boot/vmlinux-7.1.0-rc7+ -m 1024 -c 1 --pmu
>
>>>> Guest:
>>>> $ perf stat -e branches,branches true
>
>>>> Performance counter stats for 'true':
>
>>>> 167963 branches
>
>>>> 160925 branches
>
>
>>>> $ perf stat -e branches,branches,branches,branches,branches true
>
>>>> Performance counter stats for 'true':
>
>>>> 164425 branches
>
>>>> 164425 branches
>
>>>> 164425 branches
>
>>>> 157743 branches
>
>>>> 157743 branches
>
>
>>>> When running the guest on two CPUs I just get zeros. Do the kvm
>>>> selftests not catch this? Or is it something to do with my setup:
>
>>> KVM selftests definitely don't catch it. I'll see if I can reproduce.
>
>>> Since the problem happens with 2 CPUs I wonder if something is
>>> triggering the lazy context swap behavior so the counter values aren't
>>> being moved to the 2nd CPU correctly.
>
>
>> If that was the case I would have expected it to be intermittent, or you
>> would get a partial count if the second CPU started from 0, but not
>> zeros every where every time. Let me know if I can run any more tests.
>
> I'll let you know if I think of something.
>
>>>> Host (arm_pmuv3.reserved_host_counters=0):
>>>> $ sudo taskset --cpu-list 2-3 ./lkvm run --kernel \
>>>> /boot/vmlinux-7.1.0-rc7+ -m 1024 -c 1 --pmu
>
>>>> Guest:
>>>> $ perf stat -e branches,branches true
>
>>>> Performance counter stats for 'true':
>
>>>> 0 branches
>
>>>> 0 branches
>
>>>> I also noticed I get the "squeezed" warning printed after launching the
>>>> guest but not using Perf. This comment implies that not using counters
>>>> makes it a nop:
>
>>>> /*
>>>> * If we aren't guest-owned then we know the guest isn't using
>>>> * the PMU anyway, so no need to bother with the swap.
>>>> */
>>>> if (vcpu->arch.pmu.access != VCPU_PMU_ACCESS_GUEST_OWNED)
>>>> return;
>
>>>> But maybe linux is touching them in a way that makes them guest owned,
>>>> even on probe? Or is the guest/host ownership tracking not working, I
>>>> didn't look too hard.
>
>>> Maybe. I'll check. The guest is also running its own PMU driver that
>>> might trigger guest ownership on initialization since ownership is
>>> determined by which registers the guest touches.
>
>
>> It doesn't enable any counters though does it, even if it touches some
>> of the registers to probe? Should that result in squeezing out host
>> counters? Maybe it's more complicated to implement, but right now it
>> seems like there is some complexity without much benefit as 90% of hosts
>> are going to probe the counters just to see what's there but not use
>> them.
>
> As far as I'm aware the driver probe shouldn't shouldn't enable any
> counters or trigger squeezing. I'll narrow the conditions that trigger
> guest ownership.
>
> My first suspect is the guest driver probe is triggering guest ownership
> by reading PMCR_EL0, which I agree should be changed to avoid that.
^ permalink raw reply
* Re: [PATCH 1/8] arm64: dts: exynos: Move 'status' to the end to match coding style
From: André Draszik @ 2026-07-27 11:04 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ivaylo Ivanov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Peter Griffin, Alim Akhtar,
Sam Protsenko, Tudor Ambarus, Krzysztof Kozlowski, linux-fsd
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
In-Reply-To: <20260726-b4-dts-coding-style-strict-v1-1-e9e3e9879d05@oss.qualcomm.com>
Hi Krzysztof,
On Sun, 2026-07-26 at 19:43 +0200, Krzysztof Kozlowski wrote:
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index fa2029e280a5..17b13a586973 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -755,6 +755,7 @@ tmu_atlas0: tmu@10060000 {
> <&cmu_peris CLK_SCLK_TMU0>;
> clock-names = "tmu_apbif", "tmu_sclk";
> #thermal-sensor-cells = <0>;
> +
> status = "disabled";
> };
>
> @@ -766,7 +767,9 @@ tmu_atlas1: tmu@10068000 {
> <&cmu_peris CLK_SCLK_TMU0>;
> clock-names = "tmu_apbif", "tmu_sclk";
> #thermal-sensor-cells = <0>;
> +
> status = "disabled";
> +
> };
This adds an extra empty line.
Cheers,
A.
^ permalink raw reply
* Re: [PATCH v1] pmdomain: mediatek: Fix MT8183 hang on boot
From: AngeloGioacchino Del Regno @ 2026-07-27 10:57 UTC (permalink / raw)
To: Brady Norander, Dmitry Osipenko, Ulf Hansson, Matthias Brugger
Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <fe909054-5c9d-42f5-bbc1-66ca0ace72de@mainlining.org>
On 7/25/26 07:11, Brady Norander wrote:
> On 7/22/26 09:27, Dmitry Osipenko wrote:
>> Depending on firmware, part of the MFG domains may be left ON at boot
>> leaving only some MFG cores powered, to let the ACP to prefetch the GPU
>> region when the display controller is brought up. This doesn't play well
>> with an eventual delay in probing Panfrost when the display controller is
>> fully set up, as that would make genpd's sync_state() to power off the
>> domain while ACP tries to prefetch: this is causing an AXI stall,
>> effectively freezing the AP indefinitely. In order to prevent this from
>> happening, the sync_state() functionality must be obliterated on all of
>> the MFG domains: while this guarantees a power leakage if the bootloader
>> boots the kernel with MFG PDs partially powered on, this is the only way
>> to ensure stable operation of the SoC during boot on devices with such
>> firmware because, of course, those will never officially receive a
>> firmware update.
>>
>> Fixes Kappa Chromebook hanging during system boot.
>
> I also saw this same issue on my MT8192 Hayato Chromebook, and I also saw an issue
> on my MT8183 and MT8186 Chromebooks where the audio was broken. I fixed all of
> those issues by setting the GENPD_FLAG_NO_STAY_ON flag on all domains. I held off
> from submitting that change as I was unsure if it was the "correct" way to handle
> it, but perhaps it is. Either way, this issue is not specific to only MT8183.
Audio is something a bit different I believe.
For MFG on MT8183 specifically (and potentially same generation or even slightly
older) there's an issue that is very specific and described in the description
of this commit.
So, specifically for audio, I think that there may be something else that is
wrong if you're seeing such a behavior - as in, some dependencies may be missing
from somewhere (some devicetree node), or something else.
In any case, I'm always open for discussion, of course.
^ permalink raw reply
* Re: [PATCH 0/2] Add arm-smmu-v3 support for instcfg data override feature
From: Robin Murphy @ 2026-07-27 10:53 UTC (permalink / raw)
To: Will Deacon, Peter Griffin
Cc: Joerg Roedel (AMD), Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pranjal Shrivastava, Daniel Mentz, Mostafa Saleh,
linux-arm-kernel, iommu, devicetree, linux-kernel, kernel-team,
tudor.ambarus, andre.draszik, willmcvicker, jyescas
In-Reply-To: <amYIuhYenP4-qHyV@willie-the-truck>
On 26/07/2026 2:16 pm, Will Deacon wrote:
> On Fri, Jul 24, 2026 at 01:39:41PM +0100, Peter Griffin wrote:
>> These two patches add support for a new "arm,instdata-override" DT property
>> that enables the override of the instruction/data attribute of incoming
>> traffic to Data by setting the INSTCFG override bits.
>>
>> It is intended to be specified when the smmu can't guarantee that these
>> attributes are provided correctly from the client device.
>
> This is going to need an in-tree user and a much more detailed
> description of what is being worked around before we consider this for
> inclusion.
>
> In particular, if a particular client is emitting data reads as
> instructions, then a better work around would be to avoid mapping its
> domains using IOMMU_NOEXEC. But I can't tell what's going on from the
> limited description provided here.
Unless it's also emitting the privileged bit and thus falling foul of
the implicit Unpriv-W -> Priv-XN rule, but then we also have the means
to deal with devices which actually do that themselves (hello pl330...),
so that would seemingly only leave the case of some innocent piece of
AMBA-interfaced IP which doesn't expect to need special attributes, but
the system integrator has gone out of their way to tie the AxPROT bits
to some wacky value, which I would put in "erratum workaround" territory.
Thanks,
Robin.
^ permalink raw reply
* Re: [PATCH] irqchip/gic: Simplify Maintenance Interrupt ACPI parsing
From: Zenghui Yu @ 2026-07-27 10:50 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-kernel, linux-arm-kernel, Thomas Gleixner, radu,
Sascha Bischoff
In-Reply-To: <20260725155941.114322-1-maz@kernel.org>
On 2026/7/25 23:59, Marc Zyngier wrote:
> The ACPI spec describes the vgic Maintenance Interrupt with attributes
> indicating whether the signalling is Level or Edge. While this
> superficially looks like a sensible thing to do, it doesn't actually
> make much sense.
>
> By construction, this interrupt is Level, and cannot be anything
> else, as the hypervisor actively needs to interact with the vgic
> for the level to drop. This indicates a state, and not an event.
>
> Get rid of this nonsense, always register the corresponding GSI as
> Level, and let the user know that they run on quality FW should
> the interrupt be advertised as Edge.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> drivers/irqchip/irq-gic-v3.c | 10 +++-------
> drivers/irqchip/irq-gic.c | 8 ++++----
> 2 files changed, 7 insertions(+), 11 deletions(-)
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Thanks,
Zenghui
^ permalink raw reply
* Re: [PATCH v2 2/2] iommu/arm-smmu-v3: Add HAFT support for SVA
From: Robin Murphy @ 2026-07-27 10:27 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe
Cc: catalin.marinas, joro, jpb, iommu, linux-arm-kernel
In-Reply-To: <amcTBlw16RKuZC8y@willie-the-truck>
On 27/07/2026 9:12 am, Will Deacon wrote:
> On Sun, Jul 26, 2026 at 01:10:19PM -0300, Jason Gunthorpe wrote:
>> On Sun, Jul 26, 2026 at 01:00:38PM +0100, Will Deacon wrote:
>>> On Sat, Jul 25, 2026 at 11:27:59AM -0300, Jason Gunthorpe wrote:
>>>> On Thu, Jul 23, 2026 at 03:19:44PM +0100, Robin Murphy wrote:
>>>>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
>>>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
>>>>> @@ -102,6 +102,8 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
>>>>> target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
>>>>> if (master->smmu->features & ARM_SMMU_FEAT_HD)
>>>>> target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
>>>>> + if (master->smmu->features & ARM_SMMU_FEAT_HAFT && system_supports_haft())
>>>>> + target->data[1] |= cpu_to_le64(CTXDESC_CD_1_HAFT);
>>>>> } else {
>>>>> target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_EPD0);
>>>>
>>>> Based on the Sashiko remark and your note you should lift all the
>>>> HA/HD/HAFT bits outside this if (mm) block.
>>>>
>>>> AFAICT it is fine for HA/HD/HAFT to be set with EPD0, the HW won't
>>>> process any PTEs so they won't have any effect.
>>>
>>> I'm not sure about that. The spec says this about CD.HAFT:
>>
>> Sorry I see this was unclear
>>
>> I ment to move all *three* bits outside the if.
>>
>> There is no reason for EPD0 to also require setting any of those three
>> bits to zero, AFAICT.
>
> Ah, gotcha! And even if we did want to get to that configuration, I
> guess you could set EPD0, then clear HAFT, then clear HA+HD?
Indeed, it also occurred to me on the way home on Friday that in this
case we probably could get away with just setting HA/HD/HAFT
consistently in all SVA CDs irrespective of the mm. Strictly, EPD0 only
forbids *new* walks from using TTB0, so there might potentially be some
outstanding PTE updates still made in the window between the config
update and the TLBI at the end of arm_smmu_mm_release(), but that
shouldn't be harmful.
Lemme spin a v3...
Cheers,
Robin.
^ permalink raw reply
* Re: [PATCH RFC 00/18] arch, mm: create a generic set_memory/change_page_attr core
From: Mike Rapoport @ 2026-07-27 10:22 UTC (permalink / raw)
To: Dave Hansen
Cc: Borislav Petkov, linux-mm, Albert Ou, Andrew Morton,
Andy Lutomirski, Brendan Jackman, Catalin Marinas, Dave Hansen,
David Hildenbrand, Huacai Chen, Ingo Molnar, Ingo Molnar,
Kevin Brodsky, Liam R. Howlett, Lorenzo Stoakes, Michal Hocko,
Palmer Dabbelt, Paul Walmsley, Peter Zijlstra, H. Peter Anvin,
Suren Baghdasaryan, Thomas Gleixner, Vlastimil Babka, Will Deacon,
linux-arm-kernel, linux-kernel, linux-riscv, loongarch, x86,
Juergen Gross
In-Reply-To: <fa75382e-878a-4064-a9b1-43bd2c9dedce@intel.com>
On Wed, Jul 22, 2026 at 10:03:03AM -0700, Dave Hansen wrote:
> On 7/21/26 10:19, Borislav Petkov wrote:
> > On Tue, Jul 21, 2026 at 07:23:23PM +0300, Mike Rapoport (Microsoft) wrote:
> >> Currently there are 6 independent implementations for set_memory and
> >> set_direct_map APIs.
> > So with all mm/x86/CPA patches flying around, can we first agree on which tree
> > is going to collect everything?
> >
> > And if I want to review patches in that area, what am I applying it ontop?
> > linux-next perhaps...
> >
> > Let's sort out the workflow first so that we don't get lost on fruitless bug
> > chases and fingerpointing.
>
> Just practically, I think this series needs to be ignored for a bit. Bug
> fixes first, features and cleanups second.
Ignored is a bit strong, I'd still love to get feedback on the concept.
> When the time is right, it probably needs to get get acks from all the
> affected architectures and go through mm. Folks can ack it now, but I
> don't think anyone should even consider merging it until ~7.3-rc1.
FWIF, I didn't plan to send non-RFC version before 7.3-rc1.
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 1/2] soc: fsl: qe_ports_ic: Use generic I/O helper instead of specific powerPC ones
From: Christophe Leroy (CS GROUP) @ 2026-07-27 10:19 UTC (permalink / raw)
To: Qiang Zhao, Madhavan Srinivasan, Christophe Leroy (CS GROUP)
Cc: linux-kernel, linuxppc-dev, linux-arm-kernel, Paul Louvel
In-Reply-To: <b08f76c1d8ff864774246f1e2c2158c223c001be.1783435914.git.chleroy@kernel.org>
On Tue, 07 Jul 2026 16:58:14 +0200, Christophe Leroy (CS GROUP) wrote:
> Use ioread32be() and iowrite32be() instead of in_be32() and out_be32()
> to allow build on other platforms than powerPC.
>
>
Applied, thanks!
[1/2] soc: fsl: qe_ports_ic: Use generic I/O helper instead of specific powerPC ones
(no commit info)
[2/2] powerpc: Move CONFIG_QE_GPIO to SoC
commit: 6599935a1e4be0354326086ea6c73dcb8f43b881
Best regards,
--
Christophe Leroy (CS GROUP) <chleroy@kernel.org>
^ permalink raw reply
* Re: [PATCH] soc: fsl: dpio: Remove redundant dev_err()
From: Christophe Leroy (CS GROUP) @ 2026-07-27 10:18 UTC (permalink / raw)
To: Roy Pledge, linux-kernel, linuxppc-dev, linux-arm-kernel,
Pan Chuang
Cc: Christophe Leroy
In-Reply-To: <20260723024748.30105-1-panchuang@vivo.com>
On Thu, 23 Jul 2026 10:47:48 +0800, Pan Chuang wrote:
> Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
> devm_request_*_irq()"), devm_request_irq() automatically logs
> detailed error messages on failure. Remove the now-redundant
> driver-specific dev_err() calls.
>
>
Applied, thanks!
[1/1] soc: fsl: dpio: Remove redundant dev_err()
commit: 863a06885322bb1c0f43fe93faf13ad3e34b3f90
Best regards,
--
Christophe Leroy (CS GROUP) <chleroy@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] powerpc: Move CONFIG_QE_GPIO to SoC
From: Christophe Leroy (CS GROUP) @ 2026-07-27 10:17 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Qiang Zhao, Greg Kroah-Hartman, linuxppc-dev, linux-kernel,
linux-arm-kernel, linux-usb
In-Reply-To: <9a7131d15a94e2017877e628f0e97f9aa2e0aae9.1785140877.git.chleroy@kernel.org>
On Mon, 27 Jul 2026 10:45:37 +0200, Christophe Leroy (CS GROUP) wrote:
> Commit 7aa1aa6ecec2 ("QE: Move QE from arch/powerpc to drivers/soc")
> moved QE into drivers/soc including gpio.c but left CONFIG_QE_GPIO
> in powerpc's Kconfig.
>
> Move it to SoC as well as it is the only place it is used:
>
> drivers/soc/fsl/qe/Makefile:obj-$(CONFIG_QE_GPIO) += gpio.o qe_ports_ic.o
> include/soc/fsl/qe/qe.h:#ifdef CONFIG_QE_GPIO
> include/soc/fsl/qe/qe.h:#endif /* CONFIG_QE_GPIO */
>
> [...]
Applied, thanks!
[1/1] powerpc: Move CONFIG_QE_GPIO to SoC
commit: 6599935a1e4be0354326086ea6c73dcb8f43b881
Best regards,
--
Christophe Leroy (CS GROUP) <chleroy@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC 00/18] arch, mm: create a generic set_memory/change_page_attr core
From: Mike Rapoport @ 2026-07-27 10:16 UTC (permalink / raw)
To: Adrian Barnaś
Cc: linux-mm, Albert Ou, Andrew Morton, Andy Lutomirski,
Borislav Petkov, Brendan Jackman, Catalin Marinas, Dave Hansen,
David Hildenbrand, Huacai Chen, Ingo Molnar, Ingo Molnar,
Kevin Brodsky, Liam R. Howlett, Lorenzo Stoakes, Michal Hocko,
Palmer Dabbelt, Paul Walmsley, Peter Zijlstra, H. Peter Anvin,
Suren Baghdasaryan, Thomas Gleixner, Vlastimil Babka, Will Deacon,
linux-arm-kernel, linux-kernel, linux-riscv, loongarch, x86,
Dave Hansen, Juergen Gross
In-Reply-To: <amDe_3KFBc9CcIbo@google.com>
Hi Adrian,
On Wed, Jul 22, 2026 at 03:17:19PM +0000, Adrian Barnaś wrote:
> On Tue, Jul 21, 2026 at 07:23:23PM +0300, Mike Rapoport (Microsoft) wrote:
>
> Hi Mike,
>
> > Once this settles, the next step I'm planning is to convert arm64. This
> > would be much more involved than loongarch and riscv together, so I
> > didn't even aspire to include arm64 in the first RFC. That said, I have
> > a very ugly arm64 prototype that rewrites arch/arm64/pageattr.c to use
> > the generic CPA infrastructure and replaces the existing implementation
> > of page table splits for systems that support bbml2. But there's a lot
> > of yak shaving there to get from a PoC to actual patches.
>
> Could you share your PoC for ARM64. I can help you with that and align my
> execmem rox cache for ARM64 changes to the desired shape of this API.
It's too ugly and more importantly it cuts too many edges.
I'll try to bring it into a better shape and will share then Really Soon :)
> Best regards,
> Adrian
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH v6 3/5] arm64: dts: imx8mp-skov-revc: convert to overlays
From: Steffen Trumtrar @ 2026-07-27 10:10 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Steffen Trumtrar, Søren Andersen, devicetree, linux-kernel,
imx, linux-arm-kernel
In-Reply-To: <20260727-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v6-0-fa8f71dfc56f@pengutronix.de>
The i.MX8MP Skov RevC jutouch 10" and Tian 7" variants are pretty
similar, apart from the Display and touch controller.
Move the common bindings to imx8mp-skov-revc-touch.dts and convert both
variants to use overlays applied on this base version.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
arch/arm64/boot/dts/freescale/Makefile | 6 +++
...ts => imx8mp-skov-revc-jutouch-jt101tm023.dtso} | 44 ++++++---------------
...07017.dts => imx8mp-skov-revc-tian-g07017.dtso} | 42 ++++++--------------
.../boot/dts/freescale/imx8mp-skov-revc-touch.dts | 45 ++++++++++++++++++++++
4 files changed, 74 insertions(+), 63 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index b46f452f4b988..2caac104bec6e 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -434,8 +434,14 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-mi1010ait-1cp1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-bd500.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-hdmi.dtb
+
+imx8mp-skov-revc-jutouch-jt101tm023-dtbs += imx8mp-skov-revc-touch.dtb \
+ imx8mp-skov-revc-jutouch-jt101tm023.dtbo
+imx8mp-skov-revc-tian-g07017-dtbs += imx8mp-skov-revc-touch.dtb \
+ imx8mp-skov-revc-tian-g07017.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-jutouch-jt101tm023.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-tian-g07017.dtb
+
dtb-$(CONFIG_ARCH_MXC) += imx8mp-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mpxl.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt101tm023.dts b/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt101tm023.dtso
similarity index 65%
rename from arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt101tm023.dts
rename to arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt101tm023.dtso
index 3e320d6dea3a2..b50960879e82d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt101tm023.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt101tm023.dtso
@@ -1,10 +1,12 @@
// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/dts-v1/;
+/plugin/;
-#include "imx8mp-skov-reva.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
-/ {
+&{/} {
model = "SKOV IMX8MP CPU revC - JuTouch JT101TM023";
compatible = "skov,imx8mp-skov-revc-jutouch-jt101tm023", "fsl,imx8mp";
@@ -21,13 +23,9 @@ in_lvds0: endpoint {
};
};
-&backlight {
- status = "okay";
-};
-
&i2c2 {
- clock-frequency = <100000>;
- status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
touchscreen@2a {
compatible = "eeti,exc81w32", "eeti,exc80h84";
@@ -42,38 +40,20 @@ touchscreen@2a {
};
};
-&lcdif2 {
- status = "okay";
-};
-
&lvds_bridge {
- assigned-clocks = <&clk IMX8MP_CLK_MEDIA_LDB>,
- <&clk IMX8MP_VIDEO_PLL1>;
- assigned-clock-parents = <&clk IMX8MP_VIDEO_PLL1_OUT>;
/* IMX8MP_VIDEO_PLL1 = IMX8MP_CLK_MEDIA_DISP2_PIX * 7 */
assigned-clock-rates = <0>, <506800000>;
- status = "okay";
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@1 {
+ reg = <1>;
+
ldb_lvds_ch0: endpoint {
remote-endpoint = <&in_lvds0>;
};
};
- };
-};
-
-&pwm4 {
- status = "okay";
-};
-
-&pwm1 {
- status = "okay";
-};
-
-®_tft_vcom {
- regulator-min-microvolt = <3160000>;
- regulator-max-microvolt = <3160000>;
- voltage-table = <3160000 73>;
- status = "okay";
+ };
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-tian-g07017.dts b/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-tian-g07017.dtso
similarity index 66%
rename from arch/arm64/boot/dts/freescale/imx8mp-skov-revc-tian-g07017.dts
rename to arch/arm64/boot/dts/freescale/imx8mp-skov-revc-tian-g07017.dtso
index 9a562c011f2c2..c4e8f1c93a9c7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-tian-g07017.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-tian-g07017.dtso
@@ -1,10 +1,12 @@
// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/dts-v1/;
+/plugin/;
-#include "imx8mp-skov-reva.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
-/ {
+&{/} {
model = "SKOV IMX8MP CPU revC - TIAN G07017";
compatible = "skov,imx8mp-skov-revc-tian-g07017", "fsl,imx8mp";
@@ -21,13 +23,9 @@ in_lvds0: endpoint {
};
};
-&backlight {
- status = "okay";
-};
-
&i2c2 {
- clock-frequency = <100000>;
- status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
touchscreen@38 {
compatible = "edt,edt-ft5506";
@@ -44,38 +42,20 @@ touchscreen@38 {
};
};
-&lcdif2 {
- status = "okay";
-};
-
&lvds_bridge {
- assigned-clocks = <&clk IMX8MP_CLK_MEDIA_LDB>,
- <&clk IMX8MP_VIDEO_PLL1>;
- assigned-clock-parents = <&clk IMX8MP_VIDEO_PLL1_OUT>;
/* IMX8MP_VIDEO_PLL1 = IMX8MP_CLK_MEDIA_DISP2_PIX * 2 * 7 */
assigned-clock-rates = <0>, <358400000>;
- status = "okay";
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@1 {
+ reg = <1>;
+
ldb_lvds_ch0: endpoint {
remote-endpoint = <&in_lvds0>;
};
};
};
};
-
-&pwm4 {
- status = "okay";
-};
-
-&pwm1 {
- status = "okay";
-};
-
-®_tft_vcom {
- regulator-min-microvolt = <3160000>;
- regulator-max-microvolt = <3160000>;
- voltage-table = <3160000 73>;
- status = "okay";
-};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-touch.dts b/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-touch.dts
new file mode 100644
index 0000000000000..17750b5e94d43
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-touch.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
+/dts-v1/;
+
+#include "imx8mp-skov-reva.dtsi"
+
+/ {
+ model = "SKOV IMX8MP CPU revC";
+ compatible = "skov,imx8mp-skov-revc", "fsl,imx8mp";
+};
+
+&backlight {
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ status = "okay";
+};
+
+&lcdif2 {
+ status = "okay";
+};
+
+&lvds_bridge {
+ assigned-clocks = <&clk IMX8MP_CLK_MEDIA_LDB>,
+ <&clk IMX8MP_VIDEO_PLL1>;
+ assigned-clock-parents = <&clk IMX8MP_VIDEO_PLL1_OUT>;
+ status = "okay";
+};
+
+&pwm4 {
+ status = "okay";
+};
+
+&pwm1 {
+ status = "okay";
+};
+
+®_tft_vcom {
+ regulator-min-microvolt = <3160000>;
+ regulator-max-microvolt = <3160000>;
+ voltage-table = <3160000 73>;
+ status = "okay";
+};
--
2.51.0
^ permalink raw reply related
* [PATCH v6 5/5] arm64: dts: imx8mp-skov: support new 7inch panel board
From: Steffen Trumtrar @ 2026-07-27 10:10 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Steffen Trumtrar, Søren Andersen, devicetree, linux-kernel,
imx, linux-arm-kernel
In-Reply-To: <20260727-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v6-0-fa8f71dfc56f@pengutronix.de>
This board is similar to the already upstream
imx8mp-skov-revc-tian-g07017 and imx8mp-skov-revc-jt101tm023 but uses a
different 7" panel with a different touch controller.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
arch/arm64/boot/dts/freescale/Makefile | 3 ++
.../imx8mp-skov-revc-jutouch-jt070tm041.dtso | 39 ++++++++++++++++++++++
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2caac104bec6e..92559e0dd8396 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -435,10 +435,13 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-mi1010ait-1cp1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-bd500.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-hdmi.dtb
+imx8mp-skov-revc-jutouch-jt070tm041-dtbs += imx8mp-skov-revc-touch.dtb \
+ imx8mp-skov-revc-jutouch-jt070tm041.dtbo
imx8mp-skov-revc-jutouch-jt101tm023-dtbs += imx8mp-skov-revc-touch.dtb \
imx8mp-skov-revc-jutouch-jt101tm023.dtbo
imx8mp-skov-revc-tian-g07017-dtbs += imx8mp-skov-revc-touch.dtb \
imx8mp-skov-revc-tian-g07017.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-jutouch-jt070tm041.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-jutouch-jt101tm023.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-tian-g07017.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt070tm041.dtso b/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt070tm041.dtso
new file mode 100644
index 0000000000000..20e987b36c53a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt070tm041.dtso
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ model = "SKOV IMX8MP CPU revC - JuTouch JT070TM041";
+ compatible = "skov,imx8mp-skov-revc-jutouch-jt070tm041", "fsl,imx8mp";
+
+ panel {
+ compatible = "jutouch,jt070tm041";
+ backlight = <&backlight>;
+ power-supply = <®_tft_vcom>;
+
+ port {
+ in_lvds0: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+ };
+};
+
+&lvds_bridge {
+ /* IMX8MP_VIDEO_PLL1 = IMX8MP_CLK_MEDIA_DISP2_PIX * 7 */
+ assigned-clock-rates = <0>, <358400000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ ldb_lvds_ch0: endpoint {
+ remote-endpoint = <&in_lvds0>;
+ };
+ };
+ };
+};
--
2.51.0
^ permalink raw reply related
* [PATCH v6 2/5] dt-bindings: arm: fsl: add base compatible for Skov i.MX8MP revC
From: Steffen Trumtrar @ 2026-07-27 10:10 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Steffen Trumtrar, Søren Andersen, devicetree, linux-kernel,
imx, linux-arm-kernel
In-Reply-To: <20260727-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v6-0-fa8f71dfc56f@pengutronix.de>
Add a generic compatible for revC-based Skov boards.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 86876311ec59a..7bb5d6ca8485a 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1145,6 +1145,7 @@ properties:
- skov,imx8mp-skov-revb-hdmi # SKOV i.MX8MP climate control without panel
- skov,imx8mp-skov-revb-lt6 # SKOV i.MX8MP climate control with 7” panel
- skov,imx8mp-skov-revb-mi1010ait-1cp1 # SKOV i.MX8MP climate control with 10.1" panel
+ - skov,imx8mp-skov-revc # SKOV i.MX8MP climate control revision C
- skov,imx8mp-skov-revc-hdmi # SKOV i.MX8MP climate control without panel
- skov,imx8mp-skov-revc-bd500 # SKOV i.MX8MP climate control with LED frontplate
- skov,imx8mp-skov-revc-jutouch-jt101tm023 # SKOV i.MX8MP climate control with 10" JuTouch panel
--
2.51.0
^ permalink raw reply related
* [PATCH v6 4/5] dt-bindings: arm: fsl: add compatible for new Skov i.MX8MP variant
From: Steffen Trumtrar @ 2026-07-27 10:10 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Steffen Trumtrar, Søren Andersen, devicetree, linux-kernel,
imx, linux-arm-kernel, Conor Dooley
In-Reply-To: <20260727-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v6-0-fa8f71dfc56f@pengutronix.de>
In preparation for adding a new device tree variant with a different 7"
panel, describe the DT compatible in the binding.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7bb5d6ca8485a..e7f250641683e 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1148,6 +1148,7 @@ properties:
- skov,imx8mp-skov-revc # SKOV i.MX8MP climate control revision C
- skov,imx8mp-skov-revc-hdmi # SKOV i.MX8MP climate control without panel
- skov,imx8mp-skov-revc-bd500 # SKOV i.MX8MP climate control with LED frontplate
+ - skov,imx8mp-skov-revc-jutouch-jt070tm041 # SKOV i.MX8MP climate control with 7" JuTouch panel
- skov,imx8mp-skov-revc-jutouch-jt101tm023 # SKOV i.MX8MP climate control with 10" JuTouch panel
- skov,imx8mp-skov-revc-tian-g07017 # SKOV i.MX8MP climate control with 7" panel
- ultratronik,imx8mp-ultra-mach-sbc # Ultratronik SBC i.MX8MP based board
--
2.51.0
^ permalink raw reply related
* [PATCH v6 0/5] arm64: dts: imx8mp-skov: add new 7" variant
From: Steffen Trumtrar @ 2026-07-27 10:10 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Steffen Trumtrar, Søren Andersen, devicetree, linux-kernel,
imx, linux-arm-kernel, Conor Dooley
Add a new board variant for the Skov i.MX8MP based family of boards.
This variant uses a different 7" panel than the existing ones.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
Changes in v6:
- address sashikos rightful feedback
- Link to v5: https://patch.msgid.link/20260727-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v5-0-67faa5ee0bf6@pengutronix.de
Changes in v5:
- convert to overlays
- Link to v4: https://patch.msgid.link/20260706-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v4-0-dfc0c8827c02@pengutronix.de
Changes in v4:
- fix Makefile sort order
- add touchscreen fallback compatible
- fix lvds_bridge comment
- Link to v3: https://patch.msgid.link/20260701-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v3-0-d74f7e3f8293@pengutronix.de
Changes in v3:
- rebase to v7.2-rc1
- Link to v2: https://patch.msgid.link/20260427-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v2-0-e2b79fc24391@pengutronix.de
Changes in v2:
- rebase to v7.1-rc1
- Link to v1: https://patch.msgid.link/20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-0-10255d236439@pengutronix.de
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Shawn Guo <shawnguo@kernel.org>
To: Frank Li <Frank.Li@nxp.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
To: Pengutronix Kernel Team <kernel@pengutronix.de>
To: Fabio Estevam <festevam@gmail.com>
Cc: Søren Andersen <san@skov.dk>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
Steffen Trumtrar (5):
arm64: dts: freescale: imx8mp: fix sort order
dt-bindings: arm: fsl: add base compatible for Skov i.MX8MP revC
arm64: dts: imx8mp-skov-revc: convert to overlays
dt-bindings: arm: fsl: add compatible for new Skov i.MX8MP variant
arm64: dts: imx8mp-skov: support new 7inch panel board
Documentation/devicetree/bindings/arm/fsl.yaml | 2 +
arch/arm64/boot/dts/freescale/Makefile | 11 +++++-
.../imx8mp-skov-revc-jutouch-jt070tm041.dtso | 39 +++++++++++++++++++
...ts => imx8mp-skov-revc-jutouch-jt101tm023.dtso} | 44 ++++++---------------
...07017.dts => imx8mp-skov-revc-tian-g07017.dtso} | 42 ++++++--------------
.../boot/dts/freescale/imx8mp-skov-revc-touch.dts | 45 ++++++++++++++++++++++
6 files changed, 119 insertions(+), 64 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-3dbcb450a39c
Best regards,
--
Steffen Trumtrar <s.trumtrar@pengutronix.de>
^ permalink raw reply
* [PATCH v6 1/5] arm64: dts: freescale: imx8mp: fix sort order
From: Steffen Trumtrar @ 2026-07-27 10:10 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Steffen Trumtrar, Søren Andersen, devicetree, linux-kernel,
imx, linux-arm-kernel
In-Reply-To: <20260727-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v6-0-fa8f71dfc56f@pengutronix.de>
The imx8mp-skov-revc-jutouch should be alphabetically before the
imx8mp-skov-revc-tian variant.
Sort the entries in the correct order.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 8ddaab127ab9c..b46f452f4b988 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -434,8 +434,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-mi1010ait-1cp1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-bd500.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-hdmi.dtb
-dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-tian-g07017.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-jutouch-jt101tm023.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-tian-g07017.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mpxl.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314.dtb
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v5 0/3] pmdomain: imx: build the SCU power domain driver as a module
From: Ulf Hansson @ 2026-07-27 10:00 UTC (permalink / raw)
To: Zhipeng.wang_1
Cc: robh, saravanak, ulfh, Frank.Li, s.hauer, kernel, festevam,
peng.fan, aisheng.dong, jindong.yue, xuegang.liu, devicetree,
linux-pm, imx, linux-arm-kernel, linux-kernel, linux-clk
In-Reply-To: <20260723020524.1886806-1-Zhipeng.wang_1@oss.nxp.com>
On Thu, Jul 23, 2026 at 4:05 AM <Zhipeng.wang_1@oss.nxp.com> wrote:
>
> From: Zhipeng Wang <zhipeng.wang_1@nxp.com>
>
> This series makes the i.MX SCU power domain driver buildable as a
> loadable module, which is required for Android devices using the
> Generic Kernel Image (GKI) where SoC-specific drivers must be modules.
>
> Patch 1 exports of_stdout (which the driver references to find the
> console's power domain) from the OF core with EXPORT_SYMBOL_GPL().
>
> Patch 2 converts CONFIG_IMX_SCU_PD from bool to tristate and adds
> MODULE_DEVICE_TABLE() for autoloading. subsys_initcall() is used so
> that when built-in the provider probes before its consumers (e.g. the
> SCU clock driver at device_initcall level). No module_exit() is
> provided since the provider cannot be safely removed at runtime.
>
> Patch 3 adds MODULE_SOFTDEP("pre: scu_pd") to the i.MX8QXP clock
> driver so that modprobe loads the power domain module first when both
> are built as modules.
>
> Because of the cross-subsystem dependency (patches touch drivers/of,
> drivers/pmdomain, and drivers/clk), I would suggest taking the whole
> series through one tree.
>
> Changes in v5:
> - Fix MODULE_SOFTDEP module name from imx_scu_pd to scu_pd. (Sashiko
> bot)
> - Add Acked-by from Rob Herring for patch 1.
>
> Changes in v4:
> - Add patch 3: MODULE_SOFTDEP in clk-imx8qxp to guarantee module load
> order when both drivers are modules. (Sashiko bot)
>
> Changes in v3:
> - Use subsys_initcall() instead of module_init() to fix probe ordering
> between the power domain provider and the SCU clock consumer when
> both are built-in. (Sashiko bot)
>
> Changes in v2:
> - Drop module_platform_driver() which provides module_exit() and could
> lead to use-after-free on module unload. Use module_init() only, so
> the module cannot be unloaded. (Sashiko bot)
>
> Zhipeng Wang (3):
> of: export of_stdout symbol
> pmdomain: imx: scu-pd: allow building as a module
> clk: imx: imx8qxp: add soft dependency on SCU power domain driver
>
> drivers/clk/imx/clk-imx8qxp.c | 1 +
> drivers/of/base.c | 1 +
> drivers/pmdomain/imx/Kconfig | 2 +-
> drivers/pmdomain/imx/scu-pd.c | 8 +++++++-
> 4 files changed, 10 insertions(+), 2 deletions(-)
>
> --
> 2.34.1
The v5 series applied for next, thanks!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] pmdomain: mediatek: fix remaining %pOF after of_node_put()
From: Ulf Hansson @ 2026-07-27 10:00 UTC (permalink / raw)
To: Guangshuo Li
Cc: Ulf Hansson, Matthias Brugger, AngeloGioacchino Del Regno,
Nícolas F. R. A. Prado, Irving-CH Lin, Macpaul Lin,
Adam Ford, linux-pm, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260708092038.741308-1-lgs201920130244@gmail.com>
On Wed, Jul 8, 2026 at 11:23 AM Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
> scpsys_get_bus_protection_legacy() looks up several legacy bus
> protection regmaps from device-tree nodes.
>
> Two error paths put the device node before checking whether the regmap
> lookup failed, but still pass that node to dev_err_probe() with %pOF on
> failure. If of_node_put() drops the last reference, the later %pOF
> formatting can dereference a freed device node.
>
> Keep the node reference until after the error message has been emitted in
> the infracfg and SMI lookup paths. Also drop the SMI node before
> returning when the SMI phandle is missing.
>
> Fixes: c29345fa5f66 ("pmdomain: mediatek: Refactor bus protection regmaps retrieval")
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Applied for fixes and by adding a stable tag, thanks!
Kind regards
Uffe
> ---
> drivers/pmdomain/mediatek/mtk-pm-domains.c | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
> index e1cfd4223473..f877d6694dd5 100644
> --- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
> +++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
> @@ -1032,12 +1032,15 @@ static int scpsys_get_bus_protection_legacy(struct device *dev, struct scpsys *s
> node = of_find_node_with_property(np, "mediatek,infracfg");
> if (node) {
> regmap[0] = syscon_regmap_lookup_by_phandle(node, "mediatek,infracfg");
> - of_node_put(node);
> num_regmaps++;
> - if (IS_ERR(regmap[0]))
> - return dev_err_probe(dev, PTR_ERR(regmap[0]),
> + if (IS_ERR(regmap[0])) {
> + ret = dev_err_probe(dev, PTR_ERR(regmap[0]),
> "%pOF: failed to get infracfg regmap\n",
> node);
> + of_node_put(node);
> + return ret;
> + }
> + of_node_put(node);
> } else {
> regmap[0] = NULL;
> }
> @@ -1046,17 +1049,22 @@ static int scpsys_get_bus_protection_legacy(struct device *dev, struct scpsys *s
> node = of_find_node_with_property(np, "mediatek,smi");
> if (node) {
> smi_np = of_parse_phandle(node, "mediatek,smi", 0);
> - of_node_put(node);
> - if (!smi_np)
> + if (!smi_np) {
> + of_node_put(node);
> return -ENODEV;
> + }
>
> regmap[1] = device_node_to_regmap(smi_np);
> num_regmaps++;
> of_node_put(smi_np);
> - if (IS_ERR(regmap[1]))
> - return dev_err_probe(dev, PTR_ERR(regmap[1]),
> + if (IS_ERR(regmap[1])) {
> + ret = dev_err_probe(dev, PTR_ERR(regmap[1]),
> "%pOF: failed to get SMI regmap\n",
> node);
> + of_node_put(node);
> + return ret;
> + }
> + of_node_put(node);
> } else {
> regmap[1] = NULL;
> }
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH v5 3/3] soc: qcom: ubwc: Get HBB from SMEM
From: Konrad Dybcio @ 2026-07-27 9:59 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Kees Cook, Gustavo A. R. Silva,
Rob Clark, Sean Paul, Akhil P Oommen, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Alim Akhtar, Avri Altman, Bart Van Assche,
James E.J. Bottomley, Martin K. Petersen, Matthias Brugger,
AngeloGioacchino Del Regno, Suzuki K Poulose, Mike Leach,
James Clark, Leo Yan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yuanfang Zhang, Mao Jinlong, Jie Gan, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arm-msm, linux-hardening, dri-devel,
freedreno, Konrad Dybcio, linux-scsi, linux-arm-kernel,
linux-mediatek, coresight, devicetree, linux-riscv
In-Reply-To: <20260727-topic-smem_dramc-v5-0-66188b3e338d@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To make sure the correct settings for a given DRAM configuration get
applied, attempt to retrieve that data from SMEM (which happens to be
what the BSP kernel does, albeit with through convoluted means of the
bootloader altering the DT with this data).
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/soc/qcom/ubwc_config.c | 40 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/ubwc_config.c b/drivers/soc/qcom/ubwc_config.c
index 0209a02c390f..23901a4c51f7 100644
--- a/drivers/soc/qcom/ubwc_config.c
+++ b/drivers/soc/qcom/ubwc_config.c
@@ -11,6 +11,7 @@
#include <linux/platform_device.h>
#include <linux/soc/qcom/ubwc.h>
+#include <linux/soc/qcom/smem.h>
static const struct qcom_ubwc_cfg_data no_ubwc_data = {
/* no UBWC, no HBB */
@@ -168,9 +169,25 @@ static const struct of_device_id qcom_ubwc_configs[] __maybe_unused = {
{ }
};
+static struct qcom_ubwc_cfg_data *cfg;
+static DEFINE_MUTEX(cfg_mutex);
+/**
+ * qcom_ubwc_config_get_data() - Retrieve UBWC data for the platform.
+ *
+ * Return: Pointer to valid struct qcom_ubwc_cfg_data on success, negative
+ * errno on failure. Note that this may return EPROBE_DEFER.
+ */
const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void)
{
const struct qcom_ubwc_cfg_data *data;
+ int hbb;
+
+ guard(mutex)(&cfg_mutex);
+ if (cfg)
+ return cfg;
+
+ if (!qcom_smem_is_available())
+ return ERR_PTR(-EPROBE_DEFER);
data = of_machine_get_match_data(qcom_ubwc_configs);
if (!data) {
@@ -178,9 +195,30 @@ const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void)
return ERR_PTR(-EINVAL);
}
- return data;
+ hbb = qcom_smem_dram_get_hbb();
+ if (hbb == -ENODATA) {
+ /* Lack of HBB data is OK - it was only introduced later */
+ return data;
+ } else if (hbb < 0) {
+ pr_err("Couldn't get HBB data from SMEM: %d\n", hbb);
+ return ERR_PTR(hbb);
+ }
+
+ cfg = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!cfg)
+ return ERR_PTR(-ENOMEM);
+
+ cfg->highest_bank_bit = hbb;
+
+ return cfg;
}
EXPORT_SYMBOL_GPL(qcom_ubwc_config_get_data);
+static void __exit ubwc_config_exit(void)
+{
+ kfree(cfg);
+}
+module_exit(ubwc_config_exit);
+
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("UBWC config database for QTI SoCs");
--
2.55.0
^ permalink raw reply related
* [PATCH v5 2/3] soc: qcom: smem: Expose DDR data from SMEM
From: Konrad Dybcio @ 2026-07-27 9:59 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Kees Cook, Gustavo A. R. Silva,
Rob Clark, Sean Paul, Akhil P Oommen, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Alim Akhtar, Avri Altman, Bart Van Assche,
James E.J. Bottomley, Martin K. Petersen, Matthias Brugger,
AngeloGioacchino Del Regno, Suzuki K Poulose, Mike Leach,
James Clark, Leo Yan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yuanfang Zhang, Mao Jinlong, Jie Gan, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arm-msm, linux-hardening, dri-devel,
freedreno, Konrad Dybcio, linux-scsi, linux-arm-kernel,
linux-mediatek, coresight, devicetree, linux-riscv
In-Reply-To: <20260727-topic-smem_dramc-v5-0-66188b3e338d@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Most modern Qualcomm platforms (>= SM8150) expose information about the
DDR memory present on the system via SMEM.
Details from this information is used in various scenarios, such as
multimedia drivers configuring the hardware based on the "Highest Bank
address Bit" (hbb), or the list of valid frequencies in validation
scenarios...
Add support for parsing v3-v7 version of the structs. Unforunately,
they are not versioned, so some elbow grease is necessary to determine
which one is present. See for reference:
ver 3: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/1d11897d2cfcc7b85f28ff74c445018dbbecac7a
ver 4: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/f6e9aa549260bbc0bdcb156c2b05f48dc5963203
ver 5: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/617d3297abe8b1b8dd3de3d1dd69c3961e6f343f
ver 5 with 6regions: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/d770e009f9bae58d56d926f7490bbfb45af8341f
ver 6: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/62659b557fdb1551b20fae8073d1d701dfa8a62e
ver 7: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/734d95599c5ebb1ca0d4e1639142e65c590532b7
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/soc/qcom/Makefile | 3 +-
drivers/soc/qcom/smem.c | 59 +++---
drivers/soc/qcom/smem.h | 12 ++
drivers/soc/qcom/smem_dramc.c | 430 ++++++++++++++++++++++++++++++++++++++++++
include/linux/soc/qcom/smem.h | 2 +
5 files changed, 484 insertions(+), 22 deletions(-)
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index b7f1d2a57367..798643be3590 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -23,7 +23,8 @@ obj-$(CONFIG_QCOM_RPMH) += qcom_rpmh.o
qcom_rpmh-y += rpmh-rsc.o
qcom_rpmh-y += rpmh.o
obj-$(CONFIG_QCOM_SMD_RPM) += rpm-proc.o smd-rpm.o
-obj-$(CONFIG_QCOM_SMEM) += smem.o
+qcom_smem-y += smem.o smem_dramc.o
+obj-$(CONFIG_QCOM_SMEM) += qcom_smem.o
obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
CFLAGS_smp2p.o := -I$(src)
obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 43b66120fc64..4c689fc17011 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -4,6 +4,7 @@
* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
*/
+#include <linux/debugfs.h>
#include <linux/hwspinlock.h>
#include <linux/io.h>
#include <linux/module.h>
@@ -16,6 +17,8 @@
#include <linux/soc/qcom/smem.h>
#include <linux/soc/qcom/socinfo.h>
+#include "smem.h"
+
/*
* The Qualcomm shared memory system is a allocate only heap structure that
* consists of one of more memory areas that can be accessed by the processors
@@ -281,6 +284,8 @@ struct qcom_smem {
struct smem_partition global_partition;
struct xarray partitions;
+ struct dentry *debugfs_dir;
+
unsigned int num_regions;
struct smem_region regions[] __counted_by(num_regions);
};
@@ -671,6 +676,30 @@ static void *qcom_smem_get_private(struct qcom_smem *smem,
return ERR_PTR(-EINVAL);
}
+void *__qcom_smem_get(struct qcom_smem *smem, unsigned int host, unsigned int item, size_t *size)
+{
+ struct smem_partition *part;
+ void *ptr;
+
+ if (IS_ERR(smem))
+ return smem;
+
+ if (item >= smem->item_count)
+ return ERR_PTR(-EINVAL);
+
+ part = xa_load(&smem->partitions, host);
+ if (part) {
+ ptr = qcom_smem_get_private(smem, part, item, size);
+ } else if (smem->global_partition.virt_base) {
+ part = &smem->global_partition;
+ ptr = qcom_smem_get_private(smem, part, item, size);
+ } else {
+ ptr = qcom_smem_get_global(smem, item, size);
+ }
+
+ return ptr;
+}
+
/**
* qcom_smem_get() - resolve ptr of size of a smem item
* @host: the remote processor, or -1
@@ -684,26 +713,7 @@ static void *qcom_smem_get_private(struct qcom_smem *smem,
*/
void *qcom_smem_get(unsigned int host, unsigned int item, size_t *size)
{
- struct smem_partition *part;
- void *ptr;
-
- if (IS_ERR(__smem))
- return __smem;
-
- if (item >= __smem->item_count)
- return ERR_PTR(-EINVAL);
-
- part = xa_load(&__smem->partitions, host);
- if (part) {
- ptr = qcom_smem_get_private(__smem, part, item, size);
- } else if (__smem->global_partition.virt_base) {
- part = &__smem->global_partition;
- ptr = qcom_smem_get_private(__smem, part, item, size);
- } else {
- ptr = qcom_smem_get_global(__smem, item, size);
- }
-
- return ptr;
+ return __qcom_smem_get(__smem, host, item, size);
}
EXPORT_SYMBOL_GPL(qcom_smem_get);
@@ -1236,19 +1246,26 @@ static int qcom_smem_probe(struct platform_device *pdev)
if (ret < 0 && ret != -ENOENT)
return ret;
+ smem->debugfs_dir = smem_dram_parse(smem, smem->dev);
+
__smem = smem;
smem->socinfo = platform_device_register_data(&pdev->dev, "qcom-socinfo",
PLATFORM_DEVID_NONE, NULL,
0);
- if (IS_ERR(smem->socinfo))
+ if (IS_ERR(smem->socinfo)) {
+ debugfs_remove_recursive(smem->debugfs_dir);
+
dev_dbg(&pdev->dev, "failed to register socinfo device\n");
+ }
return 0;
}
static void qcom_smem_remove(struct platform_device *pdev)
{
+ debugfs_remove_recursive(__smem->debugfs_dir);
+
platform_device_unregister(__smem->socinfo);
xa_destroy(&__smem->partitions);
diff --git a/drivers/soc/qcom/smem.h b/drivers/soc/qcom/smem.h
new file mode 100644
index 000000000000..40523eb87231
--- /dev/null
+++ b/drivers/soc/qcom/smem.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __QCOM_SMEM_INTERNAL__
+#define __QCOM_SMEM_INTERNAL__
+
+#include <linux/device.h>
+
+struct qcom_smem;
+
+struct dentry *smem_dram_parse(struct qcom_smem *smem, struct device *dev);
+void *__qcom_smem_get(struct qcom_smem *smem, unsigned int host, unsigned int item, size_t *size);
+
+#endif
diff --git a/drivers/soc/qcom/smem_dramc.c b/drivers/soc/qcom/smem_dramc.c
new file mode 100644
index 000000000000..63ebe7f6db59
--- /dev/null
+++ b/drivers/soc/qcom/smem_dramc.c
@@ -0,0 +1,430 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/debugfs.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/soc/qcom/smem.h>
+#include <linux/units.h>
+
+#include "smem.h"
+
+#define SMEM_DDR_INFO_ID 603
+
+#define MAX_DDR_FREQ_NUM_V3 13
+#define MAX_DDR_FREQ_NUM_V5 14
+
+#define MAX_CHAN_NUM 8
+#define MAX_RANK_NUM 2
+
+#define DDR_HBB_MIN 13
+#define DDR_HBB_MAX 19
+
+#define MAX_SHUB_ENTRIES 8
+
+static struct smem_dram *__dram;
+
+enum ddr_info_version {
+ INFO_UNKNOWN,
+ INFO_V3,
+ INFO_V3_WITH_14_FREQS,
+ INFO_V4,
+ INFO_V5,
+ INFO_V5_WITH_6_REGIONS,
+ INFO_V6, /* INFO_V6 seems to only have shipped with 6 DDR regions, unlike V7 */
+ INFO_V7,
+ INFO_V7_WITH_6_REGIONS,
+};
+
+struct smem_dram {
+ unsigned long frequencies[MAX_DDR_FREQ_NUM_V5];
+ u32 num_frequencies;
+ u8 hbb;
+};
+
+enum ddr_type {
+ DDR_TYPE_NODDR = 0,
+ DDR_TYPE_LPDDR1 = 1,
+ DDR_TYPE_LPDDR2 = 2,
+ DDR_TYPE_PCDDR2 = 3,
+ DDR_TYPE_PCDDR3 = 4,
+ DDR_TYPE_LPDDR3 = 5,
+ DDR_TYPE_LPDDR4 = 6,
+ DDR_TYPE_LPDDR4X = 7,
+ DDR_TYPE_LPDDR5 = 8,
+ DDR_TYPE_LPDDR5X = 9,
+};
+
+/* The data structures below are NOT __packed on purpose! */
+
+/* Structs used across multiple versions */
+struct ddr_part_details {
+ __le16 revision_id1;
+ __le16 revision_id2;
+ __le16 width;
+ __le16 density;
+};
+
+struct ddr_freq_table {
+ __le32 freq_khz;
+ u8 enabled;
+};
+
+/* V3 */
+struct ddr_freq_plan_v3 {
+ struct ddr_freq_table ddr_freq[MAX_DDR_FREQ_NUM_V3];
+ u8 num_ddr_freqs;
+ phys_addr_t clk_period_address;
+};
+
+struct ddr_details_v3 {
+ u8 manufacturer_id;
+ u8 device_type;
+ struct ddr_part_details ddr_params[MAX_CHAN_NUM];
+ struct ddr_freq_plan_v3 ddr_freq_tbl;
+ u8 num_channels;
+};
+
+/* Some V3 structs have an additional frequency level */
+struct ddr_freq_plan_v3_14freqs {
+ struct ddr_freq_table ddr_freq[MAX_DDR_FREQ_NUM_V3 + 1];
+ u8 num_ddr_freqs;
+ phys_addr_t clk_period_address;
+};
+
+struct ddr_details_v3_14freqs {
+ u8 manufacturer_id;
+ u8 device_type;
+ struct ddr_part_details ddr_params[MAX_CHAN_NUM];
+ struct ddr_freq_plan_v3_14freqs ddr_freq_tbl;
+ u8 num_channels;
+};
+
+/* V4 */
+struct ddr_details_v4 {
+ u8 manufacturer_id;
+ u8 device_type;
+ struct ddr_part_details ddr_params[MAX_CHAN_NUM];
+ struct ddr_freq_plan_v3 ddr_freq_tbl;
+ u8 num_channels;
+ u8 num_ranks[MAX_CHAN_NUM];
+ u8 highest_bank_addr_bit[MAX_CHAN_NUM][MAX_RANK_NUM];
+};
+
+/* V5 */
+struct shub_freq_table {
+ u8 enable;
+ __le32 freq_khz;
+};
+
+struct shub_freq_plan_entry {
+ u8 num_shub_freqs;
+ struct shub_freq_table shub_freq[MAX_SHUB_ENTRIES];
+};
+
+struct ddr_xbl2quantum_smem_data {
+ phys_addr_t ssr_cookie_addr;
+ __le32 reserved[10];
+};
+
+struct ddr_freq_plan_v5 {
+ struct ddr_freq_table ddr_freq[MAX_DDR_FREQ_NUM_V5];
+ u8 num_ddr_freqs;
+ phys_addr_t clk_period_address;
+ __le32 max_nom_ddr_freq;
+};
+
+struct ddr_region_v5 {
+ __le64 start_address;
+ __le64 size;
+ __le64 mem_controller_address;
+ __le32 granule_size; /* MiB */
+ u8 ddr_rank;
+#define DDR_RANK_0 BIT(0)
+#define DDR_RANK_1 BIT(1)
+ u8 segments_start_index;
+ __le64 segments_start_offset;
+};
+
+struct ddr_regions_v5 {
+ __le32 ddr_region_num; /* We expect this to always be 4 or 6 */
+ __le64 ddr_rank0_size;
+ __le64 ddr_rank1_size;
+ __le64 ddr_cs0_start_addr;
+ __le64 ddr_cs1_start_addr;
+ __le32 highest_bank_addr_bit;
+ struct ddr_region_v5 ddr_region[] __counted_by_le(ddr_region_num);
+};
+
+struct ddr_details_v5 {
+ u8 manufacturer_id;
+ u8 device_type;
+ struct ddr_part_details ddr_params[MAX_CHAN_NUM];
+ struct ddr_freq_plan_v5 ddr_freq_tbl;
+ u8 num_channels;
+ u8 _padding;
+ struct ddr_regions_v5 ddr_regions;
+};
+
+/* V6 */
+struct ddr_misc_info_v6 {
+ __le32 dsf_version;
+ __le32 reserved[10];
+};
+
+/* V7 */
+struct ddr_details_v7 {
+ u8 manufacturer_id;
+ u8 device_type;
+ struct ddr_part_details ddr_params[MAX_CHAN_NUM];
+ struct ddr_freq_plan_v5 ddr_freq_tbl;
+ u8 num_channels;
+ u8 sct_config;
+ struct ddr_regions_v5 ddr_regions;
+};
+
+/**
+ * qcom_smem_dram_get_hbb(): Get the Highest bank address bit
+ *
+ * Context: Check qcom_smem_is_available() before calling this function.
+ * Because __dram * is initialized by smem_dram_parse(), which is in turn
+ * called from * qcom_smem_probe(), __dram will only be NULL if the data
+ * couldn't have been found/interpreted correctly.
+ *
+ * Return: highest bank bit on success, -ENODATA on failure.
+ */
+int qcom_smem_dram_get_hbb(void)
+{
+ if (!__dram || !__dram->hbb)
+ return -ENODATA;
+
+ if (__dram->hbb < DDR_HBB_MIN || __dram->hbb > DDR_HBB_MAX)
+ return -ENODATA;
+
+ return __dram->hbb;
+}
+EXPORT_SYMBOL_GPL(qcom_smem_dram_get_hbb);
+
+static void smem_dram_parse_v3_data(struct smem_dram *dram, void *data)
+{
+ struct ddr_details_v3 *details = data;
+
+ for (int i = 0; i < MAX_DDR_FREQ_NUM_V3; i++) {
+ struct ddr_freq_table *freq_entry = &details->ddr_freq_tbl.ddr_freq[i];
+
+ if (freq_entry->freq_khz && freq_entry->enabled) {
+ u32 freq_khz = le32_to_cpu(freq_entry->freq_khz);
+ dram->frequencies[dram->num_frequencies++] = 1000 * freq_khz;
+ }
+ }
+}
+
+static void smem_dram_parse_v3_14freqs_data(struct smem_dram *dram, void *data)
+{
+ struct ddr_details_v3_14freqs *details = data;
+
+ for (int i = 0; i < MAX_DDR_FREQ_NUM_V3 + 1; i++) {
+ struct ddr_freq_table *freq_entry = &details->ddr_freq_tbl.ddr_freq[i];
+
+ if (freq_entry->freq_khz && freq_entry->enabled)
+ dram->frequencies[dram->num_frequencies++] = 1000 * freq_entry->freq_khz;
+ }
+}
+
+static void smem_dram_parse_v4_data(struct smem_dram *dram, void *data)
+{
+ struct ddr_details_v4 *details = data;
+
+ /* Rank 0 channel 0 entry holds the correct value */
+ dram->hbb = details->highest_bank_addr_bit[0][0];
+
+ for (int i = 0; i < MAX_DDR_FREQ_NUM_V3; i++) {
+ struct ddr_freq_table *freq_entry = &details->ddr_freq_tbl.ddr_freq[i];
+
+ if (freq_entry->freq_khz && freq_entry->enabled) {
+ u32 freq_khz = le32_to_cpu(freq_entry->freq_khz);
+ dram->frequencies[dram->num_frequencies++] = 1000 * freq_khz;
+ }
+ }
+}
+
+static void smem_dram_parse_v5_data(struct smem_dram *dram, void *data)
+{
+ struct ddr_details_v5 *details = data;
+ struct ddr_regions_v5 *region = &details->ddr_regions;
+
+ dram->hbb = le32_to_cpu(region[0].highest_bank_addr_bit);
+
+ for (int i = 0; i < MAX_DDR_FREQ_NUM_V5; i++) {
+ struct ddr_freq_table *freq_entry = &details->ddr_freq_tbl.ddr_freq[i];
+
+ if (freq_entry->freq_khz && freq_entry->enabled) {
+ u32 freq_khz = le32_to_cpu(freq_entry->freq_khz);
+ dram->frequencies[dram->num_frequencies++] = 1000 * freq_khz;
+ }
+ }
+}
+
+static void smem_dram_parse_v7_data(struct smem_dram *dram, void *data)
+{
+ struct ddr_details_v7 *details = data;
+ struct ddr_regions_v5 *region = &details->ddr_regions;
+
+ dram->hbb = le32_to_cpu(region[0].highest_bank_addr_bit);
+
+ for (int i = 0; i < MAX_DDR_FREQ_NUM_V5; i++) {
+ struct ddr_freq_table *freq_entry = &details->ddr_freq_tbl.ddr_freq[i];
+
+ if (freq_entry->freq_khz && freq_entry->enabled) {
+ u32 freq_khz = le32_to_cpu(freq_entry->freq_khz);
+ dram->frequencies[dram->num_frequencies++] = 1000 * freq_khz;
+ }
+ }
+}
+
+/* The structure contains no version field, so we have to perform some guesswork.. */
+static int smem_dram_infer_struct_version(size_t size)
+{
+ /* Some early versions provided less bytes of less useful data */
+ if (size < sizeof(struct ddr_details_v3))
+ return -EINVAL;
+
+ if (size == sizeof(struct ddr_details_v3))
+ return INFO_V3;
+
+ if (size == sizeof(struct ddr_details_v3_14freqs))
+ return INFO_V3_WITH_14_FREQS;
+
+ if (size == sizeof(struct ddr_details_v4))
+ return INFO_V4;
+
+ if (size == sizeof(struct ddr_details_v5) +
+ 4 * sizeof(struct ddr_region_v5))
+ return INFO_V5;
+
+ if (size == sizeof(struct ddr_details_v5) +
+ 4 * sizeof(struct ddr_region_v5) +
+ sizeof(struct ddr_xbl2quantum_smem_data) +
+ sizeof(struct shub_freq_plan_entry))
+ return INFO_V5;
+
+ if (size == sizeof(struct ddr_details_v5) +
+ 6 * sizeof(struct ddr_region_v5))
+ return INFO_V5_WITH_6_REGIONS;
+
+ if (size == sizeof(struct ddr_details_v5) +
+ 6 * sizeof(struct ddr_region_v5) +
+ sizeof(struct ddr_xbl2quantum_smem_data) +
+ sizeof(struct shub_freq_plan_entry))
+ return INFO_V5_WITH_6_REGIONS;
+
+ if (size == sizeof(struct ddr_details_v5) +
+ 6 * sizeof(struct ddr_region_v5) +
+ sizeof(struct ddr_misc_info_v6) +
+ sizeof(struct shub_freq_plan_entry))
+ return INFO_V6;
+
+ if (size == sizeof(struct ddr_details_v7) +
+ 4 * sizeof(struct ddr_region_v5) +
+ sizeof(struct ddr_misc_info_v6) +
+ sizeof(struct shub_freq_plan_entry))
+ return INFO_V7;
+
+ if (size == sizeof(struct ddr_details_v7) +
+ 6 * sizeof(struct ddr_region_v5) +
+ sizeof(struct ddr_misc_info_v6) +
+ sizeof(struct shub_freq_plan_entry))
+ return INFO_V7_WITH_6_REGIONS;
+
+ return INFO_UNKNOWN;
+}
+
+static int smem_dram_frequencies_show(struct seq_file *s, void *unused)
+{
+ struct smem_dram *dram = s->private;
+
+ for (int i = 0; i < dram->num_frequencies; i++)
+ seq_printf(s, "%lu\n", dram->frequencies[i]);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(smem_dram_frequencies);
+
+static int smem_hbb_show(struct seq_file *s, void *unused)
+{
+ struct smem_dram *dram = s->private;
+
+ if (!dram->hbb)
+ return -EINVAL;
+
+ seq_printf(s, "%d\n", dram->hbb);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(smem_hbb);
+
+struct dentry *smem_dram_parse(struct qcom_smem *smem, struct device *dev)
+{
+ struct dentry *debugfs_dir;
+ enum ddr_info_version ver;
+ struct smem_dram *dram;
+ size_t actual_size;
+ void *data;
+
+ /* No need to check qcom_smem_is_available(), this func is called by the SMEM driver */
+ data = __qcom_smem_get(smem, QCOM_SMEM_HOST_ANY, SMEM_DDR_INFO_ID, &actual_size);
+ if (IS_ERR_OR_NULL(data))
+ return ERR_PTR(-ENODATA);
+
+ ver = smem_dram_infer_struct_version(actual_size);
+ if (ver < 0) {
+ /* Some SoCs don't provide data that's useful for us */
+ return ERR_PTR(-ENODATA);
+ } else if (ver == INFO_UNKNOWN) {
+ /* In other cases, we may not have added support for a newer struct revision */
+ dev_err(dev, "Found an unknown type of DRAM info struct (size = %zu)\n",
+ actual_size);
+ return ERR_PTR(-EINVAL);
+ }
+
+ dram = devm_kzalloc(dev, sizeof(*dram), GFP_KERNEL);
+ if (!dram)
+ return ERR_PTR(-ENOMEM);
+
+ switch (ver) {
+ case INFO_V3:
+ smem_dram_parse_v3_data(dram, data);
+ break;
+ case INFO_V3_WITH_14_FREQS:
+ smem_dram_parse_v3_14freqs_data(dram, data);
+ break;
+ case INFO_V4:
+ smem_dram_parse_v4_data(dram, data);
+ break;
+ case INFO_V5:
+ case INFO_V5_WITH_6_REGIONS:
+ case INFO_V6:
+ smem_dram_parse_v5_data(dram, data);
+ break;
+ case INFO_V7:
+ case INFO_V7_WITH_6_REGIONS:
+ smem_dram_parse_v7_data(dram, data);
+ break;
+ default:
+ return ERR_PTR(-EINVAL);
+ }
+
+ debugfs_dir = debugfs_create_dir("qcom_smem", NULL);
+ debugfs_create_file("dram_frequencies", 0444, debugfs_dir, dram,
+ &smem_dram_frequencies_fops);
+ debugfs_create_file("hbb", 0444, debugfs_dir, dram, &smem_hbb_fops);
+
+ __dram = dram;
+
+ return debugfs_dir;
+}
diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
index f946e3beca21..3249cbd2016b 100644
--- a/include/linux/soc/qcom/smem.h
+++ b/include/linux/soc/qcom/smem.h
@@ -17,4 +17,6 @@ int qcom_smem_get_feature_code(u32 *code);
int qcom_smem_bust_hwspin_lock_by_host(unsigned int host);
+int qcom_smem_dram_get_hbb(void);
+
#endif
--
2.55.0
^ permalink raw reply related
* [PATCH v5 1/3] soc: qcom: smem: Use 'unsigned int' instead of 'unsigned'
From: Konrad Dybcio @ 2026-07-27 9:59 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Kees Cook, Gustavo A. R. Silva,
Rob Clark, Sean Paul, Akhil P Oommen, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Alim Akhtar, Avri Altman, Bart Van Assche,
James E.J. Bottomley, Martin K. Petersen, Matthias Brugger,
AngeloGioacchino Del Regno, Suzuki K Poulose, Mike Leach,
James Clark, Leo Yan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yuanfang Zhang, Mao Jinlong, Jie Gan, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arm-msm, linux-hardening, dri-devel,
freedreno, Konrad Dybcio, linux-scsi, linux-arm-kernel,
linux-mediatek, coresight, devicetree, linux-riscv
In-Reply-To: <20260727-topic-smem_dramc-v5-0-66188b3e338d@oss.qualcomm.com>
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
checkpatch.pl reports:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
Convert the SMEM driver to use the less ambiguous type instead.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/soc/qcom/smem.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index afb21a778fe7..43b66120fc64 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -281,7 +281,7 @@ struct qcom_smem {
struct smem_partition global_partition;
struct xarray partitions;
- unsigned num_regions;
+ unsigned int num_regions;
struct smem_region regions[] __counted_by(num_regions);
};
@@ -399,7 +399,7 @@ EXPORT_SYMBOL_GPL(qcom_smem_is_available);
static int qcom_smem_alloc_private(struct qcom_smem *smem,
struct smem_partition *part,
- unsigned item,
+ unsigned int item,
size_t size)
{
struct smem_private_entry *hdr, *end;
@@ -460,7 +460,7 @@ static int qcom_smem_alloc_private(struct qcom_smem *smem,
}
static int qcom_smem_alloc_global(struct qcom_smem *smem,
- unsigned item,
+ unsigned int item,
size_t size)
{
struct smem_global_entry *entry;
@@ -503,7 +503,7 @@ static int qcom_smem_alloc_global(struct qcom_smem *smem,
*
* Return: 0 on success, negative errno on failure.
*/
-int qcom_smem_alloc(unsigned host, unsigned item, size_t size)
+int qcom_smem_alloc(unsigned int host, unsigned int item, size_t size)
{
struct smem_partition *part;
unsigned long flags;
@@ -544,7 +544,7 @@ int qcom_smem_alloc(unsigned host, unsigned item, size_t size)
EXPORT_SYMBOL_GPL(qcom_smem_alloc);
static void *qcom_smem_get_global(struct qcom_smem *smem,
- unsigned item,
+ unsigned int item,
size_t *size)
{
struct smem_header *header;
@@ -553,7 +553,6 @@ static void *qcom_smem_get_global(struct qcom_smem *smem,
u64 entry_offset;
u32 e_size;
u32 aux_base;
- unsigned i;
header = smem->regions[0].virt_base;
entry = &header->toc[item];
@@ -562,7 +561,7 @@ static void *qcom_smem_get_global(struct qcom_smem *smem,
aux_base = le32_to_cpu(entry->aux_base) & AUX_BASE_MASK;
- for (i = 0; i < smem->num_regions; i++) {
+ for (unsigned int i = 0; i < smem->num_regions; i++) {
region = &smem->regions[i];
if ((u32)region->aux_base == aux_base || !aux_base) {
@@ -584,7 +583,7 @@ static void *qcom_smem_get_global(struct qcom_smem *smem,
static void *qcom_smem_get_private(struct qcom_smem *smem,
struct smem_partition *part,
- unsigned item,
+ unsigned int item,
size_t *size)
{
struct smem_private_entry *e, *end;
@@ -683,7 +682,7 @@ static void *qcom_smem_get_private(struct qcom_smem *smem,
*
* Return: a pointer to an SMEM item on success, ERR_PTR() on failure.
*/
-void *qcom_smem_get(unsigned host, unsigned item, size_t *size)
+void *qcom_smem_get(unsigned int host, unsigned int item, size_t *size)
{
struct smem_partition *part;
void *ptr;
@@ -717,12 +716,12 @@ EXPORT_SYMBOL_GPL(qcom_smem_get);
*
* Return: number of available bytes on success, negative errno on failure.
*/
-int qcom_smem_get_free_space(unsigned host)
+int qcom_smem_get_free_space(unsigned int host)
{
struct smem_partition *part;
struct smem_partition_header *phdr;
struct smem_header *header;
- unsigned ret;
+ unsigned int ret;
if (IS_ERR(__smem))
return PTR_ERR(__smem);
--
2.55.0
^ permalink raw reply related
* [PATCH v5 0/3] Retrieve information about DDR from SMEM
From: Konrad Dybcio @ 2026-07-27 9:59 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Kees Cook, Gustavo A. R. Silva,
Rob Clark, Sean Paul, Akhil P Oommen, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Alim Akhtar, Avri Altman, Bart Van Assche,
James E.J. Bottomley, Martin K. Petersen, Matthias Brugger,
AngeloGioacchino Del Regno, Suzuki K Poulose, Mike Leach,
James Clark, Leo Yan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yuanfang Zhang, Mao Jinlong, Jie Gan, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arm-msm, linux-hardening, dri-devel,
freedreno, Konrad Dybcio, linux-scsi, linux-arm-kernel,
linux-mediatek, coresight, devicetree, linux-riscv
SMEM allows the OS to retrieve information about the DDR memory.
Among that information, is a semi-magic value called 'HBB', or Highest
Bank address Bit, which multimedia drivers (for hardware like Adreno
and MDSS) must retrieve in order to program the IP blocks correctly.
This series introduces an API to retrieve that value, uses it in the
aforementioned programming sequences and exposes available DDR
frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More
information can be exposed in the future, as needed.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Changes in v5:
- Parse DRAM data before publishing __smem
- Add trivial patch 1 converting 'unsigned' to 'unsigned int' to make
checkpatch happy
- Link to v4: https://patch.msgid.link/20260721-topic-smem_dramc-v4-0-748f992278a3@oss.qualcomm.com
Changes in v4:
- Rebase on top of Dmitry's cleanups to ubwc_config
- Mark and consume the shared data as little-endian
- Fix compiler optimizing out what it thinks is impossible (odd
v3_14freq case)
- Rework qcom_ubwc_config_get_data() per discussion to not alter
hardcoded data
- Remove some unnecessary comments and assignments
- Return -ENODATA instead of -EINVAL for out-of-sensible-range HBB
- Cosmetic/line wrapping fixups
- Drop applied drm/msm patch
- Link to v3: https://lore.kernel.org/r/20260108-topic-smem_dramc-v3-0-6b64df58a017@oss.qualcomm.com
Changes in v3:
- Support v6 and v7 DDRInfo (v7 is used on e.g. Hamoa)
- Handle rare cases of DDRInfo v5 with additional trailing data
- Rebase/adjust to SSoT UBWC
- Expose hbb value in debugfs
- cosmetic changes
- Link to v2: https://lore.kernel.org/r/20250410-topic-smem_dramc-v2-0-dead15264714@oss.qualcomm.com
Changes in v2:
- Avoid checking for < 0 on unsigned types
- Overwrite Adreno UBWC data to keep the data shared with userspace
coherent with what's programmed into the hardware
- Call get_hbb() in msm_mdss_enable() instead of all UBWC setup
branches separately
- Pick up Bjorn's rb on patch 1
- Link to v1: https://lore.kernel.org/r/20250409-topic-smem_dramc-v1-0-94d505cd5593@oss.qualcomm.com
To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
To: Kees Cook <kees@kernel.org>
To: "Gustavo A. R. Silva" <gustavoars@kernel.org>
To: Alim Akhtar <alim.akhtar@samsung.com>
To: Avri Altman <avri.altman@sandisk.com>
To: Bart Van Assche <bvanassche@acm.org>
To: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Mike Leach <mike.leach@arm.com>
To: James Clark <james.clark@linaro.org>
To: Leo Yan <leo.yan@arm.com>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>
To: Mao Jinlong <jinlong.mao@oss.qualcomm.com>
To: Jie Gan <jie.gan@oss.qualcomm.com>
To: Paul Walmsley <pjw@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>
To: Albert Ou <aou@eecs.berkeley.edu>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-hardening@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: coresight@lists.linaro.org
Cc: devicetree@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
---
Konrad Dybcio (3):
soc: qcom: smem: Use 'unsigned int' instead of 'unsigned'
soc: qcom: smem: Expose DDR data from SMEM
soc: qcom: ubwc: Get HBB from SMEM
drivers/soc/qcom/Makefile | 3 +-
drivers/soc/qcom/smem.c | 80 +++++---
drivers/soc/qcom/smem.h | 12 ++
drivers/soc/qcom/smem_dramc.c | 430 +++++++++++++++++++++++++++++++++++++++++
drivers/soc/qcom/ubwc_config.c | 40 +++-
include/linux/soc/qcom/smem.h | 2 +
6 files changed, 533 insertions(+), 34 deletions(-)
---
base-commit: c5e32e86ca02b003f86e095d379b38148999293d
change-id: 20250409-topic-smem_dramc-6467187ac865
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 0/2] soc: fsl: dpio: Use scope-based resource management in two functions
From: Christophe Leroy (CS GROUP) @ 2026-07-27 9:57 UTC (permalink / raw)
To: Markus Elfring, Ioana Ciornei
Cc: LKML, linuxppc-dev, Roy Pledge, kernel-janitors, linux-arm-kernel
In-Reply-To: <d2e5df25-c8b7-4ee6-8ebf-1725542baabd@web.de>
Hi Ioana,
Le 06/07/2026 à 12:36, Markus Elfring a écrit :
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 6 Jul 2026 11:42:10 +0200
>
> Some adjustment opportunities were picked up.
>
> Markus Elfring (2):
> Use scope-based resource management in dpaa2_io_store_create()
> Use scope-based resource management in dpaa2_io_create()
>
As the (new) maintainer of drivers/soc/fsl/dpio, could you have a look
at this series ?
Thanks
Christophe
>
> v2:
> Christophe Leroy requested to apply the attribute “__free(kfree)”.
>
>
> drivers/soc/fsl/dpio/dpio-service.c | 37 ++++++++++-------------------
> 1 file changed, 12 insertions(+), 25 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] soc: fsl: dpio: Remove redundant dev_err()
From: Ioana Ciornei @ 2026-07-27 9:55 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Pan Chuang, Roy Pledge, open list:FREESCALE SOC DRIVERS,
open list:DPAA2 DATAPATH I/O (DPIO) DRIVER,
moderated list:FREESCALE SOC DRIVERS
In-Reply-To: <877f0d7a-6eb9-4305-be24-20e97bb3edcb@kernel.org>
On Mon, Jul 27, 2026 at 11:47:02AM +0200, Christophe Leroy (CS GROUP) wrote:
> Hi Ioana,
>
> Le 23/07/2026 à 04:47, Pan Chuang a écrit :
> > Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
> > devm_request_*_irq()"), devm_request_irq() automatically logs
> > detailed error messages on failure. Remove the now-redundant
> > driver-specific dev_err() calls.
> >
> > Signed-off-by: Pan Chuang <panchuang@vivo.com>
>
> I plan to take this patch for v7.3, do you agree with this change ?
Yes, you can take it.
Acked-by: Ioana Ciornei <ioana.ciornei@nxp.com>
^ 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