| Message ID | 20200223131638.12130-2-andreas@kemnade.info (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mfd: rn5t618: add ADC support | expand |
On Sun, 23 Feb 2020, Andreas Kemnade wrote: > This adds a subdevice for the ADC in the RC5T619 > > Signed-off-by: Andreas Kemnade <andreas@kemnade.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? > drivers/mfd/rn5t618.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c > index 073de8e0e78b..321836f78120 100644 > --- a/drivers/mfd/rn5t618.c > +++ b/drivers/mfd/rn5t618.c > @@ -24,6 +24,7 @@ static const struct mfd_cell rn5t618_cells[] = { > }; > > static const struct mfd_cell rc5t619_cells[] = { > + { .name = "rn5t618-adc" }, > { .name = "rn5t618-regulator" }, > { .name = "rc5t619-rtc" }, In what upstream tree is this line present? > { .name = "rn5t618-wdt" },
On Wed, 26 Feb 2020 15:40:55 +0000 Lee Jones <lee.jones@linaro.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@kemnade.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. Do you want me to resend all that pending stuff together in one series? I have little experience with this multi-subdevice process. Regards, Andreas
On Wed, 26 Feb 2020, Andreas Kemnade wrote: > On Wed, 26 Feb 2020 15:40:55 +0000 > Lee Jones <lee.jones@linaro.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@kemnade.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. 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.
On Wed, 26 Feb 2020 17:46:40 +0000 Lee Jones <lee.jones@linaro.org> wrote: > On Wed, 26 Feb 2020, Andreas Kemnade wrote: > > > On Wed, 26 Feb 2020 15:40:55 +0000 > > Lee Jones <lee.jones@linaro.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@kemnade.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. > 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. Regards, Andreas
On Wed, 26 Feb 2020, Andreas Kemnade wrote: > On Wed, 26 Feb 2020 17:46:40 +0000 > Lee Jones <lee.jones@linaro.org> wrote: > > > On Wed, 26 Feb 2020, Andreas Kemnade wrote: > > > > > On Wed, 26 Feb 2020 15:40:55 +0000 > > > Lee Jones <lee.jones@linaro.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@kemnade.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.
On Thu, 27 Feb 2020 09:40:06 +0000 Lee Jones <lee.jones@linaro.org> wrote: > On Wed, 26 Feb 2020, Andreas Kemnade wrote: > > > On Wed, 26 Feb 2020 17:46:40 +0000 > > Lee Jones <lee.jones@linaro.org> wrote: > > > > > On Wed, 26 Feb 2020, Andreas Kemnade wrote: > > > > > > > On Wed, 26 Feb 2020 15:40:55 +0000 > > > > Lee Jones <lee.jones@linaro.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@kemnade.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. > I will send you a complete series containing both RTC and ADC support. Then you can decide wether you 1. apply the whole series (both things) 2. apply RTC for 5.7 and this series later 3. ignore them (not my preferred choice ;-) ). BTW: The way I did was based on the following note in Documentation/process/submitting-patches.rst "If one patch depends on another patch in order for a change to be complete, that is OK. Simply note **"this patch depends on patch X"** in your patch description." Regards, Andreas
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c index 073de8e0e78b..321836f78120 100644 --- a/drivers/mfd/rn5t618.c +++ b/drivers/mfd/rn5t618.c @@ -24,6 +24,7 @@ static const struct mfd_cell rn5t618_cells[] = { }; static const struct mfd_cell rc5t619_cells[] = { + { .name = "rn5t618-adc" }, { .name = "rn5t618-regulator" }, { .name = "rc5t619-rtc" }, { .name = "rn5t618-wdt" },
This adds a subdevice for the ADC in the RC5T619 Signed-off-by: Andreas Kemnade <andreas@kemnade.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?" drivers/mfd/rn5t618.c | 1 + 1 file changed, 1 insertion(+)