2023-09-04 20:26:39

by Lee Jones

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

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/[email protected]/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/[email protected]/T/#u
> x86_64 gcc https://lore.kernel.org/oe-kbuild-all/[email protected]/T/#u
> arm gcc https://lore.kernel.org/oe-kbuild-all/[email protected]/T/#u
> Fix by Randy:
>
> https://lore.kernel.org/linux-pm/[email protected]/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/[email protected]/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/[email protected]/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 [李琼斯]