[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <956d0ddc-21c6-1074-42fd-67e6d72fb166@theobroma-systems.com>
Date: Tue, 28 Feb 2023 18:36:03 +0100
From: Quentin Schulz <quentin.schulz@...obroma-systems.com>
To: Bjorn Andersson <andersson@...nel.org>, samuel@...lland.org,
agx@...xcpu.org, megous@...ous.com, heiko@...ech.de,
hdegoede@...hat.com, robh+dt@...nel.org, wens@...e.org,
michael.riesch@...fvision.net, lukma@...x.de, icenowy@...c.io,
kernel@...gutronix.de, david@...tonic.nl, shawnguo@...nel.org,
foss+kernel@...il.net, linux-imx@....com, festevam@...il.com,
pgwipeout@...il.com, jagan@...rulasolutions.com, agross@...nel.org,
hadess@...ess.net, dmitry.torokhov@...il.com,
jernej.skrabec@...il.com, angelogioacchino.delregno@...ainline.org,
mamlinav@...il.com, frieder.schrempf@...tron.de, angus@...ea.ca,
Sascha Hauer <s.hauer@...gutronix.de>,
konrad.dybcio@...ainline.org, krzysztof.kozlowski+dt@...aro.org
Cc: linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-input@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-sunxi@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
linux-rockchip@...ts.infradead.org
Subject: Re: (subset) [PATCH v3 0/9] fix reset line polarity for Goodix
touchscreen controllers
Hi all,
On 1/16/23 13:37, Quentin Schulz wrote:
> Hi Bjorn, all,
>
> On 1/10/23 17:17, Bjorn Andersson wrote:
>> On Mon, 5 Dec 2022 14:40:29 +0100, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz@...obroma-systems.com>
>>>
>>> The Goodix touchscreen controller has a reset line active low. It
>>> happens to
>>> also be used to configure its i2c address at runtime. If the reset
>>> line is
>>> incorrectly asserted, the address will be wrongly configured. This
>>> cost me a few
>>> hours, trying to figure out why the touchscreen wouldn't work.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [8/9] arm64: dts: qcom: msm8998-fxtec: fix touchscreen reset GPIO
>> polarity
>> commit: 8a0721dae68fdb4534e220fc9faae7a0ef2f3785
>>
>
> Thank you for the merge, however I think there could be some issue here.
>
> This requires the patches 1, 2 and 3 all modifying the input driver in
> order to not introduce a regression.
>
> I mistakenly removed the RFC tag and seemingly didn't make it clear
> enough that I had some question on how to properly merge this patch
> series, c.f. "Do we also make this patch series only one patchset since
> the DT patches depend
> on the driver patch and vice-versa? In which tree would this go?" in the
> cover letter.
>
> So please, how do we go on with the rest of the patch series? Should I
> submit a v4 which would be only one patch with DT and input changes all
> at once and Bjorn reverts the patch they had just merged?
>
> @Dmitry, since you would have to merge at least patches 1 to 3 in your
> tree (I assume), would you be willing to take the DT patches at the same
> time through your tree too? Are the appropriate device DT maintainers OK
> with this?
>
Ping.
Cheers,
Quentin
Powered by blists - more mailing lists