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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 26 Feb 2020, Andreas Kemnade wrote:

> On Wed, 26 Feb 2020 17:46:40 +0000
> Lee Jones <lee.jones@xxxxxxxxxx> wrote:
> 
> > On Wed, 26 Feb 2020, Andreas Kemnade wrote:
> > 
> > > On Wed, 26 Feb 2020 15:40:55 +0000
> > > Lee Jones <lee.jones@xxxxxxxxxx> 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@xxxxxxxxxxxx>
> > > > > ---
> > > > > depends on:
> > > > > https://lore.kernel.org/lkml/20191220122416.31881-1-andreas@xxxxxxxxxxxx/
> > > > > 
> > > > > 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@xxxxxxxxxxxx/
> > > 
> > > 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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux