[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <96c08475-72e7-9ef4-2f16-e962f9338e78@rocketmail.com>
Date: Sun, 3 Sep 2023 14:43:56 +0200
From: Jakob Hauser <jahau@...ketmail.com>
To: Sebastian Reichel <sre@...nel.org>
Cc: Lee Jones <lee@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Beomho Seo <beomho.seo@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Stephan Gerhold <stephan@...hold.net>,
Raymond Hackley <raymondhackley@...tonmail.com>,
Pavel Machek <pavel@....cz>, Axel Lin <axel.lin@...ics.com>,
ChiYuan Huang <cy_huang@...htek.com>,
Linus Walleij <linus.walleij@...aro.org>,
Henrik Grimler <henrik@...mler.se>,
Christophe Jaillet <christophe.jaillet@...adoo.fr>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Randy Dunlap <rdunlap@...radead.org>,
Yang Yingliang <yangyingliang@...wei.com>,
linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, phone-devel@...r.kernel.org,
~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: (subset) [PATCH v6 06/10 RESEND] power: supply: rt5033_charger:
Add cable detection and USB OTG supply
Hi Sebastian,
On 22.08.23 23:29, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Aug 22, 2023 at 08:07:37AM +0100, Lee Jones wrote:
>> On Thu, 17 Aug 2023, Lee Jones wrote:
>>
>>> On Mon, 15 May 2023 22:57:15 +0200, Jakob Hauser wrote:
>>>> Implement cable detection by extcon and handle the driver according to the
>>>> connector type.
>>>>
>>>> There are basically three types of action: "set_charging", "set_otg" and
>>>> "set_disconnect".
>>>>
>>>> A forth helper function to "unset_otg" was added because this is used in both
>>>> "set_charging" and "set_disconnect". In the first case it covers the rather
>>>> rare event that someone changes from OTG to charging without disconnect. In
>>>> the second case, when disconnecting, the values are set back to the ones from
>>>> initialization to return into a defined state.
>>>>
>>>> [...]
>>>
>>> Applied, thanks!
>>>
>>> [06/10] power: supply: rt5033_charger: Add cable detection and USB OTG supply
>>> commit: c1af6bcc8583b0a1083338cd26c2090d0bcb0810
>>
>> Multiple fixes now follow this patch, so I am unapplying it.
>>
>> Sebastian, would you mind collecting it up please?
>
> I'm leaving for a two week hiking trip (with basically no internet
> access) in some hours. My planed return date is basically when Linus
> is expected to tag 6.6-rc1, so I will not queue any more patches and
> send my pull request early (within the next few hours).
>
> I planned to catch up with the power-supply backlog last week during
> Chaos Communication Camp, but it was too hot to do any sensible
> review. Now I expect to process the power-supply backlog in the
> week after the merge window.
The patch 6 of the rt5033-charger series v6 gathered some issues. For
all of them a solution was provided. Thanks to everyone involved!
However, I don't know what's the best way to put them together.
- As the patch 6 was forgotten to apply with the others of the
patchset, in the meantime another small patch by Rob sneaked in. The
patch 6 needs to be rebased on Rob's patch. It affects the includes.
Would be nice to order them alphabetically after rebase.
- After patch 6 was added on top of Rob's patch in linux-next, there
was a build failure. This is because "linux/of.h" now explicitly
needs to be added to the rt5033-charger driver. Stephen Rothwell
provided a fix. I'm not sure on the order: Maybe that needs to be
added before adding patch 6 to avoid the build failure when the
kernel test bot checks each commit separately.
https://lore.kernel.org/linux-next/20230821125741.3a2474d7@canb.auug.org.au/T/#u
- Beyond that, the kernel test bot also complained about undefined
reference related to extcon. I didn't understand why this happens
because the driver has "linux/extcon.h" included. Randy was attentive
and provided a fix. Here again I'm not sure about the order, I guess
this should be added before adding patch 6 to avoid build failures if
each commit is tested separately.
Kernel test bot complaints:
x86_64 clang
https://lore.kernel.org/oe-kbuild-all/202308220324.LsI8q3ML-lkp@intel.com/T/#u
x86_64 gcc
https://lore.kernel.org/oe-kbuild-all/202308240723.O2rW0InU-lkp@intel.com/T/#u
arm gcc
https://lore.kernel.org/oe-kbuild-all/202308250617.ue4uQxWa-lkp@intel.com/T/#u
Fix by Randy:
https://lore.kernel.org/linux-pm/20230828224201.26823-1-rdunlap@infradead.org/T/#u
- Yang noticed that the mutex_unlock() is not handled correctly in
some error path and provided a fix:
https://lore.kernel.org/linux-pm/20230822030207.644738-1-yangyingliang@huawei.com/T/#u
- There are two clean-up patches by me. They need to be rebased to the
patches mentioned above but there shouldn't be conflicts with them.
https://lore.kernel.org/linux-pm/cover.1686948074.git.jahau@rocketmail.com/T/#u
Please also note that the commit hash in the linked fixes above refers
to linux-next, where the patch 6 had been applied. As the patch was
dropped later on, I don't know what this means for the commit hashes in
the fixes.
What's the best way to proceed? Can you put these patches together? Or
do you want me something to do?
Kind regards,
Jakob
Powered by blists - more mailing lists