* Re: [PATCH v3 1/8] iio: temperature: ltc2983: Fix macro parenthesization and rename
From: Joshua Crofts @ 2026-05-22 9:11 UTC (permalink / raw)
To: Liviu Stan
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Francesco Lavra, linux-iio, linux-kernel, linux,
devicetree
In-Reply-To: <20260521164323.770626-2-liviu.stan@analog.com>
On Thu, 21 May 2026 at 19:19, Liviu Stan <liviu.stan@analog.com> wrote:
>
> Wrap the 'chan' parameter in LTC2983_CHAN_START_ADDR() and
> LTC2983_CHAN_RES_ADDR() with parentheses to prevent potential
> macro argument expansion issues. Also rename LTC2983_CHAN_START_ADDR
> to LTC2983_CHAN_ASSIGN_ADDR and LTC2983_CHAN_RES_ADDR to
> LTC2983_RESULT_ADDR, to better reflect the datasheet names and avoid
> them being confused as related.
>
> Signed-off-by: Liviu Stan <liviu.stan@analog.com>
> ---
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH v4 2/4] hwmon: (pmbus/tps25990): Rework TPS25990 direct conversion handling
From: sashiko-bot @ 2026-05-22 9:12 UTC (permalink / raw)
To: Stoyan Bogdanov; +Cc: devicetree, linux-hwmon, robh, conor+dt
In-Reply-To: <20260522082349.2749970-3-sbogdanov@baylibre.com>
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?
> + 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;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522082349.2749970-1-sbogdanov@baylibre.com?part=2
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: firmware: qcom,scm: Add minidump SRAM property
From: Krzysztof Kozlowski @ 2026-05-22 9:15 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260522075200.lzpj3cfqvrpzv7r3@hu-mojha-hyd.qualcomm.com>
On 22/05/2026 09:52, Mukesh Ojha wrote:
> On Wed, May 20, 2026 at 12:17:21PM +0200, Krzysztof Kozlowski wrote:
>> On Tue, May 19, 2026 at 10:44:39PM +0530, Mukesh Ojha wrote:
>>> On most Qualcomm SoCs where minidump is supported, a word in always-on
>>> SRAM is shared between the kernel and boot firmware. Before DDR is
>>> initialised on the warm reset following a crash, firmware reads this
>>> word to decide if minidump is enabled and collect a minidump and where
>>> to deliver it (USB upload to a host, or save to local storage).
>>>
>>> Add a 'sram' property to the SCM binding to describe a region in
>>> always-on SRAM where the minidump download destination value could be
>>> written. Boot firmware reads it before DDR is initialised on a warm
>>> reset to decide where to store the minidump either to host PC or to
>>> on device storage.
>>>
>>> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>>> ---
>>> .../devicetree/bindings/firmware/qcom,scm.yaml | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>> index 25f62bacbc91..27422d00b8fc 100644
>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>> @@ -129,6 +129,13 @@ properties:
>>> - description: offset of the download mode control register
>>> description: TCSR hardware block
>>>
>>> + sram:
>>> + description:
>>> + Phandle to a region in always-on SRAM used to store the download
>>> + mode value for boot firmware to read before DDR is initialised on
>>> + the next warm reset.
>>> + maxItems: 1
>>> +
>>> allOf:
>>> # Clocks
>>> - if:
>>> @@ -250,3 +257,12 @@ examples:
>>> clock-names = "core", "bus", "iface";
>>> };
>>> };
>>> +
>>> + - |
>>> + firmware {
>>> + scm {
>>> + compatible = "qcom,scm-kaanapali", "qcom,scm";
>>
>> Incomplete, missing interrupts.
>
> Interrupt number comes from firmware and has not even been described
> statically for SCM for any SoC and so I am not sure to include it in
> the example. Perhaps I took the wrong example here and should have taken
> some pre-Gunyah Qualcomm SoC.
Then you do not need a new example. Difference in one property (reset
cells) does not justify new example.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: clock: Add Amlogic A9 PLL clock controller
From: Krzysztof Kozlowski @ 2026-05-22 9:16 UTC (permalink / raw)
To: Jian Hu
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <40e83bed-e7a0-4c66-806c-c2988c5d0f33@amlogic.com>
On 22/05/2026 08:20, Jian Hu wrote:
> Hi Krzysztof,
>
> Thanks for your review.
>
> On 5/15/2026 4:09 PM, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On Mon, May 11, 2026 at 08:47:24PM +0800, Jian Hu wrote:
>>> Add the PLL clock controller dt-bindings for the Amlogic A9 SoC family.
>>>
>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>> ---
>>> .../bindings/clock/amlogic,a9-pll-clkc.yaml | 110 +++++++++++++++++++++
>>> include/dt-bindings/clock/amlogic,a9-pll-clkc.h | 55 +++++++++++
>>> 2 files changed, 165 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>>> new file mode 100644
>>> index 000000000000..4ee6013ba1a1
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>>> @@ -0,0 +1,110 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/clock/amlogic,a9-pll-clkc.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Amlogic A9 Series PLL Clock Controller
>>> +
>>> +maintainers:
>>> + - Neil Armstrong <neil.armstrong@linaro.org>
>>> + - Jerome Brunet <jbrunet@baylibre.com>
>>> + - Jian Hu <jian.hu@amlogic.com>
>>> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - amlogic,a9-gp0-pll
>>> + - amlogic,a9-hifi0-pll
>>> + - amlogic,a9-hifi1-pll
>>> + - amlogic,a9-mclk0-pll
>>> + - amlogic,a9-mclk1-pll
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + '#clock-cells':
>>> + const: 1
>>> +
>>> + clocks:
>>> + items:
>>> + - description: pll input oscillator gate
>>> + - description: fixed input clock source for mclk_sel_0
>>> + - description: u3p2pll input clock source for mclk_sel_0 (optional)
>> Second clock is also optional. Drop "(optional)" comment, just
>> confusing.
>
>
> GP0 has only one parent clock, while MCLK has three.
>
> The second and third parent entries of GP0 are vacant,
>
> so they need to be marked optional.
>
> I will add the optional property for the second clock in the next revision.
How? Read the previous feedback...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: PCI: qcom: Document the Eliza PCIe Controller
From: Krishna Chaitanya Chundru @ 2026-05-22 9:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Bjorn Andersson,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci
In-Reply-To: <20260522-calm-bug-of-kindness-2dfae2@quoll>
On 5/22/2026 12:20 PM, Krzysztof Kozlowski wrote:
> On Thu, May 21, 2026 at 07:35:30PM +0530, Krishna Chaitanya Chundru wrote:
>> +description:
>> + Qualcomm ELIZA SoC (and compatible) PCIe root complex controller is based on
>> + the Synopsis DesignWare PCIe IP.
>> +
>> +properties:
>> + compatible:
>> + const: qcom,pcie-eliza
> All new pcie compatibles moved to correct format.
Ack, I will change it to qcom,elize-pcie
>> +
>> + reg:
>> + minItems: 5
>> + maxItems: 6
>> +
>> + reg-names:
>> + minItems: 5
>> + items:
>> + - const: parf # Qualcomm specific registers
>> + - const: dbi # DesignWare PCIe registers
>> + - const: elbi # External local bus interface registers
>> + - const: atu # ATU address space
>> + - const: config # PCIe configuration space
>> + - const: mhi # MHI registers
>> +
>> + clocks:
>> + maxItems: 7
>> +
>> + clock-names:
>> + items:
>> + - const: aux # Auxiliary clock
>> + - const: cfg # Configuration clock
>> + - const: bus_master # Master AXI clock
>> + - const: bus_slave # Slave AXI clock
>> + - const: slave_q2a # Slave Q2A clock
>> + - const: ddrss_sf_tbu # PCIe SF TBU clock
>> + - const: cnoc_sf_axi # Config NoC PCIe1 AXI clock
>> +
>> + interrupts:
>> + minItems: 8
> This should not be flexible. Neither 'reg'.
ack I will remove minItems
>> + maxItems: 9
>> +
>> + interrupt-names:
>> + minItems: 8
>> + items:
>> + - const: msi0
>> + - const: msi1
>> + - const: msi2
>> + - const: msi3
>> + - const: msi4
>> + - const: msi5
>> + - const: msi6
>> + - const: msi7
>> + - const: global
>> +
>> + resets:
>> + maxItems: 2
>> +
>> + reset-names:
>> + items:
>> + - const: pci # PCIe core reset
>> + - const: link_down # PCIe link down reset
>> +
>> +required:
>> + - power-domains
>> + - resets
>> + - reset-names
>> +
>> +allOf:
>> + - $ref: qcom,pcie-common.yaml#
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/qcom,eliza-gcc.h>
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/interconnect/qcom,eliza-rpmh.h>
>> +
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + pcie@1c00000 {
>> + compatible = "qcom,pcie-eliza";
>> + reg = <0 0x01c00000 0 0x3000>,
>> + <0 0x40000000 0 0xf1d>,
>> + <0 0x40000f20 0 0xa8>,
>> + <0 0x40001000 0 0x1000>,
>> + <0 0x40100000 0 0x100000>;
>> + reg-names = "parf", "dbi", "elbi", "atu", "config";
>> + ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
>> + <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x3d00000>;
>> +
>> + bus-range = <0x00 0xff>;
>> + device_type = "pci";
>> + linux,pci-domain = <0>;
>> + num-lanes = <1>;
>> +
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> +
>> + clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
>> + <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
>> + <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
>> + <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
>> + <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
>> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
>> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
>> + clock-names = "aux",
>> + "cfg",
>> + "bus_master",
>> + "bus_slave",
>> + "slave_q2a",
>> + "ddrss_sf_tbu",
>> + "cnoc_sf_axi";
>> +
>> + dma-coherent;
>> +
>> + interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 653 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "msi0", "msi1", "msi2", "msi3",
>> + "msi4", "msi5", "msi6", "msi7", "global";
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 0x7>;
>> + interrupt-map = <0 0 0 1 &intc 0 0 0 564 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
>> + <0 0 0 2 &intc 0 0 0 565 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
>> + <0 0 0 3 &intc 0 0 0 566 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
>> + <0 0 0 4 &intc 0 0 0 567 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
>> +
>> + interconnects = <&pcie_noc MASTER_PCIE_0 0 &mc_virt SLAVE_EBI1 0>,
>> + <&gem_noc MASTER_APPSS_PROC 0 &cnoc_main SLAVE_PCIE_0 0>;
>> + interconnect-names = "pcie-mem", "cpu-pcie";
>> +
>> + iommu-map = <0x0 &apps_smmu 0x1480 0x1>,
>> + <0x100 &apps_smmu 0x1481 0x1>;
>> +
>> + pinctrl-0 = <&pcie0_default_state>;
>> + pinctrl-names = "default";
>> +
>> + power-domains = <&gcc GCC_PCIE_0_GDSC>;
>> +
>> + resets = <&gcc GCC_PCIE_0_BCR>,
>> + <&gcc GCC_PCIE_0_LINK_DOWN_BCR>;
>> + reset-names = "pci",
>> + "link_down";
>> +
> Drop stray blank line.
ack.
- Krishna Chaitanya.
>> + };
>> + };
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 3/5] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Maulik Shah (mkshah) @ 2026-05-22 9:22 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thomas Gleixner, Linus Walleij, linux-arm-msm, devicetree,
linux-kernel, linux-gpio, Sneh Mankad
In-Reply-To: <acH7AJq6tcmemvU5@baldur>
On 3/24/2026 8:22 AM, Bjorn Andersson wrote:
> On Thu, Mar 12, 2026 at 09:26:37PM +0530, Maulik Shah wrote:
>> There are two modes PDC irqchip supports pass through mode and secondary
>> controller mode.
>>
>> All PDC irqchip supports pass through mode in which both Direct SPIs and
>> GPIO IRQs (as SPIs) are sent to GIC without latching at PDC.
>>
>> Newer PDCs (v3.0 onwards) also support additional secondary controller mode
>> where PDC latches GPIO IRQs and sends to GIC as level type IRQ. Direct SPIs
>> still works same as pass through mode without latching at PDC even in
>> secondary controller mode.
>>
>> All the SoCs so far default uses pass through mode with the exception of
>> x1e. x1e PDC may be set to secondary controller mode for builds on CRD
>> boards whereas it may be set to pass through mode for IoT-EVK.
>>
>> There is no way to read which current mode it is set to and make PDC work
>> in respective mode as the read access is not opened up for non secure
>> world. There is though write access opened up via SCM write API to set the
>> mode.
>>
>> Configure PDC mode to pass through mode for all x1e based boards via SCM
>> write.
>>
>
> You're failing to mention that the SCM interface was not present in
> initially shipping Windows firmware, which would result in you breaking
> those devices.
I will mention same in the v2 series commit message.
This series has also been tested on older firmware and the scm_write failure path is handled
properly, so existing devices will not be braked.
>
> If you're certain that this change is available to all users, you can
> argue that this is acceptable - but omitting this from the commit
> message isn't.
Not certain. In v2 series adding the secondary mode support which allows to hit deepest low
power mode irrespective of the old/new firmware.
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: soc: qcom: pmic-glink: Document batteryless property
From: Konrad Dybcio @ 2026-05-22 9:24 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kamal Wadhwa, jishnu.prakash
Cc: Rakesh Kota, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
linux-arm-msm, devicetree, linux-kernel, linux-pm
In-Reply-To: <e07085c5-0fe8-4ea7-8e51-ebe104e7aa2d@kernel.org>
On 5/21/26 11:58 AM, Krzysztof Kozlowski wrote:
> On 21/05/2026 10:46, Konrad Dybcio wrote:
>> On 5/21/26 9:20 AM, Krzysztof Kozlowski wrote:
>>>> Since firmware does not have a way to dynamically tell if it on a
>>>> debug-board powered device or a DCIN powered device, We are required to
>>>> add this new DT property.
>>>
>>> Neither debug-board powered device nor battery-less will have
>>> monitored-battery, thus again, why lack of that property cannot tell you
>>> what you need?
>>
>> A device with a battery will not have a monitored-battery either
> But why? If for such device property "no battery" is suitable, then for
> me "monitored-battery" is suitable as well. IOW, if you say that having
> a property describing batter is not a accurate hardware property here,
> then neither saying "no battery" is, because no batter is basically some
> sort of battery (just like empty set is still a set, empty array is
> still an array).
The battmgr service running on one of the remoteprocs already has all
the information about the battery and it also handles all the type-c,
PD and charger configuration, only letting the OS know about the
results.
Hence, unless there's some other hardware at play (e.g. for custom
200 W charging), which wasn't fully implemented in the QC firmware,
there is no reason to describe a battery separately, since the OS
can't do anything useful with that information
In some abstract way, perhaps monitored_battery = <&pmic_glink> could
be thought of as valid (since that's the data source the OS gets to
see)
Konrad
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: hwmon: pmbus/tps25990: Add TPS1689
From: sashiko-bot @ 2026-05-22 9:24 UTC (permalink / raw)
To: Stoyan Bogdanov; +Cc: conor+dt, robh, devicetree, linux-hwmon
In-Reply-To: <20260522082349.2749970-4-sbogdanov@baylibre.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The driver incorrectly uses `i2c_get_clientdata()` to retrieve the `pmbus_driver_info` pointer, resulting in a type mismatch and out-of-bounds memory access.
--
commit 11131ea034ce953233470df60e4f6a1c34cca609
Author: Stoyan Bogdanov <sbogdanov@baylibre.com>
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. It introduces structures
for per-device coefficients and uses generic PMBus 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
[ ... ]
> @@ -36,17 +36,63 @@
> #define TPS25990_UNLOCKED BIT(7)
>
> #define TPS25990_8B_SHIFT 2
[ ... ]
> +struct tps25990_data {
> + struct pmbus_driver_info info;
> + struct tps25990_local_direct_value info_local;
> +};
> +
> +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 code correctly retrieve the pmbus_driver_info pointer?
In pmbus_core.c, pmbus_do_probe() sets the I2C client data to a newly
allocated struct pmbus_data object, not struct pmbus_driver_info.
Because info is the first member of struct tps25990_data, container_of()
evaluates to the same pointer, causing the driver to mistakenly interpret the
pmbus_data object as a tps25990_data object.
When accessing the info_local member, it reads from an offset, yielding garbage
values for the calculation constants m, b, and R. If the garbage m value
happens to be zero, reading sensors via sysfs could cause a divide-by-zero
kernel panic in pmbus_reg2data_direct_calc().
Should this use pmbus_get_driver_info(client) instead of i2c_get_clientdata()?
> + 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);
> +}
> +
> +static u16 tps25990_data2reg_direct(struct i2c_client *client, int param, s64 val)
> +{
> + struct pmbus_driver_info *info = i2c_get_clientdata(client);
> + struct tps25990_data *data = container_of(info, struct tps25990_data, info);
[Severity: Critical]
Does this face the same type mismatch regression?
Since the I2C client data points to a struct pmbus_data, using
i2c_get_clientdata() here will also misinterpret the object and result in
out-of-bounds memory access when reading info_local.
Could this be updated to use pmbus_get_driver_info(client) as well?
> + struct tps25990_local_direct_value *info_local = &data->info_local;
> + s32 m, R;
> + s64 b;
> +
> + m = info_local->m[param];
> + b = info_local->b[param];
> + R = info_local->R[param];
> +
> + return pmbus_data2reg_direct_calc(val, b, m, R);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522082349.2749970-1-sbogdanov@baylibre.com?part=3
^ permalink raw reply
* Re: [PATCH 3/5] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Maulik Shah (mkshah) @ 2026-05-22 9:26 UTC (permalink / raw)
To: Konrad Dybcio, Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Linus Walleij, linux-arm-msm,
devicetree, linux-kernel, linux-gpio, Sneh Mankad,
Stephan Gerhold, Johan Hovold
In-Reply-To: <0df69fd0-92f0-4daa-af15-56163b812741@oss.qualcomm.com>
On 3/13/2026 5:19 PM, Konrad Dybcio wrote:
> On 3/13/26 7:40 AM, Maulik Shah (mkshah) wrote:
>>
>>
>> On 3/13/2026 7:52 AM, Dmitry Baryshkov wrote:
>>> On Thu, Mar 12, 2026 at 09:26:37PM +0530, Maulik Shah wrote:
>
> [...]
>
>>>> All the SoCs so far default uses pass through mode with the exception of
>>>
>>> Is it something that must be configured by the bootloaders?
>>
>> yes, currently changing the the mode can be done from secure world either at boot
>> or after boot via scm write.
>
> ..which won't work on almost any X1E devices, except CRD and IOT..
The series "works" for all x1e devices with added SS3 low power mode and GPIO
interrupts also continue to work for all.
>
>>>> x1e. x1e PDC may be set to secondary controller mode for builds on CRD
>>>> boards whereas it may be set to pass through mode for IoT-EVK.
>>>>
>>>> There is no way to read which current mode it is set to and make PDC work
>>>> in respective mode as the read access is not opened up for non secure
>>>> world. There is though write access opened up via SCM write API to set the
>>>> mode.
>>>
>>> What are going to loose? The ability to latch the wakeup sources on the
>>> CRD?
>>
>> CXPC (SoC level low power mode) would be lost if the device can not wake up from GPIO wakeup sources.
>
> To the best of my understanding, that's only because your approach chooses
> to ignore supporting the secondary controller mode and force-reconfigure,
> since GPIO wakeup functionality is otherwise available regardless of the
> mode.
>
Yes, secondary controller mode was of no practical use in Linux and
hence the v1 series chosen to ignore it. This part is captured in the HDD
(hardware design document) too,
"Some of SW platforms can’t detect all type of interrupts [..]
the ask is for the PDC to act as secondary interrupt controller [..]
Please note that not all SW platforms might enable and use this feature"
Linux did not have any problem working with all types of interrupts and
hence did not want to enable and carry this feature in Linux PDC irqchip.
This was added for specific windows SW platform requirement and was never
intended for Linux SW use.
Saying this, In v2 series adding the secondary mode support and with that
PDC irqchip driver will have capability to work in the secondary mode.
>>>> Configure PDC mode to pass through mode for all x1e based boards via SCM
>>>> write.
>>>
>>> Would it make sense to always use the secondary mode instead?
>>
>> No, it would not make sense to support the secondary mode in Linux.
>
> Why?
Above reply covers same.
>
> [...]
>
>>>> + * - Inform TLMM to monitor GPIO IRQs (same as MPM)
>>>> + * - Prevent SoC low power mode (CxPC) as PDC is not
>>>> + * monitoring GPIO IRQs which may be needed to wake
>>>> + * the SoC from low power mode.
>>>
>>> This doesn't quite match the description of "latches the GPIO IRQs".
>>
>> It does, PDC would continue to still latch the GPIO IRQs (as the mode change failed)
>> but PDC won't forward them to parent GIC as they are masked at PDC with __pdc_mask_intr().
>
> Can you not refrain from masking them then, and clear them upon reception,
> with a write to IRQ_i_CFG[IRQ_STATUS]?
This needs other changes too apart from clearing them upon reception.
They are part of v2 (to be sent).
>
> The HPG states that this mechanism is only engaged for GPIO IRQs and that
> the forwarded interrupt will be of LEVEL_HIGH type (which is what TLMM
> accepts anyway)
TLMM isn't much used for IRQs which are routed via PDC.
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH 3/6] drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge
From: Konrad Dybcio @ 2026-05-22 9:28 UTC (permalink / raw)
To: Graham O'Connor, linux-arm-msm
Cc: andersson, konradybcio, robin.clark, lumag, abhinav.kumar, robh,
krzk+dt, conor+dt, dri-devel, devicetree, linux-kernel
In-Reply-To: <20260522060645.4399-4-graham.oconnor@gmail.com>
On 5/22/26 8:06 AM, Graham O'Connor wrote:
> The RA620 DP-to-HDMI bridge used on the Radxa Dragon Q6A does not
> acknowledge DP link training at voltage swing level 3. The bridge
> requests maximum voltage swing but never completes link training
> when the driver attempts level 3, causing HDMI output to fail.
>
> Cap DP_TRAIN_LEVEL_MAX at 2 to match the behaviour of the vendor
> kernel, where link training completes successfully at level 2.
> This allows the RA620 bridge to establish a stable HDMI connection.
>
> Tested on Radxa Dragon Q6A (QCS6490) with RA620 DP-to-HDMI bridge
>
> Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
> ---
> drivers/gpu/drm/msm/dp/dp_link.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_link.h b/drivers/gpu/drm/msm/dp/dp_link.h
> index 76125e9c0..ff0d8e99d 100644
> --- a/drivers/gpu/drm/msm/dp/dp_link.h
> +++ b/drivers/gpu/drm/msm/dp/dp_link.h
> @@ -24,7 +24,7 @@ struct msm_dp_link_info {
> unsigned long capabilities;
> };
>
> -#define DP_TRAIN_LEVEL_MAX 3
> +#define DP_TRAIN_LEVEL_MAX 2
You're limiting this value for *all* devices featuring a Qualcomm
SoC with a DP controller. Instead, if this is really an issue that
results from the bridge's capabilities (which could potentially only
be a symptom, not the cause), this should be somehow limited to the
specific bridge itself
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: cpufreq: qcom-hw: Document Shikra CPUFREQ Hardware
From: Imran Shaik @ 2026-05-22 9:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Ajit Pandey, Taniya Das,
Jagadeesh Kona, linux-pm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260522-juicy-seal-of-wind-a2fc50@quoll>
On 22-05-2026 12:04 pm, Krzysztof Kozlowski wrote:
> On Thu, May 21, 2026 at 07:36:04PM +0530, Imran Shaik wrote:
>> The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
>> but supports only up to 12 frequency lookup table (LUT) entries. Introduce
>> Shikra specific bindings to represent this constrained EPSS variant.
>>
>> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
>> ---
>> .../bindings/cpufreq/qcom,shikra-epss.yaml | 96 ++++++++++++++++++++++
>> 1 file changed, 96 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..8543fd00d82acdbb3422bde462417118aa4c49d1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
>> @@ -0,0 +1,96 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/cpufreq/qcom,shikra-epss.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: CPUFREQ HW for Qualcomm Shikra SoC
>
> Qualcomm Shikra SoC EPSS
>
>> +
>> +maintainers:
>> + - Imran Shaik <imran.shaik@oss.qualcomm.com>
>> + - Taniya Das <taniya.das@oss.qualcomm.com>
>> +
>> +description: |
>> + CPUFREQ HW is a hardware engine used by some Qualcomm SoCs to manage
>
> EPSS is a ....
>
>> + frequency in hardware. It is capable of controlling frequency for
>> + multiple clusters.
>> +
>> + The Qualcomm Shikra CPUFREQ HW supports up to 12 frequency lookup table
>
> here as well, like I mentioned last time. cpufreq is linuxism and I
> asked you about name of actual device.
>
Sure, will drop CPUFREQ and use EPSS as you mentioned, and post next series.
Thanks,
Imran
> With above:
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: cpufreq: qcom-hw: Document Shikra CPUFREQ Hardware
From: Imran Shaik @ 2026-05-22 9:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Ajit Pandey, Taniya Das,
Jagadeesh Kona, linux-pm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260522-massive-hopping-oxpecker-d9dcca@quoll>
On 22-05-2026 12:05 pm, Krzysztof Kozlowski wrote:
> On Thu, May 21, 2026 at 07:36:04PM +0530, Imran Shaik wrote:
>> The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
>> but supports only up to 12 frequency lookup table (LUT) entries. Introduce
>> Shikra specific bindings to represent this constrained EPSS variant.
>>
>> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
>> ---
>> .../bindings/cpufreq/qcom,shikra-epss.yaml | 96 ++++++++++++++++++++++
>> 1 file changed, 96 insertions(+)
>
> Please use subject prefixes matching the subsystem. You can get them for
> example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
> your patch is touching. For bindings, the preferred subjects are
> explained here:
> https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
>
> There is no "qcom-hw" schema, so no clue from where did you get this
> one.
>
Actually, I picked the reference from latest Eliza/Milos commits. Will
drop the qcom-hw prefix, and update as blow for Shikra and post next series.
dt-bindings: cpufreq: Document Qualcomm Shikra SoC EPSS
Thanks,
Imran
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 3/4] PCI: qcom: Add Support for Eliza
From: Krishna Chaitanya Chundru @ 2026-05-22 9:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Bjorn Andersson,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci
In-Reply-To: <20260522-discerning-sympathetic-moth-daa9e7@quoll>
On 5/22/2026 12:21 PM, Krzysztof Kozlowski wrote:
> On Thu, May 21, 2026 at 07:35:31PM +0530, Krishna Chaitanya Chundru wrote:
>> Add support for Eliza soc, which has two PCIe controllers capable
>> of 8GT/s X1 and 8GT/s X2, using the cfg_1_9_0 configuration.
>>
>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>> ---
>> drivers/pci/controller/dwc/pcie-qcom.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>> index af6bf5cce65b..40f0a5f247eb 100644
>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>> @@ -2123,6 +2123,7 @@ static int qcom_pcie_resume_noirq(struct device *dev)
>> static const struct of_device_id qcom_pcie_match[] = {
>> { .compatible = "qcom,pcie-apq8064", .data = &cfg_2_1_0 },
>> { .compatible = "qcom,pcie-apq8084", .data = &cfg_1_0_0 },
>> + { .compatible = "qcom,pcie-eliza", .data = &cfg_1_9_0 },
> So compatible with sm8550. Why isn't this explained in commit msg of
> the binding?
No, PCIe controller is not compatible with sm8550, we are just re using the boot
sequence used by the sm8550.
> Anyway, drop the change, pointless. Look how other devices handle this -
> do you see kaanapali here? No.
As we are going to use different dts schema for this controller we can't
really re-use
like how we have done in kaanapali case. kaanpali is reusing sm8550 schema, where
this controller can't use sm8550 schema, as some clocks are different.
- Krishna Chaitanya.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 3/4] PCI: qcom: Add Support for Eliza
From: Krzysztof Kozlowski @ 2026-05-22 9:34 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Bjorn Andersson,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci
In-Reply-To: <5593d136-569e-4ba9-9a2f-e635125899aa@oss.qualcomm.com>
On 22/05/2026 11:31, Krishna Chaitanya Chundru wrote:
>
>
> On 5/22/2026 12:21 PM, Krzysztof Kozlowski wrote:
>> On Thu, May 21, 2026 at 07:35:31PM +0530, Krishna Chaitanya Chundru wrote:
>>> Add support for Eliza soc, which has two PCIe controllers capable
>>> of 8GT/s X1 and 8GT/s X2, using the cfg_1_9_0 configuration.
>>>
>>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>>> ---
>>> drivers/pci/controller/dwc/pcie-qcom.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>>> index af6bf5cce65b..40f0a5f247eb 100644
>>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>>> @@ -2123,6 +2123,7 @@ static int qcom_pcie_resume_noirq(struct device *dev)
>>> static const struct of_device_id qcom_pcie_match[] = {
>>> { .compatible = "qcom,pcie-apq8064", .data = &cfg_2_1_0 },
>>> { .compatible = "qcom,pcie-apq8084", .data = &cfg_1_0_0 },
>>> + { .compatible = "qcom,pcie-eliza", .data = &cfg_1_9_0 },
>> So compatible with sm8550. Why isn't this explained in commit msg of
>> the binding?
> No, PCIe controller is not compatible with sm8550, we are just re using the boot
> sequence used by the sm8550.
Then with what it is compatible? You cannot use someone else's match
data and claim they are not compatible. This is contradictory to itself.
>> Anyway, drop the change, pointless. Look how other devices handle this -
>> do you see kaanapali here? No.
> As we are going to use different dts schema for this controller we can't
> really re-use
> like how we have done in kaanapali case. kaanpali is reusing sm8550 schema, where
> this controller can't use sm8550 schema, as some clocks are different.
OK, schema is different, that's fine and might need some adjustments.
However this commit clearly states devices are compatible and this needs
to be fixed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 0/3] Enable Inline crypto engine for kodiak and monaco
From: Neeraj Soni @ 2026-05-22 9:34 UTC (permalink / raw)
To: ulf.hansson, robh, krzk+dt, conor+dt, andersson, konradybcio,
ulfh
Cc: linux-mmc, devicetree, linux-kernel
In-Reply-To: <20260310113557.348502-1-neeraj.soni@oss.qualcomm.com>
On 3/10/2026 5:05 PM, Neeraj Soni wrote:
> Document Inline Crypto Engine (ICE) handle for SDHC and add its device-tree
> node to enable it for kodiak and monaco.
>
> How this patch was tested:
> - export ARCH=arm64
> - export CROSS_COMPILE=aarch64-linux-gnu-
> - make menuconfig
> - make defconifg
> - make DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/sdhci-msm.yaml dt_binding_check
> - make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y dtbs
>
> ---
Hi Ulf/Bjorn,
We are looking to target this patch series to be part of 7.2 merge window
if there are no further review comments.
If if is fine, Ulf can you please ack the dt-binding patch (1/3) so that
this entire series be picked via Bjorn tree.
Bjorn i hope this is fine with you.
The v5 of this patch series was "Reviewed-by" Krzysztof for dt-binding changes:
https://lore.kernel.org/all/20260307-llama-of-massive-downpour-2e512a@quoll/
but i missed to add it in v6. Requesting to please apply the tag while picking
the patch series.
Regards,
Neeraj
^ permalink raw reply
* Re: [PATCH 06/11] arm64: dts: qcom: sc8280xp-arcata: Enable 4-lane DP support
From: Konrad Dybcio @ 2026-05-22 9:36 UTC (permalink / raw)
To: jerome.debretagne, Douglas Anderson, Neil Armstrong,
Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: dri-devel, linux-kernel, linux-arm-msm, devicetree,
Krzysztof Kozlowski
In-Reply-To: <20260520-surface-sp9-5g-for-next-v1-6-9df52552bf87@gmail.com>
On 5/20/26 6:40 PM, Jérôme de Bretagne via B4 Relay wrote:
> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>
> Allow up to 4 lanes for the DisplayPort link from the PHYs to the
> controllers and allow mode-switch events to reach the QMP Combo PHYs
> for the 2 left-side USB-C ports.
>
> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH RFC v6 0/7] Add support for Adreno 810 GPU
From: Konrad Dybcio @ 2026-05-22 9:39 UTC (permalink / raw)
To: Akhil P Oommen, Dmitry Baryshkov
Cc: Alexander Koskovich, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Bjorn Andersson, Luca Weiss, linux-arm-msm,
dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <01b424f6-6617-442a-a77f-9b7a8472c447@oss.qualcomm.com>
On 5/20/26 9:38 PM, Akhil P Oommen wrote:
> On 5/17/2026 11:54 PM, Dmitry Baryshkov wrote:
>> On Sat, May 16, 2026 at 03:52:08AM +0530, Akhil P Oommen wrote:
>>> On 5/15/2026 10:38 AM, Alexander Koskovich wrote:
>>>> Adreno 810 is present in the Milos SoC and is the first GPU to be released in
>>>> the A8x family.
>>>>
>>>> This series is marked as RFC because it depends on a few other in review
>>>> series, GPU GX GDSC handling [1], QFPROM efuse for Milos [2], and devicetree
>>>> support for Glymur [3] (for a8xx RSCC offset fix and X2-185 bindings change).
>>>>
>>>> Also depends on the GXCLKCTL block for Milos [4], but this is no longer in
>>>> review and has been applied.
>>>>
>>>> [1]: https://lore.kernel.org/linux-arm-msm/20260427-gfx-clk-fixes-v2-0-797e54b3d464@oss.qualcomm.com
>>>> [2]: https://lore.kernel.org/linux-arm-msm/20260331-milos-qfprom-v1-0-36017cc642db@pm.me
>>>> [3]: https://lore.kernel.org/linux-arm-msm/20260513-glymur-gpu-dt-v4-0-f83832c3bc9a@oss.qualcomm.com
>>>> [4]: https://lore.kernel.org/linux-arm-msm/20260417-milos-gxclkctl-v3-0-08f5988c43a2@fairphone.com
>>>>
>>>> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
>>>
>>> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>
>>> For the rest of the patches that doesn't have my R-b tag in this series.
>>
>> Unfortunately patchwork doesn't capture tags from the responses to the
>> cover letter. I'd kindly ask to spam the list with individual r-b's.
>>
>>
>
> There will be another rev to remove the RFC tag which will hopefully
> have my R-b tag. ;)
Do we have a resolution on whether the proposed fuse values
are OK for this platform?
Konrad
^ permalink raw reply
* Re: [PATCH RFC v6 6/7] drm/msm/adreno: add Adreno 810 GPU support
From: Konrad Dybcio @ 2026-05-22 9:41 UTC (permalink / raw)
To: Alexander Koskovich, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Akhil P Oommen, Bjorn Andersson
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel
In-Reply-To: <20260515-adreno-810-v6-6-fbe04c7203e1@pm.me>
On 5/15/26 7:09 AM, Alexander Koskovich wrote:
> Add catalog entry and register configuration for the Adreno 810
> found in Qualcomm SM7635 (Milos) based devices.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
modulo the speedbin question:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH RFC v6 0/7] Add support for Adreno 810 GPU
From: Konrad Dybcio @ 2026-05-22 9:41 UTC (permalink / raw)
To: Akhil P Oommen, Dmitry Baryshkov
Cc: Alexander Koskovich, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Bjorn Andersson, Luca Weiss, linux-arm-msm,
dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <191d66ef-7d36-41e0-b29f-1ddd47812b75@oss.qualcomm.com>
On 5/22/26 11:39 AM, Konrad Dybcio wrote:
> On 5/20/26 9:38 PM, Akhil P Oommen wrote:
>> On 5/17/2026 11:54 PM, Dmitry Baryshkov wrote:
>>> On Sat, May 16, 2026 at 03:52:08AM +0530, Akhil P Oommen wrote:
>>>> On 5/15/2026 10:38 AM, Alexander Koskovich wrote:
>>>>> Adreno 810 is present in the Milos SoC and is the first GPU to be released in
>>>>> the A8x family.
>>>>>
>>>>> This series is marked as RFC because it depends on a few other in review
>>>>> series, GPU GX GDSC handling [1], QFPROM efuse for Milos [2], and devicetree
>>>>> support for Glymur [3] (for a8xx RSCC offset fix and X2-185 bindings change).
>>>>>
>>>>> Also depends on the GXCLKCTL block for Milos [4], but this is no longer in
>>>>> review and has been applied.
>>>>>
>>>>> [1]: https://lore.kernel.org/linux-arm-msm/20260427-gfx-clk-fixes-v2-0-797e54b3d464@oss.qualcomm.com
>>>>> [2]: https://lore.kernel.org/linux-arm-msm/20260331-milos-qfprom-v1-0-36017cc642db@pm.me
>>>>> [3]: https://lore.kernel.org/linux-arm-msm/20260513-glymur-gpu-dt-v4-0-f83832c3bc9a@oss.qualcomm.com
>>>>> [4]: https://lore.kernel.org/linux-arm-msm/20260417-milos-gxclkctl-v3-0-08f5988c43a2@fairphone.com
>>>>>
>>>>> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
>>>>
>>>> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>
>>>> For the rest of the patches that doesn't have my R-b tag in this series.
>>>
>>> Unfortunately patchwork doesn't capture tags from the responses to the
>>> cover letter. I'd kindly ask to spam the list with individual r-b's.
>>>
>>>
>>
>> There will be another rev to remove the RFC tag which will hopefully
>> have my R-b tag. ;)
>
> Do we have a resolution on whether the proposed fuse values
> are OK for this platform?
Ref:
https://lore.kernel.org/all/oka0Q911ixJLZzAbfWBx54dOmxbQAre36QqHUX4iDZoH3TE5jD-IqTAHspti6B8kfpLQ-OTnuWjFdXtsqJM-CUC8G9R3x_9vFI--LnpppiA=@pm.me/
Konrad
^ permalink raw reply
* Re: [PATCH v4 4/4] hwmon: (pmbus/tps25990): Add TPS1689 support
From: sashiko-bot @ 2026-05-22 9:45 UTC (permalink / raw)
To: Stoyan Bogdanov; +Cc: linux-hwmon, conor+dt, devicetree, robh
In-Reply-To: <20260522082349.2749970-5-sbogdanov@baylibre.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Medium] The output current (`PSC_CURRENT_OUT`) parameters for TPS1689 are configured, but the feature is rendered inactive due to a missing capability flag, and its mantissa is not dynamically scaled by the sense resistor.
Pre-existing issues:
- [Critical] The driver incorrectly uses `i2c_get_clientdata()` to retrieve the `pmbus_driver_info` pointer in `tps25990_reg2data_direct` and `tps25990_data2reg_direct`, resulting in a type confusion and out-of-bounds read.
- [High] The mantissa for the local `TPS25990_IIN_OCF` parameter is not dynamically scaled by the `rimon` resistor value, leading to incorrect over-current fault limits.
--
commit 7807fad0cb3cb2d485b85493ccab6a9ca7c6bdde
Author: Stoyan Bogdanov <sbogdanov@baylibre.com>
hwmon: (pmbus/tps25990): Add TPS1689 support
Extend the existing TPS25990 driver to support the TPS1689 eFuse,
as both devices share the same command interface and functionality.
> diff --git a/drivers/hwmon/pmbus/tps25990.c b/drivers/hwmon/pmbus/tps25990.c
> index 1e252844217b8..720e134f18925 100644
> --- a/drivers/hwmon/pmbus/tps25990.c
> +++ b/drivers/hwmon/pmbus/tps25990.c
[ ... ]
> @@ -286,7 +287,6 @@ static int tps25990_write_word_data(struct i2c_client *client,
> value = clamp_val(value, 0, 0xff);
> ret = pmbus_write_word_data(client, page, reg, value);
> break;
> -
> case PMBUS_VIN_OV_FAULT_LIMIT:
> value = tps25990_data2reg_direct(client, TPS25990_VIN_OVF, value);
[Severity: Critical]
This is a pre-existing issue, but does tps25990_data2reg_direct() retrieve
the correct pointer type here?
Looking at tps25990_data2reg_direct(), it uses i2c_get_clientdata() to
get struct pmbus_driver_info *:
static u16 tps25990_data2reg_direct(struct i2c_client *client, int param, s64 val)
{
struct pmbus_driver_info *info = i2c_get_clientdata(client);
struct tps25990_data *data = container_of(info, struct tps25990_data, info);
Since pmbus_do_probe() sets the client data to its internal
struct pmbus_data *, wouldn't this cast read past the end of
struct pmbus_data into arbitrary heap memory when accessing data->info_local?
Should this use pmbus_get_driver_info(client) to retrieve the correct
pointer instead?
> value = clamp_val(value, 0, 0xf);
> ret = pmbus_write_word_data(client, page, reg, value);
[ ... ]
> @@ -376,6 +376,14 @@ static const struct regulator_desc tps25990_reg_desc[] = {
> #endif
>
> static struct tps25990_local_direct_value tps25990_local_info[] = {
> + [tps1689] = {
> + .m[TPS25990_VIN_OVF] = 3984,
> + .b[TPS25990_VIN_OVF] = -63750,
> + .R[TPS25990_VIN_OVF] = -3,
> + .m[TPS25990_IIN_OCF] = 7111,
[Severity: High]
This is a pre-existing issue, but is the mantissa for TPS25990_IIN_OCF
scaled correctly for custom sense resistors?
Because PMBUS_IIN_OC_FAULT_LIMIT corresponds to a physical current passing
through the sense resistor, shouldn't the mantissa be dynamically scaled by
the hardware rimon resistor value in tps25990_probe(), similar to
PSC_CURRENT_IN?
Without scaling, will writing to PMBUS_IIN_OC_FAULT_LIMIT configure the
over-current protection based on the unscaled default resistor value?
> + .b[TPS25990_IIN_OCF] = -2133,
> + .R[TPS25990_IIN_OCF] = -2,
> + },
> [tps25990] = {
[ ... ]
> @@ -387,6 +395,59 @@ static struct pmbus_driver_info tps25990_base_info[] = {
> + [tps1689] = {
> + .pages = 1,
[ ... ]
> + .format[PSC_CURRENT_OUT] = direct,
> + .m[PSC_CURRENT_OUT] = 24347,
> + .b[PSC_CURRENT_OUT] = 0,
> + .R[PSC_CURRENT_OUT] = -3,
> + .format[PSC_POWER] = direct,
> + .m[PSC_POWER] = 2775,
> + .b[PSC_POWER] = 0,
> + .R[PSC_POWER] = -4,
> + .func[0] = (PMBUS_HAVE_VIN |
> + PMBUS_HAVE_VOUT |
> + PMBUS_HAVE_VMON |
> + PMBUS_HAVE_IIN |
> + PMBUS_HAVE_PIN |
> + PMBUS_HAVE_TEMP |
> + PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_STATUS_IOUT |
> + PMBUS_HAVE_STATUS_INPUT |
> + PMBUS_HAVE_STATUS_TEMP |
> + PMBUS_HAVE_SAMPLES),
[Severity: Medium]
Are we missing the PMBUS_HAVE_IOUT capability flag here?
The format parameters for PSC_CURRENT_OUT are configured above, but
without the capability flag, isn't the feature inaccessible?
Additionally, does tps25990_probe() need to be updated to dynamically scale
the PSC_CURRENT_OUT mantissa with the rimon sense resistor, just like it
does for PSC_CURRENT_IN and PSC_POWER?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522082349.2749970-1-sbogdanov@baylibre.com?part=4
^ permalink raw reply
* Re: [PATCH v15 3/3] of: Respect #{iommu,msi}-cells in maps
From: Vijayanand Jitta @ 2026-05-22 9:47 UTC (permalink / raw)
To: sashiko-reviews; +Cc: imx, conor+dt, devicetree, robh, linux-pci, Frank.Li
In-Reply-To: <4eab296c-1b5f-4767-9e66-22af3474bf67@oss.qualcomm.com>
On 5/21/2026 6:47 PM, Vijayanand Jitta wrote:
>
>
> On 5/20/2026 2:59 PM, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>> - [High] Strict requirement for `#iommu-cells` or `#msi-cells` breaks MSI allocations on standard-compliant controllers.
>> - [High] Array desynchronization when parsing legacy 0-cell maps padded to 4 words per entry.
>> --
>>
>> commit 23cece64ecb1dcea6290dbab34facbdac53ff293
>> Author: Robin Murphy <robin.murphy@arm.com>
>> Date: Wed May 20 08:02:42 2026 +0000
>>
>> of: Respect #{iommu,msi}-cells in maps
>>
>> This commit adds support for parsing target nodes' #cells values for
>> iommu-map and msi-map properties, instead of assuming output specifiers
>> always have exactly 1 cell. It updates of_map_id() to parse multi-cell and
>> 0-cell output specifiers and reflect the actual number of output specifier
>> cells.
>>
>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>> index d658c26201353..f436e26763818 100644
>>> --- a/drivers/of/base.c
>>> +++ b/drivers/of/base.c
>>
>> [ ... ]
>>
>>> @@ -2176,39 +2206,93 @@ int of_map_id(const struct device_node *np, u32 id,
>>
>> [ ... ]
>>
>>> + phandle = be32_to_cpup(map + offset + 1);
>>> phandle_node = of_find_node_by_phandle(phandle);
>>> if (!phandle_node)
>>> return -ENODEV;
>>>
>>> + if (bad_map) {
>>> + cells = 1;
>>> + } else if (of_property_read_u32(phandle_node, cells_name, &cells)) {
>>> + pr_err("%pOF: missing %s property\n", phandle_node, cells_name);
>>> + of_node_put(phandle_node);
>>> + return -EINVAL;
>>> + }
>>
>> [Severity: High]
>> Does this strict requirement for #iommu-cells or #msi-cells break MSI
>> allocations on standard-compliant controllers?
>>
>> Several MSI controllers validly lack a #msi-cells property. For instance,
>> arm,gic-v2m-frame nodes do not require it. In
>> arch/arm64/boot/dts/qcom/ipq5018.dtsi, the pcie0 node defines:
>>
>> msi-map = <0x0 &v2m0 0x0 0xff8>;
>>
>> but v2m0 does not have #msi-cells.
>>
>> Prior to this patch, of_map_id() implicitly consumed 4 words per entry and
>> succeeded. Will it now fail to find #msi-cells, print an error, and
>> return -EINVAL, propagating the error through of_msi_xlate() and breaking
>> MSI initialization on affected platforms?
>>
>
> I see both arch/arm64/boot/dts/qcom/ipq5018.dtsi and ipq5332.dtsi both have
> msi-map pointing to arm,gic-v2m-frame nodes without #msi-cells.
>
> The new strict pr_err + -EINVAL breaks MSI on these platforms. I'll fix this
> in v16 by defaulting cells to '1' when #msi-cells is absent.
>
>
>>> +
>>> + if (cells > MAX_PHANDLE_ARGS) {
>>
>> [ ... ]
>>
>>> + if (map_len - offset < 3 + cells) {
>>> + of_node_put(phandle_node);
>>> + goto err_map_len;
>>> + }
>>> +
>>> + out_base = map + offset + 2;
>>> + offset += 3 + cells;
>>
>> [Severity: High]
>> Could this cause array desynchronization when parsing legacy 0-cell maps
>> that were padded to 4 words per entry?
>>
>> Prior to this patch, of_map_id() mandated that the map property length must
>> be a multiple of 16 bytes:
>>
>> if (!map_len || map_len % (4 * sizeof(*map)))
>> return -EINVAL;
>>
>> Consequently, if a legacy device tree targeted an MSI controller that
>> explicitly defined #msi-cells = <0> (such as RISC-V IMSIC nodes), it was
>> structurally forced to pad the 3-word map entry with a dummy 4th word to
>> satisfy the kernel's length check.
>>
>> Since the new logic computes the entry stride dynamically as 3 + cells,
>> when parsing a legacy padded map with cells=0, does the code advance by 3
>> and incorrectly interpret the 4th dummy word of the first entry as the
>> id_base of the second entry?
>>
>
> I see there is no real in-tree DT combines #msi-cells = <0> or #iommu-cells = <0>
> with msi-map/iommu-map. All in-tree #msi-cells = <0> nodes (RISC-V IMSIC) use msi-parent.
> If such DTs appear in the future, they would need to use the new 3-word entry format
> (without the old padding), which is correct per the binding spec.
>
> So, No changes are needed here.
>
> Thanks,
> Vijay
>
Please do let me know if there are any further comments. I'll address those
as well as part of v16.
Thanks,
Vijay
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Konrad Dybcio @ 2026-05-22 9:47 UTC (permalink / raw)
To: Loic Poulain, Manivannan Sadhasivam, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <20260520-monza-wireless-v1-3-9f6942310653@oss.qualcomm.com>
On 5/20/26 1:01 PM, Loic Poulain wrote:
> Add support for the QCA2066 (QCNFA765) WiFi/Bluetooth module on the
> Arduino VENTUNO Q board. The module is interfaced via LGA and is
> compatible with the M.2 Key E.
>
> Add wireless-lga-connector node using pcie-m2-e-connector binding,
> connecting PCIe port 0 to the WiFi interface and UART10 port 3 to
> the Bluetooth interface.
>
> Add pcie@1,0 downstream port node with pciclass,0604 compatible so
> the pci-pwrctrl driver can acquire the power sequencer and enable
> the M.2 slot before PCIe enumeration.
>
> Add nfa725b_default_state pinctrl for the W_DISABLE1/2 GPIOs
> (gpio56/gpio55) used by the power sequencer.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Konrad Dybcio @ 2026-05-22 9:48 UTC (permalink / raw)
To: Loic Poulain, Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <CAFEp6-3Gbd1gzfeu5xdfBJixL6JXaoSFkRUsBjOji0ZEOHHyvw@mail.gmail.com>
On 5/20/26 4:41 PM, Loic Poulain wrote:
> On Wed, May 20, 2026 at 4:36 PM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>
>> On Wed, May 20, 2026 at 04:29:40PM +0200, Loic Poulain wrote:
>>> On Wed, May 20, 2026 at 2:34 PM Dmitry Baryshkov
>>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>>>
>>>> On Wed, May 20, 2026 at 01:01:44PM +0200, Loic Poulain wrote:
>>>>> Add support for the QCA2066 (QCNFA765) WiFi/Bluetooth module on the
>>>>> Arduino VENTUNO Q board. The module is interfaced via LGA and is
>>>>> compatible with the M.2 Key E.
>>>>>
>>>>> Add wireless-lga-connector node using pcie-m2-e-connector binding,
>>>>> connecting PCIe port 0 to the WiFi interface and UART10 port 3 to
>>>>> the Bluetooth interface.
>>>>>
>>>>> Add pcie@1,0 downstream port node with pciclass,0604 compatible so
>>>>> the pci-pwrctrl driver can acquire the power sequencer and enable
>>>>> the M.2 slot before PCIe enumeration.
>>>>>
>>>>> Add nfa725b_default_state pinctrl for the W_DISABLE1/2 GPIOs
>>>>> (gpio56/gpio55) used by the power sequencer.
>>>>>
>>>>> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 65 +++++++++++++++++++++++
>>>>> 1 file changed, 65 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
>>>>> index 93ed575817af1c5e903662c209ead629fe202ee2..6fcad77f320cb82eccb6f07244d185abfb1976d9 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
>>>>> +++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
>>>>> @@ -154,6 +154,39 @@ vreg_nvme: regulator-3p3-m2 {
>>>>> enable-active-high;
>>>>> startup-delay-us = <20000>;
>>>>> };
>>>>> +
>>>>> + wireless-lga-connector {
>>>>> + compatible = "pcie-m2-e-connector";
>>>>
>>>> I think it was discussed that LGA can't be an actual M.2 E-key
>>>> connector.
>>>
>>> I am not sure I followed this discussion. Do you mean that I should
>>> introduce a dedicated LGA/vendor-compatible string in the compatible
>>> list of the pcie-m2-e-connector binding, or that LGA-based designs
>>> should not be described using the pcie-m2-e-connector binding (graph
>>> representation)?
>>
>> I think, it should be a separate, vendor-specific compat (maybe using
>> m2-e as a fallback).
>
> ok, understood.
Oh, I reviewed this before looking at this discussion.. yeah Dmitry's
suggestion is good
Konrad
^ permalink raw reply
* [PATCH] arm64: dts: glymur-crd: Add reset GPIO to touchscreen node
From: Pradyot Kumar Nayak @ 2026-05-22 9:56 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abel Vesa, Dmitry Baryshkov
Cc: linux-arm-msm, Konrad Dybcio, devicetree, linux-kernel,
Pradyot Kumar Nayak,
20260519-glymur-mahua-common-nodes-v2-1-9f1b89a3f398
The touchscreen module on Glymur/Mahua CRDs is different from the one
used on Hamoa CRDs and requires the reset-gpios to be wired to the device.
Without this in place the reset line will remain permanently asserted
during resume leaving the device offline and causing all I2C transactions
to fail with -ENXIO.
Error Logs:
i2c_hid_of 3-0038: failed to change power setting.
i2c_hid_of 3-0038: PM: dpm_run_callback(): i2c_hid_core_pm_resume [i2c_hid] returns -6
i2c_hid_of 3-0038: PM: failed to resume async: error -6
Add the reset GPIO so the driver can deassert the line on resume,
restoring I2C communication with the device.
Fixes: e6bf559f7eb9 ("arm64: dts: qcom: glymur-crd: Enable keyboard, trackpad and touchscreen")
Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
---
arm64: dts: glymur-crd: Add reset GPIO to touchscreen
prerequisite-message-id: 20260519-glymur-mahua-common-nodes-v2-1-9f1b89a3f398@oss.qualcomm.com
---
arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
index 1de3a49f49e4..2259577b9ae1 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
@@ -623,6 +623,8 @@ touchscreen@38 {
vdd-supply = <&vreg_misc_3p3>;
vddl-supply = <&vreg_l15b_e0_1p8>;
+ reset-gpios = <&tlmm 48 GPIO_ACTIVE_LOW>;
+
pinctrl-0 = <&ts0_default>;
pinctrl-names = "default";
};
---
base-commit: 1d376e58cb4a94f89de0fa9195d583ad6b86eb89
change-id: 20260522-arm64-dts-glymur-crd-add-reset-gpio-to-touchscreen-5892beded29b
Best regards,
--
Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
^ permalink raw reply related
* RE: [PATCH v3 6/8] iio: core: Add IIO_COVERAGE channel type
From: Stan, Liviu @ 2026-05-22 9:57 UTC (permalink / raw)
To: Stan, Liviu, Jonathan Cameron, David Lechner, Sa, Nuno,
Andy Shevchenko, Hennerich, Michael, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Miclaus, Antoniu,
Francesco Lavra, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, linux, devicetree@vger.kernel.org
In-Reply-To: <20260521164323.770626-7-liviu.stan@analog.com>
Hello everyone, I'll reply to sashiko's review here:
On Thu, 21 May 2026 18:10:28 +0000 sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] The sysfs ABI documentation for IIO_COVERAGE incorrectly uses 'X' instead of 'Y' as the channel index wildcard.
> --
>
> commit 6217a0a065fdaa7ef3fffa525f2928d59a323a05
> Author: Liviu Stan <liviu.stan@analog.com>
> iio: core: Add IIO_COVERAGE channel type
>
> This commit introduces a new channel type for sensors that report fractional
> coverage as a percentage. It updates the core IIO structures and provides
> the necessary sysfs ABI documentation for the new attributes.
>
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> > index 4fc9f6bd42812..90fb8ef26de0e 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -1959,6 +1959,23 @@ Description:
> > Raw (unscaled no offset etc.) resistance reading.
> > Units after application of scale and offset are ohms.
> >
> > +What: /sys/bus/iio/devices/iio:deviceX/in_coverageX_raw
>
> [Severity: Low]
> Should this use Y for the channel index wildcard instead of X? The IIO sysfs
> ABI documentation typically uses X strictly for the device index and Y for the
> channel index, which would make this in_coverageY_raw.
>
> > +KernelVersion: 7.2
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + Raw (unscaled no offset etc.) coverage reading. Used for sensors
> > + that report fractional coverage as a percentage, such as leak
> > + detectors where the value represents what portion of the sensing
> > + element is wetted. Units after application of scale and offset are
> > + percent.
> > +
> > +What: /sys/bus/iio/devices/iio:deviceX/in_coverageX_scale
>
> [Severity: Low]
> Does this attribute have the same naming consistency issue? Following the
> standard convention, this would be in_coverageY_scale.
>
> --
> Sashiko AI review * https://sashiko.dev/#/patchset/20260521164323.770626-1-liviu.stan@analog.com?part=6
>
I see now that other attributes have Y as the channel index wildcard.
Will change
Thanks,
Liviu
^ 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