Upstreaming - how to deal with vendor fork
Hi Some time ago I managed to upstream one bugfix, now I have more changes but I'm wondering how to approach this. Suppose that I have found a bug and prepared a fix. However, the bug and its solution has been found and tested on a custom board that is equipped with a particular buggy device. The problem is that I cannot simply use mainline/maintainer tree, build it, and run on my board as these source trees do not have support for my board, as I use SoC vendor fork (v6.12) supplied with their bsp with patches that add support for my board. It's not mine decision - obviously - me and my team would be very willing to use mainline but it would require some effort, time and obviously we would not get vendor support in case of some bugs (it happened mamy times). I can of course take the minimal set of patches for out board and apply them over mainline but e.g. now I have a bugfix for mainline driver...but in order to fully test it I need vendor changes as they did not upstream it yet. So at the end in order to test a bugfix on the mainline I would need to apply patches that add support for my board as well patches from vendor fork that add support for the rest of the functionality (not yet upstreamed by vendor) that I need in order to test the bugfix. Any sugestion on how to approach this? I have already few changes that could be applied to mainline but due to what I described above they're just waiting... Will be grateful for some sugestion. Best regards Patryk
On Wed Apr 29, 2026 at 3:27 PM CEST, Patryk wrote:
Hi Some time ago I managed to upstream one bugfix, now I have more changes but I'm wondering how to approach this.
Suppose that I have found a bug and prepared a fix. However, the bug and its solution has been found and tested on a custom board that is equipped with a particular buggy device. The problem is that I cannot simply use mainline/maintainer tree, build it, and run on my board as these source trees do not have support for my board, as I use SoC vendor fork (v6.12) supplied with their bsp with patches that add support for my board.
It's not mine decision - obviously - me and my team would be very willing to use mainline but it would require some effort, time and obviously we would not get vendor support in case of some bugs (it happened mamy times).
I can of course take the minimal set of patches for out board and apply them over mainline but e.g. now I have a bugfix for mainline driver...but in order to fully test it I need vendor changes as they did not upstream it yet.
So at the end in order to test a bugfix on the mainline I would need to apply patches that add support for my board as well patches from vendor fork that add support for the rest of the functionality (not yet upstreamed by vendor) that I need in order to test the bugfix.
Any sugestion on how to approach this? I have already few changes that could be applied to mainline but due to what I described above they're just waiting...
Will be grateful for some sugestion.
Best regards Patryk
Hi Patryk, if your patches can't be applied without first applying the vendors patches then there's not much you can do is there. Your fixes won't apply. If your patches do apply to staging-next and they do fix your issue isn't that enough to submit them? You should be able to explain how you have confirmed the fixes even though it requires some steps to get there. You can always submit a patch-tree to linux-staging with an RFC prefix and you will get feedback based on that. Either you get a no or a yes. Worth testing IMO. Br, Linus
On Wed, Apr 29, 2026 at 07:42:14PM +0200, Linus Probert wrote:
On Wed Apr 29, 2026 at 3:27 PM CEST, Patryk wrote:
Hi Some time ago I managed to upstream one bugfix, now I have more changes but I'm wondering how to approach this.
Suppose that I have found a bug and prepared a fix. However, the bug and its solution has been found and tested on a custom board that is equipped with a particular buggy device. The problem is that I cannot simply use mainline/maintainer tree, build it, and run on my board as these source trees do not have support for my board, as I use SoC vendor fork (v6.12) supplied with their bsp with patches that add support for my board.
It's not mine decision - obviously - me and my team would be very willing to use mainline but it would require some effort, time and obviously we would not get vendor support in case of some bugs (it happened mamy times).
I can of course take the minimal set of patches for out board and apply them over mainline but e.g. now I have a bugfix for mainline driver...but in order to fully test it I need vendor changes as they did not upstream it yet.
So at the end in order to test a bugfix on the mainline I would need to apply patches that add support for my board as well patches from vendor fork that add support for the rest of the functionality (not yet upstreamed by vendor) that I need in order to test the bugfix.
Any sugestion on how to approach this? I have already few changes that could be applied to mainline but due to what I described above they're just waiting...
Will be grateful for some sugestion.
Best regards Patryk
Hi Patryk,
if your patches can't be applied without first applying the vendors patches then there's not much you can do is there. Your fixes won't apply.
If your patches do apply to staging-next and they do fix your issue isn't that enough to submit them? You should be able to explain how you have confirmed the fixes even though it requires some steps to get there.
You can always submit a patch-tree to linux-staging with an RFC prefix and you will get feedback based on that. Either you get a no or a yes. Worth testing IMO.
What does the staging tree have to do with this? confused, greg k-h
On Thu Apr 30, 2026 at 9:15 AM CEST, Greg KH wrote:
On Wed, Apr 29, 2026 at 07:42:14PM +0200, Linus Probert wrote:
On Wed Apr 29, 2026 at 3:27 PM CEST, Patryk wrote:
Hi Some time ago I managed to upstream one bugfix, now I have more changes but I'm wondering how to approach this.
Suppose that I have found a bug and prepared a fix. However, the bug and its solution has been found and tested on a custom board that is equipped with a particular buggy device. The problem is that I cannot simply use mainline/maintainer tree, build it, and run on my board as these source trees do not have support for my board, as I use SoC vendor fork (v6.12) supplied with their bsp with patches that add support for my board.
It's not mine decision - obviously - me and my team would be very willing to use mainline but it would require some effort, time and obviously we would not get vendor support in case of some bugs (it happened mamy times).
I can of course take the minimal set of patches for out board and apply them over mainline but e.g. now I have a bugfix for mainline driver...but in order to fully test it I need vendor changes as they did not upstream it yet.
So at the end in order to test a bugfix on the mainline I would need to apply patches that add support for my board as well patches from vendor fork that add support for the rest of the functionality (not yet upstreamed by vendor) that I need in order to test the bugfix.
Any sugestion on how to approach this? I have already few changes that could be applied to mainline but due to what I described above they're just waiting...
Will be grateful for some sugestion.
Best regards Patryk
Hi Patryk,
if your patches can't be applied without first applying the vendors patches then there's not much you can do is there. Your fixes won't apply.
If your patches do apply to staging-next and they do fix your issue isn't that enough to submit them? You should be able to explain how you have confirmed the fixes even though it requires some steps to get there.
You can always submit a patch-tree to linux-staging with an RFC prefix and you will get feedback based on that. Either you get a no or a yes. Worth testing IMO.
What does the staging tree have to do with this?
confused,
greg k-h
Nothing most likely. Patryk should use an appropriate tree for his fixes if they are applicable. The driver was never named. I mostly look at the staging tree so it was fresh on my mind. Freudian slip if you will. Br, Linus
participants (3)
-
Greg KH -
Linus Probert -
Patryk