dt-bindings: watchdog: convert Broadcom's WDT to the json-schema
Subsystems (5)
PATCH RESEND v4 1/2 dt-bindings: watchdog: convert Broadcom's WDT to the json-schema
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
---
V2: Use valid $id
V4: Add "clocks" maxItems and include Rob's Reviewed-by
RESEND: Patchwork lost 1/2, marc.info lost 2/2
--- .../bindings/watchdog/brcm,bcm7038-wdt.txt | 19 --------- .../bindings/watchdog/brcm,bcm7038-wdt.yaml | 41 +++++++++++++++++++ 2 files changed, 41 insertions(+), 19 deletions(-) delete mode 100644 Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt create mode 100644 Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt deleted +0 -19
@@ -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>; -};
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml new file +41 -0
41 lines not on this page · raw message
Signature · 1 line
2.31.1
PATCH RESEND v4 2/2 dt-bindings: mfd: add Broadcom's Timer-Watchdog block
From: Rafał Miłecki <[email protected]>
It's a block implementing few time related functions depending on a (SoC specific) variant. At this point there is ready binding for a watchdog only. Work on remaining subblocks (e.g. "reg" based reboot) is in progress.
---
V2: Update $id, description, compatible, example & commit message
V3: Drop "brcm,twd" from compatible list per Rob's review
RESEND: Patchwork lost 1/2, marc.info lost 2/2
--- .../devicetree/bindings/mfd/brcm,twd.yaml | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/brcm,twd.yaml
Documentation/devicetree/bindings/mfd/brcm,twd.yaml new file +61 -0
@@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/brcm,twd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom's Timer-Watchdog (aka TWD) + +maintainers: + - Rafał Miłecki <[email protected]> + +description: | + Broadcom has a Timer-Watchdog block used in multiple SoCs (e.g., BCM4908, + BCM63xx, BCM7038). There are few variants available (they differ slightly in + registers layout). This block consists of: timers, watchdog and optionally a + software reset handler. + +properties: + compatible: + items: + - enum: + - brcm,bcm4908-twd + - brcm,bcm7038-twd + - const: simple-mfd + - const: syscon + + reg: + maxItems: 1 + + ranges: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + +patternProperties: + '^watchdog@[a-f0-9]+$': + $ref: /schemas/watchdog/brcm,bcm7038-wdt.yaml + +additionalProperties: false + +required: + - reg + +examples: + - | + timer-mfd@ff800400 { + compatible = "brcm,bcm4908-twd", "simple-mfd", "syscon"; + reg = <0xff800400 0x4c>; + ranges = <0x00000000 0xff800400 0x4c>; + + #address-cells = <1>; + #size-cells = <1>; + + watchdog@28 { + compatible = "brcm,bcm7038-wdt"; + reg = <0x28 0x8>; + }; + };
Signature · 1 line
2.31.1
Re: [PATCH V4 RESEND 2/2] dt-bindings: mfd: add Broadcom's Timer-Watchdog block
Quoted 8 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
It's a block implementing few time related functions depending on a (SoC specific) variant. At this point there is ready binding for a watchdog only. Work on remaining subblocks (e.g. "reg" based reboot) is in progress.
Signed-off-by Rafał Miłecki <[email protected]>
Quoted 9 lines
---
V2: Update $id, description, compatible, example & commit message
V3: Drop "brcm,twd" from compatible list per Rob's review
RESEND: Patchwork lost 1/2, marc.info lost 2/2--- .../devicetree/bindings/mfd/brcm,twd.yaml | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/brcm,twd.yaml
Lee Jones
AppliedRe: [PATCH V4 RESEND 2/2] dt-bindings: mfd: add Broadcom's Timer-Watchdog block
In reply to Rafał MiłeckiQuoted 8 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
It's a block implementing few time related functions depending on a (SoC specific) variant. At this point there is ready binding for a watchdog only. Work on remaining subblocks (e.g. "reg" based reboot) is in progress.
Signed-off-by Rafał Miłecki <[email protected]>
Quoted 8 lines
---
V2: Update $id, description, compatible, example & commit message
V3: Drop "brcm,twd" from compatible list per Rob's review
RESEND: Patchwork lost 1/2, marc.info lost 2/2--- .../devicetree/bindings/mfd/brcm,twd.yaml | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/brcm,twd.yaml
Applied, thanks.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Wim, Lee,
Quoted 7 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
Signed-off-by Rafał Miłecki <[email protected]>Acked-by Florian Fainelli <[email protected]>Reviewed-by Rob Herring <[email protected]>
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?
Quoted 11 lines · Rafał Miłecki
Wim, Lee,
Quoted 7 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
Signed-off-by Rafał Miłecki <[email protected]>Acked-by Florian Fainelli <[email protected]>Reviewed-by Rob Herring <[email protected]>
Quoted 5 lines
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?
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 10 lines · Lee Jones
Quoted 9 lines · Rafał Miłecki
Quoted 7 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
Signed-off-by Rafał Miłecki <[email protected]>Acked-by Florian Fainelli <[email protected]>Reviewed-by Rob Herring <[email protected]>
Quoted 7 lines
Quoted 5 lines
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".
Quoted 17 lines · Rafał Miłecki
Quoted 16 lines · Lee Jones
Quoted 14 lines · Rafał Miłecki
Quoted 7 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
Signed-off-by Rafał Miłecki <[email protected]>Acked-by Florian Fainelli <[email protected]>Reviewed-by Rob Herring <[email protected]>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?
Quoted 7 lines
Quoted 1 line
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?
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 24 lines · Lee Jones
Quoted 22 lines · Rafał Miłecki
Quoted 10 lines · Lee Jones
Quoted 9 lines · Rafał Miłecki
Quoted 7 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
Signed-off-by Rafał Miłecki <[email protected]>Acked-by Florian Fainelli <[email protected]>Reviewed-by Rob Herring <[email protected]>Quoted 7 lines
Quoted 5 lines
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.
Quoted 7 lines
Quoted 2 lines
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:
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.
Signature · 1 line
Florian
Quoted 33 lines · Florian Fainelli
Quoted 24 lines · Lee Jones
Quoted 22 lines · Rafał Miłecki
Quoted 10 lines · Lee Jones
Quoted 9 lines · Rafał Miłecki
Quoted 7 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
Signed-off-by Rafał Miłecki <[email protected]>Acked-by Florian Fainelli <[email protected]>Reviewed-by Rob Herring <[email protected]>Quoted 7 lines
Quoted 5 lines
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.Quoted 7 lines
Quoted 2 lines
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?
Quoted 6 lines
The first patch is queued up in Guenter's watchdog tree here:
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.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Guenter Roeck
maintainerQuoted 35 lines · Lee Jones
Quoted 33 lines · Florian Fainelli
Quoted 31 lines · Lee Jones
Quoted 17 lines · Rafał Miłecki
Quoted 16 lines · Lee Jones
Quoted 14 lines · Rafał Miłecki
Quoted 7 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
Signed-off-by Rafał Miłecki <[email protected]>Acked-by Florian Fainelli <[email protected]>Reviewed-by Rob Herring <[email protected]>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?
Quoted 7 lines
Quoted 1 line
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?
Quoted 9 lines
Quoted 6 lines
The first patch is queued up in Guenter's watchdog tree here:
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
Quoted 50 lines · Guenter Roeck
Quoted 40 lines · Lee Jones
Quoted 38 lines · Florian Fainelli
Quoted 27 lines · Lee Jones
Quoted 25 lines · Rafał Miłecki
Quoted 14 lines · Lee Jones
Quoted 13 lines · Rafał Miłecki
Quoted 7 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
Signed-off-by Rafał Miłecki <[email protected]>Acked-by Florian Fainelli <[email protected]>Reviewed-by Rob Herring <[email protected]>I'm not familiar with handling multi-subsystem patchsets (here:
watchdog
& MFD).Quoted 5 lines
Quoted 3 lines
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.Quoted 7 lines
Quoted 2 lines
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:
Quoted 8 lines
Quoted 5 lines
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.
Quoted 6 lines
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?
Signature · 1 line
Florian
Guenter Roeck
maintainerQuoted 58 lines · Florian Fainelli
Quoted 50 lines · Guenter Roeck
Quoted 40 lines · Lee Jones
Quoted 38 lines · Florian Fainelli
Quoted 27 lines · Lee Jones
Quoted 25 lines · Rafał Miłecki
Quoted 14 lines · Lee Jones
Quoted 13 lines · Rafał Miłecki
Quoted 7 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
Signed-off-by Rafał Miłecki <[email protected]>Acked-by Florian Fainelli <[email protected]>Reviewed-by Rob Herring <[email protected]>I'm not familiar with handling multi-subsystem patchsets (here:
watchdog
& MFD).Quoted 5 lines
Quoted 3 lines
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.Quoted 7 lines
Quoted 2 lines
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:
Quoted 8 lines
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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
Quoted 67 lines · Guenter Roeck
Quoted 60 lines · Florian Fainelli
Quoted 52 lines · Guenter Roeck
Quoted 41 lines · Lee Jones
Quoted 39 lines · Florian Fainelli
Quoted 27 lines · Lee Jones
Quoted 25 lines · Rafał Miłecki
Quoted 14 lines · Lee Jones
Quoted 13 lines · Rafał Miłecki
Quoted 7 lines · Rafał Miłecki
From: Rafał Miłecki <[email protected]>
This helps validating DTS files.
Signed-off-by Rafał Miłecki <[email protected]>Acked-by Florian Fainelli <[email protected]>Reviewed-by Rob Herring <[email protected]>I'm not familiar with handling multi-subsystem patchsets (here:
watchdog
& MFD).Quoted 5 lines
Quoted 3 lines
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.Quoted 8 lines
Quoted 3 lines
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:
Quoted 9 lines
Quoted 6 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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?
Quoted 3 lines
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.
Signature · 1 line
Florian
Guenter Roeck
maintainerOn Mon, Dec 06, 2021 at 11:43:31AM -0800, Florian Fainelli wrote:
[ ... ]
Quoted 9 lines
Quoted 4 lines
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.
Quoted 5 lines
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
Quoted 5 lines · Florian Fainelli
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.
Quoted 2 lines · Rafał Miłecki
would that be OK for you to simply ack 2/2? So Guenter can pick my patch without the whole immutable branch & PR thing?
Quoted 6 lines · Guenter Roeck
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.
Quoted 1 line
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.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Guenter Roeck
maintainerOn 12/7/21 2:03 AM, Lee Jones wrote:
[ ... ]
Quoted 11 lines
Quoted 1 line
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
Quoted 14 lines · Guenter Roeck
On 12/7/21 2:03 AM, Lee Jones wrote:
[ ... ]Quoted 11 lines
Quoted 1 line
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.
Quoted 7 lines
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.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Wim Van Sebroeck
maintainerHi Lee,
Quoted 26 lines · Guenter Roeck
Quoted 15 lines · Lee Jones
[ ... ]
Quoted 11 lines
Quoted 1 line
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.
Quoted 7 lines
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.
Quoted 7 lines
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.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 32 lines · Wim Van Sebroeck
Hi Lee,
Quoted 30 lines · Guenter Roeck
Quoted 15 lines · Lee Jones
[ ... ]
Quoted 11 lines
Quoted 1 line
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.
Quoted 7 lines
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.
Quoted 5 lines
Quoted 3 lines
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.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 16 lines · Florian Fainelli
Quoted 10 lines · Guenter Roeck
Quoted 5 lines · Florian Fainelli
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.
Quoted 5 lines
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?