Upstreaming - how to deal with vendor fork

Upstreaming - how to deal with vendor fork

[Patryk]

[-- Attachment #1.1: Type: text/plain, Size: 1490 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1943 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Upstreaming - how to deal with vendor fork

[Linus Probert]

[-- Attachment #1.1: Type: text/plain, Size: 2196 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Upstreaming - how to deal with vendor fork

[Greg KH]

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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Upstreaming - how to deal with vendor fork

[Linus Probert]

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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies