* [PATCH v3 02/17] ACPI: GTDT: Parse information related to the EL2 virtual timer
From: Marc Zyngier @ 2026-05-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-acpi, linux-kernel, devicetree
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <20260523140242.586031-1-maz@kernel.org>
Now that we have a way to identify GTDTv3, allow the information
related to the EL2 virtual timer to be retrieved by the interface
used by the architected timer driver.
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/acpi/arm64/gtdt.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
index 950d5efdf85ea..00158c8aa6d90 100644
--- a/drivers/acpi/arm64/gtdt.c
+++ b/drivers/acpi/arm64/gtdt.c
@@ -41,6 +41,14 @@ struct gtdt_v3 {
static struct acpi_gtdt_descriptor acpi_gtdt_desc __initdata;
+static __init struct acpi_gtdt_el2 *gtdt_to_el2_vtimer(struct acpi_table_gtdt *gtdt)
+{
+ if (gtdt->header.revision < 3)
+ return NULL;
+
+ return &container_of(gtdt, struct gtdt_v3, gtdt_v2)->el2_vtimer;
+}
+
static __init bool platform_timer_valid(void *platform_timer)
{
struct acpi_gtdt_header *gh = platform_timer;
@@ -112,6 +120,7 @@ static int __init map_gt_gsi(u32 interrupt, u32 flags)
int __init acpi_gtdt_map_ppi(int type)
{
struct acpi_table_gtdt *gtdt = acpi_gtdt_desc.gtdt;
+ struct acpi_gtdt_el2 *el2_vtimer = gtdt_to_el2_vtimer(gtdt);
switch (type) {
case ARCH_TIMER_PHYS_NONSECURE_PPI:
@@ -124,6 +133,12 @@ int __init acpi_gtdt_map_ppi(int type)
case ARCH_TIMER_HYP_PPI:
return map_gt_gsi(gtdt->non_secure_el2_interrupt,
gtdt->non_secure_el2_flags);
+ case ARCH_TIMER_HYP_VIRT_PPI:
+ if (el2_vtimer && el2_vtimer->virtual_el2_timer_gsiv)
+ return map_gt_gsi(el2_vtimer->virtual_el2_timer_gsiv,
+ el2_vtimer->virtual_el2_timer_flags);
+
+ return 0;
default:
pr_err("Failed to map timer interrupt: invalid type.\n");
}
@@ -141,6 +156,7 @@ int __init acpi_gtdt_map_ppi(int type)
bool __init acpi_gtdt_c3stop(int type)
{
struct acpi_table_gtdt *gtdt = acpi_gtdt_desc.gtdt;
+ struct acpi_gtdt_el2 *el2_vtimer = gtdt_to_el2_vtimer(gtdt);
switch (type) {
case ARCH_TIMER_PHYS_NONSECURE_PPI:
@@ -152,6 +168,10 @@ bool __init acpi_gtdt_c3stop(int type)
case ARCH_TIMER_HYP_PPI:
return !(gtdt->non_secure_el2_flags & ACPI_GTDT_ALWAYS_ON);
+ case ARCH_TIMER_HYP_VIRT_PPI:
+ return el2_vtimer && el2_vtimer->virtual_el2_timer_gsiv &&
+ !(el2_vtimer->virtual_el2_timer_flags & ACPI_GTDT_ALWAYS_ON);
+
default:
pr_err("Failed to get c3stop info: invalid type.\n");
}
--
2.47.3
^ permalink raw reply related
* [PATCH v3 00/17] arm64: Use EL2 virtual timer when running VHE
From: Marc Zyngier @ 2026-05-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-acpi, linux-kernel, devicetree
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
This is the third version of the series initially posted at [1],
which
- updates the ACPI GTDT parsing to deal the v3 layout and the EL2
virtual timer,
- moves the architected timer driver to use it when running VHE,
- fixes a number of DTs to reflect the reality of the HW.
This results in significant performance uplift in deeper nested virt
scenarios, at no overhead to the host.
Patches based on -rc3, tested on Amlogic SM1, QC X1E, Ampere Altra,
and Apple M2, as well as KVM NV guests.
* From v2 [2]:
- Add more consistency checks to the GTDT parsing
- Match the virtual counter when using the KVM PTP backend
- Drop a number of changes to Qualcomm DTs, being only tangentially
related and that will be posted separately
- Fix the Realtek Kent platform, which had the GICv3 maintenance
interrupt advertised as the EL2 virtual timer
- Collected TBs and RBs, with thanks
* From v1 [2]:
- Now also using the EL2 virtual counter, which further improve
things when running at a deeper nesting level
- Updated consistency checks for the platform timers when finding a
GTDTv3
- Collected ABs and RBs, with thanks
[1] https://lore.kernel.org/r/20260507125544.2903406-1-maz@kernel.org
[2] https://lore.kernel.org/r/20260514150945.3917510-1-maz@kernel.org
Marc Zyngier (17):
ACPI: GTDT: Account for GTDTv3 size when walking the platform timer
descriptors
ACPI: GTDT: Parse information related to the EL2 virtual timer
clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when
running VHE
dt-bindings: timer: arm,arch_timer: Fix requirements for interrupt
description
arm64: dts: allwinner: Add EL2 virtual timer interrupt
arm64: dts: amlogic: Add EL2 virtual timer interrupt
arm64: dts: bst: Add EL2 virtual timer interrupt
arm64: dts: exynos: Add EL2 virtual timer interrupt
arm64: dts: freescale: Add EL2 virtual timer interrupt
arm64: dts: intel: Add EL2 virtual timer interrupt
arm64: dts: mediatek: Add EL2 virtual timer interrupt
arm64: dts: nvidia: Add EL2 virtual timer interrupt
arm64: dts: qcom: Add EL2 virtual timer interrupt
arm64: dts: realtek: Add EL2 virtual timer interrupt
arm64: dts: rockchip: Add EL2 virtual timer interrupt
arm64: dts: sprd: Add EL2 virtual timer interrupt
arm64: dts: xilinx: Add EL2 virtual timer interrupt
.../bindings/timer/arm,arch_timer.yaml | 21 +++----
.../arm64/boot/dts/allwinner/sun55i-a523.dtsi | 3 +-
.../boot/dts/amlogic/amlogic-a4-common.dtsi | 8 ---
arch/arm64/boot/dts/amlogic/amlogic-a4.dtsi | 8 +++
arch/arm64/boot/dts/amlogic/amlogic-a5.dtsi | 9 +++
arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi | 3 +-
arch/arm64/boot/dts/amlogic/amlogic-s7.dtsi | 3 +-
arch/arm64/boot/dts/amlogic/amlogic-s7d.dtsi | 3 +-
.../boot/dts/amlogic/meson-g12-common.dtsi | 13 -----
arch/arm64/boot/dts/amlogic/meson-g12.dtsi | 9 +++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 10 ++++
arch/arm64/boot/dts/bst/bstc1200.dtsi | 3 +-
arch/arm64/boot/dts/exynos/axis/artpec9.dtsi | 3 +-
arch/arm64/boot/dts/exynos/exynos2200.dtsi | 3 +-
arch/arm64/boot/dts/exynos/exynos990.dtsi | 3 +-
arch/arm64/boot/dts/exynos/exynosautov9.dtsi | 3 +-
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 3 +-
.../boot/dts/freescale/imx91_93_common.dtsi | 3 +-
arch/arm64/boot/dts/freescale/imx94.dtsi | 3 +-
arch/arm64/boot/dts/freescale/imx95.dtsi | 3 +-
arch/arm64/boot/dts/freescale/imx952.dtsi | 3 +-
arch/arm64/boot/dts/freescale/s32n79.dtsi | 3 +-
.../arm64/boot/dts/intel/socfpga_agilex5.dtsi | 3 +-
arch/arm64/boot/dts/mediatek/mt6779.dtsi | 3 +-
arch/arm64/boot/dts/mediatek/mt8186.dtsi | 3 +-
arch/arm64/boot/dts/mediatek/mt8188.dtsi | 3 +-
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 3 +-
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 3 +-
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 3 +-
arch/arm64/boot/dts/qcom/eliza.dtsi | 3 +-
arch/arm64/boot/dts/qcom/hamoa.dtsi | 3 +-
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 3 +-
arch/arm64/boot/dts/qcom/kodiak.dtsi | 3 +-
arch/arm64/boot/dts/qcom/lemans.dtsi | 3 +-
arch/arm64/boot/dts/qcom/monaco.dtsi | 3 +-
arch/arm64/boot/dts/qcom/sar2130p.dtsi | 3 +-
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 3 +-
arch/arm64/boot/dts/qcom/sm4450.dtsi | 3 +-
arch/arm64/boot/dts/qcom/sm8250.dtsi | 3 +-
arch/arm64/boot/dts/qcom/sm8350.dtsi | 3 +-
arch/arm64/boot/dts/qcom/sm8450.dtsi | 3 +-
arch/arm64/boot/dts/qcom/sm8550.dtsi | 3 +-
arch/arm64/boot/dts/qcom/sm8650.dtsi | 3 +-
arch/arm64/boot/dts/qcom/sm8750.dtsi | 3 +-
arch/arm64/boot/dts/realtek/kent.dtsi | 2 +-
arch/arm64/boot/dts/realtek/rtd16xx.dtsi | 3 +-
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 3 +-
arch/arm64/boot/dts/sprd/sc9863a.dtsi | 3 +-
arch/arm64/boot/dts/sprd/ums512.dtsi | 3 +-
arch/arm64/boot/dts/sprd/ums9620.dtsi | 3 +-
arch/arm64/boot/dts/xilinx/versal-net.dtsi | 3 +-
drivers/acpi/arm64/gtdt.c | 42 +++++++++++++-
drivers/clocksource/arm_arch_timer.c | 55 +++++++++++--------
54 files changed, 206 insertions(+), 102 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH v3 01/17] ACPI: GTDT: Account for GTDTv3 size when walking the platform timer descriptors
From: Marc Zyngier @ 2026-05-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-acpi, linux-kernel, devicetree
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <20260523140242.586031-1-maz@kernel.org>
Since ARMv8.1, the architecture has grown an EL2-private virtual
timer. This has been described in ACPI since ACPI v6.3 and revision
3 of the GTDT table.
An aditional structure was added in ACPICA, though in a rather
bizarre way, and merged in v5.1 as 8f5a14d053100 ("ACPICA: ACPI 6.3:
add GTDT Revision 3 support").
Finally plug the table parsing in GTDT, and correct the parsing of
the platform timer subtables to account for the expanded size of
the base table. This also comes with some extra sanitisation of
the table, in the unlikely case someone got it wrong...
Suggested-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/acpi/arm64/gtdt.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
index ffc867bac2d60..950d5efdf85ea 100644
--- a/drivers/acpi/arm64/gtdt.c
+++ b/drivers/acpi/arm64/gtdt.c
@@ -34,14 +34,25 @@ struct acpi_gtdt_descriptor {
void *platform_timer;
};
+struct gtdt_v3 {
+ struct acpi_table_gtdt gtdt_v2;
+ struct acpi_gtdt_el2 el2_vtimer;
+};
+
static struct acpi_gtdt_descriptor acpi_gtdt_desc __initdata;
static __init bool platform_timer_valid(void *platform_timer)
{
struct acpi_gtdt_header *gh = platform_timer;
+ void *platform_timer_begin;
- return (platform_timer >= (void *)(acpi_gtdt_desc.gtdt + 1) &&
- platform_timer < acpi_gtdt_desc.gtdt_end &&
+ if (acpi_gtdt_desc.gtdt->header.revision >= 3)
+ platform_timer_begin = container_of(acpi_gtdt_desc.gtdt, struct gtdt_v3, gtdt_v2) + 1;
+ else
+ platform_timer_begin = acpi_gtdt_desc.gtdt + 1;
+
+ return (platform_timer >= platform_timer_begin &&
+ platform_timer + sizeof(*gh) <= acpi_gtdt_desc.gtdt_end &&
gh->length != 0 &&
platform_timer + gh->length <= acpi_gtdt_desc.gtdt_end);
}
@@ -166,6 +177,13 @@ int __init acpi_gtdt_init(struct acpi_table_header *table,
u32 cnt = 0;
gtdt = container_of(table, struct acpi_table_gtdt, header);
+
+ if ((gtdt->header.revision >= 3 && gtdt->header.length < sizeof(struct gtdt_v3)) ||
+ (gtdt->header.revision == 2 && gtdt->header.length < sizeof(*gtdt))) {
+ pr_err(FW_BUG "GTDT with invalid size %d\n", gtdt->header.length);
+ return -EINVAL;
+ }
+
acpi_gtdt_desc.gtdt = gtdt;
acpi_gtdt_desc.gtdt_end = (void *)table + table->length;
acpi_gtdt_desc.platform_timer = NULL;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] clk: canaan: k230: Fix sparse warnings reported by LKP
From: Conor Dooley @ 2026-05-23 14:02 UTC (permalink / raw)
To: Xukai Wang
Cc: Conor Dooley, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Paul Walmsley, Palmer Dabbelt,
Albert Ou, linux-clk, devicetree, linux-kernel, linux-riscv,
Samuel Holland, Troy Mitchell, Krzysztof Kozlowski
In-Reply-To: <1f74efd2-444f-4330-a1e8-62f75e85ecfa@zohomail.com>
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
On Sat, May 23, 2026 at 03:00:15PM +0800, Xukai Wang wrote:
>
> On 2026/5/23 04:39, Conor Dooley wrote:
> > On Fri, May 22, 2026 at 08:59:12PM +0800, Xukai Wang wrote:
> >> Fix all sparse warnings detected during LKP randconfig testing:
> >> - Replace plain integer 0 with NULL.
> >> - Add static modifier to k230_plls and k230_pll_divs.
> >>
> >> Reported-by: kernel test robot <lkp@intel.com>
> >> Closes: https://lore.kernel.org/oe-kbuild-all/202605220724.j4ZeM3KI-lkp@intel.com/
> >> Signed-off-by: Xukai Wang <kingxukai@zohomail.com>
> > Forgot to reply earlier, but I went and squashed this in.
> Thanks Conor!
I dunno if you saw my message about giving what I have in my
branches a go, but if you could try what's in the riscv-soc-for-next
branch, that'd be great. Just to make sure that I have all the bits in
place.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Can Guo @ 2026-05-23 13:47 UTC (permalink / raw)
To: 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: <20260523134711.323425-1-can.guo@oss.qualcomm.com>
UFS v5.0/UFSHCI v5.0 add HS-G6 support (46.6 Gbps/lane) via UniPro v3.0
and M-PHY v6.0. In these specs, TX Equalization is defined for all High
Speed Gears (not only HS-G6) to compensate channel loss and improve signal
integrity at high speed operation.
For HS-G6, M-PHY uses PAM4 1b1b line coding, Pre-Coding may also be
required depending on channel characteristics.
Add vendor-neutral DT patternProperties:
txeq-settings-g[1-6]
Each property is a uint32 array of per-lane tuples:
(PreShoot, DeEmphasis, PrecodeEn)
Tuple order is:
Host Lane 0, [Host Lane 1], Device Lane 0, [Device Lane 1]
Accept 2..4 tuples (6..12 u32 values) to cover x1/x2 lane configs. These
patternProperties carry board-level SI characterization data used as
static TX Equalization settings for each High Speed Gear.
Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/ufs/ufs-common.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
index ed97f5682509..bc83948fc168 100644
--- a/Documentation/devicetree/bindings/ufs/ufs-common.yaml
+++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
@@ -105,6 +105,17 @@ properties:
Restricts the UFS controller to rate-a or rate-b for both TX and
RX directions.
+patternProperties:
+ "^txeq-settings-g[1-6]$":
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 6
+ maxItems: 12
+ description: |
+ Static TX Equalization settings for High Speed (HS) gears.
+ The settings are specified as an array of tuples (PreShoot, DeEmphasis, PrecodeEn).
+ The array must contain these tuples in the following order:
+ Host Lane 0, [Host Lane 1], Device Lane 0, [Device Lane 1].
+
dependencies:
freq-table-hz: [ clocks ]
operating-points-v2: [ clocks, clock-names ]
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 2/4] hwmon: (pmbus/tps25990): Rework TPS25990 direct conversion handling
From: Guenter Roeck @ 2026-05-23 13:27 UTC (permalink / raw)
To: sashiko-reviews, Stoyan Bogdanov; +Cc: devicetree, linux-hwmon, robh, conor+dt
In-Reply-To: <20260522091252.9E5C01F00A3D@smtp.kernel.org>
On 5/22/26 02:12, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
>
> New issues:
> - [Critical] The custom conversion functions incorrectly retrieve I2C client data, leading to severe type confusion and out-of-bounds heap reads.
> - [High] Replacing ratio-based math with direct conversion helpers inside `read_word_data` and `write_word_data` introduces a double-conversion bug that completely corrupts sysfs output and configuration limits.
> - [High] Calling `pmbus_reg2data_direct_calc()` directly with negative `R` coefficients and small register values leads to a total loss of precision due to premature integer division.
> - [High] The patch silently drops the correct translation ratios for the Over-Current Fault Limit (`PMBUS_IIN_OC_FAULT_LIMIT`) and bypasses dynamic resistor scaling.
> - [Low] Spelling mistakes in the newly introduced `tps25990_parameters` enum comments.
>
> Pre-existing issues:
> - [High] When setting fault limits, an integer underflow on low user inputs leads to an unsigned wrap-around, causing `clamp_val()` to clamp to the maximum limit instead of the minimum limit, dangerously defeating hardware protection.
> --
>
> commit 11131ea034ce953233470df60e4f6a1c34cca609
> Author: Stoyan Bogdanov <sbogdanov@baylibre.com>
> Date: Fri May 22 08:23:37 2026 +0000
>
> hwmon: (pmbus/tps25990): Rework TPS25990 direct conversion handling
>
> Rework the existing implementation of direct format conversion for
> TPS25990 non-standard parameters to improve code reusability and
> integration with the PMBus direct conversion helpers.
>
>> diff --git a/drivers/hwmon/pmbus/tps25990.c b/drivers/hwmon/pmbus/tps25990.c
>> index 05c6288ecafcc..1e252844217b8 100644
>> --- a/drivers/hwmon/pmbus/tps25990.c
>> +++ b/drivers/hwmon/pmbus/tps25990.c
>
> [ ... ]
>
>> +enum tps25990_parameters {
>> + TPS25990_VIN_OVF = 0, /* VIN over volatage fault */
>> + TPS25990_IIN_OCF, /* IIN Over currect fault */
>
> [Severity: Low]
> This isn't a bug, but there are minor typos in the comments: volatage and
> currect.
>
>> + TPS25990_DIRECT_VALUES_COUNT,
>> +};
>
> [ ... ]
>
>> +static s64 tps25990_reg2data_direct(struct i2c_client *client, int param, s32 raw)
>> +{
>> + struct pmbus_driver_info *info = i2c_get_clientdata(client);
>> + struct tps25990_data *data = container_of(info, struct tps25990_data, info);
>
> [Severity: Critical]
> Does this correctly retrieve the driver info?
>
> Looking at pmbus_do_probe(), i2c_get_clientdata(client) is set to a
> struct pmbus_data * object, not a struct pmbus_driver_info * object.
>
> Using container_of() on the wrong type calculates a 0 offset, but improperly
> casts the pmbus_data object into a struct tps25990_data pointer, causing the
> subsequent read of info_local to fetch completely out-of-bounds heap memory.
>
> Should this use pmbus_get_driver_info(client) instead?
>
Did you even test this code ?
Guenter
>> + struct tps25990_local_direct_value *info_local = &data->info_local;
>> + s64 b, val;
>> + s32 m, R;
>> +
>> + val = (s16)raw;
>> + m = info_local->m[param];
>> + b = info_local->b[param];
>> + R = info_local->R[param];
>> +
>> + return pmbus_reg2data_direct_calc(val, b, m, R);
>
> [Severity: High]
> Can this result in a total loss of precision due to integer division?
>
> For TPS25990_VIN_OVF, R is -4 and the raw register value is a small 4-bit
> integer (0 to 15). The generic pmbus_reg2data_direct_calc() handles negative
> R by dividing the input by 10 for each R:
>
> pmbus_core.c:pmbus_reg2data_direct_calc() {
> ...
> while (R < 0) {
> val = div_s64(val + 5LL, 10L);
> R++;
> }
> ...
> }
>
> Dividing a small value like 15 by 10000 via integer division would truncate
> it to 0, permanently destroying the underlying data. Does this need
> pre-scaling before the calculation loop?
>
> [ ... ]
>
>> @@ -184,9 +230,7 @@ static int tps25990_read_word_data(struct i2c_client *client,
>> ret = pmbus_read_word_data(client, page, phase, reg);
>> if (ret < 0)
>> break;
>> - ret = DIV_ROUND_CLOSEST(ret * TPS25990_VIN_OVF_NUM,
>> - TPS25990_VIN_OVF_DIV);
>> - ret += TPS25990_VIN_OVF_OFF;
>> + ret = tps25990_reg2data_direct(client, TPS25990_VIN_OVF, ret);
>
> [Severity: High]
> Does this introduce a double-conversion bug?
>
> The driver's .read_word_data hook is expected to convert between the
> chip-specific raw register value and the standard PMBus raw format (Y_std).
> The PMBus core then converts Y_std to physical units.
>
> By calling pmbus_reg2data_direct_calc() directly here, does it return the
> physical value (e.g. milliVolts) rather than Y_std, causing the PMBus core
> to apply its standard conversion a second time to an already converted value?
>
> [ ... ]
>
>> @@ -246,17 +288,13 @@ static int tps25990_write_word_data(struct i2c_client *client,
>> break;
>>
>> case PMBUS_VIN_OV_FAULT_LIMIT:
>> - value -= TPS25990_VIN_OVF_OFF;
>> - value = DIV_ROUND_CLOSEST(((unsigned int)value) * TPS25990_VIN_OVF_DIV,
>> - TPS25990_VIN_OVF_NUM);
>> + value = tps25990_data2reg_direct(client, TPS25990_VIN_OVF, value);
>> value = clamp_val(value, 0, 0xf);
>
> [Severity: High]
> This is a pre-existing issue, but does this lead to an integer underflow
> that defeats hardware protection?
>
> The value parameter in tps25990_write_word_data() is an unsigned u16. If a
> sufficiently low limit (like 0) is converted, the mathematical result could
> be negative. This would wrap around the unsigned u16 to a large value
> (e.g., 65530).
>
> Since clamp_val() compares using the type of the passed variable, it would see
> the wrapped value as much greater than 15 and incorrectly clamp it to the
> maximum hardware limit (0xf) instead of the minimum limit.
>
>> ret = pmbus_write_word_data(client, page, reg, value);
>> break;
>>
>> case PMBUS_IIN_OC_FAULT_LIMIT:
>> - value -= TPS25990_IIN_OCF_OFF;
>> - value = DIV_ROUND_CLOSEST(((unsigned int)value) * TPS25990_IIN_OCF_DIV,
>> - TPS25990_IIN_OCF_NUM);
>> + value = tps25990_data2reg_direct(client, TPS25990_IIN_OCF, value);
>
> [Severity: High]
> Are we losing the dynamic resistor scaling here?
>
> The original code mapped TPS25990_VIREF to the standard Y_std format,
> allowing the PMBus core to dynamically convert it using the PSC_CURRENT_IN
> coefficients, which are adjusted in tps25990_probe() based on the
> ti,rimon-micro-ohms property.
>
> The new tps25990_data2reg_direct() call uses static coefficients from
> tps25990_local_info which are never updated by the rimon logic. Will this
> break the over-current limits for boards using a non-default rimon
> configuration?
>
>> value = clamp_val(value, 0, 0x3f);
>> ret = pmbus_write_byte_data(client, page, TPS25990_VIREF, value);
>> break;
>
^ permalink raw reply
* Re: [PATCH v4 1/4] hwmon: (pmbus) Add and export direct conversion calculation helpers
From: Guenter Roeck @ 2026-05-23 13:25 UTC (permalink / raw)
To: Stoyan Bogdanov, jbrunet, robh, krzk+dt, conor+dt, corbet, skhan
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260522082349.2749970-2-sbogdanov@baylibre.com>
On 5/22/26 01:23, Stoyan Bogdanov wrote:
> TPS25990 and upcoming TPS1689 need common computation APIs but
> the current implementation is static to TPS25990. As a preparation for
> TPS1689 support, split the math-only parts of pmbus_reg2data_direct() and
> pmbus_data2reg_direct() into separate helper functions:
>
> - pmbus_reg2data_direct_calc()
> - pmbus_data2reg_direct_calc()
>
> export them so the upcoming TPS1689 can use the same APIs.
>
> This has no behavioral change on TPS25990 while allowing TPS1689
> to use the same.
>
> Signed-off-by: Stoyan Bogdanov <sbogdanov@baylibre.com>
Please do not introduce new API functions without discussing it first.
Keep this in the driver.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 3/3] riscv: dts: spacemit: k1: Add Banana Pi BPI-CM6 IO board
From: Junhui Liu @ 2026-05-23 11:34 UTC (permalink / raw)
To: Junhui Liu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Yixun Lan, Vivian Wang, Paolo Abeni, Guodong Xu, Yangyu Chen
Cc: devicetree, linux-riscv, spacemit, linux-kernel
In-Reply-To: <20260522-bpi-cm6-v1-3-707ef1917a30@pigmoral.tech>
On Fri May 22, 2026 at 6:01 PM CST, Junhui Liu wrote:
> The Banana Pi BPI-CM6 IO board combines the BPI-CM6 compute module with
> an IO carrier board. The core module integrates the SpacemiT K1 SoC,
> PMIC, DDR, eMMC, the eth0 PHY, and wireless connectivity. The companion
> IO carrier board extends it by providing the eth1 PHY and exposing
> standard interfaces, including dual Gigabit Ethernet, MicroSD, two USB-A
> ports, a USB Type-C port, two PCIe M.2 slots, and a serial console.
>
> The board also has two I2C EEPROMs. One is on the core module, which
> stores factory manufacturing data and is marked read-only. The other is
> on the carrier board, which is shipped unprogrammed and left writable
> for evaluation purposes.
>
> Add initial support for UART console, eMMC, SD card, I2C, EEPROMs,
> PCIe, USB, and dual Ethernet interfaces.
>
> Link: https://docs.banana-pi.org/en/BPI-CM6/BananaPi_BPI-CM6
> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> ---
> arch/riscv/boot/dts/spacemit/Makefile | 1 +
> .../riscv/boot/dts/spacemit/k1-bananapi-cm6-io.dts | 215 +++++++++++++++++++
> arch/riscv/boot/dts/spacemit/k1-bananapi-cm6.dtsi | 227 +++++++++++++++++++++
> 3 files changed, 443 insertions(+)
>
[...]
> +
> +&pcie1_port {
> + phys = <&pcie1_phy>;
> + vpcie3v3-supply = <&pcie_vcc_3v3>;
> +};
> +
> +&pcie1 {
> + vpcie3v3-supply = <&pcie_vcc_3v3>;
Thanks for the reminder from Sashiko AI.
The vpcie3v3-supply property should be removed from the PCIe host
controller node here. According to the binding, this supply belongs to
the PCIe root port child node.
I have checked the driver side: devm_regulator_get_enable() eventually
calls of_get_regulator(), which first looks up the supply in the current
device node and then falls back to searching child nodes if it is not
found there. I also verified on hardware that keeping vpcie3v3-supply
only in the port node still lets the driver resolve the regulator
correctly.
So I will drop the duplicate vpcie3v3-supply property here in the next
version.
> + status = "okay";
> +};
> +
> +&pcie2_phy {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie2_4_cfg>;
> + status = "okay";
> +};
> +
> +&pcie2_port {
> + phys = <&pcie2_phy>;
> + vpcie3v3-supply = <&pcie_vcc_3v3>;
> +};
> +
> +&pcie2 {
> + vpcie3v3-supply = <&pcie_vcc_3v3>;
Same here.
> + status = "okay";
> +};
> +
[...]
--
Best regards,
Junhui Liu
^ permalink raw reply
* Re: [PATCH V9 3/3] arm64: dts: qcom: glymur-crd: add Audio sound card node
From: sashiko-bot @ 2026-05-23 11:25 UTC (permalink / raw)
To: Sibi Sankar; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260523085511.2532669-4-sibi.sankar@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The WSA8845 speaker nodes incorrectly use the `reset-gpios` property and directly share GPIO lines, which will result in ignored resets and probe failures.
- [High] The `&lpass_vamacro` node is missing the `vdd-micb-supply` property, which is required by the defined audio routing and will cause DMIC recording to fail silently.
--
commit 2f0fde1acdca88bc05fbbb5ed700dfb37ffa6d5c
Author: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
arm64: dts: qcom: glymur-crd: add Audio sound card node
Add the sound card of Glymur-crd board with the routing for speakers,
including playback via WSA884x smart speakers and recording via DMIC
microphones.
> diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> index e784b538f42e1..6c272fb6081a8 100644
> --- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
[ ... ]
> @@ -444,6 +492,12 @@ vreg_l4h_e0_1p2: ldo4 {
> };
> };
>
> +&lpass_vamacro {
> + pinctrl-0 = <&dmic01_default>, <&dmic23_default>;
> + pinctrl-names = "default";
> + qcom,dmic-sample-rate = <4800000>;
> +};
[Severity: High]
The audio routing explicitly maps the Digital Microphones to the vdd-micb
widget, but is this lpass_vamacro node missing the vdd-micb-supply property?
The lpass-va-macro driver uses DAPM to manage the power state for this widget.
Without the vdd-micb-supply property here, the regulator framework will silently
substitute a dummy regulator.
This will cause DAPM to report success while the hardware won't receive the
required microphone bias voltage, resulting in silent audio recordings on the
DMIC capture path.
[ ... ]
> +&swr0 {
> + status = "okay";
> +
> + /* WSA8845, Left Woofer */
> + left_woofer: speaker@0,0 {
> + compatible = "sdw20217020400";
> + reg = <0 0>;
> + reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
[Severity: High]
Is reset-gpios the correct property name for this codec?
The wsa884x codec driver expects either a reset controller via the resets
property or powerdown-gpios. Using reset-gpios will result in the driver
finding neither, leaving the speakers in hardware reset and failing to
enumerate on the SoundWire bus.
Additionally, if this were renamed to powerdown-gpios, would the shared GPIO
line cause a probe failure?
The left_tweeter node below also uses GPIO 12, which would cause the second
speaker's probe to fail with -EBUSY because devm_gpiod_get_optional requests
exclusive access.
Should this use a gpio-reset controller defined and referenced via the resets
property instead to properly share the line?
> + #sound-dai-cells = <0>;
> + sound-name-prefix = "WooferLeft";
> + vdd-1p8-supply = <&vreg_l15b_e0_1p8>;
> + vdd-io-supply = <&vreg_l18b_e0_1p2>;
> + qcom,port-mapping = <1 2 3 7 12 14>;
> + };
> +
> + /* WSA8845, Left Tweeter */
> + left_tweeter: speaker@0,1 {
> + compatible = "sdw20217020400";
> + reg = <0 1>;
> + reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523085511.2532669-1-sibi.sankar@oss.qualcomm.com?part=3
^ permalink raw reply
* Re: [PATCH RESEND] arm64: dts: mediatek: add LED and key support on Xiaomi AX3000T
From: sashiko-bot @ 2026-05-23 10:37 UTC (permalink / raw)
To: Aleksander Jan Bajkowski; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260523101904.293215-1-olek2@wp.pl>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `key-mesh` node incorrectly pairs `linux,code = <BTN_9>` with `linux,input-type = <EV_SW>`. Since `BTN_9` (265) exceeds `SW_MAX`, the input subsystem rejects the capability, causing a kernel error splat on boot and rendering the button completely non-functional.
--
commit b3e6ab558b15225bf59d262cc68b446d232036a9
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
arm64: dts: mediatek: add LED and key support on Xiaomi AX3000T
This commit adds device tree support for the physical buttons and
status LEDs present on the Xiaomi AX3000T router.
> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts b/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts
> index a314c3e05e500..db399cb3ead73 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts
[ ... ]
> @@ -12,4 +15,37 @@ memory@40000000 {
> reg = <0 0x40000000 0 0x10000000>;
> device_type = "memory";
> };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + key-mesh {
> + label = "MESH";
> + gpios = <&pio 0 GPIO_ACTIVE_LOW>;
> + linux,code = <BTN_9>;
> + linux,input-type = <EV_SW>;
[Severity: Medium]
Will this combination of EV_SW and BTN_9 cause a capability rejection
during boot?
During the gpio-keys driver probe, input_set_capability() is called to
register the button capability. This function strictly bounds-checks the
event code against the maximum for the given type.
For EV_SW, input_max_code is SW_MAX (17). Since BTN_9 (265) exceeds SW_MAX,
the check fails, causing the kernel to print an error splat and return
early without registering the switch capability.
Does this leave the mesh button completely non-functional when pressed?
> + };
> +
> + key-reset {
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523101904.293215-1-olek2@wp.pl?part=1
^ permalink raw reply
* [PATCH RESEND] arm64: dts: mediatek: add LED and key support on Xiaomi AX3000T
From: Aleksander Jan Bajkowski @ 2026-05-23 10:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Aleksander Jan Bajkowski
This patch adds support for keys and LEDs on the Xiaomi AX3000T.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
---
.../dts/mediatek/mt7981b-xiaomi-ax3000t.dts | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts b/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts
index a314c3e05e50..db399cb3ead7 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts
@@ -1,6 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-only OR MIT
/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
#include "mt7981b.dtsi"
@@ -12,4 +15,37 @@ memory@40000000 {
reg = <0 0x40000000 0 0x10000000>;
device_type = "memory";
};
+
+ keys {
+ compatible = "gpio-keys";
+
+ key-mesh {
+ label = "MESH";
+ gpios = <&pio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <BTN_9>;
+ linux,input-type = <EV_SW>;
+ };
+
+ key-reset {
+ label = "RESET";
+ gpios = <&pio 1 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_RESTART>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&pio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&pio 10 GPIO_ACTIVE_LOW>;
+ };
+ };
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 3/4] clk: qcom: Add support for Display Clock Controller on Shikra
From: Dmitry Baryshkov @ 2026-05-23 10:04 UTC (permalink / raw)
To: Imran Shaik
Cc: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-arm-msm, linux-clk,
devicetree, linux-kernel
In-Reply-To: <143e095c-471b-4cd7-9395-1fa06fa50625@oss.qualcomm.com>
On Fri, May 22, 2026 at 02:39:01PM +0530, Imran Shaik wrote:
>
>
> On 20-05-2026 09:59 pm, Dmitry Baryshkov wrote:
> > On Tue, May 19, 2026 at 09:34:09AM +0530, Imran Shaik wrote:
> > >
> > >
> > > On 13-05-2026 08:38 pm, Dmitry Baryshkov wrote:
> > > > On Wed, May 13, 2026 at 04:51:03PM +0200, Konrad Dybcio wrote:
> > > > > On 5/13/26 4:06 PM, Dmitry Baryshkov wrote:
> > > > > > On Wed, May 13, 2026 at 05:01:16PM +0300, Dmitry Baryshkov wrote:
> > > > > > > On Wed, May 13, 2026 at 07:10:38PM +0530, Imran Shaik wrote:
> > > > > > > > Add a driver for the Display clock controller on Qualcomm Shikra SoC.
> > > > > > > >
> > > > > > > > Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> > > > > > > > ---
> > > > > > > > drivers/clk/qcom/Kconfig | 10 +
> > > > > > > > drivers/clk/qcom/Makefile | 1 +
> > > > > > > > drivers/clk/qcom/dispcc-shikra.c | 565 +++++++++++++++++++++++++++++++++++++++
> > > > > > > > 3 files changed, 576 insertions(+)
> > > > > > > >
> > > > > > >
> > > > > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > > > > >
> > > > > > After comparing the files...
> > > > > >
> > > > > > Can we use dispcc-qcm2290.c instead? It uses clock-names instead of
> > > > > > clock-indices, but I think it should be fine to use clock-names as a
> > > > > > one-off.
> > > > >
> > > > > Or we can convert it to use indices, since those are stable for agatti
> > > > > too - the names would remain in the binding, just unused by the driver
> > > >
> > > > Either is fine for me.
> > > >
> > >
> > > Hi,
> > >
> > > In Agatti, apart from the clock-names difference, I see that the AHB/XO
> > > clocks are not handled as always-on via the probe and instead rely on pm_clk
> >
> > There is no pm_clk handling in Agatti driver.
> >
> > > style handling, whereas Shikra follows the newer pattern by marking required
> > > CBCRs as critical during probe. I think that attempting to modify this
> > > approach into Agatti may introduce unnecessary complexity.
> >
> > Well, you can start by explaining what caused the difference and the
> > result of those differences.
> >
> > >
> > > And the Agatti DISPCC doesn't have the DT_DSI1 bindings exposed, and
> > > updating this might break the ABI with respect to bindings, and DT.
> >
> > You can add Shikra-specific bindings. See how it's handled for other
> > dispcc drivers.
> >
> > > Given these and considering that Agatti is already stable, keeping the
> > > Shikra as separate GPUCC/DISPCC drivers is better to avoid the risk of
> > > regressions and complexity.
> >
> > I think you've provided arguments for merging two drivers. It would
> > allow us to modernize Agatti driver and also to make sure that both
> > platforms use the well-tested code pattern.
> >
>
> Sure Dmitry, but we would like to proceed with Shikra as-is now since it
> already follows the latest upstream conventions, and will handle Agatti
> modernization as a follow-up series to align and reuse Shikra drivers.
Having two drivers for the (almost) same hw is a bad idea. Please either
refresh Agatti driver to follow the conventions and then add Shikra
support or add Shikra into the existing driver and then update it to
follow the standards. "we would like to proceed" is not a technical
argument, it's you trying to override the review for the managerial
reasons, which don't apply upstream.
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
From: David Heidelberg via B4 Relay @ 2026-05-23 9:45 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
David Heidelberg, Krzysztof Kozlowski
In-Reply-To: <20260523-synaptics-rmi4-dt-v2-0-0645122babdc@ixit.cz>
From: David Heidelberg <david@ixit.cz>
Mostly irrelevant for authentic Synaptics touchscreens, but very important
for applying workarounds to cheap TS knockoffs.
These knockoffs work well with the downstream driver, and since the user
has no way to distinguish them, later in this patch set, we introduce
workarounds to ensure they function as well as possible.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Documentation/devicetree/bindings/input/syna,rmi4.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
index 8685ef4481f4a..fb4804ac3544d 100644
--- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml
+++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
@@ -13,19 +13,24 @@ maintainers:
description: |
The Synaptics RMI4 (Register Mapped Interface 4) core is able to support RMI4
devices using different transports (I2C, SPI) and different functions (e.g.
Function 1, 2D sensors using Function 11 or 12).
properties:
compatible:
- enum:
- - syna,rmi4-i2c
- - syna,rmi4-spi
+ oneOf:
+ - enum:
+ - syna,rmi4-i2c
+ - syna,rmi4-spi
+ - items:
+ - enum:
+ - syna,rmi4-s3706b # OnePlus 6/6T
+ - const: syna,rmi4-i2c
reg:
maxItems: 1
'#address-cells':
const: 1
'#size-cells':
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] Introduce OnePlus 6/6T touchscreen compatible
From: David Heidelberg via B4 Relay @ 2026-05-23 9:45 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
David Heidelberg, Krzysztof Kozlowski, Konrad Dybcio
Mostly related to the
https://codeberg.org/sdm845/linux/commits/branch/b4/synaptics-rmi4
series, but independent on other changes which I trying to upstream for
more than one year.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Changes in v2:
- Add R-b tag.
- Link to v1: https://lore.kernel.org/r/20260408-synaptics-rmi4-dt-v1-0-2d32bacce673@ixit.cz
---
David Heidelberg (2):
dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
Documentation/devicetree/bindings/input/syna,rmi4.yaml | 11 ++++++++---
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
---
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
change-id: 20260408-synaptics-rmi4-dt-8aebf31790dc
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: David Heidelberg via B4 Relay @ 2026-05-23 9:45 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
David Heidelberg, Krzysztof Kozlowski, Konrad Dybcio
In-Reply-To: <20260523-synaptics-rmi4-dt-v2-0-0645122babdc@ixit.cz>
From: David Heidelberg <david@ixit.cz>
We know the driver is reporting s3706b, introduce the compatible so we
can more easily introduce quirks for weird touchscreen replacements in
followup series.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
index 6b7378cf4d493..148164d456a5a 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
@@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
};
};
&i2c12 {
status = "okay";
clock-frequency = <400000>;
synaptics-rmi4-i2c@20 {
- compatible = "syna,rmi4-i2c";
+ compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
reg = <0x20>;
#address-cells = <1>;
#size-cells = <0>;
interrupts-extended = <&tlmm 125 IRQ_TYPE_EDGE_FALLING>;
pinctrl-names = "default";
pinctrl-0 = <&ts_default_pins>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v12 3/6] pinctrl: core: Make pin group callbacks optional for pin-only drivers
From: Linus Walleij @ 2026-05-23 9:37 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Peter Rosin, kernel, linux-kernel, devicetree,
linux-hwmon, linux-gpio, David Jander
In-Reply-To: <20260515160537.115808-4-o.rempel@pengutronix.de>
On Fri, May 15, 2026 at 6:05 PM Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> Currently, the pinctrl core strictly requires all drivers to implement
> .get_groups_count and .get_group_name callbacks in their pinctrl_ops.
>
> However, for simple pinctrl drivers that act purely as GPIO controllers
> and pin-specific configuration proxies, without any concept of muxing or
> pin groups, this strict requirement forces the implementation of dummy
> callbacks just to satisfy pinctrl_check_ops().
>
> Relax this requirement for pin-only drivers by making the group callbacks
> optional when no muxing or group pin configuration support is provided.
> Update the core and debugfs helpers to check for the existence of these
> callbacks before invoking them.
>
> Drivers that provide muxing or group pin configuration operations still
> must implement group enumeration and naming callbacks, and are rejected
> at registration time if they do not.
>
> Suggested-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
Since it's unlikely that the rest of the series will be merged for v7.2
I just applied this one patch to the pinctrl tree, because why not.
I stripped off the controversial Sashiko review tag until we know
what to do with these.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/2] power: sequencing: Add support for Nvidia Tegra modem pwrseq
From: sashiko-bot @ 2026-05-23 9:30 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260523085102.51000-3-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Hijacking and modifying the private state of the `tegra-usb` driver causes resource conflicts, memory leaks, and double-frees.
- [High] Missing device link allows the provider driver to unbind, leaving a dangling pointer.
- [High] Storing an `ERR_PTR` in `usb->dev` guarantees a crash during device removal.
- [High] Blindly casting driver data of an arbitrary platform device to `struct tegra_usb *` without validating the device type.
- [Low] Dereferencing incomplete type `struct tegra_usb` causes a compilation error.
- [Low] The Kconfig symbol depends on a non-existent symbol `USB_NET_XMM6260`.
--
commit 5c2fd594a3aa6ab625a68ba4bb3f25750e538e63
Author: Svyatoslav Ryhel <clamor95@gmail.com>
power: sequencing: Add support for Nvidia Tegra modem pwrseq
Nvidia Tegra modem power sequence is a set of configurations used in Tegra
SoCs to provide proper interaction between the application processor and
the modem, as well as control over one of the SoC's USB lines for the
modem.
> diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
> index 1c5f5820f5b76..e04a6bacb476f 100644
> --- a/drivers/power/sequencing/Kconfig
> +++ b/drivers/power/sequencing/Kconfig
> @@ -46,4 +46,16 @@ config POWER_SEQUENCING_PCIE_M2
> connectors. This driver handles the power sequencing for the M.2
> connectors exposing multiple interfaces like PCIe, SATA, UART, etc...
>
> +config POWER_SEQUENCING_TEGRA_MODEM
> + tristate "NVIDIA Tegra modem power sequencing driver"
> + depends on ARCH_TEGRA && USB_NET_XMM6260 && USB_SUPPORT
[Severity: Low]
Does the USB_NET_XMM6260 config symbol exist in the kernel tree? If this
symbol is not present, this driver will be permanently disabled due to an
unsatisfied dependency.
> + help
> + Enable this to support power sequence for XMM6260 modem found in
> + various Tegra devices with cellular capabilities, like
> + LG Optimus 4X P880, LG Optimus Vu P895, Google Nexus 7 (2012) 3G
> + and ASUS Transformer Pad 3G TF300TG.
[ ... ]
> diff --git a/drivers/power/sequencing/pwrseq-tegra-modem.c b/drivers/power/sequencing/pwrseq-tegra-modem.c
> new file mode 100644
> index 0000000000000..0b212ec8b643e
> --- /dev/null
> +++ b/drivers/power/sequencing/pwrseq-tegra-modem.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
[ ... ]
> +struct pwrseq_tegra_modem_ctx {
> + struct device *dev;
> + struct pwrseq_device *pwrseq;
> +
> + struct gpio_desc *enable_gpio;
> + struct regulator *power_supply;
> +
> + struct platform_device *usb_dev;
> + struct tegra_usb *usb;
> +};
[ ... ]
> +static int pwrseq_tegra_modem_enable(struct pwrseq_device *pwrseq)
> +{
> + struct pwrseq_tegra_modem_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> + struct tegra_usb *usb = ctx->usb;
> + int ret;
> +
> + /*
> + * USB controller registers shouldn't be touched before PHY is
> + * initialized, otherwise CPU will hang because clocks are gated.
> + * PHY driver controls gating of internal USB clocks on Tegra.
> + */
> + ret = usb_phy_init(usb->phy);
[Severity: Low]
Is struct tegra_usb defined in a public header? It appears to be a private
structure defined only in drivers/usb/chipidea/ci_hdrc_tegra.c. Will accessing
usb->phy here cause a compilation error due to dereferencing an incomplete
type?
> + if (ret) {
> + dev_err(ctx->dev, "failed to init USB PHY\n");
> + return ret;
> + }
> +
> + usb->dev = ci_hdrc_add_device(&ctx->usb_dev->dev,
> + ctx->usb_dev->resource,
> + ctx->usb_dev->num_resources,
> + &usb->data);
[Severity: High]
Does modifying the tegra-usb driver's private state directly create resource
conflicts?
If tegra_usb_probe() already initialized the PHY and registered a child
device, calling ci_hdrc_add_device() here and overwriting usb->dev could leak
the originally registered device. Furthermore, if both drivers independently
attempt to call ci_hdrc_remove_device(usb->dev) during teardown, could this
lead to use-after-free and double-free bugs?
> + if (IS_ERR(usb->dev)) {
[Severity: High]
If ci_hdrc_add_device() fails, usb->dev is left containing an ERR_PTR. If the
tegra-usb driver is subsequently unbound, its remove path:
tegra_usb_remove()
ci_hdrc_remove_device(usb->dev)
will unconditionally dereference this pointer since it expects a valid device.
Could this lead to a fatal invalid pointer dereference?
> + usb_phy_shutdown(usb->phy);
> + dev_err(ctx->dev, "failed to register USB controller\n");
> + return PTR_ERR(usb->dev);
> + }
> +
> + gpiod_set_value_cansleep(ctx->enable_gpio, 1);
> +
> + return 0;
> +}
[ ... ]
> +static int pwrseq_tegra_modem_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *usb_node;
> + struct pwrseq_tegra_modem_ctx *ctx;
> + struct pwrseq_config config = { };
> + int ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + ctx->dev = dev;
> +
> + ctx->enable_gpio = devm_gpiod_get_optional(dev, "enable",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(ctx->enable_gpio))
> + return dev_err_probe(dev, PTR_ERR(ctx->enable_gpio),
> + "failed to get enable GPIO\n");
> +
> + ctx->power_supply = devm_regulator_get(dev, "power");
> + if (IS_ERR(ctx->power_supply))
> + return dev_err_probe(dev, PTR_ERR(ctx->power_supply),
> + "failed to get power supply\n");
> +
> + usb_node = of_parse_phandle(dev->of_node, "nvidia,usb-bus", 0);
> + if (!usb_node)
> + return dev_err_probe(dev, -ENODEV,
> + "failed to parse modem USB bus\n");
> +
> + ctx->usb_dev = of_find_device_by_node(usb_node);
> + of_node_put(usb_node);
> + if (!ctx->usb_dev)
> + return -EPROBE_DEFER;
> +
> + ret = devm_add_action_or_reset(dev, pwrseq_tegra_modem_put_device,
> + &ctx->usb_dev->dev);
> + if (ret)
> + return ret;
> +
> + ctx->usb = platform_get_drvdata(ctx->usb_dev);
[Severity: High]
Is it safe to cast the driver data of this platform device to
struct tegra_usb * without first verifying the device type (for example, by
checking its compatible string)?
If the phandle incorrectly points to an unrelated device, ctx->usb will point
to the wrong driver data. Could this cause type confusion and crashes when
fields like usb->phy are accessed later?
[Severity: High]
Should there be a device link established here using device_link_add() to
enforce a consumer-supplier relationship?
Without a device link, the tegra-usb driver can be unbound at any time.
If unbound, the devres-managed struct tegra_usb is freed. Would this leave
ctx->usb as a dangling pointer, leading to a use-after-free during subsequent
power sequence operations?
> + if (!ctx->usb)
> + return -EPROBE_DEFER;
> +
> + config.parent = dev;
> + config.owner = THIS_MODULE;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523085102.51000-1-clamor95@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2 4/4] usb: chipidea: tegra: Expose tegra_usb structure
From: sashiko-bot @ 2026-05-23 9:28 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260523083013.46372-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Exposing the private driver data structure `struct tegra_usb` in a public header violates driver encapsulation.
--
commit 458c2154b4c34aa542cc2d5d1ce84db0b5258a4b
Author: Svyatoslav Ryhel <clamor95@gmail.com>
usb: chipidea: tegra: Expose tegra_usb structure
This commit moves the tegra_usb structure from the tegra chipidea driver into
a public header file. The commit message states this is required for proper
manipulation when init and deinit are externally controlled.
> diff --git a/include/linux/usb/tegra_usb_phy.h b/include/linux/usb/tegra_usb_phy.h
> index 6343f88df5de8..ba74b7ebfba0e 100644
> --- a/include/linux/usb/tegra_usb_phy.h
> +++ b/include/linux/usb/tegra_usb_phy.h
[ ... ]
> @@ -62,6 +63,20 @@ enum tegra_usb_phy_port_speed {
> TEGRA_USB_PHY_PORT_SPEED_HIGH,
> };
>
> +struct tegra_usb_soc_info;
> +
> +struct tegra_usb {
> + struct ci_hdrc_platform_data data;
> + struct platform_device *dev;
> +
> + const struct tegra_usb_soc_info *soc;
> + struct usb_phy *phy;
> + struct clk *clk;
> +
> + bool needs_double_reset;
> + bool externally_controlled;
> +};
[Severity: Low]
Does moving this private runtime state into a public header break driver
encapsulation?
Exposing the raw internal state structure allows external entities to
directly manipulate the controller's internal state, tightly coupling the
PHY and controller drivers.
Would it be better to provide explicit API functions, such as init and
deinit helpers, for cross-driver manipulation instead of exposing the
internal structure?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523083013.46372-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v2 3/4] usb: chipidea: tegra: Avoid controller/PHY init if bus is externally controlled
From: sashiko-bot @ 2026-05-23 9:17 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260523083013.46372-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Out-of-bounds I/O memory access in `tegra_ehci_hub_control()` due to unvalidated `wIndex`.
--
commit 60717c8d1b44f3d9bbb2d143c18add1a1d62f035
Author: Svyatoslav Ryhel <clamor95@gmail.com>
usb: chipidea: tegra: Avoid controller/PHY init if bus is externally controlled
This commit skips the registration of the USB controller and PHY
initialization if they are externally controlled. Since the USB PHY
in Tegra controls clock gates required by the controller itself, it
defers this configuration to the device that controls the bus.
> diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
> index 372788f0f9701..a19cb3b33bf37 100644
> --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
[ ... ]
> @@ -342,12 +348,14 @@ static int tegra_usb_probe(struct platform_device *pdev)
> if (of_usb_get_phy_mode(pdev->dev.of_node) == USBPHY_INTERFACE_MODE_ULPI)
> usb->data.flags &= ~CI_HDRC_SUPPORTS_RUNTIME_PM;
>
> - usb->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
> - pdev->num_resources, &usb->data);
[Severity: High]
This is a pre-existing issue, but does tegra_ehci_hub_control() have an
out-of-bounds I/O memory access?
When handling root hub control requests, the core USB code in
rh_call_control() passes the raw, user-supplied wIndex (e.g., from usbfs via
the USBDEVFS_CONTROL ioctl) to the HCD's hub_control callback.
In tegra_ehci_hub_control(), which is passed in the usb->data structure here,
the pointer to the port status register is calculated without bounds checking
on wIndex:
status_reg = &ehci->regs->port_status[(wIndex & 0xff) - 1]
If wIndex & 0xff evaluates to 0, the calculation produces an index of -1
(pointing to the configured_flag register). If it is a large number like 255,
it results in an index of 254, reading far past the port_status array which
has a size of HCS_N_PORTS_MAX (15).
Could sending a SetPortFeature request with wValue = USB_PORT_FEAT_RESET
and a crafted wIndex allow a user with access to the root hub device node to
force the driver to perform multiple reads and writes at arbitrary MMIO
offsets?
> + if (!usb->externally_controlled) {
> + usb->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
> + pdev->num_resources, &usb->data);
> + if (IS_ERR(usb->dev)) {
> + err = dev_err_probe(&pdev->dev, PTR_ERR(usb->dev),
> + "failed to add HDRC device");
> + goto phy_shutdown;
> + }
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523083013.46372-1-clamor95@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: gpio: add Axiado SGPIO controller
From: Linus Walleij @ 2026-05-23 9:13 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Tzu-Hao Wei, Swark Yang, Prasad Bolisetty, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
SriNavmani A, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <c20dc0cb-252b-4637-bb22-6078be62b21d@axiado.com>
On Wed, May 13, 2026 at 10:59 AM Petar Stepanovic
<pstepanovic@axiado.com> wrote:
> Some SGPIO outputs may control host-critical signals. For example, if the
> BMC reboots while the host/server remains powered on, changing SGPIO output
> values during driver initialization could potentially reset or shut down the
> running host.
>
> The purpose of `dout-init` is to provide a deterministic safe output state
> during SGPIO initialization, before any GPIO consumer has requested the line.
>
> That said, if the preferred approach is to preserve the existing hardware
> DOUT state during probe and only change the value when a GPIO consumer
> requests the line, I can rework the driver in that direction.
That is usually the best. The gpio framework scans the direction
of each line at probe(). While it does not know about the initial *value*
of each line, consumers can take this into account
when requesting a GPIO line like this:
gpio_vbus = devm_gpiod_get(dev, "vbus", GPIOD_ASIS);
This means the kernel does not put any initial value on the line.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH V9 1/3] dt-bindings: soundwire: qcom: Increase max data ports to 17
From: sashiko-bot @ 2026-05-23 9:11 UTC (permalink / raw)
To: Sibi Sankar; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260523085511.2532669-2-sibi.sankar@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Globally increasing maxItems to 17 for port properties weakens schema validation for older SoundWire controllers that only support 16 ports.
Pre-existing issues:
- [High] Port allocation logic fails to properly check if the highest port is busy, leading to silent collisions where the maximum port index is allocated repeatedly when all lower ports are exhausted.
--
commit 4f104dadbb8cc83ffee25439c24bc3ee896cb832
Author: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
dt-bindings: soundwire: qcom: Increase max data ports to 17
This patch bumps the maxItems from 16 to 17 for all qcom,ports-* properties.
This accommodates SoundWire controllers v3.1.0 which feature 17 data ports.
> diff --git a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
> index 9447a2f371b56..8e6973fa229c9 100644
> --- a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
> +++ b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
> @@ -90,7 +90,7 @@ properties:
> or applicable for the respective data port.
> More info in MIPI Alliance SoundWire 1.0 Specifications.
> minItems: 3
> - maxItems: 16
> + maxItems: 17
[Severity: Medium]
By globally increasing maxItems to 17, does this weaken schema validation
for older SoundWire controllers that physically only support 16 ports?
A device tree for older hardware (e.g., v1.3.0 to v2.2.0) could now incorrectly
specify 17 ports and pass dt_binding_check.
Should this use conditional allOf / if-then blocks based on the compatible
string to enforce generation-specific bounds?
[ ... ]
[Severity: High]
This isn't a bug introduced by this patch, but there appears to be a pre-existing
logic error in the dynamic port allocation that these bounds protect.
Looking at qcom_swrm_stream_alloc_ports():
drivers/soundwire/qcom.c:qcom_swrm_stream_alloc_ports() {
...
pn = find_first_zero_bit(port_mask, maxport);
if (pn > maxport) {
dev_err(ctrl->dev, "All ports busy\n");
return -EBUSY;
}
set_bit(pn, port_mask);
...
}
Because find_first_zero_bit() searches the range [0, maxport-1], it returns
maxport if no zero bits are found. If ports 1 to maxport-1 are all busy, the
check "if (pn > maxport)" evaluates to false.
Does this allow the code to blindly assign maxport and set its bit without
verifying if it was actually free?
It seems on subsequent allocations, the search will again find no zero bits and
repeatedly assign maxport, causing silent resource collisions where multiple
audio streams share the same hardware port.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523085511.2532669-1-sibi.sankar@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH 4/4] clk: add support for siflower sf21-topcrm
From: Chuanhong Guo @ 2026-05-23 9:09 UTC (permalink / raw)
To: Yao Zi
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, linux-riscv,
linux-kernel, linux-clk, devicetree
In-Reply-To: <ahB46uuoFQxKgr7r@pie>
On Fri, May 22, 2026 at 11:45 PM Yao Zi <me@ziyao.cc> wrote:
>
> On Mon, May 18, 2026 at 09:34:17PM +0800, Chuanhong Guo wrote:
> > Hi!
> >
> > On Mon, May 18, 2026 at 8:22 PM Yao Zi <me@ziyao.cc> wrote:
> > >
> > > On Sun, May 17, 2026 at 10:12:58PM +0800, Chuanhong Guo wrote:
>
> ...
>
> > >
> > > [...]
> > >
> > > Besides field/register offsets, the only difference I could tell between
> > > cmnpll_postdiv and pciepll_fout is that pciepll_fout clocks could be
> > > gated.
> > >
> > > Would it be a good idea to describe the gating function separately as a
> > > clock, and merge the common part of pciepll_fout and cmnpll_postdiv? In
> > > which way you could save a lot of mostly duplicated code.
> >
> > I don't think so. Since the majority of the existing code are register
> > operations, and the register bit layout are completely different,
> > there isn't much to share between these two PLLs.
> > Writing a struct to describe both register layouts together seems
> > unnecessarily complicated and harder to read.
>
> I'm not suggesting merging the implementation of the two PLLs
> themselves, but only the two types of clocks derived from them,
> i.e. cmnpll_postdiv and pciepll_fout.
I don't feel like arbitrarily splitting a single clock into two and exposing
an internal clock unused by anything outside the PLL block is a good idea.
I'll try reusing the ops and omit the enable/disable call for cmnpll_postdiv.
>
> > BTW the CMNPLL and PCIEPLL are actually different hardware.
> > The former is an integer PLL while the latter actually supports
> > fractional operations. I didn't add support for the fractional part
> > due to the lack of use cases and documentation. PCIE and GMAC
> > clocks are fed by this PLL and require exact clock frequencies
> > which can be achieved using only the integer mode.
> >
> > >
> > > > + .recalc_rate = sf21_pciepll_fout_recalc_rate,
> > > > + .determine_rate = sf21_pciepll_fout_determine_rate,
> > > > + .set_rate = sf21_pciepll_fout_set_rate,
> > > > +};
> > > [...]
> > > > +
> > > > + spin_lock_irqsave(cmn_priv->lock, flags);
> > > > + if (index)
> > > > + sf_rmw(cmn_priv, mux_reg, 0, BIT(mux_offs));
> > > > + else
> > > > + sf_rmw(cmn_priv, mux_reg, BIT(mux_offs), 0);
> > > > +
> > > > + spin_unlock_irqrestore(cmn_priv->lock, flags);
> > > > + return 0;
> > > > +}
> > >
> > > I believe besides the divider reloading part, clk_mux_ops,
> > > clk_divider_ops, and clk_gate_ops have already provided the logic
> > > you implemented here. So it might be a better option to composite them
> > > together to implement your clocks instead of building from scratch.
> >
> > The divider reloading is the exact reason I chose to not compose them
> > with the function you mentioned. The reloading bit need to be set on
> > both clock divider change and clock enabling, because the clock divider
> > loading only happens when the clock is running. Since I already have
> > to write two of the three parts you mentioned, trying to reuse
> > clk_mux_ops doesn't seem to reduce the code complexity here.
>
> You don't have to write divider/gate operations from scratch, but only
> wrappers that first call clk_{divider,gate}_ops.* then trigger frequency
> reloading.
The wrapper needs to be spinlock + frequency reloading trigger,
because the built-in spinlock routine only covers the divider/gate.
writing. I see no point wrapping all the callbacks and writing a way
more complicated probe routine just to reuse a few lines of
calculations + register ops.
>
> > It's just trading get_parent and set_parent call with one more level
> > in the clock tree for every clock and more code to wire them together
> > in the probe function.
I just learned that clk_hw_register_composite won't result in
one more level of clock. but the second part still is true.
In order to reuse the mentioned kernel function I have to give
up on my current single for-loop probe function, add a separated
array of clocks with mux/div/gate, mux-only, div-only, gate-only
clocks, and write separated probe routines for them because
the clock composition is different. The current static pointers
in struct sf21_hw_clks will also need to be replaced because
clk_hw_register_composite allocates its own clk_hw instead.
I'd argue that the point of reusing code is to reduce code
duplication and simplify the driver.
In this case I could only see the driver getting way more
complex in order to reuse the routine you mentioned.
--
Regards,
Chuanhong Guo
^ permalink raw reply
* Re: [PATCH v2 0/2] pinctrl: qcom: eliza: Merge QUP1_SE4 lane functions
From: Linus Walleij @ 2026-05-23 9:04 UTC (permalink / raw)
To: Abel Vesa
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Koskovich, Konrad Dybcio, Krzysztof Kozlowski,
linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260515-eliza-tlmm-group-qup1-se4-lanes-v2-0-ebb630de0dcf@oss.qualcomm.com>
On Fri, May 15, 2026 at 1:22 PM Abel Vesa <abel.vesa@oss.qualcomm.com> wrote:
> QUP1_SE4 uses GPIO36 and GPIO37 for two selectable lane pairs.
> Splitting into function per lane works, but it forces the devicetree to
> describe a state per pin while these are usually configured in pairs.
>
> Follow the pair-wise scheme used on Qualcomm Hawi platform and expose
> the two selectable pairs as qup1_se4_01 and qup1_se4_23 in both the
> binding and the driver.
>
> This has been proposed here:
> https://lore.kernel.org/all/agIZOAa6nYSb5PWX@baldur/
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Patches applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Linus Walleij @ 2026-05-23 9:02 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel, linux-gpio, devicetree, imx,
linux-arm-kernel, Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <agNFaXbd_sMq5eAo@lizhi-Precision-Tower-5810>
On Tue, May 12, 2026 at 5:21 PM Frank Li <Frank.li@nxp.com> wrote:
> On Mon, May 11, 2026 at 10:34:35PM +0200, Linus Walleij wrote:
> > On Mon, May 11, 2026 at 9:38 PM Frank Li <Frank.li@nxp.com> wrote:
> >
> > > I fixed a build warning by missing doc 'np',
> > > https://lore.kernel.org/imx/20260507152117.240612-1-Frank.Li@nxp.com/
> > >
> > > Anything need me to do futher?
> >
> > Sorry was busy!
> >
> > Applied this fixup on top of the branch and merged it into my
> > devel branch for v7.2!
>
> Sorry, I missed picked up fix patch during rebase.
>
> https://lore.kernel.org/imx/20260512144806.22447-1-Frank.Li@nxp.com/T/#u
Ooops I should have seen it.
Applied it now!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq
From: sashiko-bot @ 2026-05-23 9:00 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260523085102.51000-2-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Modeling a software power sequence as a virtual standalone device tree node, bypassing physical bus topology.
--
commit 5baacde1b782878f582e887bcf988caf135487f5
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq
This commit documents the Tegra modem power sequence configuration. It provides
a node to manage interaction between the application processor and the modem,
including control over the USB lines.
> diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml
> new file mode 100644
> index 0000000000000..3770fd6dc2cf9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml
[ ... ]
> +properties:
> + compatible:
> + const: nvidia,tegra-modem-pwrseq
> +
> + enable-gpios:
> + description: GPIO connected to the modem EINT1 pin
> + maxItems: 1
> +
> + nvidia,usb-bus:
> + description:
> + Contains phandle pointing to the Host's USB controller
> + $ref: /schemas/types.yaml#/definitions/phandle
[Severity: High]
Does this binding model a software power sequence rather than the physical
hardware layout?
The device tree typically describes physical topology. Under standard bus
architecture, would a USB-connected modem be modeled as a child node under
the corresponding USB controller or hub port, including its required
power-supplies and enable-gpios as properties of that physical child node?
By introducing a standalone virtual node that points backwards to the USB
controller via the nvidia,usb-bus phandle, does this bypass the driver core's
standard bus hierarchy and device link management?
Without a structural dependency established through device links, if the USB
controller driver is unbound, could the power sequencer retain a dangling
pointer to the USB bus device and trigger a use-after-free during the next
enable or disable sequence?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523085102.51000-1-clamor95@gmail.com?part=1
^ 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