Re: (subset) [PATCH v6 06/10 RESEND] power: supply: rt5033_charger: Add cable detection and USB OTG supply

[Lee Jones <lee@kernel.org>]

On Sun, 03 Sep 2023, Jakob Hauser wrote:

> 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?

You need to do this yourself.

Rebase all of the fixes on top of v6.6-rc1 (which will be released in a
little under a week).  Ensure that each patch builds as it's applied so
as not to harm bisecability.  If you have to squash them to prevent
built-breakages, then so be it, but don't forget to credit the
contributors.  Once complete, post as a set and we'll take it from
there.

-- 
Lee Jones [李琼斯]