Re: (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions
On Thu, 10 Oct 2024, Karel Balej wrote: > Lee Jones, 2024-10-10T09:35:19+01:00: > > On Thu, 10 Oct 2024, Lee Jones wrote: > > > > > On Wed, 09 Oct 2024, Karel Balej wrote: > > > > > > > Lee Jones, 2024-10-09T11:06:43+01:00: > > > > > On Fri, 20 Sep 2024 18:12:34 +0200, Karel Balej wrote: > > > > > > RTC lives on the base register page of the chip. Add definitions of > > > > > > the > > > > > > registers needed for a basic set/read time functionality. > > > > > > > > > > > > > > > > > > > > > > Applied, thanks! > > > > > > > > Thank you, however I'm a little perplexed. > > > > > > > > It was my understanding that RFC patches should not be applied without > > > > further agreement, is that not the case? Obviously this patch was very > > > > simple and I used RFC mainly because of the RTC driver itself, but I'm > > > > curious to know for future submissions. > > > > > > I missed the fact that this was an RFC. I can unapply it if you like? > > > > > > > Also, I expected the entire series to go at once through the rtc tree > > > > with your ack as while it is not a strict dependency in terms of > > > > breakage, the first patch seems rather pointless without the follow-up > > > > which could theoretically take a long time to get applied and even some > > > > requested changes could require changes to this patch. Could you please > > > > explain what the policy is on this? > > > > > > The policy is flexible. However, the generally accepted rule is that if > > > there are build-time dependencies between patches, then one maintainer > > > (usually me since MFD is usually at the centre of these cross-subsystem > > > patch-sets) takes them and sends out a pull-request for an immutable > > > branch for the other maintainers to pull from. > > > > > > However in this case, there are no build-time dependencies so the > > > patches are able to and therefore should go in via their respective > > > repos. > > > > Actually, it looks like there are build-time deps between them. > > Indeed, I didn't realize that yesterday. What I had in mind before was > in fact the other part of the patch: I was wondering about the policy of > applying a patch adding a MFD cell for which there is no driver > available. That's what I meant by "not a strict dependency in terms of > breakage". I've become less strict about that over the years. The chances of the accompanying driver not going in over the next release or so is usually very small. > > Please break out the inclusion of the additional defines and place them > > into the RTC patch. I will then Ack that one. The patch making changes > > to driver/mfd will still go in via the MFD repo. > > So the above in other words: it sounds like you would apply this updated > patch independently of the RTC driver because otherwise you could just > ack the current version, is that correct? If so, I cannot see why this > would be preferable given what I wrote before about the RTC driver being > possibly delayed or eventually given up on (not that I would expect that > to be the case here :-). Could you please still comment on this then? As above. I trust you. :) -- Lee Jones [李琼斯]
Re: (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions
Lee Jones, 2024-10-10T09:35:19+01:00: > On Thu, 10 Oct 2024, Lee Jones wrote: > > > On Wed, 09 Oct 2024, Karel Balej wrote: > > > > > Lee Jones, 2024-10-09T11:06:43+01:00: > > > > On Fri, 20 Sep 2024 18:12:34 +0200, Karel Balej wrote: > > > > > RTC lives on the base register page of the chip. Add definitions of > > > > > the > > > > > registers needed for a basic set/read time functionality. > > > > > > > > > > > > > > > > > > Applied, thanks! > > > > > > Thank you, however I'm a little perplexed. > > > > > > It was my understanding that RFC patches should not be applied without > > > further agreement, is that not the case? Obviously this patch was very > > > simple and I used RFC mainly because of the RTC driver itself, but I'm > > > curious to know for future submissions. > > > > I missed the fact that this was an RFC. I can unapply it if you like? > > > > > Also, I expected the entire series to go at once through the rtc tree > > > with your ack as while it is not a strict dependency in terms of > > > breakage, the first patch seems rather pointless without the follow-up > > > which could theoretically take a long time to get applied and even some > > > requested changes could require changes to this patch. Could you please > > > explain what the policy is on this? > > > > The policy is flexible. However, the generally accepted rule is that if > > there are build-time dependencies between patches, then one maintainer > > (usually me since MFD is usually at the centre of these cross-subsystem > > patch-sets) takes them and sends out a pull-request for an immutable > > branch for the other maintainers to pull from. > > > > However in this case, there are no build-time dependencies so the > > patches are able to and therefore should go in via their respective > > repos. > > Actually, it looks like there are build-time deps between them. Indeed, I didn't realize that yesterday. What I had in mind before was in fact the other part of the patch: I was wondering about the policy of applying a patch adding a MFD cell for which there is no driver available. That's what I meant by "not a strict dependency in terms of breakage". > Please break out the inclusion of the additional defines and place them > into the RTC patch. I will then Ack that one. The patch making changes > to driver/mfd will still go in via the MFD repo. So the above in other words: it sounds like you would apply this updated patch independently of the RTC driver because otherwise you could just ack the current version, is that correct? If so, I cannot see why this would be preferable given what I wrote before about the RTC driver being possibly delayed or eventually given up on (not that I would expect that to be the case here :-). Could you please still comment on this then? Thank you, K. B.
Re: (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions
On Wed, 09 Oct 2024, Lee Jones wrote: > On Fri, 20 Sep 2024 18:12:34 +0200, Karel Balej wrote: > > RTC lives on the base register page of the chip. Add definitions of the > > registers needed for a basic set/read time functionality. > > > > > > Applied, thanks! > > [1/2] mfd: 88pm886: add the RTC cell and relevant definitions > commit: 0a936c2c45884b9a3800379f3cab4d0a685d63f5 Unapplied, thanks. -- Lee Jones [李琼斯]
Re: (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions
On Thu, 10 Oct 2024, Lee Jones wrote: > On Wed, 09 Oct 2024, Karel Balej wrote: > > > Lee Jones, 2024-10-09T11:06:43+01:00: > > > On Fri, 20 Sep 2024 18:12:34 +0200, Karel Balej wrote: > > > > RTC lives on the base register page of the chip. Add definitions of the > > > > registers needed for a basic set/read time functionality. > > > > > > > > > > > > > > Applied, thanks! > > > > Thank you, however I'm a little perplexed. > > > > It was my understanding that RFC patches should not be applied without > > further agreement, is that not the case? Obviously this patch was very > > simple and I used RFC mainly because of the RTC driver itself, but I'm > > curious to know for future submissions. > > I missed the fact that this was an RFC. I can unapply it if you like? > > > Also, I expected the entire series to go at once through the rtc tree > > with your ack as while it is not a strict dependency in terms of > > breakage, the first patch seems rather pointless without the follow-up > > which could theoretically take a long time to get applied and even some > > requested changes could require changes to this patch. Could you please > > explain what the policy is on this? > > The policy is flexible. However, the generally accepted rule is that if > there are build-time dependencies between patches, then one maintainer > (usually me since MFD is usually at the centre of these cross-subsystem > patch-sets) takes them and sends out a pull-request for an immutable > branch for the other maintainers to pull from. > > However in this case, there are no build-time dependencies so the > patches are able to and therefore should go in via their respective > repos. Actually, it looks like there are build-time deps between them. Please break out the inclusion of the additional defines and place them into the RTC patch. I will then Ack that one. The patch making changes to driver/mfd will still go in via the MFD repo. -- Lee Jones [李琼斯]
Re: (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions
On Wed, 09 Oct 2024, Karel Balej wrote: > Lee Jones, 2024-10-09T11:06:43+01:00: > > On Fri, 20 Sep 2024 18:12:34 +0200, Karel Balej wrote: > > > RTC lives on the base register page of the chip. Add definitions of the > > > registers needed for a basic set/read time functionality. > > > > > > > > > > Applied, thanks! > > Thank you, however I'm a little perplexed. > > It was my understanding that RFC patches should not be applied without > further agreement, is that not the case? Obviously this patch was very > simple and I used RFC mainly because of the RTC driver itself, but I'm > curious to know for future submissions. I missed the fact that this was an RFC. I can unapply it if you like? > Also, I expected the entire series to go at once through the rtc tree > with your ack as while it is not a strict dependency in terms of > breakage, the first patch seems rather pointless without the follow-up > which could theoretically take a long time to get applied and even some > requested changes could require changes to this patch. Could you please > explain what the policy is on this? The policy is flexible. However, the generally accepted rule is that if there are build-time dependencies between patches, then one maintainer (usually me since MFD is usually at the centre of these cross-subsystem patch-sets) takes them and sends out a pull-request for an immutable branch for the other maintainers to pull from. However in this case, there are no build-time dependencies so the patches are able to and therefore should go in via their respective repos. -- Lee Jones [李琼斯]
Re: (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions
Lee Jones, 2024-10-09T11:06:43+01:00: > On Fri, 20 Sep 2024 18:12:34 +0200, Karel Balej wrote: > > RTC lives on the base register page of the chip. Add definitions of the > > registers needed for a basic set/read time functionality. > > > > > > Applied, thanks! Thank you, however I'm a little perplexed. It was my understanding that RFC patches should not be applied without further agreement, is that not the case? Obviously this patch was very simple and I used RFC mainly because of the RTC driver itself, but I'm curious to know for future submissions. Also, I expected the entire series to go at once through the rtc tree with your ack as while it is not a strict dependency in terms of breakage, the first patch seems rather pointless without the follow-up which could theoretically take a long time to get applied and even some requested changes could require changes to this patch. Could you please explain what the policy is on this? Thank you, kind regards, K. B.
Re: (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions
On Fri, 20 Sep 2024 18:12:34 +0200, Karel Balej wrote: > RTC lives on the base register page of the chip. Add definitions of the > registers needed for a basic set/read time functionality. > > Applied, thanks! [1/2] mfd: 88pm886: add the RTC cell and relevant definitions commit: 0a936c2c45884b9a3800379f3cab4d0a685d63f5 -- Lee Jones [李琼斯]
