On 25/06/2026 18:57, Dmitry Torokhov wrote: > Hi Krzysztof, > > On Thu, Jun 25, 2026 at 10:23:54AM +0200, 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 <[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? >>>>> >>>>> 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. > > Essential in what way? What will break if such compatible is not there?
Essential by the rules we defined for DT and documented in writing-bindings. > We have lived without it for many years and will continue live happily > without it for years to come. Does not matter if compatible is used or not. The rules are dictating that. Best regards, Krzysztof
