* Re: [PATCH] pmdomain: ti_sci: add wakeup constraint to parent devices of wakeup source
From: Vitor Soares @ 2026-05-13 9:40 UTC (permalink / raw)
To: Kendall Willis
Cc: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Ulf Hansson,
Kevin Hilman, Dhruva Gole, linux-arm-kernel, linux-pm,
linux-kernel, stable, tomi.valkeinen, sebin.francis, devarsht,
vigneshr, vishalm, vitor.soares
In-Reply-To: <20260512161737.pflweaz2r3q3nrfl@uda0506412>
On Tue, 2026-05-12 at 11:17 -0500, Kendall Willis wrote:
> On 17:51-20260511, Vitor Soares wrote:
> > Hi Kendall,
> >
> > On Wed, 2026-05-06 at 22:16 -0500, Kendall Willis wrote:
> > > Set wakeup constraint for any device in a wakeup path. All parent devices
> > > of a wakeup device should not be turned off during suspend. This ensures
> > > the wakeup device is kept on while the system is suspended.
> > >
> >
> > Thanks for the patch.
> >
> > I tested it on our Verdin AM62P. As expected, suspend now fails cleanly with
> > "-
> > 19" when an SDIO WiFi module is registered as a wakeup source, instead of
> > crashing on resume:
> >
> > ti-sci 44043000.system-controller: PM: failed to suspend: error -19
> >
> > I did not test the IO daisy chain wakeup path, since that is out of scope
> > for
> > this patch.
> >
> > Best regards,
> > Vitor Soares
> >
>
> Hi Vitor,
>
> Thanks for testing the patch! Could you add your Tested-by tag?
>
> Best,
> Kendall
Hi Kendall,
Sure:
Tested-by: Vitor Soares vitor.soares@toradex.com
Best regards,
Vitor
^ permalink raw reply
* Re: [RFC V2 00/14] arm64/mm: Enable 128 bit page table entries
From: Lorenzo Stoakes @ 2026-05-13 9:39 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Mark Rutland, Andrew Morton, David Hildenbrand, Mike Rapoport,
Linu Cherian, Usama Arif, linux-kernel, linux-mm
In-Reply-To: <20260513044547.4128549-1-anshuman.khandual@arm.com>
-cc my previous kernel address
Hi Anshuman,
Sorry to be a pain, but I'm using ljs@kernel.org now for my kernel mail, so
I am at risk of missing stuff sent to my @oracle.com address (I changed
things around to make managing the... rather large quantities of mail I get
a bit easier :)
Hence I missed this previously, can you send future revisions to
ljs@kernel.org? Thanks!
Cheers, Lorenzo
On Wed, May 13, 2026 at 10:15:33AM +0530, Anshuman Khandual wrote:
> FEAT_D128 is a new arm architecture feature adding support for VMSAv9-128
> translation system. FEAT_D128 is an optional feature from ARMV9.3 onwards.
> So with this feature arm64 platforms could have two different translation
> systems, VMSAv8-64 and VMSAv9-128 could selectively be enabled.
>
> FEAT_D128 adds 128 bit page table entries, thus supporting larger physical
> and virtual address range while also expanding available room for more MMU
> management feature bits both for HW and SW.
>
> This series has been split into two parts. Generic MM changes followed by
> arm64 platform changes, finally enabling D128 with a new config ARM64_D128.
>
> READ_ONCE() on page table entries get routed via level specific pxdp_get()
> helpers which platforms could then override when required. These accessors
> on arm64 platform help in ensuring page table accesses are performed in an
> atomic manner while reading 128 bit page table entries.
>
> All ARM64_VA_BITS and ARM64_PA_BITS combinations for all page sizes are now
> supported both on D64 and D128 translation regimes. Although new 56 bits VA
> space is not yet supported. Similarly FEAT_D128 skip level is not supported
> currently.
>
> Basic page table geometry has also been changed with D128 as there are fewer
> entries per level. Please refer to the following table for leaf entry sizes.
>
> D64 D128
> ------------------------------------------------
> | PAGE_SIZE | PMD | PUD | PMD | PUD |
> -----------------------------|-----------------|
> | 4K | 2M | 1G | 1M | 256M |
> | 16K | 32M | 64G | 16M | 16G |
> | 64K | 512M | 4T | 256M | 1T |
> ------------------------------------------------
>
> D64 D128
> --------------------------------------------------------------------
> | PAGE_SIZE | CONT_PTE | CONT_PMD | CONT_PTE | CONT_PMD |
> --------------------------|------------|-------------|--------------
> | 4K | 64K | 32M | 64K | 16M |
> | 16K | 2M | 1G | 1M | 256M |
> | 64K | 2M | 16G | 1M | 16G |
> --------------------------------------------------------------------
>
> From arm64 kernel features perspective KVM, KASAN and UNMAP_KERNEL_AT_EL0
> are currently not supported as well.
>
> This series applies on v7.1-rc3 and there are no apparent problems while
> running MM kselftests with and without CONFIG_ARM64_D128. Besides this has
> been built tested on other platform such as x86, powerpc, riscv, arm and
> s390 etc.
>
> Changes in RFC V2:
>
> - Dropped some patches that were merged upstream and rebased on v7.1-rc3
> - Moved pxdval_t definition inside generic page table header per Mike
> - Restored print format in __print_bad_page_map_pgtable() per Usama
> - Renamed __PRIpte as __PRIpxx per David
> - Dropped _once from pgprot_[read|write]() callbacks per Mike
> - Moved back all helpers back from arch/arm64/mm/mmu.c into the header
> - Renamed all ptdesc_ instances as pxxval_ instead
> - Moved arm64 pgtable header READ_ONCE() replacements later in the series
> - Updated commit message for the 5-level fixmap change per David
> - Updated ARM64_CONT_[PTE|PMD]_SHIFT both for 16K and 64K base pages
> - Added abstraction for tlbi_op
> - Adopted TLBIP implementation to recent TLB flush changes
> - Updated all commit messages as required and suggested
>
> Changes in RFC V1:
>
> https://lore.kernel.org/linux-arm-kernel/20260224051153.3150613-2-anshuman.khandual@arm.com/
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Linu Cherian <linu.cherian@arm.com>
> Cc: Usama Arif <usama.arif@linux.dev>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-mm@kvack.org
>
> Anshuman Khandual (13):
> mm: Abstract printing of pxd_val()
> mm: Add read-write accessors for vm_page_prot
> arm64/mm: Convert READ_ONCE() as pmdp_get() while accessing PMD
> arm64/mm: Convert READ_ONCE() as pudp_get() while accessing PUD
> arm64/mm: Convert READ_ONCE() as p4dp_get() while accessing P4D
> arm64/mm: Convert READ_ONCE() as pgdp_get() while accessing PGD
> arm64/mm: Route all pgtable reads via pxxval_get()
> arm64/mm: Route all pgtable writes via pxxval_set()
> arm64/mm: Route all pgtable atomics to central helpers
> arm64/mm: Abstract printing of pxd_val()
> arm64/mm: Override read-write accessors for vm_page_prot
> arm64/mm: Enable fixmap with 5 level page table
> arm64/mm: Add initial support for FEAT_D128 page tables
>
> Linu Cherian (1):
> arm64/mm: Add an abstraction level for tlbi_op
>
> arch/arm64/Kconfig | 51 +++++++-
> arch/arm64/Makefile | 4 +
> arch/arm64/include/asm/assembler.h | 4 +-
> arch/arm64/include/asm/el2_setup.h | 9 ++
> arch/arm64/include/asm/pgtable-hwdef.h | 137 ++++++++++++++++++++
> arch/arm64/include/asm/pgtable-prot.h | 18 ++-
> arch/arm64/include/asm/pgtable-types.h | 12 ++
> arch/arm64/include/asm/pgtable.h | 169 ++++++++++++++++++++-----
> arch/arm64/include/asm/smp.h | 1 +
> arch/arm64/include/asm/tlbflush.h | 138 ++++++++++++++------
> arch/arm64/kernel/head.S | 12 ++
> arch/arm64/mm/fault.c | 20 +--
> arch/arm64/mm/fixmap.c | 24 +++-
> arch/arm64/mm/hugetlbpage.c | 10 +-
> arch/arm64/mm/kasan_init.c | 14 +-
> arch/arm64/mm/mmu.c | 65 +++++-----
> arch/arm64/mm/pageattr.c | 8 +-
> arch/arm64/mm/proc.S | 25 +++-
> arch/arm64/mm/trans_pgd.c | 14 +-
> include/linux/pgtable.h | 25 ++++
> mm/huge_memory.c | 4 +-
> mm/memory.c | 25 ++--
> mm/migrate.c | 2 +-
> mm/mmap.c | 2 +-
> 24 files changed, 624 insertions(+), 169 deletions(-)
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v3 06/13] pmdomain: core: Add initial fine grained sync_state support
From: Ulf Hansson @ 2026-05-13 9:35 UTC (permalink / raw)
To: Saravana Kannan
Cc: Danilo Krummrich, Rafael J . Wysocki, Greg Kroah-Hartman,
driver-core, linux-pm, Sudeep Holla, Cristian Marussi,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Geert Uytterhoeven,
Dmitry Baryshkov, linux-arm-kernel, linux-kernel
In-Reply-To: <CACRMN=cyMjHtW1xjoYPWa8_TjmQEoJBvKtMo-UgP5yZJ=zDh2Q@mail.gmail.com>
On Wed, 13 May 2026 at 07:34, Saravana Kannan <saravanak@kernel.org> wrote:
>
> On Mon, May 11, 2026 at 3:25 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Mon, 11 May 2026 at 07:09, Saravana Kannan <saravanak@kernel.org> wrote:
> > >
> > > On Fri, May 8, 2026 at 5:39 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > >
> > > > A onecell (#power-domain-cells = <1 or 2>; in DT) power domain provider
> > > > typically provides multiple independent power domains, each with their own
> > > > corresponding consumers. In these cases we have to wait for all consumers
> > > > for all the provided power domains before the ->sync_state() callback gets
> > > > called for the supplier.
> > > >
> > > > In a first step to improve this, let's implement support for fine grained
> > > > sync_state support a per genpd basis by using the ->queue_sync_state()
> > > > callback. To take step by step, let's initially limit the improvement to
> > > > the internal genpd provider driver and to its corresponding genpd devices
> > > > for onecell providers.
> > > >
> > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > > > ---
> > > >
> > > > Changes in v3:
> > > > - Addressed some cosmetic comments from Geert.
> > > >
> > > > ---
> > > > drivers/pmdomain/core.c | 124 ++++++++++++++++++++++++++++++++++++++
> > > > include/linux/pm_domain.h | 1 +
> > > > 2 files changed, 125 insertions(+)
> > > >
> > > > diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
> > > > index ad57846f02a3..c01a9a96e5c2 100644
> > > > --- a/drivers/pmdomain/core.c
> > > > +++ b/drivers/pmdomain/core.c
> > > > @@ -2699,6 +2699,119 @@ static struct generic_pm_domain *genpd_get_from_provider(
> > > > return genpd;
> > > > }
> > > >
> > > > +static bool genpd_should_wait_for_consumer(struct device_node *np)
> > > > +{
> > > > + struct generic_pm_domain *genpd;
> > > > + bool should_wait = false;
> > > > +
> > > > + mutex_lock(&gpd_list_lock);
> > > > + list_for_each_entry(genpd, &gpd_list, gpd_list_node) {
> > > > + if (genpd->provider == of_fwnode_handle(np)) {
> > > > + genpd_lock(genpd);
> > > > +
> > > > + /* Clear the previous state before reevaluating. */
> > > > + genpd->wait_for_consumer = false;
> > > > +
> > > > + /*
> > > > + * Unless there is at least one genpd for the provider
> > > > + * that is being kept powered-on, we don't have to care
> > > > + * about waiting for consumers.
> > > > + */
> > > > + if (genpd->stay_on)
> > > > + should_wait = true;
> > > > +
> > > > + genpd_unlock(genpd);
> > > > + }
> > > > + }
> > > > + mutex_unlock(&gpd_list_lock);
> > >
> > > I think I understand the intent of this function, but haven't dug into
> > > genpd code enough to comment on this yet. I'll come back to this
> > > later.
> > >
> > > > +
> > > > + return should_wait;
> > > > +}
> > > > +
> > > > +static void genpd_parse_for_consumer(struct device_node *sup,
> > > > + struct device_node *con)
> > > > +{
> > > > + struct generic_pm_domain *genpd;
> > > > +
> > > > + for (unsigned int i = 0; ; i++) {
> > > > + struct of_phandle_args pd_args;
> > > > +
> > > > + if (of_parse_phandle_with_args(con, "power-domains",
> > > > + "#power-domain-cells",
> > > > + i, &pd_args))
> > > > + break;
> > >
> > > Why not use a while or a do while() instead of this infinite for loop
> > > with a break?
> >
> > I guess it's a matter of personal preference. I'm not sure the code
> > gets any nicer with a do/while, but if you really insist I can change
> > it.
> >
> > >
> > > > +
> > > > + /*
> > > > + * The phandle must correspond to the supplier's genpd provider
> > > > + * to be relevant else let's move to the next index.
> > > > + */
> > > > + if (sup != pd_args.np) {
> > > > + of_node_put(pd_args.np);
> > > > + continue;
> > > > + }
> > > > +
> > > > + mutex_lock(&gpd_list_lock);
> > > > + genpd = genpd_get_from_provider(&pd_args);
> > > > + if (!IS_ERR(genpd)) {
> > > > + genpd_lock(genpd);
> > > > + genpd->wait_for_consumer = true;
> > > > + genpd_unlock(genpd);
> > > > + }
> > > > + mutex_unlock(&gpd_list_lock);
> > > > +
> > > > + of_node_put(pd_args.np);
> > > > + }
> > > > +}
> > > > +
> > > > +static void _genpd_queue_sync_state(struct device_node *np)
> > > > +{
> > > > + struct generic_pm_domain *genpd;
> > > > +
> > > > + mutex_lock(&gpd_list_lock);
> > > > + list_for_each_entry(genpd, &gpd_list, gpd_list_node) {
> > > > + if (genpd->provider == of_fwnode_handle(np)) {
> > > > + genpd_lock(genpd);
> > > > + if (genpd->stay_on && !genpd->wait_for_consumer) {
> > > > + genpd->stay_on = false;
> > > > + genpd_queue_power_off_work(genpd);
> > > > + }
> > > > + genpd_unlock(genpd);
> > > > + }
> > > > + }
> > > > + mutex_unlock(&gpd_list_lock);
> > > > +}
> > > > +
> > > > +static void genpd_queue_sync_state(struct device *dev)
> > > > +{
> > > > + struct device_node *np = dev->of_node;
> > > > + struct device_link *link;
> > > > +
> > > > + if (!genpd_should_wait_for_consumer(np))
> > > > + return;
> > > > +
> > > > + list_for_each_entry(link, &dev->links.consumers, s_node) {
> > >
> > > Couple of issues:
> > > 1. I don't want the frameworks to be so deeply aware of driver core
> > > internals. I want the driver core maintainers to be able to change the
> > > devlink implementation without having to worry about going and fixing
> > > all the frameworks. So, please add a for_each_consumer_dev(supplier,
> > > callback) and for_each_supplier_dev(consumer, callback) helper
> > > functions.
> >
> > I understand your concern and I like the idea. However, maybe it's
> > better to get this landed (the series is complicated as is) first and
> > then can continue to improve the code on top, with helper functions
> > etc.
>
> That patch should be pretty simple, so let's just do it? You are
> literally just moving the code to another file and massaging it a bit.
> I can send one out if you want/
Okay, I will fold in a patch into my series that adds the helper. No
point you sending it as it needs to be apart of my series to have a
user for it.
>
> > >
> > > 2. This doesn't ignore "SYNC_STATE_ONLY" links and that's going to
> > > confuse the consumer count/check you might do or at the least waste
> > > parsing those.
> >
> > I am not sure I understand how I should take SYNC_STATE_ONLY links
> > into account here.
> >
> > At each call to the genpd_queue_sync_state(), we walk through all the
> > provided genpds for the provider. No previous state is cached to track
> > consumer counts.
>
> Ok, correct me if I'm wrong here, but it looks like you are looking at
> all the consumers, finding the ones that haven't probed yet and then
> trying to see which specific genpd provider each one of them is using
> by parsing their dt properties and then keep those ON.
The code cares only about the genpd OF provider that the supplier
device belongs to, if any. Any other genpd OF providers and their
genpds is untouched.
The corresponding genpd OF provider may provide multiple genpds
through the same fwnode.
>
> If my understanding above is wrong then, please help me understand
> what the code is trying to do.
>
> If it's right, then here's the issue:
>
> fw_devlink relies on device links and fwnode links to keep track of
> consumers. fwnode links get created first and then get converted to
> device links when both the supplier AND consumer devices are created.
>
> Consider a case when the supplier S is created and the consumer device
> C is several levels deep inside a parent device A.
> S { #power-domain-cells = <1>; }
> A { B { C { power-domains = <&S MY_DOMAIN>; } } }
>
> fw_devlink can't just go "oh there's no consumer device that hasn't
> probed yet, let me call sync_state()". It needs to wait for C. But
> there's no way to create a device link to C. So, here's the sequence
> that happens:
>
> 1. When device A gets added, it creates a "proxy" SYNC_STATE_ONLY link
> between S and A.
> 2. When A probes, it adds device B.
> 3. The SYNC_STATE_ONLY link between S to B is created.
> 4. The SYNC_STATE_ONLY link between S to A is deleted.
> 5. When B probes, it adds device C.
> 6. The actual device link between S and C is created.
> 7. The SYNC_STATE_ONLY link between S to B is deleted.
> 8. Device C probes, the device links get updated, sync_state() gets called.
>
> So, if your code doesn't account for SYNC_STATE_ONLY links, you are
> going to check device "A" to see which providers are used. You'll
> think that MY_DOMAIN isn't used by any unprobed consumer and turn it
> off.
>
> >
> > >
> > > 3. **Device** links are not the complete list of consumers because
> > > they can only link consumer **devices** once the consumer **device**
> > > is created.
> > >
> > > 4. What you really need is a for_each_consumer_fwnode(supplier,
> > > callback) that first loops through all the consumer device links and
> > > calls the callback() on their fwnode and then the same function needs
> > > to loop through all the fwnode links and then pass those consumer
> > > fwnodes to the callback. And inside that callback you can do whatever
> > > you want.
> >
> > The ->queue_sync_state() callback is invoked *after*
> > __device_links_queue_sync_state() has been called for the device,
> > which is also when the conditions for calling ->sync_state() is
> > checked.
>
> I'm not sure what you are trying to say here. Yes, what you are saying
> is true. But at the point the current code returns before calling
> sync_state(), your patch 2/13 ends up calling the "consumer_probed()"
> callback.
>
> If you see the example I gave above, there is a SYNC_STATE_ONLY link
> all the way up to step 7 that'll prevent sync_state() from being
> called. And until step 5, there is no device link between S and C and
> you'll have to go look at S's fwnode links to find C.
Thanks for the details, but I don't think the code in genpd needs to
take these details into account. Or at least that is my goal, if
possible.
As I understand it, all of the above should already been taken care of
when __device_links_queue_sync_state() is called, as it's at that
point when we can validate whether all consumers for a supplier have
been probed, right?
>
> > If there are problems with not yet registered consumer device links,
> > why isn't that as problem for regular ->sync_state() in
> > __device_links_queue_sync_state()?
>
> Does my explanation above make sense?
I think you may have misunderstood how the code in $subject patch
works. Let's try again.
>
> Welcome to the annoying worlds of fw_devlink corner cases/nuances.
> There's a case where the child is the supplier of the
> parent/grandparent. There's a comment for that in the fw_devlink code.
Yeah, I am fully aware of the high level of complexity and as I said,
I don't want genpd to have to know about *all* of that.
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] coresight: trbe: Hide enable_sink sysfs file
From: James Clark @ 2026-05-13 9:33 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Mike Leach, Alexander Shishkin, coresight,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260513081551.GC34802@e132581.arm.com>
On 13/05/2026 9:15 am, Leo Yan wrote:
> On Thu, May 07, 2026 at 11:53:45AM +0100, James Clark wrote:
>
> [...]
>
>> +static umode_t coresight_attr_is_visible(struct kobject *kobj,
>> + struct attribute *attr, int n)
>> {
>> struct device *dev = kobj_to_dev(kobj);
>> + struct coresight_device *csdev = to_coresight_device(dev);
>>
>> if (attr == &dev_attr_label.attr) {
>> if (fwnode_property_present(dev_fwnode(dev), "label"))
>> return attr->mode;
>> else
>> return 0;
>> + } else if (attr == &dev_attr_enable_sink.attr ||
>> + attr == &dev_attr_enable_source.attr) {
>> + if (csdev->no_sysfs_mode)
>> + return 0;
>> + else
>> + return attr->mode;
>
> I'd prefer no_sysfs_mode to work as a general flag rather than being
> limited to sink/source devices only. Otherwise, LGTM.
>
> Thanks,
> Leo
Which other files would you hide though? These are the only two that I
could think of.
I wouldn't hide all sysfs files for 'no_sysfs_mode' as there are read
only things that aren't strictly related to sysfs mode.
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-13 9:24 UTC (permalink / raw)
To: Marc Zyngier, Paolo Bonzini
Cc: Jonathan Corbet, Shuah Khan, kvm, linux-doc, linux-kernel,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <86h5obya2r.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4564 bytes --]
On Wed, 2026-05-13 at 09:42 +0100, Marc Zyngier wrote:
> On Mon, 11 May 2026 17:56:15 +0100,
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> > On 5/11/26 18:38, David Woodhouse wrote:
> > > Not *everything* is in CPUID; one recent exception that comes to mind
> > > is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the
> > > existing behaviour of older kernels — even when that behaviour doesn't
> > > make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would
> > > *advertise* the feature, but not actually *implement* it. Nevertheless,
> > > that remains the default behaviour of future kernels unless userspace
> > > explicitly opts in to fully enable (or disable) the feature.
> > >
> > > But this documentation update isn't even asking for that compatible-by-
> > > default behaviour, even though that is the right thing to do. It's only
> > > asking that it be *possible* to reinstate the old behaviour, for
> > > userspace that *knows* about the change and explicitly wants to go back
> > > to the old way to remain compatible.
> >
> > Yep, these are the "quirks"---if it's too early for Arm to commit to
> > that, I guess it's fine.
>
> Compatible by default means nothing, because userspace needs to
> discover the combined capabilities of the host and KVM. This is not a
> "CPU model" architecture.
>
> If userspace is not a total joke, it will read all the ID registers,
> and configure what it wants to see, assuming it is a feature that can
> be configured (not everything can, because the architecture itself is
> not fully backward compatible).
>
> Yes, this is buggy at times, because the combinatorial explosion of
> CPU capabilities and supported features makes it pretty hard to test
> (and really nobody actually does). But overall, it works, and QEMU is
> growing an infrastructure to manage it in a "user friendly" way.
Yes, that is precisely what I'm asking for. I'm prepared to deal with
the fact that KVM/Arm64 is not a stable and mature platform like x86
is, and that userspace has to find all the random changes from one
version to the next, and explicitly pin things down to be compatible.
All I'm asking for is that KVM makes it *possible* to pin things down
to the behaviour of previously released Linux/KVM kernels.
> But really, this isn't what David is asking. He's demanding "bug for
> bug" compatibility. For that, we have two possible cases:
No, I am not asking you to meet that bar. I merely observed that x86
does and that it would be nice. But we are a *long* way from that.
> - this is a behaviour that, while undesirable, is allowed by the
> architecture: fine, we preserve the behaviour and add another way to
> expose the one we really want. it is ugly, but we manage.
>
> - this is a behaviour that is not allowed by the architecture: we fix
> it for good. We do that on every release. Some minor, some much more
> visible. And there is no way we will add this sort of "bring the
> bugs back" type of behaviours. Specially when it is really obvious
> that no SW can make any reasonable use of the defect. We allow
> userspace to keep behaving as before, but the guest will not see a
> non-compliant behaviour.
>
> That being said, there is a way out of that: convince people in charge
> of the architecture that the non-compliant KVM behaviour is actually
> valuable, and deserves to be tolerated. This has happened before (VHE
> only and NV2 only, just to name two recent changes).
>
> Other terrible hacks (such as GICv3's GICD_TYPER.num_LPIs which KVM
> doesn't support) were added at the request of cloud vendors that David
> might be familiar with, so it isn't like it is a brand new process.
>
> And once it is in the architecture, it becomes a behaviour that is
> allowed to be exposed to a guest, for better or worse.
Marc, this is complete nonsense and you should know better.
Once a behaviour is present in a released version of Linux/KVM, we
can't just declare it "wrong" and unilaterally impose a change in
guest-visible behaviour on *running* guests as a side-effect of a
kernel upgrade.
The criterion for *KVM* to remain compatible is "once it has been in a
released version of the kernel". Not "once it is in the architecture".
> These are the rules we have followed since we started KVM/arm, and I
> intend to stick to them.
Then KVM/arm is falling far short of the standards we expect of KVM and
of Linux in general.
Please do better.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH 10/10] clk: amlogic: Add A9 AO clock controller driver
From: Jian Hu @ 2026-05-13 9:19 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <agH5q01HHszGc6ud@redhat.com>
On 5/11/2026 11:45 PM, Brian Masney wrote:
> [ EXTERNAL EMAIL ]
>
> Hi Jian,
>
> On Mon, May 11, 2026 at 08:47:32PM +0800, Jian Hu via B4 Relay wrote:
>> From: Jian Hu <jian.hu@amlogic.com>
>>
>> Add the Always-on clock controller driver for the Amlogic A9 SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> I'll only flag new things that I spot here that weren't mentioned in
> the other patches I reviewed in this series.
Got you, I will sort the header, also use
CLK_HW_INIT_FW_NAME/CLK_HW_INIT_HWS for this driver.
[......]
>> +static A9_COMP_SEL(ao_pwm_a, AO_PWM_CLK_A_CTRL, 9, 0x7, a9_ao_pwm_parents);
>> +static A9_COMP_DIV(ao_pwm_a, AO_PWM_CLK_A_CTRL, 0, 8);
>> +static A9_COMP_GATE(ao_pwm_a, AO_PWM_CLK_A_CTRL, 8);
>> +
>> +static A9_COMP_SEL(ao_pwm_b, AO_PWM_CLK_B_CTRL, 9, 0x7, a9_ao_pwm_parents);
>> +static A9_COMP_DIV(ao_pwm_b, AO_PWM_CLK_B_CTRL, 0, 8);
>> +static A9_COMP_GATE(ao_pwm_b, AO_PWM_CLK_A_CTRL, 8);
> Should this be AO_PWM_CLK_B_CTRL ?
Yes, it should be AO_PWM_CLK_B_CTRL.
Thank you for pointing it out.
>> +
>> +static A9_COMP_SEL(ao_pwm_c, AO_PWM_CLK_C_CTRL, 9, 0x7, a9_ao_pwm_parents);
>> +static A9_COMP_DIV(ao_pwm_c, AO_PWM_CLK_C_CTRL, 0, 8);
>> +static A9_COMP_GATE(ao_pwm_c, AO_PWM_CLK_C_CTRL, 8);
>> +
>> +static A9_COMP_SEL(ao_pwm_d, AO_PWM_CLK_D_CTRL, 9, 0x7, a9_ao_pwm_parents);
>> +static A9_COMP_DIV(ao_pwm_d, AO_PWM_CLK_D_CTRL, 0, 8);
>> +static A9_COMP_GATE(ao_pwm_d, AO_PWM_CLK_D_CTRL, 8);
>> +
>> +static A9_COMP_SEL(ao_pwm_e, AO_PWM_CLK_E_CTRL, 9, 0x7, a9_ao_pwm_parents);
>> +static A9_COMP_DIV(ao_pwm_e, AO_PWM_CLK_E_CTRL, 0, 8);
>> +static A9_COMP_GATE(ao_pwm_e, AO_PWM_CLK_E_CTRL, 8);
>> +
>> +static A9_COMP_SEL(ao_pwm_f, AO_PWM_CLK_F_CTRL, 9, 0x7, a9_ao_pwm_parents);
>> +static A9_COMP_DIV(ao_pwm_f, AO_PWM_CLK_F_CTRL, 0, 8);
>> +static A9_COMP_GATE(ao_pwm_f, AO_PWM_CLK_F_CTRL, 8);
>> +
>> +static A9_COMP_SEL(ao_pwm_g, AO_PWM_CLK_G_CTRL, 9, 0x7, a9_ao_pwm_parents);
>> +static A9_COMP_DIV(ao_pwm_g, AO_PWM_CLK_G_CTRL, 0, 8);
>> +static A9_COMP_GATE(ao_pwm_g, AO_PWM_CLK_G_CTRL, 8);
>> +
>> +static struct clk_regmap a9_ao_rtc_dualdiv_in = {
>> + .data = &(struct clk_regmap_gate_data){
>> + .offset = AO_RTC_BY_OSCIN_CTRL0,
>> + .bit_idx = 31,
>> + },
>> + .hw.init = &(struct clk_init_data) {
>> + .name = "ao_rtc_duandiv_in",
> s/duandiv/dualdiv/ ?
>
> Brian
Ok, I will fix the duandiv name.
Thank you for pointing it out.
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: Cubie A5E: enable SPI flash
From: Andre Przywara @ 2026-05-13 9:19 UTC (permalink / raw)
To: wens
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, devicetree, linux-arm-kernel, linux-sunxi
In-Reply-To: <CAGb2v64u4sqwiiQcEBg-XvmJ2DLEpSj-_AWNbp14RAp-GXP7OA@mail.gmail.com>
Hi Chen-Yu,
thanks for chipping in!
On 5/13/26 07:21, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, May 12, 2026 at 6:18 AM Andre Przywara <andre.przywara@arm.com> wrote:
>>
>> The Cubie A5E board comes with 16MiB of SPI NOR flash.
>>
>> Enable the SPI0 DT node and describe the configuration.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> .../boot/dts/allwinner/sun55i-a527-cubie-a5e.dts | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
>> index bfdf1728cd14b..7ad22fc85d1fd 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
>> @@ -344,6 +344,21 @@ &r_pio {
>> vcc-pm-supply = <®_aldo3>;
>> };
>>
>> +&spi0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&spi0_pc_pins>, <&spi0_cs0_pc_pin>,
>> + <&spi0_hold_pc_pin>, <&spi0_wp_pc_pin>;
>
> This whole thing needs to be an overlay. The HOLD and WP pins
> conflict with eMMC usage, so it seems that Radxa only populates
> one or the other.
>
> If you look at the pictures on their official website, you'll see the
> SPI NOR chip populated, but not the eMMC chip. On the linux-sunxi wiki
> page, you'll see the opposite.
Well, I have a hard time spotting any actual eMMC SKUs in the shops anyway.
But you are right, the hold and WP pins conflict with eMMC, whereas the
other pins are not.
> And you probably want to enable QSPI, like Sashiko mentioned.
Well, in the interest of keeping this simple and enabling the usage of
SPI flash for all the users out there, I'd rather drop the extra pins.
This is mostly really useful for booting the firmware, maybe loading a
tiny kernel or other data once, so performance is not a big concern in
this use case. The BootROM surely does not use QSPI.
And as you say, if people are really interested in the last bit of
performance, they can use an overlay.
Cheers,
Andre
>
>
> ChenYu
>
>
>> + status = "okay";
>> +
>> + flash@0 {
>> + compatible = "winbond,w25q128", "jedec,spi-nor";
>> + reg = <0>;
>> + spi-max-frequency = <40000000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + };
>> +};
>> +
>> &uart0 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&uart0_pb_pins>;
>> --
>> 2.46.4
>>
>
^ permalink raw reply
* Re: [PATCH v7 10/20] KVM: arm64: Context swap Partitioned PMU guest registers
From: Oliver Upton @ 2026-05-13 9:18 UTC (permalink / raw)
To: Colton Lewis
Cc: kvm, Alexandru Elisei, Paolo Bonzini, Jonathan Corbet,
Russell King, Catalin Marinas, Will Deacon, Marc Zyngier,
Oliver Upton, Mingwei Zhang, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Mark Rutland, Shuah Khan, Ganapatrao Kulkarni,
James Clark, linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <20260504211813.1804997-11-coltonlewis@google.com>
On Mon, May 04, 2026 at 09:18:03PM +0000, Colton Lewis wrote:
> +
> +/**
> + * kvm_pmu_host_counter_mask() - Compute bitmask of host-reserved counters
> + * @pmu: Pointer to arm_pmu struct
> + *
> + * Compute the bitmask that selects the host-reserved counters in the
> + * {PMCNTEN,PMINTEN,PMOVS}{SET,CLR} registers. These are the counters
> + * in HPMN..N
> + *
> + * Return: Bitmask
> + */
> +u64 kvm_pmu_host_counter_mask(struct arm_pmu *pmu)
> +{
> + u8 nr_counters = *host_data_ptr(nr_event_counters);
> +
> + if (kvm_pmu_is_partitioned(pmu))
> + return GENMASK(nr_counters - 1, pmu->max_guest_counters);
> +
> + return ARMV8_PMU_CNT_MASK_ALL;
> +}
> +
> +/**
> + * kvm_pmu_guest_counter_mask() - Compute bitmask of guest-reserved counters
> + * @pmu: Pointer to arm_pmu struct
> + *
> + * Compute the bitmask that selects the guest-reserved counters in the
> + * {PMCNTEN,PMINTEN,PMOVS}{SET,CLR} registers. These are the counters
> + * in 0..HPMN and the cycle and instruction counters.
> + *
> + * Return: Bitmask
> + */
> +u64 kvm_pmu_guest_counter_mask(struct arm_pmu *pmu)
> +{
> + if (kvm_pmu_is_partitioned(pmu))
> + return ARMV8_PMU_CNT_MASK_C | GENMASK(pmu->max_guest_counters - 1, 0);
> +
> + return 0;
> +}
> +
> +/**
> + * kvm_pmu_load() - Load untrapped PMU registers
> + * @vcpu: Pointer to struct kvm_vcpu
> + *
> + * Load all untrapped PMU registers from the VCPU into the PCPU. Mask
> + * to only bits belonging to guest-reserved counters and leave
> + * host-reserved counters alone in bitmask registers.
> + */
> +void kvm_pmu_load(struct kvm_vcpu *vcpu)
> +{
> + struct arm_pmu *pmu;
> + unsigned long guest_counters;
> + u64 mask;
> + u8 i;
> + u64 val;
> +
> + /*
> + * 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 (!kvm_vcpu_pmu_is_partitioned(vcpu))
> + return;
> +
> + preempt_disable();
> +
> + pmu = vcpu->kvm->arch.arm_pmu;
> + guest_counters = kvm_pmu_guest_counter_mask(pmu);
> +
> + for_each_set_bit(i, &guest_counters, ARMPMU_MAX_HWEVENTS) {
> + val = __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i);
> +
> + if (i == ARMV8_PMU_CYCLE_IDX) {
> + write_sysreg(val, pmccntr_el0);
> + } else {
> + write_sysreg(i, pmselr_el0);
> + write_sysreg(val, pmxevcntr_el0);
This is wrong, you would need an intervening ISB. It'd be better to
avoid the ISB altogether and just use {read,write}_pmevcntrn().
Thanks,
Oliver
^ permalink raw reply
* [PATCH v2 01/11] m68k: mcf5441x: fix clocks numbering
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Fix clocks numbering, set correct values for eport and DAC,
as per RM Rev 5, 05/2018, table 9.5.
Fixes: bea8bcb12da09 ("m68knommu: Add support for the Coldfire m5441x.")
Fixes: 007f84ede6e3e ("m68k: coldfire: remove private clk_get/clk_put")
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/coldfire/m5441x.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
index 6ce730098ff6..613b0275d9d8 100644
--- a/arch/m68k/coldfire/m5441x.c
+++ b/arch/m68k/coldfire/m5441x.c
@@ -41,9 +41,9 @@ DEFINE_CLK(0, "mcfpit.0", 32, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.1", 33, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.2", 34, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
-DEFINE_CLK(0, "mcfeport.0", 37, MCF_CLK);
-DEFINE_CLK(0, "mcfadc.0", 38, MCF_CLK);
-DEFINE_CLK(0, "mcfdac.0", 39, MCF_CLK);
+DEFINE_CLK(0, "mcfeport.0", 36, MCF_CLK);
+DEFINE_CLK(0, "mcfadc.0", 37, MCF_CLK);
+DEFINE_CLK(0, "mcfdac.0", 38, MCF_CLK);
DEFINE_CLK(0, "mcfrtc.0", 42, MCF_CLK);
DEFINE_CLK(0, "mcfsim.0", 43, MCF_CLK);
DEFINE_CLK(0, "mcfusb-otg.0", 44, MCF_CLK);
@@ -103,9 +103,9 @@ static struct clk_lookup m5411x_clk_lookup[] = {
CLKDEV_INIT("mcfpit.1", NULL, &__clk_0_33),
CLKDEV_INIT("mcfpit.2", NULL, &__clk_0_34),
CLKDEV_INIT("mcfpit.3", NULL, &__clk_0_35),
- CLKDEV_INIT("mcfeport.0", NULL, &__clk_0_37),
- CLKDEV_INIT("mcfadc.0", NULL, &__clk_0_38),
- CLKDEV_INIT("mcfdac.0", NULL, &__clk_0_39),
+ CLKDEV_INIT("mcfeport.0", NULL, &__clk_0_36),
+ CLKDEV_INIT("mcfadc.0", NULL, &__clk_0_37),
+ CLKDEV_INIT("mcfdac.0", NULL, &__clk_0_38),
CLKDEV_INIT("mcfrtc.0", NULL, &__clk_0_42),
CLKDEV_INIT("mcfsim.0", NULL, &__clk_0_43),
CLKDEV_INIT("mcfusb-otg.0", NULL, &__clk_0_44),
@@ -156,7 +156,7 @@ static struct clk * const enable_clks[] __initconst = {
&__clk_0_27, /* uart3 */
&__clk_0_33, /* pit.1 */
- &__clk_0_37, /* eport */
+ &__clk_0_36, /* eport */
&__clk_0_48, /* pll */
&__clk_0_51, /* esdhc */
@@ -174,8 +174,8 @@ static struct clk * const disable_clks[] __initconst = {
&__clk_0_32, /* pit.0 */
&__clk_0_34, /* pit.2 */
&__clk_0_35, /* pit.3 */
- &__clk_0_38, /* adc */
- &__clk_0_39, /* dac */
+ &__clk_0_37, /* adc */
+ &__clk_0_38, /* dac.0 */
&__clk_0_44, /* usb otg */
&__clk_0_45, /* usb host */
&__clk_0_47, /* ssi.0 */
--
2.54.0
^ permalink raw reply related
* [PATCH v2 11/11] iio: dac: add mcf54415 DAC
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add basic version of mcf54415 DAC driver. DAC is embedded in the cpu and
DAC configuration registers are mapped in the internal IO address space.
The DAC accepts a 12-bit digital signal and creates a monotonic 12-bit
analog output varying from DAC_VREFL to DAC_VREFH. The DAC module
consists of a conversion unit, an output amplifier, and the associated
digital control blocks. Default register values for DAC_VREFL and DAC_VREFH
are respectively 0 and 0xfff, left untouched in this initial version.
This initial version of the driver is minimalistic, "output raw" only, to
be extended in the future. DMA and external sync are disabled, default mode
is high speed, default format is right-justified 12bit on 16bit word.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v2:
- remove tests from commit message, moved to patch 0
- remove additional blank lines
- remove dead code and unused definitions
- use regmap
- add limit check on raw write
- non functional style fixes
- add COMPILE_TEST to Kconfig
---
drivers/iio/dac/Kconfig | 10 ++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/mcf54415_dac.c | 203 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 214 insertions(+)
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index cd4870b65415..85147df00aa3 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -516,6 +516,16 @@ config MAX5821
Say yes here to build support for Maxim MAX5821
10 bits DAC.
+config MCF54415_DAC
+ tristate "NXP MCF54415 DAC driver"
+ depends on M5441x || COMPILE_TEST
+ help
+ Say yes here to build support for NXP MCF54415
+ 12bit DAC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called mcf54415_dac.
+
config MCP4725
tristate "MCP4725/6 DAC driver"
depends on I2C
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 2a80bbf4e80a..1cb93e83d0eb 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_MAX517) += max517.o
obj-$(CONFIG_MAX22007) += max22007.o
obj-$(CONFIG_MAX5522) += max5522.o
obj-$(CONFIG_MAX5821) += max5821.o
+obj-$(CONFIG_MCF54415_DAC) += mcf54415_dac.o
obj-$(CONFIG_MCP4725) += mcp4725.o
obj-$(CONFIG_MCP4728) += mcp4728.o
obj-$(CONFIG_MCP47FEB02) += mcp47feb02.o
diff --git a/drivers/iio/dac/mcf54415_dac.c b/drivers/iio/dac/mcf54415_dac.c
new file mode 100644
index 000000000000..e95ab6b89b17
--- /dev/null
+++ b/drivers/iio/dac/mcf54415_dac.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * NXP mcf54415 DAC driver
+ *
+ * Copyright 2026 BayLibre - adureghello@baylibre.com
+ */
+
+#include <linux/array_size.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/compiler_types.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#include <linux/iio/iio.h>
+
+#define MCF54415_DAC_CR 0x00
+#define MCF54415_DAC_CR_PDN BIT(0)
+#define MCF54415_DAC_CR_HSLS BIT(6)
+#define MCF54415_DAC_CR_WMLVL GENMASK(9, 8)
+#define MCF54415_DAC_CR_FILT BIT(12)
+
+#define MCF54415_DAC_DATA 0x02
+
+struct mcf54415_dac {
+ struct clk *clk;
+ struct regmap *map;
+};
+
+static const struct regmap_config mcf54415_dac_regmap_config = {
+ .reg_bits = 16,
+ .reg_stride = 2,
+ .val_bits = 16,
+ .io_port = true,
+ .max_register = 0x1F,
+};
+
+static void mcf54415_dac_init(struct mcf54415_dac *info)
+{
+ /* Keeping defaults and enable DAC (bit 0 set to 0) */
+ regmap_write(info->map, MCF54415_DAC_CR, MCF54415_DAC_CR_FILT |
+ FIELD_PREP(MCF54415_DAC_CR_WMLVL, 1));
+
+ /* DAC is ready after 12us, from RM table 40-3 */
+ fsleep(12);
+}
+
+static void mcf54415_dac_exit(void *data)
+{
+ struct mcf54415_dac *info = data;
+
+ regmap_update_bits(info->map, MCF54415_DAC_CR, MCF54415_DAC_CR_PDN,
+ MCF54415_DAC_CR_PDN);
+}
+
+#define MCF54415_DAC_CHAN \
+{ \
+ .type = IIO_VOLTAGE, \
+ .output = 1, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+static const struct iio_chan_spec mcf54415_dac_iio_channels[] = {
+ MCF54415_DAC_CHAN,
+};
+
+static int mcf54415_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct mcf54415_dac *info = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ regmap_read(info->map, MCF54415_DAC_DATA, val);
+ *val &= 0xfff;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ /* Reference voltage as per ColdFire datasheet is 3.3V */
+ *val = 3300 /* mV */;
+ *val2 = 12;
+ return IIO_VAL_FRACTIONAL_LOG2;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int mcf54415_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val, int val2, long mask)
+{
+ struct mcf54415_dac *info = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ if (val < 0 || val > 4095)
+ return -EINVAL;
+ regmap_write(info->map, MCF54415_DAC_DATA, val);
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info mcf54415_dac_iio_info = {
+ .read_raw = &mcf54415_read_raw,
+ .write_raw = &mcf54415_write_raw,
+};
+
+static int mcf54415_dac_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct iio_dev *indio_dev;
+ struct mcf54415_dac *info;
+ void __iomem *regs;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*info));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ info = iio_priv(indio_dev);
+
+ regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(regs))
+ return dev_err_probe(dev, PTR_ERR(regs),
+ "failed to get io regs\n");
+
+ info->map = devm_regmap_init_mmio(dev, regs,
+ &mcf54415_dac_regmap_config);
+ if (IS_ERR(info->map))
+ return PTR_ERR(info->map);
+
+ info->clk = devm_clk_get_enabled(dev, "dac");
+ if (IS_ERR(info->clk))
+ return dev_err_probe(dev, PTR_ERR(info->clk),
+ "failed getting clock\n");
+
+ platform_set_drvdata(pdev, indio_dev);
+
+ indio_dev->name = "mcf54415";
+ indio_dev->info = &mcf54415_dac_iio_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = mcf54415_dac_iio_channels;
+ indio_dev->num_channels = ARRAY_SIZE(mcf54415_dac_iio_channels);
+
+ mcf54415_dac_init(info);
+
+ ret = devm_add_action_or_reset(dev, mcf54415_dac_exit, info);
+ if (ret)
+ return ret;
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static int mcf54415_dac_suspend(struct device *dev)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct mcf54415_dac *info = iio_priv(indio_dev);
+
+ mcf54415_dac_exit(info);
+ clk_disable_unprepare(info->clk);
+
+ return 0;
+}
+
+static int mcf54415_dac_resume(struct device *dev)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct mcf54415_dac *info = iio_priv(indio_dev);
+ int ret;
+
+ ret = clk_prepare_enable(info->clk);
+ if (ret)
+ return ret;
+
+ mcf54415_dac_init(info);
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(mcf54415_dac_pm_ops,
+ mcf54415_dac_suspend,
+ mcf54415_dac_resume);
+
+static struct platform_driver mcf54415_dac_driver = {
+ .probe = mcf54415_dac_probe,
+ .driver = {
+ .name = "mcf54415_dac",
+ .pm = pm_sleep_ptr(&mcf54415_dac_pm_ops),
+ },
+};
+module_platform_driver(mcf54415_dac_driver);
+
+MODULE_AUTHOR("Angelo Dureghello <angelo@kernel-space.org>");
+MODULE_DESCRIPTION("NXP MCF54415 DAC driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH v2 04/11] m68k: defconfig: update stmark2 defconfig
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Update stmark2 defconfig enabling MCF5441X DACs.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/configs/stmark2_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/m68k/configs/stmark2_defconfig b/arch/m68k/configs/stmark2_defconfig
index b3fb95f73a95..3941113bc60b 100644
--- a/arch/m68k/configs/stmark2_defconfig
+++ b/arch/m68k/configs/stmark2_defconfig
@@ -76,6 +76,8 @@ CONFIG_DMADEVICES=y
CONFIG_MCF_EDMA=y
# CONFIG_VIRTIO_MENU is not set
# CONFIG_VHOST_MENU is not set
+CONFIG_IIO=y
+CONFIG_MCF54415_DAC=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
--
2.54.0
^ permalink raw reply related
* [PATCH v2 10/11] m68k: stmark2: enable DACs outputs
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Enabled DAC0 and DAC1 outpus disabling shared ADC inputs on ADC3 and ADC7.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v2:
- using mcf_read16/mcf_write16
- remove unuseful comment
---
arch/m68k/coldfire/stmark2.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/m68k/coldfire/stmark2.c b/arch/m68k/coldfire/stmark2.c
index a5b36af8e70a..a82e1b286770 100644
--- a/arch/m68k/coldfire/stmark2.c
+++ b/arch/m68k/coldfire/stmark2.c
@@ -117,6 +117,8 @@ static struct platform_device *stmark2_devices[] __initdata = {
*/
static int __init init_stmark2(void)
{
+ u16 val;
+
/* DSPI0, all pins as DSPI, and using CS1 */
mcf_write8(0x80, MCFGPIO_PAR_DSPIOWL);
mcf_write8(0xfc, MCFGPIO_PAR_DSPIOWH);
@@ -129,6 +131,11 @@ static int __init init_stmark2(void)
/* CAN pads */
mcf_write8(0x50, MCFGPIO_PAR_CANI2C);
+ val = mcf_read16(MCF_CCM_MISCCR2);
+ val &= ~(MCF_CCM_MISCCR2_ADC3_EN | MCF_CCM_MISCCR2_ADC7_EN);
+ val |= MCF_CCM_MISCCR2_DAC0_SEL | MCF_CCM_MISCCR2_DAC1_SEL;
+ mcf_write16(val, MCF_CCM_MISCCR2);
+
platform_add_devices(stmark2_devices, ARRAY_SIZE(stmark2_devices));
spi_register_board_info(stmark2_board_info,
--
2.54.0
^ permalink raw reply related
* [PATCH v2 09/11] m68k: stmark2: use ioport.h macros for resources
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Align also other resource declaration using DEFINE_RES_.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/coldfire/stmark2.c | 19 ++++---------------
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/m68k/coldfire/stmark2.c b/arch/m68k/coldfire/stmark2.c
index aa2b4d2a8a64..a5b36af8e70a 100644
--- a/arch/m68k/coldfire/stmark2.c
+++ b/arch/m68k/coldfire/stmark2.c
@@ -63,21 +63,10 @@ static struct fsl_dspi_platform_data dspi_spi0_info = {
};
static struct resource dspi_spi0_resource[] = {
- [0] = {
- .start = MCFDSPI_BASE0,
- .end = MCFDSPI_BASE0 + 0xFF,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = 12,
- .end = 13,
- .flags = IORESOURCE_DMA,
- },
- [2] = {
- .start = MCF_IRQ_DSPI0,
- .end = MCF_IRQ_DSPI0,
- .flags = IORESOURCE_IRQ,
- },
+ DEFINE_RES_MEM(MCFDSPI_BASE0, 0x100),
+ DEFINE_RES_DMA(12),
+ DEFINE_RES_DMA(13),
+ DEFINE_RES_IRQ(MCF_IRQ_DSPI0),
};
static u64 stmark2_dspi_mask = DMA_BIT_MASK(32);
--
2.54.0
^ permalink raw reply related
* [PATCH v2 08/11] m68k: stmark2: add mcf5441x DAC platform devices
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add mcf5441x DAC platform devices.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v2:
- fix copy-paste error on naming
- use DEFINE_RES()
---
arch/m68k/coldfire/stmark2.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/m68k/coldfire/stmark2.c b/arch/m68k/coldfire/stmark2.c
index 9263b77bd09a..aa2b4d2a8a64 100644
--- a/arch/m68k/coldfire/stmark2.c
+++ b/arch/m68k/coldfire/stmark2.c
@@ -8,6 +8,7 @@
* for more details.
*/
+#include <linux/ioport.h>
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
#include <linux/spi/spi.h>
@@ -94,8 +95,32 @@ static struct platform_device dspi_spi0_device = {
},
};
+static struct resource dac0_resource[] = {
+ DEFINE_RES_MEM(MCFDAC_BASE0, 0x100),
+};
+
+static struct platform_device dac0_device = {
+ .name = "mcf54415_dac",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(dac0_resource),
+ .resource = dac0_resource,
+};
+
+static struct resource dac1_resource[] = {
+ DEFINE_RES_MEM(MCFDAC_BASE1, 0x100),
+};
+
+static struct platform_device dac1_device = {
+ .name = "mcf54415_dac",
+ .id = 1,
+ .num_resources = ARRAY_SIZE(dac1_resource),
+ .resource = dac1_resource,
+};
+
static struct platform_device *stmark2_devices[] __initdata = {
&dspi_spi0_device,
+ &dac0_device,
+ &dac1_device,
};
/*
--
2.54.0
^ permalink raw reply related
* [PATCH v2 05/11] m68k: add DAC modules base addresses
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add DAC controller 0 and 1 base addresses.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/include/asm/m5441xsim.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/m68k/include/asm/m5441xsim.h b/arch/m68k/include/asm/m5441xsim.h
index f48cf63bd782..f5acc962bb95 100644
--- a/arch/m68k/include/asm/m5441xsim.h
+++ b/arch/m68k/include/asm/m5441xsim.h
@@ -191,6 +191,11 @@
#define MCFEPORT_EPPAR 0xfc090000
#define MCFEPORT_EPIER 0xfc090003
#define MCFEPORT_EPFR 0xfc090006
+/*
+ * DAC Modules.
+ */
+#define MCFDAC_BASE0 0xfc098000
+#define MCFDAC_BASE1 0xfc09c000
/*
* RTC Module.
*/
--
2.54.0
^ permalink raw reply related
* [PATCH v2 07/11] m68k: mcf5441x: add CCR MISCCR2 bitfields
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add CCR MISCCR2 register bitfields.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v2:
- add "iwyu" include for BIT and GENMASK
- fix MCF_CCM_MISCCR2_PLL_MODE bitfield
---
arch/m68k/include/asm/m5441xsim.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/m68k/include/asm/m5441xsim.h b/arch/m68k/include/asm/m5441xsim.h
index 9ce2cbb05316..ea01c7753b7b 100644
--- a/arch/m68k/include/asm/m5441xsim.h
+++ b/arch/m68k/include/asm/m5441xsim.h
@@ -8,6 +8,8 @@
#ifndef m5441xsim_h
#define m5441xsim_h
+#include <linux/bits.h>
+
#define CPU_NAME "COLDFIRE(m5441x)"
#define CPU_INSTR_PER_JIFFY 2
#define MCF_BUSCLK (MCF_CLK / 2)
@@ -145,6 +147,21 @@
#define MCF_CCM_SBFCR 0xec090022
#define MCF_CCM_FNACR 0xec090024
+/* Bit definitions and macros for MCF_CCM_MISCCR2 */
+#define MCF_CCM_MISCCR2_ULPI BIT(0)
+#define MCF_CCM_MISCCR2_FB_HALF BIT(1)
+#define MCF_CCM_MISCCR2_ADC3_EN BIT(2)
+#define MCF_CCM_MISCCR2_ADC7_EN BIT(3)
+#define MCF_CCM_MISCCR2_ADC_EN BIT(4)
+#define MCF_CCM_MISCCR2_DAC0_SEL BIT(5)
+#define MCF_CCM_MISCCR2_DAC1_SEL BIT(6)
+#define MCF_CCM_MISCCR2_DCC_BYP BIT(7)
+#define MCF_CCM_MISCCR2_PLL_MODE GENMASK(10, 8)
+#define MCF_CCM_MISCCR2_SWT_SCR BIT(12)
+#define MCF_CCM_MISCCR2_RGPIO_HALF BIT(13)
+#define MCF_CCM_MISCCR2_DDR2_CLK BIT(14)
+#define MCF_CCM_MISCCR2_EXTCLK_BYP BIT(15)
+
/*
* UART module.
*/
--
2.54.0
^ permalink raw reply related
* [PATCH v2 06/11] m68k: mcf5441x: add CCM registers
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add CCM module register offsets.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/include/asm/m5441xsim.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/m68k/include/asm/m5441xsim.h b/arch/m68k/include/asm/m5441xsim.h
index f5acc962bb95..9ce2cbb05316 100644
--- a/arch/m68k/include/asm/m5441xsim.h
+++ b/arch/m68k/include/asm/m5441xsim.h
@@ -125,6 +125,26 @@
#define MCFPM_PPMHR1 0xfc040038
#define MCFPM_PPMLR1 0xfc04003c
#define MCFPM_LPCR 0xec090007
+
+/*
+ * Chip Configuration Module (CCM).
+ */
+#define MCF_CCM_CCR 0xec090004
+#define MCF_CCM_RCON 0xec090008
+#define MCF_CCM_CIR 0xec09000a
+#define MCF_CCM_MISCCR 0xec09000e
+#define MCF_CCM_CDRH 0xec090010
+#define MCF_CCM_CDRL 0xec090012
+#define MCF_CCM_UOCSR 0xec090014
+#define MCF_CCM_UHCSR 0xec090016
+#define MCF_CCM_MISCCR3 0xec090018
+#define MCF_CCM_MISCCR2 0xec09001a
+#define MCF_CCM_ADCTSR 0xec09001c
+#define MCF_CCM_DACTSR 0xec09001e
+#define MCF_CCM_SBFSR 0xec090020
+#define MCF_CCM_SBFCR 0xec090022
+#define MCF_CCM_FNACR 0xec090024
+
/*
* UART module.
*/
--
2.54.0
^ permalink raw reply related
* [PATCH v2 03/11] m68k: mcf5441x: setup DAC clock name as per driver name
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Later in this patchset, the mcf54415 DAC driver is added.
Considering some other different ColdFire cpu DACs exists, the DAC driver
is named as "mcf54415_dac", related to the mcf5441x family SoCs with
DACs (mcf54415/6/7/8).
So updating DAC clock names to bind with proper driver name.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/coldfire/m5441x.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
index 5b5e09ecf487..b724d7fc1a08 100644
--- a/arch/m68k/coldfire/m5441x.c
+++ b/arch/m68k/coldfire/m5441x.c
@@ -43,8 +43,8 @@ DEFINE_CLK(0, "mcfpit.2", 34, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
DEFINE_CLK(0, "mcfeport.0", 36, MCF_CLK);
DEFINE_CLK(0, "mcfadc.0", 37, MCF_CLK);
-DEFINE_CLK(0, "mcfdac.0", 38, MCF_CLK);
-DEFINE_CLK(0, "mcfdac.1", 39, MCF_CLK);
+DEFINE_CLK(0, "mcf54415_dac.0", 38, MCF_CLK);
+DEFINE_CLK(0, "mcf54415_dac.1", 39, MCF_CLK);
DEFINE_CLK(0, "mcfrtc.0", 42, MCF_CLK);
DEFINE_CLK(0, "mcfsim.0", 43, MCF_CLK);
DEFINE_CLK(0, "mcfusb-otg.0", 44, MCF_CLK);
@@ -106,8 +106,8 @@ static struct clk_lookup m5411x_clk_lookup[] = {
CLKDEV_INIT("mcfpit.3", NULL, &__clk_0_35),
CLKDEV_INIT("mcfeport.0", NULL, &__clk_0_36),
CLKDEV_INIT("mcfadc.0", NULL, &__clk_0_37),
- CLKDEV_INIT("mcfdac.0", NULL, &__clk_0_38),
- CLKDEV_INIT("mcfdac.1", NULL, &__clk_0_39),
+ CLKDEV_INIT("mcf54415_dac.0", NULL, &__clk_0_38),
+ CLKDEV_INIT("mcf54415_dac.1", NULL, &__clk_0_39),
CLKDEV_INIT("mcfrtc.0", NULL, &__clk_0_42),
CLKDEV_INIT("mcfsim.0", NULL, &__clk_0_43),
CLKDEV_INIT("mcfusb-otg.0", NULL, &__clk_0_44),
--
2.54.0
^ permalink raw reply related
* [PATCH v2 02/11] m68k: mcf5441x: add clock for DAC channel 1
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add missing clock for mcf5441x DAC channel 1.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/coldfire/m5441x.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
index 613b0275d9d8..5b5e09ecf487 100644
--- a/arch/m68k/coldfire/m5441x.c
+++ b/arch/m68k/coldfire/m5441x.c
@@ -44,6 +44,7 @@ DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
DEFINE_CLK(0, "mcfeport.0", 36, MCF_CLK);
DEFINE_CLK(0, "mcfadc.0", 37, MCF_CLK);
DEFINE_CLK(0, "mcfdac.0", 38, MCF_CLK);
+DEFINE_CLK(0, "mcfdac.1", 39, MCF_CLK);
DEFINE_CLK(0, "mcfrtc.0", 42, MCF_CLK);
DEFINE_CLK(0, "mcfsim.0", 43, MCF_CLK);
DEFINE_CLK(0, "mcfusb-otg.0", 44, MCF_CLK);
@@ -106,6 +107,7 @@ static struct clk_lookup m5411x_clk_lookup[] = {
CLKDEV_INIT("mcfeport.0", NULL, &__clk_0_36),
CLKDEV_INIT("mcfadc.0", NULL, &__clk_0_37),
CLKDEV_INIT("mcfdac.0", NULL, &__clk_0_38),
+ CLKDEV_INIT("mcfdac.1", NULL, &__clk_0_39),
CLKDEV_INIT("mcfrtc.0", NULL, &__clk_0_42),
CLKDEV_INIT("mcfsim.0", NULL, &__clk_0_43),
CLKDEV_INIT("mcfusb-otg.0", NULL, &__clk_0_44),
@@ -176,6 +178,7 @@ static struct clk * const disable_clks[] __initconst = {
&__clk_0_35, /* pit.3 */
&__clk_0_37, /* adc */
&__clk_0_38, /* dac.0 */
+ &__clk_0_39, /* dac.1 */
&__clk_0_44, /* usb otg */
&__clk_0_45, /* usb host */
&__clk_0_47, /* ssi.0 */
--
2.54.0
^ permalink raw reply related
* [PATCH v2 00/11] add mcf54415 DAC driver
From: Angelo Dureghello @ 2026-05-13 9:14 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
This patchset adds a minimalistic DAC driver for the NXP mcf54415/6/7/8
ibuiltin DACs.
Currently the driver enables the raw write only. Feature as dma, sync, or
format are not supoprted for this version.
Additional options suppoerted by the DAC module will be added to the driver
later on, as needed.
The same patchset prepares the m68k/coldfire architecture to support
the driver.
Below soem basic tests done on stmark2 mcf54415-based board, voltage check
on DAC0 and DAC1:
~ # cd /sys/bus/iio/devices/iio:device0/
/sys/bus/iio/devices/iio:device0 # ls
name out_voltage_scale uevent
out_voltage_raw subsystem
/sys/bus/iio/devices/iio:device0 # cat name
mcf54415
/sys/bus/iio/devices/iio:device0 # echo 4095 > out_voltage_raw
/sys/bus/iio/devices/iio:device0 # echo 2048 > out_voltage_raw
/sys/bus/iio/devices/iio:device0 # echo 4096 > out_voltage_raw
sh: write error: Invalid argument
/sys/bus/iio/devices/iio:device0 # cat out_voltage_raw
2048
/sys/bus/iio/devices/iio:device0 #
Same behavior for /sys/bus/iio/devices/iio:device1.
Generated a sine wave by shell script, sine shape is good.
Note: this patchset depends on mew mcf_read/mcf_write implementation:
Link: https://lore.kernel.org/linux-m68k/209d0653-6386-4b64-9e15-e358f84453ab@app.fastmail.com/T/#t
---
Changes in v2:
- keeping changelog in each single patch, where any
- Link to v1: https://patch.msgid.link/20260504-wip-stmark2-dac-v1-0-874c36a4910d@baylibre.com
---
Angelo Dureghello (11):
m68k: mcf5441x: fix clocks numbering
m68k: mcf5441x: add clock for DAC channel 1
m68k: mcf5441x: setup DAC clock name as per driver name
m68k: defconfig: update stmark2 defconfig
m68k: add DAC modules base addresses
m68k: mcf5441x: add CCM registers
m68k: mcf5441x: add CCR MISCCR2 bitfields
m68k: stmark2: add mcf5441x DAC platform devices
m68k: stmark2: use ioport.h macros for resources
m68k: stmark2: enable DACs outputs
iio: dac: add mcf54415 DAC
arch/m68k/coldfire/m5441x.c | 21 ++--
arch/m68k/coldfire/stmark2.c | 51 ++++++---
arch/m68k/configs/stmark2_defconfig | 2 +
arch/m68k/include/asm/m5441xsim.h | 42 ++++++++
drivers/iio/dac/Kconfig | 10 ++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/mcf54415_dac.c | 203 ++++++++++++++++++++++++++++++++++++
7 files changed, 306 insertions(+), 24 deletions(-)
---
base-commit: 25c66a1b49f3c5463ee8266a3fd5256cbc794610
change-id: 20260430-wip-stmark2-dac-7060f49dd94f
Best regards,
--
Angelo Dureghello <adureghello@baylibre.com>
^ permalink raw reply
* Re: [PATCH v2 3/5] dt-bindings: phy: rockchip,inno-usb2phy: Add compatible for RK3528
From: Diederik de Haas @ 2026-05-13 9:09 UTC (permalink / raw)
To: Heiko Stuebner, vkoul
Cc: neil.armstrong, robh, krzk+dt, conor+dt, linux-phy, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, jonas
In-Reply-To: <20260505170410.3265305-4-heiko@sntech.de>
Hi Heiko,
On Tue May 5, 2026 at 7:04 PM CEST, Heiko Stuebner wrote:
> From: Jonas Karlman <jonas@kwiboo.se>
>
> The embedded USB2 PHY on RK3528 is very similar to the one in RK3568,
> the main difference being that it only uses two clocks instead of three.
>
> Add compatible to support the USB2 PHY in RK3528.
>
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> .../bindings/phy/rockchip,inno-usb2phy.yaml | 30 ++++++++++++++++---
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
> index b95c9e3e44fe..f50fc69fbbe4 100644
> --- a/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
> @@ -20,6 +20,7 @@ properties:
> - rockchip,rk3328-usb2phy
> - rockchip,rk3366-usb2phy
> - rockchip,rk3399-usb2phy
> + - rockchip,rk3528-usb2phy
> - rockchip,rk3562-usb2phy
> - rockchip,rk3568-usb2phy
> - rockchip,rk3576-usb2phy
> @@ -41,11 +42,15 @@ properties:
> maxItems: 3
>
> clock-names:
> - minItems: 1
> - items:
> + oneOf:
> - const: phyclk
> - - const: aclk
> - - const: aclk_slv
> + - items:
> + - const: phyclk
> + - const: pclk
> + - items:
> + - const: phyclk
> + - const: aclk
> + - const: aclk_slv
>
> assigned-clocks:
> description:
> @@ -65,6 +70,9 @@ properties:
> description: Muxed interrupt for both ports
> maxItems: 1
>
> + power-domains:
> + maxItems: 1
> +
The commit message talks about (the differences in) clocks, but says
nothing about power-domains. Shouldn't that be mentioned and/or split
off into its own patch? (FWIW: I like the change itself)
Cheers,
Diederik
> resets:
> maxItems: 2
>
> @@ -150,6 +158,7 @@ allOf:
> compatible:
> contains:
> enum:
> + - rockchip,rk3528-usb2phy
> - rockchip,rk3568-usb2phy
> - rockchip,rv1108-usb2phy
> then:
> @@ -218,6 +227,19 @@ allOf:
> clock-names:
> maxItems: 1
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - rockchip,rk3528-usb2phy
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + clock-names:
> + minItems: 2
> +
> - if:
> properties:
> compatible:
^ permalink raw reply
* Re: [PATCH v5 18/29] media: rockchip: rga: check scaling factor
From: Sven Püschel @ 2026-05-13 9:09 UTC (permalink / raw)
To: Nicolas Dufresne, Jacob Chen, Ezequiel Garcia,
Mauro Carvalho Chehab, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil
Cc: linux-media, linux-rockchip, linux-arm-kernel, linux-kernel,
devicetree, kernel, sebastian.reichel
In-Reply-To: <67c2e5b74340a3a33a5e1e377e88298250a6d3c5.camel@ndufresne.ca>
Hi Nicolas,
On 5/9/26 1:11 AM, Nicolas Dufresne wrote:
> Le mardi 28 avril 2026 à 11:00 +0200, Sven Püschel a écrit :
>> Check the scaling factor to avoid potential problems. This is relevant
>> for the upcoming RGA3 support, as it can hang when the scaling factor
>> is exceeded.
>>
>> There are two relevant scenarios that have to be considered to protect
>> against invalid scaling values:
>>
>> When the output or capture is already streaming, setting the format on
>> the other side should consider the max scaling factor and clamp it
>> accordingly. This is only done in the streaming case, as it otherwise
>> may unintentionally clamp the value when the application sets the first
>> format (due to a default format on the other side).
>>
>> When the format is set on both sides first, then the format won't be
>> corrected by above means. Therefore the second streamon call has to
>> check the scaling factor and fail otherwise.
>>
>> As try functions should only be state aware if specified, the scaling
>> limitation is only done in s_fmt.
>>
>> Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
>> ---
>> drivers/media/platform/rockchip/rga/rga-hw.c | 1 +
>> drivers/media/platform/rockchip/rga/rga-hw.h | 1 +
>> drivers/media/platform/rockchip/rga/rga.c | 47 ++++++++++++++++++++++++++++
>> drivers/media/platform/rockchip/rga/rga.h | 1 +
>> 4 files changed, 50 insertions(+)
>>
>> diff --git a/drivers/media/platform/rockchip/rga/rga-hw.c b/drivers/media/platform/rockchip/rga/rga-hw.c
>> index 11079477a3008..11a1a914668f6 100644
>> --- a/drivers/media/platform/rockchip/rga/rga-hw.c
>> +++ b/drivers/media/platform/rockchip/rga/rga-hw.c
>> @@ -595,6 +595,7 @@ const struct rga_hw rga2_hw = {
>> .max_width = MAX_WIDTH,
>> .min_height = MIN_HEIGHT,
>> .max_height = MAX_HEIGHT,
>> + .max_scaling_factor = MAX_SCALING_FACTOR,
>> .stride_alignment = 4,
>>
>> .setup_cmdbuf = rga_hw_setup_cmdbuf,
>> diff --git a/drivers/media/platform/rockchip/rga/rga-hw.h b/drivers/media/platform/rockchip/rga/rga-hw.h
>> index c2e34be751939..805ec23e5e3f4 100644
>> --- a/drivers/media/platform/rockchip/rga/rga-hw.h
>> +++ b/drivers/media/platform/rockchip/rga/rga-hw.h
>> @@ -14,6 +14,7 @@
>>
>> #define MIN_WIDTH 34
>> #define MIN_HEIGHT 34
>> +#define MAX_SCALING_FACTOR 16
>>
>> #define RGA_TIMEOUT 500
>>
>> diff --git a/drivers/media/platform/rockchip/rga/rga.c b/drivers/media/platform/rockchip/rga/rga.c
>> index d111b348255e2..75d05c86b1c00 100644
>> --- a/drivers/media/platform/rockchip/rga/rga.c
>> +++ b/drivers/media/platform/rockchip/rga/rga.c
>> @@ -405,10 +405,36 @@ static int vidioc_s_fmt(struct file *file, void *priv, struct v4l2_format *f)
>> struct v4l2_pix_format_mplane *pix_fmt = &f->fmt.pix_mp;
>> struct rga_ctx *ctx = file_to_rga_ctx(file);
>> struct rockchip_rga *rga = ctx->rga;
>> + const struct rga_hw *hw = rga->hw;
>> struct vb2_queue *vq;
>> struct rga_frame *frm;
>> int ret = 0;
>> int i;
>> + struct rga_frame *limit_frm = NULL;
>> +
>> + /* Limit before try_fmt to avoid recalculating the stride */
>> + if (V4L2_TYPE_IS_OUTPUT(f->type) &&
>> + v4l2_m2m_get_dst_vq(ctx->fh.m2m_ctx)->streaming)
>> + limit_frm = &ctx->out;
> If you need to, use helpers such as vb2_is_streaming(), though in this case, I
> think you want to use vb2_is_busy(), which protects against changing the format
> of a queue that is already allocated. This is needed because drivers, except vp9
> and av1 stateless decoders, don't track the format per buffer.
>
>> + if (V4L2_TYPE_IS_CAPTURE(f->type) &&
>> + v4l2_m2m_get_src_vq(ctx->fh.m2m_ctx)->streaming)
> Same.
>
>> + limit_frm = &ctx->in;
>> + if (limit_frm) {
>> + const struct v4l2_frmsize_stepwise frmsize = {
>> + .min_width = DIV_ROUND_UP(limit_frm->pix.width,
>> + hw->max_scaling_factor),
>> + .max_width =
>> + limit_frm->pix.width * hw->max_scaling_factor,
> Shouldn't you control the absolute min/max for this IP ?
That is done later in try_fmt. This is separately done in s_fmt to avoid
making try_fmt stateful. I'll add a comment to make it more clear that
this is only for the theoretical scaling limits.
>
>> + .min_height = DIV_ROUND_UP(limit_frm->pix.height,
>> + hw->max_scaling_factor),
>> + .max_height =
>> + limit_frm->pix.height * hw->max_scaling_factor,
>> + .step_width = 1,
>> + .step_height = 1,
> Shouldn't that step match the subsampling like you did earlier ?
same as above.
Sincerely
Sven
>
> Nicolas
>
>> + };
>> + v4l2_apply_frmsize_constraints(&pix_fmt->width,
>> + &pix_fmt->height, &frmsize);
>> + }
>>
>> /* Adjust all values accordingly to the hardware capabilities
>> * and chosen format.
>> @@ -568,12 +594,33 @@ static int vidioc_s_selection(struct file *file, void *priv,
>> return ret;
>> }
>>
>> +static bool check_scaling(const struct rga_hw *hw, u32 src_size, u32 dst_size)
>> +{
>> + if (src_size < dst_size)
>> + return src_size * hw->max_scaling_factor >= dst_size;
>> + else
>> + return dst_size * hw->max_scaling_factor >= src_size;
>> +}
>> +
>> static int vidioc_streamon(struct file *file, void *priv,
>> enum v4l2_buf_type type)
>> {
>> struct rga_ctx *ctx = file_to_rga_ctx(file);
>> const struct rga_hw *hw = ctx->rga->hw;
>>
>> + if ((V4L2_TYPE_IS_OUTPUT(type) &&
>> + v4l2_m2m_get_dst_vq(ctx->fh.m2m_ctx)->streaming) ||
>> + (V4L2_TYPE_IS_CAPTURE(type) &&
>> + v4l2_m2m_get_src_vq(ctx->fh.m2m_ctx)->streaming)) {
>> + /*
>> + * As the other side is already streaming,
>> + * check that the max scaling factor isn't exceeded.
>> + */
>> + if (!check_scaling(hw, ctx->in.pix.width, ctx->out.pix.width) ||
>> + !check_scaling(hw, ctx->in.pix.height, ctx->out.pix.height))
>> + return -EINVAL;
>> + }
>> +
>> hw->setup_cmdbuf(ctx);
>>
>> return v4l2_m2m_streamon(file, ctx->fh.m2m_ctx, type);
>> diff --git a/drivers/media/platform/rockchip/rga/rga.h b/drivers/media/platform/rockchip/rga/rga.h
>> index c741213710b32..454af283b1694 100644
>> --- a/drivers/media/platform/rockchip/rga/rga.h
>> +++ b/drivers/media/platform/rockchip/rga/rga.h
>> @@ -150,6 +150,7 @@ struct rga_hw {
>> size_t cmdbuf_size;
>> u32 min_width, min_height;
>> u32 max_width, max_height;
>> + u8 max_scaling_factor;
>> u8 stride_alignment;
>>
>> void (*setup_cmdbuf)(struct rga_ctx *ctx);
^ permalink raw reply
* [PATCH] clk: scpi: pass child node to of_clk_del_provider() in remove
From: Stepan Ionichev @ 2026-05-13 9:09 UTC (permalink / raw)
To: sudeep.holla
Cc: cristian.marussi, mturquette, sboyd, arm-scmi, linux-arm-kernel,
linux-clk, linux-kernel, sozdayvek
scpi_clocks_remove() iterates over the SCPI clock provider's child
device nodes, but passes the parent node to of_clk_del_provider()
on every iteration:
for_each_available_child_of_node(np, child)
of_clk_del_provider(np);
Providers are registered per-child in scpi_clk_add() (via
of_clk_add_hw_provider(np, ...) where the np argument is the
child node passed in from probe). of_clk_del_provider() looks up
the entry by node equality, so a call with the parent never
matches and silently does nothing.
This leaks the struct of_clk_provider allocations and the
of_node_get() references the helper takes for every registered
child, both on module unload and on the probe error path
(scpi_clk_add() failure for child N leaves children 0..N-1
registered).
Pass child to of_clk_del_provider() instead, matching the
pattern used by clk-stm32mp1.c:2350-2351.
Fixes: cd52c2a4b5c4 ("clk: add support for clocks provided by SCP(System Control Processor)")
Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
---
drivers/clk/clk-scpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-scpi.c b/drivers/clk/clk-scpi.c
index 7806569cd..24cee7c9f 100644
--- a/drivers/clk/clk-scpi.c
+++ b/drivers/clk/clk-scpi.c
@@ -258,7 +258,7 @@ static void scpi_clocks_remove(struct platform_device *pdev)
}
for_each_available_child_of_node(np, child)
- of_clk_del_provider(np);
+ of_clk_del_provider(child);
}
static int scpi_clocks_probe(struct platform_device *pdev)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 02/13] driver core: Enable suppliers to implement fine grained sync_state support
From: Ulf Hansson @ 2026-05-13 9:04 UTC (permalink / raw)
To: Saravana Kannan
Cc: Danilo Krummrich, Rafael J . Wysocki, Greg Kroah-Hartman,
driver-core, linux-pm, Sudeep Holla, Cristian Marussi,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Geert Uytterhoeven,
Dmitry Baryshkov, linux-arm-kernel, linux-kernel
In-Reply-To: <CACRMN=dZFvbXjZGqTvFdNVyXfyvS6YtWNKQnej9A1jihGJHcqA@mail.gmail.com>
On Wed, 13 May 2026 at 07:01, Saravana Kannan <saravanak@kernel.org> wrote:
>
> On Mon, May 11, 2026 at 2:43 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Mon, 11 May 2026 at 07:09, Saravana Kannan <saravanak@kernel.org> wrote:
> > >
> > > On Fri, May 8, 2026 at 5:39 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > >
> > > > The common sync_state support isn't fine grained enough for some types of
> > > > suppliers, like power domains for example. Especially when a supplier
> > > > provides multiple independent power domains, each with their own set of
> > > > consumers. In these cases we need to wait for all consumers for all the
> > > > provided power domains before invoking the supplier's ->sync_state().
> > > >
> > > > To allow a more fine grained sync_state support to be implemented on per
> > > > supplier's driver basis, let's add a new optional callback. As soon as
> > > > there is an update worth to consider in regards to managing sync_state for
> > > > a supplier device, __device_links_queue_sync_state() queues the device in a
> > > > list, allowing the new callback to be invoked when flushing the list in
> > > > device_links_flush_sync_list().
> > > >
> > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > > > ---
> > > >
> > > > Changes in v3:
> > > > - Re-worked the approach to use a list to queue/flush devices for
> > > > ->queue_sync_state(). This should make sure the device lock is being
> > > > held when it's needed, as pointed out by Danilo.
> > > >
> > >
> > > Hi Ulf,
> > >
> > > Thanks for working on this!
> > >
> > > And please bear with my slow replies.
> >
> > I will try, but taking more than 2 months to reply isn't sustainable,
> > I think. Let's hope you can get some more bandwidth for reviews when
> > moving forward.
> >
> > >
> > > > ---
> > > > drivers/base/base.h | 18 ++++++++
> > > > drivers/base/core.c | 77 ++++++++++++++++++++++++++---------
> > > > drivers/base/driver.c | 7 ++++
> > > > include/linux/device.h | 2 +
> > > > include/linux/device/driver.h | 7 ++++
> > > > 5 files changed, 91 insertions(+), 20 deletions(-)
> > > >
> > > > diff --git a/drivers/base/base.h b/drivers/base/base.h
> > > > index 30b416588617..c8be24af92c3 100644
> > > > --- a/drivers/base/base.h
> > > > +++ b/drivers/base/base.h
> > > > @@ -196,6 +196,24 @@ static inline void dev_sync_state(struct device *dev)
> > > > dev->driver->sync_state(dev);
> > > > }
> > > >
> > > > +static inline bool dev_has_queue_sync_state(struct device *dev)
> > >
> > > Let's please pick a better name. This is too similar to the actual
> > > queue function you call __device_links_queue_sync_state() and is very
> > > confusing. Maybe something that has a meaning along the lines of
> > > "another consumer probed". So, maybe:
> > > * consumer_probed()
> > > * change_of_active_consumers()
> >
> > The whole point of naming it "queue_sync_state" was exactly to refer
> > to __device_links_queue_sync_state(). The point is, the callback can't
> > be invoked unless __device_links_queue_sync_state() has been called
> > for the device first.
> >
> > Not sure why you think that is confusing? To me, that is rather the
> > opposite. :-)
>
>
> sync_state() is a callback telling the driver that it's okay to sync
> the state of the hardware with the software.
>
> queue_sync_state() means nothing to the driver. It's just leaking an
> internal implementation detail (name of the internal function) to the
> driver that's not really relevant. What you are really telling the
> driver is that some additional consumers have probed.
>
> > Before deciding on another name, note also that
> > __device_links_queue_sync_state() is called when resuming sync_state
> > from device_links_supplier_sync_state_resume() and from
> > device_links_driver_bound(). I am not sure "consumer_probed" a good
> > name that covers both of these cases; what do you think?
>
> Yes, I'm well aware of that :) The contract of sync_state() is that
> it'll come after a point where it's safe to sync the state. Not "as
> soon as it's safe" -- meaning no timing guarantee. Really, this is
> just to make sure sync_state() doesn't come before late initcalls
> (because a lot of frameworks make assumptions around it) are done and
> before all the top level devices are added.
>
> So, even today, sync_state() can come a bit late. In general, the
> driver framework doesn't guarantee immediate action. There is no
> guarantee that a drive probe will be called as soon as it's registered
> (if there is a device) and vice versa. The same will be true for a
> "consumer_probed()" callback too.
>
> Also, your implementation is literally trying to check which consumers
> have probed and which ones haven't. So something like
> "consumer_probed()" or "consumer_change()" should work well and is
> actually meaningful for a driver developer.
I have no strong opinion on the name, so if you prefer
"consumer_probed|changed", let me just pick one of them then.
[...]
Kind regards
Uffe
^ permalink raw reply
* [PATCH v5 04/10] arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
From: Damon Ding @ 2026-05-13 7:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260513074414.2053435-1-damon.ding@rock-chips.com>
Add the required HCLK_VO1 bus clock to RK3588 eDP1 node with
corresponding clock-name "hclk". This clock is necessary for
the eDP controller to access video output GRF and work properly.
Previously the clock was enabled implicitly via GRF phandle
reference. Add it explicitly now to align with updated binding.
Fixes: a481bb0b1ad9 ("arm64: dts: rockchip: Add eDP1 dt node for rk3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
index a2640014ee04..b251bb129cdb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
@@ -285,8 +285,8 @@ hdmi1_out: port@1 {
edp1: edp@fded0000 {
compatible = "rockchip,rk3588-edp";
reg = <0x0 0xfded0000 0x0 0x1000>;
- clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>;
- clock-names = "dp", "pclk";
+ clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>, <&cru HCLK_VO1>;
+ clock-names = "dp", "pclk", "hclk";
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH 0>;
phys = <&hdptxphy1>;
phy-names = "dp";
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox