Sound Open Firmware
How to upstream Linux SOF driver patches? #7398
Replies: 15 comments
-
|
Yes, I agree with this. Great to have this formalized. I think there was a void period when the expectations were different :). First series of patches for Mediatek was sent by me. But I think Mediatek folks should take over this. I will continue to support them. |
Beta Was this translation helpful? Give feedback.
-
|
agreed, this makes sense, I will make sure to note that in our documentation. |
Beta Was this translation helpful? Give feedback.
-
|
@plbossart who is the expected owner of the common code patches? Or is it up to the author to send the patch? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I also agree. I think we can send our patches taken from topic/sof-dev-rebase directly to Mark Brown. and also appreciate @dbaluta support. Just want to confirm one thing. If there is a suggestion from Mark Brown and we need to modify our patches. How do I handle the modified patches on topic/sof-dev branch? (Do we revert the original patches and resend the modified patches?) |
Beta Was this translation helpful? Give feedback.
-
|
Good question @yaochunhung. What we've done so far is to create a new PR against topic/sof-dev, and depending on the complexity of the changes added the desired modification with a fixup! patch (or set of patches). When it's too complicated, it's easier to revert all the previous commits and restart. See examples in https://github.com/thesofproject/linux/pull/3232/commits |
Beta Was this translation helpful? Give feedback.
-
Very good question @kuanhsuncheng.
Also: Plenty of previous examples of previous Note the When upstream is merged back into |
Beta Was this translation helpful? Give feedback.
-
|
I think this will mess up if there are dependencies with the patches, especially, when there are patches with core file changes done by different authors, and also other complications as kuanhsuncheng mentioned. Other way also it won't be that simple to address the review comments from Mark by one person for other authors patches. Little complicated, need to find a way. |
Beta Was this translation helpful? Give feedback.
-
Good question as well. In most of the cases it was Intel submitting the patches, with @dbaluta doing some changes as well. I am not sure if there's any merit in defining a process for now, given that the core patches are still handled by Intel and NXP. The key part where we have a problem today is for hardware-specific patches. If and when we see key core changes done by Mediatek and AMD we will probably need some sort of sync-up channel. |
Beta Was this translation helpful? Give feedback.
-
We've addressed upstream feedback for 3 years, it's not that bad... |
Beta Was this translation helpful? Give feedback.
-
If developer B's series depends on developer A's series then developer B must simply wait until developer A's series is fully approved and merged upstream before formally submitting upstream. There is no tool or process that can magically make dependencies go away. It's not always possible but what can happen sometimes is one of the developer ends up doing the whole work. It can be less work even for the developer who does it all because it makes the communication costs go away. Otherwise: wait. |
Beta Was this translation helpful? Give feedback.
-
|
@plbossart since we are here, I want to clarify further more on the process. Once a patch is accepted to topic/sof-dev who is responsible of moving the patch to topic/sof-dev-rebase. Also, who will do the squashing for a fixup? |
Beta Was this translation helpful? Give feedback.
-
|
The topic/sof-dev-rebase branch is updated whenever we do an upstream merge. The process is a) use scripts to cherry-pick commits from topic/sof-dev to topic/sof-dev-rebase. The scripts automatically add the Reviewed-by tags based on github 'accept' status. The fixup! patches can be squashed at that point. At this point the two branches topic/sof-dev and topic/sof-dev-rebase shall be identical (using git diff). Since we have a single branch, we need one volunteer to do this work. We've split the work between Intel maintainers, @bardlio @ujfalusi @kv2019i @ranj063 and I have done it when we have spare cycles. The rebase typically happens 1-2 days after each rc update from Linus is propagated into maintainer branches. Does this help? |
Beta Was this translation helpful? Give feedback.
-
|
The periodic rebase process is also documented in https://thesofproject.github.io/latest/contribute/linux/development_tree.html#sof-maintainers-process |
Beta Was this translation helpful? Give feedback.
-
|
This discussion doesn't appear to be visible to sof-developers, can we publish workflow docs so devs can see this? or move to a visible mode? |
Beta Was this translation helpful? Give feedback.
-
I believe we have a shared expectation that the Linux SOF driver patches are reviewed on GitHub, with contributors from different companies providing feedback. Once patches are merged on the topic/sof-dev branch, they will also be applied with the review status on topic/sof-dev-rebase.
I don't think we have clarified how patches from e.g. AMD or Mediatek would land on the alsa-devel mailing list. Clearly no one from Intel is prepared to send hardware support patches for a competing platform to Mark Brown. Core changes and minor fixes on existing code are acceptable, but NXP, Mediatek and AMD should send their own patches taken from topic/sof-dev-rebase directly to Mark Brown.
In the past this was an informal process with @dbaluta but now with four contributing companies we have to formally agree on who does what.
@dbaluta @ajitkupandey @kuanhsuncheng @cujomalainey does this align with your understanding/expectations?
Beta Was this translation helpful? Give feedback.
All reactions