| Message ID | 20211115055354.6089-1-zajec5@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [V4,RESEND,1/2] dt-bindings: watchdog: convert Broadcom's WDT to the json-schema | expand |
Wim, Lee, On 15.11.2021 06:53, Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > This helps validating DTS files. > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > Acked-by: Florian Fainelli <f.fainelli@gmail.com> > Reviewed-by: Rob Herring <robh@kernel.org> I'm not familiar with handling multi-subsystem patchsets (here: watchdog & MFD). Please kindly let me know: how to proceed with this patchset now to get it queued for Linus?
On Mon, 06 Dec 2021, Rafał Miłecki wrote: > Wim, Lee, > > On 15.11.2021 06:53, Rafał Miłecki wrote: > > From: Rafał Miłecki <rafal@milecki.pl> > > > > This helps validating DTS files. > > > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > > Acked-by: Florian Fainelli <f.fainelli@gmail.com> > > Reviewed-by: Rob Herring <robh@kernel.org> > > I'm not familiar with handling multi-subsystem patchsets (here: watchdog > & MFD). > > Please kindly let me know: how to proceed with this patchset now to get > it queued for Linus? What is the requirement for these to be merged together?
On 06.12.2021 09:44, Lee Jones wrote: > On Mon, 06 Dec 2021, Rafał Miłecki wrote: >> On 15.11.2021 06:53, Rafał Miłecki wrote: >>> From: Rafał Miłecki <rafal@milecki.pl> >>> >>> This helps validating DTS files. >>> >>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> >>> Acked-by: Florian Fainelli <f.fainelli@gmail.com> >>> Reviewed-by: Rob Herring <robh@kernel.org> >> >> I'm not familiar with handling multi-subsystem patchsets (here: watchdog >> & MFD). >> >> Please kindly let me know: how to proceed with this patchset now to get >> it queued for Linus? > > What is the requirement for these to be merged together? If you merge 2/2 without 1/2 then people running "make dt_binding_check" may see 1 extra warning until both patches meet in Linus's tree. So it all comes to how much you care about amount of warnings produced by "dt_binding_check".
On Mon, 06 Dec 2021, Rafał Miłecki wrote: > On 06.12.2021 09:44, Lee Jones wrote: > > On Mon, 06 Dec 2021, Rafał Miłecki wrote: > > > On 15.11.2021 06:53, Rafał Miłecki wrote: > > > > From: Rafał Miłecki <rafal@milecki.pl> > > > > > > > > This helps validating DTS files. > > > > > > > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > > > > Acked-by: Florian Fainelli <f.fainelli@gmail.com> > > > > Reviewed-by: Rob Herring <robh@kernel.org> > > > > > > I'm not familiar with handling multi-subsystem patchsets (here: watchdog > > > & MFD). > > > > > > Please kindly let me know: how to proceed with this patchset now to get > > > it queued for Linus? > > > > What is the requirement for these to be merged together? > > If you merge 2/2 without 1/2 then people running "make dt_binding_check" > may see 1 extra warning until both patches meet in Linus's tree. > > So it all comes to how much you care about amount of warnings produced > by "dt_binding_check". In -next, I don't, but I know Rob gets excited about it. Rob, what is your final word on this? Is it a forced requirement for all interconnected document changes to go in together?
On 12/6/21 1:05 AM, Lee Jones wrote: > On Mon, 06 Dec 2021, Rafał Miłecki wrote: > >> On 06.12.2021 09:44, Lee Jones wrote: >>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>>> On 15.11.2021 06:53, Rafał Miłecki wrote: >>>>> From: Rafał Miłecki <rafal@milecki.pl> >>>>> >>>>> This helps validating DTS files. >>>>> >>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> >>>>> Acked-by: Florian Fainelli <f.fainelli@gmail.com> >>>>> Reviewed-by: Rob Herring <robh@kernel.org> >>>> >>>> I'm not familiar with handling multi-subsystem patchsets (here: watchdog >>>> & MFD). >>>> >>>> Please kindly let me know: how to proceed with this patchset now to get >>>> it queued for Linus? >>> >>> What is the requirement for these to be merged together? >> >> If you merge 2/2 without 1/2 then people running "make dt_binding_check" >> may see 1 extra warning until both patches meet in Linus's tree. >> >> So it all comes to how much you care about amount of warnings produced >> by "dt_binding_check". > > In -next, I don't, but I know Rob gets excited about it. > > Rob, what is your final word on this? Is it a forced requirement for > all interconnected document changes to go in together? The first patch is queued up in Guenter's watchdog tree here: https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=watchdog-next&id=a5b2ebc8f6e67b5c81023e8bde6b19ff48ffdb02 and will be submitted to Wim shortly I believe, so I suppose we should take patch #2 via Guenter and Wim's tree as well logically.
On Mon, 06 Dec 2021, Florian Fainelli wrote: > On 12/6/21 1:05 AM, Lee Jones wrote: > > On Mon, 06 Dec 2021, Rafał Miłecki wrote: > > > >> On 06.12.2021 09:44, Lee Jones wrote: > >>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: > >>>> On 15.11.2021 06:53, Rafał Miłecki wrote: > >>>>> From: Rafał Miłecki <rafal@milecki.pl> > >>>>> > >>>>> This helps validating DTS files. > >>>>> > >>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > >>>>> Acked-by: Florian Fainelli <f.fainelli@gmail.com> > >>>>> Reviewed-by: Rob Herring <robh@kernel.org> > >>>> > >>>> I'm not familiar with handling multi-subsystem patchsets (here: watchdog > >>>> & MFD). > >>>> > >>>> Please kindly let me know: how to proceed with this patchset now to get > >>>> it queued for Linus? > >>> > >>> What is the requirement for these to be merged together? > >> > >> If you merge 2/2 without 1/2 then people running "make dt_binding_check" > >> may see 1 extra warning until both patches meet in Linus's tree. > >> > >> So it all comes to how much you care about amount of warnings produced > >> by "dt_binding_check". > > > > In -next, I don't, but I know Rob gets excited about it. > > > > Rob, what is your final word on this? Is it a forced requirement for > > all interconnected document changes to go in together? > > The first patch is queued up in Guenter's watchdog tree here: > > https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=watchdog-next&id=a5b2ebc8f6e67b5c81023e8bde6b19ff48ffdb02 > > and will be submitted to Wim shortly I believe, so I suppose we should > take patch #2 via Guenter and Wim's tree as well logically. If that happens, I would like a PR to an immutable branch.
On 12/6/21 10:55 AM, Lee Jones wrote: > On Mon, 06 Dec 2021, Florian Fainelli wrote: > >> On 12/6/21 1:05 AM, Lee Jones wrote: >>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>> >>>> On 06.12.2021 09:44, Lee Jones wrote: >>>>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>>>>> On 15.11.2021 06:53, Rafał Miłecki wrote: >>>>>>> From: Rafał Miłecki <rafal@milecki.pl> >>>>>>> >>>>>>> This helps validating DTS files. >>>>>>> >>>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> >>>>>>> Acked-by: Florian Fainelli <f.fainelli@gmail.com> >>>>>>> Reviewed-by: Rob Herring <robh@kernel.org> >>>>>> >>>>>> I'm not familiar with handling multi-subsystem patchsets (here: watchdog >>>>>> & MFD). >>>>>> >>>>>> Please kindly let me know: how to proceed with this patchset now to get >>>>>> it queued for Linus? >>>>> >>>>> What is the requirement for these to be merged together? >>>> >>>> If you merge 2/2 without 1/2 then people running "make dt_binding_check" >>>> may see 1 extra warning until both patches meet in Linus's tree. >>>> >>>> So it all comes to how much you care about amount of warnings produced >>>> by "dt_binding_check". >>> >>> In -next, I don't, but I know Rob gets excited about it. >>> >>> Rob, what is your final word on this? Is it a forced requirement for >>> all interconnected document changes to go in together? >> >> The first patch is queued up in Guenter's watchdog tree here: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=watchdog-next&id=a5b2ebc8f6e67b5c81023e8bde6b19ff48ffdb02 >> >> and will be submitted to Wim shortly I believe, so I suppose we should >> take patch #2 via Guenter and Wim's tree as well logically. > > If that happens, I would like a PR to an immutable branch. > I don't entirely see the point of that complexity for dt changes, but whatever. Since my tree is not the official watchdog-next tree, that means I can not take the entire series (which goes way beyond the dt changes and also drops the bcm63xx driver). Unless I hear otherwise, I'll drop the series from my tree for the time being and wait for the dt changes to be sorted out. Guenter
On 12/6/21 11:10 AM, Guenter Roeck wrote: > On 12/6/21 10:55 AM, Lee Jones wrote: >> On Mon, 06 Dec 2021, Florian Fainelli wrote: >> >>> On 12/6/21 1:05 AM, Lee Jones wrote: >>>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>>> >>>>> On 06.12.2021 09:44, Lee Jones wrote: >>>>>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>>>>>> On 15.11.2021 06:53, Rafał Miłecki wrote: >>>>>>>> From: Rafał Miłecki <rafal@milecki.pl> >>>>>>>> >>>>>>>> This helps validating DTS files. >>>>>>>> >>>>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> >>>>>>>> Acked-by: Florian Fainelli <f.fainelli@gmail.com> >>>>>>>> Reviewed-by: Rob Herring <robh@kernel.org> >>>>>>> >>>>>>> I'm not familiar with handling multi-subsystem patchsets (here: >>>>>>> watchdog >>>>>>> & MFD). >>>>>>> >>>>>>> Please kindly let me know: how to proceed with this patchset now >>>>>>> to get >>>>>>> it queued for Linus? >>>>>> >>>>>> What is the requirement for these to be merged together? >>>>> >>>>> If you merge 2/2 without 1/2 then people running "make >>>>> dt_binding_check" >>>>> may see 1 extra warning until both patches meet in Linus's tree. >>>>> >>>>> So it all comes to how much you care about amount of warnings produced >>>>> by "dt_binding_check". >>>> >>>> In -next, I don't, but I know Rob gets excited about it. >>>> >>>> Rob, what is your final word on this? Is it a forced requirement for >>>> all interconnected document changes to go in together? >>> >>> The first patch is queued up in Guenter's watchdog tree here: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=watchdog-next&id=a5b2ebc8f6e67b5c81023e8bde6b19ff48ffdb02 >>> >>> >>> and will be submitted to Wim shortly I believe, so I suppose we should >>> take patch #2 via Guenter and Wim's tree as well logically. >> >> If that happens, I would like a PR to an immutable branch. >> > > I don't entirely see the point of that complexity for dt changes, > but whatever. Since my tree is not the official watchdog-next tree, > that means I can not take the entire series (which goes way beyond > the dt changes and also drops the bcm63xx driver). Unless I hear > otherwise, I'll drop the series from my tree for the time being > and wait for the dt changes to be sorted out. There is simply no rush in getting the bcm7038-wdt driver to support 4908 *just now*, so why don't you just take the bcm63xx-wdt series that I posed, and Rafal posts an updated series that adds support for the 4908 watchdog for the 5.18 cycle?
On 12/6/21 11:13 AM, Florian Fainelli wrote: > On 12/6/21 11:10 AM, Guenter Roeck wrote: >> On 12/6/21 10:55 AM, Lee Jones wrote: >>> On Mon, 06 Dec 2021, Florian Fainelli wrote: >>> >>>> On 12/6/21 1:05 AM, Lee Jones wrote: >>>>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>>>> >>>>>> On 06.12.2021 09:44, Lee Jones wrote: >>>>>>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>>>>>>> On 15.11.2021 06:53, Rafał Miłecki wrote: >>>>>>>>> From: Rafał Miłecki <rafal@milecki.pl> >>>>>>>>> >>>>>>>>> This helps validating DTS files. >>>>>>>>> >>>>>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> >>>>>>>>> Acked-by: Florian Fainelli <f.fainelli@gmail.com> >>>>>>>>> Reviewed-by: Rob Herring <robh@kernel.org> >>>>>>>> >>>>>>>> I'm not familiar with handling multi-subsystem patchsets (here: >>>>>>>> watchdog >>>>>>>> & MFD). >>>>>>>> >>>>>>>> Please kindly let me know: how to proceed with this patchset now >>>>>>>> to get >>>>>>>> it queued for Linus? >>>>>>> >>>>>>> What is the requirement for these to be merged together? >>>>>> >>>>>> If you merge 2/2 without 1/2 then people running "make >>>>>> dt_binding_check" >>>>>> may see 1 extra warning until both patches meet in Linus's tree. >>>>>> >>>>>> So it all comes to how much you care about amount of warnings produced >>>>>> by "dt_binding_check". >>>>> >>>>> In -next, I don't, but I know Rob gets excited about it. >>>>> >>>>> Rob, what is your final word on this? Is it a forced requirement for >>>>> all interconnected document changes to go in together? >>>> >>>> The first patch is queued up in Guenter's watchdog tree here: >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=watchdog-next&id=a5b2ebc8f6e67b5c81023e8bde6b19ff48ffdb02 >>>> >>>> >>>> and will be submitted to Wim shortly I believe, so I suppose we should >>>> take patch #2 via Guenter and Wim's tree as well logically. >>> >>> If that happens, I would like a PR to an immutable branch. >>> >> >> I don't entirely see the point of that complexity for dt changes, >> but whatever. Since my tree is not the official watchdog-next tree, >> that means I can not take the entire series (which goes way beyond >> the dt changes and also drops the bcm63xx driver). Unless I hear >> otherwise, I'll drop the series from my tree for the time being >> and wait for the dt changes to be sorted out. > > There is simply no rush in getting the bcm7038-wdt driver to support > 4908 *just now*, so why don't you just take the bcm63xx-wdt series that > I posed, and Rafal posts an updated series that adds support for the > 4908 watchdog for the 5.18 cycle? > Your series includes the patch discussed here, and it is the first patch of your series. The second patch in your series depends on it. Are you telling me that I should drop those two patches from your series ? For reference, the patches are 079a2959e68b dt-bindings: watchdog: Add BCM6345 compatible to BCM7038 binding a5b2ebc8f6e6 dt-bindings: watchdog: convert Broadcom's WDT to the json-schema in my watchdog-next branch. Guenter
On 12/6/21 11:37 AM, Guenter Roeck wrote: > On 12/6/21 11:13 AM, Florian Fainelli wrote: >> On 12/6/21 11:10 AM, Guenter Roeck wrote: >>> On 12/6/21 10:55 AM, Lee Jones wrote: >>>> On Mon, 06 Dec 2021, Florian Fainelli wrote: >>>> >>>>> On 12/6/21 1:05 AM, Lee Jones wrote: >>>>>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>>>>> >>>>>>> On 06.12.2021 09:44, Lee Jones wrote: >>>>>>>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>>>>>>>> On 15.11.2021 06:53, Rafał Miłecki wrote: >>>>>>>>>> From: Rafał Miłecki <rafal@milecki.pl> >>>>>>>>>> >>>>>>>>>> This helps validating DTS files. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> >>>>>>>>>> Acked-by: Florian Fainelli <f.fainelli@gmail.com> >>>>>>>>>> Reviewed-by: Rob Herring <robh@kernel.org> >>>>>>>>> >>>>>>>>> I'm not familiar with handling multi-subsystem patchsets (here: >>>>>>>>> watchdog >>>>>>>>> & MFD). >>>>>>>>> >>>>>>>>> Please kindly let me know: how to proceed with this patchset now >>>>>>>>> to get >>>>>>>>> it queued for Linus? >>>>>>>> >>>>>>>> What is the requirement for these to be merged together? >>>>>>> >>>>>>> If you merge 2/2 without 1/2 then people running "make >>>>>>> dt_binding_check" >>>>>>> may see 1 extra warning until both patches meet in Linus's tree. >>>>>>> >>>>>>> So it all comes to how much you care about amount of warnings >>>>>>> produced >>>>>>> by "dt_binding_check". >>>>>> >>>>>> In -next, I don't, but I know Rob gets excited about it. >>>>>> >>>>>> Rob, what is your final word on this? Is it a forced requirement for >>>>>> all interconnected document changes to go in together? >>>>> >>>>> The first patch is queued up in Guenter's watchdog tree here: >>>>> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=watchdog-next&id=a5b2ebc8f6e67b5c81023e8bde6b19ff48ffdb02 >>>>> >>>>> >>>>> >>>>> and will be submitted to Wim shortly I believe, so I suppose we should >>>>> take patch #2 via Guenter and Wim's tree as well logically. >>>> >>>> If that happens, I would like a PR to an immutable branch. >>>> >>> >>> I don't entirely see the point of that complexity for dt changes, >>> but whatever. Since my tree is not the official watchdog-next tree, >>> that means I can not take the entire series (which goes way beyond >>> the dt changes and also drops the bcm63xx driver). Unless I hear >>> otherwise, I'll drop the series from my tree for the time being >>> and wait for the dt changes to be sorted out. >> >> There is simply no rush in getting the bcm7038-wdt driver to support >> 4908 *just now*, so why don't you just take the bcm63xx-wdt series that >> I posed, and Rafal posts an updated series that adds support for the >> 4908 watchdog for the 5.18 cycle? >> > > Your series includes the patch discussed here, and it is the first patch > of your series. The second patch in your series depends on it. Are you > telling me that I should drop those two patches from your series ? No, quite the contrary, I want you to keep the entire 7 patches that converted the bcm7038-wdt binding to YAML and get rid of the bcm63xx-wdt changes, the branch that you have right now is good in that regard. I don't see why you should be creating an immutable branch for Lee and not simply merge Rafal's "[PATCH V4 RESEND 2/2] dt-bindings: mfd: add Broadcom's Timer-Watchdog block" patch with Lee's ack directly. This is a new file, so I don't see how it would create conflicts as long as we don't pile up changes on top.
On Mon, Dec 06, 2021 at 11:43:31AM -0800, Florian Fainelli wrote: [ ... ] > > > > Your series includes the patch discussed here, and it is the first patch > > of your series. The second patch in your series depends on it. Are you > > telling me that I should drop those two patches from your series ? > > No, quite the contrary, I want you to keep the entire 7 patches that > converted the bcm7038-wdt binding to YAML and get rid of the bcm63xx-wdt > changes, the branch that you have right now is good in that regard. > > I don't see why you should be creating an immutable branch for Lee and > not simply merge Rafal's "[PATCH V4 RESEND 2/2] dt-bindings: mfd: add > Broadcom's Timer-Watchdog block" patch with Lee's ack directly. This is > a new file, so I don't see how it would create conflicts as long as we > don't pile up changes on top. It sounded to me like Lee wanted an immutable branch for that, which I can't do for watchdog. That means the options are to either drop the dt changes, or to drop everything until after the dt issues are sorted out. Guenter
On 06.12.2021 20:43, Florian Fainelli wrote: > On 12/6/21 11:37 AM, Guenter Roeck wrote: >> On 12/6/21 11:13 AM, Florian Fainelli wrote: >>> There is simply no rush in getting the bcm7038-wdt driver to support >>> 4908 *just now*, so why don't you just take the bcm63xx-wdt series that >>> I posed, and Rafal posts an updated series that adds support for the >>> 4908 watchdog for the 5.18 cycle? >>> >> >> Your series includes the patch discussed here, and it is the first patch >> of your series. The second patch in your series depends on it. Are you >> telling me that I should drop those two patches from your series ? > > No, quite the contrary, I want you to keep the entire 7 patches that > converted the bcm7038-wdt binding to YAML and get rid of the bcm63xx-wdt > changes, the branch that you have right now is good in that regard. > > I don't see why you should be creating an immutable branch for Lee and > not simply merge Rafal's "[PATCH V4 RESEND 2/2] dt-bindings: mfd: add > Broadcom's Timer-Watchdog block" patch with Lee's ack directly. This is > a new file, so I don't see how it would create conflicts as long as we > don't pile up changes on top. I'd like that pretty much as I wouldn't need to wait few extra months. Lee: would that be OK for you to simply ack 2/2? So Guenter can pick my patch without the whole immutable branch & PR thing?
Florian Fainelli wrote: > I don't see why you should be creating an immutable branch for Lee and > not simply merge Rafal's "[PATCH V4 RESEND 2/2] dt-bindings: mfd: add > Broadcom's Timer-Watchdog block" patch with Lee's ack directly. This is > a new file, so I don't see how it would create conflicts as long as we > don't pile up changes on top. Rafał Miłecki wrote: > would that be OK for you to simply ack 2/2? So Guenter can pick my > patch without the whole immutable branch & PR thing? Guenter Roeck wrote: > I don't entirely see the point of that complexity for dt changes, > but whatever. Since my tree is not the official watchdog-next tree, > that means I can not take the entire series (which goes way beyond > the dt changes and also drops the bcm63xx driver). Unless I hear > otherwise, I'll drop the series from my tree for the time being > and wait for the dt changes to be sorted out. If Rob wants `dt_binding_check` to run cleanly in -next, we have to treat the DT documentation in the same manner we do for real code when build dependencies exist between patches. Simply sucking them up through a single repo is just dandy until subsequent changes are required, which unfortunately is often the case. Being the Maintainer of MFD, which is often the centre point of cross-subsystems patch sets, I've been bitten by this too many times. Hence my hesitancy to 'just Ack it and be done'. I've been pushing back on the requirement for clean `dt_binding_check` runs in -next for a while and would much prefer to treat it the same way we do `checkpatch.pl`, whereby a clean run is not a hard requirement. Instead it is used as one of many tools to check for inconsistencies prior to submission (as possibly against patch-sets once they are posted onto the list). However, just as we see false positives in `checkpatch.pl` we should see them in `dt_binding_check` where patches have simply been applied into different trees and may lag each other by a week or two. > It sounded to me like Lee wanted an immutable branch for that Not exactly, I said: "> Suppose we should take patch #2 via [Watchdog] as well. If that happens, I would like a PR to an immutable branch." The alternative is that I take the patch and provide an immutable branch to you, which I am in a position to do. Of course all of this hassle just goes away if the clean `dt_binding_check` run on -next requirement is laxed and we can just take our own patches without fear of wrath.
On 12/7/21 2:03 AM, Lee Jones wrote: [ ... ] >> It sounded to me like Lee wanted an immutable branch for that > > Not exactly, I said: > > "> Suppose we should take patch #2 via [Watchdog] as well. > > If that happens, I would like a PR to an immutable branch." > > The alternative is that I take the patch and provide an immutable > branch to you, which I am in a position to do. > I understand, only I am not in a position to take it since my tree isn't the official watchdog-next tree, and it doesn't show up in -next. If Wim takes it into the official watchdog-next tree or not would be completely up to him. I personally don't care if the bindings check is clean in my inofficial tree, so maybe this is a non-issue. Guenter
On Tue, 07 Dec 2021, Guenter Roeck wrote: > On 12/7/21 2:03 AM, Lee Jones wrote: > [ ... ] > > > It sounded to me like Lee wanted an immutable branch for that > > > > Not exactly, I said: > > > > "> Suppose we should take patch #2 via [Watchdog] as well. > > > > If that happens, I would like a PR to an immutable branch." > > > > The alternative is that I take the patch and provide an immutable > > branch to you, which I am in a position to do. > > > > I understand, only I am not in a position to take it since my tree > isn't the official watchdog-next tree, and it doesn't show up in -next. > If Wim takes it into the official watchdog-next tree or not would be > completely up to him. > > I personally don't care if the bindings check is clean in my inofficial > tree, so maybe this is a non-issue. That doesn't help, sadly. I think the best course of action is for Wim to let me know when this patch makes it into his tree. I'll take the MFD one at the same time and the two shall meet in -next. Honestly, this is all such a faff. Just to keep a script happy that 3 people care about.
Hi Lee, > On Tue, 07 Dec 2021, Guenter Roeck wrote: > > > On 12/7/21 2:03 AM, Lee Jones wrote: > > [ ... ] > > > > It sounded to me like Lee wanted an immutable branch for that > > > > > > Not exactly, I said: > > > > > > "> Suppose we should take patch #2 via [Watchdog] as well. > > > > > > If that happens, I would like a PR to an immutable branch." > > > > > > The alternative is that I take the patch and provide an immutable > > > branch to you, which I am in a position to do. > > > > > > > I understand, only I am not in a position to take it since my tree > > isn't the official watchdog-next tree, and it doesn't show up in -next. > > If Wim takes it into the official watchdog-next tree or not would be > > completely up to him. > > > > I personally don't care if the bindings check is clean in my inofficial > > tree, so maybe this is a non-issue. > > That doesn't help, sadly. > > I think the best course of action is for Wim to let me know when this > patch makes it into his tree. I'll take the MFD one at the same time > and the two shall meet in -next. > > Honestly, this is all such a faff. > > Just to keep a script happy that 3 people care about. It's going in today. Kind regards, Wim.
On Tue, 28 Dec 2021, Wim Van Sebroeck wrote: > Hi Lee, > > > On Tue, 07 Dec 2021, Guenter Roeck wrote: > > > > > On 12/7/21 2:03 AM, Lee Jones wrote: > > > [ ... ] > > > > > It sounded to me like Lee wanted an immutable branch for that > > > > > > > > Not exactly, I said: > > > > > > > > "> Suppose we should take patch #2 via [Watchdog] as well. > > > > > > > > If that happens, I would like a PR to an immutable branch." > > > > > > > > The alternative is that I take the patch and provide an immutable > > > > branch to you, which I am in a position to do. > > > > > > > > > > I understand, only I am not in a position to take it since my tree > > > isn't the official watchdog-next tree, and it doesn't show up in -next. > > > If Wim takes it into the official watchdog-next tree or not would be > > > completely up to him. > > > > > > I personally don't care if the bindings check is clean in my inofficial > > > tree, so maybe this is a non-issue. > > > > That doesn't help, sadly. > > > > I think the best course of action is for Wim to let me know when this > > patch makes it into his tree. I'll take the MFD one at the same time > > and the two shall meet in -next. > > > > Honestly, this is all such a faff. > > > > Just to keep a script happy that 3 people care about. > > It's going in today. Also applied. Thanks Wim.
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt deleted file mode 100644 index 84122270be8f..000000000000 --- a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt +++ /dev/null @@ -1,19 +0,0 @@ -BCM7038 Watchdog timer - -Required properties: - -- compatible : should be "brcm,bcm7038-wdt" -- reg : Specifies base physical address and size of the registers. - -Optional properties: - -- clocks: The clock running the watchdog. If no clock is found the - driver will default to 27000000 Hz. - -Example: - -watchdog@f040a7e8 { - compatible = "brcm,bcm7038-wdt"; - clocks = <&upg_fixed>; - reg = <0xf040a7e8 0x16>; -}; diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml new file mode 100644 index 000000000000..ed6210666ead --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/brcm,bcm7038-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: BCM7038 watchdog timer + +allOf: + - $ref: "watchdog.yaml#" + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + - Justin Chen <justinpopo6@gmail.com> + - Rafał Miłecki <rafal@milecki.pl> + +properties: + compatible: + const: brcm,bcm7038-wdt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + description: > + The clock running the watchdog. If no clock is found the driver will + default to 27000000 Hz. + +unevaluatedProperties: false + +required: + - reg + +examples: + - | + watchdog@f040a7e8 { + compatible = "brcm,bcm7038-wdt"; + reg = <0xf040a7e8 0x16>; + clocks = <&upg_fixed>; + };