On Sat, 22 Jun 2019 at 20:13, Sasha Levin sashal@kernel.org wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag, fixing commit: 1c984942f0a4 regulator: s2mps11: Pass descriptor instead of GPIO number.
The bot has tested the following trees: v5.1.12, v4.19.53.
v5.1.12: Build OK! v4.19.53: Failed to apply! Possible dependencies: Unable to calculate
How should we proceed with this patch?
The commit mentioned in fixes tag (1c984942f0a4) came in v5.0-rc1/v5.0. Why do you try to port it to v4.19?
Best regards, Krzysztof
On Mon, Jun 24, 2019 at 09:01:27AM +0200, Krzysztof Kozlowski wrote:
On Sat, 22 Jun 2019 at 20:13, Sasha Levin sashal@kernel.org wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag, fixing commit: 1c984942f0a4 regulator: s2mps11: Pass descriptor instead of GPIO number.
The bot has tested the following trees: v5.1.12, v4.19.53.
v5.1.12: Build OK! v4.19.53: Failed to apply! Possible dependencies: Unable to calculate
How should we proceed with this patch?
The commit mentioned in fixes tag (1c984942f0a4) came in v5.0-rc1/v5.0. Why do you try to port it to v4.19?
This is an interesting one! Usually when something like this happens, it means that the "fixed" commit was backported to stable, but as you pointed out, it was not.
My scripts have logic to try and detect these backports, and it appears that there's a commit with an identical subject line in the 4.19 tree, so at this point there are two commits with identical subject lines in Linus's tree:
1c984942f0a4 regulator: s2mps11: Pass descriptor instead of GPIO number 0369e02b75e6 regulator: s2mps11: Pass descriptor instead of GPIO number
Which can be confusing for humans too :)
-- Thanks, Sasha
On Mon, 24 Jun 2019 at 12:11, Sasha Levin sashal@kernel.org wrote:
On Mon, Jun 24, 2019 at 09:01:27AM +0200, Krzysztof Kozlowski wrote:
On Sat, 22 Jun 2019 at 20:13, Sasha Levin sashal@kernel.org wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag, fixing commit: 1c984942f0a4 regulator: s2mps11: Pass descriptor instead of GPIO number.
The bot has tested the following trees: v5.1.12, v4.19.53.
v5.1.12: Build OK! v4.19.53: Failed to apply! Possible dependencies: Unable to calculate
How should we proceed with this patch?
The commit mentioned in fixes tag (1c984942f0a4) came in v5.0-rc1/v5.0. Why do you try to port it to v4.19?
This is an interesting one! Usually when something like this happens, it means that the "fixed" commit was backported to stable, but as you pointed out, it was not.
My scripts have logic to try and detect these backports, and it appears that there's a commit with an identical subject line in the 4.19 tree, so at this point there are two commits with identical subject lines in Linus's tree:
1c984942f0a4 regulator: s2mps11: Pass descriptor instead of GPIO number 0369e02b75e6 regulator: s2mps11: Pass descriptor instead of GPIO number
Which can be confusing for humans too :)
+CC Mark Brown,
Ugh, I see more of commits from this patchset getting to mainline twice. One branch goes to Linus via 79f20778fb228ae372cd7602745382fd4543ef31 Merge tag 'regulator-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator which is based on v4.20-rc1
The other commits gets there via: 68cc38ff33f38424d0456f9a1ecfec4683226a7e Merge tag 'regulator-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator which is before (gets into v4.18-rc1).
But how the latter can be applied again if it is based on something already containing these commits... I am so confused...
Anyway the Fixes needs to be corrected to contain both (also 0369e02b75e6) and should be backported to v4.19... I'll see if I have spare time to make a backport.
Best regards, Krzysztof
On Mon, 24 Jun 2019 at 12:41, Krzysztof Kozlowski krzk@kernel.org wrote:
On Mon, 24 Jun 2019 at 12:11, Sasha Levin sashal@kernel.org wrote:
On Mon, Jun 24, 2019 at 09:01:27AM +0200, Krzysztof Kozlowski wrote:
On Sat, 22 Jun 2019 at 20:13, Sasha Levin sashal@kernel.org wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag, fixing commit: 1c984942f0a4 regulator: s2mps11: Pass descriptor instead of GPIO number.
The bot has tested the following trees: v5.1.12, v4.19.53.
v5.1.12: Build OK! v4.19.53: Failed to apply! Possible dependencies: Unable to calculate
How should we proceed with this patch?
The commit mentioned in fixes tag (1c984942f0a4) came in v5.0-rc1/v5.0. Why do you try to port it to v4.19?
This is an interesting one! Usually when something like this happens, it means that the "fixed" commit was backported to stable, but as you pointed out, it was not.
My scripts have logic to try and detect these backports, and it appears that there's a commit with an identical subject line in the 4.19 tree, so at this point there are two commits with identical subject lines in Linus's tree:
1c984942f0a4 regulator: s2mps11: Pass descriptor instead of GPIO number 0369e02b75e6 regulator: s2mps11: Pass descriptor instead of GPIO number
Which can be confusing for humans too :)
+CC Mark Brown,
Ugh, I see more of commits from this patchset getting to mainline twice. One branch goes to Linus via 79f20778fb228ae372cd7602745382fd4543ef31 Merge tag 'regulator-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator which is based on v4.20-rc1
The other commits gets there via: 68cc38ff33f38424d0456f9a1ecfec4683226a7e Merge tag 'regulator-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator which is before (gets into v4.18-rc1).
But how the latter can be applied again if it is based on something already containing these commits... I am so confused...
Anyway the Fixes needs to be corrected to contain both (also 0369e02b75e6) and should be backported to v4.19... I'll see if I have spare time to make a backport.
Ah, I see now revert of the first commit 37fa23dbccbd97663acc085bd79246f427e603a1 (regulator: s2mps11: Fix boot on Odroid XU3). Actually git diff points that there was no effective change in the s2mps11 regulator.
Since the revert got into v4.18, then v4.19 is safe and there is no need for backport.
Best regards, Krzysztof
linux-stable-mirror@lists.linaro.org
-
Krzysztof Kozlowski -
Sasha Levin