Message ID | 20211001094106.52412-1-krzysztof.kozlowski@canonical.com (mailing list archive) |
---|---|
Headers | show |
Series | regulator/mfd/clock: dt-bindings: Samsung S2M and S5M to dtschema | expand |
On Fri, Oct 01, 2021 at 11:40:56AM +0200, Krzysztof Kozlowski wrote: > Merging/dependencies > ==================== > 1. Regulator related binding changes depend on first two commits (the > fixes), because of context. > 2. The mfd bindings depend on clock and regulator bindings. > > The fixes and bindings changes (patches 1-10) should go via the same > tree. For example regulator or mfd tree. I propose the regulator tree, > since it will have also one driver change (the fix, first commit). Lee, Stephen, Michael does Krzysztof's plan make sense to you?
On Tue, 05 Oct 2021, Mark Brown wrote: > On Fri, Oct 01, 2021 at 11:40:56AM +0200, Krzysztof Kozlowski wrote: > > > Merging/dependencies > > ==================== > > 1. Regulator related binding changes depend on first two commits (the > > fixes), because of context. > > 2. The mfd bindings depend on clock and regulator bindings. > > > > The fixes and bindings changes (patches 1-10) should go via the same > > tree. For example regulator or mfd tree. I propose the regulator tree, > > since it will have also one driver change (the fix, first commit). > > Lee, Stephen, Michael does Krzysztof's plan make sense to you? I tend to take cross subsystem patches. MFD is usually in the centre of these scenarios and I have tooling to easily set-up immutable branches/pull-requests. Always happy to discuss if others have different/better ideas though.
On 05/10/2021 15:14, Lee Jones wrote: > On Tue, 05 Oct 2021, Mark Brown wrote: > >> On Fri, Oct 01, 2021 at 11:40:56AM +0200, Krzysztof Kozlowski wrote: >> >>> Merging/dependencies >>> ==================== >>> 1. Regulator related binding changes depend on first two commits (the >>> fixes), because of context. >>> 2. The mfd bindings depend on clock and regulator bindings. >>> >>> The fixes and bindings changes (patches 1-10) should go via the same >>> tree. For example regulator or mfd tree. I propose the regulator tree, >>> since it will have also one driver change (the fix, first commit). >> >> Lee, Stephen, Michael does Krzysztof's plan make sense to you? > > I tend to take cross subsystem patches. MFD is usually in the centre > of these scenarios and I have tooling to easily set-up immutable > branches/pull-requests. > > Always happy to discuss if others have different/better ideas though. > Another alternative is that regulator patches (1-2, 4-6) go via Mark who later gives you a stable branch/tag to pull. Then the clock and MFD bindings would go on top via MFD tree. There is a comment from Rob which I will fix in v3. Best regards, Krzysztof
On Wed, 06 Oct 2021, Krzysztof Kozlowski wrote: > On 05/10/2021 15:14, Lee Jones wrote: > > On Tue, 05 Oct 2021, Mark Brown wrote: > > > >> On Fri, Oct 01, 2021 at 11:40:56AM +0200, Krzysztof Kozlowski wrote: > >> > >>> Merging/dependencies > >>> ==================== > >>> 1. Regulator related binding changes depend on first two commits (the > >>> fixes), because of context. > >>> 2. The mfd bindings depend on clock and regulator bindings. > >>> > >>> The fixes and bindings changes (patches 1-10) should go via the same > >>> tree. For example regulator or mfd tree. I propose the regulator tree, > >>> since it will have also one driver change (the fix, first commit). > >> > >> Lee, Stephen, Michael does Krzysztof's plan make sense to you? > > > > I tend to take cross subsystem patches. MFD is usually in the centre > > of these scenarios and I have tooling to easily set-up immutable > > branches/pull-requests. > > > > Always happy to discuss if others have different/better ideas though. > > > > Another alternative is that regulator patches (1-2, 4-6) go via Mark who > later gives you a stable branch/tag to pull. Then the clock and MFD > bindings would go on top via MFD tree. It shouldn't matter where they are first applied. Creating 2 immutable branches when just 1 will do would be a pain. > There is a comment from Rob which I will fix in v3. Sure.