| Message ID | 5552256.Sb9uPGUboI@phil (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [GIT,PULL] Rockchip dts64 changes for 6.15 #3 | expand |
On Wed, Mar 19, 2025 at 6:56 PM Heiko Stuebner <heiko@sntech.de> wrote: > > Hi soc maintainers, > > I made an error and accidentially applied a patch that was meant for > the mfd tree. Thankfully Stephen noticed that when the duplicate > commit appeared in linux-next. Both commits are in v6.15-rc1 now and the revert is not, so this should not get applied/pulled. Or you will need to revert the revert. Rob > > > Please pull. > Thanks > Heiko > > > The following changes since commit 73d246b4402c3356f6b3d13665de3a51eea7b555: > > arm64: dts: rockchip: remove ethm0_clk0_25m_out from Sige5 gmac0 (2025-03-15 15:49:00 +0100) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v6.15-rockchip-dts64-3 > > for you to fetch changes up to cee24bc73d4f3f47344a1a54100a69c72f1db061: > > Revert "dt-bindings: mfd: syscon: Add rk3528 QoS register compatible" (2025-03-19 00:22:18 +0100) > > ---------------------------------------------------------------- > Revert of one commit that was applied accidentially and should instead > go through the MFD tree. It is already part of that tree as > commit 7f3e3e7228bb ("dt-bindings: mfd: syscon: Add rk3528 QoS register > compatible"). > > ---------------------------------------------------------------- > Heiko Stuebner (1): > Revert "dt-bindings: mfd: syscon: Add rk3528 QoS register compatible" > > Documentation/devicetree/bindings/mfd/syscon.yaml | 2 -- > 1 file changed, 2 deletions(-) > > > >
Hi Rob, Am Montag, 7. April 2025, 17:56:37 Mitteleuropäische Sommerzeit schrieb Rob Herring: > On Wed, Mar 19, 2025 at 6:56 PM Heiko Stuebner <heiko@sntech.de> wrote: > > > > Hi soc maintainers, > > > > I made an error and accidentially applied a patch that was meant for > > the mfd tree. Thankfully Stephen noticed that when the duplicate > > commit appeared in linux-next. > > Both commits are in v6.15-rc1 now and the revert is not, so this > should not get applied/pulled. Or you will need to revert the revert. yes, that was the intention. Back when I submitted this PR, I talked with Arnd on IRC the next day. As both commits are identical sans some Signed-off-by lines, he suggested not trying to put a revert in, but instead let git solve it itself, because arnd on IRC: > [...], but I worry that this would make things worse if 'git merge' > ends up doing the revert on top of the original commit once it gets to > torvalds. Not sure if that's still a problem in git these days, but > I've seen it happen in the past. > if two identical patches are in different branches, just leaving them > there is usually easier So this PR was already marked as "superseeded" in patchwork back on march 20th. Nevertheless, thanks for making sure no funky revert happens now. Heiko > > The following changes since commit 73d246b4402c3356f6b3d13665de3a51eea7b555: > > > > arm64: dts: rockchip: remove ethm0_clk0_25m_out from Sige5 gmac0 (2025-03-15 15:49:00 +0100) > > > > are available in the Git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v6.15-rockchip-dts64-3 > > > > for you to fetch changes up to cee24bc73d4f3f47344a1a54100a69c72f1db061: > > > > Revert "dt-bindings: mfd: syscon: Add rk3528 QoS register compatible" (2025-03-19 00:22:18 +0100) > > > > ---------------------------------------------------------------- > > Revert of one commit that was applied accidentially and should instead > > go through the MFD tree. It is already part of that tree as > > commit 7f3e3e7228bb ("dt-bindings: mfd: syscon: Add rk3528 QoS register > > compatible"). > > > > ---------------------------------------------------------------- > > Heiko Stuebner (1): > > Revert "dt-bindings: mfd: syscon: Add rk3528 QoS register compatible" > > > > Documentation/devicetree/bindings/mfd/syscon.yaml | 2 -- > > 1 file changed, 2 deletions(-) > > > > > > > > >
On Mon, Apr 7, 2025 at 11:40 AM Heiko Stübner <heiko@sntech.de> wrote: > > Hi Rob, > > Am Montag, 7. April 2025, 17:56:37 Mitteleuropäische Sommerzeit schrieb Rob Herring: > > On Wed, Mar 19, 2025 at 6:56 PM Heiko Stuebner <heiko@sntech.de> wrote: > > > > > > Hi soc maintainers, > > > > > > I made an error and accidentially applied a patch that was meant for > > > the mfd tree. Thankfully Stephen noticed that when the duplicate > > > commit appeared in linux-next. > > > > Both commits are in v6.15-rc1 now and the revert is not, so this > > should not get applied/pulled. Or you will need to revert the revert. > > yes, that was the intention. > > Back when I submitted this PR, I talked with Arnd on IRC the next day. > > As both commits are identical sans some Signed-off-by lines, he suggested > not trying to put a revert in, but instead let git solve it itself, because > > arnd on IRC: > > [...], but I worry that this would make things worse if 'git merge' > > ends up doing the revert on top of the original commit once it gets to > > torvalds. Not sure if that's still a problem in git these days, but > > I've seen it happen in the past. > > if two identical patches are in different branches, just leaving them > > there is usually easier > > So this PR was already marked as "superseeded" in patchwork back > on march 20th. > > > Nevertheless, thanks for making sure no funky revert happens now. The commit is still in linux-next though. That's how I happened upon this. Rob
Am Montag, 7. April 2025, 18:43:54 Mitteleuropäische Sommerzeit schrieb Rob Herring: > On Mon, Apr 7, 2025 at 11:40 AM Heiko Stübner <heiko@sntech.de> wrote: > > > > Hi Rob, > > > > Am Montag, 7. April 2025, 17:56:37 Mitteleuropäische Sommerzeit schrieb Rob Herring: > > > On Wed, Mar 19, 2025 at 6:56 PM Heiko Stuebner <heiko@sntech.de> wrote: > > > > > > > > Hi soc maintainers, > > > > > > > > I made an error and accidentially applied a patch that was meant for > > > > the mfd tree. Thankfully Stephen noticed that when the duplicate > > > > commit appeared in linux-next. > > > > > > Both commits are in v6.15-rc1 now and the revert is not, so this > > > should not get applied/pulled. Or you will need to revert the revert. > > > > yes, that was the intention. > > > > Back when I submitted this PR, I talked with Arnd on IRC the next day. > > > > As both commits are identical sans some Signed-off-by lines, he suggested > > not trying to put a revert in, but instead let git solve it itself, because > > > > arnd on IRC: > > > [...], but I worry that this would make things worse if 'git merge' > > > ends up doing the revert on top of the original commit once it gets to > > > torvalds. Not sure if that's still a problem in git these days, but > > > I've seen it happen in the past. > > > if two identical patches are in different branches, just leaving them > > > there is usually easier > > > > So this PR was already marked as "superseeded" in patchwork back > > on march 20th. > > > > > > Nevertheless, thanks for making sure no funky revert happens now. > > The commit is still in linux-next though. That's how I happened upon this. Ah right. I've recreated my next branch earlier today, after the -rc1 release, so this should be gone with the next linux-next. Heiko
On Mon, Apr 7, 2025 at 11:49 AM Heiko Stübner <heiko@sntech.de> wrote: > > Am Montag, 7. April 2025, 18:43:54 Mitteleuropäische Sommerzeit schrieb Rob Herring: > > On Mon, Apr 7, 2025 at 11:40 AM Heiko Stübner <heiko@sntech.de> wrote: > > > > > > Hi Rob, > > > > > > Am Montag, 7. April 2025, 17:56:37 Mitteleuropäische Sommerzeit schrieb Rob Herring: > > > > On Wed, Mar 19, 2025 at 6:56 PM Heiko Stuebner <heiko@sntech.de> wrote: > > > > > > > > > > Hi soc maintainers, > > > > > > > > > > I made an error and accidentially applied a patch that was meant for > > > > > the mfd tree. Thankfully Stephen noticed that when the duplicate > > > > > commit appeared in linux-next. > > > > > > > > Both commits are in v6.15-rc1 now and the revert is not, so this > > > > should not get applied/pulled. Or you will need to revert the revert. > > > > > > yes, that was the intention. > > > > > > Back when I submitted this PR, I talked with Arnd on IRC the next day. > > > > > > As both commits are identical sans some Signed-off-by lines, he suggested > > > not trying to put a revert in, but instead let git solve it itself, because > > > > > > arnd on IRC: > > > > [...], but I worry that this would make things worse if 'git merge' > > > > ends up doing the revert on top of the original commit once it gets to > > > > torvalds. Not sure if that's still a problem in git these days, but > > > > I've seen it happen in the past. > > > > if two identical patches are in different branches, just leaving them > > > > there is usually easier > > > > > > So this PR was already marked as "superseeded" in patchwork back > > > on march 20th. > > > > > > > > > Nevertheless, thanks for making sure no funky revert happens now. > > > > The commit is still in linux-next though. That's how I happened upon this. > > Ah right. I've recreated my next branch earlier today, after the -rc1 > release, so this should be gone with the next linux-next. Still there today and now we have: ['tsd,px30-cobra-ltk050h3146w', 'rockchip,px30-cobra', 'rockchip,px30'] ['tsd,px30-cobra-ltk050h3146w-a2', 'rockchip,px30-cobra', 'rockchip,px30'] ['tsd,px30-cobra-ltk500hd1829', 'tsd,px30-cobra', 'rockchip,px30'] Which appear on no list. Rob
Am Dienstag, 8. April 2025, 16:01:21 Mitteleuropäische Sommerzeit schrieb Rob Herring: > On Mon, Apr 7, 2025 at 11:49 AM Heiko Stübner <heiko@sntech.de> wrote: > > > > Am Montag, 7. April 2025, 18:43:54 Mitteleuropäische Sommerzeit schrieb Rob Herring: > > > On Mon, Apr 7, 2025 at 11:40 AM Heiko Stübner <heiko@sntech.de> wrote: > > > > > > > > Hi Rob, > > > > > > > > Am Montag, 7. April 2025, 17:56:37 Mitteleuropäische Sommerzeit schrieb Rob Herring: > > > > > On Wed, Mar 19, 2025 at 6:56 PM Heiko Stuebner <heiko@sntech.de> wrote: > > > > > > > > > > > > Hi soc maintainers, > > > > > > > > > > > > I made an error and accidentially applied a patch that was meant for > > > > > > the mfd tree. Thankfully Stephen noticed that when the duplicate > > > > > > commit appeared in linux-next. > > > > > > > > > > Both commits are in v6.15-rc1 now and the revert is not, so this > > > > > should not get applied/pulled. Or you will need to revert the revert. > > > > > > > > yes, that was the intention. > > > > > > > > Back when I submitted this PR, I talked with Arnd on IRC the next day. > > > > > > > > As both commits are identical sans some Signed-off-by lines, he suggested > > > > not trying to put a revert in, but instead let git solve it itself, because > > > > > > > > arnd on IRC: > > > > > [...], but I worry that this would make things worse if 'git merge' > > > > > ends up doing the revert on top of the original commit once it gets to > > > > > torvalds. Not sure if that's still a problem in git these days, but > > > > > I've seen it happen in the past. > > > > > if two identical patches are in different branches, just leaving them > > > > > there is usually easier > > > > > > > > So this PR was already marked as "superseeded" in patchwork back > > > > on march 20th. > > > > > > > > > > > > Nevertheless, thanks for making sure no funky revert happens now. > > > > > > The commit is still in linux-next though. That's how I happened upon this. > > > > Ah right. I've recreated my next branch earlier today, after the -rc1 > > release, so this should be gone with the next linux-next. > > Still there today and now we have: Not much luck for me this week it seems. So I've now re-created the for-next branch again, especially without the stuff from below. I guess the Revert slipped in again via that miss-merged branch. Looking at the rec-created https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/Documentation/devicetree?h=for-next that revert should be finally gone now and not reappear. > ['tsd,px30-cobra-ltk050h3146w', 'rockchip,px30-cobra', 'rockchip,px30'] > ['tsd,px30-cobra-ltk050h3146w-a2', 'rockchip,px30-cobra', 'rockchip,px30'] > ['tsd,px30-cobra-ltk500hd1829', 'tsd,px30-cobra', 'rockchip,px30'] > > Which appear on no list. And I've also fixed my scripts to not miss-merge branches not actually intended for next. Heiko
Hi soc maintainers, I made an error and accidentially applied a patch that was meant for the mfd tree. Thankfully Stephen noticed that when the duplicate commit appeared in linux-next. Please pull. Thanks Heiko The following changes since commit 73d246b4402c3356f6b3d13665de3a51eea7b555: arm64: dts: rockchip: remove ethm0_clk0_25m_out from Sige5 gmac0 (2025-03-15 15:49:00 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v6.15-rockchip-dts64-3 for you to fetch changes up to cee24bc73d4f3f47344a1a54100a69c72f1db061: Revert "dt-bindings: mfd: syscon: Add rk3528 QoS register compatible" (2025-03-19 00:22:18 +0100) ---------------------------------------------------------------- Revert of one commit that was applied accidentially and should instead go through the MFD tree. It is already part of that tree as commit 7f3e3e7228bb ("dt-bindings: mfd: syscon: Add rk3528 QoS register compatible"). ---------------------------------------------------------------- Heiko Stuebner (1): Revert "dt-bindings: mfd: syscon: Add rk3528 QoS register compatible" Documentation/devicetree/bindings/mfd/syscon.yaml | 2 -- 1 file changed, 2 deletions(-)