* Re: [PATCH net-next 1/2] net: ti: icssg: Derive stats array lengths from ARRAY_SIZE
From: MD Danish Anwar @ 2026-05-12 9:40 UTC (permalink / raw)
To: David CARLIER
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Roger Quadros,
Andrew Lunn, Jacob Keller, Meghana Malladi, Kevin Hao,
Vadim Fedorenko, netdev, linux-doc, linux-kernel,
linux-arm-kernel, Vignesh Raghavendra
In-Reply-To: <CA+XhMqykBWcMdk+iNnOtUxM4MX6jpDyUwfuAVZFbjAShO9_v7Q@mail.gmail.com>
Hi David,
On 12/05/26 1:28 pm, David CARLIER wrote:
> Hi MD,
>
> On Tue, 12 May 2026 at 07:06, MD Danish Anwar <danishanwar@ti.com> wrote:
>>
>> Replace the manually maintained ICSSG_NUM_MIIG_STATS and
>> ICSSG_NUM_PA_STATS constants with ARRAY_SIZE() expressions derived
>> directly from the corresponding stat descriptor arrays, so that adding
>> new entries to icssg_all_miig_stats[] or icssg_all_pa_stats[] no longer
>> requires a separate update to a numeric constant.
>>
>> To make this self-contained, break the circular include dependency
>> between icssg_stats.h and icssg_prueth.h:
>>
>> - icssg_stats.h previously included icssg_prueth.h (transitively
>> pulling in icssg_switch_map.h and ETH_GSTRING_LEN). Replace that
>> with direct includes of <linux/ethtool.h>, <linux/kernel.h> and
>> "icssg_switch_map.h".
>>
>> - icssg_prueth.h now includes icssg_stats.h, giving it access to
>> the ARRAY_SIZE-based ICSSG_NUM_MIIG_STATS and ICSSG_NUM_PA_STATS
>> before they are used in the prueth_emac struct and ICSSG_NUM_STATS.
>>
>> Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
>> ---
>> drivers/net/ethernet/ti/icssg/icssg_prueth.h | 3 +--
>> drivers/net/ethernet/ti/icssg/icssg_stats.h | 7 ++++++-
>> 2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.h b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
>> index df93d15c5b78..e2ccecb0a0dd 100644
>> --- a/drivers/net/ethernet/ti/icssg/icssg_prueth.h
>> +++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
>> @@ -43,6 +43,7 @@
>>
>> #include "icssg_config.h"
>> #include "icss_iep.h"
>> +#include "icssg_stats.h"
>> #include "icssg_switch_map.h"
>>
>> #define PRUETH_MAX_MTU (2000 - ETH_HLEN - ETH_FCS_LEN)
>> @@ -57,8 +58,6 @@
>>
>> #define ICSSG_MAX_RFLOWS 8 /* per slice */
>>
>> -#define ICSSG_NUM_PA_STATS 32
>> -#define ICSSG_NUM_MIIG_STATS 60
>> /* Number of ICSSG related stats */
>> #define ICSSG_NUM_STATS (ICSSG_NUM_MIIG_STATS + ICSSG_NUM_PA_STATS)
>> #define ICSSG_NUM_STANDARD_STATS 31
>> diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/net/ethernet/ti/icssg/icssg_stats.h
>> index 5ec0b38e0c67..b854eb587c1e 100644
>> --- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
>> +++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
>> @@ -8,10 +8,15 @@
>> #ifndef __NET_TI_ICSSG_STATS_H
>> #define __NET_TI_ICSSG_STATS_H
>>
>> -#include "icssg_prueth.h"
>> +#include <linux/ethtool.h>
>> +#include <linux/kernel.h>
>> +#include "icssg_switch_map.h"
>>
>> #define STATS_TIME_LIMIT_1G_MS 25000 /* 25 seconds @ 1G */
>>
>> +#define ICSSG_NUM_MIIG_STATS ARRAY_SIZE(icssg_all_miig_stats)
>> +#define ICSSG_NUM_PA_STATS ARRAY_SIZE(icssg_all_pa_stats)
>> +
>> struct miig_stats_regs {
>> /* Rx */
>> u32 rx_packets;
>> --
>> 2.34.1
>>
>
> One thing that caught my eye: icssg_all_miig_stats[] and
> icssg_all_pa_stats[] are 'static const' arrays in icssg_stats.h with
> ETH_GSTRING_LEN name buffers per entry. Right now only icssg_stats.c
> and icssg_ethtool.c pull them in. After this patch icssg_prueth.h
> includes icssg_stats.h, so every .c in the driver (classifier,
> common, config, mii_cfg, queues, switchdev, ...) ends up with its own
> static-const copy of both tables.
>
> Would a static_assert() work for what you're after? Something like:
>
While adding more stats manually, The ARRAY_SIZE() approach was
explicitly requested by maintainer [1]:
This patch is a direct response to that feedback. static_assert() would
still require updating the numeric constant on every array change. The
goal here is to eliminate the need of manually incrementing stats count
whenever new stats are added
Your concern about multiple copies of table is noted and valid. Could
you advise on the preferred way to reconcile these two requirements? I
am happy to restructure if there is an approach that satisfies both.
[1]
https://lore.kernel.org/all/20260112181436.4s5ceywwembn674r@skbuf/#:~:text=Can%27t%20this%20be%20expressed%20as%20ARRAY_SIZE(icssg_all_pa_stats)%3F%20It%20is%20very%0Afragile%20to%20have%20to%20count%20and%20update%20this%20manually.
> static const struct icssg_miig_stats icssg_all_miig_stats[] = {
> ...
> };
> static_assert(ARRAY_SIZE(icssg_all_miig_stats) == ICSSG_NUM_MIIG_STATS);
>
> next to each array, keeping the numeric #defines as-is. Then 2/2 fails
> to build the moment a new entry is added without bumping the count,
> which is the case you're guarding against — without touching the
> include graph.
>
> What do you think ?
>
> Cheers.
--
Thanks and Regards,
Danish
^ permalink raw reply
* Re: [PATCH v3 2/5] arm_mpam: resctrl: Pre-allocate assignable monitors
From: Ben Horgan @ 2026-05-12 9:43 UTC (permalink / raw)
To: Shaopeng Tan (Fujitsu)
Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com,
baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com,
dave.martin@arm.com, david@kernel.org, dfustini@baylibre.com,
fenghuay@nvidia.com, gshan@redhat.com, james.morse@arm.com,
jonathan.cameron@huawei.com, kobak@nvidia.com,
lcherian@marvell.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, peternewman@google.com,
punit.agrawal@oss.qualcomm.com, quic_jiles@quicinc.com,
reinette.chatre@intel.com, rohit.mathew@arm.com,
scott@os.amperecomputing.com, sdonthineni@nvidia.com,
xhao@linux.alibaba.com, zengheng4@huawei.com, x86@kernel.org
In-Reply-To: <TY4PR01MB1693081CFF2DCB47DA4C2F9C38B392@TY4PR01MB16930.jpnprd01.prod.outlook.com>
Hi Shaopeng,
Thanks for the quick review.
On 5/12/26 08:16, Shaopeng Tan (Fujitsu) wrote:
> Hello Ben,
>
>
>> MPAM is able to emulate ABMC, i.e. mbm_event mode, by making memory
>> bandwidth monitors assignable. Rather than supporting the 'default'
>> mbm_assign_mode always use 'mbm_event' mode even if there are sufficient
>> memory bandwidth monitors. The per monitor event configuration is only
>> provided by resctrl when in 'mbm_event' mode and so only allowing
>> 'mbm_event' mode will make it easier to support per-monitor event
>> configuration for MPAM. For the moment, the only event supported is
>> mbm_total_event with no bandwidth type configuration. The 'mbm_assign_mode'
>> file will still show 'default' when there is no support for memory
>> bandwidth monitoring.
>>
>> The monitors need to be allocated from the driver, and mapped to whichever
>> control/monitor group resctrl wants to use them with.
>>
>> Add a second array to hold the monitor values indexed by resctrl's cntr_id.
>>
>> When CDP is in use, two monitors are needed so the available number of
>> counters halves. Platforms with one monitor will have zero monitors when
>> CDP is in use.
>>
>> Co-developed-by: James Morse <james.morse@arm.com>
>> Signed-off-by: James Morse <james.morse@arm.com>
>> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
>> ---
>> Changes since rfc v1:
>> abmc enabled even if enough counters
>> Helpers from dropped free running commits
>> carry on with zero counters if using cdp
>> set config bits
>> use kmalloc_objs
>> drop tags for rework
>> Configure mbm_cntr_configurable, mbm_cntr_assign_fixed
>>
>> Changes since rfc v2:
>> Don't set mon->assigned_counters to an error pointer
>> Fix mpam_resctrl_teardown_mon()
>> Remove free running check
>> Separate cleanup allocations, e.g. __free(), from the rest
>> Restrict scope on err in mpam_resctrl_monitor_init()
>> ---
>> drivers/resctrl/mpam_internal.h | 6 +-
>> drivers/resctrl/mpam_resctrl.c | 138 +++++++++++++++++++++++++++++++-
>> 2 files changed, 140 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h
>> index 1914aefdcba9..7a166b395b5a 100644
>> --- a/drivers/resctrl/mpam_internal.h
>> +++ b/drivers/resctrl/mpam_internal.h
>> @@ -411,7 +411,11 @@ struct mpam_resctrl_res {
>> struct mpam_resctrl_mon {
>> struct mpam_class *class;
>>
>> - /* per-class data that resctrl needs will live here */
>> + /* Array of allocated MBWU monitors, indexed by (closid, rmid). */
>> + int *mbwu_idx_to_mon;
>> +
>> + /* Array of assigned MBWU monitors, indexed by idx argument. */
>> + int *assigned_counters;
>> };
>>
>> static inline int mpam_alloc_csu_mon(struct mpam_class *class)
>> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
>> index f70fa65d39e4..cba295621f56 100644
>> --- a/drivers/resctrl/mpam_resctrl.c
>> +++ b/drivers/resctrl/mpam_resctrl.c
>> @@ -75,6 +75,8 @@ static DECLARE_WAIT_QUEUE_HEAD(wait_cacheinfo_ready);
>> */
>> static bool resctrl_enabled;
>>
>> +static unsigned int l3_num_allocated_mbwu = ~0;
>> +
>> bool resctrl_arch_alloc_capable(void)
>> {
>> struct mpam_resctrl_res *res;
>> @@ -140,7 +142,7 @@ int resctrl_arch_cntr_read(struct rdt_resource *r, struct rdt_l3_mon_domain *d,
>>
>> bool resctrl_arch_mbm_cntr_assign_enabled(struct rdt_resource *r)
>> {
>> - return false;
>> + return (r == &mpam_resctrl_controls[RDT_RESOURCE_L3].resctrl_res);
>> }
>>
>> int resctrl_arch_mbm_cntr_assign_set(struct rdt_resource *r, bool enable)
>> @@ -185,6 +187,22 @@ static void resctrl_reset_task_closids(void)
>> read_unlock(&tasklist_lock);
>> }
>>
>> +static void mpam_resctrl_monitor_sync_abmc_vals(struct rdt_resource *l3)
>> +{
>> + l3->mon.num_mbm_cntrs = l3_num_allocated_mbwu;
>> + if (cdp_enabled)
>> + l3->mon.num_mbm_cntrs /= 2;
>> +
>> + /*
>> + * Continue as normal even if there are zero counters to avoid giving
>> + * resctrl mixed messages.
>> + */
>> + l3->mon.mbm_cntr_assignable = true;
>> + l3->mon.mbm_assign_on_mkdir = true;
>> + l3->mon.mbm_cntr_configurable = false;
>> + l3->mon.mbm_cntr_assign_fixed = true;
>> +}
>> +
>> int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
>> {
>> u32 partid_i = RESCTRL_RESERVED_CLOSID, partid_d = RESCTRL_RESERVED_CLOSID;
>> @@ -244,6 +262,7 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
>> WRITE_ONCE(arm64_mpam_global_default, mpam_get_regval(current));
>>
>> resctrl_reset_task_closids();
>> + mpam_resctrl_monitor_sync_abmc_vals(l3);
>>
>> for_each_possible_cpu(cpu)
>> mpam_set_cpu_defaults(cpu, partid_d, partid_i, 0, 0);
>> @@ -613,6 +632,9 @@ static bool class_has_usable_mbwu(struct mpam_class *class)
>> if (!mpam_has_feature(mpam_feat_msmon_mbwu, cprops))
>> return false;
>>
>> + if (!cprops->num_mbwu_mon)
>> + return false;
>> +
>> return true;
>> }
>>
>> @@ -935,6 +957,52 @@ static void mpam_resctrl_pick_mba(void)
>> }
>> }
>>
>> +static void __free_mbwu_mon(struct mpam_class *class, int *array,
>> + u16 num_mbwu_mon)
>> +{
>> + for (int i = 0; i < num_mbwu_mon; i++) {
>> + if (array[i] < 0)
>> + continue;
>> +
>> + mpam_free_mbwu_mon(class, array[i]);
>> + array[i] = ~0;
>> + }
>> +}
>> +
>> +static int __alloc_mbwu_mon(struct mpam_class *class, int *array,
>> + u16 num_mbwu_mon)
>> +{
>> + for (int i = 0; i < num_mbwu_mon; i++) {
>> + int mbwu_mon = mpam_alloc_mbwu_mon(class);
>> +
>> + if (mbwu_mon < 0) {
>> + __free_mbwu_mon(class, array, num_mbwu_mon);
>> + return mbwu_mon;
>> + }
>> + array[i] = mbwu_mon;
>> + }
>> +
>> + l3_num_allocated_mbwu = min(l3_num_allocated_mbwu, num_mbwu_mon);
>> +
>> + return 0;
>> +}
>> +
>> +static int *__alloc_mbwu_array(struct mpam_class *class, u16 num_mbwu_mon)
>> +{
>> + int err;
>> +
>> + int *array __free(kfree) = kmalloc_objs(*array, num_mbwu_mon);
>> + if (!array)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + memset(array, -1, num_mbwu_mon * sizeof(*array));
>> +
>> + err = __alloc_mbwu_mon(class, array, num_mbwu_mon);
>> + if (err)
>> + return ERR_PTR(err);
>> + return_ptr(array);
>> +}
>> +
>> static void counter_update_class(enum resctrl_event_id evt_id,
>> struct mpam_class *class)
>> {
>> @@ -1089,6 +1157,38 @@ static int mpam_resctrl_pick_domain_id(int cpu, struct mpam_component *comp)
>> return comp->comp_id;
>> }
>>
>> +/*
>> + * This must run after all event counters have been picked so that any free
>> + * running counters have already been allocated.
>> + */
>> +static int mpam_resctrl_monitor_init_abmc(struct mpam_resctrl_mon *mon)
>> +{
>> + struct mpam_resctrl_res *res = &mpam_resctrl_controls[RDT_RESOURCE_L3];
>> + struct rdt_resource *l3 = &res->resctrl_res;
>> + struct mpam_class *class = mon->class;
>> + u16 num_mbwu_mon;
>> + size_t num_rmid = resctrl_arch_system_num_rmid_idx();
>> + int *cntrs;
>
> Wouldn't a reverse tree format be better?
Do you mean just moving the num_rmid line up? If so, yes, that is a bit neater.
struct mpam_resctrl_res *res = &mpam_resctrl_controls[RDT_RESOURCE_L3];
size_t num_rmid = resctrl_arch_system_num_rmid_idx();
struct rdt_resource *l3 = &res->resctrl_res;
struct mpam_class *class = mon->class;
u16 num_mbwu_mon;
int *cntrs;
>
>> + int *rmid_array __free(kfree) = kmalloc_objs(*rmid_array, num_rmid);
>> + if (!rmid_array) {
>> + pr_debug("Failed to allocate RMID array\n");
>> + return -ENOMEM;
>> + }
>> + memset(rmid_array, -1, num_rmid * sizeof(*rmid_array));
>> +
>> + num_mbwu_mon = class->props.num_mbwu_mon;
>> + cntrs = __alloc_mbwu_array(mon->class, num_mbwu_mon);
>> + if (IS_ERR(cntrs))
>> + return PTR_ERR(cntrs);
>> + mon->assigned_counters = cntrs;
>> + mon->mbwu_idx_to_mon = no_free_ptr(rmid_array);
>> +
>> + mpam_resctrl_monitor_sync_abmc_vals(l3);
>> +
>> + return 0;
>> +}
>> +
>> static int mpam_resctrl_monitor_init(struct mpam_resctrl_mon *mon,
>> enum resctrl_event_id type)
>> {
>> @@ -1133,8 +1233,21 @@ static int mpam_resctrl_monitor_init(struct mpam_resctrl_mon *mon,
>> */
>> l3->mon.num_rmid = resctrl_arch_system_num_rmid_idx();
>>
>> - if (resctrl_enable_mon_event(type, false, 0, NULL))
>> - l3->mon_capable = true;
>> + if (type == QOS_L3_MBM_TOTAL_EVENT_ID) {
>> + int err;
>> +
>> + err = mpam_resctrl_monitor_init_abmc(mon);
>> + if (err)
>> + return err;
>> +
>> + static_assert(MAX_EVT_CONFIG_BITS == 0x7f);
>> + l3->mon.mbm_cfg_mask = MAX_EVT_CONFIG_BITS;
>> + }
>> +
>> + if (!resctrl_enable_mon_event(type, false, 0, NULL))
>> + return -EINVAL;
>> +
>> + l3->mon_capable = true;
>>
>> return 0;
>> }
>> @@ -1697,6 +1810,23 @@ void mpam_resctrl_exit(void)
>> resctrl_exit();
>> }
>>
>> +static void mpam_resctrl_teardown_mon(struct mpam_resctrl_mon *mon, struct mpam_class *class)
>> +{
>> + u32 num_mbwu_mon = l3_num_allocated_mbwu;
>> +
>> + if (mon->mbwu_idx_to_mon)
>> + return;
>
> Isn't it 'if (mon->mbwu_idx_to_mon == NULL)' ?
Oops... indeed.
Thanks,
Ben
>
>
> Best regards,
> Shaopeng TAN
>
>> + if (mon->assigned_counters) {
>> + __free_mbwu_mon(class, mon->assigned_counters, num_mbwu_mon);
>> + kfree(mon->assigned_counters);
>> + mon->assigned_counters = NULL;
>> + }
>> +
>> + kfree(mon->mbwu_idx_to_mon);
>> + mon->mbwu_idx_to_mon = NULL;
>> +}
>> +
>> /*
>> * The driver is detaching an MSC from this class, if resctrl was using it,
>> * pull on resctrl_exit().
>> @@ -1719,6 +1849,8 @@ void mpam_resctrl_teardown_class(struct mpam_class *class)
>> for_each_mpam_resctrl_mon(mon, eventid) {
>> if (mon->class == class) {
>> mon->class = NULL;
>> +
>> + mpam_resctrl_teardown_mon(mon, class);
>> break;
>> }
>> }
>> --
>> 2.43.0
^ permalink raw reply
* Re: [PATCH 1/4] remoteproc: add common wc-ioremap carveout callbacks
From: Arnaud POULIQUEN @ 2026-05-12 9:44 UTC (permalink / raw)
To: Ben Levinsky, Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <20260511211841.284809-2-ben.levinsky@amd.com>
On 5/11/26 23:18, Ben Levinsky wrote:
> Several remoteproc drivers open-code the same ioremap_wc() and
> iounmap() callbacks for carveout mappings. Add subsystem-private
> helpers in remoteproc_internal.h so those drivers can share the same
> implementation.
>
> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
> ---
> drivers/remoteproc/remoteproc_internal.h | 26 +++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
> index 0a5e15744b1d..3724a47a9748 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -12,8 +12,9 @@
> #ifndef REMOTEPROC_INTERNAL_H
> #define REMOTEPROC_INTERNAL_H
>
> -#include <linux/irqreturn.h>
> #include <linux/firmware.h>
> +#include <linux/io.h>
> +#include <linux/irqreturn.h>
>
> struct rproc;
>
> @@ -122,6 +123,29 @@ rproc_find_carveout_by_name(struct rproc *rproc, const char *name, ...);
> void rproc_add_rvdev(struct rproc *rproc, struct rproc_vdev *rvdev);
> void rproc_remove_rvdev(struct rproc_vdev *rvdev);
>
> +static inline int rproc_mem_entry_ioremap_wc(struct rproc *rproc,
> + struct rproc_mem_entry *mem)
> +{
> + void __iomem *va;
> +
> + va = ioremap_wc(mem->dma, mem->len);
> + if (!va)
> + return -ENOMEM;
Could you add error message here to help for debug
+ dev_err(dev, "Unable to map memory region: %pa+%zx\n",
+ &mem->dma, mem->len);
> +
> + mem->va = (__force void *)va;
> + mem->is_iomem = true;
HHere, you set mem->is_iomem, but this is not done in platform drivers.
It seems better to add this in a separate commit after patch 2/4, with
an explanation of why it needs to be set.
Regards,
Arnaud
> +
> + return 0;
> +}
> +
> +static inline int rproc_mem_entry_iounmap(struct rproc *rproc,
> + struct rproc_mem_entry *mem)
> +{
> + iounmap((__force __iomem void *)mem->va);
> +
> + return 0;
> +}
> +
> static inline int rproc_prepare_device(struct rproc *rproc)
> {
> if (rproc->ops->prepare)
^ permalink raw reply
* Re: cleanup the RAID6 P/Q library v2
From: Ard Biesheuvel @ 2026-05-12 9:50 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Morton
Cc: Catalin Marinas, Will Deacon, Huacai Chen, WANG Xuerui,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H . Peter Anvin, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260512052230.2947683-1-hch@lst.de>
On Tue, 12 May 2026, at 07:20, Christoph Hellwig wrote:
> Hi all,
>
> this series cleans up the RAID6 P/Q library to match the recent updates
> to the RAID 5 XOR library and other CRC/crypto libraries. This includes
> providing properly documented external interfaces, hiding the internals,
> using static_call instead of indirect calls and turning the user space
> test suite into an in-kernel kunit test which is also extended to
> improve coverage.
>
> Note that this changes registration so that non-priority algorithms are
> not registered, which greatly helps with the benchmark time at boot time.
> I'd like to encourage all architecture maintainers to see if they can
> further optimized this by registering as few as possible algorithms when
> there is a clear benefit in optimized or more unrolled implementations.
>
> This series sits on top of the "cleanup the RAID5 XOR library v3" series.
>
> A git tree is also available here:
>
> git://git.infradead.org/users/hch/misc.git lib-raid6
>
> Gitweb:
>
>
> https://git.infradead.org/?p=users/hch/misc.git;a=shortlog;h=refs/heads/lib-raid6
>
> Changes since v1:
> - fix arm64 objdir != srcdir builds
> - call the kunit module raid6_kunit.ko from the beginning
> - update MAINTAINERS
> - don't require preemptible context and apply the same restrictions as
> the merged version of the XOR API
> - fix the arm64 default in Kconfig
> - pick the last registered (and presumably most optimized) algorithm when
> benchmarking is disabled
> - port over the randomization fixes from the XOR series
> - misc other kunit cleanups
> - require at least 4 devices for RAID6 to skip broken special cases
>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # kunit only on arm64
Acked-by: Ard Biesheuvel <ardb@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 3/3] usb: dwc3: imx8mp: disable auto suspend for host role
From: Xu Yang @ 2026-05-12 9:53 UTC (permalink / raw)
To: Franz Schnyder
Cc: Thinh.Nguyen, gregkh, shawnguo, s.hauer, kernel, festevam,
linux-usb, linux-kernel, imx, linux-arm-kernel, jun.li,
Francesco Dolcini
In-Reply-To: <hsyy2owzbt7tsljktlrz5g4bnrnecznvcyy6zxt7gfyxb4xvgi@ysko6xe6h2zm>
On Fri, May 08, 2026 at 06:04:49PM +0200, Franz Schnyder wrote:
> Hi Xu,
>
> On Fri, May 08, 2026 at 06:54:40PM +0800, Xu Yang wrote:
> > It's strange that link->status is not DL_STATE_DORMANT or DL_STATE_NONE at
> > the time which means the device core may not properly unbind consumer devices
> > or handle something. The patch does a simple thing so the issue may not come
> > from the patch itself.
> >
> > 1639: list_for_each_entry_safe_reverse(link, ln, &dev->links.consumers, s_node) {
> > 1640: WARN_ON(link->status != DL_STATE_DORMANT &&
> > 1641: link->status != DL_STATE_NONE);
> > 1642: __device_link_del(&link->kref);
> > 1643: }
> >
> > Which kernel and dtb are you using? If it's a downstream repo, how do the USB
> > controller and related DTS nodes look like?
>
> I was using kernel version 7.1-rc2 and noticed it while working on
> sending the Aquila iMX95 upstream.
> https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-2-69c8ee1c5413@toradex.com/
I don't see any special configuration in your DTS. I modified my configuration
to match yours, but I can't reproduce the issue. I also created some fault points
during the probe process, but still didn't encounter the issue.
> >
> > Does the issue easily happen? Does dwc3_imx8mp_probe() eventually succeed?
>
> I did various boot attempts with the commit reverted and couldn't
> reproduce the issue. With the commit I ran into the issue in about one
> third of all boot attempts. So most of the time dwc3_imx8mp_prove
> actually succeeds.
OK. I mean, does dwc3_imx8mp_probe() still succeed after the kernel dumps
at the end?
>
> >
> > Could you add "#define DEBUG" in the head of drivers/base/core.c, rerun and share the log?
> >
> I can provide you with the data next week.
OK. More debug information will be helpful.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH v3 10/20] drm/plane: Add new atomic_create_state callback
From: Maxime Ripard @ 2026-05-12 9:55 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260504165229.GM1344263@killaraus.ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]
Hi,
On Mon, May 04, 2026 at 07:52:29PM +0300, Laurent Pinchart wrote:
> On Fri, Apr 24, 2026 at 12:18:50PM +0200, Maxime Ripard wrote:
> > Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> > to drm_private_obj") introduced a new pattern for allocating drm object
> > states.
> >
> > Instead of relying on the reset() callback, it created a new
> > atomic_create_state hook. This is helpful because reset is a bit
> > overloaded: it's used to create the initial software state, reset it,
> > but also reset the hardware.
> >
> > It can also be used either at probe time, to create the initial state
> > and possibly reset the hardware to an expected default, but also during
> > suspend/resume.
> >
> > Both these cases come with different expectations too: during the
> > initialization, we want to initialize all states, but during
> > suspend/resume, drm_private_states for example are expected to be kept
> > around.
> >
> > reset() also isn't fallible, which makes it harder to handle
> > initialization errors properly. This is only really relevant for some
> > drivers though, since all the helpers for reset only create a new
> > state, and don't touch the hardware at all.
> >
> > It was thus decided to create a new hook that would allocate and
> > initialize a pristine state without any side effect:
> > atomic_create_state to untangle a bit some of it, and to separate the
> > initialization with the actual reset one might need during a
> > suspend/resume.
> >
> > Continue the transition to the new pattern with planes.
> >
> > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > ---
> > drivers/gpu/drm/drm_atomic_state_helper.c | 25 +++++++++++++++++++++++++
> > drivers/gpu/drm/drm_mode_config.c | 21 ++++++++++++++++++++-
> > include/drm/drm_atomic_state_helper.h | 2 ++
> > include/drm/drm_plane.h | 16 ++++++++++++++++
> > 4 files changed, 63 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 285efbf29520..50fe4eec41a8 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -338,10 +338,35 @@ void drm_atomic_helper_plane_reset(struct drm_plane *plane)
> > if (plane->state)
> > __drm_atomic_helper_plane_reset(plane, plane->state);
> > }
> > EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
> >
> > +/**
> > + * drm_atomic_helper_plane_create_state - default &drm_plane_funcs.atomic_create_state hook for planes
>
> drm_atomic_helper_colorop_create_state() states "Allocates and
> initializes colorop atomic state", while here you document it as
> "default hook for planes". Consistency would be good.
I don't think it's inconsistent?
colorops don't have a create_state callback, so the only function to
create it is defined as "Allocates and initializes colorop atomic
state". For planes, the hook is documented as "Allocates a pristine,
initialized, state for the plane object and returns it.", and here we
have the default implementation for that hook, which is documented as
such.
It all seems consistent to me?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v4 00/13] net: lan966x: add support for PCIe FDMA
From: Daniel Machon @ 2026-05-12 9:56 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260511192018.49dfcd7b@kernel.org>
> On Fri, 8 May 2026 09:35:24 +0200 Daniel Machon wrote:
> > When lan966x operates as a PCIe endpoint, the driver currently uses
> > register-based I/O for frame injection and extraction. This approach is
> > functional but slow, topping out at around 33 Mbps on an Intel x86 host
> > with a lan966x PCIe card.
>
> Looks like sashiko-bot responded but only CCed bpf@
> Please let us know if all the issues are false positives,
> I'm going to assume for now that at least one of the issues
> is real :)
I ran through all the issues from sashiko-gemini (sashiko-nipa only reported low
severity issues).
Most of them are false-positives, some are pre-existing and some are purely
theoretical. I have experimented a little with fixing some of the theoretical,
but subsequent local sashiko runs seem to just find new ones indefinitely ;)
IMHO, like Paolo commented on v3, I think these can safely be postponed to
future follow-ups, if need be.
Let me know what you think.
/Daniel
^ permalink raw reply
* [PATCH v4 03/10] arm64: dts: rockchip: Add missing hclk for RK3588 eDP0
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Add the required HCLK_VO1 bus clock to RK3588 eDP0 node with
corresponding clock-name "hclk". This clock is necessary for the
eDP controller to access video output GRF and work properly.
Previously the clock was enabled implicitly via GRF phandle
reference. Add it explicitly now to align with updated binding.
Fixes: dc79d3d5e7c7 ("arm64: dts: rockchip: Add eDP0 node for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index 4fb8888c281c..24a5ccbac08c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -1712,8 +1712,8 @@ hdmi0_out: port@1 {
edp0: edp@fdec0000 {
compatible = "rockchip,rk3588-edp";
reg = <0x0 0xfdec0000 0x0 0x1000>;
- clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>;
- clock-names = "dp", "pclk";
+ clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>, <&cru HCLK_VO1>;
+ clock-names = "dp", "pclk", "hclk";
interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH 0>;
phys = <&hdptxphy0>;
phy-names = "dp";
--
2.34.1
^ permalink raw reply related
* [PATCH v4 02/10] dt-bindings: display: rockchip: analogix-dp: Add per-clock descriptions
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Supplement dedicated description for each clock in the clocks
property, clarifying the function of each clock input for the
Analogix DP controller binding.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index d2bc8636b626..0651853a7a5d 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -19,7 +19,10 @@ properties:
clocks:
minItems: 2
- maxItems: 3
+ items:
+ - description: Reference clock
+ - description: APB bus clock
+ - description: GRF or AHB bus clock
clock-names:
minItems: 2
--
2.34.1
^ permalink raw reply related
* [PATCH v4 00/10] Add eDP support for RK3576
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
Patch 1-5 are to add missing clock "hclk" for RK3588 eDP nodes.
Patch 6-7 are to add the RK3576 eDP node.
Patch 8~10 are to support the RK3576 Analogix DP controller.
This series is followed by the [0] series.
[0] https://lore.kernel.org/all/20260409065301.446670-1-damon.ding@rock-chips.com/
Damon Ding (10):
dt-bindings: display: rockchip: analogix-dp: Allow hclk as third clock
dt-bindings: display: rockchip: analogix-dp: Add per-clock
descriptions
arm64: dts: rockchip: Add missing hclk for RK3588 eDP0
arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
drm/rockchip: analogix_dp: Enable hclk for RK3588
dt-bindings: display: rockchip: analogix-dp: Add support for RK3576
arm64: dts: rockchip: Add eDP node for RK3576
drm/bridge: analogix_dp: Rename and simplify is_rockchip()
drm/bridge: analogix_dp: Add support for RK3576
drm/rockchip: analogix_dp: Add support for RK3576
.../rockchip/rockchip,analogix-dp.yaml | 11 ++++++--
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 28 +++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 +--
.../arm64/boot/dts/rockchip/rk3588-extra.dtsi | 4 +--
.../drm/bridge/analogix/analogix_dp_core.c | 3 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 ++++++------
.../gpu/drm/rockchip/analogix_dp-rockchip.c | 15 ++++++++++
include/drm/bridge/analogix_dp.h | 13 +++++++--
8 files changed, 78 insertions(+), 18 deletions(-)
---
Changes in v2:
- Split out separate patches to add the "hclk" clock reference.
- Split out separate patches to enable the "hclk" clock.
- Add Reviewed-by tag.
Changes in v3:
- Add a patch to expand descriptions for clocks of the eDP node.
- Add Reviewed-by tag.
Changes in v4:
- Modify commit msg.
--
2.34.1
^ permalink raw reply
* [PATCH v4 01/10] dt-bindings: display: rockchip: analogix-dp: Allow hclk as third clock
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
RK3588 eDP controller requires HCLK_VO1 (video output bus clock)
to access the VO1 GRF registers and enable the video datapath.
Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
phandle reference, which allowed the eDP to work without explicitly
managing the hclk_vo1 clock. However, this is not safe or explicit.
To align with other display controllers (HDMI) on RK3588 and make
the clock requirement explicit, expand clock-names to support either
"grf" (for older SoCs) or "hclk" (for RK3588) as the third clock.
This makes the clock dependency clear and removes reliance on implicit
clock enablement from GRF phandle.
Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index d99b23b88cc5..d2bc8636b626 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -26,7 +26,9 @@ properties:
items:
- const: dp
- const: pclk
- - const: grf
+ - enum:
+ - grf
+ - hclk
power-domains:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH v4 06/10] dt-bindings: display: rockchip: analogix-dp: Add support for RK3576
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
RK3576 integrates an eDP TX controller compatible with the existing
RK3588 hardware design, reuse the same binding configuration directly.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v2:
- Split out a separate patch to add the "hclk" clock reference.
Chanegs in v4:
- Modify the commit msg.
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index 0651853a7a5d..7568044a5b2f 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -15,6 +15,7 @@ properties:
enum:
- rockchip,rk3288-dp
- rockchip,rk3399-edp
+ - rockchip,rk3576-edp
- rockchip,rk3588-edp
clocks:
@@ -70,6 +71,7 @@ allOf:
compatible:
contains:
enum:
+ - rockchip,rk3576-edp
- rockchip,rk3588-edp
then:
properties:
--
2.34.1
^ permalink raw reply related
* [PATCH v4 05/10] drm/rockchip: analogix_dp: Enable hclk for RK3588
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Acquire and enable the HCLK_VO1 bus clock explicitly for RK3588
eDP controller to guarantee register and datapath access.
The clock was previously enabled implicitly via rockchip,vo-grf
phandle reference, which relies on side effect and is fragile.
Fetch optional "hclk" clock in driver to align with updated device
tree binding and keep consistent with hardware clock dependency.
Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 41ff44eaf44d..a864bcf8200e 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -311,6 +311,7 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
{
struct device *dev = dp->dev;
struct device_node *np = dev->of_node;
+ struct clk *clk;
dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(dp->grf))
@@ -327,6 +328,11 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
return dev_err_probe(dev, PTR_ERR(dp->pclk),
"failed to get pclk property\n");
+ clk = devm_clk_get_optional_enabled(dev, "hclk");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk),
+ "failed to get hclk property\n");
+
dp->rst = devm_reset_control_get(dev, "dp");
if (IS_ERR(dp->rst))
return dev_err_probe(dev, PTR_ERR(dp->rst),
--
2.34.1
^ permalink raw reply related
* [PATCH v4 08/10] drm/bridge: analogix_dp: Rename and simplify is_rockchip()
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Rename inline helper is_rockchip() to analogix_dp_is_rockchip()
to follow driver namespace convention consistently across code.
Replace chained equality comparisons with switch-case layout
to improve readability and simplify adding new SoC entries later.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Suggested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
.../gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 +++++++++---------
include/drm/bridge/analogix_dp.h | 11 +++++++++--
3 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 3e46350170d4..d45c81c1d77a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -870,7 +870,7 @@ static int analogix_dp_bridge_atomic_check(struct drm_bridge *bridge,
struct drm_display_info *di = &conn_state->connector->display_info;
u32 mask = BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) | BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422);
- if (is_rockchip(dp->plat_data->dev_type)) {
+ if (analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
if ((di->color_formats & mask)) {
DRM_DEBUG_KMS("Swapping display color format from YUV to RGB\n");
di->color_formats &= ~mask;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 38fd8d5014d2..6207ded7ffd5 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -72,7 +72,7 @@ void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
reg = REF_CLK_24M;
if (dp->plat_data->dev_type == RK3288_DP)
reg ^= REF_CLK_MASK;
@@ -123,7 +123,7 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
analogix_dp_stop_video(dp);
analogix_dp_enable_video_mute(dp, 0);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
SW_FUNC_EN_N;
else
@@ -233,7 +233,7 @@ void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool enable)
u32 mask = DP_PLL_PD;
u32 pd_addr = ANALOGIX_DP_PLL_CTL;
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
pd_addr = ANALOGIX_DP_PD;
mask = RK_PLL_PD;
}
@@ -254,12 +254,12 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
u32 mask;
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
mask = RK_AUX_PD;
else
mask = AUX_PD;
@@ -317,7 +317,7 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
* to power off everything instead of DP_PHY_PD in
* Rockchip
*/
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
mask = DP_INC_BG;
else
mask = DP_PHY_PD;
@@ -329,7 +329,7 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
reg &= ~mask;
writel(reg, dp->reg_base + phy_pd_addr);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
usleep_range(10, 15);
break;
case POWER_ALL:
@@ -465,7 +465,7 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
analogix_dp_reset_aux(dp);
/* AUX_BIT_PERIOD_EXPECTED_DELAY doesn't apply to Rockchip IP */
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
reg = 0;
else
reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3);
@@ -837,7 +837,7 @@ void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp)
u32 reg;
reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
} else {
reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 854af692229b..7b670dd769e9 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -19,9 +19,16 @@ enum analogix_dp_devtype {
RK3588_EDP,
};
-static inline bool is_rockchip(enum analogix_dp_devtype type)
+static inline bool analogix_dp_is_rockchip(enum analogix_dp_devtype type)
{
- return type == RK3288_DP || type == RK3399_EDP || type == RK3588_EDP;
+ switch (type) {
+ case RK3288_DP:
+ case RK3399_EDP:
+ case RK3588_EDP:
+ return true;
+ default:
+ return false;
+ }
}
struct analogix_dp_plat_data {
--
2.34.1
^ permalink raw reply related
* [PATCH v4 09/10] drm/bridge: analogix_dp: Add support for RK3576
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Add RK3576_EDP device type entry and extend Rockchip check
to match existing hardware capabilities shared with RK3588.
Set identical maximum link rate and lane count parameters
for RK3576 eDP controller to reuse existing RK3588 config.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
include/drm/bridge/analogix_dp.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index d45c81c1d77a..0ff1b4a70e70 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1249,6 +1249,7 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
video_info->max_link_rate = 0x0A;
video_info->max_lane_count = 0x04;
break;
+ case RK3576_EDP:
case RK3588_EDP:
video_info->max_link_rate = 0x14;
video_info->max_lane_count = 0x04;
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 7b670dd769e9..0e0b87abee59 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -16,6 +16,7 @@ enum analogix_dp_devtype {
EXYNOS_DP,
RK3288_DP,
RK3399_EDP,
+ RK3576_EDP,
RK3588_EDP,
};
@@ -24,6 +25,7 @@ static inline bool analogix_dp_is_rockchip(enum analogix_dp_devtype type)
switch (type) {
case RK3288_DP:
case RK3399_EDP:
+ case RK3576_EDP:
case RK3588_EDP:
return true;
default:
--
2.34.1
^ permalink raw reply related
* [PATCH v4 10/10] drm/rockchip: analogix_dp: Add support for RK3576
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
RK3576 integrates Analogix eDP 1.3 TX and Samsung combo PHY
hardware blocks that fully match the proven RK3588 design.
Add dedicated chip data table and device tree matching entry
to bring up basic eDP functionality for the RK3576 platform.
Support is limited to RGB output up to 4K@60Hz for now; audio,
PSR and other advanced eDP 1.3 features remain unvalidated.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- Split out a separate patch to enable the "hclk" clock.
- Add Reviewed-by tag.
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index a864bcf8200e..75706a2fdba8 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -522,6 +522,14 @@ static const struct rockchip_dp_chip_data rk3288_dp[] = {
{ /* sentinel */ }
};
+static const struct rockchip_dp_chip_data rk3576_edp[] = {
+ {
+ .chip_type = RK3576_EDP,
+ .reg = 0x27dc0000,
+ },
+ { /* sentinel */ }
+};
+
static const struct rockchip_dp_chip_data rk3588_edp[] = {
{
.edp_mode = GRF_REG_FIELD(0x0000, 0, 0),
@@ -539,6 +547,7 @@ static const struct rockchip_dp_chip_data rk3588_edp[] = {
static const struct of_device_id rockchip_dp_dt_ids[] = {
{.compatible = "rockchip,rk3288-dp", .data = &rk3288_dp },
{.compatible = "rockchip,rk3399-edp", .data = &rk3399_edp },
+ {.compatible = "rockchip,rk3576-edp", .data = &rk3576_edp },
{.compatible = "rockchip,rk3588-edp", .data = &rk3588_edp },
{}
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Joonwon Kang @ 2026-05-12 9:57 UTC (permalink / raw)
To: jgg, robin.murphy
Cc: Alexander.Grest, amhetre, baolu.lu, easwar.hariharan, iommu,
jacob.jun.pan, joonwonkang, joro, jpb, kees, kevin.tian,
linux-arm-kernel, linux-kernel, nicolinc, praan, smostafa, will
In-Reply-To: <20260511132128.GM9285@ziepe.ca>
Hi Jason and Robin, thanks a lot for sharing your insights! Could you help
to answer the further questions below? or just let me know if it is better
to use other channels for them like ARM support.
> On Mon, May 11, 2026 at 01:39:06PM +0100, Robin Murphy wrote:
> > On 2026-05-09 6:10 pm, Jason Gunthorpe wrote:
> > > On Thu, May 07, 2026 at 09:58:51AM +0000, Joonwon Kang wrote:
> > >
> > > > By "similar instruction" on ARM, I guess you mean ST64BV0, which fetches
> > > > the bottom 32 bits data from ACCDATA_EL1. Please let me know if you meant
> > > > others as it will matter. If ST64BV0 is supported on ARM, however, it
> > > > would mean that ST64B and ST64BV are also supported already according to
> > > > the ID_AA64ISAR1_EL1's LS64 field. The latter 2 instructions are just to
> > > > atomically store whatever user wants to a memory location without
> > > > referring to ACCDATA_EL1 and all the 3 instructions can be run at EL0. So,
> > > > the userspace driver would have enough capability to designate arbitrary
> > > > PASID as it wants via the latter 2 instructions when communicating with
> > > > multiple devices.
> > >
> > > IDK exactly what ARM did. IIRC on Intel ENQCMD forms a special
> > > non-posted write TLP and the device can tell the TLP came from ENQCMD
> > > and so it trusts the encoded PASID. ARM has to have done the same
> > > thing - allowing anyone to forge the PASID by using a different
> > > instruction misses the point of the Intel design.
> >
> > Yes, ACCDATA_EL1 is a privileged register neither writeable nor readable by
> > userspace[1], so it should be functionally equivalent from an SVA point of
> > view.
>
> There is a bit more going on though, I think that is what Joonwon is
> mentioning by asking about ST64B and ST64BV. I *think* the answer is:
>
> - ST64B uses a posted write
> - ST64BV can be restricted so EL0 cannot execute it, it uses a
> non-posted write (AI tells me via EnASR)
> - ST64BV0 can be used by EL0, always uses a non-posted write, and always
> uses ACCDATA_EL1
>
> Which is similar to Intel.
Ah, I missed that ST64BV is currently being trapped to EL1 while ST64B is
not [1]. However, I am not sure if the trap is to disallow EL0 to use it.
Can it be instead to pass the response value of the non-posted write to
EL0 while using the EL0-given PASID as-is? If so, I believe EL0 still can
specify arbitrary PASID as it wants via ST64BV.
Since I guess ST64B* instructions are to serve generic purposes not only
for communication with accelerators with SIOV but also with any memory
location or device without SIOV, I am not sure if it is always okay to
make those instructions work the way Jason mentioned.
> The device only processes the PASID from a non-posted write,
>
Regarding ST64B, are the ARM devices behind ARM SMMU v3 supposed to work
this way too? If not, EL0 can specify arbitrary PASID via ST64B with the
kernel today [1].
[1] https://github.com/torvalds/linux/blob/50897c955902c93ae71c38698abb910525ebdc89/arch/arm64/kernel/cpufeature.c#L3166-L3181
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH v3 3/3] usb: dwc3: imx8mp: disable auto suspend for host role
From: Xu Yang @ 2026-05-12 9:58 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Franz Schnyder, Thinh.Nguyen, gregkh, shawnguo, s.hauer, kernel,
festevam, linux-usb, linux-kernel, imx, linux-arm-kernel, jun.li
In-Reply-To: <af8stIGhzVMfhyIQ@livingston.pivistrello.it>
On Sat, May 09, 2026 at 02:46:44PM +0200, Francesco Dolcini wrote:
> On Fri, May 08, 2026 at 06:04:49PM +0200, Franz Schnyder wrote:
> > On Fri, May 08, 2026 at 06:54:40PM +0800, Xu Yang wrote:
> > > It's strange that link->status is not DL_STATE_DORMANT or DL_STATE_NONE at
> > > the time which means the device core may not properly unbind consumer devices
> > > or handle something. The patch does a simple thing so the issue may not come
> > > from the patch itself.
> > >
> > > 1639: list_for_each_entry_safe_reverse(link, ln, &dev->links.consumers, s_node) {
> > > 1640: WARN_ON(link->status != DL_STATE_DORMANT &&
> > > 1641: link->status != DL_STATE_NONE);
> > > 1642: __device_link_del(&link->kref);
> > > 1643: }
> > >
> > > Which kernel and dtb are you using? If it's a downstream repo, how do the USB
> > > controller and related DTS nodes look like?
> >
> > I was using kernel version 7.1-rc2 and noticed it while working on
> > sending the Aquila iMX95 upstream.
> > https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-2-69c8ee1c5413@toradex.com/
> > >
> > > Does the issue easily happen? Does dwc3_imx8mp_probe() eventually succeed?
> >
> > I did various boot attempts with the commit reverted and couldn't
> > reproduce the issue. With the commit I ran into the issue in about one
> > third of all boot attempts. So most of the time dwc3_imx8mp_prove
> > actually succeeds.
>
> ...
>
> > > Yes, if you use the new driver, I think this issue won't happen at all.
> > >
> > So once your work is merged in the imx95.dtsi we should be fine.
>
> To me it looks like a regression that should be taken care of.
>
> Maybe not relevant for aquila imx95, where you did reproduce it (the reason is
> that aquila imx95 is not in mainline, yet), but from the USB point of view this
> board is very similar to other boards using the i.MX95 SoC that are therefore
> likely affected.
Sure. I can't reproduce the issue now.
I'll research it when more information is given.
Thanks,
Xu Yang
^ permalink raw reply
* [PATCH v4 04/10] arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Add the required HCLK_VO1 bus clock to RK3588 eDP1 node with
corresponding clock-name "hclk". This clock is necessary for
the eDP controller to access video output GRF and work properly.
Previously the clock was enabled implicitly via GRF phandle
reference. Add it explicitly now to align with updated binding.
Fixes: a481bb0b1ad9 ("arm64: dts: rockchip: Add eDP1 dt node for rk3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
index a2640014ee04..b251bb129cdb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
@@ -285,8 +285,8 @@ hdmi1_out: port@1 {
edp1: edp@fded0000 {
compatible = "rockchip,rk3588-edp";
reg = <0x0 0xfded0000 0x0 0x1000>;
- clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>;
- clock-names = "dp", "pclk";
+ clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>, <&cru HCLK_VO1>;
+ clock-names = "dp", "pclk", "hclk";
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH 0>;
phys = <&hdptxphy1>;
phy-names = "dp";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller
From: Icenowy Zheng @ 2026-05-12 10:01 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <dfbc4042-64cf-49f2-a5de-12260beffaa0@gmail.com>
在 2026-05-12二的 17:06 +0800，Joey Lu写道：
======= 8< =============
> > > > > diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > > > b/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > > > index 7a93049368db..225af322de32 100644
> > > > > --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > > > +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > > > @@ -164,13 +164,16 @@ static void
> > > > > vs_bridge_enable_common(struct
> > > > > vs_crtc *crtc,
> > > > > VSDC_DISP_PANEL_CONFIG_CLK_EN);
> > > > > regmap_set_bits(dc->regs,
> > > > > VSDC_DISP_PANEL_CONFIG(output),
> > > > > VSDC_DISP_PANEL_CONFIG_RUNNING);
> > > > > - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> > > > > -
> > > > > VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
> > > > > - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
> > > > > -
> > > > > VSDC_DISP_PANEL_START_RUNNING(output));
> > > > >
> > > > > - regmap_set_bits(dc->regs,
> > > > > VSDC_DISP_PANEL_CONFIG_EX(crtc-
> > > > > > id),
> > > > > - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
> > > > > + if (dc->info->has_config_ex) {
> > > > > + regmap_clear_bits(dc->regs,
> > > > > VSDC_DISP_PANEL_START,
> > > > > +
> > > > > VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
> > > > > + regmap_set_bits(dc->regs,
> > > > > VSDC_DISP_PANEL_START,
> > > > > + VSDC_DISP_PANEL_START_RUNNIN
> > > > > G(ou
> > > > > tput
> > > > > ));
> > > > > +
> > > > > + regmap_set_bits(dc->regs,
> > > > > VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
> > > > > + VSDC_DISP_PANEL_CONFIG_EX_CO
> > > > > MMIT
> > > > > );
> > > > Should the commit operation happen on DC8000/DCUltraLite too?
> > > > (By
> > > > writing to DcregFrameBufferConfig0.VALID).
> > > >
> > > > Many registers written has "Note: This field is double
> > > > buffered" in
> > > > the
> > > > DCUltraLite documentation.
> > > >
> > > > I suggest create a static function for commit -- write to the
> > > > corresponding commit bit on DC8200, and write to
> > > > DcregFrameBufferConfig0.VALID on DC8000/DCUltraLite.
> > > [a] There is no commit operation for DCUltra Lite.
> > > I'll not add a `VSDC_FB_CONFIG_VALID` macro. VALID (BIT(3)) is a
> > > hardware-managed double-buffer status bit: hardware writes
> > > 1=PENDING
> > > when a new register set is ready and clears to 0=WORKING after
> > > the
> > > VBLANK copy. Software must never write it, and there is no
> > > polling
> > > use
> > It seems to be writable and controls whether register buffering is
> > enabled, see [1].
> >
> > The description of this bit in MA35D1 TRM says "This ensures a
> > frame
> > will always start with a valid working set if this register is
> > programmed last, which reduces the need for SW to wait for the
> > start of
> > a VBLANK signal in order to ensure all states are loaded before the
> > next VBLANK", which indicates some kind of "committing write",
> > although
> > the code at [1] seems to indicate that double buffering is only
> > enabled
> > when bit is cleared.
> >
> > Anyway this bit should be programmable, and "Software must never
> > write
> > it" contradicts with the MA35D1 TRM.
> >
> > Thanks,
> > Icenowy
> >
> > [1]
> > https://github.com/rockos-riscv/rockos-kernel/blob/rockos-v6.6.y/drivers/gpu/drm/eswin/es_dc_hw.c#L993
> Thank you for the correction. I'll add
> `#define VSDC_FB_CONFIG_VALID BIT(3)` to vs_primary_plane_regs.h and
> write it in `vs_primary_plane_commit()` for non-config_ex variants.
> > > case in the driver that requires a named constant. For non-
> > > config_ex
> > > variants, `vs_primary_plane_commit()` performs no commit
> > > operation —
> > > `VSDC_FB_CONFIG_ENABLE` (OUTPUT, BIT(0)) is set in
> > > `vs_crtc_atomic_enable()` and `VSDC_FB_CONFIG_RESET` (BIT(4)) is
> > > set/cleared in the bridge enable/disable paths.
Well according to the driver code for DC8000 from Eswin, and the bit
named "VALID", maybe it should be cleared before programming the
registers, and set after programming registers, to make the process of
programming registers atomic from the perspective of the display
controller.
Anyway this should require testing on real hardware to verify.
By the way, I see multiple peripheral drivers for MA35D1 get applied in
the torvalds tree, but the device tree is still only a skeleton; when
will the device tree be updated?
Thanks,
Icenowy
> > ========= 8< ==========
> >
^ permalink raw reply
* [PATCH v4 07/10] arm64: dts: rockchip: Add eDP node for RK3576
From: Damon Ding @ 2026-05-12 9:56 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260512095644.1946084-1-damon.ding@rock-chips.com>
Add full device tree definition for the integrated eDP controller
on RK3576, following the existing RK3588 hardware layout.
Configure required register range, clocks, interrupt, phy, power
domain, reset and grf properties to fully describe the controller.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v2:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 28 ++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
index 28175d8200d5..733449cb88b1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
@@ -1496,6 +1496,34 @@ hdmi_out: port@1 {
};
};
+ edp: edp@27dc0000 {
+ compatible = "rockchip,rk3576-edp";
+ reg = <0x0 0x27dc0000 0x0 0x1000>;
+ clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>, <&cru HCLK_VO0_ROOT>;
+ clock-names = "dp", "pclk", "hclk";
+ interrupts = <GIC_SPI 365 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&hdptxphy>;
+ phy-names = "dp";
+ power-domains = <&power RK3576_PD_VO0>;
+ resets = <&cru SRST_EDP0_24M>, <&cru SRST_P_EDP0>;
+ reset-names = "dp", "apb";
+ rockchip,grf = <&vo0_grf>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in: port@0 {
+ reg = <0>;
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
dp: dp@27e40000 {
compatible = "rockchip,rk3576-dp";
reg = <0x0 0x27e40000 0x0 0x30000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3] dt-bindings: i2c: convert davinci i2c to dt-schema
From: Bartosz Golaszewski @ 2026-05-12 10:06 UTC (permalink / raw)
To: Chaitanya Sabnis
Cc: linux-i2c, devicetree, linux-kernel, linux-arm-kernel,
kernel test robot, andi.shyti, robh, krzk+dt, conor+dt, brgl
In-Reply-To: <20260512030032.5006-1-chaitanya.msabnis@gmail.com>
On Tue, 12 May 2026 05:00:32 +0200, Chaitanya Sabnis
<chaitanya.msabnis@gmail.com> said:
> Convert the Texas Instruments DaVinci and Keystone I2C controller
> bindings from legacy text format to modern dt-schema (YAML).
>
> During the conversion, the `interrupts` property was made required
> to match the strict requirement in the driver probe function. The
> custom `ti,has-pfunc` and `power-domains` properties were also
> properly defined to match SoC-specific hardware features.
>
> Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202605120133.lQ1F3qlY-lkp@intel.com/
The report was on an earlier version. This patch is not a solution to a problem
spotted by the build bot itself. I'd just drop this line.
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v3 1/7] PCI: Add pci_host_common_link_train_delay() helper
From: Hans Zhang @ 2026-05-12 10:06 UTC (permalink / raw)
To: Claudiu Beznea, bhelgaas, lpieralisi, kwilczynski, mani, vigneshr,
jingoohan1, thomas.petazzoni, pali, ryder.lee, claudiu.beznea.uj,
mpillai
Cc: robh, s-vadapalli, linux-omap, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-pci, linux-kernel
In-Reply-To: <e092cd5d-6a46-4440-9085-95c929e8fb83@kernel.org>
On 5/12/26 15:05, Claudiu Beznea wrote:
> Hi, Hans,
>
> On 5/11/26 08:59, Hans Zhang wrote:
>> PCIe r6.0, sec 6.6.1 (Conventional Reset) requires that for a Downstream
>> Port supporting Link speeds greater than 5.0 GT/s, software must wait a
>> minimum of 100 ms after Link training completes before sending any
>> Configuration Request.
>>
>> Introduce a static inline helper pci_host_common_link_train_delay() that
>> checks the given max_link_speed (2 = 5.0 GT/s, 3 = 8.0 GT/s, etc.) and
>> calls msleep(100) only when the speed is greater than 5.0 GT/s.
>>
>> This allows multiple host controller drivers to share the same mandatory
>> delay without duplicating the logic.
>>
>> Signed-off-by: Hans Zhang <18255117159@163.com>
>> ---
>> drivers/pci/controller/pci-host-common.h | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/pci/controller/pci-host-common.h b/drivers/pci/
>> controller/pci-host-common.h
>> index b5075d4bd7eb..d709f7e3e11a 100644
>> --- a/drivers/pci/controller/pci-host-common.h
>> +++ b/drivers/pci/controller/pci-host-common.h
>> @@ -10,6 +10,9 @@
>> #ifndef _PCI_HOST_COMMON_H
>> #define _PCI_HOST_COMMON_H
>> +#include <linux/delay.h>
>> +#include "../pci.h"
>> +
>> struct pci_ecam_ops;
>> int pci_host_common_probe(struct platform_device *pdev);
>> @@ -20,4 +23,18 @@ void pci_host_common_remove(struct platform_device
>> *pdev);
>> struct pci_config_window *pci_host_common_ecam_create(struct device
>> *dev,
>> struct pci_host_bridge *bridge, const struct pci_ecam_ops *ops);
>> +
>> +/**
>> + * pci_host_common_link_train_delay - Wait 100 ms if link speed > 5 GT/s
>> + * @max_link_speed: the maximum link speed (2 = 5.0 GT/s, 3 = 8.0 GT/
>> s, ...)
>> + *
>> + * Must be called after Link training completes and before the first
>> + * Configuration Request is sent.
>> + */
>> +static inline void pci_host_common_link_train_delay(int max_link_speed)
>> +{
>> + if (max_link_speed > 2)
>> + msleep(PCIE_RESET_CONFIG_WAIT_MS);
>
> In case of RZ/G3S driver the max_link_speed is populated based on "max-
> link-speed" DT property (by calling of_pci_get_max_link_speed()). My
> understanding from [1] (and the review of the initial RZ/G3S driver
> support) is that this is not a mandatory property (note also the "Host
> drivers *could* add this" from [1]). At least for the RZ/G3S driver, in
> case the "max-link-speed" DT property is not present in DT but the
> controller supports more than 5GT/s (that is possible as the driver
> supports more controller variants), the max_link_speed argument will be
> negative. In that case the msleep() will not be called. This looks like
> an opposite of what the patch set is trying to achieve.
Hi Claudiu,
The situation you mentioned also exists in the dwc common driver. My
understanding is that we are writing this driver at the normal rate
which is greater than GEN2. For some exceptions, or when the support is
greater than GEN2 but the actual operation is less than or equal to
GEN2, this situation might be unavoidable. Furthermore, for RZ/G3S, the
"max-link-speed" attribute can be added to the DT.
>
> Also, if I'm not wrong, there is also the possibility of having the max-
> link-speed > 2 but the downstream port to not support more than 5GT/s.
> In that case the mspeep() would also be executed (but I think that
> wouldn't be really an issue).
Before this patch, the RZ/G3S driver would always perform a msleep(100)
regardless of whether it was greater than GEN2 or less than or equal to
GEN2.
Best regards,
Hans
>
> Thank you,
> Claudiu
>
> [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/
> schemas/pci/pci-bus-common.yaml#L117
>
> Thank you,
> Claudiu
^ permalink raw reply
* Re: [PATCH net-next v3 5/6] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Maxime Chevallier @ 2026-05-12 10:06 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Andrew Lunn,
Heiner Kallweit, Russell King
Cc: kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20260512-add-airoha-an8801-support-v3-5-1edb34e363ae@collabora.com>
Hi :)
This looks good, I just have very minimal comments
On 5/12/26 06:33, Louis-Alexis Eyraud wrote:
> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> Introduce a driver for the Airoha AN8801R Series Gigabit Ethernet
> PHY; this currently supports setting up PHY LEDs, 10/100M, 1000M
> speeds, and Wake on LAN and PHY interrupts.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
[...]
> +static u32 an8801r_led_blink_ms_to_hw(unsigned long req_ms)
> +{
> + u32 req_ns, regval;
> +
> + if (req_ms > AN8801_MAX_PERIOD_MS)
> + req_ms = AN8801_MAX_PERIOD_MS;
> +
> + req_ns = req_ms * 1000000;
Use NSEC_PER_MSEC :)
> +
> + /* Round to the nearest period unit... */
> + regval = req_ns + (AN8801_PERIOD_UNIT / 2);
> +
> + /* ...and now divide by the full period */
> + regval >>= AN8801_PERIOD_SHIFT;
> +
> + return regval;
> +}
> +
[...]
> +static int an8801r_led_hw_control_set(struct phy_device *phydev, u8 index,
> + unsigned long rules)
> +{
> + u16 on = 0, blink = 0;
> + int ret;
> +
> + if (index >= AN8801R_NUM_LEDS)
> + return -EINVAL;
> +
> + ret = an8801r_led_trig_to_hw(rules, &on, &blink);
> + if (ret)
> + return ret;
> +
> + ret = phy_modify_mmd(phydev, MDIO_MMD_VEND2, LED_ON_CTRL(index),
> + LED_ON_EVT_MASK, on);
> + if (ret)
> + return ret;
> +
> + ret = phy_modify_mmd(phydev, MDIO_MMD_VEND2, LED_BLINK_CTRL(index),
> + LED_BLINK_EVT_MASK, blink);
> +
> + if (ret)
> + return ret;
Extra newline before the if()
> +
> + return phy_modify_mmd(phydev, MDIO_MMD_VEND2, LED_ON_CTRL(index),
> + LED_ON_EN, on | blink ? LED_ON_EN : 0);
> +}
> +
[...]
> +static int an8801r_rgmii_rxdelay(struct phy_device *phydev, bool enable,
> + u16 delay_steps)
> +{
> + u32 reg_val;
> +
> + if (delay_steps > RGMII_DELAY_STEP_MASK)
> + return -EINVAL;
> +
> + if (enable) {
> + reg_val = delay_steps & RGMII_DELAY_STEP_MASK;
> +
> + /* Set align bit to add extra offset for RX delay */
> + reg_val |= RGMII_RXDELAY_ALIGN;
> +
> + /* Set force mode bit to enable RX delay insertion */
> + reg_val |= RGMII_RXDELAY_FORCE_MODE;
> + } else {
> + reg_val = 0;
> + }
> +
> + return an8801_buckpbus_reg_write(phydev, AN8801_BPBUS_REG_RXDLY_STEP,
> + reg_val);
> +}
> +
> +static int an8801r_rgmii_txdelay(struct phy_device *phydev, bool enable,
> + u16 delay_steps)
> +{
> + u32 reg_val;
> +
> + if (delay_steps > RGMII_DELAY_STEP_MASK)
> + return -EINVAL;
> +
> + if (enable) {
> + reg_val = delay_steps & RGMII_DELAY_STEP_MASK;
Is this bitwise and needed, as you have the check above ?
> +
> + /* Set force mode bit to enable TX delay insertion */
> + reg_val |= RGMII_TXDELAY_FORCE_MODE;
> + } else {
> + reg_val = 0;
> + }
> +
> + return an8801_buckpbus_reg_write(phydev, AN8801_BPBUS_REG_TXDLY_STEP,
> + reg_val);
> +}
> +
> +static int an8801r_rgmii_delay_config(struct phy_device *phydev)
> +{
> + bool enable_delay;
> + u16 delay_step;
> + int ret;
> +
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
> + enable_delay = true;
> + delay_step = AN8801_RGMII_TXDELAY_DEFAULT;
> + } else {
> + enable_delay = false;
> + delay_step = RGMII_DELAY_NO_STEP;
> + }
> +
> + ret = an8801r_rgmii_txdelay(phydev, enable_delay, delay_step);
> + if (ret)
> + return ret;
> +
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
> + enable_delay = true;
> + delay_step = AN8801_RGMII_RXDELAY_DEFAULT;
Is it correct that AN8801_RGMII_RXDELAY_DEFAULT expands to
RGMII_DELAY_NO_STEP ? feels strange, but it may simply be how the HW is
made :)
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH v3 4/7] PCI: dwc: Use common pci_host_common_link_train_delay() helper
From: Hans Zhang @ 2026-05-12 10:06 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: bhelgaas, lpieralisi, mani, vigneshr, jingoohan1,
thomas.petazzoni, pali, ryder.lee, claudiu.beznea.uj, mpillai,
robh, s-vadapalli, linux-omap, linux-arm-kernel, claudiu.beznea,
linux-mediatek, linux-renesas-soc, linux-pci, linux-kernel
In-Reply-To: <20260512071328.GA3606279@rocinante>
On 5/12/26 15:14, Krzysztof Wilczyński wrote:
> Hello,
>
>>>> - /*
>>>> - * As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link
>>>> - * speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms
>>>> - * after Link training completes before sending a Configuration Request.
>>>> - */
>>>> - if (pci->max_link_speed > 2)
>>>> - msleep(PCIE_RESET_CONFIG_WAIT_MS);
>>>> + pci_host_common_link_train_delay(pci->max_link_speed);
>>>
>>> This comment could move to the helper you added.
>>
>> Hi Krzysztof,
>>
>> Will add.
>
> No need. Per Mani's feedback about macro being well documented.
>
Hi Krzysztof,
Okay.
Best regards,
Hans
> Thank you nonetheless!
>
> Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox