Rockchip dts64 changes for 6.15 #3

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(-)

Quoted 6 lines

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.

[...], 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

Quoted 28 lines

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:

Quoted 10 lines · Heiko Stuebner

Quoted 6 lines

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:

Quoted 6 lines

[...], 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.

Quoted 30 lines

Hi Rob,

Am Montag, 7. April 2025, 17:56:37 Mitteleuropäische Sommerzeit schrieb Rob Herring:

Quoted 10 lines · Heiko Stuebner

Quoted 6 lines

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:

Quoted 6 lines

[...], 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

Quoted 5 lines

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.

Am Montag, 7. April 2025, 18:43:54 Mitteleuropäische Sommerzeit schrieb Rob Herring:

Quoted 35 lines · Heiko Stübner

Quoted 34 lines

Hi Rob,

Am Montag, 7. April 2025, 17:56:37 Mitteleuropäische Sommerzeit schrieb Rob Herring:

Quoted 10 lines · Heiko Stuebner

Quoted 6 lines

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:

Quoted 6 lines

[...], 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.

Quoted 3 lines

Quoted 1 line

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.

Quoted 37 lines

Am Montag, 7. April 2025, 18:43:54 Mitteleuropäische Sommerzeit schrieb Rob Herring:

Quoted 35 lines · Heiko Stübner

Quoted 34 lines

Hi Rob,

Am Montag, 7. April 2025, 17:56:37 Mitteleuropäische Sommerzeit schrieb Rob Herring:

Quoted 10 lines · Heiko Stuebner

Quoted 6 lines

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:

Quoted 6 lines

[...], 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.

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

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.