linux-kernel - Re: [PATCH v5 1/2] mfd: rn5t618: add ADC subdevice for RC5T619

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 27 Feb 2020 09:40:06 +0000
From:   Lee Jones <lee.jones@...aro.org>
To:     Andreas Kemnade <andreas@...nade.info>
Cc:     knaack.h@....de, lars@...afoo.de, pmeerw@...erw.net,
        b.galvani@...il.com, linus.walleij@...aro.org,
        linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
        phh@....me, stefan@...er.ch, letux-kernel@...nphoenux.org,
        jic23@...nel.org
Subject: Re: [PATCH v5 1/2] mfd: rn5t618: add ADC subdevice for RC5T619

On Wed, 26 Feb 2020, Andreas Kemnade wrote:

> On Wed, 26 Feb 2020 17:46:40 +0000
> Lee Jones <lee.jones@...aro.org> wrote:
> 
> > On Wed, 26 Feb 2020, Andreas Kemnade wrote:
> > 
> > > On Wed, 26 Feb 2020 15:40:55 +0000
> > > Lee Jones <lee.jones@...aro.org> wrote:
> > >   
> > > > On Sun, 23 Feb 2020, Andreas Kemnade wrote:
> > > >   
> > > > > This adds a subdevice for the ADC in the RC5T619
> > > > > 
> > > > > Signed-off-by: Andreas Kemnade <andreas@...nade.info>
> > > > > ---
> > > > > depends on:
> > > > > https://lore.kernel.org/lkml/20191220122416.31881-1-andreas@kemnade.info/
> > > > > 
> > > > > Changes in v3:
> > > > > re-added it to the series because of
> > > > > "Oh, it looks like there was a conflict.  Could you collect any Acks
> > > > > (including mine) rebase and resend please?"    
> > > > 
> > > > Looks like there is still a conflict.  Sure, it's not a complicated
> > > > fix, but that's beside the point.  What tree is this set based on?
> > > >   
> > > It must be applied on top of my rc5t619 rtc series here:
> > > https://lore.kernel.org/lkml/20191220122416.31881-1-andreas@kemnade.info/
> > > 
> > > I expected it to make it into 5.6 and when I first sent the RTC series
> > >  (in October) I had no idea when I will continue with other stuff.
> > > 
> > > That is why I sent this ADC series separately, also to give the IIO
> > > maintainer plenty of time to review.   
> > 
> > If a patch-set can or should be applied on its own, you should send it
> > based on an upstream commit, or else things like this happen.
> > 
> It cannot without breaking bisectability. The RTC series adds IRQ support in
> the PMIC which is used here.

Then Kconfig should reflect that.

Or, if that's not possible, then you should not break-up and submit
sets which cannot be applied by themselves.  Either submit the whole
set together, or submit them piece by piece, not submitting the next
part until it's predecessor has been applied.

> > My advice would be to maintain topic branches, each based on an
> > upstream release, which you can merge together into an integration
> > branch for full coverage testing.
> > 
> > > Do you want me to resend all that pending stuff together in one series?
> > > I have little experience with this multi-subdevice process.  
> > 
> > It makes more sense to rebase this set onto the latest full release
> > and resubmit this set on its own.
> > 
> So, I resend the RC5T619 RTC series mentioned above as you answered
> upont Nikolaus question and wait with this series until review is
> through.
> Ok, so wait and rebase it onto 5.7-rc1 or 5.8-rc1 or whatever release
> the RTC stuff will appear.
> So you are not going to create an ib-mfd-rtc-iio branch.

As above.

If you go the whole-patch-set route, yes, either myself or someone
else would have to create an immutable pull-request, but you don't
have to concern yourself with that.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog