search

sonyxperiadev / kernel

Other
353 stars 364 forks source link

[LA.UM.9.12.r1] Backport msm pci changes from LA.UM.9.14.r1 #2474

Closed Thaodan closed 2 years ago

Thaodan commented 2 years ago

This PR backports changes from msm pci LA.UM.9.14.r1 to fix issues releasing IRQs making the reverting of a later mainline redundant.

jerpelea commented 2 years ago

cherry-picked

MarijnS95 commented 2 years ago

Is there a particular advantage history-wise to revert your own revert-commit, within the same PR?

Thaodan commented 2 years ago

Is there a particular advantage history-wise to revert your own revert-commit, within the same PR? Yes I don't have to force push to revert my commit?

MarijnS95 commented 2 years ago

Yes I don't have to force push to revert my commit?

Do consider that, while this may be easier for yourself, it introduces extraneous overhead and noise upstream.

Thaodan commented 2 years ago

Yes I don't have to force push to revert my commit?

Do consider that, while this may be easier for yourself, it introduces more overhead and noise upstream.

I can't do that and this can create issues downstream e.g. In our/hybris kernel tree.

MarijnS95 commented 2 years ago

I can't do that and this can create issues downstream e.g. In our/hybris kernel tree.

That doesn't set a great precedent for upstream contributions, where the maintainer generally picks (rebase-merges) changes on top. Presuming the upstream project doesn't force push (which we as smaller project try not to do, but is sometimes necessary to combat "accidents"), downstream projects are expected to simply merge in the upstream branch or better: rebase their own patches on top so that they can be smoothly reworked for submission (where necessary) too.

MarijnS95 commented 2 years ago

It looks like this PR and the picking of it created the wrong outcome now. Your original revert was applied a while ago in e718cae4b3eea (#2471), and now the patches were picked in the wrong order so that it was first reverted again in 7aa55fbaed1c0, and then reapplied again in 4401449fe74f1).

In other words, this PR (you can just create a new branch, nothing that should affect downstream hybris) should have been based on top of at least e718cae4b3eea, and should have never included e4fab65af86562c87ae783714c82d75825b5a66e as it was already applied.

Case in point.

jerpelea commented 2 years ago

I will force push the cleanup ASAP

Thaodan commented 2 years ago

It looks like this PR and the picking of it created the wrong outcome now. Your original revert was applied a while ago in e718cae (#2471), and now the patches were picked in the wrong order so that it was first reverted again in 7aa55fb, and then reapplied again in 4401449).

The revert was because the revert was redundant now by the backports applied to the kernel so you dropping the revert is fine.