* Re: [PATCH 0/3] arm64: dts: tegra: CPU and cache node updates
From: Thierry Reding @ 2026-06-25 9:10 UTC (permalink / raw)
To: jonathanh, robh, krzk+dt, conor+dt, devicetree, linux-tegra,
linux-kernel, Sumit Gupta
Cc: bbasu
In-Reply-To: <20260121104536.3214101-1-sumitg@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
On Wed, 21 Jan 2026 16:15:33 +0530, Sumit Gupta wrote:
> - Fixes for Tegra234/264 device tree CPU compatible string.
> - Populate CPU and L2 cache nodes for Tegra264.
>
> Sumit Gupta (3):
> arm64: dts: tegra234: Fix CPU compatible string to cortex-a78ae
> arm64: dts: tegra264: Fix CPU1 node unit-address
> arm64: dts: tegra264: Populate CPU and L2 cache nodes
>
> [...]
Applied, thanks!
[1/3] arm64: dts: tegra234: Fix CPU compatible string to cortex-a78ae
commit: 2e1f4664c1be73065070d8b380a3c7440f98f6a4
[2/3] arm64: dts: tegra264: Fix CPU1 node unit-address
commit: c003ea35f934a9e6672ea02778f07f08cb6f13ad
[3/3] arm64: dts: tegra264: Populate CPU and L2 cache nodes
commit: 1199de78b2ca6439e83a565fe39eb4fed67d70b8
Best regards,
--
Thierry Reding <treding@nvidia.com>
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Grégoire Layet @ 2026-06-25 9:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <b9ca9e36-a851-4a98-a739-ca99dd534d6d@kernel.org>
Hi Krzysztof,
> > It's a Virtual UART. Internally, it's two FIFOs accessible via
> > 8250-compatible register sets on both ends.
>
> I do not know what is Virtual UART...
Yes the name of ASPEED is a bit weird, it means that it is not a real
UART. It is two 8250-compatible register sets, and the data path is
handled by two hardware FIFOs (one per direction).
> > There is 4 Virtuals UARTs on the LPC bus of the AST2600 and 2 of them
> > are bridged over the PCI bus.
> > So, from the host, you can access the 8250 register set on the PCI bus.
>
> You mean these appear (or are) as PCI devices?
Yes but not as a UART devices.
The two VUART are accessible under the same PCIe BMC device, at the
VUART addresses configured on the BMC. They are accessible on the BAR1
of the PCIe BMC device.
There is a 2 bit left shift between the addresses of the registers on
the BMC LPC bus and the addresses accessible over the PCI device.
0x3F8 on the BMC is accessible at BAR1 0xFE0 over the PCI device.
The PCIe BMC Device is one PCI device where you can access several
peripherals. It's not one PCI device per VUART.
For example, you can also enable the KCS channel 4 and it will be also
accessible via the BAR1 of the PCI BMC device. KCS is a protocol used
for IPMI.
Only these two peripherals can be accessed over the PCI BMC device and
they need to be enabled.
The host cannot access everything on the LPC bus of the BMC.
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode
From: Mukesh Savaliya @ 2026-06-25 9:06 UTC (permalink / raw)
To: Konrad Dybcio, Pengyu Luo, Dmitry Baryshkov
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Bjorn Andersson, linux-arm-msm, linux-spi, devicetree,
linux-kernel
In-Reply-To: <3451facc-4a2e-43bf-ba13-944488bce437@oss.qualcomm.com>
Hi Konrad, sorry for late response.
On 6/15/2026 5:12 PM, Konrad Dybcio wrote:
> On 6/15/26 6:25 AM, Pengyu Luo wrote:
>> On Mon, Jun 15, 2026 at 5:18 AM Dmitry Baryshkov
>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>>
>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>> also support GSI mode, which is highly preferred for certain
>>>> peripherals like SPI touchscreens to improve performance.
>>>>
>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>> the controller into GSI mode during initialization.
>>>
>>> Ideally, this should be decided by the SPI controller based on the
>>> requirements. Another option would be to prefer GSI for all transfers if
>>> it is available, ignoring the FIFO even if it is not disabled.
>>>
>>
>> I have read reviews. Can we check if the compatible
>> "qcom,sm6350-gpi-dma" is in DT? If the gpi dma controller is
>> presented, then we enable GSI mode.
>
>
> This hunk is very odd:
>
> /*
> * in case of failure to get gpi dma channel, we can still do the
> * FIFO mode, so fallthrough
> */
> dev_warn(mas->dev, "FIFO mode disabled, but couldn't get DMA, fall back to FIFO mode\n");
>
> In my understanding, GSI DMA mode is always preferable. +Mukesh, do
> you have any insights?
>
GSI mode is preferable but if for some reason it fails, we try to
continue with the FIFO mode. Just fallback mechanism.
> Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-25 8:56 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <a13fb65c-726b-4c99-b741-29040c4564d0@oss.qualcomm.com>
On Thu, Jun 25, 2026 at 09:01:18AM +0800, Jie Gan wrote:
[...]
> > > However, I believe it is acceptable to allocate an ATID for the itNoC device
> > > and the issue can be fixed with this way.
> >
> > I think so.
>
> Hi Suzuki/Leo
>
> Which solution do you prefer to address the issue?
I will leave this to Suzuki.
> The interconnect traceNoC platform driver is intended for the itnoc device,
> implying that no TPDM devices are connected to it. So, if I modify it to
> allocate an ATID, I think it would be better to rename the “itnoc” node
> accordingly? Or it's ok to leave it as-is?
>
> BTW, the traceNoC device definitely is an AMBA device with CID/PID
> registers.
Just to share a bit thoughts on the driver's design.
I think it would be better to keep the probe function generic. The AMBA
probe should not be specific to TraceNoC, and the platform probe should
not be only dedicated to the interconnect TraceNoC. The probe function
should simply handle a device that appears on either the AMBA bus or the
platform bus.
So the question is: if allocat an ATID for all traceNoC devices, do you
still need to distinguish TraceNoC types? If no, then the code can be
unified.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Konrad Dybcio @ 2026-06-25 8:47 UTC (permalink / raw)
To: Bibek Kumar Patro, Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <aaf4daee-4886-4214-a761-80545d2565ee@oss.qualcomm.com>
On 6/19/26 12:54 PM, Bibek Kumar Patro wrote:
>
>
> On 6/18/2026 2:58 PM, Konrad Dybcio wrote:
>> On 6/17/26 4:26 PM, Bibek Kumar Patro wrote:
>>>
>>>
>>> On 6/16/2026 5:51 AM, Dmitry Baryshkov wrote:
>>>> On Mon, Jun 15, 2026 at 06:36:51PM +0530, Bibek Kumar Patro wrote:
>>>>>
>>>>>
>>>>> On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
>>>>>> On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
>>>>>>> On some SoCs the SMMU registers require an active interconnect
>>>>>>> bandwidth vote to be accessible. While other clients typically
>>>>>>> satisfy this requirement implicitly, certain corner cases (e.g.
>>>>>>> during sleep/wakeup transitions) can leave the SMMU without a
>>>>>>> vote, causing intermittent register access failures.
>>>>>>>
>>>>>>> Add support for an optional interconnect path to the arm-smmu
>>>>>>> driver and vote for bandwidth while the SMMU is active. The path
>>>>>>> is acquired from DT if present and ignored otherwise.
>>>>>>>
>>>>>>> The bandwidth vote is enabled before accessing SMMU registers
>>>>>>> during probe and runtime resume, and released during runtime
>>>>>>> suspend and on error paths.
>>>>>>>
>>>>>>> Generally, from an architectural perspective, GEM_NOC and DDR are
>>>>>>> expected to have an active vote whenever the adreno_smmu block is
>>>>>>> powered on. In most common use cases, this requirement is implicitly
>>>>>>> satisfied because other GPU-related clients (for example, the GMU
>>>>>>> device) already hold a GEM_NOC vote when adreno_smmu is enabled.
>>>>>>>
>>>>>>> However, there are certain corner cases, such as during sleep/wakeup
>>>>>>> transitions, where the GEM_NOC vote can be removed before adreno_smmu
>>>>>>> is powered down. If adreno_smmu is then accessed while the interconnect
>>>>>>> vote is missing, it can lead to the observed failures. Because of the
>>>>>>> precise ordering involved, this scenario is difficult to reproduce
>>>>>>> consistently.
>>>>>>> (also GDSC is involved in adreno usecases can have an independent vote)
>>>>>>>
>>>>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>>>>> ---
>>>>>>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
>>>>>>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
>>>>>>> 2 files changed, 57 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
>>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>> @@ -53,6 +53,11 @@
>>>>>>> #define MSI_IOVA_BASE 0x8000000
>>>>>>> #define MSI_IOVA_LENGTH 0x100000
>>>>>>> +/* Interconnect bandwidth vote values for the SMMU register access path */
>>>>>>> +#define ARM_SMMU_ICC_AVG_BW 0
>>>>>>> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
>>>>>>
>>>>>> totally random numbers, which might be different for non-Qualcomm platform.
>>>>>>
>>>>>
>>>>> Ideally, any non-zero value would be enough to keep the path active.
>>>>
>>>> This is true for Qualcomm devices. However, you are adding this to a
>>>> generic code.
>>>>
>>>>> Here 1 Would be enough to keep the path active, but might be too small to
>>>>> reliably keep the bus active.
>>>>> Other is UINT_MAX, which will reliably keep the bus active but might cause a
>>>>> power penalty.
>>>>>
>>>>> #define ARM_SMMU_ICC_PEAK_BW_HIGH UINT_MAX
>>>>>
>>>>> seems to be suitable here to reliably keep the bus active by BCM
>>>>> for both Qualcomm and non-Qualcomm platforms (with some power penalty).
>>>>>
>>>>> LMK, if you feel otherwise.
>>>>
>>>> Shift it to the qcom instance or provide platform-specific values? (My
>>>> preference would be towards the first solution).
>>>>
>>>
>>>
>>> To support platform-specific values, we may need to introduce a LUT-based approach in the driver. (Bandwidth voting values cannot be placed in device-tree property IIRC ?)
>>>
>>> Currently, all Qualcomm platforms use 0x1000 for SMMU ICC voting. I
>>
>> (you used decimal 1000)
>>
>
> It's my bad, i meant 1000 only
> (I'll check on the icc_bw calculation to get clarity on the values)
>
>>> can evaluate if this could be moved to a Qualcomm-specific
>>> implementation.
>>
>> Add a vendor hook to arm_smmu_runtime_suspend/resume and handle it within
>> the QC driver
>>
>
> Just curious, wouldn't this apply for all the arm-smmu users in addition to Qualcomm devices as i mentioned here [1].
> Vendor hook would make it Qualcomm specific.
You're proposing to use a Qualcomm-specific bandwidth value so that
fits
Konrad
>
> [1]: https://lore.kernel.org/all/984ff9c7-3eef-463c-a330-bf7acd063667@oss.qualcomm.com/
>
> Thanks & regards,
> Bibek
>
>> Konrad
>
^ permalink raw reply
* Re: [PATCH v4 13/13] arm64: dts: qcom: shikra: Add support for DISPCC/GPUCC nodes
From: Konrad Dybcio @ 2026-06-25 8:44 UTC (permalink / raw)
To: Imran Shaik, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Loic Poulain, Brian Masney
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-arm-msm, linux-clk,
devicetree, linux-kernel
In-Reply-To: <20260604-shikra-dispcc-gpucc-v4-13-8204f1029311@oss.qualcomm.com>
On 6/4/26 7:26 AM, Imran Shaik wrote:
> Add support for Display clock controller and GPU clock controller nodes
> on Qualcomm Shikra SoCs.
>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 41 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..1ccb0f1419aaa34d32f3c3eaabdb8727a497b501 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -3,6 +3,8 @@
> * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> */
>
> +#include <dt-bindings/clock/qcom,dispcc-qcm2290.h>
> +#include <dt-bindings/clock/qcom,qcm2290-gpucc.h>
> #include <dt-bindings/clock/qcom,rpmcc.h>
> #include <dt-bindings/clock/qcom,shikra-gcc.h>
> #include <dt-bindings/interconnect/qcom,icc.h>
> @@ -640,6 +642,45 @@ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
> };
> };
>
> + gpucc: clock-controller@5990000 {
> + compatible = "qcom,shikra-gpucc";
> + reg = <0x0 0x05990000 0x0 0x9000>;
> + clocks = <&gcc GCC_GPU_CFG_AHB_CLK>,
> + <&rpmcc RPM_SMD_XO_CLK_SRC>,
> + <&gcc GCC_GPU_GPLL0_CLK_SRC>,
> + <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
> + power-domains = <&rpmpd RPMPD_VDDCX>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + };
> +
> + dispcc: clock-controller@5f00000 {
> + compatible = "qcom,shikra-dispcc", "qcom,qcm2290-dispcc";
> + reg = <0x0 0x05f00000 0x0 0x20000>;
> + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
> + <&rpmcc RPM_SMD_XO_A_CLK_SRC>,
> + <&gcc GCC_DISP_GPLL0_CLK_SRC>,
> + <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>,
> + <0>,
> + <0>,
> + <0>,
> + <0>,
> + <&sleep_clk>;
> + clock-names = "bi_tcxo",
> + "bi_tcxo_ao",
Is the AO clock going to be any useful? Taniya recently dropped it
from some other submission after assessing it wasn't
> + "gcc_disp_gpll0_clk_src",
> + "gcc_disp_gpll0_div_clk_src",
> + "dsi0_phy_pll_out_byteclk",
> + "dsi0_phy_pll_out_dsiclk",
> + "dsi1_phy_pll_out_byteclk",
> + "dsi1_phy_pll_out_dsiclk",
> + "sleep_clk";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
DISP_CC also needs to source power from somewhere!
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8996-xiaomi-gemini: Fix up ti,drv2604 enable GPIO
From: Krzysztof Kozlowski @ 2026-06-25 8:44 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Raffaele Tranquillini, Yassine Oudjana
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260625-topic-ti_drv2604_dtwarn-v1-1-76e91fcafbe8@oss.qualcomm.com>
On 25/06/2026 10:42, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Update the 'enable-gpio' property name to 'enable-gpios' to conform to
> the bindings for the TI DRV2604 haptics module. While at it, use the
> GPIO_ACTIVE_HIGH define instead of the raw literal.
>
> Fixes: 4ac46b3682c5 ("arm64: dts: qcom: msm8996: xiaomi-gemini: Add support for Xiaomi Mi 5")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/msm8996-xiaomi-gemini.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: qcom: msm8996-xiaomi-gemini: Fix up ti,drv2604 enable GPIO
From: Konrad Dybcio @ 2026-06-25 8:42 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Raffaele Tranquillini, Yassine Oudjana
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Update the 'enable-gpio' property name to 'enable-gpios' to conform to
the bindings for the TI DRV2604 haptics module. While at it, use the
GPIO_ACTIVE_HIGH define instead of the raw literal.
Fixes: 4ac46b3682c5 ("arm64: dts: qcom: msm8996: xiaomi-gemini: Add support for Xiaomi Mi 5")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/msm8996-xiaomi-gemini.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996-xiaomi-gemini.dts b/arch/arm64/boot/dts/qcom/msm8996-xiaomi-gemini.dts
index fd3a2121465b..ca22e2f9d20a 100644
--- a/arch/arm64/boot/dts/qcom/msm8996-xiaomi-gemini.dts
+++ b/arch/arm64/boot/dts/qcom/msm8996-xiaomi-gemini.dts
@@ -39,7 +39,7 @@ &blsp2_i2c3 {
haptics: drv2604@5a {
compatible = "ti,drv2604";
reg = <0x5a>;
- enable-gpio = <&tlmm 93 0x00>;
+ enable-gpios = <&tlmm 93 GPIO_ACTIVE_HIGH>;
mode = <DRV260X_LRA_MODE>;
library-sel = <DRV260X_LIB_LRA>;
pinctrl-names = "default","sleep";
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260625-topic-ti_drv2604_dtwarn-06bc191359b3
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH 2/4] dt-bindings: display: tegra: Add channel/syncpoint range properties
From: Krzysztof Kozlowski @ 2026-06-25 8:36 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260622-host1x-nohv-v1-2-65bc682a617f@nvidia.com>
On Mon, Jun 22, 2026 at 05:22:51PM +0900, Mikko Perttunen wrote:
> Channels and syncpoints available may be limited when other system
What are channels and syncpoints?
> components are using them. Add properties nvidia,channels and
> nvidia,syncpoints to limit the range of usable channels and/or
> syncpoints.
Why isn't this deducible from the compatible?
Also, nvidia,channels is too broad/generic. This is not ADC, right? And
channels is a common term in IIO. And in few other cases.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display: tegra: Make non-vm registers optional
From: Krzysztof Kozlowski @ 2026-06-25 8:34 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260622-host1x-nohv-v1-1-65bc682a617f@nvidia.com>
On Mon, Jun 22, 2026 at 05:22:50PM +0900, Mikko Perttunen wrote:
> Host1x can be used without accessing the hypervisor or common
> registers. Adjust the bindings to make them optional.
You still have these registers in the hardware, so it is not optional,
not flexible. IOW, DTS represents the view of real hardware for the
software, and that hardware still has this address space regardless if
OS should use it or not.
Otherwise you need to provide better background here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 6/7] power: supply: Add driver for ASUS Transformer battery
From: sashiko-bot @ 2026-06-25 8:31 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, robh, devicetree, linux-leds, dmitry.torokhov,
linux-input, lee
In-Reply-To: <20260625081529.22447-7-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Driver implements one battery cell per EC controller and supports reading
> of battery status for ASUS Transformer's pad and mobile dock.
>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v6 5/6 RESEND] mfd: motorola-cpcap: diverge configuration per-board
From: sashiko-bot @ 2026-06-25 8:29 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: devicetree, linux-input, conor+dt, linux-leds, robh, lee,
dmitry.torokhov
In-Reply-To: <20260625081812.33474-6-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Repurposing the `motorola,cpcap` compatible string and removing `st,6556002` breaks backwards compatibility with existing Device Trees.
- [Low] Direct cast from `const void *` to `enum cpcap_variant` will cause a `-Wpointer-to-int-cast` compiler warning on 64-bit architectures.
--
commit bcc834e6accda9ec696d0ed365c9e5ada87bff4f
Author: Svyatoslav Ryhel <clamor95@gmail.com>
mfd: motorola-cpcap: diverge configuration per-board
MFD have rigid subdevice structure which does not allow flexible dynamic
subdevice linking. Address this by diverging CPCAP subdevice composition
to take into account board specific configuration.
> diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> index d8243b956f875..5b6ca6b81c232 100644
> --- a/drivers/mfd/motorola-cpcap.c
> +++ b/drivers/mfd/motorola-cpcap.c
[ ... ]
> @@ -241,62 +229,58 @@ static int cpcap_resume(struct device *dev)
[ ... ]
> +static const struct mfd_cell cpcap_default_devices[] = {
> + MFD_CELL_OF("cpcap_adc", NULL, NULL, 0, 0, "motorola,cpcap-adc"),
> + MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0, "motorola,cpcap-regulator"),
> + MFD_CELL_OF("cpcap-usb-phy", NULL, NULL, 0, 0, "motorola,cpcap-usb-phy"),
> +};
[Severity: Critical]
Does repurposing the default configuration break backwards compatibility with
existing Device Trees?
Existing hardware using the "motorola,cpcap" compatible string will now
use this generic array. It completely omits the charger and uses non-Mapphone
of_compatible strings, which will prevent existing child nodes (like
"motorola,mapphone-cpcap-adc") from successfully binding.
[ ... ]
> static int cpcap_probe(struct spi_device *spi)
> {
> struct cpcap_ddata *cpcap;
> + const struct mfd_cell *cells;
> + unsigned int num_cells;
> int ret;
>
> cpcap = devm_kzalloc(&spi->dev, sizeof(*cpcap), GFP_KERNEL);
> if (!cpcap)
> return -ENOMEM;
>
> + cpcap->variant = (enum cpcap_variant)spi_get_device_match_data(spi);
[Severity: Low]
Will this direct cast from const void * to enum cpcap_variant cause a
-Wpointer-to-int-cast compiler warning when building on 64-bit architectures?
[ ... ]
> @@ -331,10 +315,29 @@ static int cpcap_probe(struct spi_device *spi)
[ ... ]
> +static const struct of_device_id cpcap_of_match[] = {
> + { .compatible = "motorola,cpcap", .data = (void *)CPCAP_DEFAULT },
> + { .compatible = "motorola,mapphone-cpcap", .data = (void *)CPCAP_MAPPHONE },
> + { /* sentinel */ }
> +};
[Severity: Critical]
Does removing the "st,6556002" compatible string and re-mapping
"motorola,cpcap" to CPCAP_DEFAULT break existing devices?
Devices in the wild using "motorola,cpcap" or "st,6556002" in their
device tree may fail to probe critical PMIC functionality because they
are no longer correctly matched with their required Mapphone components.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v6 4/6 RESEND] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
From: sashiko-bot @ 2026-06-25 8:27 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, devicetree, lee, conor+dt, dmitry.torokhov, linux-input,
linux-leds
In-Reply-To: <20260625081812.33474-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The newly added device tree compatible strings `motorola,mapphone-cpcap` and `motorola,mot-cpcap` are defined as a standalone enum without a fallback, forcing device trees to either break schema validation or break OMAP platform initialization.
--
commit 6926040210bec2501eaa0528dd29bde0ac318c6c
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
Add compatibles for Mapphone and Mot CPCAP subdevice compositions. Both
variations cannot use st,6556002 fallback since they may be based on
different controllers.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> --- a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
[ ... ]
> @@ -14,9 +14,14 @@ allOf:
>
> properties:
> compatible:
> - items:
> - - const: motorola,cpcap
> - - const: st,6556002
> + oneOf:
> + - enum:
> + - motorola,mapphone-cpcap
> + - motorola,mot-cpcap
[Severity: High]
Will this schema change break OMAP platform initialization for devices
using these new variants?
The schema defines the new compatibles as a standalone enum. However, the
OMAP platform initialization code explicitly relies on finding a node with the
generic motorola,cpcap compatible to configure the PMIC:
arch/arm/mach-omap2/pmic-cpcap.c:omap4_cpcap_init() {
...
if (!of_find_compatible_node(NULL, NULL, "motorola,cpcap"))
return -ENODEV;
...
}
If a device tree conforms to this new schema (using only the specific variant
compatible), the platform code will fail to find the node, breaking PMIC setup
and CPU voltage scaling.
Conversely, if a device tree defines an items array using motorola,cpcap as a
fallback to successfully initialize the platform code, it will fail schema
validation because this oneOf block expects either a standalone enum or the
specific ["motorola,cpcap", "st,6556002"] items list.
Should the new variants include motorola,cpcap as a fallback in an items
array, or does the OMAP platform code need an update to recognize these
new standalone compatibles?
> +
> + - items:
> + - const: motorola,cpcap
> + - const: st,6556002
>
> reg:
> maxItems: 1
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v9 3/7] input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
From: sashiko-bot @ 2026-06-25 8:27 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: dmitry.torokhov, conor+dt, linux-input, devicetree, robh,
linux-leds, lee
In-Reply-To: <20260625081529.22447-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Premature registration of the event notifier before callback initialization causes a race condition leading to a NULL pointer dereference.
- [High] Incorrect devres ordering leaves the notifier active after serio ports are destroyed, causing a Use-After-Free during teardown.
- [High] Incorrect bounds check on the EC packet length allows an out-of-bounds heap read and exposes uninitialized memory.
--
commit 27a9e7909b45cc654374940aa7f4c4574172729b
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
Add input driver for ASUS Transformer dock keyboard and touchpad. Modify
incoming keyboard data to send proper scancodes for keys that don't match
their position.
> diff --git a/drivers/input/serio/asus-transformer-ec-kbc.c b/drivers/input/serio/asus-transformer-ec-kbc.c
> new file mode 100644
> index 0000000000000..3ddfa9925b2b0
> --- /dev/null
> +++ b/drivers/input/serio/asus-transformer-ec-kbc.c
[ ... ]
> +static int asus_ec_kbc_notify(struct notifier_block *nb,
> + unsigned long action, void *data_)
> +{
[ ... ]
> + /*
> + * The data[0] is the length of the packet including itself. The data[]
> + * buffer has to be at least 3 bytes (length + ctrl + 1 data byte) and
> + * must not exceed the EC buffer size.
> + */
> + if (data[0] < 2 || data[0] > ASUSEC_ENTRY_BUFSIZE)
> + return NOTIFY_BAD;
> +
> + n = data[0] - 1;
> + data += 2;
[ ... ]
> + while (n--)
> + serio_interrupt(priv->sdev[port_idx], *data++, 0);
[Severity: High]
If data[0] is ASUSEC_ENTRY_BUFSIZE (33), n becomes 32, and data is advanced
by 2. Will the loop read 32 bytes from data[2] up to data[33]?
Since the buffer is exactly 33 bytes long, could this read past the end of
the array or access uninitialized data?
> +
> + return NOTIFY_OK;
> +}
[ ... ]
> +static int asus_ec_kbc_probe(struct platform_device *pdev)
> +{
> + struct asusec_core *ec = dev_get_drvdata(pdev->dev.parent);
> + struct asus_ec_kbc_data *priv;
> + int error;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> +
> + priv->ec = ec;
> + priv->parent = to_i2c_client(pdev->dev.parent);
> +
> + error = blocking_notifier_chain_register(&ec->notify_list, &priv->nb);
[Severity: High]
Is it safe to register the notifier here before priv->nb.notifier_call is
initialized?
If an interrupt fires immediately after registration, could the notifier core
attempt to call a NULL pointer?
> + if (error)
> + return dev_err_probe(&pdev->dev, error,
> + "failed to register blocking notifier chain");
> +
> + error = devm_add_action_or_reset(&pdev->dev,
> + asus_ec_notifier_chain_unregister,
> + priv);
[Severity: High]
Since managed resources (devm) are released in LIFO order, will the serio
ports registered below be unregistered and freed before this notifier is
unregistered?
If an interrupt arrives during the unbind window or if the probe function
fails after port registration, could the notifier loop in asus_ec_kbc_notify()
dereference the freed serio port pointers?
> + if (error)
> + return error;
> +
> + error = asus_ec_register_serio(pdev, 0, "Keyboard", 0);
> + if (error)
> + return error;
> +
> + error = asus_ec_register_serio(pdev, 1, "Touchpad", I8042_CMD_AUX_SEND);
> + if (error)
> + return error;
> +
> + priv->nb.notifier_call = asus_ec_kbc_notify;
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v9 2/7] mfd: Add driver for ASUS Transformer embedded controller
From: sashiko-bot @ 2026-06-25 8:26 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, lee, linux-input, devicetree, robh, linux-leds,
dmitry.torokhov
In-Reply-To: <20260625081529.22447-3-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Support Nuvoton NPCE795-based ECs as used in Asus Transformer TF201,
> TF300T, TF300TG, TF300TL and TF700T pad and dock, as well as TF101 dock
> and TF600T, P1801-T and TF701T pad. This is a glue driver handling
> detection and common operations for EC's functions.
>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v9 4/7] input: keyboard: Add driver for ASUS Transformer dock multimedia keys
From: sashiko-bot @ 2026-06-25 8:25 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, linux-input, dmitry.torokhov, lee, devicetree, conor+dt,
linux-leds
In-Reply-To: <20260625081529.22447-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Explicitly calling `input_unregister_device()` on a device allocated with `devm_input_allocate_device()`.
--
commit b1b4cf8c044b790c2019bf0bb44a52ad2de52358
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
input: keyboard: Add driver for ASUS Transformer dock multimedia keys
This patch adds support for the multimedia top button row of the ASUS
Transformer's Mobile Dock keyboard. It tracks keyboard input events for
AltGr presses to switch to multimedia keys.
> diff --git a/drivers/input/keyboard/asus-transformer-ec-keys.c b/drivers/input/keyboard/asus-transformer-ec-keys.c
> new file mode 100644
> index 0000000000000..53aff3ce7146d
> --- /dev/null
> +++ b/drivers/input/keyboard/asus-transformer-ec-keys.c
[ ... ]
> +static int asus_ec_keys_probe(struct platform_device *pdev)
> +{
> + struct i2c_client *parent = to_i2c_client(pdev->dev.parent);
> + struct asusec_core *ec = dev_get_drvdata(pdev->dev.parent);
> + struct device *dev = &pdev->dev;
> + struct asus_ec_keys_data *priv;
> + int error;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> + priv->ec = ec;
> +
> + priv->xidev = devm_input_allocate_device(dev);
[ ... ]
> + error = input_register_device(priv->xidev);
> + if (error)
> + return dev_err_probe(dev, error,
> + "failed to register extension keys\n");
> +
> + error = asus_ec_keys_register_handler(dev, priv);
> + if (error) {
> + input_unregister_device(priv->xidev);
[Severity: Medium]
Since priv->xidev is allocated with devm_input_allocate_device() earlier in
asus_ec_keys_probe(), does explicitly calling input_unregister_device()
here in the error path lead to a double-unregistration when the managed API
automatic cleanup triggers?
> + return error;
> + }
> +
> + priv->nb.notifier_call = asus_ec_keys_notify;
> +
> + error = blocking_notifier_chain_register(&ec->notify_list, &priv->nb);
> + if (error) {
> + input_unregister_device(priv->xidev);
[Severity: Medium]
Could manually unregistering the devm-managed input device here in the
notifier registration error path similarly cause a double-unregistration?
> + input_unregister_handler(&priv->input_handler);
> + return error;
> + }
> +
> + return 0;
> +}
> +
> +static void asus_ec_keys_remove(struct platform_device *pdev)
> +{
> + struct asus_ec_keys_data *priv = platform_get_drvdata(pdev);
> + struct asusec_core *ec = priv->ec;
> +
> + blocking_notifier_chain_unregister(&ec->notify_list, &priv->nb);
> + input_unregister_handler(&priv->input_handler);
> + input_unregister_device(priv->xidev);
[Severity: Medium]
Does bypassing the automatic devm lifecycle by explicitly calling
input_unregister_device() in asus_ec_keys_remove() on a managed device lead
to double-unregistration when the device is unbound?
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Konrad Dybcio @ 2026-06-25 8:25 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <82253653-bd85-45b8-8520-e2bb213ca48f@oss.qualcomm.com>
On 6/17/26 12:12 PM, Fenglin Wu wrote:
>
> On 6/17/2026 5:30 PM, Konrad Dybcio wrote:
>> On 6/17/26 4:31 AM, Fenglin Wu wrote:
>>>>> + ret = ptn_bulk_write(h, HAP_PTN_FIFO_DIN_0_REG, &data[i], 4);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + }
>>>>> +
>>>>> + for (; i < len; i++) {
>>>>> + ret = ptn_write(h, HAP_PTN_FIFO_DIN_1B_REG, (u8)data[i]);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + }
>>>> So if i'm reading this right, the first loop will always write
>>>> 4*(len//4) bytes and the second one will be entered at most once,
>>>> to write len rem 4 bytes.. should this be an if instead?
>>> I should put a comment for clarification. Here’s some background: FIFO data writing supports both 4-byte bulk writes using registers [HAP_PTN_FIFO_DIN_0_REG ... HAP_PTN_FIFO_DIN_3_REG], and 1-byte writes using the HAP_PTN_FIFO_DIN_1B_REG register. The 4-byte bulk write is more efficient, especially for waveform which has several Kb data, and it helps to reduce software latency when loading effects and reduce the delay in triggering vibration. It also helps prevent the FIFO from running dry during data refill in FIFO-empty interrupts. Typically, we use 4-byte writes for the initial 4-byte aligned data, and 1-byte writes for any trailing remainder.
>>>
>>> So it still needs a 'for' loop here since the remainder could be more than 1 byte.
>> Right, I mentioned len rem 4 but failed to notice it's a
>> single-byte write.. anyway, a comment here would be good
>>
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> + * Configure the hardware FIFO memory boundary.
>>>>> + * FIFO occupies addresses [0, fifo_len).
>>>>> + */
>>>>> +static int haptics_configure_fifo_mmap(struct qcom_haptics *h)
>>>>> +{
>>>>> + u32 fifo_len, fifo_units;
>>>>> +
>>>>> + /* Config all memory space for FIFO usage for now */
>>>> What's the not-"for now" endgame for this?
>>> The hardware supports more modes than the two currently supported in the driver. One of these, called 'PAT_MEM' mode, also shares memory space with FIFO mode. However, 'PAT_MEM' requires memory to be pre-reserved and waveform data to be pre-loaded. The entire 8K bytes of memory can be divided into partitions, and it is configurable, with FIFO mode always using the first partition [0, fifo_len], where 'fifo_len' is set via the 'MMAP_FIFO_REG' register. 'PAT_MEM' mode plays waveform using data preloaded in a memory bank defined by the registers 'PATX_MEM_START_ADDR_REG' and 'PATTERN_SPMI_PATX_LEN_REG' (they are not defined in the driver). Since PAT_MEM is mainly intended for hardware-triggered vibrations, such as a signal from a dedicated GPIO triggering a short vibration with a preloaded waveform, and although it also supports software triggers, I haven't found a suitable way to support it well into the driver under input FF framework yet. So, I am currently allocating the
>>> entire 8K FIFO memory for FIFO mode only. We can adjust this later if we find a better way to incorporate 'PAT_MEM' mode into the driver.
>> Sounds like a plan.
>>
>> For the other mode, would that GPIO trigger need any OS intervention?
>> Could you speak a bit more about how that works?
>>
>> Konrad
>
> I'll try to clarify the 'PAT_MEM' mode further. 'PAT_MEM' is useful for latency-sensitive vibrations because it preloads the waveform into a fixed memory bank, then it doesn't need to load the data of the effect in the HW before triggering the play. When playback is triggered, it plays the waveform from the specified memory address and length. This memory should be preserved, and the data is preloaded during boot. Unlike FIFO mode, it doesn't allow data refilling. The trigger can come from hardware via dedicated GPIOs—currently, three are supported, each mapping to a memory bank set through specific registers. Software configuration can be done in the bootloader or in the driver probe, but the 'fifo_len' should be adjusted accordingly. After setup, software doesn't need to manage it further, relying on the GPIO signal to activate the playback (for example, a pressure sensor triggering vibration to simulate a physical key press). The trigger can also come from software using
> SPMI commands by setting the play mode, start address, and data length. I previously tried using the 'FF_HAPTIC' effect by mapping 'hid_usage' to a predefined effect in the devicetree, but later I found it unsuitable since 'FF_HAPTIC' is mainly for USB HID touch devices and not general vibration usage. If you have any suggestions for supporting 'PAT_MEM' mode through the input FF framework, please let me know.
I don't really know much about this part of the kernel, but at a glance
FF_HAPTIC seems to be roughly what we're after - quoting the cover letter
of the series that introduced it:
<quote>
Haptic control
..............
The HID protocol described in HUTRR63[3] must be used.
The following waveforms should be supported:
| WAVEFORMNONE | Implicit waveforms required by protocol |
| WAVEFORMSTOP | |
| ------------------------ | ------------------------------------------------- |
| WAVEFORMPRESS | To be used to simulate button press. In device- |
| | controlled mode, it will also be used to simulate |
| | button release. |
| ------------------------ | ------------------------------------------------- |
| WAVEFORMRELEASE | To be used to simulate button release. |
All waveforms will have an associated duration; continuous waveforms will be
ignored by the kernel.
</quote>
(i.e. reword 'press' to 'trigger' and we're mostly there?)
I'd start prototyping in that area (maybe taking it out of drivers/hid/)
and see where it goes. However as I mentioned, this may as well be my
wishful thinking.
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Krzysztof Kozlowski @ 2026-06-25 8:25 UTC (permalink / raw)
To: Dmitry Torokhov, David Heidelberg
Cc: Krzysztof Kozlowski, Konrad Dybcio, Rob Herring, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel
In-Reply-To: <f81e4d83-90d9-47c8-aee9-319df3f8b0fb@kernel.org>
On 25/06/2026 10:23, Krzysztof Kozlowski wrote:
> On 25/06/2026 06:53, Dmitry Torokhov wrote:
>> On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
>>> On 24/06/2026 06:28, Dmitry Torokhov wrote:
>>>> Hi David,
>>>>
>>>> On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
>>>>> On 28/05/2026 00:13, David Heidelberg wrote:
>>>>>> On 27/05/2026 23:56, Dmitry Torokhov wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
>>>>>>>> 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";
>>>>>>>
>>>>>>> So I believe we established that this device (s3706b) does not in fact
>>>>>>> implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
>>>>>>> fallback? Shouldn't it be just "syna,rmi4-s3706b"?
>>>>>>
>>>>>> The vendor supplies s3706b which does implement the RMI4 properly.
>>>>>>
>>>>>> The 3rd party replacement impersonating original parts may not implement
>>>>>> it properly, but I don't address this issue in this initial submission.
>>>>>>
>>>>>> With this compatible we know which original part is used by the vendor
>>>>>> and installed in the phones, so later we can deduct specific sequences
>>>>>> for the replacement aftermarket parts to keep phone touchscreen working
>>>>>> same as they do on Android without affecting other devices.
>>>>>
>>>>> Hello Dmitry.
>>>>>
>>>>> May I ask what is currently preventing this series from moving forward?
>>>>>
>>>>> The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
>>>>> and am now on the 9th iteration (this patchset). At this point, the series
>>>>> has been under discussion for well over a year, with relatively little
>>>>> feedback and increasingly long gaps between review rounds.
>>>>>
>>>>> The current approach is based on the guidance I have received so far,
>>>>> including suggestions from the device-tree maintainers. When concerns were
>>>>> raised, I tried to address them and rework the series accordingly.
>>>>>
>>>>> What I am struggling with is understanding what specific issue still needs
>>>>> to be resolved before these patches can be accepted. If there are remaining
>>>>> requirements, objections to the approach, or technical concerns that I have
>>>>> not addressed, I would appreciate having them stated explicitly so I can
>>>>> work on them.
>>>>>
>>>>> I also split out the straightforward, self-contained changes in the hope
>>>>> that at least those could progress independently while I continued working
>>>>> on any follow-up requirements. However, even those patches do not appear to
>>>>> be moving forward.
>>>>>
>>>>> Could you please clarify what outcome you would like to see from this
>>>>> series, and what concrete changes would be required to get it accepted?
>>>>
>>>> I am still confused about how you want to differentiate between the full
>>>> RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
>>>> mentioned, implements RMI4 protocol properly, so we do not need to
>>>> actually have it documented neither in binding nor in DTS.
>>>
>>> --- part 1 ---
>>>
>>> This series addresses identification within device-tree. It's normal
>>> recommended practice.
>>>
>>> If we know, the device ships specific, but **compliant** variant, we just
>>> put it as compatible = "more-specific", "less-specific"; in this case
>>> "syna,rmi4-s3706b", "syna,rmi4-i2c"
>>>
>>> This approach is used everywhere. This has nothing to do with after-market parts.
>>
>> We do this in many cases, sometimes when a part has different timings or
>> maybe additional functionality compared to the base model.
>
> Generic expectation is to have always dedicated front compatible for
> every device. rmi4-i2c is not really specific enough, more like a
> family, thus a specific device compatible is essential by the DT rules.
>
> It does not matter if that specific compatible is ever used.
>
>>
>> How does this new compatible for controller that fully implements RMI4
>> protocol help here?
>
> It does not matter. This is a different device, thus it needs
> front-specific compatible.
>
> Also, the commit msg actually did mention how this helps: allowing
> further quirks (I did not verify that in practice, but explanation is
> plausible).
>
>>
>>>
>>> --- part 2 (irrelevant for this series) ---
>>>
>>>>
>>>> The issue you have with after-market parts that are not compliant and we
>>>> need to figure out how to deal with them. Inside the driver I
>>>
>>> As was suggested by device-tree folks, this is the first step, there isn't
>>> better one available. If there is, please suggest one, and I'll apply it.
>>
>> Was it clearly communicated to DT folks that the compatible you are
>> adding is fully compatible with the base "syna,rmi4-i2c" but other ones
>> will not be compatible?
>
> That was not communicated but also did not have to. You can install in
> your board whatever you wish, e.g. replacing foo device with bar being
> something completely different and incompatible. Does not matter really
> if this is after-market or a person just swapped things.
>
> DT does not solve that problem simply, because we describe static
> hardware configuration.
>
>>
>>>
>>>> essentially need a"incomplete protocol" flag that we can use to
>>>> implement additional checks or skip known to be not implemented
>>>> functions/queries. In DT we could introduce something like
>>>> "oneplus,rmi4-i2c" that is decidedly not compatible with "syna,rmi4-i2c"
>>>> and neither one should be a fallback for the other.
>>>>
>>>> This of course needs buy-in from DT maintainers.
>>>
>>> As you can see, this still holds Acked-by and Reviewed-by from the relevant
>>> people - Krzysztof and Konrad.
>>
>> I see that but the commit does not explain how exactly you are planning
>> to deal with knockoffs.
>
> I think it does not have to. David does not need to solve all possible
> problems. He is solving his problems and not preventing the other
> problems to be solved in the future. Unless you expect that the second
> part - future problems - will be blocked by this code.
>
> But then I think no one ever solved in DT a problem of replacement of
> valid parts with after-market incompatible parts. Therefore I do not
> even know what solution I could suggest to David.
... maybe except DT overlays. This DTS would be correct and if anyone
installs replacement part which is not compatible, then just use overlay
changing the compatible. The idea of manually (per-user) altering
hardware is matching the concept behind DT overlays.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/6 RESEND] dt-bindings: leds: leds-cpcap: convert to DT schema
From: sashiko-bot @ 2026-06-25 8:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: devicetree, robh, linux-input, dmitry.torokhov, lee, conor+dt,
linux-leds
In-Reply-To: <20260625081812.33474-2-clamor95@gmail.com>
> Convert LEDs devicetree bindings for the Motorola CPCAP MFD from TXT to
> YAML format. This patch does not change any functionality; the bindings
> remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Krzysztof Kozlowski @ 2026-06-25 8:23 UTC (permalink / raw)
To: Dmitry Torokhov, David Heidelberg
Cc: Krzysztof Kozlowski, Konrad Dybcio, Rob Herring, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel
In-Reply-To: <ajxakXFuKAkhdZLN@google.com>
On 25/06/2026 06:53, Dmitry Torokhov wrote:
> On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
>> On 24/06/2026 06:28, Dmitry Torokhov wrote:
>>> Hi David,
>>>
>>> On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
>>>> On 28/05/2026 00:13, David Heidelberg wrote:
>>>>> On 27/05/2026 23:56, Dmitry Torokhov wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
>>>>>>> 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";
>>>>>>
>>>>>> So I believe we established that this device (s3706b) does not in fact
>>>>>> implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
>>>>>> fallback? Shouldn't it be just "syna,rmi4-s3706b"?
>>>>>
>>>>> The vendor supplies s3706b which does implement the RMI4 properly.
>>>>>
>>>>> The 3rd party replacement impersonating original parts may not implement
>>>>> it properly, but I don't address this issue in this initial submission.
>>>>>
>>>>> With this compatible we know which original part is used by the vendor
>>>>> and installed in the phones, so later we can deduct specific sequences
>>>>> for the replacement aftermarket parts to keep phone touchscreen working
>>>>> same as they do on Android without affecting other devices.
>>>>
>>>> Hello Dmitry.
>>>>
>>>> May I ask what is currently preventing this series from moving forward?
>>>>
>>>> The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
>>>> and am now on the 9th iteration (this patchset). At this point, the series
>>>> has been under discussion for well over a year, with relatively little
>>>> feedback and increasingly long gaps between review rounds.
>>>>
>>>> The current approach is based on the guidance I have received so far,
>>>> including suggestions from the device-tree maintainers. When concerns were
>>>> raised, I tried to address them and rework the series accordingly.
>>>>
>>>> What I am struggling with is understanding what specific issue still needs
>>>> to be resolved before these patches can be accepted. If there are remaining
>>>> requirements, objections to the approach, or technical concerns that I have
>>>> not addressed, I would appreciate having them stated explicitly so I can
>>>> work on them.
>>>>
>>>> I also split out the straightforward, self-contained changes in the hope
>>>> that at least those could progress independently while I continued working
>>>> on any follow-up requirements. However, even those patches do not appear to
>>>> be moving forward.
>>>>
>>>> Could you please clarify what outcome you would like to see from this
>>>> series, and what concrete changes would be required to get it accepted?
>>>
>>> I am still confused about how you want to differentiate between the full
>>> RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
>>> mentioned, implements RMI4 protocol properly, so we do not need to
>>> actually have it documented neither in binding nor in DTS.
>>
>> --- part 1 ---
>>
>> This series addresses identification within device-tree. It's normal
>> recommended practice.
>>
>> If we know, the device ships specific, but **compliant** variant, we just
>> put it as compatible = "more-specific", "less-specific"; in this case
>> "syna,rmi4-s3706b", "syna,rmi4-i2c"
>>
>> This approach is used everywhere. This has nothing to do with after-market parts.
>
> We do this in many cases, sometimes when a part has different timings or
> maybe additional functionality compared to the base model.
Generic expectation is to have always dedicated front compatible for
every device. rmi4-i2c is not really specific enough, more like a
family, thus a specific device compatible is essential by the DT rules.
It does not matter if that specific compatible is ever used.
>
> How does this new compatible for controller that fully implements RMI4
> protocol help here?
It does not matter. This is a different device, thus it needs
front-specific compatible.
Also, the commit msg actually did mention how this helps: allowing
further quirks (I did not verify that in practice, but explanation is
plausible).
>
>>
>> --- part 2 (irrelevant for this series) ---
>>
>>>
>>> The issue you have with after-market parts that are not compliant and we
>>> need to figure out how to deal with them. Inside the driver I
>>
>> As was suggested by device-tree folks, this is the first step, there isn't
>> better one available. If there is, please suggest one, and I'll apply it.
>
> Was it clearly communicated to DT folks that the compatible you are
> adding is fully compatible with the base "syna,rmi4-i2c" but other ones
> will not be compatible?
That was not communicated but also did not have to. You can install in
your board whatever you wish, e.g. replacing foo device with bar being
something completely different and incompatible. Does not matter really
if this is after-market or a person just swapped things.
DT does not solve that problem simply, because we describe static
hardware configuration.
>
>>
>>> essentially need a"incomplete protocol" flag that we can use to
>>> implement additional checks or skip known to be not implemented
>>> functions/queries. In DT we could introduce something like
>>> "oneplus,rmi4-i2c" that is decidedly not compatible with "syna,rmi4-i2c"
>>> and neither one should be a fallback for the other.
>>>
>>> This of course needs buy-in from DT maintainers.
>>
>> As you can see, this still holds Acked-by and Reviewed-by from the relevant
>> people - Krzysztof and Konrad.
>
> I see that but the commit does not explain how exactly you are planning
> to deal with knockoffs.
I think it does not have to. David does not need to solve all possible
problems. He is solving his problems and not preventing the other
problems to be solved in the future. Unless you expect that the second
part - future problems - will be blocked by this code.
But then I think no one ever solved in DT a problem of replacement of
valid parts with after-market incompatible parts. Therefore I do not
even know what solution I could suggest to David.
>
>>
>>>
>>> Does this make sense?
>>
>> For the scope we're discussing it doesn't seems so.
>>
>> This discussion should be associated with the last revision of the full
>> series I sent 3 months ago. We're in very unflattering state, where:
>>
>> 2018 - these aftermarket touchscreen worked on Android well enough for
>> people to have working touch (let's say with slightly worse experience then
>> the original).
>>
>> 2026 in the mainline, we cannot even more forward and report to user-space
>> there is aftermarket non-compliant piece of hardware installed.
>>
>> Actionable steps I suggest after this series lands:
>>
>> 1. don't do any changes, but since we know what 3rd party touchscreen do
>> incorrectly deviating from the standard, REPORT it to the userspace, so USER
>> know, their device (phone/tablet) doesn't have original part.
>>
>> 2. then figure out, IF we can reasonably well workaround it and HOW to do it
>>
>> These two steps present some progress which could be discussed and could
>> lead us somewhere, what do you think?
>
> So since we know that these devices can come with controllers that do
> not implement RMI4 fully, can we:
>
> 1. Establish a new compatible that is separate from syna,rmi4-i2c? As I
> mentioned, it could be oneplus,rmi4-i2c or event a concrete controller
> vendor,id combo. The point that it should be completely separate from
> the current compatible and not use the current compatible as a fallback.
Board/machine level compatible already gives you that.
after-market-incompatible-parts is not a problem of this s3706b, if I
understood correctly. It feels to me more of a problem of the board:
people install into this board some incompatible replacement parts.
I would understand that this is not a board/machine level problem, if
multiple different boards with s3706b were affected. Is this the case?
>
> 2. Make modifications to RMI4 implementation to handle these controllers
> in a reasonable manner, but not mess up the full RMI4 support
>
> 3. Update DTS for the affected headsets to switch them to this new
> implementation.2. Make modifications to RMI4 implementation to handle
> these controllers in a reasonable manner, but not mess up the full RMI4
> support
>
> 3. Update DTS for the affected headsets to switch them to this new
> implementation.
>
> Thanks.
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 6/6 RESEND] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: sashiko-bot @ 2026-06-25 8:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, linux-leds, dmitry.torokhov, conor+dt, linux-input,
devicetree, lee
In-Reply-To: <20260625081812.33474-7-clamor95@gmail.com>
> Add a MFD subdevice composition used in Tegra20 based Mot board
> (Motorola Atrix 4G and Droid X2).
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v6 2/6 RESEND] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
From: sashiko-bot @ 2026-06-25 8:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, devicetree, linux-leds, linux-input, robh, lee,
dmitry.torokhov
In-Reply-To: <20260625081812.33474-3-clamor95@gmail.com>
> Convert power button devicetree bindings for the Motorola CPCAP MFD from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v9 7/7] power: supply: Add charger driver for Asus Transformers
From: sashiko-bot @ 2026-06-25 8:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, dmitry.torokhov, robh, lee, linux-leds, conor+dt,
devicetree
In-Reply-To: <20260625081529.22447-8-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Add support for charger detection capabilities found in the embedded
> controller of ASUS Transformer devices.
>
> Suggested-by: Maxim Schwalm <maxim.schwalm@gmail.com>
> Suggested-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH v9 5/7] leds: Add driver for ASUS Transformer LEDs
From: sashiko-bot @ 2026-06-25 8:22 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, linux-input, dmitry.torokhov, robh, devicetree,
linux-leds, lee
In-Reply-To: <20260625081529.22447-6-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> ASUS Transformer tablets have a green and an amber LED on both the Pad
> and the Dock. If both LEDs are enabled simultaneously, the emitted light
> will be yellow.
>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v9 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: sashiko-bot @ 2026-06-25 8:21 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-leds, linux-input, lee, conor+dt, robh, devicetree,
dmitry.torokhov
In-Reply-To: <20260625081529.22447-2-clamor95@gmail.com>
> Document embedded controller used in ASUS Transformer device series.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-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