* Re: [PATCH v4 0/2] Bluetooth: btmtksdio: teardown fixes
From: Sergey Senozhatsky @ 2026-06-24 5:19 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Sean Wang
Cc: Tomasz Figa, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, Sergey Senozhatsky
In-Reply-To: <20260618031338.1011410-1-senozhatsky@chromium.org>
On (26/06/18 12:13), Sergey Senozhatsky wrote:
> This fixes several teardown issues:
>
> INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
> __cancel_work_timer+0x3f4/0x460
> cancel_work_sync+0x1c/0x2c
> btmtksdio_flush+0x2c/0x40
> hci_dev_open_sync+0x10c4/0x2190
> [..]
>
> close/flush can deadlock when run concurrently with btmtksdio_txrx_work().
> In addition btmtksdio_txrx_work() re-enables interrupts regardless of
> close/flush being executed on another CPU.
>
> v3 -> v4:
> - fix commit message linter warnings/errors (tabs, subject line over 80
> chars).
>
> Sergey Senozhatsky (2):
> Bluetooth: btmtksdio: test for BUS IO errors in btmtksdio_txrx_work()
> Bluetooth: btmtksdio: call cancel_work_sync() out of host lock scope
Do the patches look good enough to pick up?
^ permalink raw reply
* Re: [RFC PATCH 1/6] media: mc: Implement shared media graph
From: Paul Elder @ 2026-06-24 4:47 UTC (permalink / raw)
To: laurent.pinchart
Cc: michael.riesch, xuhf, stefan.klug, kieran.bingham, dan.scally,
jacopo.mondi, linux-media, linux-arm-kernel, linux-rockchip,
linux-kernel, hverkuil+cisco, nicolas.dufresne, ribalda,
sakari.ailus
In-Reply-To: <20260619052637.1110672-2-paul.elder@ideasonboard.com>
Hi me,
You have a typo...
Quoting Paul Elder (2026-06-19 14:26:28)
> Currently, a media graph contains a main device whose driver is
> responsible for creating the media device. We have however recently run
> into devices that have multiple devices that can quality as a main
> device. Examples are the RK3588 which has a VICAP and two ISP
> instances, and another example is the i.MX8MP which has an ISI and two
> ISP instances. As there is currently no way to reconcile who the main
> device is in the media device, these setups simple cannot be used
> simultaneously.
>
> This patch extends the media controller API with a "shared media graph"
> framework. This allows drivers to share a media device, thus enabling
> the setups mentioned above. Instead of owning and creating a media
> device, drivers can join-or-create a shared media device via the shared
> media graph API. The matching is done automatically based on the
> detected endpoints in the device tree.
>
> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> ---
> drivers/media/mc/Makefile | 2 +-
> drivers/media/mc/mc-shared-graph.c | 335 +++++++++++++++++++++++++++++
> include/media/mc-shared-graph.h | 92 ++++++++
> 3 files changed, 428 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/mc/mc-shared-graph.c
> create mode 100644 include/media/mc-shared-graph.h
>
> diff --git a/drivers/media/mc/Makefile b/drivers/media/mc/Makefile
> index 2b7af42ba59c..1d502fdc52ad 100644
> --- a/drivers/media/mc/Makefile
> +++ b/drivers/media/mc/Makefile
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
>
> mc-objs := mc-device.o mc-devnode.o mc-entity.o \
> - mc-request.o
> + mc-request.o mc-shared-graph.o
>
> ifneq ($(CONFIG_USB),)
> mc-objs += mc-dev-allocator.o
> diff --git a/drivers/media/mc/mc-shared-graph.c b/drivers/media/mc/mc-shared-graph.c
> new file mode 100644
> index 000000000000..c4067e5b861d
> --- /dev/null
> +++ b/drivers/media/mc/mc-shared-graph.c
> @@ -0,0 +1,335 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * mc-shared-graph.c - Media Controller Shared Graph API
> + *
> + * Copyright (c) 2026 Paul Elder <paul.elder@ideasonboard.com>
> + */
> +
> +/*
> + * This file adds the Media Controller Shared Graph API. This allows drivers
> + * to create shared media graphs or join existing media graphs from other
> + * drivers, so that they can all be in the same media graph. This allows us to
> + * have more complex media graphs chaining more complex hardware together,
> + * instead of simple async subdevs.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/fwnode.h>
> +#include <linux/kref.h>
> +#include <linux/property.h>
> +
> +#include <media/media-device.h>
> +
> +#include <media/mc-shared-graph.h>
> +
> +static LIST_HEAD(media_device_shared_list);
> +static DEFINE_MUTEX(media_device_shared_lock);
> +
> +struct media_device_shared_member {
> + struct device *dev;
> + struct fwnode_handle *fwnode;
> + struct list_head list;
> +};
> +
> +struct media_device_shared_link {
> + struct media_entity *source;
> + u16 source_pad;
> + struct media_entity *sink;
> + u16 sink_pad;
> + u32 flags;
> + struct list_head list;
> +};
> +
> +// TODO figure out locking for when multiple drivers touch the media graph;
> +// maybe macros for shared versions?
> +struct media_device_shared {
> + struct media_device mdev;
> + struct list_head members;
> + struct list_head links;
> +
> + struct list_head list;
> + struct kref refcount;
> +
> + struct device *removed_device;
> +};
> +
> +static inline struct media_device_shared *
> +to_media_device_shared(struct media_device *mdev)
> +{
> + return container_of(mdev, struct media_device_shared, mdev);
> +}
> +
> +static void media_device_shared_release(struct kref *kref)
> +{
> + struct media_device_shared *mds =
> + container_of(kref, struct media_device_shared, refcount);
> +
> + dev_dbg(mds->removed_device, "%s: releasing Media Device\n", __func__);
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + media_device_unregister(&mds->mdev);
> + media_device_cleanup(&mds->mdev);
> +
> + list_del(&mds->list);
> + mutex_unlock(&media_device_shared_lock);
> +
> + kfree(mds);
> +}
> +
> +/* Callers should hold media_device_shared_lock when calling this function */
> +static bool __media_device_shared_find_match(struct media_device_shared *mds,
> + struct fwnode_handle *fwnode)
> +{
> + struct media_device_shared_member *member;
> + struct fwnode_handle *ep;
> + struct fwnode_handle *remote_ep;
> + bool match = false;
> +
> + // TODO: parse the device tree endpoints graph instead of finding just the
> + // first-level neighbours
> + fwnode_graph_for_each_endpoint(fwnode, ep) {
> + list_for_each_entry(member, &mds->members, list) {
> + remote_ep = fwnode_graph_get_remote_port_parent(ep);
> + match = (member->fwnode == remote_ep);
> + fwnode_handle_put(remote_ep);
> +
> + if (!match)
> + continue;
> +
> + goto match_complete;
> + }
> + }
> +
> +match_complete:
> + fwnode_handle_put(ep);
> + return match;
> +}
> +
> +/* Callers should hold media_device_shared_lock when calling this function */
> +static struct media_device *__media_device_shared_get(struct device *dev)
> +{
> + struct media_device_shared *mds;
> + struct media_device_shared_member *member;
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> + bool ret;
> +
> + dev_dbg(dev, "%s: searching for media device for %pfwf", __func__, fwnode);
> +
> + list_for_each_entry(mds, &media_device_shared_list, list) {
> + ret = __media_device_shared_find_match(mds, fwnode);
> + if (ret)
> + break;
> + }
> +
> + if (!ret)
> + return NULL;
> +
> + member = kzalloc_obj(*member);
> + if (!member)
> + return NULL;
> +
> + member->dev = dev;
> + member->fwnode = fwnode;
> + list_add_tail(&member->list, &mds->members);
> + kref_get(&mds->refcount);
> +
> + dev_dbg(dev, "%s: %pfwf joined media device of %pfwf",
> + __func__, fwnode,
> + list_first_entry(&mds->members, struct media_device_shared_member, list)->fwnode);
> +
> + return &mds->mdev;
> +}
> +
> +/* Callers should hold media_device_shared_lock when calling this function */
> +static struct media_device *__media_device_shared_create(struct device *dev)
> +{
> + struct media_device_shared *mds;
> + struct media_device_shared_member *member;
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> + int ret;
> +
> + mds = kzalloc_obj(*mds);
> + if (!mds)
> + return NULL;
> +
> + member = kzalloc_obj(*member);
> + if (!member)
> + goto err_free_mds;
> +
> + media_device_init(&mds->mdev);
> +
> + ret = media_device_register(&mds->mdev);
> + if (ret)
> + goto err_free_member;
> +
> + INIT_LIST_HEAD(&mds->members);
> + member->dev = dev;
> + member->fwnode = fwnode;
> + list_add_tail(&member->list, &mds->members);
> +
> + INIT_LIST_HEAD(&mds->links);
> +
> + kref_init(&mds->refcount);
> + list_add_tail(&mds->list, &media_device_shared_list);
> +
> + // TODO figure out how to reconcile this with multiple members
> + mds->mdev.dev = dev;
> +
> + devv_dbg(dev, "%s: Allocated media device with %pfwf at %p\n",
here:
s/devv/dev/
Paul
> + __func__, fwnode, &mds->mdev);
> + return &mds->mdev;
> +
> +err_free_member:
> + kfree(member);
> +err_free_mds:
> + kfree(mds);
> + return NULL;
> +}
> +
> +// TODO figure out how to resolve the identifiers (model, driver name, etc);
> +// atm it's racy and whoever gets it last wins
> +struct media_device *media_device_shared_join(struct device *dev)
> +{
> + struct media_device *mdev;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + mdev = __media_device_shared_get(dev);
> + if (!!mdev) {
> + dev_dbg(dev, "%s: found media device for %pfwf", __func__, dev_fwnode(dev));
> + mutex_unlock(&media_device_shared_lock);
> + return mdev;
> + }
> +
> + mdev = __media_device_shared_create(dev);
> + if (!mdev) {
> + dev_warn(dev, "%s: failed to create media device for %pfwf", __func__, dev_fwnode(dev));
> + mutex_unlock(&media_device_shared_lock);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + dev_dbg(dev, "%s: created media device for %pfwf", __func__, dev_fwnode(dev));
> + mutex_unlock(&media_device_shared_lock);
> + return mdev;
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_join);
> +
> +void media_device_shared_leave(struct media_device *mdev, struct device *dev)
> +{
> + struct media_device_shared *mds = to_media_device_shared(mdev);
> + struct media_device_shared_member *member;
> + struct media_device_shared_member *member_tmp;
> + bool removed = false;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + list_for_each_entry_safe(member, member_tmp, &mds->members, list) {
> + if (member->dev == dev) {
> + list_del(&member->list);
> + kfree(member);
> + removed = true;
> + }
> + }
> +
> + if (!removed)
> + dev_err(dev, "%s: %pfwf trying to leave from graph in which not a member",
> + __func__, dev_fwnode(dev));
> +
> + mds->removed_device = dev;
> + mutex_unlock(&media_device_shared_lock);
> + kref_put(&mds->refcount, media_device_shared_release);
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_leave);
> +
> +int media_device_shared_join_link_source(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *source,
> + u16 source_pad, u32 flags)
> +{
> + struct media_device_shared *mds = to_media_device_shared(mdev);
> + struct media_device_shared_link *link;
> + struct media_device_shared_link *link_tmp;
> + int ret = 0;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + /*
> + * TODO Figure out flags. Should we use greatest common denominator? Or
> + * prioritize sink? Or whoever wins the race? For now we just take the flags
> + * from the sink.
> + *
> + * TODO Figure out how to actually do the matching. For now we just match
> + * whoever comes in first. This works with the simple example we're running
> + * with now (rkcif + one rkisp2) but with setups with multiple copies of
> + * hardware this will cause problems, like with rkcif + two rkisp2 and
> + * imx8-isi + two rkisp1.
> + */
> + list_for_each_entry_safe(link, link_tmp, &mds->links, list) {
> + if (link->sink) {
> + ret = media_create_pad_link(source, source_pad,
> + link->sink, link->sink_pad,
> + link->flags);
> + list_del(&link->list);
> + kfree(link);
> + goto exit_join_link_source;
> + }
> + }
> +
> + link = kzalloc_obj(*link);
> + if (!link) {
> + ret = -ENOMEM;
> + goto exit_join_link_source;
> + }
> +
> + link->source = source;
> + link->source_pad = source_pad;
> + link->flags = flags;
> + list_add_tail(&link->list, &mds->links);
> +
> +exit_join_link_source:
> + mutex_unlock(&media_device_shared_lock);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_join_link_source);
> +
> +// TODO deduplicate from above
> +int media_device_shared_join_link_sink(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *sink,
> + u16 sink_pad, u32 flags)
> +{
> + struct media_device_shared *mds = to_media_device_shared(mdev);
> + struct media_device_shared_link *link;
> + struct media_device_shared_link *link_tmp;
> + int ret = 0;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + list_for_each_entry_safe(link, link_tmp, &mds->links, list) {
> + if (link->source) {
> + ret = media_create_pad_link(link->source, link->source_pad,
> + sink, sink_pad,
> + flags);
> + list_del(&link->list);
> + kfree(link);
> + goto exit_join_link_sink;
> + }
> + }
> +
> + link = kzalloc_obj(*link);
> + if (!link) {
> + ret = -ENOMEM;
> + goto exit_join_link_sink;
> + }
> +
> + link->sink = sink;
> + link->sink_pad = sink_pad;
> + link->flags = flags;
> + list_add_tail(&link->list, &mds->links);
> +
> +exit_join_link_sink:
> + mutex_unlock(&media_device_shared_lock);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_join_link_sink);
> diff --git a/include/media/mc-shared-graph.h b/include/media/mc-shared-graph.h
> new file mode 100644
> index 000000000000..487325163f84
> --- /dev/null
> +++ b/include/media/mc-shared-graph.h
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * mc-shared-graph.h - Media Controller Shared Graph API
> + *
> + * Copyright (c) 2026 Paul Elder <paul.elder@ideasonboard.com>
> + */
> +
> +/*
> + * This file adds the Media Controller Shared Graph API. This allows drivers
> + * to create shared media graphs or join existing media graphs from other
> + * drivers, so that they can all be in the same media graph. This allows us to
> + * have more complex media graphs chaining more complex hardware together,
> + * instead of simple async subdevs.
> + */
> +
> +#include <linux/types.h>
> +
> +#ifndef _MEDIA_SHARED_GRAPH_H
> +#define _MEDIA_SHARED_GRAPH_H
> +
> +struct device;
> +struct media_device;
> +struct media_entity;
> +
> +#if defined(CONFIG_MEDIA_CONTROLLER)
> +/**
> + * media_device_shared_join() - Join or create a new shared media device
> + *
> + * @dev: struct &device pointer
> + *
> + * This is the entrance function for a device to join or create a new shared
> + * media device. It searches for an existing shared media device based on the
> + * neighbours in the device's device tree ports node. If found, then this
> + * functions returns the existing shared media device and joins it. If one is
> + * not found then one is created and initialized and returned.
> + */
> +struct media_device *media_device_shared_join(struct device *dev);
> +
> +/**
> + * media_device_shared_leave() - Leave the shared media device.
> + *
> + * @mdev: struct &media_device pointer
> + * @dev: struct &device pointer
> + *
> + * This function makes the device leave the shared media device. When all
> + * members have left the media device it will be freed.
> + */
> +void media_device_shared_leave(struct media_device *mdev, struct device *dev);
> +
> +/**
> + * media_device_shared_join_link_source() - Register a link source in the shared media device
> + *
> + * @mdev: The struct &media_device pointer that is part of a shared media device
> + * @dev: struct &device pointer
> + * @source: The link source
> + * @source_pad: The pad
> + * @flags: The flags
> + *
> + * This function registers with the shared media device the source part of a
> + * link. When the shared media device receives the matching sink part of a link
> + * via media_device_shared_join_link_sink() then the link will be fully created.
> + */
> +int media_device_shared_join_link_source(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *source,
> + u16 source_pad, u32 flags);
> +
> +/**
> + * media_device_shared_join_link_sink() - Register a link sink in the shared media device
> + *
> + * Same as media_device_shared_join_link_source() but for sink instead of
> + * source.
> + */
> +int media_device_shared_join_link_sink(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *sink,
> + u16 sink_pad, u32 flags);
> +#else
> +static inline struct media_device *media_device_shared_join(struct device *dev)
> +{ return NULL; }
> +static inline void media_device_shared_leave(struct media_device *mdev,
> + struct device *dev) { }
> +static inline int media_device_shared_join_link_source(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *source,
> + u16 source_pad, u32 flags) { }
> +static inline int media_device_shared_join_link_sink(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *sink,
> + u16 sink_pad, u32 flags) { }
> +#endif /* CONFIG_MEDIA_CONTROLLER */
> +#endif /* _MEDIA_DEV_SHARED_GRAPH_H */
> --
> 2.47.2
>
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Dev Jain @ 2026-06-24 4:14 UTC (permalink / raw)
To: Catalin Marinas
Cc: Harry Yoo, ryabinin.a.a, akpm, corbet, glider, andreyknvl,
dvyukov, vincenzo.frascino, kasan-dev, linux-mm, linux-kernel,
skhan, workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <ajq-Ukmd9NBruhr5@arm.com>
On 23/06/26 10:41 pm, Catalin Marinas wrote:
> On Tue, Jun 23, 2026 at 10:32:16AM +0530, Dev Jain wrote:
>> On 22/06/26 10:43 pm, Catalin Marinas wrote:
>>> On Mon, Jun 22, 2026 at 09:42:10PM +0900, Harry Yoo wrote:
>>>> On 6/19/26 10:19 PM, Catalin Marinas wrote:
>>>>> On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
>>>>>> On 6/12/26 1:44 PM, Dev Jain wrote:
>>>>>>> Now, when a memory object will be freed, it will retain the random tag it
>>>>>>> had at allocation time. This compromises on catching UAF bugs, till the
>>>>>>> time the object is not reallocated, at which point it will have a new
>>>>>>> random tag.
>>>>>>>
>>>>>>> Hence, not catching "use-after-free-before-reallocation" and not catching
>>>>>>> "double-free" will be the compromise for reduced KASAN overhead.
>>>>>>
>>>>>> I doubt users who care about security enough to enable HW_TAGS KASAN
>>>>>> are willing to compromise on security just to save a few instructions
>>>>>> to store tags in the free path.
>>>>>>
>>>>>> To me, it looks like too much of a compromise on security for little
>>>>>> performance gain.
>>>>>
>>>>> I don't think there's much compromise on security for use-after-free.
>>>>
>>>> I think it depends... OH, WAIT! I see what you mean.
>>>>
>>>> You mean use-after-free before reallocation does not lead to much
>>>> compromise on security because objects are initialized after allocation?
>>>>
>>>> You're probably right.
>>>>
>>>> Hmm, but stores to e.g.) free pointer, fields initialized by
>>>> constructor or accessed by SLAB_TYPESAFE_BY_RCU semantics after free
>>>> will be undiscovered if they happen before reallocation.
>>>
>>> Even with SLAB_TYPESAFE_BY_RCU, the object isn't tagged on free either
>>> (or realloc, only if the actual slab page ends up freed). But we don't
>>> get type confusion for such slab.
>>>
>>> However, without tagging on free, one could argue that it reduces
>>> security for cases where the page is re-allocated as untagged - e.g. all
>>> user pages mapped without PROT_MTE. Currently we have a deterministic
>>> tag check fault if the page is coloured as KASAN_TAG_INVALID. I think
>>
>> So you are saying that a stale kernel pointer can continue to use the
>> reallocated page, because for non-PROT_MTE case the page does not get
>> a new tag. Makes sense.
>
> Yes.
>
>>> for this patch, it might be better to only do such skip on free in
>>> kasan_poison_slab() rather than kasan_poison(). Freed pages would then
>>> be tagged.
>>
>> I think you mean to say, "skip tag on free when freeing pages into buddy"?
>
> No, I meant always poison via kasan_poison_pages(), as we currently do
> with KASAN_PAGE_FREE being set.
>
>> So that would mean, kasan_poison() will do the poisoning also in the
>> case of value == KASAN_PAGE_FREE.
Yeah sorry I wrote two contradictory things above, that's what I meant too.
>>
>>> An alternative would be tagging on free only with a new tag and skipping
>>> it on re-alloc. But we'd need to track when it's a completely new
>>> allocation or a reused object (I haven't looked I'm pretty sure it's
>>> doable).
>>
>> That was our original approach, and IIRC we had concluded there was no
>> security compromise. However it is difficult to implement - it has cases
>> like, what happens when two differently tagged pages are coalesced by
>> buddy and someone gets that large page as an allocation.
>
> Yeah, it's fairly complex.
>
> I think the more problematic case is when we can't detect
> use-after-reallocation and this happens when a page is reused untagged
> (probabilistically, also when the page is reused with the old tag). As
> an optimisation, it might be sufficient to skip poisoning when freeing
> an object into the slab but keep the poisoning when freeing a slab page
> into the buddy allocator. That's where the page may end up in a place
> untagged.
>
> Also for your optimisation to only tag on reallocation, do you have any
> code to read the current tag and avoid reusing it? That's useful for
> kmalloc caches or other merged kmem caches where we can have type
> confusion.
I don't have it, but should be fairly simple I guess. I just wanted to
keep it simple for now.
Anyhow someone needs to first test the current patchset to get some
numbers, we would be wasting time on this if no one gets an improvement.
>
^ permalink raw reply
* Re: [PATCH] Input: mtk-pmic-keys: Count available keys during probe instead of pre-counting
From: Dmitry Torokhov @ 2026-06-24 4:14 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-input, Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <20260528235600.312045-1-rosenp@gmail.com>
Hi Rosen,
On Thu, May 28, 2026 at 04:56:00PM -0700, Rosen Penev wrote:
> Replace the separate of_get_available_child_count() pre-count and
> validation step with a single pass through for_each_child_of_node_scoped().
> Skip unavailable child nodes and bail out if more than
> MTK_PMIC_MAX_KEY_COUNT available keys are found. Set nkeys after the
> loop so suspend/resume iterate only over initialized entries.
>
> Also use a key variable in the loop for clarity.
>
> Use of_device_get_match_data() to fetch the PMIC key register data directly
> instead of open-coding an of_match_device() lookup.
Please split this out into a separate patch.
>
> This also lets the driver drop the of_device.h include.
>
> Assisted-by: OpenCode:BigPickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/input/keyboard/mtk-pmic-keys.c | 53 ++++++++++++--------------
> 1 file changed, 24 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
> index c78d9f6d97c4..e34856693ee2 100644
> --- a/drivers/input/keyboard/mtk-pmic-keys.c
> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
> @@ -16,7 +16,6 @@
> #include <linux/mfd/mt6397/core.h>
> #include <linux/mfd/mt6397/registers.h>
> #include <linux/module.h>
> -#include <linux/of_device.h>
> #include <linux/of.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> @@ -147,6 +146,7 @@ struct mtk_pmic_keys {
> struct input_dev *input_dev;
> struct device *dev;
> struct regmap *regmap;
> + unsigned int nkeys;
> struct mtk_pmic_keys_info keys[MTK_PMIC_MAX_KEY_COUNT];
> };
>
> @@ -267,7 +267,7 @@ static int mtk_pmic_keys_suspend(struct device *dev)
> struct mtk_pmic_keys *keys = dev_get_drvdata(dev);
> int index;
>
> - for (index = 0; index < MTK_PMIC_MAX_KEY_COUNT; index++) {
> + for (index = 0; index < keys->nkeys; index++) {
> if (keys->keys[index].wakeup) {
> enable_irq_wake(keys->keys[index].irq);
> if (keys->keys[index].irq_r > 0)
> @@ -283,7 +283,7 @@ static int mtk_pmic_keys_resume(struct device *dev)
> struct mtk_pmic_keys *keys = dev_get_drvdata(dev);
> int index;
>
> - for (index = 0; index < MTK_PMIC_MAX_KEY_COUNT; index++) {
> + for (index = 0; index < keys->nkeys; index++) {
> if (keys->keys[index].wakeup) {
> disable_irq_wake(keys->keys[index].irq);
> if (keys->keys[index].irq_r > 0)
> @@ -325,24 +325,23 @@ MODULE_DEVICE_TABLE(of, of_mtk_pmic_keys_match_tbl);
> static int mtk_pmic_keys_probe(struct platform_device *pdev)
> {
> int error, index = 0;
> - unsigned int keycount;
> struct mt6397_chip *pmic_chip = dev_get_drvdata(pdev->dev.parent);
> struct device_node *node = pdev->dev.of_node;
> static const char *const irqnames[] = { "powerkey", "homekey" };
> static const char *const irqnames_r[] = { "powerkey_r", "homekey_r" };
> struct mtk_pmic_keys *keys;
> const struct mtk_pmic_regs *mtk_pmic_regs;
> + struct mtk_pmic_keys_info *key;
> struct input_dev *input_dev;
> - const struct of_device_id *of_id =
> - of_match_device(of_mtk_pmic_keys_match_tbl, &pdev->dev);
>
> keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
> if (!keys)
> return -ENOMEM;
> -
> keys->dev = &pdev->dev;
> keys->regmap = pmic_chip->regmap;
> - mtk_pmic_regs = of_id->data;
> + mtk_pmic_regs = of_device_get_match_data(&pdev->dev);
> + if (!mtk_pmic_regs)
> + return -EINVAL;
>
> keys->input_dev = input_dev = devm_input_allocate_device(keys->dev);
> if (!input_dev) {
> @@ -356,31 +355,26 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
> input_dev->id.product = 0x0001;
> input_dev->id.version = 0x0001;
>
> - keycount = of_get_available_child_count(node);
> - if (keycount > MTK_PMIC_MAX_KEY_COUNT ||
> - keycount > ARRAY_SIZE(irqnames)) {
> - dev_err(keys->dev, "too many keys defined (%d)\n", keycount);
> - return -EINVAL;
> - }
> + for_each_available_child_of_node_scoped(node, child) {
Let's keep using for_each_child_of_node_scoped() and check
of_device_is_available() inside the loop. This will allow marking a key
as disabled without shifting it's meaning (power key vs home key).
In the rest of the driver we should be able to determine if key is set
up checking for key->irq > 0.
Thanks.
--
Dmitry
^ permalink raw reply
* RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: YH Chung @ 2026-06-24 3:59 UTC (permalink / raw)
To: Shulzhenko, Oleksandr, Arnd Bergmann, Andrew Jeffery,
Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <KL1PR0601MB4276452D09689C90B04209C190EF2@KL1PR0601MB4276.apcprd06.prod.outlook.com>
Hi Mark,
> (1) Reuse the existing SPI subsystem and treat eSPI packets as pure signals.
> (2) Maintain the driver under the SoC subsystem, since there is currently no
> eSPI subsystem.
> (3) Create a new eSPI subsystem and rewrite the eSPI driver accordingly.
>
> For option 1, we do not think this would be a good fit, because eSPI has clearly
> defined semantics for each channel, and our hardware exposes different sets of
> registers for each of them.
Regarding option 1, could you kindly share your feedback on whether this
patch set should be modified to fit under the SPI subsystem, or whether a new
eSPI subsystem would be more appropriate?
For option 2, Arnd has indicated that he does not want to take this through
the SoC subsystem. Therefore, if the SPI subsystem is also not a good fit, we
think a new eSPI subsystem may be needed to provide a common home for channel
handling, even though the individual channels are relatively independent.
For example, the VW and OOB channel handling could potentially be integrated
with existing subsystems such as GPIO or net/mctp. However, the Flash channel
would still need an eSPI-specific interface to configure the backing store.
Placing that code under MTD feels awkward, since the driver is not really an
MTD device or a flash controller.
If this direction sounds reasonable, we would like to explore introducing a
new drivers/espi subsystem and moving the eSPI driver there. Please let us
know if you think we should take a different approach.
Thanks,
Yun Hsuan.
^ permalink raw reply
* [PATCH v2] cpufreq: apple-soc: Fix OPP table cleanup
From: Haoxiang Li @ 2026-06-24 3:37 UTC (permalink / raw)
To: sven, j, neal, rafael, viresh.kumar
Cc: linux-arm-kernel, asahi, linux-pm, linux-kernel, Haoxiang Li
dev_pm_opp_of_add_table() adds the DT OPP table but not all failure
paths remove it. The driver also uses dev_pm_opp_remove_all_dynamic(),
which is not the right cleanup helper for OPPs loaded from firmware.
Remove the DT OPP table with dev_pm_opp_of_remove_table() on init
failure paths and from apple_soc_cpufreq_exit().
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
Changes in v2:
- Remove unnecessary cleanup calls.
- Remove OPP table from apple_soc_cpufreq_exit(). Thanks, Viresh!
---
drivers/cpufreq/apple-soc-cpufreq.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/apple-soc-cpufreq.c b/drivers/cpufreq/apple-soc-cpufreq.c
index 638e5bf72185..977d56fc4fa0 100644
--- a/drivers/cpufreq/apple-soc-cpufreq.c
+++ b/drivers/cpufreq/apple-soc-cpufreq.c
@@ -258,7 +258,7 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
ret = apple_soc_cpufreq_find_cluster(policy, ®_base, &info);
if (ret) {
dev_err(cpu_dev, "%s: failed to get cluster info: %d\n", __func__, ret);
- return ret;
+ goto out_remove_opp_table;
}
ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
@@ -271,13 +271,13 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
if (ret <= 0) {
dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
ret = -EPROBE_DEFER;
- goto out_free_opp;
+ goto out_iounmap;
}
priv = kzalloc_obj(*priv);
if (!priv) {
ret = -ENOMEM;
- goto out_free_opp;
+ goto out_iounmap;
}
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
@@ -320,10 +320,10 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
out_free_priv:
kfree(priv);
-out_free_opp:
- dev_pm_opp_remove_all_dynamic(cpu_dev);
out_iounmap:
iounmap(reg_base);
+out_remove_opp_table:
+ dev_pm_opp_of_remove_table(cpu_dev);
return ret;
}
@@ -332,7 +332,7 @@ static void apple_soc_cpufreq_exit(struct cpufreq_policy *policy)
struct apple_cpu_priv *priv = policy->driver_data;
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
- dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
+ dev_pm_opp_of_remove_table(priv->cpu_dev);
iounmap(priv->reg_base);
kfree(priv);
}
--
2.25.1
^ permalink raw reply related
* RE: [PATCH 4/4] media: qcom: camss: use fwnode_graph_for_each_endpoint_scoped() to simpifly code
From: G.N. Zhou @ 2026-06-24 3:17 UTC (permalink / raw)
To: Frank Li (OSS), Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Mauro Carvalho Chehab, Dafna Hirschfeld,
Laurent Pinchart, Heiko Stuebner, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain
Cc: driver-core@lists.linux.dev, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, Frank Li
In-Reply-To: <20260622-fw_scoped-v1-4-a37d0aac0a68@nxp.com>
Hi Frank,
> -----Original Message-----
> From: Frank Li (OSS) <frank.li@oss.nxp.com>
> Sent: Monday, June 22, 2026 10:30 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Daniel Scally
> <djrscally@gmail.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Rafael J. Wysocki <rafael@kernel.org>; Danilo
> Krummrich <dakr@kernel.org>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Dafna Hirschfeld <dafna@fastmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Heiko Stuebner
> <heiko@sntech.de>; Bryan O'Donoghue <bryan.odonoghue@linaro.org>;
> Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>; Loic Poulain
> <loic.poulain@oss.qualcomm.com>
> Cc: driver-core@lists.linux.dev; linux-acpi@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-arm-kernel@lists.infradead.org; linux-arm-
> msm@vger.kernel.org; imx@lists.linux.dev; G.N. Zhou
> <guoniu.zhou@nxp.com>; Frank Li <frank.li@nxp.com>
> Subject: [PATCH 4/4] media: qcom: camss: use
> fwnode_graph_for_each_endpoint_scoped() to simpifly code
>
> From: Frank Li <Frank.Li@nxp.com>
>
> Use fwnode_graph_for_each_endpoint_scoped() to simpifly code.
s/simpifly/simplify/ both in message title and body.
With this addressed:
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
>
> No functional changes.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/media/platform/qcom/camss/camss.c | 17 +++++------------
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss.c
> b/drivers/media/platform/qcom/camss/camss.c
> index 2123f6388e3d7..23f3cc30a15a5 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -4793,30 +4793,23 @@ static int camss_parse_endpoint_node(struct
> device *dev, static int camss_parse_ports(struct camss *camss) {
> struct device *dev = camss->dev;
> - struct fwnode_handle *fwnode = dev_fwnode(dev), *ep;
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> int ret;
>
> - fwnode_graph_for_each_endpoint(fwnode, ep) {
> + fwnode_graph_for_each_endpoint_scoped(fwnode, ep) {
> struct camss_async_subdev *csd;
>
> csd = v4l2_async_nf_add_fwnode_remote(&camss->notifier,
> ep,
> typeof(*csd));
> - if (IS_ERR(csd)) {
> - ret = PTR_ERR(csd);
> - goto err_cleanup;
> - }
> + if (IS_ERR(csd))
> + return PTR_ERR(csd);
>
> ret = camss_parse_endpoint_node(dev, ep, csd);
> if (ret < 0)
> - goto err_cleanup;
> + return ret;
> }
>
> return 0;
> -
> -err_cleanup:
> - fwnode_handle_put(ep);
> -
> - return ret;
> }
>
> /*
>
> --
> 2.43.0
^ permalink raw reply
* RE: [PATCH 2/4] media: mc: use fwnode_graph_for_each_endpoint_scoped() to simpilfy code
From: G.N. Zhou @ 2026-06-24 3:15 UTC (permalink / raw)
To: Frank Li (OSS), Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Mauro Carvalho Chehab, Dafna Hirschfeld,
Laurent Pinchart, Heiko Stuebner, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain
Cc: driver-core@lists.linux.dev, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, Frank Li
In-Reply-To: <20260622-fw_scoped-v1-2-a37d0aac0a68@nxp.com>
Hi Frank,
> -----Original Message-----
> From: Frank Li (OSS) <frank.li@oss.nxp.com>
> Sent: Monday, June 22, 2026 10:30 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Daniel Scally
> <djrscally@gmail.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Rafael J. Wysocki <rafael@kernel.org>; Danilo
> Krummrich <dakr@kernel.org>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Dafna Hirschfeld <dafna@fastmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Heiko Stuebner
> <heiko@sntech.de>; Bryan O'Donoghue <bryan.odonoghue@linaro.org>;
> Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>; Loic Poulain
> <loic.poulain@oss.qualcomm.com>
> Cc: driver-core@lists.linux.dev; linux-acpi@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-arm-kernel@lists.infradead.org; linux-arm-
> msm@vger.kernel.org; imx@lists.linux.dev; G.N. Zhou
> <guoniu.zhou@nxp.com>; Frank Li <frank.li@nxp.com>
> Subject: [PATCH 2/4] media: mc: use
> fwnode_graph_for_each_endpoint_scoped() to simpilfy code
>
> From: Frank Li <Frank.Li@nxp.com>
>
> Use cleanup helper fwnode_graph_for_each_endpoint_scoped() to simpilfy
s/simpifly/simplify/ both in message title and body.
With this addressed:
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> code.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/media/v4l2-core/v4l2-mc.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-mc.c b/drivers/media/v4l2-core/v4l2-
> mc.c
> index 937d358697e19..5d7fcd67dc42e 100644
> --- a/drivers/media/v4l2-core/v4l2-mc.c
> +++ b/drivers/media/v4l2-core/v4l2-mc.c
> @@ -324,12 +324,10 @@
> EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
> int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
> struct media_pad *sink, u32 flags) {
> - struct fwnode_handle *endpoint;
> -
> if (!(sink->flags & MEDIA_PAD_FL_SINK))
> return -EINVAL;
>
> - fwnode_graph_for_each_endpoint(src_sd->fwnode, endpoint) {
> + fwnode_graph_for_each_endpoint_scoped(src_sd->fwnode, endpoint)
> {
> struct fwnode_handle *remote_ep;
> int src_idx, sink_idx, ret;
> struct media_pad *src;
> @@ -397,7 +395,6 @@ int v4l2_create_fwnode_links_to_pad(struct
> v4l2_subdev *src_sd,
> src_sd->entity.name, src_idx,
> sink->entity->name, sink_idx, ret);
>
> - fwnode_handle_put(endpoint);
> return ret;
> }
> }
>
> --
> 2.43.0
^ permalink raw reply
* [RFC PATCH] irqchip/gic-v3-its: enable dynamic MSI-X allocation
From: Jinqian Yang @ 2026-06-24 2:53 UTC (permalink / raw)
To: lpieralisi, maz, tglx, alex
Cc: linux-kernel, linux-arm-kernel, liuyonglong, wangzhou1, linuxarm,
Jinqian Yang
On ARM64 platforms with GICv3 ITS, VFIO PCI passthrough currently
cannot dynamically allocate MSI-X vectors after MSI-X has been
enabled. When QEMU needs to extend the vector range, it must
disable MSI-X, free all interrupts, then re-enable with a larger
allocation. This creates an interrupt loss window for already-active
vectors.
Consider HNS3 with RoCE: NIC and RDMA share one PCI device and
ITS DeviceID, with MSI-X vectors partitioned as NIC (lower range)
then RoCE (starting at base_vector = num_nic_msi). In VFIO
passthrough, loading hns_roce after hns3 forces QEMU to tear down
all interrupts before re-allocating the larger range. During this
process, NIC interrupts may be lost. Testing confirmed that this
occasionally occurs, causing the network port reset to fail.
ITS_MSI_FLAGS_SUPPORTED lacks MSI_FLAG_PCI_MSIX_ALLOC_DYN, causing
pci_msix_can_alloc_dyn() to return false. VFIO then sets
has_dyn_msix=false and never clears VFIO_IRQ_INFO_NORESIZE for
MSI-X, keeping the old "disable and reallocate" behavior.
The essential prerequisite for enabling this flag is the fix to
msi_prepare() call timing (commit 1396e89e09f0 ("genirq/msi: Move
prepare() call to per-device allocation")): msi_prepare() is
now called once at per-device domain creation with hwsize, so ITS
creates an ITT with sufficient capacity for all MSI-X vectors.
Without this fix, msi_prepare() was called per-allocation with
semi-random nvec, maybe resulting in an ITT too small for dynamic
vector addition.
With this in place, dynamic MSI-X allocation works correctly:
msi_domain_alloc_irq_at() uses populate_alloc_info() to copy the
pre-prepared alloc_data without re-invoking msi_prepare(), so each
new vector simply gets a LPI entry in the already-allocated ITT,
without affecting existing vectors.
Signed-off-by: Jinqian Yang <yangjinqian1@huawei.com>
---
drivers/irqchip/irq-gic-its-msi-parent.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c
index b9257103a999..b2b9d2068bb1 100644
--- a/drivers/irqchip/irq-gic-its-msi-parent.c
+++ b/drivers/irqchip/irq-gic-its-msi-parent.c
@@ -18,7 +18,8 @@
#define ITS_MSI_FLAGS_SUPPORTED (MSI_GENERIC_FLAGS_MASK | \
MSI_FLAG_PCI_MSIX | \
- MSI_FLAG_MULTI_PCI_MSI)
+ MSI_FLAG_MULTI_PCI_MSI | \
+ MSI_FLAG_PCI_MSIX_ALLOC_DYN)
static int its_translate_frame_address(struct fwnode_handle *msi_node, phys_addr_t *pa)
{
--
2.33.0
^ permalink raw reply related
* RE: [PATCH 1/4] device property: Introduce fwnode_graph_for_each_endpoint_scoped()
From: G.N. Zhou @ 2026-06-24 2:54 UTC (permalink / raw)
To: Frank Li (OSS), Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Mauro Carvalho Chehab, Dafna Hirschfeld,
Laurent Pinchart, Heiko Stuebner, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain
Cc: driver-core@lists.linux.dev, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, Frank Li
In-Reply-To: <20260622-fw_scoped-v1-1-a37d0aac0a68@nxp.com>
Hi Frank,
> -----Original Message-----
> From: Frank Li (OSS) <frank.li@oss.nxp.com>
> Sent: Monday, June 22, 2026 10:30 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Daniel Scally
> <djrscally@gmail.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Rafael J. Wysocki <rafael@kernel.org>; Danilo
> Krummrich <dakr@kernel.org>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Dafna Hirschfeld <dafna@fastmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Heiko Stuebner
> <heiko@sntech.de>; Bryan O'Donoghue <bryan.odonoghue@linaro.org>;
> Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>; Loic Poulain
> <loic.poulain@oss.qualcomm.com>
> Cc: driver-core@lists.linux.dev; linux-acpi@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-arm-kernel@lists.infradead.org; linux-arm-
> msm@vger.kernel.org; imx@lists.linux.dev; G.N. Zhou
> <guoniu.zhou@nxp.com>; Frank Li <frank.li@nxp.com>
> Subject: [PATCH 1/4] device property: Introduce
> fwnode_graph_for_each_endpoint_scoped()
>
> From: Frank Li <Frank.Li@nxp.com>
>
> Similar to recently propose for_each_child_of_node_scoped() this new version
> of the loop macro instantiates a new local struct fwnode_handle * that uses the
> __free(fwnode_handle) auto cleanup handling so that if a reference to a node is
> held on early exit from the loop the reference will be released. If the loop runs
> to completion, the child pointer will be NULL and no action will be taken.
>
> The reason this is useful is that it removes the need for
> fwnode_handle_put() on early loop exits. If there is a need to retain the
> reference, then return_ptr(child) or no_free_ptr(child) may be used to safely
> disable the auto cleanup.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> include/linux/property.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/property.h b/include/linux/property.h index
> 14c304db46648..ade194c462d42 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -545,6 +545,11 @@ unsigned int
> fwnode_graph_get_endpoint_count(const struct fwnode_handle *fwnode,
> for (child = fwnode_graph_get_next_endpoint(fwnode, NULL); child;
> \
> child = fwnode_graph_get_next_endpoint(fwnode, child))
>
> +#define fwnode_graph_for_each_endpoint_scoped(fwnode, child)
> \
> + for (struct fwnode_handle *child __free(fwnode_handle) =
> \
> + fwnode_graph_get_next_endpoint(fwnode, NULL);
> \
> + child; child = fwnode_graph_get_next_endpoint(fwnode, child))
> +
> int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
> struct fwnode_endpoint *endpoint);
>
>
> --
> 2.43.0
^ permalink raw reply
* Re: chipidea: usbmisc_imx: i.MX93 support
From: Xu Yang @ 2026-06-24 2:50 UTC (permalink / raw)
To: Stefan Wahren
Cc: Xu Yang, Frank Li, Jun Li, Alexander Stein, Greg Kroah-Hartman,
Linux ARM, linux-usb@vger.kernel.org
In-Reply-To: <b2fb88eb-5c5f-499f-9cee-6a69769c578c@gmx.net>
On Tue, Jun 23, 2026 at 12:23:12PM +0200, Stefan Wahren wrote:
> Hi,
>
> during debugging USB OTG on our custom i.MX93 board, we noticed remarkable
> differences between the implementation of the chipidea/usbmisc_imx and the
> official NXP i.MX93 Reference Manual [1].
>
> Is the USB OTG part including PHY of the i.MX93 officially supported in
> Linux Mainline?
Yes.
>
> According to imx91_93_common.dtsi the USB IP of the i.MX93 should be
> identical to i.MX8MM [2]
>
> usbmisc1: usbmisc@4c100200 {
>
> compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
> "fsl,imx6q-usbmisc";
>
> But looking at the PHY register definition and reset values in the NXP
> i.MX93 Reference Manual,
>
> the registers are comparable to the i.MX95 [3] ones.
>
> Could you please clarify which source is correct (Mainline DTS vs Reference
> Manual)?
The Reference Manual is correct.
>
> Looking deeper at chipidea/usbmisc_imx shows the usage of the following
> register bits
>
> #define MX7D_USB_OTG_PHY_CFG2_CHRG_CHRGSEL BIT(0)
>
> #define MX7D_USB_OTG_PHY_CFG2_CHRG_VDATDETENB0 BIT(1)
>
> #define MX7D_USB_OTG_PHY_CFG2_CHRG_VDATSRCENB0 BIT(2)
>
> #define MX7D_USB_OTG_PHY_CFG2_CHRG_DCDENB BIT(3)
>
> #define MX7D_USB_OTG_PHY_STATUS_LINE_STATE0 BIT(0)
>
> #define MX7D_USB_OTG_PHY_STATUS_LINE_STATE1 BIT(1)
>
> #define MX7D_USB_OTG_PHY_STATUS_CHRGDET BIT(29)
>
> According to NXP i.MX93 & i.MX95 Reference Manual, these are bits reserved.
>
> Is it correct that the chipidea/usbmisc_imx use these bits on i.MX93?
i.MX93 & i.MX95 no longer claims to support Battery charger detection. So these
bits are reserved. However, at the IP level, accessing these bits will not produce
errors. We will remove .charger_detection hook for the i.MX9 series in the future.
Do you want to use Battery charger detection on i.MX93?
Thanks,
Xu Yang
>
> Best regards
>
> [1] - https://www.nxp.com/docs/en/reference-manual/IMX93RM.pdf
> <https://www.nxp.com/docs/en/reference-manual/IMX93RM.pdf>
>
> [2] - https://www.nxp.com/docs/en/reference-manual/IMX8MMRM.pdf
> <https://www.nxp.com/docs/en/reference-manual/IMX8MMRM.pdf>
>
> [3] - https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf
> <https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf>
>
^ permalink raw reply
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
From: Bui Duc Phuc @ 2026-06-24 2:37 UTC (permalink / raw)
To: Mark Brown
Cc: Heiko Stuebner, Liam Girdwood, Nicolas Frattaroli,
Krzysztof Kozlowski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <CAABR9nG6BL+-urEg0qDzJHYmowm7O=du_0T4+K2ogdrcD30CXA@mail.gmail.com>
Hi all,
Regarding the case where PM configuration is not enabled, with the old
source code, I suspect there is an unbalanced clk_disable_unprepare()
call on hclk when the driver is unbound after a successful probe under
CONFIG_PM=n.
The actual enable_count / prepare_count sequence for hclk (with values
clamped at 0) would be:
probe:
devm_clk_get_enabled 0 -> 1
runtime_resume (manual) 1 -> 2
clk_disable_unprepare 2 -> 1 (at the end of probe)
unbind:
remove -> runtime_suspend 1 -> 0 (ops->disable/unprepare executed here)
devm cleanup 0 -> WARN "already disabled" /
"already unprepared"
This conclusion is based solely on code inspection; I do not have
hardware available to verify it.
I noticed that Nicolas tested and ACKed the use of devm_clk_get_enabled(),
so I'm not sure whether that testing included the CONFIG_PM=n configuration.
https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
If it did, then I may have overlooked something.
@Nicolas (or anyone familiar with this), could you please help
double-check if my understanding is correct?
Best regards,
Phuc
On Tue, Jun 23, 2026 at 5:53 PM Bui Duc Phuc <phucduc.bui@gmail.com> wrote:
>
> Hi Mark,
>
> Thank you for your review.
>
> > > 1 Reverting back to devm_clk_get() to remove the implicit devres
> > > enable/disable behavior.
> > > 2 Manually enabling and disabling hclk explicitly only around the
> > > early register access before Runtime PM takes over.
> > > 3 Dropping the stray clk_disable_unprepare() at the end of probe()
> > > so Runtime PM solely owns hclk afterward.
> >
> > Note that runtime PM can be disabled at build time so we might not have
> > runtime PM at all...
> >
>
> Thanks for pointing this out. You're right that with !CONFIG_PM, the
> driver only relies on the
> two manual calls to rokchip_sai_runtime_resume() / suspend(), so hclk
> stays enabled the
> whole time. I understand this is unvavoidable in that configuration,
> throgh, since there's no
> Runtime PM to re-enable the clock when it's needed.
>
> I'll update the commit message to reflect that the driver uses a
> combination of Runtime PM
> and explicit manual enable/disable, rather than relying on Runtime PM alone.
>
> > > Links:
> > > 1 This change is based on the discussion around manual hclk handing during probe(),
> > > as raised by Krysztof:
> > > https://lore.kernel.org/all/20e4754b-ea9a-404d-b529-ec44a7263cbf@kernel.org/#t
> > > 2 Background for the earlier devm_clk_get_enbabled() conversion:
> > > https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
> >
> > > An alternative approach would be use devm_regmap_init_mmio_clk() and let regmap
> > > manage clock enablement around register accesses. If preferred, I can rework the
> > > driver accordingly.
> >
> > > - sai->hclk = devm_clk_get_enabled(&pdev->dev, "hclk");
> > > + sai->hclk = devm_clk_get(&pdev->dev, "hclk");
> > > if (IS_ERR(sai->hclk))
> > > return dev_err_probe(&pdev->dev, PTR_ERR(sai->hclk),
> > > "Failed to get hclk\n");
> > >
> > > + ret = clk_prepare_enable(sai->hclk);
> > > + if (ret)
> > > + return dev_err_probe(&pdev->dev, ret, "Failed to enable hclk\n");
> > > +
> >
> > > @@ -1482,8 +1492,6 @@ static int rockchip_sai_probe(struct platform_device *pdev)
> > > pm_runtime_use_autosuspend(&pdev->dev);
> > > pm_runtime_put(&pdev->dev);
> > >
> > > - clk_disable_unprepare(sai->hclk);
> > > -
> > > return 0;
> >
> > Are you sure that the runtime PM state there is such that it knows a
> > reference is held? The driver used pm_runtime_get_noresume() so the
> > device didn't have RPM_ACTIVE set I think?
>
>
> You are right, pm_runtime_get_noresume() doesn't set RPM_ACTIVE. I
> think we need to add
> pm_runtime_set_active() before pm_runtime_enable(). Otherwise, with CONFIG_PM,
> the pm_runtime_put() at the end of probe() might skip the suspend,
> since the core still considers
> the device suspended .
>
> >
> > The runtime PM API really is a miserable collection of landmines :(
>
> Yeah, plenty of landmines indeed :(
> I checked, and rockchip_spdif.c does use devm_regmap_init_mmio_clk() for hclk,
> rather than wrapping every register access in pm_runtime_get_sync() /
> pm_runtime_put()
> the way rockchip_sai does.
>
> Best regards,
> Phuc
^ permalink raw reply
* [PATCH] mmc: cqhci: Remove unused intmask parameter from cqhci_irq()
From: Chanwoo Lee @ 2026-06-24 2:19 UTC (permalink / raw)
To: Adrian Hunter, Asutosh Das, Ritesh Harjani, Ulf Hansson,
Chaotian Jing, Matthias Brugger, AngeloGioacchino Del Regno,
Kamal Dasu, Al Cooper, Broadcom internal kernel review list,
Florian Fainelli, Haibo Chen, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Michal Simek,
Thierry Reding, Jonathan Hunter,
open list:EMMC CMDQ HOST CONTROLLER INTERFACE (CQHCI) DRIVER,
open list, moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
open list:ARM/QUALCOMM MAILING LIST,
open list:TEGRA ARCHITECTURE SUPPORT
Cc: Chanwoo Lee
In-Reply-To: <CGME20260624021955epcas1p2ba2fa4eb8bd0aafaf7b46bde2cf524be@epcas1p2.samsung.com>
The intmask parameter of cqhci_irq() is never used within the function
body. The function reads the CQHCI interrupt status directly via
cqhci_readl() and processes interrupts independently of the SDHCI
intmask value passed by callers.
Signed-off-by: Chanwoo Lee <cw9316.lee@samsung.com>
---
drivers/mmc/host/cqhci-core.c | 3 +--
drivers/mmc/host/cqhci.h | 3 +--
drivers/mmc/host/mtk-sd.c | 2 +-
drivers/mmc/host/sdhci-brcmstb.c | 2 +-
drivers/mmc/host/sdhci-esdhc-imx.c | 2 +-
drivers/mmc/host/sdhci-msm.c | 2 +-
drivers/mmc/host/sdhci-of-arasan.c | 2 +-
drivers/mmc/host/sdhci-of-dwcmshc.c | 2 +-
drivers/mmc/host/sdhci-pci-core.c | 2 +-
drivers/mmc/host/sdhci-pci-gli.c | 2 +-
drivers/mmc/host/sdhci-tegra.c | 2 +-
drivers/mmc/host/sdhci_am654.c | 2 +-
12 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/cqhci-core.c b/drivers/mmc/host/cqhci-core.c
index 178277d90c31..98ceb0b9a6d1 100644
--- a/drivers/mmc/host/cqhci-core.c
+++ b/drivers/mmc/host/cqhci-core.c
@@ -819,8 +819,7 @@ static void cqhci_finish_mrq(struct mmc_host *mmc, unsigned int tag)
mmc_cqe_request_done(mmc, mrq);
}
-irqreturn_t cqhci_irq(struct mmc_host *mmc, u32 intmask, int cmd_error,
- int data_error)
+irqreturn_t cqhci_irq(struct mmc_host *mmc, int cmd_error, int data_error)
{
u32 status;
unsigned long tag = 0, comp_status;
diff --git a/drivers/mmc/host/cqhci.h b/drivers/mmc/host/cqhci.h
index 3668856531c1..8fbbc48c3f85 100644
--- a/drivers/mmc/host/cqhci.h
+++ b/drivers/mmc/host/cqhci.h
@@ -315,8 +315,7 @@ static inline u32 cqhci_readl(struct cqhci_host *host, int reg)
struct platform_device;
-irqreturn_t cqhci_irq(struct mmc_host *mmc, u32 intmask, int cmd_error,
- int data_error);
+irqreturn_t cqhci_irq(struct mmc_host *mmc, int cmd_error, int data_error);
int cqhci_init(struct cqhci_host *cq_host, struct mmc_host *mmc, bool dma64);
struct cqhci_host *cqhci_pltfm_init(struct platform_device *pdev);
int cqhci_deactivate(struct mmc_host *mmc);
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index b2680cc054bd..01ea3adbdf3b 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1805,7 +1805,7 @@ static irqreturn_t msdc_cmdq_irq(struct msdc_host *host, u32 intsts)
cmd_err, dat_err, intsts);
}
- return cqhci_irq(mmc, 0, cmd_err, dat_err);
+ return cqhci_irq(mmc, cmd_err, dat_err);
}
static irqreturn_t msdc_irq(int irq, void *dev_id)
diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
index 57e45951644e..1de2f05fd958 100644
--- a/drivers/mmc/host/sdhci-brcmstb.c
+++ b/drivers/mmc/host/sdhci-brcmstb.c
@@ -430,7 +430,7 @@ static u32 sdhci_brcmstb_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 18ecddd6df6f..d0fa83f67a80 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -1503,7 +1503,7 @@ static u32 esdhc_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 0882ce74e0c9..ceed47ccfda8 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -2165,7 +2165,7 @@ static u32 sdhci_msm_cqe_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 785d3acb18c5..4ca73e7d799e 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -555,7 +555,7 @@ static u32 sdhci_arasan_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c b/drivers/mmc/host/sdhci-of-dwcmshc.c
index eef53455b8ee..4c5fa6a6931d 100644
--- a/drivers/mmc/host/sdhci-of-dwcmshc.c
+++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
@@ -624,7 +624,7 @@ static u32 dwcmshc_cqe_irq_handler(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index c347fac24515..b121d896a804 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -215,7 +215,7 @@ static u32 sdhci_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c
index 6e4084407662..b55618566d65 100644
--- a/drivers/mmc/host/sdhci-pci-gli.c
+++ b/drivers/mmc/host/sdhci-pci-gli.c
@@ -1760,7 +1760,7 @@ static u32 sdhci_gl9763e_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 820ce4dae58b..221e48b59f48 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1280,7 +1280,7 @@ static u32 sdhci_tegra_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
index d235b0aecfdb..2a27db2f558b 100644
--- a/drivers/mmc/host/sdhci_am654.c
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -462,7 +462,7 @@ static u32 sdhci_am654_cqhci_irq(struct sdhci_host *host, u32 intmask)
if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
return intmask;
- cqhci_irq(host->mmc, intmask, cmd_error, data_error);
+ cqhci_irq(host->mmc, cmd_error, data_error);
return 0;
}
--
2.43.0
^ permalink raw reply related
* [arm64:for-next/core 12/12] usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
From: kernel test robot @ 2026-06-24 2:14 UTC (permalink / raw)
To: Will Deacon; +Cc: oe-kbuild-all, linux-arm-kernel, Marc Zyngier, Arnd Bergmann
Hi Will,
FYI, the error/warning was bisected to this commit, please ignore it if it's irrelevant.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
head: 9d6306113f921dc00793df46f31ed46583c720df
commit: 9d6306113f921dc00793df46f31ed46583c720df [12/12] arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers
config: arm64-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260624/202606240441.7eZ1TIRM-lkp@intel.com/config)
compiler: aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260624/202606240441.7eZ1TIRM-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606240441.7eZ1TIRM-lkp@intel.com/
Note: the arm64/for-next/core HEAD 9d6306113f921dc00793df46f31ed46583c720df builds fine.
It only hurts bisectability.
All errors (new ones prefixed by >>):
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from testcases/fake_sigreturn_bad_magic.c:10:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from ./test_signals.h:14,
from ./test_signals_utils.h:14,
from testcases/fake_sigreturn_bad_magic.c:13:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from test_signals.h:7,
from test_signals.c:16:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from test_signals.h:14:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from test_signals_utils.c:6:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from test_signals.h:14,
from test_signals_utils.c:18:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from testcases/testcases.h:12,
from testcases/testcases.c:7:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from sve_helpers.c:10:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
--
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from /usr/aarch64-linux-gnu/include/sys/wait.h:36,
from pac.c:8:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
--
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from /usr/aarch64-linux-gnu/include/sys/wait.h:36,
from fp-ptrace.c:22:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from fp-ptrace.c:28:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
--
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from mte_common_util.h:7,
from check_buffer_fill.c:11:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from mte_common_util.c:6:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
--
In file included from system.h:20,
from test.c:7:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
In file included from test.c:14:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
--
In file included from system.h:20,
from signal.c:7:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
--
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from tools/testing/selftests/cgroup/lib/cgroup_util.c:9:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
cc1: note: unrecognized command-line option '-Wno-gnu-variable-sized-type-not-at-end' may have been intended to silence earlier diagnostics
--
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from include/test_util.h:12,
from include/kvm_util.h:8,
from demand_paging_test.c:17:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
In file included from usr/include/asm/kvm.h:37,
from usr/include/linux/kvm.h:16,
from include/kvm_util.h:14:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
cc1: note: unrecognized command-line option '-Wno-gnu-variable-sized-type-not-at-end' may have been intended to silence earlier diagnostics
--
In file included from usr/include/asm/kvm.h:37,
from usr/include/linux/kvm.h:16,
from lib/arm64/gic_v3_its.c:7:
>> usr/include/asm/ptrace.h:96:9: error: unknown type name '__u128'; did you mean '__u32'?
96 | __u128 vregs[32];
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:261:9: error: unknown type name '__u128'; did you mean '__u32'?
261 | __u128 apiakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:262:9: error: unknown type name '__u128'; did you mean '__u32'?
262 | __u128 apibkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:263:9: error: unknown type name '__u128'; did you mean '__u32'?
263 | __u128 apdakey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:264:9: error: unknown type name '__u128'; did you mean '__u32'?
264 | __u128 apdbkey;
| ^~~~~~
| __u32
usr/include/asm/ptrace.h:268:9: error: unknown type name '__u128'; did you mean '__u32'?
268 | __u128 apgakey;
| ^~~~~~
| __u32
In file included from /usr/aarch64-linux-gnu/include/bits/sigcontext.h:30,
from /usr/aarch64-linux-gnu/include/signal.h:301,
from include/test_util.h:12,
from include/kvm_util.h:8,
from lib/arm64/gic_v3_its.c:12:
>> usr/include/asm/sigcontext.h:81:9: error: unknown type name '__u128'; did you mean '__u32'?
81 | __u128 vregs[32];
| ^~~~~~
| __u32
cc1: note: unrecognized command-line option '-Wno-gnu-variable-sized-type-not-at-end' may have been intended to silence earlier diagnostics
..
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] media: imx-jpeg: finish the job on device_run() error paths
From: Fan Wu @ 2026-06-24 0:32 UTC (permalink / raw)
To: mirela.rabulea, mchehab
Cc: shawnguo, s.hauer, kernel, festevam, imx, linux-media,
linux-arm-kernel, linux-kernel, stable, Fan Wu
mxc_jpeg_device_run() returns early through a shared "end" label on several
error paths (no free slot, mxc_jpeg_alloc_slot_data() failure, or missing
buffers or queue data), and none of them calls v4l2_m2m_job_finish().
Since the delayed work is queued only after the hardware is started, those
paths neither finish the job directly nor queue timeout work that could
finish it later. The job is left with TRANS_RUNNING set, so the
wait_event() in v4l2_m2m_cancel_job() (reached from v4l2_m2m_ctx_release()
at close) waits indefinitely and the close hangs.
mxc_jpeg_alloc_slot_data() uses dma_alloc_coherent(), so the failure path
is reachable under memory pressure.
Return the src/dst buffers with VB2_BUF_STATE_ERROR and call
v4l2_m2m_job_finish() on those paths: paths that have buffers use a
"buf_finish" label; the no-buffer path uses "job_finish" directly. This
mirrors the existing jpeg_parse_error path.
This bug was found by static analysis.
Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
Cc: stable@vger.kernel.org
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
---
.../media/platform/nxp/imx-jpeg/mxc-jpeg.c | 21 +++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
index 9e4a813489c0..6b224a19f40e 100644
--- a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
+++ b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
@@ -1525,15 +1525,15 @@ static void mxc_jpeg_device_run(void *priv)
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
if (!src_buf || !dst_buf) {
dev_err(dev, "Null src or dst buf\n");
- goto end;
+ goto job_finish;
}
q_data_cap = mxc_jpeg_get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
if (!q_data_cap)
- goto end;
+ goto buf_finish;
q_data_out = mxc_jpeg_get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
if (!q_data_out)
- goto end;
+ goto buf_finish;
src_buf->sequence = q_data_out->sequence++;
dst_buf->sequence = q_data_cap->sequence++;
@@ -1571,11 +1571,11 @@ static void mxc_jpeg_device_run(void *priv)
ctx->slot = mxc_get_free_slot(&jpeg->slot_data);
if (ctx->slot < 0) {
dev_err(dev, "No more free slots\n");
- goto end;
+ goto buf_finish;
}
if (!mxc_jpeg_alloc_slot_data(jpeg)) {
dev_err(dev, "Cannot allocate slot data\n");
- goto end;
+ goto buf_finish;
}
mxc_jpeg_enable_slot(reg, ctx->slot);
@@ -1597,8 +1597,17 @@ static void mxc_jpeg_device_run(void *priv)
mxc_jpeg_dec_mode_go(dev, reg);
}
schedule_delayed_work(&ctx->task_timer, msecs_to_jiffies(hw_timeout));
-end:
+
spin_unlock_irqrestore(&ctx->mxc_jpeg->hw_lock, flags);
+ return;
+buf_finish:
+ v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_ERROR);
+ v4l2_m2m_buf_done(dst_buf, VB2_BUF_STATE_ERROR);
+job_finish:
+ spin_unlock_irqrestore(&ctx->mxc_jpeg->hw_lock, flags);
+ v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
}
static int mxc_jpeg_decoder_cmd(struct file *file, void *priv,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 0/2] Add SMCCC cache clean/invalidate provider
From: Srirangan Madhavan @ 2026-06-23 23:37 UTC (permalink / raw)
To: Mark Rutland, Lorenzo Pieralisi, Sudeep Holla, Conor Dooley,
Jonathan Cameron
Cc: Catalin Marinas, Will Deacon, Dan Williams, Thierry Reding,
Jon Hunter, Vikram Sethi, Souvik Chakravarty,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org
In-Reply-To: <20260608220709.1300245-1-smadhavan@nvidia.com>
Hi all,
Gentle ping on this v2.
This version includes Jonathan's Reviewed-by tags and addresses the v1
comments around the Kconfig wording, Makefile ordering/comment, and retry
loop handling.
The main open question from v1 was whether DEN0028 v1.7 BET0 is sufficient
for merging these SMCCC cache maintenance definitions/provider. Could one
of the Arm/SMCCC maintainers please confirm whether this is acceptable for
merge, or whether the series should wait for a non-beta spec revision?
If the spec status is acceptable, please let me know if there are any
remaining concerns with v2.
Thanks,
Srirangan
________________________________________
From: Srirangan Madhavan
Sent: Monday, June 8, 2026 3:07 PM
To: Mark Rutland; Lorenzo Pieralisi; Sudeep Holla; Conor Dooley; Jonathan Cameron
Cc: Catalin Marinas; Will Deacon; Dan Williams; Thierry Reding; Jon Hunter; Souvik Chakravarty; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-tegra@vger.kernel.org; Srirangan Madhavan
Subject: [PATCH v2 0/2] Add SMCCC cache clean/invalidate provider
This series adds an arm64 backend for memregion cache invalidation users
based on the Arm SMCCC cache clean+invalidate interface.
Per DEN0028, this interface targets systems where a Normal Cacheable
memory region can be modified in ways that are not handled by usual PE
coherency mechanisms, and where VA-based CMOs may be too slow or
insufficient for large ranges and/or system-cache implementations.
Representative use cases include device-backed memory state transitions
where stale CPU/system cache lines must be invalidated reliably (for
example secure erase, reset/offline flows, and dynamic memory
reconfiguration).
Patch 1 introduces the Arm SMCCC cache clean/invalidate function IDs and
transient return codes needed by callers [1].
Patch 2 adds a cache maintenance provider that:
- discovers SMCCC support and attributes at init time
- registers with the generic cache coherency framework used by
cpu_cache_invalidate_memregion()
- handles transient BUSY/RATE_LIMITED responses with bounded retries
This patch set does not add a software fallback path; when firmware does
not implement the SMCCC cache maintenance interface, the provider is not
registered and existing behavior is preserved.
Reference:
[1] https://developer.arm.com/documentation/den0028/latest
Note: Jonathan Cameron raised whether DEN0028 v1.7 BET0 is sufficient
for merge. Input from Arm maintainers / SMCCC spec owners on that point
would be appreciated.
Changes since v1:
- Added Jonathan Cameron's Reviewed-by tags.
- Clarified the ARM_SMCCC_CACHE Kconfig help text.
- Added a Makefile comment identifying the providers that depend on
CACHEMAINT_FOR_HOTPLUG.
- Dropped the final-backoff-sleep skip in the retry loop.
Changes since RFC:
- Dropped the RFC tag.
- Moved the provider from arch/arm64/mm to drivers/cache.
- Added a dedicated CONFIG_ARM_SMCCC_CACHE option under the existing
CACHEMAINT_FOR_HOTPLUG menu.
- Dropped the global-operation coalescing optimization.
- Dropped provider handling for SMCCC_RET_NOT_REQUIRED.
- Removed the unnecessary global provider pointer.
- Removed arm64_ prefixes from static provider-local names.
- Documented why these SMCCC Arch cache maintenance calls use SMC64.
- Anchored the SMCCC return-code comment to DEN0028 v1.7.
- Used fsleep() for retry backoff.
- Used unsigned long for retry delay values passed to fsleep().
- Skipped the final backoff sleep when no retry remains.
- Documented the bounded mutex hold time across the serialized retry
sequence.
- Added mutex_destroy() on the registration failure path.
Srirangan Madhavan (2):
arm64: smccc: add cache clean/invalidate IDs and return codes
cache: add SMCCC-backed cache invalidate provider
drivers/cache/Kconfig | 11 +++
drivers/cache/Makefile | 2 +
drivers/cache/arm_smccc_cache.c | 157 ++++++++++++++++++++++++++++++++
include/linux/arm-smccc.h | 21 ++++-
tools/include/linux/arm-smccc.h | 21 ++++-
5 files changed, 208 insertions(+), 4 deletions(-)
create mode 100644 drivers/cache/arm_smccc_cache.c
base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
--
2.43.0
^ permalink raw reply
* Re: [PATCH RFC 5/8] clk: sunxi-ng: a733: Add bus clocks support
From: Andre Przywara @ 2026-06-23 22:35 UTC (permalink / raw)
To: Junhui Liu, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Richard Cochran
Cc: linux-clk, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv, netdev
In-Reply-To: <20260310-a733-clk-v1-5-36b4e9b24457@pigmoral.tech>
Hi,
On 3/10/26 08:33, Junhui Liu wrote:
> Add the essential bus clocks in the Allwinner A733 CCU, including AHB,
> APB0, APB1, APB_UART, NSI, and MBUS. These buses are necessary for many
> other functional modules. Additionally clocks such as trace, gic and
> cpu_peri are also added as they fall within the register address range
> of the bus clocks, even though they are not strictly bus clocks.
>
> The MBUS clock is marked as critical to ensure the memory bus remains
> operational at all times. For the NSI and MBUS clocks, the hardware
> requires an update bit (bit 27) to be set so that the configuration
> takes effect and the updated parameters can be correctly read back.
>
> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> ---
> drivers/clk/sunxi-ng/ccu-sun60i-a733.c | 131 +++++++++++++++++++++++++++++++++
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun60i-a733.c b/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
> index cf819504c51f..68457813dbbb 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
> @@ -19,6 +19,7 @@
> #include "ccu_common.h"
>
> #include "ccu_div.h"
> +#include "ccu_mp.h"
> #include "ccu_mult.h"
> #include "ccu_nkmp.h"
> #include "ccu_nm.h"
> @@ -65,6 +66,16 @@ static const struct clk_hw *pll_ref_hws[] = {
> &pll_ref_clk.common.hw
> };
>
> +/*
> + * There is a non-software-configurable mux selecting between the DCXO and the
> + * PLL_REF in hardware, whose output is fed to the sys-24M clock. Although both
> + * sys-24M and pll-ref are fixed at 24 MHz, define a 1:1 fixed factor clock to
> + * provide logical separation:
> + * - pll-ref is dedicated to feeding other PLLs
> + * - sys-24M serves as reference clock for downstream functional modules
> + */
> +static CLK_FIXED_FACTOR_HWS(sys_24M_clk, "sys-24M", pll_ref_hws, 1, 1, 0);
> +
> #define SUN60I_A733_PLL_DDR_REG 0x020
> static struct ccu_nkmp pll_ddr_clk = {
> .enable = BIT(27),
> @@ -371,6 +382,107 @@ static SUNXI_CCU_M_HWS(pll_de_4x_clk, "pll-de-4x", pll_de_hws,
> static SUNXI_CCU_M_HWS(pll_de_3x_clk, "pll-de-3x", pll_de_hws,
> SUN60I_A733_PLL_DE_REG, 16, 3, 0);
>
> +/**************************************************************************
> + * bus clocks *
> + **************************************************************************/
> +
> +static const struct clk_parent_data ahb_apb_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .fw_name = "losc" },
> + { .fw_name = "iosc" },
> + { .hw = &pll_periph0_600M_clk.hw },
> +};
> +
> +static SUNXI_CCU_M_DATA_WITH_MUX(ahb_clk, "ahb", ahb_apb_parents, 0x500,
> + 0, 5, /* M */
> + 24, 2, /* mux */
> + 0);
> +
> +static SUNXI_CCU_M_DATA_WITH_MUX(apb0_clk, "apb0", ahb_apb_parents, 0x510,
> + 0, 5, /* M */
> + 24, 2, /* mux */
> + 0);
> +
> +static SUNXI_CCU_M_DATA_WITH_MUX(apb1_clk, "apb1", ahb_apb_parents, 0x518,
> + 0, 5, /* M */
> + 24, 2, /* mux */
> + 0);
> +
> +static const struct clk_parent_data apb_uart_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .fw_name = "losc" },
> + { .fw_name = "iosc" },
> + { .hw = &pll_periph0_600M_clk.hw },
> + { .hw = &pll_periph0_480M_clk.common.hw },
> +};
> +static SUNXI_CCU_M_DATA_WITH_MUX(apb_uart_clk, "apb-uart", apb_uart_parents, 0x538,
> + 0, 5, /* M */
> + 24, 3, /* mux */
> + 0);
> +
> +static const struct clk_parent_data trace_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .fw_name = "losc" },
> + { .fw_name = "iosc" },
> + { .hw = &pll_periph0_300M_clk.hw },
> + { .hw = &pll_periph0_400M_clk.hw },
> +};
> +static SUNXI_CCU_M_DATA_WITH_MUX_GATE(trace_clk, "trace", trace_parents, 0x540,
> + 0, 5, /* M */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static const struct clk_parent_data gic_cpu_peri_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .fw_name = "losc" },
> + { .hw = &pll_periph0_600M_clk.hw },
> + { .hw = &pll_periph0_480M_clk.common.hw },
> + { .hw = &pll_periph0_400M_clk.hw },
> +};
> +static SUNXI_CCU_M_DATA_WITH_MUX_GATE(gic_clk, "gic", gic_cpu_peri_parents, 0x560,
Do we really want to model the GIC clock? The A523 has one as well, as
we don't describe it there. And while the GICv3 binding describes a
clock property, the Linux driver completely ignores that.
So if I see this correctly, this clock would become unused, and would be
turned off, killing the GIC? So we would at least need a CLK_IS_CRITICAL
flag?
But it's a good reminder to lift this clock to something PLL based, in
U-Boot's SPL, because I guess the 24MHz are rather slow.
> + 0, 5, /* M */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_M_DATA_WITH_MUX_GATE(cpu_peri_clk, "cpu-peri", gic_cpu_peri_parents, 0x568,
What is this clock about? I don't see it referenced by any peripheral in
the manual.
> + 0, 5, /* M */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static const struct clk_parent_data nsi_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .hw = &pll_ddr_clk.common.hw },
> + { .hw = &pll_periph0_800M_clk.common.hw },
> + { .hw = &pll_periph0_600M_clk.hw },
> + { .hw = &pll_periph0_480M_clk.common.hw },
> + { .hw = &pll_de_3x_clk.common.hw },
> +};
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE_FEAT(nsi_clk, "nsi", nsi_parents, 0x580,
Similar question like for the GIC: do we need this in the kernel, and do
we need to prevent this from being turned off?
> + 0, 5, /* M */
> + 0, 0, /* no P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0, CCU_FEATURE_UPDATE_BIT);
> +
> +static const struct clk_parent_data mbus_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .hw = &pll_periph1_600M_clk.hw },
> + { .hw = &pll_ddr_clk.common.hw },
> + { .hw = &pll_periph1_480M_clk.common.hw },
> + { .hw = &pll_periph1_400M_clk.hw },
> + { .hw = &pll_npu_clk.common.hw },
> +};
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE_FEAT(mbus_clk, "mbus", mbus_parents, 0x588,
> + 0, 5, /* M */
> + 0, 0, /* no P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + CLK_IS_CRITICAL,
> + CCU_FEATURE_UPDATE_BIT);
> +
> /*
> * Contains all clocks that are controlled by a hardware register. They
> * have a (sunxi) .common member, which needs to be initialised by the common
> @@ -407,11 +519,21 @@ static struct ccu_common *sun60i_a733_ccu_clks[] = {
> &pll_de_clk.common,
> &pll_de_4x_clk.common,
> &pll_de_3x_clk.common,
> + &ahb_clk.common,
> + &apb0_clk.common,
> + &apb1_clk.common,
> + &apb_uart_clk.common,
> + &trace_clk.common,
> + &gic_clk.common,
> + &cpu_peri_clk.common,
> + &nsi_clk.common,
> + &mbus_clk.common,
> };
>
> static struct clk_hw_onecell_data sun60i_a733_hw_clks = {
> .hws = {
> [CLK_PLL_REF] = &pll_ref_clk.common.hw,
> + [CLK_SYS_24M] = &sys_24M_clk.hw,
> [CLK_PLL_DDR] = &pll_ddr_clk.common.hw,
> [CLK_PLL_PERIPH0_4X] = &pll_periph0_4x_clk.common.hw,
> [CLK_PLL_PERIPH0_2X] = &pll_periph0_2x_clk.common.hw,
> @@ -453,6 +575,15 @@ static struct clk_hw_onecell_data sun60i_a733_hw_clks = {
> [CLK_PLL_DE] = &pll_de_clk.common.hw,
> [CLK_PLL_DE_4X] = &pll_de_4x_clk.common.hw,
> [CLK_PLL_DE_3X] = &pll_de_3x_clk.common.hw,
> + [CLK_AHB] = &ahb_clk.common.hw,
> + [CLK_APB0] = &apb0_clk.common.hw,
> + [CLK_APB1] = &apb1_clk.common.hw,
> + [CLK_APB_UART] = &apb_uart_clk.common.hw,
> + [CLK_TRACE] = &trace_clk.common.hw,
> + [CLK_GIC] = &gic_clk.common.hw,
> + [CLK_CPU_PERI] = &cpu_peri_clk.common.hw,
> + [CLK_NSI] = &nsi_clk.common.hw,
> + [CLK_MBUS] = &mbus_clk.common.hw,
> },
> .num = CLK_FANOUT3 + 1,
> };
>
^ permalink raw reply
* [PATCH] i2c: mediatek: fix WRRD for SoCs without auto_restart option
From: Roman Vivchar via B4 Relay @ 2026-06-23 21:40 UTC (permalink / raw)
To: Qii Wang, Andi Shyti, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-i2c, linux-kernel, linux-arm-kernel, linux-mediatek,
Roman Vivchar
From: Roman Vivchar <rva333@protonmail.com>
MediaTek mt65xx family SoCs have no auto restart, however, they still
support the WRRD mode in the hardware. Because auto_restart is set to 0,
the WRRD mode will be never enabled, leading to read errors.
Fix this by removing auto_restart check from the WRRD enable path.
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
This is a preparation for the mt6572/6595 upstreaming.
mt65xx family SoCs don't have auto restart, but vendor kernels keep using
WRRD mode. Lack of the WRRD mode makes i2c reads impossible from both
userspace and kernel drivers.
Without patch (mt6595, da9210 buck at 0x68):
~ # i2cget -y 1 0x68 0x00
Error: Read failed
~ # i2cget -y 1 0x68 0x01
Error: Read failed
With patch:
~ # i2cget -y 1 0x68 0x00
0x80
~ # i2cget -y 1 0x68 0x01
0x00
Same behavior observed on mt6572 devices.
This change doesn't affect SoCs with auto restart option.
---
drivers/i2c/busses/i2c-mt65xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 126040ca05f1..307925fb78e3 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -1258,7 +1258,7 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
i2c->auto_restart = i2c->dev_comp->auto_restart;
/* checking if we can skip restart and optimize using WRRD mode */
- if (i2c->auto_restart && num == 2) {
+ if (num == 2) {
if (!(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
msgs[0].addr == msgs[1].addr) {
i2c->auto_restart = 0;
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260623-6572-6595-i2c-6ec9c4e6a6a6
Best regards,
--
Roman Vivchar <rva333@protonmail.com>
^ permalink raw reply related
* Re: [PATCH net v2] net: ti: icssg: Fix XSK zero copy TX during application wakeup
From: patchwork-bot+netdevbpf @ 2026-06-23 21:50 UTC (permalink / raw)
To: Meghana Malladi
Cc: diogo.ivo, vadim.fedorenko, haokexin, devnexen, horms,
jacob.e.keller, pabeni, kuba, edumazet, davem, andrew+netdev,
linux-kernel, netdev, linux-arm-kernel, srk, vigneshr, rogerq,
danishanwar
In-Reply-To: <20260618100348.2209907-1-m-malladi@ti.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 18 Jun 2026 15:33:48 +0530 you wrote:
> emac_xsk_xmit_zc() handles tx xmit for zero copy and gets called
> inside napi context. User application wakes up the kernel while
> initiating the transmit which triggers napi to start processing
> the tx packets. The num_tx check inside emac_tx_complete_packets()
> returns early if no packet transfer happen hindering the call
> to emac_xsk_xmit_zc(). Remove this check to let application
> wakeup initiate zero copy xmit traffic.
>
> [...]
Here is the summary with links:
- [net,v2] net: ti: icssg: Fix XSK zero copy TX during application wakeup
https://git.kernel.org/netdev/net/c/d95ea4bc09e8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v6 1/2] iio: dac: add mcf54415 DAC
From: Andy Shevchenko @ 2026-06-23 21:22 UTC (permalink / raw)
To: Angelo Dureghello
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Geert Uytterhoeven, Maxime Coquelin, Alexandre Torgue,
linux-kernel, linux-iio, linux-m68k, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260618-wip-stmark2-dac-v6-1-48761dbb96d7@baylibre.com>
On Thu, Jun 18, 2026 at 11:04:15PM +0200, Angelo Dureghello wrote:
> Add basic version of mcf54415 DAC driver. DAC is embedded in the SoC 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 12-bit on 16-bit word.
...
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
Is it used now?
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/types.h>
...
> + platform_set_drvdata(pdev, indio_dev);
Is it used?
...
Otherwise LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v6 0/2] add mcf54415 DAC driver
From: Andy Shevchenko @ 2026-06-23 21:18 UTC (permalink / raw)
To: Angelo Dureghello
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Geert Uytterhoeven, Maxime Coquelin, Alexandre Torgue,
linux-kernel, linux-iio, linux-m68k, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260618-wip-stmark2-dac-v6-0-48761dbb96d7@baylibre.com>
On Thu, Jun 18, 2026 at 11:04:14PM +0200, Angelo Dureghello wrote:
> This patchset adds a minimalistic DAC driver for the NXP mcf54415/6/7/8
> builtin 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 some 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.
Heard a presentation (Embedded Recipes IIRC) where one tried sine and real
sound (it was about sound DAC) was really awful. So, Can you try a bit more
sophisticated signal?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v5 6/6] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Alexander Sverdlin @ 2026-06-23 20:48 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans de Goede, Dmitry Torokhov, Andre Przywara, Jun Yan,
Lukas Schmid, J. Neuschäfer, Eric Biggers, Michal Simek,
Luca Weiss, Sven Peter, Maxime Ripard, devicetree, linux-kernel,
linux-input
In-Reply-To: <20260623204824.691832-1-alexander.sverdlin@gmail.com>
Baijie Helper A133 board is a development board around Baijie A133 Core
SBC. Features:
- 1/2/4GiB LPDDR4 DRAM
- 8/16/32GiB eMMC
- AXP707 PMIC
- USB-C OTG port in peripheral mode (via onboard hub)
- 2 USB 2.0 ports
- MicroSD slot and on-board eMMC module
- Gigabit Ethernet
- Bluetooth
- WiFi
Add initial support for both the Helper and Core boards, including UART,
PMU, eMMC, USB, Ethernet, LRADC-connected buttons.
UART1 can only be used for Bluetooth module, but BT-WiFi combo Allwinner
AW869A chip has no mainline driver currently.
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changelog:
v5:
- no changes
v4:
- renamed "sun50i-a133-baijie-helper.dtb" -> "sun50i-a133-helperboard.dtb"
- added "model" property into root of sun50i-a133-helperboard-core.dtsi
- added "cap-mmc-highspeed" and "max-frequency" into &mmc2
- added "x-powers,drive-vbus-en" and "*-supply" into &axp803
- dropped all "regulator-enable-ramp-delay" properties
- replaced ®_dcdc3 with a "polyphased" comment
- exact DRAM voltage in ®_dcdc5
- disabled ®_dcdc6 to avoid "[ 31.710641] dcdc6: disabling"
- added ®_vdd5v "root" regulator
- added "disable-wp" into &mmc0
- commented &usb_otg
- assigned usb1_vbus-supply in &usbphy
v3:
- added my copyrights into the newly introduced DTs
- all DT nodes sorted alphabetically
- all always-on regulators commented/propetly named
- all regulators got proper voltages (not default ranges)
- ADC-sensed buttons K1..K5 added
- re-labelled "eth_phy" -> "rgmii_phy"
- usbphy 0 switched from host into peripheral mode (downstream from an
onboard hub)
- typo sun50i-a133-baije-core.dtsi -> sun50i-a133-baijie-core.dtsi
v2:
- introduced baijie,helper-a133-core compatible for the Core (SoM) board
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../sun50i-a133-helperboard-core.dtsi | 197 ++++++++++++++++++
.../dts/allwinner/sun50i-a133-helperboard.dts | 148 +++++++++++++
3 files changed, 346 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a133-helperboard-core.dtsi
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a133-helperboard.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 53e6b701e7d3..aa21f58a4be1 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -24,6 +24,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h64-remix-mini-pc.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a133-helperboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a133-liontron-h-a133l.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus-v1.2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-helperboard-core.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a133-helperboard-core.dtsi
new file mode 100644
index 000000000000..545972d2324a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-helperboard-core.dtsi
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2025 Arm Ltd.
+ * Copyright (c) 2026 Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "sun50i-a100.dtsi"
+#include "sun50i-a100-cpu-opp.dtsi"
+
+/{
+ model = "Baijie A133 HelperBoard Core";
+ compatible = "baijie,helperboard-a133-core",
+ "allwinner,sun50i-a100";
+
+ aliases {
+ serial1 = &uart1; /* BT module */
+ };
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&lradc {
+ vref-supply = <®_aldo1>;
+};
+
+&mmc2 {
+ vmmc-supply = <®_dcdc1>;
+ vqmmc-supply = <®_eldo1>;
+ cap-mmc-highspeed;
+ cap-mmc-hw-reset;
+ max-frequency = <100000000>;
+ non-removable;
+ bus-width = <8>;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ status = "okay";
+};
+
+&pio {
+ vcc-pb-supply = <®_dcdc1>;
+ vcc-pc-supply = <®_eldo1>;
+ vcc-pd-supply = <®_dcdc1>;
+ vcc-pe-supply = <®_dldo2>;
+ vcc-pf-supply = <®_dcdc1>;
+ vcc-pg-supply = <®_dldo1>;
+ vcc-ph-supply = <®_dcdc1>;
+ /*
+ * PL0/PL1 are the I2C connection to PMIC, but it would create a
+ * circular dependency:
+ * vcc-pl-supply = <®_aldo3>;
+ */
+};
+
+&r_i2c0 {
+ status = "okay";
+
+ axp803: pmic@34 {
+ compatible = "x-powers,axp803";
+ reg = <0x34>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
+ aldoin-supply = <®_vdd5v>;
+ dldoin-supply = <®_vdd5v>;
+ eldoin-supply = <®_vdd5v>;
+ fldoin-supply = <®_dcdc5>;
+ vin1-supply = <®_vdd5v>;
+ vin2-supply = <®_vdd5v>;
+ vin3-supply = <®_vdd5v>;
+ vin4-supply = <®_vdd5v>;
+ vin5-supply = <®_vdd5v>;
+ vin6-supply = <®_vdd5v>;
+ drivevbus-supply = <®_vdd5v>;
+ };
+};
+
+#include "axp803.dtsi"
+
+&ac_power_supply {
+ status = "okay";
+};
+
+®_aldo1 {
+ /* PLL + LRADC analog reference */
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc-pll";
+};
+
+®_aldo2 {
+ /* LPDDR */
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vdd18-lpddr";
+};
+
+®_aldo3 {
+ /*
+ * Port L, but linking it to &pio node would create a circular
+ * dependency because of PL0/PL1 I2C connection to PMIC
+ */
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc-pl";
+};
+
+®_dcdc1 {
+ /* Besides Port D it also powers analog part of USB IP and SoC I/O */
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-3v3";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vdd-cpu";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+®_dcdc4 {
+ /* Digital part of USB IP, "System" SoC power rail */
+ regulator-always-on;
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <950000>;
+ regulator-name = "vdd-sys";
+};
+
+®_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vcc-dram";
+};
+
+/* DCDC6 unused */
+®_dcdc6 {
+ status = "disabled";
+};
+
+®_dldo1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc-pg";
+};
+
+®_dldo2 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc-pe";
+};
+
+®_dldo3 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "avdd-csi";
+};
+
+®_dldo4 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "afvcc-csi";
+};
+
+®_eldo1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc-pc";
+};
+
+®_eldo2 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "dvdd-csi";
+};
+
+/* ELDO3 unused */
+
+®_fldo1 {
+ /* CPUS power rail */
+ regulator-always-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-name = "vdd-cpus";
+};
+
+/* reg_drivevbus unused */
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-helperboard.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-helperboard.dts
new file mode 100644
index 000000000000..694c0cacf906
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-helperboard.dts
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2025 Arm Ltd.
+ * Copyright (c) 2026 Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "sun50i-a133-helperboard-core.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/leds/common.h>
+
+/{
+ model = "Baijie HelperBoard A133";
+ compatible = "baijie,helperboard-a133",
+ "baijie,helperboard-a133-core",
+ "allwinner,sun50i-a100";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led {
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&pio 7 13 GPIO_ACTIVE_LOW>; /* PH13 */
+ };
+ };
+
+ reg_vdd5v: vdd5v {
+ /* board wide 5V supply from a 12V->5V regulator */
+ compatible = "regulator-fixed";
+ regulator-name = "vdd-5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&emac0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii0_pins>;
+ phy-handle = <&rgmii_phy>;
+ phy-mode = "rgmii-id";
+ allwinner,rx-delay-ps = <200>;
+ allwinner,tx-delay-ps = <200>;
+ status = "okay";
+};
+
+&lradc {
+ wakeup-source;
+ status = "okay";
+
+ button-115 {
+ label = "K1";
+ linux,code = <KEY_1>;
+ channel = <0>;
+ voltage = <114607>;
+ };
+
+ button-235 {
+ label = "K2";
+ linux,code = <KEY_2>;
+ channel = <0>;
+ voltage = <234783>;
+ };
+
+ button-360 {
+ label = "K3";
+ linux,code = <KEY_3>;
+ channel = <0>;
+ voltage = <360000>;
+ };
+
+ button-476 {
+ label = "K4";
+ linux,code = <KEY_4>;
+ channel = <0>;
+ voltage = <476471>;
+ };
+
+ button-592 {
+ label = "K5";
+ linux,code = <KEY_5>;
+ channel = <0>;
+ voltage = <591946>;
+ };
+};
+
+&mdio0 {
+ reset-gpios = <&pio 7 11 GPIO_ACTIVE_LOW>; /* PH11 */
+ reset-delay-us = <10000>;
+ reset-post-delay-us = <150000>;
+
+ rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_dcdc1>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ bus-width = <4>;
+ disable-wp;
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&rgmii0_pins {
+ drive-strength = <30>;
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
+ status = "okay";
+};
+
+&usb_otg {
+ /*
+ * Connected to a downstream port of an onboard hub, therefore only
+ * "peripheral" mode will work here.
+ */
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&usbphy {
+ usb1_vbus-supply = <®_vdd5v>;
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v5 4/6] dt-bindings: input: sun4i-lradc-keys: Add A100/A133 compatible
From: Alexander Sverdlin @ 2026-06-23 20:48 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans de Goede, Dmitry Torokhov, Andre Przywara, Jun Yan,
Lukas Schmid, J. Neuschäfer, Eric Biggers, Michal Simek,
Luca Weiss, Sven Peter, Maxime Ripard, devicetree, linux-kernel,
linux-input
In-Reply-To: <20260623204824.691832-1-alexander.sverdlin@gmail.com>
The Allwinner A100/A133 SoCs have an LRADC which is compatible with the
versions in existing SoCs. Add a compatible string for A100, with the R329
fallback.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changelog:
v5:
- no changes
v4:
- new patch
.../bindings/input/allwinner,sun4i-a10-lradc-keys.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
index 6bdb8040be65..524c8b51f53f 100644
--- a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
+++ b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
@@ -23,6 +23,7 @@ properties:
- const: allwinner,sun50i-r329-lradc
- items:
- enum:
+ - allwinner,sun50i-a100-lradc
- allwinner,sun50i-h616-lradc
- allwinner,sun20i-d1-lradc
- const: allwinner,sun50i-r329-lradc
--
2.54.0
^ permalink raw reply related
* [PATCH v5 5/6] arm64: dts: allwinner: a100: Add LRADC node
From: Alexander Sverdlin @ 2026-06-23 20:48 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans de Goede, Dmitry Torokhov, Andre Przywara, Jun Yan,
Lukas Schmid, J. Neuschäfer, Eric Biggers, Michal Simek,
Luca Weiss, Sven Peter, Maxime Ripard, devicetree, linux-kernel,
linux-input
In-Reply-To: <20260623204824.691832-1-alexander.sverdlin@gmail.com>
A100/A133 SoCs feature a Low Rate ADC (LRADC) for Key application.
Specs:
- Power supply voltage: 1.8 V
- Reference voltage: 1.35 V
- Interrupt support
- Support Hold Key and General Key
- Support normal, continue and single work mode
- 6-bits resolution, sample rate up to 2 kHz
- Voltage input range between 0 and 1.35 V
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changelog:
v5:
- reflowed "compatible" property of lradc node
v4:
- added allwinner,sun50i-a100-lradc compatible
v3:
- new patch
arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
index b3fb1e0ee796..ba6020989ce9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
@@ -466,6 +466,16 @@ ths: thermal-sensor@5070400 {
#thermal-sensor-cells = <1>;
};
+ lradc: lradc@5070800 {
+ compatible = "allwinner,sun50i-a100-lradc",
+ "allwinner,sun50i-r329-lradc";
+ reg = <0x05070800 0x400>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_LRADC>;
+ resets = <&ccu RST_BUS_LRADC>;
+ status = "disabled";
+ };
+
usb_otg: usb@5100000 {
compatible = "allwinner,sun50i-a100-musb",
"allwinner,sun8i-a33-musb";
--
2.54.0
^ permalink raw reply related
* [PATCH v5 1/6] arm64: defconfig: Enable Allwinner LRADC input driver
From: Alexander Sverdlin @ 2026-06-23 20:48 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans de Goede, Dmitry Torokhov, Andre Przywara, Jun Yan,
Lukas Schmid, J. Neuschäfer, Eric Biggers, Michal Simek,
Luca Weiss, Sven Peter, Maxime Ripard, devicetree, linux-kernel,
linux-input
In-Reply-To: <20260623204824.691832-1-alexander.sverdlin@gmail.com>
Enable Allwinner LRADC input driver as module to support buttons on Baijie
HelperBoard A133.
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changelog:
v4-v5:
- no changes
v3:
- new patch
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 654a102cb5bc..c267f0906460 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -527,6 +527,7 @@ CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_GPIO_POLLED=m
CONFIG_KEYBOARD_SNVS_PWRKEY=m
CONFIG_KEYBOARD_IMX_SC_KEY=m
+CONFIG_KEYBOARD_SUN4I_LRADC=m
CONFIG_KEYBOARD_CROS_EC=y
CONFIG_KEYBOARD_MTK_PMIC=m
CONFIG_MOUSE_ELAN_I2C=m
--
2.54.0
^ 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