* Re: [PATCH v5 5/9] block: implement NVMEM provider
From: Bartosz Golaszewski @ 2026-06-15 8:53 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
In-Reply-To: <20260612-block-as-nvmem-v5-5-95e0b30fff90@oss.qualcomm.com>
On Fri, 12 Jun 2026 15:20:57 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> From: Daniel Golle <daniel@makrotopia.org>
>
> On embedded devices using an eMMC it is common that one or more partitions
> on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM
> data. Allow referencing the partition in device tree for the kernel and
> Wi-Fi drivers accessing it via the NVMEM layer.
>
> For now, NVMEM is only registered for the whole disk block device, as the
> OF node is currently only associated to it.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> Co-developed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> block/Kconfig | 9 ++++
> block/Makefile | 1 +
> block/blk-nvmem.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++
> block/blk.h | 8 ++++
> block/genhd.c | 4 ++
> include/linux/blk_types.h | 3 ++
> include/linux/blkdev.h | 1 +
> 7 files changed, 135 insertions(+)
>
> diff --git a/block/Kconfig b/block/Kconfig
> index 15027963472d7b40e27b9097a5993c457b5b3054..0b33747e16dc33473683706f75c92bdf8b648f7c 100644
> --- a/block/Kconfig
> +++ b/block/Kconfig
> @@ -209,6 +209,15 @@ config BLK_INLINE_ENCRYPTION_FALLBACK
> by falling back to the kernel crypto API when inline
> encryption hardware is not present.
>
> +config BLK_NVMEM
> + bool "Block device NVMEM provider"
> + depends on OF
> + depends on NVMEM
> + help
> + Allow block devices (or partitions) to act as NVMEM providers,
> + typically used with eMMC to store MAC addresses or Wi-Fi
> + calibration data on embedded devices.
> +
> source "block/partitions/Kconfig"
>
> config BLK_PM
> diff --git a/block/Makefile b/block/Makefile
> index 7dce2e44276c4274c11a0a61121c83d9c43d6e0c..d7ac389e71902bc091a8800ea266190a43b3e63d 100644
> --- a/block/Makefile
> +++ b/block/Makefile
> @@ -36,3 +36,4 @@ obj-$(CONFIG_BLK_INLINE_ENCRYPTION) += blk-crypto.o blk-crypto-profile.o \
> blk-crypto-sysfs.o
> obj-$(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) += blk-crypto-fallback.o
> obj-$(CONFIG_BLOCK_HOLDER_DEPRECATED) += holder.o
> +obj-$(CONFIG_BLK_NVMEM) += blk-nvmem.o
> diff --git a/block/blk-nvmem.c b/block/blk-nvmem.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..c005f059d9fe56242ebaef9905673dff902b5686
> --- /dev/null
> +++ b/block/blk-nvmem.c
> @@ -0,0 +1,109 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * block device NVMEM provider
> + *
> + * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + *
> + * Useful on devices using a partition on an eMMC for MAC addresses or
> + * Wi-Fi calibration EEPROM data.
> + */
> +
> +#include <linux/file.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/pagemap.h>
> +#include <linux/property.h>
> +
> +#include "blk.h"
> +
> +static int blk_nvmem_reg_read(void *priv, unsigned int from, void *val, size_t bytes)
> +{
> + blk_mode_t mode = BLK_OPEN_READ | BLK_OPEN_RESTRICT_WRITES;
> + dev_t devt = (dev_t)(uintptr_t)priv;
> + size_t bytes_left = bytes;
> + loff_t pos = from;
> + int ret = 0;
> +
> + struct file *bdev_file __free(fput) = bdev_file_open_by_dev(devt, mode, priv, NULL);
> + if (IS_ERR(bdev_file))
> + return PTR_ERR(bdev_file);
> +
> + while (bytes_left) {
> + pgoff_t f_index = pos >> PAGE_SHIFT;
> + struct folio *folio;
> + size_t folio_off;
> + size_t to_read;
> +
> + folio = read_mapping_folio(bdev_file->f_mapping, f_index, NULL);
> + if (IS_ERR(folio)) {
> + ret = PTR_ERR(folio);
> + break;
> + }
> +
> + folio_off = offset_in_folio(folio, pos);
> + to_read = min(bytes_left, folio_size(folio) - folio_off);
> + memcpy_from_folio(val, folio, folio_off, to_read);
> + pos += to_read;
> + bytes_left -= to_read;
> + val += to_read;
> + folio_put(folio);
> + }
> +
> + return ret;
> +}
> +
> +void blk_nvmem_add(struct block_device *bdev)
> +{
> + struct device *dev = &bdev->bd_device;
> + struct nvmem_config config = {};
> +
> + /* skip devices which do not have a device tree node */
> + if (!dev_of_node(dev))
> + return;
> +
> + /* skip devices without an nvmem layout defined */
> + struct device_node *child __free(device_node) =
> + of_get_child_by_name(dev_of_node(dev), "nvmem-layout");
> + if (!child)
> + return;
> +
> + /*
> + * skip block device too large to be represented as NVMEM devices,
> + * the NVMEM reg_read callback uses an unsigned int offset
> + */
> + if (bdev_nr_bytes(bdev) > UINT_MAX) {
> + dev_warn(dev, "block device too large to be an NVMEM provider\n");
> + return;
> + }
> +
> + config.id = NVMEM_DEVID_NONE;
> + config.dev = dev;
> + config.name = dev_name(dev);
> + config.owner = THIS_MODULE;
> + config.priv = (void *)(uintptr_t)dev->devt;
> + config.reg_read = blk_nvmem_reg_read;
> + config.size = bdev_nr_bytes(bdev);
> + config.word_size = 1;
> + config.stride = 1;
> + config.read_only = true;
> + config.root_only = true;
> + config.ignore_wp = true;
> + config.of_node = to_of_node(dev->fwnode);
> +
> + bdev->bd_nvmem = nvmem_register(&config);
> + if (IS_ERR(bdev->bd_nvmem)) {
> + dev_err_probe(dev, PTR_ERR(bdev->bd_nvmem),
> + "Failed to register NVMEM device\n");
Using dev_err_probe() only makes sense with a return value. Which makes me
think: we won't retry this after a probe deferral. I think we should return
int from this function just for this use-case. Also: if we *do* have
a layout, shouldn't we treat a failure to register the nvmem provider as
a an error and propagate it up the stack?
> + bdev->bd_nvmem = NULL;
> + }
> +}
> +
> +void blk_nvmem_del(struct block_device *bdev)
> +{
> + if (bdev->bd_nvmem)
Nvmem core already performs a NULL check.
> + nvmem_unregister(bdev->bd_nvmem);
> +
> + bdev->bd_nvmem = NULL;
> +}
> diff --git a/block/blk.h b/block/blk.h
> index ec4674cdf2ead4fd259ff5fc42401f591e684ee9..cd3c7ca723391c40be56f1dd4810e641b7c8a2b3 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -757,4 +757,12 @@ static inline void blk_debugfs_unlock(struct request_queue *q,
> memalloc_noio_restore(memflags);
> }
>
> +#ifdef CONFIG_BLK_NVMEM
> +void blk_nvmem_add(struct block_device *bdev);
> +void blk_nvmem_del(struct block_device *bdev);
> +#else
> +static inline void blk_nvmem_add(struct block_device *bdev) {}
> +static inline void blk_nvmem_del(struct block_device *bdev) {}
> +#endif
> +
> #endif /* BLK_INTERNAL_H */
> diff --git a/block/genhd.c b/block/genhd.c
> index 7d6854fd28e95ae9134309679a7c6a937f5b7db8..1b2382de6fb30c1e5f60f45c04dc03ed3bf5d5f2 100644
> --- a/block/genhd.c
> +++ b/block/genhd.c
> @@ -421,6 +421,8 @@ static void add_disk_final(struct gendisk *disk)
> */
> dev_set_uevent_suppress(ddev, 0);
> disk_uevent(disk, KOBJ_ADD);
> +
> + blk_nvmem_add(disk->part0);
> }
>
> blk_apply_bdi_limits(disk->bdi, &disk->queue->limits);
> @@ -704,6 +706,8 @@ static void __del_gendisk(struct gendisk *disk)
>
> disk_del_events(disk);
>
> + blk_nvmem_del(disk->part0);
> +
> /*
> * Prevent new openers by unlinked the bdev inode.
> */
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index 8808ee76e73c09e0ceaac41ba59e86fb0c4efc64..ace6f59b860d0813665b2f62a1c03a1f4be94059 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -73,6 +73,9 @@ struct block_device {
> int bd_writers;
> #ifdef CONFIG_SECURITY
> void *bd_security;
> +#endif
> +#ifdef CONFIG_BLK_NVMEM
> + struct nvmem_device *bd_nvmem;
> #endif
> /*
> * keep this out-of-line as it's both big and not needed in the fast
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 890128cdea1ce66863c5baa36f3b336ec4550807..f15d2b5bf9e4fd2368b8a70416a978e22c0d4333 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -30,6 +30,7 @@
>
> struct module;
> struct request_queue;
> +struct nvmem_device;
> struct elevator_queue;
> struct blk_trace;
> struct request;
>
> --
> 2.34.1
>
>
I like this approach better than the previous one.
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v3 0/3] Move thread_info into task_struct for LoongArch
From: Huacai Chen @ 2026-06-15 8:53 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Tiezhu Yang, Hengqi Chen, loongarch, bpf, LKML
In-Reply-To: <CAADnVQLAgYFQ=BRi+hKwt5pp7fffqsvD0rXzn6Nk9jJQ=6uUZA@mail.gmail.com>
Hi, Alexei,
On Mon, Jun 15, 2026 at 11:45 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Sun, Jun 14, 2026 at 8:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >
> > On Mon, Jun 15, 2026 at 11:16 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> > >
> > > On 2026/6/15 上午10:23, Huacai Chen wrote:
> > > > On Mon, Jun 15, 2026 at 9:41 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> > > >>
> > > >> On 2026/6/14 上午10:51, Huacai Chen wrote:
> > > >>> Hi, Tiezhu,
> > > >>>
> > > >>> I have queued this series for 7.2, does the below series depend on this one?
> > > >>>
> > > >>> https://lore.kernel.org/loongarch/20260521125636.26744-1-yangtiezhu@loongson.cn/T/#t
> > > >>
> > > >> This is independent on CONFIG_THREAD_INFO_IN_TASK.
> > > >>
> > > >>> https://lore.kernel.org/loongarch/20260428080051.20938-1-yangtiezhu@loongson.cn/T/#t
> > > >>
> > > >> This is dependent on CONFIG_THREAD_INFO_IN_TASK.
> > > >>
> > > >> But anyway, I plan to send new version for the above two series of
> > > >> selftests once this "Move thread_info into task_struct for LoongArch"
> > > >> series is merged into the mainline, maybe after 7.2-rc1.
> > > >>
> > > >> Because the code under selftests need to be updated, for example,
> > > >> it can use bpf_get_current_task_btf()->thread_info.preempt_count
> > > >> for get_preempt_count(), and it should use ld.wu rather than ld.w
> > > >> for bpf_get_smp_processor_id().
> > > > You can update new versions now, then they can be merged together.
> > >
> > > Thanks for your suggestion.
> > >
> > > However, considering that these selftest patches need to be
> > > routed through the BPF tree (rather than the LoongArch tree),
> > > updating them right now during the active merge window might
> > > be inappropriate and risky.
> > >
> > > Given that these selftests strictly depend on the "move
> > > thread_info into task_struct" core changes, sending them to
> > > the BPF list now could cause cross-tree dependency issues and
> > > potential build breakages if the core series undergoes any late
> > > adjustments before hitting mainline.
> > >
> > > Moreover, because these are selftest adaptations rather than
> > > urgent bug fixes, they aren't high-priority for this immediate
> > > window. I will rebase and submit the new version to the BPF tree
> > > right after 7.2-rc1, once the LoongArch base infrastructure is
> > > securely merged into the mainline.
> > In history most arch-specific selftests are merged via arch trees,
> > including perf, bpf, ftrace, kvm and so on.
>
> This is not true at all.
> All bpf selftests are going through bpf-next tree.
> For example, x86 and arm64 bpf JIT changes always go
> through bpf-next.
> loongarch is causing problems this way by taking bpf JIT changes
> into the loongarch tree.
I'm sorry for my mistake. Yes, you are right, most BPF changes go
through bpf-next, but LoongArch is not the first and not the only
exception. See commit 806381e1a24c6eec2b431cbba2ba1b81e518fea8 and
3203a08c1266689c204fb8f10d6bb5186921fce2.
Frankly, cross subsystem patches usually have some extra difficulty to
get merged because of dependencies & confliction, and my mentor gave
me a solution: Merge a single tag from another subsystem (e.g. from
the bpf tree) to create a clean base, and then apply arch patches on
top of that base.
Huacai
^ permalink raw reply
* Re: [PATCH v2 02/16] mm/slab: do not init any kfence objects on allocation
From: Vlastimil Babka (SUSE) @ 2026-06-15 8:52 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Alexei Starovoitov, Andrew Morton,
Johannes Weiner, Michal Hocko, Shakeel Butt, Alexander Potapenko,
Andrey Konovalov, Marco Elver, Dmitry Vyukov, kasan-dev, linux-mm,
linux-kernel, cgroups
In-Reply-To: <CAJuCfpH8g9mNGV_ke-mhVZ=J9J05PZg-ozPTA=5WQrm_eViVpA@mail.gmail.com>
On 6/15/26 03:28, Suren Baghdasaryan wrote:
> On Thu, Jun 11, 2026 at 9:37 AM Vlastimil Babka (SUSE)
> <vbabka@kernel.org> wrote:
>>
>> On 6/11/26 17:11, Harry Yoo wrote:
>> >
>> >> From 3a1c4398ce9f361a4e6f4d9946eab6237eea89c2 Mon Sep 17 00:00:00 2001
>> >> From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
>> >> Date: Wed, 10 Jun 2026 17:40:04 +0200
>> >> Subject: [PATCH] mm/slab: do not init any kfence objects on allocation
>> >>
>> >> When init (zeroing) on allocation is requested, for kmalloc() we
>> >> generally have to zero the full object size even if a smaller size is
>> >> requested, in order to provide krealloc()'s __GFP_ZERO guarantees.
>> >>
>> >> When we end up allocating a kfence object, kfence perfoms the zeroing on
>> >
>> > nit: perfoms -> performs
>>
>> Fixed.
>>
>> >> its own because has its own redzone beyond the requested size. Thus
>
> nit: s/because has/because it has
Fixed.
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Thanks!
^ permalink raw reply
* [PATCH v4 2/2] thermal/drivers/qcom/tsens: Add support for ipq9650 tsens
From: Varadarajan Narayanan @ 2026-06-15 8:52 UTC (permalink / raw)
To: amitk, thara.gopinath, rafael, daniel.lezcano, rui.zhang,
lukasz.luba, robh, krzk+dt, conor+dt, linux-arm-msm, linux-pm,
devicetree, linux-kernel
Cc: Varadarajan Narayanan, Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260615085218.1421347-1-varadarajan.narayanan@oss.qualcomm.com>
ipq9650's tsens is similar to ipq5332 tsens but has different number of
sensors. Re-use the ipq5332 data for ipq9650 and modify the sensor related
information.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
v4: Pick R-b Dmitry Baryshkov
---
drivers/thermal/qcom/tsens-v2.c | 8 ++++++++
drivers/thermal/qcom/tsens.c | 3 +++
drivers/thermal/qcom/tsens.h | 2 +-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
index 2ee117aa91ba..70ee5ca4ece2 100644
--- a/drivers/thermal/qcom/tsens-v2.c
+++ b/drivers/thermal/qcom/tsens-v2.c
@@ -299,6 +299,14 @@ const struct tsens_plat_data data_ipq5424 = {
.fields = tsens_v2_regfields,
};
+const struct tsens_plat_data data_ipq9650 = {
+ .num_sensors = 11,
+ .ops = &ops_ipq5332,
+ .hw_ids = (unsigned int []){5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15},
+ .feat = &ipq5332_feat,
+ .fields = tsens_v2_regfields,
+};
+
/* Kept around for backward compatibility with old msm8996.dtsi */
struct tsens_plat_data data_8996 = {
.num_sensors = 13,
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index 6e3714ecab1d..3e09a06db06b 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -1173,6 +1173,9 @@ static const struct of_device_id tsens_table[] = {
}, {
.compatible = "qcom,ipq8074-tsens",
.data = &data_ipq8074,
+ }, {
+ .compatible = "qcom,ipq9650-tsens",
+ .data = &data_ipq9650,
}, {
.compatible = "qcom,mdm9607-tsens",
.data = &data_9607,
diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
index e8376accdff3..2514f1161794 100644
--- a/drivers/thermal/qcom/tsens.h
+++ b/drivers/thermal/qcom/tsens.h
@@ -676,7 +676,7 @@ extern const struct tsens_plat_data data_ipq5018;
/* TSENS v2 targets */
extern struct tsens_plat_data data_8996, data_ipq8074, data_tsens_v2;
-extern const struct tsens_plat_data data_ipq5332, data_ipq5424;
+extern const struct tsens_plat_data data_ipq5332, data_ipq5424, data_ipq9650;
/* TSENS automotive targets */
extern struct tsens_plat_data data_automotive_v2;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: thermal: tsens: add ipq5210 & ipq9650 compatible
From: Varadarajan Narayanan @ 2026-06-15 8:52 UTC (permalink / raw)
To: amitk, thara.gopinath, rafael, daniel.lezcano, rui.zhang,
lukasz.luba, robh, krzk+dt, conor+dt, linux-arm-msm, linux-pm,
devicetree, linux-kernel
Cc: Varadarajan Narayanan
In-Reply-To: <20260615085218.1421347-1-varadarajan.narayanan@oss.qualcomm.com>
Add the compatible for the thermal sensors on the ipq5210 and ipq9650. The
ipq5210 uses ipq5332-tsens as a fallback, while ipq9650 is added as a
standalone v2 TSENS compatible with combined interrupt.
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
v4: Fix version number
v3: patch version no. mixup
Include ipq9650 to all applicable constraints
https://lore.kernel.org/linux-arm-msm/20260610081241.1468507-1-varadarajan.narayanan@oss.qualcomm.com/
v2: Fix fallback definition
https://lore.kernel.org/linux-arm-msm/20260609065447.4024695-1-varadarajan.narayanan@oss.qualcomm.com/
---
.../devicetree/bindings/thermal/qcom-tsens.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index f0efaa8349ee..bcec314e0532 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -95,6 +95,13 @@ properties:
- qcom,ipq5332-tsens
- qcom,ipq5424-tsens
- qcom,ipq8074-tsens
+ - qcom,ipq9650-tsens
+
+ - description: v2 of TSENS with combined interrupt
+ items:
+ - enum:
+ - qcom,ipq5210-tsens
+ - const: qcom,ipq5332-tsens
- description: v2 of TSENS with combined interrupt
items:
@@ -306,6 +313,7 @@ allOf:
- qcom,ipq5332-tsens
- qcom,ipq5424-tsens
- qcom,ipq8074-tsens
+ - qcom,ipq9650-tsens
then:
properties:
interrupts:
@@ -323,6 +331,7 @@ allOf:
- qcom,ipq5332-tsens
- qcom,ipq5424-tsens
- qcom,ipq8074-tsens
+ - qcom,ipq9650-tsens
- qcom,tsens-v0_1
- qcom,tsens-v1
- qcom,tsens-v2
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/2] Add support tsens in ipq5210 & ipq9650
From: Varadarajan Narayanan @ 2026-06-15 8:52 UTC (permalink / raw)
To: amitk, thara.gopinath, rafael, daniel.lezcano, rui.zhang,
lukasz.luba, robh, krzk+dt, conor+dt, linux-arm-msm, linux-pm,
devicetree, linux-kernel
Cc: Varadarajan Narayanan
ipq5210 and ipq9560 have the Qualcomm tsens-v2 IP. The tsens framework
in these two SoCs are similar to the one found in ipq5332. This series
adds the sensor data to the tsens-v2 driver.
v4: Fix version number
v3: (incorrect version number)
Add additional constraints for ipq9650
https://lore.kernel.org/linux-arm-msm/20260610081241.1468507-1-varadarajan.narayanan@oss.qualcomm.com/
v2: Combine bindings and driver patches
Use fallback for ipq5210 and dropped the driver changes
https://lore.kernel.org/linux-arm-msm/20260609065447.4024695-1-varadarajan.narayanan@oss.qualcomm.com/
v1: bindings - https://lore.kernel.org/linux-arm-msm/20260515-tsens-yaml-v1-1-8039c62cc249@oss.qualcomm.com/
driver - https://lore.kernel.org/linux-arm-msm/20260515-tsens-driver-v1-0-015ca76f1418@oss.qualcomm.com/
Varadarajan Narayanan (2):
dt-bindings: thermal: tsens: add ipq5210 & ipq9650 compatible
thermal/drivers/qcom/tsens: Add support for ipq9650 tsens
.../devicetree/bindings/thermal/qcom-tsens.yaml | 9 +++++++++
drivers/thermal/qcom/tsens-v2.c | 8 ++++++++
drivers/thermal/qcom/tsens.c | 3 +++
drivers/thermal/qcom/tsens.h | 2 +-
4 files changed, 21 insertions(+), 1 deletion(-)
--
2.34.1
^ permalink raw reply
* [PATCH v8 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Can Guo @ 2026-06-15 8:50 UTC (permalink / raw)
To: krzk, bvanassche, beanhuo, peter.wang, martin.petersen, mani
Cc: linux-scsi, Can Guo, Alim Akhtar, Avri Altman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ram Kumar Dwivedi,
Zhaoming Luo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20260615085027.2102882-1-can.guo@oss.qualcomm.com>
UFS v5.0/UFSHCI v5.0 adds HS-G6 support (46.6 Gbps/lane) via UniPro
v3.0 and M-PHY v6.0. These specs define TX Equalization for all
High-Speed Gears (not only HS-G6) to compensate channel loss and
improve signal integrity at high speed.
For HS-G6, M-PHY uses PAM4 1b1b line coding. Pre-Coding may also be
required depending on channel characteristics.
Document vendor-neutral properties in ufs-common.yaml:
- txeq-preshoot-g[1-6]
- txeq-deemphasis-g[1-6]
- tx-precode-enable-g6
Values are per-lane Host/Device tuples (2 values for x1, 4 values for
x2). PreShoot/DeEmphasis range from 0..7, and Precode is 0/1.
These are board-specific signal-integrity tuning values. They depend on
channel SI/PHY characterization and validation (host PHY, device PHY,
package, and board routing), and are determined by HW/PHY designers.
Although UFSHCI v5.0 supports TX Equalization Training via UniPro v3.0,
which allows host software to determine optimal TX Equalization at
runtime, static board-specific TX Equalization settings in the Device
Tree are still necessary because:
- TX Equalization Training is not supported for HS-G3 and below
- TX Equalization Training is disabled on some platforms
Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
---
.../devicetree/bindings/ufs/ufs-common.yaml | 55 +++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
index ed97f5682509..145a6416e1df 100644
--- a/Documentation/devicetree/bindings/ufs/ufs-common.yaml
+++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
@@ -105,6 +105,61 @@ properties:
Restricts the UFS controller to rate-a or rate-b for both TX and
RX directions.
+ tx-precode-enable-g6:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ oneOf:
+ - items:
+ - description: Host_Lane0 precode
+ - description: Device_Lane0 precode
+ - items:
+ - description: Host_Lane0 precode
+ - description: Device_Lane0 precode
+ - description: Host_Lane1 precode
+ - description: Device_Lane1 precode
+ items:
+ enum: [0, 1]
+ description:
+ Static TX Precode enable values for HS-G6 only.
+
+patternProperties:
+ "^txeq-preshoot-g[1-6]$":
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ oneOf:
+ - items:
+ - description: Host_Lane0 Preshoot value
+ - description: Device_Lane0 Preshoot value
+ - items:
+ - description: Host_Lane0 Preshoot value
+ - description: Device_Lane0 Preshoot value
+ - description: Host_Lane1 Preshoot value
+ - description: Device_Lane1 Preshoot value
+ items:
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ description: |
+ Static TX Equalization PreShoot settings for High Speed Gears. These
+ values are programmed to the corresponding UniPro PA layer attribute
+ PA_TxEQG[1-6]Setting. Each value selects a Pre-Shoot level as defined
+ by the MIPI M-PHY specification (TX_HS_PreShoot_Setting).
+
+ "^txeq-deemphasis-g[1-6]$":
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ oneOf:
+ - items:
+ - description: Host_Lane0 DeEmphasis value
+ - description: Device_Lane0 DeEmphasis value
+ - items:
+ - description: Host_Lane0 DeEmphasis value
+ - description: Device_Lane0 DeEmphasis value
+ - description: Host_Lane1 DeEmphasis value
+ - description: Device_Lane1 DeEmphasis value
+ items:
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ description: |
+ Static TX Equalization DeEmphasis settings for High Speed Gears. These
+ values are programmed to the corresponding UniPro PA layer attribute
+ PA_TxEQG[1-6]Setting. Each value selects a De-Emphasis level as defined
+ by the MIPI M-PHY specification (TX_HS_DeEmphasis_Setting).
+
dependencies:
freq-table-hz: [ clocks ]
operating-points-v2: [ clocks, clock-names ]
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 4/6] drm/verisilicon: add DC8000 (DCUltraLite) display controller support
From: Icenowy Zheng @ 2026-06-15 8:51 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: <20260615065003.76661-5-a0987203069@gmail.com>
在 2026-06-15一的 14:50 +0800，Joey Lu写道：
> The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltraLite display
> controller whose register layout differs from the DC8200 in several
> important ways:
>
> 1. No CONFIG_EX commit path: framebuffer updates use the enable (bit
> 0)
> and reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
> registers (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT,
> FB_BLEND_CONFIG, PANEL_CONFIG_EX).
>
> 2. No PANEL_START register: panel output starts when
> PANEL_CONFIG.RUNNING is set; there is no multi-display sync start
> register.
>
> 3. Different IRQ registers: DCUltraLite uses DISP_IRQ_STA (0x147C) /
> DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
> TOP_IRQ_EN (0x0014).
>
> 4. Per-frame commit cycle: DCUltraLite requires the VALID bit in
> FB_CONFIG to be set at the start of each atomic commit
> (crtc_begin)
> and cleared after (crtc_flush).
>
> 5. Simpler clock topology: only 'core' (bus gate) and 'pix0' (pixel
> divider) clocks; no axi or ahb clocks required. Make axi_clk and
> ahb_clk optional (devm_clk_get_optional_enabled) so DC8000 nodes
> without those clocks are handled gracefully.
>
> Add vs_dc8000.c implementing the vs_dc_funcs vtable for the above
> differences. The probe now selects vs_dc8000_funcs when the
> identified
> generation is VSDC_GEN_DC8000 (DCUltraLite reads model 0x0,
> revision 0x5560, customer_id 0x305).
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/Makefile | 2 +-
> drivers/gpu/drm/verisilicon/vs_dc.c | 9 ++-
> drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
> drivers/gpu/drm/verisilicon/vs_dc8000.c | 78
> +++++++++++++++++++++++++
> 4 files changed, 86 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
>
> diff --git a/drivers/gpu/drm/verisilicon/Makefile
> b/drivers/gpu/drm/verisilicon/Makefile
> index 9d4cd16452fa..d2fd8e4dff24 100644
> --- a/drivers/gpu/drm/verisilicon/Makefile
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
> vs_drm.o vs_hwdb.o \
> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
> vs_dc8000.o vs_drm.o vs_hwdb.o \
> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>
> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
> b/drivers/gpu/drm/verisilicon/vs_dc.c
> index 9729b693d360..9499fffbca58 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> return PTR_ERR(dc->core_clk);
> }
>
> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
> + dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
> if (IS_ERR(dc->axi_clk)) {
> dev_err(dev, "can't get axi clock\n");
> return PTR_ERR(dc->axi_clk);
> }
>
> - dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
> + dc->ahb_clk = devm_clk_get_optional_enabled(dev, "ahb");
Please make the clock change a separated patch for atomicity.
BTW the MA35D1 manual's clock tree shows that DCUltra appears on AXI2
ACLK, AHB_HCLK2, behind a mux of SYS-PLL/EPLL-DIV2 (which seems to be
the core clock), and behind a divider (which seems to be the pixel
clock).
However it's weird that only one DCUltra Clock Enable Bit exists
despite both bus clocks have "ICG" (I think it means "Integrated Clock
Gating"). In addition the linux clk-ma35d1 driver assigns "dcu_gate" as
a downstream of "dcu_mux", although the Figure 6.5-2 in the TRM shows
no ICG after the "Display core CLK" mux.
Is the two bus clocks controlled by a single gate bit, and is the bit
also gating DC core clock?
Thanks,
Icenowy
> if (IS_ERR(dc->ahb_clk)) {
> dev_err(dev, "can't get ahb clock\n");
> return PTR_ERR(dc->ahb_clk);
> @@ -134,7 +134,10 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
> >identity.model,
> dc->identity.revision, dc->identity.customer_id);
>
> - dc->funcs = &vs_dc8200_funcs;
> + if (dc->identity.generation == VSDC_GEN_DC8200)
> + dc->funcs = &vs_dc8200_funcs;
> + else
> + dc->funcs = &vs_dc8000_funcs;
>
> if (port_count > dc->identity.display_count) {
> dev_err(dev, "too many downstream ports than HW
> capability\n");
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
> b/drivers/gpu/drm/verisilicon/vs_dc.h
> index 544e1a37065b..5218e8cf63e2 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
> @@ -66,5 +66,6 @@ struct vs_dc {
> };
>
> extern const struct vs_dc_funcs vs_dc8200_funcs;
> +extern const struct vs_dc_funcs vs_dc8000_funcs;
>
> #endif /* _VS_DC_H_ */
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8000.c
> b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> new file mode 100644
> index 000000000000..be0c0d7baf52
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> @@ -0,0 +1,78 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 Joey Lu <yclu4@nuvoton.com>
> + */
> +
> +#include <linux/regmap.h>
> +
> +#include "vs_crtc_regs.h"
> +#include "vs_dc.h"
> +#include "vs_primary_plane_regs.h"
> +
> +static void vs_dc8000_panel_enable_ex(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_RESET);
> +}
> +
> +static void vs_dc8000_panel_disable_ex(struct vs_dc *dc, unsigned
> int output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_RESET);
> +}
> +
> +static void vs_dc8000_crtc_begin(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_VALID);
> +}
> +
> +static void vs_dc8000_crtc_flush(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_VALID);
> +}
> +
> +static void vs_dc8000_crtc_enable(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_ENABLE);
> +}
> +
> +static void vs_dc8000_crtc_disable(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_ENABLE);
> +}
> +
> +static void vs_dc8000_enable_vblank(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_DISP_IRQ_EN,
> + VSDC_DISP_IRQ_VSYNC(output));
> +}
> +
> +static void vs_dc8000_disable_vblank(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_DISP_IRQ_EN,
> + VSDC_DISP_IRQ_VSYNC(output));
> +}
> +
> +static u32 vs_dc8000_irq_ack(struct vs_dc *dc)
> +{
> + u32 irqs;
> +
> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &irqs);
> + return irqs;
> +}
> +
> +const struct vs_dc_funcs vs_dc8000_funcs = {
> + .panel_enable_ex = vs_dc8000_panel_enable_ex,
> + .panel_disable_ex = vs_dc8000_panel_disable_ex,
> + .crtc_begin = vs_dc8000_crtc_begin,
> + .crtc_flush = vs_dc8000_crtc_flush,
> + .crtc_enable = vs_dc8000_crtc_enable,
> + .crtc_disable = vs_dc8000_crtc_disable,
> + .enable_vblank = vs_dc8000_enable_vblank,
> + .disable_vblank = vs_dc8000_disable_vblank,
> + .irq_ack = vs_dc8000_irq_ack,
> +};
^ permalink raw reply
* Re: [PATCH RFC 3/3] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Jinjie Ruan @ 2026-06-15 8:51 UTC (permalink / raw)
To: Michael Kelley, catalin.marinas@arm.com, will@kernel.org,
tsbogend@alpha.franken.de, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, peterz@infradead.org, kees@kernel.org,
nathan@kernel.org, linusw@kernel.org, ojeda@kernel.org,
david.kaplan@amd.com, lukas.bulwahn@redhat.com,
ryan.roberts@arm.com, maz@kernel.org, timothy.hayes@arm.com,
lpieralisi@kernel.org, thuth@redhat.com, oupton@kernel.org,
yeoreum.yun@arm.com, miko.lenczewski@arm.com, broonie@kernel.org,
kevin.brodsky@arm.com, james.clark@linaro.org, tabba@google.com,
mrigendra.chaubey@gmail.com, arnd@arndb.de,
anshuman.khandual@arm.com, x86@kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <SN6PR02MB41575306521E6223561F476FD4182@SN6PR02MB4157.namprd02.prod.outlook.com>
On 6/12/2026 11:45 PM, Michael Kelley wrote:
> From: Jinjie Ruan <ruanjinjie@huawei.com> Sent: Thursday, June 11, 2026 6:38 AM
>>
>> Support for parallel secondary CPU bringup is already utilized by x86,
>> MIPS, and RISC-V. This patch brings this capability to the arm64
>> architecture.
>>
>> Rework the global `secondary_data` accessed during early boot into
>> a per-CPU array. This array maps logical CPU IDs to MPIDR_EL1 values,
>> enabling the early boot code in head.S to resolve each secondary CPU's
>> logical ID concurrently.
>>
>> To fully enable HOTPLUG_PARALLEL, this patch implements:
>> 1) An arm64-specific arch_cpuhp_kick_ap_alive() handler.
>> 2) Callbacks to cpuhp_ap_sync_alive() inside secondary_start_kernel().
>>
>> Successfully tested on QEMU ARM64 virt machine (KVM on, 128 vCPUs).
>>
>> | test kernel | secondary CPUs boot time |
>> | --------------------- | -------------------- |
>> | Without this patch | 155.672 |
>> | cpuhp.parallel=0 | 62.897 |
>> | cpuhp.parallel=1 | 166.703 |
>
> The last two rows seem mixed up. I would expect parallel=0 to
> result in a longer boot time.
Hi, Michael,
The results are correct and not mixed up.
Compared to the original non‑HOTPLUG_PARALLEL approach, the advantage of
cpuhp.parallel=0 lies in its use of cpu_relax(`yield` on arm64) instead
of the wait_for_completion_timeout() mechanism (which may cause sleep
and context switching). This significantly reduces the overhead of VM
exits and context switches in a KVM guest, thereby cutting the secondary
CPU boot time by more than half.
Regarding cpuhp.parallel=1, I believe the reason it fails to optimize
boot time is that when a large number of CPUs issue the KICK_AP call
simultaneously, it results in severe lock contention within KVM, which
paradoxically slows down secondary CPU bringup. However, this needs
further investigation into the PSCI_CPU_ON code in KVM.
I'm testing these performance aspects on physical hardware, so the
results might be somewhat different because secondary CPU bringup
requires trapping into the ATF firmware.
Best regards,
Jinjie
>
> Michael
>
>>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/smp.h | 8 ++++++++
>> arch/arm64/kernel/head.S | 23 +++++++++++++++++++++++
>> arch/arm64/kernel/smp.c | 27 +++++++++++++++++++++++++++
>> 4 files changed, 59 insertions(+)
>>
>
>
^ permalink raw reply
* Re: [PATCH] 9p: fix WARN_ON when dropping nlink on files with nlink=0
From: Breno Leitao @ 2026-06-15 8:51 UTC (permalink / raw)
To: Dominique Martinet
Cc: Eric Van Hensbergen, Latchesar Ionkov, Christian Schoenebeck,
Andrew Morton, Eryu Guan, Yiwen Jiang, v9fs, linux-kernel, stable
In-Reply-To: <aeZNdxmYw1K0Swg9@codewreck.org>
On Tue, Apr 21, 2026 at 12:59:51AM +0900, Dominique Martinet wrote:
> Breno Leitao wrote on Mon, Apr 20, 2026 at 07:31:14AM -0700:
> > In cacheless mode the server is authoritative and the inode is on its
> > way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count()
> > entirely when neither CACHE_META nor CACHE_LOOSE is set, which both
> > avoids the warning and removes a class of nlink races (two concurrent
> > unlinkers observing nlink > 0 and both calling drop_nlink()) that an
> > nlink == 0 guard alone would only narrow rather than close.
>
> I need to check this doesn't actually leak memory or something but this
> sounds better to me, thanks.
>
> Please send as a proper PATCH mail and I'll tentatively apply for 7.2
> (a bit too late for 7.1)
Please, don't forget this one for 7.2. This is one is hurting me from
time to time.
Thanks,
--breno
^ permalink raw reply
* Re: [GIT pull] timers/ptp for v7.2-rc1
From: pr-tracker-bot @ 2026-06-15 8:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86
In-Reply-To: <178137556888.445890.317871355101283049.tglx@fw13>
The pull request you sent on Sat, 13 Jun 2026 23:25:22 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-ptp-2026-06-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2d6d57f889f3a5e7d19009c560ea2002cdde9fb8
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT pull] irq/drivers for v7.2-rc1
From: pr-tracker-bot @ 2026-06-15 8:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86
In-Reply-To: <178137556155.445890.9274985148046172962.tglx@fw13>
The pull request you sent on Sat, 13 Jun 2026 23:24:54 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-drivers-2026-06-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/857ae5a4459c600d70b9ad64c46a730c428770e2
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT pull] timers/nohz for v7.2-rc1
From: pr-tracker-bot @ 2026-06-15 8:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86
In-Reply-To: <178137556766.445890.17221615557871210068.tglx@fw13>
The pull request you sent on Sat, 13 Jun 2026 23:25:17 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-nohz-2026-06-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a53fcff8fc7530f59a8171824ed586200df724a0
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT pull] timers/vdso for v7.2-rc1
From: pr-tracker-bot @ 2026-06-15 8:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86
In-Reply-To: <178137557009.445890.4888837437985292773.tglx@fw13>
The pull request you sent on Sat, 13 Jun 2026 23:25:26 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-vdso-2026-06-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/186d3c4e92242351afc24d9784f31cb4cd08a4b7
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT pull] timers/core for v7.2-rc1
From: pr-tracker-bot @ 2026-06-15 8:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86
In-Reply-To: <178137556644.445890.6379164368087565389.tglx@fw13>
The pull request you sent on Sat, 13 Jun 2026 23:25:13 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-core-2026-06-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a60ce761d99ff2d9eefe33374c5f20726465a140
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v4 7/7] arm64: dts: qcom: mahua: Switch pcie5_phy ref clock to RPMH_CXO_CLK
From: Qiang Yu @ 2026-06-15 8:51 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <db074223-ac01-4ffe-ae82-187ef0cb2cbb@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 03:06:02PM +0200, Konrad Dybcio wrote:
> On 5/28/26 4:29 AM, Qiang Yu wrote:
> > PCIe5 PHY on Mahua gets refclk from CXO0 pad directly, so no QREF
> > clkref_en voting is required. Override the clock list to use RPMH_CXO_CLK
> > directly instead.
>
> This is the last piece of the puzzle that this series is missing.
> There's no QREF clkref_en, but there is a refgen that needs to be
> powered. For PCIe5 on Mahua this would be L2F_E0 (0p9) and L4H_E0
> (1p2).
>
> I think the easiest (laziest?) solution would be to add dummy clocks
> in the clkref driver and only toggle the required regulators. Another
> option is to defer back to individual drivers (such as PCIe QMPPHY).
>
> I kinda like the "one central node to drive power" approach, but I'm
> not sure others agree, since it stretches truth just a tiny bit
> (although not as much as one would think since there are *some*
> controls for the transparent-to-the-OS hw pieces in these paths still
> in TCSR).. Dmitry, Krzysztof, would you object to that?
>
PCIe5 PHY on Mahua does not use QREF at all, so there is no refgen for
QREF either. The refgen supplies you mentioned are for the PCIe5 PHY
itself, not for QREF. For other PHYs that do use QREF, there are two
refgens: one for QREF (voted here in the TCSR clkref driver) and one for
the PHY (which should be voted in the PHY driver).
- Qiang Yu
> Konrad
^ permalink raw reply
* Re: [GIT pull] timers/clocksource for v7.2-rc1
From: pr-tracker-bot @ 2026-06-15 8:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86
In-Reply-To: <178137556520.445890.13394636551789463159.tglx@fw13>
The pull request you sent on Sat, 13 Jun 2026 23:25:08 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-clocksource-2026-06-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f20e2fdaaeb74330a6c5d65af22a8c47409a7a91
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT pull] irq/core for v7.2-rc1
From: pr-tracker-bot @ 2026-06-15 8:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86
In-Reply-To: <178137556026.445890.6319042373384832589.tglx@fw13>
The pull request you sent on Sat, 13 Jun 2026 23:24:50 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-2026-06-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/13e1a6d6a17eb4bca350e5bf59a89a3056c834ca
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT pull] smp/core for v7.2-rc1
From: pr-tracker-bot @ 2026-06-15 8:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86
In-Reply-To: <178137556398.445890.8664475273449229722.tglx@fw13>
The pull request you sent on Sat, 13 Jun 2026 23:25:04 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp-core-2026-06-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9e94480d81b9eb9bd175499636bf622e5d62176d
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT pull] irq/msi for v7.2-rc1
From: pr-tracker-bot @ 2026-06-15 8:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86
In-Reply-To: <178137556276.445890.17155896169437072988.tglx@fw13>
The pull request you sent on Sat, 13 Jun 2026 23:24:59 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-msi-2026-06-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8f45c6ce4959edee1ed25131fc14ce8bd261ca35
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT pull] core/rseq for v7.2-rc1
From: pr-tracker-bot @ 2026-06-15 8:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86
In-Reply-To: <178137555902.445890.9588113013654487803.tglx@fw13>
The pull request you sent on Sat, 13 Jun 2026 23:24:45 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rseq-2026-06-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a04c8472b0bc99963283e379f4ca2c775be4949b
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [PATCH v8 2/2] scsi: ufs: core: Add support for static TX Equalization settings
From: Can Guo @ 2026-06-15 8:50 UTC (permalink / raw)
To: krzk, bvanassche, beanhuo, peter.wang, martin.petersen, mani
Cc: linux-scsi, Can Guo, Alim Akhtar, Avri Altman,
James E.J. Bottomley, Nitin Rawat, Ram Kumar Dwivedi, open list
In-Reply-To: <20260615085027.2102882-1-can.guo@oss.qualcomm.com>
Parse board-specific static TX Equalization settings from Device Tree for
each HS gear and store them in hba->tx_eq_params.
Parse txeq-preshoot-g[1-6] and txeq-deemphasis-g[1-6] as per-lane tuples:
<Host_Lane0 Device_Lane0>, [<Host_Lane1 Device_Lane1>].
For HS-G6, parse optional tx-precode-enable-g6 using the same per-lane
Host/Device tuple format. If provided, it must contain values for all
active lanes, and each value must be 0 or 1.
Introduce from_dt in struct ufshcd_tx_eq_params to track whether TX EQ
values came from static Device Tree data.
When adaptive TX Equalization is used, these static settings are not final:
- If valid settings are retrieved from qTxEQGnSettings/wTxEQGnSettingsExt,
those retrieved settings override static Device Tree settings.
- If retrieval is not available/valid, TX EQTR runs and trained settings
override static Device Tree settings.
So static Device Tree settings are a fallback for cases where adaptive TX
Equalization is not enabled or not used. Adaptive TX Equalization remains
the primary path when enabled.
No behavior changes for platforms that do not provide these properties.
Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
---
drivers/ufs/core/ufs-txeq.c | 15 ++-
drivers/ufs/host/ufshcd-pltfrm.c | 156 +++++++++++++++++++++++++++++++
include/ufs/ufshcd.h | 2 +
3 files changed, 172 insertions(+), 1 deletion(-)
diff --git a/drivers/ufs/core/ufs-txeq.c b/drivers/ufs/core/ufs-txeq.c
index 4b264adfdf49..63616f8c2f74 100644
--- a/drivers/ufs/core/ufs-txeq.c
+++ b/drivers/ufs/core/ufs-txeq.c
@@ -1297,7 +1297,13 @@ int ufshcd_config_tx_eq_settings(struct ufs_hba *hba,
}
params = &hba->tx_eq_params[gear - 1];
- if (!params->is_valid || force_tx_eqtr) {
+ /*
+ * TX EQTR must run for the following cases:
+ * 1. TX EQ settings are invalid.
+ * 2. TX EQ settings are from Device Tree.
+ * 3. TX EQTR procedure is forced.
+ */
+ if (!params->is_valid || params->from_dt || force_tx_eqtr) {
int ret;
ret = ufshcd_tx_eqtr(hba, params, pwr_mode);
@@ -1310,6 +1316,8 @@ int ufshcd_config_tx_eq_settings(struct ufs_hba *hba,
/* Mark TX Equalization settings as valid */
params->is_valid = true;
params->is_trained = true;
+ /* TX EQTR succeeds, clear from_dt flag */
+ params->from_dt = false;
params->is_applied = false;
}
@@ -1495,6 +1503,11 @@ static void ufshcd_extract_tx_eq_settings_attrs(struct ufs_hba *hba, u8 gear)
}
params->is_valid = true;
+ /*
+ * Optimal TX EQ settings are retrieved from UFS device attributes,
+ * clear from_dt flag to avoid TX EQTR procedure.
+ */
+ params->from_dt = false;
}
void ufshcd_retrieve_tx_eq_settings(struct ufs_hba *hba)
diff --git a/drivers/ufs/host/ufshcd-pltfrm.c b/drivers/ufs/host/ufshcd-pltfrm.c
index c2dafb583cf5..5cf934bf10d0 100644
--- a/drivers/ufs/host/ufshcd-pltfrm.c
+++ b/drivers/ufs/host/ufshcd-pltfrm.c
@@ -210,6 +210,160 @@ static void ufshcd_init_lanes_per_dir(struct ufs_hba *hba)
}
}
+static int ufshcd_parse_tx_precode_enable(struct ufs_hba *hba,
+ bool host_precode_en[UFS_MAX_LANES],
+ bool device_precode_en[UFS_MAX_LANES])
+{
+ const char *prop_name = "tx-precode-enable-g6";
+ u32 num_elems = 2 * hba->lanes_per_direction;
+ const u32 lpd = hba->lanes_per_direction;
+ u32 precode[UFS_MAX_LANES * 2];
+ struct device *dev = hba->dev;
+ struct property *prop;
+ int count, err, i;
+
+ prop = of_find_property(dev->of_node, prop_name, NULL);
+ if (!prop)
+ return 0;
+
+ count = of_property_count_u32_elems(dev->of_node, prop_name);
+ if (count < 0)
+ return count;
+
+ if (count != num_elems) {
+ dev_err(dev, "Property %s has invalid count (%d), expecting %u\n",
+ prop_name, count, num_elems);
+ return -EINVAL;
+ }
+
+ err = of_property_read_u32_array(dev->of_node, prop_name, precode, num_elems);
+ if (err) {
+ dev_err(dev, "Failed to read %s property, %d\n", prop_name, err);
+ return err;
+ }
+
+ for (i = 0; i < num_elems; i++) {
+ if (precode[i] > 1) {
+ dev_err(dev, "Invalid TX precode value (%u) in %s property\n",
+ precode[i], prop_name);
+ return -EINVAL;
+ }
+ }
+
+ for (i = 0; i < lpd; i++) {
+ host_precode_en[i] = precode[i * 2];
+ device_precode_en[i] = precode[i * 2 + 1];
+ }
+
+ return 0;
+}
+
+static int ufshcd_parse_tx_eq_value_array(struct ufs_hba *hba,
+ const char *prop_name,
+ const u32 max_value,
+ u32 values[UFS_MAX_LANES * 2])
+{
+ u32 num_elems = 2 * hba->lanes_per_direction;
+ struct device *dev = hba->dev;
+ int count, err, i;
+
+ count = of_property_count_u32_elems(dev->of_node, prop_name);
+ if (count < 0)
+ return count;
+
+ if (count != num_elems) {
+ dev_err(dev, "Property %s has invalid count (%d), expecting %u\n",
+ prop_name, count, num_elems);
+ return -EINVAL;
+ }
+
+ err = of_property_read_u32_array(dev->of_node, prop_name, values, num_elems);
+ if (err) {
+ dev_err(dev, "Failed to read %s property, %d\n", prop_name, err);
+ return err;
+ }
+
+ for (i = 0; i < num_elems; i++) {
+ if (values[i] >= max_value) {
+ dev_err(dev, "Invalid TX EQ value (%u) in %s property\n",
+ values[i], prop_name);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * ufshcd_parse_tx_eq_settings_for_gear - Parse static TX EQ DT settings for one gear
+ * @hba: per adapter instance
+ * @gear: target HS gear
+ *
+ * Reads the txeq-preshoot-gN, txeq-deemphasis-gN, and (for G6)
+ * tx-precode-enable-g6 device-tree properties.
+ * If all present values are valid, stores them as static TX Equalization
+ * settings for the given gear.
+ */
+static void ufshcd_parse_tx_eq_settings_for_gear(struct ufs_hba *hba, int gear)
+{
+ bool device_precode_en[UFS_MAX_LANES] = { false };
+ bool host_precode_en[UFS_MAX_LANES] = { false };
+ const u32 lpd = hba->lanes_per_direction;
+ struct ufshcd_tx_eq_params *params;
+ u32 deemphasis[UFS_MAX_LANES * 2];
+ u32 preshoot[UFS_MAX_LANES * 2];
+ char prop_name[MAX_PROP_SIZE];
+ int err, lane;
+
+ snprintf(prop_name, MAX_PROP_SIZE, "txeq-preshoot-g%d", gear);
+ err = ufshcd_parse_tx_eq_value_array(hba, prop_name, TX_HS_NUM_PRESHOOT, preshoot);
+ if (err)
+ return;
+
+ snprintf(prop_name, MAX_PROP_SIZE, "txeq-deemphasis-g%d", gear);
+ err = ufshcd_parse_tx_eq_value_array(hba, prop_name, TX_HS_NUM_DEEMPHASIS, deemphasis);
+ if (err)
+ return;
+
+ if (gear == UFS_HS_G6) {
+ err = ufshcd_parse_tx_precode_enable(hba, host_precode_en, device_precode_en);
+ if (err)
+ return;
+ }
+
+ params = &hba->tx_eq_params[gear - 1];
+ for (lane = 0; lane < lpd; lane++) {
+ params->host[lane].preshoot = preshoot[lane * 2];
+ params->host[lane].deemphasis = deemphasis[lane * 2];
+ params->host[lane].precode_en = host_precode_en[lane];
+
+ params->device[lane].preshoot = preshoot[lane * 2 + 1];
+ params->device[lane].deemphasis = deemphasis[lane * 2 + 1];
+ params->device[lane].precode_en = device_precode_en[lane];
+ }
+
+ params->is_valid = true;
+ params->from_dt = true;
+}
+
+static void ufshcd_parse_static_tx_eq_settings(struct ufs_hba *hba)
+{
+ const u32 lpd = hba->lanes_per_direction;
+ int gear;
+
+ if (!lpd)
+ return;
+
+ if (lpd > UFS_MAX_LANES) {
+ dev_warn(hba->dev, "lanes_per_direction (%u) exceeds UFS_MAX_LANES (%u)\n",
+ lpd, UFS_MAX_LANES);
+ return;
+ }
+
+ for (gear = UFS_HS_G1; gear <= UFS_HS_GEAR_MAX; gear++)
+ ufshcd_parse_tx_eq_settings_for_gear(hba, gear);
+}
+
/**
* ufshcd_parse_clock_min_max_freq - Parse MIN and MAX clocks freq
* @hba: per adapter instance
@@ -528,6 +682,8 @@ int ufshcd_pltfrm_init(struct platform_device *pdev,
ufshcd_init_lanes_per_dir(hba);
+ ufshcd_parse_static_tx_eq_settings(hba);
+
err = ufshcd_parse_operating_points(hba);
if (err) {
dev_err(dev, "%s: OPP parse failed %d\n", __func__, err);
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index f48d6416e299..0f87b081b2ff 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -359,6 +359,7 @@ struct ufshcd_tx_eqtr_record {
* @is_valid: True if parameter contains valid TX Equalization settings
* @is_applied: True if settings have been applied to UniPro of both sides
* @is_trained: True if parameters obtained from TX EQTR procedure
+ * @from_dt: True if settings are from Device Tree
*/
struct ufshcd_tx_eq_params {
struct ufshcd_tx_eq_settings host[UFS_MAX_LANES];
@@ -367,6 +368,7 @@ struct ufshcd_tx_eq_params {
bool is_valid;
bool is_applied;
bool is_trained;
+ bool from_dt;
};
/**
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/6] irqchip/gic-v3-its: Fix LPI range leak and refactor error handler in its_lpi_alloc()
From: Marc Zyngier @ 2026-06-15 8:52 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260615032910.54735-2-shikemeng@huaweicloud.com>
On Mon, 15 Jun 2026 04:29:05 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> Fix the LIP range leak when bitmap_zalloc() failed. Besides refactor
Typo.
> error handling code to make it a little simpler.
No. Please don't mix fixes and (totally pointless) refactoring.
>
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 291d7668cc8d..2b7b546c43c8 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -2217,10 +2217,9 @@ static int __init its_lpi_init(u32 id_bits)
> static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
> {
> unsigned long *bitmap = NULL;
> - int err = 0;
>
> do {
> - err = alloc_lpi_range(nr_irqs, base);
> + int err = alloc_lpi_range(nr_irqs, base);
> if (!err)
> break;
>
> @@ -2228,22 +2227,20 @@ static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
> } while (nr_irqs > 0);
>
> if (!nr_irqs)
> - err = -ENOSPC;
> -
> - if (err)
> - goto out;
> + goto err_out;
>
> bitmap = bitmap_zalloc(nr_irqs, GFP_ATOMIC);
> if (!bitmap)
> - goto out;
> + goto err_free_lpi;
>
> *nr_ids = nr_irqs;
> -
> -out:
> - if (!bitmap)
> - *base = *nr_ids = 0;
> -
> return bitmap;
> +
> +err_free_lpi:
> + free_lpi_range(*base, nr_irqs);
> +err_out:
> + *base = *nr_ids = 0;
> + return NULL;
> }
>
> static void its_lpi_free(unsigned long *bitmap, u32 base, u32 nr_ids)
Honestly, I question the validity of handling errors this way. You are
already unable to allocate a per-device bitmap. And yet you are
calling free_lpi_range(), which has the interesting property of
*allocating* memory. Which you don't have. Oh wait...
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] bpf: Preserve pointer spill metadata during half-slot cleanup
From: bot+bpf-ci @ 2026-06-15 8:48 UTC (permalink / raw)
To: gnq25, ast, daniel, andrii, eddyz87, memxor, martin.lau, song,
yonghong.song, jolsa, emil, shuah
Cc: bpf, linux-kernel, linux-kselftest, gnq25, ast, andrii, daniel,
martin.lau, eddyz87, yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260615-f01-06-half-slot-pointer-spill-v1-1-47f1c18a8965@mails.tsinghua.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
> bpf: Preserve pointer spill metadata during half-slot cleanup
>
> __clean_func_state() cleans dead stack slots in 4-byte halves. When the
> high half of a STACK_SPILL slot is dead and the low half remains live,
> cleanup converts the live low half to STACK_MISC or STACK_ZERO and clears
> the saved spilled_ptr metadata.
>
> That conversion is safe only for scalar spills. For a pointer spill, this
> metadata clear lets a later 32-bit fill from the still-live half avoid the
> normal non-scalar register-fill check and be treated as an ordinary scalar
> stack read.
>
> Leave non-scalar spill slots intact in this half-live shape. This is
> conservative for pruning and preserves the existing
> check_stack_read_fixed_off() rejection path for partial fills from pointer
> spills.
>
> Fixes: 2cb27158adb3 ("bpf: poison dead stack slots")
> Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
Is the Fixes: tag pointing at the right commit?
The commit referenced, 2cb27158adb3 ("bpf: poison dead stack slots"), adds
STACK_POISON handling in kernel/bpf/verifier.c and does not contain the
half-slot cleanup logic being corrected here.
The 4-byte half-slot cleanup in __clean_func_state() that downgrades a
still-live STACK_SPILL low half to STACK_MISC/STACK_ZERO and clears the
saved spilled_ptr metadata without checking for SCALAR_VALUE was introduced
by be23266b4a08 ("bpf: 4-byte precise clean_verifier_state"). That commit
added the lo_live/hi_live model and the exact block this patch corrects:
if (lo_live && stype == STACK_SPILL) {
be23266b4a08 predates both 2cb27158adb3 and this fix. Should the tag be:
Fixes: be23266b4a08 ("bpf: 4-byte precise clean_verifier_state")
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27533304560
^ permalink raw reply
* Re: [PATCH v4 28/39] drm/msm/dp: Mark the SST bridge disconnected when mst is active
From: Yongxing Mou @ 2026-06-15 8:47 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Sean Paul,
Marijn Suijten, David Airlie, Simona Vetter, Jessica Zhang,
linux-arm-msm, dri-devel, freedreno, linux-kernel, Abhinav Kumar
In-Reply-To: <ge2bgx7rn4vcyptf4cd7hnodnycrg7gdjceqq5zdncmdmmnjlu@2cuu3lcotxeb>
On 4/12/2026 8:11 AM, Dmitry Baryshkov wrote:
> On Fri, Apr 10, 2026 at 05:34:03PM +0800, Yongxing Mou wrote:
>> From: Abhinav Kumar <quic_abhinavk@quicinc.com>
>>
>> The bridge detect function is only applicable for SST. In MST mode,
>> connector detection is handled by MST bridges. This patch skips
>> detection for the SST bridge when MST is active.
>
> "This patch"
>
Sorry, I missed that earlier. I’ve fixed it in this version.
>>
>> Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> ---
>> drivers/gpu/drm/msm/dp/dp_display.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>
^ permalink raw reply
page: next (older)
- 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