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 <[email protected]>
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 <[email protected]>
Signed-off-by: David Heidelberg <[email protected]>
---
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?
Thank you,
David
[1]
https://lore.kernel.org/all/[email protected]/
[2]
https://lore.kernel.org/all/[email protected]/
David
Thanks.
--
David Heidelberg
